All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Russell King <linux@arm.linux.org.uk>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Vinod Koul <vinod.koul@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dmaengine@vger.kernel.org, Grant Likely <grant.likely@linaro.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Michal Simek <michal.simek@xilinx.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Randy Dunlap <rdunlap@infradead.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH v5 3/4] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM
Date: Tue, 16 Sep 2014 20:25:25 +0200	[thread overview]
Message-ID: <CAPDyKFrNYxSx3KwOLg0Bgw2TCtsC2-1YXjo1kSms2ie_b8sNww@mail.gmail.com> (raw)
In-Reply-To: <1410872360-27029-4-git-send-email-k.kozlowski@samsung.com>

On 16 September 2014 14:59, Krzysztof Kozlowski <k.kozlowski@samsung.com> wrote:
> The AMBA bus driver defines runtime Power Management functions which
> disable and unprepare AMBA bus clock. This is problematic for runtime PM
> because unpreparing a clock might sleep so it is not interrupt safe.
>
> However some drivers may want to implement runtime PM functions in
> interrupt-safe way (see pm_runtime_irq_safe()). In such case the AMBA
> bus driver should only disable/enable the clock in runtime suspend and
> resume callbacks.
>
> Detect the device driver behavior after calling its probe function and
> store it. During runtime suspend/resume deal with clocks according to
> stored value.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> ---
>  drivers/amba/bus.c       | 29 +++++++++++++++++++++++++----
>  include/linux/amba/bus.h |  1 +
>  2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 3cf61a127ee5..e8fd5706954f 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -94,8 +94,18 @@ static int amba_pm_runtime_suspend(struct device *dev)
>         struct amba_device *pcdev = to_amba_device(dev);
>         int ret = pm_generic_runtime_suspend(dev);
>
> -       if (ret == 0 && dev->driver)
> -               clk_disable_unprepare(pcdev->pclk);
> +       if (ret == 0 && dev->driver) {
> +               /*
> +                * Drivers should not change pm_runtime_irq_safe()
> +                * after probe.
> +                */
> +               WARN_ON(pcdev->irq_safe != pm_runtime_is_irq_safe(dev));

Do we really need a WARN_ON here. Driver shouldn't update their
irq_safe value dynamically, right!?

> +
> +               if (pcdev->irq_safe)
> +                       clk_disable(pcdev->pclk);

Since the irq_safe flag, could be considered as a special case, an
option for these cases - could be to leave the clock to be entirely
handled from the driver's runtime PM callback instead.

I wonder if that could simplify both for the driver and for the amba bus?

Russell, what do you think? Is it a bad idea?

> +               else
> +                       clk_disable_unprepare(pcdev->pclk);
> +       }
>
>         return ret;
>  }
> @@ -106,7 +116,16 @@ static int amba_pm_runtime_resume(struct device *dev)
>         int ret;
>
>         if (dev->driver) {
> -               ret = clk_prepare_enable(pcdev->pclk);
> +               /*
> +                * Drivers should not change pm_runtime_irq_safe()
> +                * after probe.
> +                */
> +               WARN_ON(pcdev->irq_safe != pm_runtime_is_irq_safe(dev));
> +
> +               if (pcdev->irq_safe)
> +                       ret = clk_enable(pcdev->pclk);
> +               else
> +                       ret = clk_prepare_enable(pcdev->pclk);
>                 /* Failure is probably fatal to the system, but... */
>                 if (ret)
>                         return ret;
> @@ -191,8 +210,10 @@ static int amba_probe(struct device *dev)
>                 pm_runtime_enable(dev);
>
>                 ret = pcdrv->probe(pcdev, id);
> -               if (ret == 0)
> +               if (ret == 0) {
> +                       pcdev->irq_safe = pm_runtime_is_irq_safe(dev);

I suggest to remove the local copy of this flag and to use
pm_runtime_is_irq_safe(dev) directly instead.

>                         break;
> +               }
>
>                 pm_runtime_disable(dev);
>                 pm_runtime_set_suspended(dev);
> diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
> index ad52027a9cbf..ce101e4497d6 100644
> --- a/include/linux/amba/bus.h
> +++ b/include/linux/amba/bus.h
> @@ -32,6 +32,7 @@ struct amba_device {
>         struct clk              *pclk;
>         unsigned int            periphid;
>         unsigned int            irq[AMBA_NR_IRQS];
> +       unsigned int            irq_safe:1;
>  };
>
>  struct amba_driver {
> --
> 1.9.1
>

Kind regards
Uffe

  reply	other threads:[~2014-09-16 18:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16 12:59 [PATCH v5 0/4] amba/dma: pl330: add Power Management support Krzysztof Kozlowski
2014-09-16 12:59 ` [PATCH v5 1/4] PM / Runtime: Add getter for quering the IRQ safe option Krzysztof Kozlowski
2014-09-16 18:27   ` Ulf Hansson
2014-09-16 12:59 ` [PATCH v5 2/4] amba: Add helper macros for (un)preparing AMBA clock Krzysztof Kozlowski
2014-09-16 12:59 ` [PATCH v5 3/4] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM Krzysztof Kozlowski
2014-09-16 18:25   ` Ulf Hansson [this message]
2014-09-16 19:52     ` Russell King - ARM Linux
2014-09-17 17:59       ` Ulf Hansson
2014-09-16 12:59 ` [PATCH v5 4/4] dma: pl330: add Power Management support Krzysztof Kozlowski
2014-09-16 16:18 ` [PATCH v5 0/4] amba/dma: " Russell King - ARM Linux
2014-09-16 16:28   ` Krzysztof Kozlowski

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=CAPDyKFrNYxSx3KwOLg0Bgw2TCtsC2-1YXjo1kSms2ie_b8sNww@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=k.kozlowski@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=lars@metafoo.de \
    --cc=len.brown@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=michal.simek@xilinx.com \
    --cc=pavel@ucw.cz \
    --cc=rdunlap@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=stern@rowland.harvard.edu \
    --cc=vinod.koul@intel.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.