All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Beleswar Prasad Padhi <b-padhi@ti.com>
Cc: andersson@kernel.org, afd@ti.com, hnagalla@ti.com,
	u-kumar1@ti.com, s-anna@ti.com, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe routine
Date: Fri, 16 Aug 2024 08:51:25 -0600	[thread overview]
Message-ID: <Zr9nbWnADDB+ZOlg@p14s> (raw)
In-Reply-To: <d0fea480-1682-48ec-99dd-73deaff99d7d@ti.com>

On Fri, Aug 16, 2024 at 01:23:59PM +0530, Beleswar Prasad Padhi wrote:
> Hi Mathieu,
> 
> On 14-08-2024 21:22, Mathieu Poirier wrote:
> > Hi Beleswar, On Thu, Aug 08, 2024 at 01: 11: 26PM +0530, Beleswar Padhi
> > wrote: > 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
> > ZjQcmQRYFpfptBannerStart
> > Report Suspicious
> > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!vldnVV7DH2eSIoaksHjpMPogloWUPfAcp2-dEVbMoE1YA3kGFXdJXGAJUKJm$>
> > 
> > ZjQcmQRYFpfptBannerEnd
> > Hi Beleswar,
> > 
> > On Thu, Aug 08, 2024 at 01:11:26PM +0530, Beleswar Padhi wrote:
> > > 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 <b-padhi@ti.com>
> > > ---
> > >  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_client *client, void *data)
> > >  	const char *name = kproc->rproc->name;
> > >  	u32 msg = omap_mbox_message(data);
> > >  > +	/* Do not forward message from a detached core */
> > > +	if (kproc->rproc->state == RPROC_DETACHED)
> > > +		return;
> > > +
> > >  	dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> > >  >  	switch (msg) {
> > > @@ -229,6 +233,10 @@ static void k3_r5_rproc_kick(struct rproc *rproc, int vqid)
> > >  	mbox_msg_t msg = (mbox_msg_t)vqid;
> > >  	int ret;
> > >  > +	/* Do not forward message to a detached core */
> > > +	if (kproc->rproc->state == RPROC_DETACHED)
> > > +		return;
> > > +
> > >  	/* send the index of the triggered virtqueue in the mailbox payload */
> > >  	ret = mbox_send_message(kproc->mbox, (void *)msg);
> > >  	if (ret < 0)
> > > @@ -399,12 +407,9 @@ static int k3_r5_rproc_request_mbox(struct rproc *rproc)
> > >  	client->knows_txdone = false;
> > >  >  	kproc->mbox = mbox_request_channel(client, 0);
> > > -	if (IS_ERR(kproc->mbox)) {
> > > -		ret = -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");
> > >  >  	/*
> > >  	 * 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;
> > >  > -	ret = k3_r5_rproc_request_mbox(rproc);
> > > -	if (ret)
> > > -		return ret;
> > > -
> > >  	boot_addr = rproc->bootaddr;
> > >  	/* TODO: add boot_addr sanity checking */
> > >  	dev_dbg(dev, "booting R5F core using boot addr = 0x%x\n", boot_addr);
> > > @@ -564,7 +565,7 @@ static int k3_r5_rproc_start(struct rproc *rproc)
> > >  	core = kproc->core;
> > >  	ret = ti_sci_proc_set_config(core->tsp, boot_addr, 0, 0);
> > >  	if (ret)
> > > -		goto put_mbox;
> > > +		return ret;
> > >  >  	/* unhalt/run all applicable cores */
> > >  	if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
> > > @@ -580,13 +581,12 @@ static int k3_r5_rproc_start(struct rproc *rproc)
> > >  		if (core != core0 && core0->rproc->state == RPROC_OFFLINE) {
> > >  			dev_err(dev, "%s: can not start core 1 before core 0\n",
> > >  				__func__);
> > > -			ret = -EPERM;
> > > -			goto put_mbox;
> > > +			return -EPERM;
> > >  		}
> > >  >  		ret = k3_r5_core_run(core);
> > >  		if (ret)
> > > -			goto put_mbox;
> > > +			return ret;
> > >  	}
> > >  >  	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;
> > >  }
> > >  > @@ -658,8 +656,6 @@ static int k3_r5_rproc_stop(struct rproc
> > *rproc)
> > >  			goto out;
> > >  	}
> > >  > -	mbox_free_channel(kproc->mbox);
> > > -
> > >  	return 0;
> > >  >  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 invoked
> > > - * only in IPC-only mode.
> > > + * The R5F attach callback is a NOP. The remote processor is already booted, and
> > > + * all required resources have been acquired during probe routine, so there 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.
> > 
> > Excellent documentation.
> 
> 
> Thanks!
> 
> > 
> > >   */
> > > -static int k3_r5_rproc_attach(struct rproc *rproc)
> > > -{
> > > -	struct k3_r5_rproc *kproc = rproc->priv;
> > > -	struct device *dev = kproc->dev;
> > > -	int ret;
> > > -
> > > -	ret = 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; }
> > >  >  /*
> > >   * Detach from a running R5F remote processor (IPC-only mode)
> > >   *
> > > - * The R5F detach callback performs the opposite operation to attach callback
> > > - * 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 will be
> > > + * left in booted state in IPC-only mode. This callback is invoked only in
> > > + * IPC-only mode and exists for sanity sake.
> > 
> > I would add the part about detach() being a NOP to attach() above...
> > 
> > >   */
> > > -static int k3_r5_rproc_detach(struct rproc *rproc)
> > > -{
> > > -	struct k3_r5_rproc *kproc = rproc->priv;
> > > -	struct device *dev = 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; }
> > 
> > ... and just remove this.
> 
> 
> Thanks for the comments. But dropping k3_r5_rproc_detach() would mean we
> would get -EINVAL[1] while trying to detach the core from sysfs[0]. Is it
> expected?
>

You are correct.  I have applied your patch.

> [0]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/remoteproc_sysfs.c#n202
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/remoteproc_core.c#n1752
> 
> > 
> > Otherwise this patch looks good.
> > 
> > >  >  /*
> > >   * This function implements the .get_loaded_rsc_table() callback and is used
> > > @@ -1278,6 +1254,10 @@ static int k3_r5_cluster_rproc_init(struct platform_device *pdev)
> > >  		kproc->rproc = rproc;
> > >  		core->rproc = rproc;
> > >  > +		ret = k3_r5_rproc_request_mbox(rproc);
> > > +		if (ret)
> > > +			return ret;
> > > +
> > >  		ret = k3_r5_rproc_configure_mode(kproc);
> > >  		if (ret < 0)
> > >  			goto out;
> > > @@ -1392,6 +1372,8 @@ static void k3_r5_cluster_rproc_exit(void *data)
> > >  			}
> > >  		}
> > >  > +		mbox_free_channel(kproc->mbox);
> > > +
> > >  		rproc_del(rproc);
> > >  >  		k3_r5_reserved_mem_exit(kproc);
> > > -- > 2.34.1
> > >

  reply	other threads:[~2024-08-16 14:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-08  7:41 [PATCH v4 0/3] Defer TI's Remoteproc's Probe until Mailbox is Probed Beleswar Padhi
2024-08-08  7:41 ` [PATCH v4 1/3] remoteproc: k3-r5: Use devm_rproc_alloc() helper Beleswar Padhi
2024-08-08 14:22   ` Andrew Davis
2024-08-08  7:41 ` [PATCH v4 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe routine Beleswar Padhi
2024-08-14 15:52   ` Mathieu Poirier
2024-08-16  7:53     ` Beleswar Prasad Padhi
2024-08-16 14:51       ` Mathieu Poirier [this message]
2024-08-08  7:41 ` [PATCH v4 3/3] remoteproc: k3-dsp: " Beleswar Padhi
2024-08-14 15:53   ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zr9nbWnADDB+ZOlg@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=afd@ti.com \
    --cc=andersson@kernel.org \
    --cc=b-padhi@ti.com \
    --cc=hnagalla@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=s-anna@ti.com \
    --cc=u-kumar1@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.