linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Suman Anna <s-anna@ti.com>
Cc: linux-remoteproc@vger.kernel.org, Sekhar Nori <nsekhar@ti.com>,
	Robert Tivy <rtivy@ti.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] remoteproc/davinci: streamline the interrupt management
Date: Sun, 25 Jun 2017 14:19:31 -0700	[thread overview]
Message-ID: <20170625211931.GC26155@builder> (raw)
In-Reply-To: <20170518220902.2846-5-s-anna@ti.com>

On Thu 18 May 15:09 PDT 2017, Suman Anna wrote:

> The davinci remoteproc driver is currently requesting its interrupt
> that deals with the virtio kicks in probe, and that too before all
> the associated variables used by the handler are initialized. This
> is a lot in advance before the DSP remote processor is even loaded
> and booted and is not essential. Streamline the interrupt request
> and freeing operations instead alongside the boot and shutdown of
> the remote processor.
> 

I do prefer that all resources are acquired at probe() time, rather than
handled upon each start/stop. In the current handle_event()
implementation the remoteproc code will not find the yet unallocated
notify-id's and do nothing. So this seems okay.

[..]
> @@ -213,15 +224,6 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, rproc);
>  
> -	/* everything the ISR needs is now setup, so hook it up */
> -	ret = devm_request_threaded_irq(dev, irq, da8xx_rproc_callback,
> -					handle_event, 0, "da8xx-remoteproc",
> -					rproc);
> -	if (ret) {
> -		dev_err(dev, "devm_request_threaded_irq error: %d\n", ret);
> -		goto free_rproc;
> -	}

In the error paths after this the driver will end up freeing the rproc
context before disabling the irq, so these cases need a call to
disable_irq().

> -
>  	/*
>  	 * rproc_add() can end up enabling the DSP's clk with the DSP
>  	 * *not* in reset, but da8xx_rproc_start() needs the DSP to be
> @@ -254,14 +256,6 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
>  static int da8xx_rproc_remove(struct platform_device *pdev)
>  {
>  	struct rproc *rproc = platform_get_drvdata(pdev);
> -	struct da8xx_rproc *drproc = (struct da8xx_rproc *)rproc->priv;
> -
> -	/*
> -	 * The devm subsystem might end up releasing things before
> -	 * freeing the irq, thus allowing an interrupt to sneak in while
> -	 * the device is being removed.  This should prevent that.
> -	 */

devres _will not_ disable the IRQ until after remove() returns, making it
possible for the interrupt handler to be executed after the rproc
context is freed.

So this comment would benefit from an update.

> -	disable_irq(drproc->irq);
>  
>  	rproc_del(rproc);
>  	rproc_free(rproc);

Regards,
Bjorn

  reply	other threads:[~2017-06-25 21:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 22:08 [PATCH 0/4] Davinci remoteproc cleanups/fixes Suman Anna
2017-05-18 22:08 ` [PATCH 1/4] remoteproc/davinci: Update Kconfig to depend on DMA_CMA Suman Anna
2017-05-18 22:09 ` [PATCH 2/4] remoteproc/davinci: simplify the reset function Suman Anna
2017-05-18 22:09 ` [PATCH 3/4] remoteproc/davinci: fix unbalanced reset between start and stop ops Suman Anna
2017-05-18 22:09 ` [PATCH 4/4] remoteproc/davinci: streamline the interrupt management Suman Anna
2017-06-25 21:19   ` Bjorn Andersson [this message]
2017-06-26 16:09     ` Suman Anna
2017-06-27  5:38       ` Bjorn Andersson
2017-06-27 19:14         ` Suman Anna
2017-06-08 20:47 ` [PATCH 0/4] Davinci remoteproc cleanups/fixes Suman Anna
2017-06-23 21:29   ` Suman Anna
2017-06-25 21:19 ` Bjorn Andersson

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=20170625211931.GC26155@builder \
    --to=bjorn.andersson@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=rtivy@ti.com \
    --cc=s-anna@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).