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 <[email protected]>
---
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;
--
1.7.9.5
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 <[email protected]>
> ---
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 <[email protected]>
quite a few weeks back I sent a series enabling runtime pm for all glue
layers. I'll use that version instead, sorry.
--
balbi
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 <[email protected]>
>
> 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 <[email protected]>
> >
> > 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.
--
balbi
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 <[email protected]>
>>>
>>> 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 <[email protected]>
> >>>
> >>> 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
--
balbi
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 <[email protected]>
>>>>>
>>>>> 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.
--
balbi
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
--
balbi
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