On śro, 2014-11-12 at 16:28 +0100, Ulf Hansson wrote:
> On 12 November 2014 15:32, Krzysztof Kozlowski <k.kozlow...@samsung.com>
> wrote:
> > Add system suspend/resume capabilities to the pl330 driver so the amba
> > bus clock could be also unprepared to conserve energy.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> > ---
> > drivers/dma/pl330.c | 37 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> > index c3bd3584f261..fd71777fc565 100644
> > --- a/drivers/dma/pl330.c
> > +++ b/drivers/dma/pl330.c
> > @@ -2627,6 +2627,42 @@ static int pl330_dma_device_slave_caps(struct
> > dma_chan *dchan,
> > return 0;
> > }
> >
> > +/*
> > + * Runtime PM callbacks are provided by amba/bus.c driver.
> > + *
> > + * It is assumed here that IRQ safe runtime PM is chosen in probe and amba
> > + * bus driver will only disable/enable the clock in runtime PM callbacks.
> > + */
> > +static int __maybe_unused pl330_suspend(struct device *dev)
> > +{
> > + struct amba_device *pcdev = to_amba_device(dev);
> > +
> > + if (!pm_runtime_status_suspended(dev)) {
>
> No, this wont work. Consider this scenario:
>
> pm_runtime_status_suspended() returns "true", which means you consider
> the device to be runtime PM suspended, thus you will unprepare the
> clock below.
>
> Later, a call to pm_runtime_get_sync() is invoked from "somewhere" and
> before this driver's system PM resume callback has been invoked. That
> will trigger the runtime PM resume callback to be invoked, causing
> clock unbalance issues.
If during system resume the device runtime resume is called BEFORE
normal resume of device, then you're right: clock will be unbalanced.
But such case does not make sense. pm_runtime_get_sync() is called when
someone wants to use the dmaengine/pl330... but the pl330 driver is
still suspended in that time!
If runtime resume is called AFTER normal resume of device - then it is
fine with my code.
> You need a pm_runtime_disable() prior checking the runtime PM status
> using pm_runtime_status_suspended(). That will prevent this from
> happen.
>
> I guess you may see where this is leading. I think
> pm_runtime_force_suspend|resume() is well suited for this situation.
I've been there... :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
