Thread (11 messages) 11 messages, 3 authors, 2014-09-17

Re: [PATCH v5 3/4] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM

From: Ulf Hansson <hidden>
Date: 2014-09-16 18:25:28
Also in: lkml

On 16 September 2014 14:59, Krzysztof Kozlowski [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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 <redacted>
---
 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?
quoted hunk ↗ jump to hunk
+               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.
quoted hunk ↗ jump to hunk
                        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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help