| Message ID | 1348658647-25975-2-git-send-email-vipulkumar.samar@st.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar <vipulkumar.samar@st.com> wrote: > SPI functional clock must be disalble/enable in non RTPM suspend/resume > hooks. Currently it is only done for RTPM cases. > > This patch add support to disable/enbale clock for conventional > suspend/resume calls. > > Signed-off-by: Vipul Kumar Samar <vipulkumar.samar@st.com> Cross dependency between runtime suspend/resume and common suspend/resume. Oh the horror ... Ulf Hansson has experienced pain with this as well, let's discuss this a bit. > @@ -2310,6 +2310,8 @@ static int pl022_suspend(struct device *dev) > } > > dev_dbg(dev, "suspended\n"); > + clk_disable(pl022->clk); > + > return 0; > } > > @@ -2318,6 +2320,12 @@ static int pl022_resume(struct device *dev) > struct pl022 *pl022 = dev_get_drvdata(dev); > int ret; > > + ret = clk_enable(pl022->clk); > + if (ret) { > + dev_err(dev, "could not enable SSP/SPI bus clock\n"); > + return ret; > + } > + There is a potential race between the runtime suspend/resume and ordinary suspend/resume hooks here I'm afraid. I think in this case since we're not reading nor writing registers, we should just wait for the device to go down to runtime suspend in the ordinary suspend hook, just wait for runtime suspend to happen in suspend, do nothing in resume (and wait for the device to wake itself as needed). So something like: while (!pm_runtime_status_suspended(&dev)) cpu_relax(); // or usleep_range()? /* Here you know the block is gated off */ Or is this better: pm_runtime_get_sync(); /* Now we know for sure it's on! */ pm_runtime_put_sync(); /* Now we know for sure it's off! */ Is there a *good* way to await runtime suspend? I don't know if any of this is the proper solution so let Rafael and Magnus comment on how it's supposed to be done. Ramblings: The semantics between runtime suspend/resume and ordinary suspend/resume are unclear to me, it seems like this is all up to the drivers and busses to figure out. Like you weren't supposed to use both at the same time. What we've done in other drivers here at ST-Ericsson is to make the .suspend hook actually do a runtime get so that runtime PM is "running", then hammer off all resources and go to suspend with PM runtime actually enabled. Something like this: suspend() pm_runtime_get_sync() /* Maybe poke some registers here */ clk_disable(); resume(): clk_enable(); /* Maybe poke some registers here */ pm_runtime_put(); This is to be sure that there is not a race between runtime suspend/resume and ordinary suspend/resume. I don't like it since it actually turns things upside-down completely, during ordinary suspend the device is "runtime resumed" for example. Rafael, Magnus: help. Yours, Linus Walleij
On Wed, Sep 26, 2012 at 02:17:36PM +0200, Linus Walleij wrote: > On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar > > SPI functional clock must be disalble/enable in non RTPM suspend/resume > > hooks. Currently it is only done for RTPM cases. > > This patch add support to disable/enbale clock for conventional > > suspend/resume calls. > Cross dependency between runtime suspend/resume and > common suspend/resume. Oh the horror ... This should be fine, we runtime resume before we suspend. > The semantics between runtime suspend/resume and > ordinary suspend/resume are unclear to me, it seems like > this is all up to the drivers and busses to figure out. Like > you weren't supposed to use both at the same time. This was clarified at some point relatively recently with the above (which is essentially the same as the solution you describe).
On Wed, Sep 26, 2012 at 2:19 PM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Wed, Sep 26, 2012 at 02:17:36PM +0200, Linus Walleij wrote: >> On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar > >> > SPI functional clock must be disalble/enable in non RTPM suspend/resume >> > hooks. Currently it is only done for RTPM cases. > >> > This patch add support to disable/enbale clock for conventional >> > suspend/resume calls. > >> Cross dependency between runtime suspend/resume and >> common suspend/resume. Oh the horror ... > > This should be fine, we runtime resume before we suspend. (...) > This was clarified at some point relatively recently with the above > (which is essentially the same as the solution you describe). Oh. How come that whenever I poke my nose into this stuff I feel like a compleat n00b X-D Can you point me to the relevant posts/doc so I can read up on it, would be much appreciated! Yours, Linus Walleij
On Wed, Sep 26, 2012 at 5:49 PM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Wed, Sep 26, 2012 at 02:17:36PM +0200, Linus Walleij wrote: >> On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar > >> > SPI functional clock must be disalble/enable in non RTPM suspend/resume >> > hooks. Currently it is only done for RTPM cases. > >> > This patch add support to disable/enbale clock for conventional >> > suspend/resume calls. > >> Cross dependency between runtime suspend/resume and >> common suspend/resume. Oh the horror ... > > This should be fine, we runtime resume before we suspend. I believe Vipul sent this patch for the cases where RTPM in not enabled in the configs. -- viresh
On Wed, Sep 26, 2012 at 4:08 PM, viresh kumar <viresh.kumar@linaro.org> wrote: > On Wed, Sep 26, 2012 at 5:49 PM, Mark Brown > <broonie@opensource.wolfsonmicro.com> wrote: >> On Wed, Sep 26, 2012 at 02:17:36PM +0200, Linus Walleij wrote: >>> On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar >> >>> > SPI functional clock must be disalble/enable in non RTPM suspend/resume >>> > hooks. Currently it is only done for RTPM cases. >> >>> > This patch add support to disable/enbale clock for conventional >>> > suspend/resume calls. >> >>> Cross dependency between runtime suspend/resume and >>> common suspend/resume. Oh the horror ... >> >> This should be fine, we runtime resume before we suspend. > > I believe Vipul sent this patch for the cases where RTPM in not > enabled in the configs. OK so we need to handle the cases where either, both or just one of them is enabled... Mark says the defined semantics is that runtime PM is resumed across suspend/resume but I'd just like to understand the overall mechanism that makes sure this happens and I'm go... However there is another problem with the patch, because in -next there is also pin control handling in the runtime hooks, so we need to duplicate not only clocks but also that in each of the functions. Maybe we can first make a patch that breaks out resource handling so we can call that from each of the suspend/resume calls? (I'll try.) Yours, Linus Walleij
On Wed, Sep 26, 2012 at 02:41:56PM +0200, Linus Walleij wrote: > Can you point me to the relevant posts/doc so I can read up on > it, would be much appreciated! I can't remember anything specific off the top of my head, sorry.
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c index f2a80ff..09fb09e 100644 --- a/drivers/spi/spi-pl022.c +++ b/drivers/spi/spi-pl022.c @@ -2310,6 +2310,8 @@ static int pl022_suspend(struct device *dev) } dev_dbg(dev, "suspended\n"); + clk_disable(pl022->clk); + return 0; } @@ -2318,6 +2320,12 @@ static int pl022_resume(struct device *dev) struct pl022 *pl022 = dev_get_drvdata(dev); int ret; + ret = clk_enable(pl022->clk); + if (ret) { + dev_err(dev, "could not enable SSP/SPI bus clock\n"); + return ret; + } + /* Start the queue running */ ret = spi_master_resume(pl022->master); if (ret)
SPI functional clock must be disalble/enable in non RTPM suspend/resume hooks. Currently it is only done for RTPM cases. This patch add support to disable/enbale clock for conventional suspend/resume calls. Signed-off-by: Vipul Kumar Samar <vipulkumar.samar@st.com> --- drivers/spi/spi-pl022.c | 8 ++++++++ 1 file changed, 8 insertions(+)