| Message ID | 1391174426-13773-1-git-send-email-grygorii.strashko@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Friday 31 January 2014 08:20 AM, Grygorii Strashko wrote: > The Keystone PM management layer has been implemented using PM bus for > power management clocks. As result, most of Keystone drivers don't need > to manage clocks directly. They just need to enable runtime PM and use it > to handle their PM state and clocks. > > Hence, remove clock management code and switch to use runtime PM. > > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > --- Please capture why now it allowes us to remove the clock code. Commit 8a6720e {PM / clock_ops: fix up clk prepare/unprepare count} Without that information, the change log will be miss-leading > drivers/usb/dwc3/dwc3-keystone.c | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c > index 1fad161..a810b41 100644 > --- a/drivers/usb/dwc3/dwc3-keystone.c > +++ b/drivers/usb/dwc3/dwc3-keystone.c > @@ -23,6 +23,7 @@ > #include <linux/dma-mapping.h> > #include <linux/io.h> > #include <linux/of_platform.h> > +#include <linux/pm_runtime.h> > > /* USBSS register offsets */ > #define USBSS_REVISION 0x0000 > @@ -116,12 +117,10 @@ static int kdwc3_probe(struct platform_device *pdev) > kdwc3_dma_mask = dma_get_mask(dev); > dev->dma_mask = &kdwc3_dma_mask; > > - kdwc->clk = devm_clk_get(kdwc->dev, "usb"); > - > - error = clk_prepare_enable(kdwc->clk); > + pm_runtime_enable(dev); > + error = pm_runtime_get_sync(dev); > if (error < 0) { > - dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n", > - error); > + dev_dbg(dev, "unable to enable usb dev, err %d\n", error); > return error; > } > > @@ -152,7 +151,8 @@ static int kdwc3_probe(struct platform_device *pdev) > err_core: > kdwc3_disable_irqs(kdwc); > err_irq: > - clk_disable_unprepare(kdwc->clk); > + pm_runtime_put_sync(dev); > + pm_runtime_disable(dev); > > return error; > } > @@ -172,7 +172,8 @@ static int kdwc3_remove(struct platform_device *pdev) > > kdwc3_disable_irqs(kdwc); > device_for_each_child(&pdev->dev, NULL, kdwc3_remove_core); > - clk_disable_unprepare(kdwc->clk); > + pm_runtime_put_sync(&pdev->dev); > + pm_runtime_disable(&pdev->dev); > platform_set_drvdata(pdev, NULL); > > return 0; >
Hi, On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote: > The Keystone PM management layer has been implemented using PM bus for > power management clocks. As result, most of Keystone drivers don't need > to manage clocks directly. They just need to enable runtime PM and use it > to handle their PM state and clocks. > > Hence, remove clock management code and switch to use runtime PM. > > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> quite a few weeks back I sent a series enabling runtime pm for all glue layers. I'll use that version instead, sorry.
On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote: > Hi, > > On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote: >> The Keystone PM management layer has been implemented using PM bus for >> power management clocks. As result, most of Keystone drivers don't need >> to manage clocks directly. They just need to enable runtime PM and use it >> to handle their PM state and clocks. >> >> Hence, remove clock management code and switch to use runtime PM. >> >> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > > quite a few weeks back I sent a series enabling runtime pm for all glue > layers. I'll use that version instead, sorry. > That should be fine but you need to drop clk_*() related code from that patch. I assume you will send refresh version of it then. Regards, Santosh
On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote: > On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote: > > Hi, > > > > On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote: > >> The Keystone PM management layer has been implemented using PM bus for > >> power management clocks. As result, most of Keystone drivers don't need > >> to manage clocks directly. They just need to enable runtime PM and use it > >> to handle their PM state and clocks. > >> > >> Hence, remove clock management code and switch to use runtime PM. > >> > >> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > > > > quite a few weeks back I sent a series enabling runtime pm for all glue > > layers. I'll use that version instead, sorry. > > > That should be fine but you need to drop clk_*() related code > from that patch. I assume you will send refresh version of it then. why ? it makes no difference if you enable twice and disable twice.
On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote: > On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote: >> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote: >>> Hi, >>> >>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote: >>>> The Keystone PM management layer has been implemented using PM bus for >>>> power management clocks. As result, most of Keystone drivers don't need >>>> to manage clocks directly. They just need to enable runtime PM and use it >>>> to handle their PM state and clocks. >>>> >>>> Hence, remove clock management code and switch to use runtime PM. >>>> >>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >>> >>> quite a few weeks back I sent a series enabling runtime pm for all glue >>> layers. I'll use that version instead, sorry. >>> >> That should be fine but you need to drop clk_*() related code >> from that patch. I assume you will send refresh version of it then. > > why ? it makes no difference if you enable twice and disable twice. > Sure but why do you want to have the clock node handling code in drivers if it is not needed. Isn't that better ?
On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote: > On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote: > > On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote: > >> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote: > >>> Hi, > >>> > >>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote: > >>>> The Keystone PM management layer has been implemented using PM bus for > >>>> power management clocks. As result, most of Keystone drivers don't need > >>>> to manage clocks directly. They just need to enable runtime PM and use it > >>>> to handle their PM state and clocks. > >>>> > >>>> Hence, remove clock management code and switch to use runtime PM. > >>>> > >>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > >>> > >>> quite a few weeks back I sent a series enabling runtime pm for all glue > >>> layers. I'll use that version instead, sorry. > >>> > >> That should be fine but you need to drop clk_*() related code > >> from that patch. I assume you will send refresh version of it then. > > > > why ? it makes no difference if you enable twice and disable twice. > > > Sure but why do you want to have the clock node handling code in drivers > if it is not needed. Isn't that better ? It might, but then way that I wanted to see it is so that I can make assumptions about the device state. From a driver perspective, what I would love to see is the ability to assume that when my probe gets called the device is already enabled. So if you can make sure that clk_enable() happens before my probe and that you call pm_runtime_set_active() before my probe too, then I can more than hapilly remove clk_* calls from the driver ;-) either that or maintain the driver like so: probe() { ... clk_get(dev, "fck"); clk_prepare(clk); clk_enable(clk); pm_runtime_set_active(dev); pm_runtime_enable(dev); pm_runtime_get_sync(dev); ... } runtime_suspend() { clk_disable(dev); } runtime_resume() { clk_enable(dev); } note that because of pm_runtime_set_active() that first pm_runtime_get_sync() in probe() will simply increase the reference counter without calling my ->runtime_resume() callback, which is exactly what we want, as that would completely avoid situations of bad context being restored because of that initial pm_runtime_get_sync(). Then, we can even make pm_runtime completely async easily, because clk_prepare() was called only on probe() (or before it, for that matter). Bottomline is, if you can guarantee me that clk_get(), clk_prepare(), clk_enable() and pm_runtime_set_active() will be called properly before my probe, i'll be more than happy to comply with your request above as that will greatly simplify my driver. Just make, also, that if this clock is shared between dwc3-keystone wrapper and dwc3 core, you clk_get() on both driver's probe. cheers
On Friday 31 January 2014 11:45 AM, Felipe Balbi wrote: > On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote: >> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote: >>> On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote: >>>> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote: >>>>> Hi, >>>>> >>>>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote: >>>>>> The Keystone PM management layer has been implemented using PM bus for >>>>>> power management clocks. As result, most of Keystone drivers don't need >>>>>> to manage clocks directly. They just need to enable runtime PM and use it >>>>>> to handle their PM state and clocks. >>>>>> >>>>>> Hence, remove clock management code and switch to use runtime PM. >>>>>> >>>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >>>>> >>>>> quite a few weeks back I sent a series enabling runtime pm for all glue >>>>> layers. I'll use that version instead, sorry. >>>>> >>>> That should be fine but you need to drop clk_*() related code >>>> from that patch. I assume you will send refresh version of it then. >>> >>> why ? it makes no difference if you enable twice and disable twice. >>> >> Sure but why do you want to have the clock node handling code in drivers >> if it is not needed. Isn't that better ? > > It might, but then way that I wanted to see it is so that I can make > assumptions about the device state. From a driver perspective, what I > would love to see is the ability to assume that when my probe gets > called the device is already enabled. So if you can make sure that > clk_enable() happens before my probe and that you call > pm_runtime_set_active() before my probe too, then I can more than > hapilly remove clk_* calls from the driver ;-) > > either that or maintain the driver like so: > > probe() > { > ... > > clk_get(dev, "fck"); > clk_prepare(clk); > clk_enable(clk); > pm_runtime_set_active(dev); > pm_runtime_enable(dev); > pm_runtime_get_sync(dev); > ... > } > > runtime_suspend() > { > clk_disable(dev); > } > > runtime_resume() > { > clk_enable(dev); > } > > note that because of pm_runtime_set_active() that first > pm_runtime_get_sync() in probe() will simply increase the reference > counter without calling my ->runtime_resume() callback, which is exactly > what we want, as that would completely avoid situations of bad context > being restored because of that initial pm_runtime_get_sync(). > Thanks for making your point bit clear. > Then, we can even make pm_runtime completely async easily, because > clk_prepare() was called only on probe() (or before it, for that > matter). > > Bottomline is, if you can guarantee me that clk_get(), clk_prepare(), > clk_enable() and pm_runtime_set_active() will be called properly before > my probe, i'll be more than happy to comply with your request above as > that will greatly simplify my driver. > Which is the case at least I see on Keystone. And hence the patch from Grygorii works. I also noticed your proposal for wider platform to enforce above behavior which seems to be a good idea. > Just make, also, that if this clock is shared between dwc3-keystone > wrapper and dwc3 core, you clk_get() on both driver's probe. > I understand. In summary, whichever patch you pick(yours) or Grygorii's, its completely safe to remove the clock handling from Keystone USB driver. Regards, Santosh
On Fri, 31 Jan 2014, Felipe Balbi wrote: > probe() > { > ... > > clk_get(dev, "fck"); > clk_prepare(clk); > clk_enable(clk); > pm_runtime_set_active(dev); > pm_runtime_enable(dev); > pm_runtime_get_sync(dev); > ... > } > note that because of pm_runtime_set_active() that first > pm_runtime_get_sync() in probe() will simply increase the reference > counter without calling my ->runtime_resume() callback, which is exactly > what we want, as that would completely avoid situations of bad context > being restored because of that initial pm_runtime_get_sync(). Very minor note... A slightly better way to do the same thing is: pm_runtime_set_active(dev); pm_runtime_get_noresume(dev); pm_runtime_enable(dev); The get_noresume says that you want to increment the usage counter without performing any callbacks, and doing it before the pm_runtime_enable avoids any window during which a runtime suspend might somehow occur. Alan Stern
On Fri, Jan 31, 2014 at 04:13:19PM -0500, Alan Stern wrote: > On Fri, 31 Jan 2014, Felipe Balbi wrote: > > > probe() > > { > > ... > > > > clk_get(dev, "fck"); > > clk_prepare(clk); > > clk_enable(clk); > > pm_runtime_set_active(dev); > > pm_runtime_enable(dev); > > pm_runtime_get_sync(dev); > > ... > > } > > > note that because of pm_runtime_set_active() that first > > pm_runtime_get_sync() in probe() will simply increase the reference > > counter without calling my ->runtime_resume() callback, which is exactly > > what we want, as that would completely avoid situations of bad context > > being restored because of that initial pm_runtime_get_sync(). > > Very minor note... A slightly better way to do the same thing is: > > pm_runtime_set_active(dev); > pm_runtime_get_noresume(dev); > pm_runtime_enable(dev); > > The get_noresume says that you want to increment the usage counter > without performing any callbacks, and doing it before the > pm_runtime_enable avoids any window during which a runtime suspend > might somehow occur. aha, that's perfect :-) Thanks Alan.
Hi, On Fri, Jan 31, 2014 at 02:20:48PM -0500, Santosh Shilimkar wrote: [ snip ] > > note that because of pm_runtime_set_active() that first > > pm_runtime_get_sync() in probe() will simply increase the reference > > counter without calling my ->runtime_resume() callback, which is exactly > > what we want, as that would completely avoid situations of bad context > > being restored because of that initial pm_runtime_get_sync(). > > > Thanks for making your point bit clear. no problem. > > Then, we can even make pm_runtime completely async easily, because > > clk_prepare() was called only on probe() (or before it, for that > > matter). > > > > Bottomline is, if you can guarantee me that clk_get(), clk_prepare(), > > clk_enable() and pm_runtime_set_active() will be called properly before > > my probe, i'll be more than happy to comply with your request above as > > that will greatly simplify my driver. > > > Which is the case at least I see on Keystone. And hence the patch from I was going over pm_domain.c and drivers/base/power/clock_ops.c and none of them enable pm_runtime or make sure pm_runtime_set_active() is called. > Grygorii works. I also noticed your proposal for wider platform to > enforce above behavior which seems to be a good idea. it'll take months to stabilize though ;-) > > Just make, also, that if this clock is shared between dwc3-keystone > > wrapper and dwc3 core, you clk_get() on both driver's probe. > > > I understand. In summary, whichever patch you pick(yours) or Grygorii's, > its completely safe to remove the clock handling from Keystone USB driver. alright, since I can't really test, I'll take this as a true statement. If there are any regressions I can blame you, hehehe. cheers
On Friday 31 January 2014 05:15 PM, Felipe Balbi wrote: > Hi, > > On Fri, Jan 31, 2014 at 02:20:48PM -0500, Santosh Shilimkar wrote: > > [ snip ] > >>> note that because of pm_runtime_set_active() that first >>> pm_runtime_get_sync() in probe() will simply increase the reference >>> counter without calling my ->runtime_resume() callback, which is exactly >>> what we want, as that would completely avoid situations of bad context >>> being restored because of that initial pm_runtime_get_sync(). >>> >> Thanks for making your point bit clear. > > no problem. > >>> Then, we can even make pm_runtime completely async easily, because >>> clk_prepare() was called only on probe() (or before it, for that >>> matter). >>> >>> Bottomline is, if you can guarantee me that clk_get(), clk_prepare(), >>> clk_enable() and pm_runtime_set_active() will be called properly before >>> my probe, i'll be more than happy to comply with your request above as >>> that will greatly simplify my driver. >>> >> Which is the case at least I see on Keystone. And hence the patch from > > I was going over pm_domain.c and drivers/base/power/clock_ops.c and none > of them enable pm_runtime or make sure pm_runtime_set_active() is > called. > >> Grygorii works. I also noticed your proposal for wider platform to >> enforce above behavior which seems to be a good idea. > > it'll take months to stabilize though ;-) > >>> Just make, also, that if this clock is shared between dwc3-keystone >>> wrapper and dwc3 core, you clk_get() on both driver's probe. >>> >> I understand. In summary, whichever patch you pick(yours) or Grygorii's, >> its completely safe to remove the clock handling from Keystone USB driver. > > alright, since I can't really test, I'll take this as a true statement. > If there are any regressions I can blame you, hehehe. > No problem... :D Grygorii patch has been working well so all good with that
diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c index 1fad161..a810b41 100644 --- a/drivers/usb/dwc3/dwc3-keystone.c +++ b/drivers/usb/dwc3/dwc3-keystone.c @@ -23,6 +23,7 @@ #include <linux/dma-mapping.h> #include <linux/io.h> #include <linux/of_platform.h> +#include <linux/pm_runtime.h> /* USBSS register offsets */ #define USBSS_REVISION 0x0000 @@ -116,12 +117,10 @@ static int kdwc3_probe(struct platform_device *pdev) kdwc3_dma_mask = dma_get_mask(dev); dev->dma_mask = &kdwc3_dma_mask; - kdwc->clk = devm_clk_get(kdwc->dev, "usb"); - - error = clk_prepare_enable(kdwc->clk); + pm_runtime_enable(dev); + error = pm_runtime_get_sync(dev); if (error < 0) { - dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n", - error); + dev_dbg(dev, "unable to enable usb dev, err %d\n", error); return error; } @@ -152,7 +151,8 @@ static int kdwc3_probe(struct platform_device *pdev) err_core: kdwc3_disable_irqs(kdwc); err_irq: - clk_disable_unprepare(kdwc->clk); + pm_runtime_put_sync(dev); + pm_runtime_disable(dev); return error; } @@ -172,7 +172,8 @@ static int kdwc3_remove(struct platform_device *pdev) kdwc3_disable_irqs(kdwc); device_for_each_child(&pdev->dev, NULL, kdwc3_remove_core); - clk_disable_unprepare(kdwc->clk); + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); platform_set_drvdata(pdev, NULL); return 0;
The Keystone PM management layer has been implemented using PM bus for power management clocks. As result, most of Keystone drivers don't need to manage clocks directly. They just need to enable runtime PM and use it to handle their PM state and clocks. Hence, remove clock management code and switch to use runtime PM. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> --- drivers/usb/dwc3/dwc3-keystone.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)