From nobody Tue Dec 16 22:19:26 2025 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C1BA18950C; Thu, 8 Aug 2024 07:41:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.23.249 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723102901; cv=none; b=KGuq4TXyeKue9SylJYs4DVphNpFtzZYT4THfzD+LFM6NWqwy6JN65dyme/CzxYc0+TInwfoN2r6uI+8JwP2VRBbxIhAdFmnf8NH00h0QqAKVq5sxWgvmRNwGu0YfXD1mR2v4WF0QZgLXgABzfaJEECD7m7/XhsJp9qjxkkIN2T8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723102901; c=relaxed/simple; bh=nlN9IikgQ3NvFEixRonssv1CTijOfPnjKPsXaZPYm9M=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NWos+3ZBhLwwojmKzSrvaSOFVvIfroqzVFULOX1g81US6RkFN//udfQAugoCu7FGW3VHwRfGu2NVyDFdzkcqZtXyqlUA1T9d8GDuhDD/jtjfO8SgA9dbwknSgLTVjQIOHNEs5z0bsJpkzEO9CHB1Tnp4TFO2ldTGPXDMzLViXMQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com; spf=pass smtp.mailfrom=ti.com; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b=JjjgHzAP; arc=none smtp.client-ip=198.47.23.249 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="JjjgHzAP" Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 4787faDq049403; Thu, 8 Aug 2024 02:41:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1723102896; bh=R0iPLkMWPfN4m0cRuChhb/Nwq+8wgteVEpwiD+QvVK0=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=JjjgHzAP4/kw5pezPcdzp6Mh3+xaOfUWSKic6IXxHpNpzBnpacaDM65YMDAws4fiH npK+h1sPqr7lSpdPuB0f/TM0hbldEt3yz6sSGwWLNQpXiL8xjR8LqwJvmTaR6whutx cWJ+RC24rbikMgPCUnQMj+LfzS7l4KyaOC5397xo= Received: from DLEE100.ent.ti.com (dlee100.ent.ti.com [157.170.170.30]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 4787faFp087387 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 8 Aug 2024 02:41:36 -0500 Received: from DLEE101.ent.ti.com (157.170.170.31) by DLEE100.ent.ti.com (157.170.170.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Thu, 8 Aug 2024 02:41:35 -0500 Received: from lelvsmtp6.itg.ti.com (10.180.75.249) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Thu, 8 Aug 2024 02:41:35 -0500 Received: from uda0510294.dhcp.ti.com (uda0510294.dhcp.ti.com [172.24.227.151]) by lelvsmtp6.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4787fRZP020900; Thu, 8 Aug 2024 02:41:33 -0500 From: Beleswar Padhi To: , , CC: , , , , Subject: [PATCH v4 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe routine Date: Thu, 8 Aug 2024 13:11:26 +0530 Message-ID: <20240808074127.2688131-3-b-padhi@ti.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240808074127.2688131-1-b-padhi@ti.com> References: <20240808074127.2688131-1-b-padhi@ti.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Content-Type: text/plain; charset="utf-8" Acquire the mailbox handle during device probe and do not release handle in stop/detach routine or error paths. This removes the redundant requests for mbox handle later during rproc start/attach. This also allows to defer remoteproc driver's probe if mailbox is not probed yet. Signed-off-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_r5_remoteproc.c | 78 +++++++++--------------- 1 file changed, 30 insertions(+), 48 deletions(-) diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/= ti_k3_r5_remoteproc.c index 57067308b3c0..8a63a9360c0f 100644 --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c @@ -194,6 +194,10 @@ static void k3_r5_rproc_mbox_callback(struct mbox_clie= nt *client, void *data) const char *name =3D kproc->rproc->name; u32 msg =3D omap_mbox_message(data); =20 + /* Do not forward message from a detached core */ + if (kproc->rproc->state =3D=3D RPROC_DETACHED) + return; + dev_dbg(dev, "mbox msg: 0x%x\n", msg); =20 switch (msg) { @@ -229,6 +233,10 @@ static void k3_r5_rproc_kick(struct rproc *rproc, int = vqid) mbox_msg_t msg =3D (mbox_msg_t)vqid; int ret; =20 + /* Do not forward message to a detached core */ + if (kproc->rproc->state =3D=3D RPROC_DETACHED) + return; + /* send the index of the triggered virtqueue in the mailbox payload */ ret =3D mbox_send_message(kproc->mbox, (void *)msg); if (ret < 0) @@ -399,12 +407,9 @@ static int k3_r5_rproc_request_mbox(struct rproc *rpro= c) client->knows_txdone =3D false; =20 kproc->mbox =3D mbox_request_channel(client, 0); - if (IS_ERR(kproc->mbox)) { - ret =3D -EBUSY; - dev_err(dev, "mbox_request_channel failed: %ld\n", - PTR_ERR(kproc->mbox)); - return ret; - } + if (IS_ERR(kproc->mbox)) + return dev_err_probe(dev, PTR_ERR(kproc->mbox), + "mbox_request_channel failed\n"); =20 /* * Ping the remote processor, this is only for sanity-sake for now; @@ -552,10 +557,6 @@ static int k3_r5_rproc_start(struct rproc *rproc) u32 boot_addr; int ret; =20 - ret =3D k3_r5_rproc_request_mbox(rproc); - if (ret) - return ret; - boot_addr =3D rproc->bootaddr; /* TODO: add boot_addr sanity checking */ dev_dbg(dev, "booting R5F core using boot addr =3D 0x%x\n", boot_addr); @@ -564,7 +565,7 @@ static int k3_r5_rproc_start(struct rproc *rproc) core =3D kproc->core; ret =3D ti_sci_proc_set_config(core->tsp, boot_addr, 0, 0); if (ret) - goto put_mbox; + return ret; =20 /* unhalt/run all applicable cores */ if (cluster->mode =3D=3D CLUSTER_MODE_LOCKSTEP) { @@ -580,13 +581,12 @@ static int k3_r5_rproc_start(struct rproc *rproc) if (core !=3D core0 && core0->rproc->state =3D=3D RPROC_OFFLINE) { dev_err(dev, "%s: can not start core 1 before core 0\n", __func__); - ret =3D -EPERM; - goto put_mbox; + return -EPERM; } =20 ret =3D k3_r5_core_run(core); if (ret) - goto put_mbox; + return ret; } =20 return 0; @@ -596,8 +596,6 @@ static int k3_r5_rproc_start(struct rproc *rproc) if (k3_r5_core_halt(core)) dev_warn(core->dev, "core halt back failed\n"); } -put_mbox: - mbox_free_channel(kproc->mbox); return ret; } =20 @@ -658,8 +656,6 @@ static int k3_r5_rproc_stop(struct rproc *rproc) goto out; } =20 - mbox_free_channel(kproc->mbox); - return 0; =20 unroll_core_halt: @@ -674,42 +670,22 @@ static int k3_r5_rproc_stop(struct rproc *rproc) /* * Attach to a running R5F remote processor (IPC-only mode) * - * The R5F attach callback only needs to request the mailbox, the remote - * processor is already booted, so there is no need to issue any TI-SCI - * commands to boot the R5F cores in IPC-only mode. This callback is invok= ed - * only in IPC-only mode. + * The R5F attach callback is a NOP. The remote processor is already boote= d, and + * all required resources have been acquired during probe routine, so ther= e is + * no need to issue any TI-SCI commands to boot the R5F cores in IPC-only = mode. + * This callback is invoked only in IPC-only mode and exists because + * rproc_validate() checks for its existence. */ -static int k3_r5_rproc_attach(struct rproc *rproc) -{ - struct k3_r5_rproc *kproc =3D rproc->priv; - struct device *dev =3D kproc->dev; - int ret; - - ret =3D k3_r5_rproc_request_mbox(rproc); - if (ret) - return ret; - - dev_info(dev, "R5F core initialized in IPC-only mode\n"); - return 0; -} +static int k3_r5_rproc_attach(struct rproc *rproc) { return 0; } =20 /* * Detach from a running R5F remote processor (IPC-only mode) * - * The R5F detach callback performs the opposite operation to attach callb= ack - * and only needs to release the mailbox, the R5F cores are not stopped and - * will be left in booted state in IPC-only mode. This callback is invoked - * only in IPC-only mode. + * The R5F detach callback is a NOP. The R5F cores are not stopped and wil= l be + * left in booted state in IPC-only mode. This callback is invoked only in + * IPC-only mode and exists for sanity sake. */ -static int k3_r5_rproc_detach(struct rproc *rproc) -{ - struct k3_r5_rproc *kproc =3D rproc->priv; - struct device *dev =3D kproc->dev; - - mbox_free_channel(kproc->mbox); - dev_info(dev, "R5F core deinitialized in IPC-only mode\n"); - return 0; -} +static int k3_r5_rproc_detach(struct rproc *rproc) { return 0; } =20 /* * This function implements the .get_loaded_rsc_table() callback and is us= ed @@ -1278,6 +1254,10 @@ static int k3_r5_cluster_rproc_init(struct platform_= device *pdev) kproc->rproc =3D rproc; core->rproc =3D rproc; =20 + ret =3D k3_r5_rproc_request_mbox(rproc); + if (ret) + return ret; + ret =3D k3_r5_rproc_configure_mode(kproc); if (ret < 0) goto out; @@ -1392,6 +1372,8 @@ static void k3_r5_cluster_rproc_exit(void *data) } } =20 + mbox_free_channel(kproc->mbox); + rproc_del(rproc); =20 k3_r5_reserved_mem_exit(kproc); --=20 2.34.1