* Re: [PATCH] usb: dwc3: keystone: switch to use runtime pm
@ 2014-01-31 16:45 ` Felipe Balbi
0 siblings, 0 replies; 24+ messages in thread
From: Felipe Balbi @ 2014-01-31 16:45 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: balbi, Grygorii Strashko, Greg Kroah-Hartman, ivan.khoronzhuk,
linux-usb, linux-arm-kernel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]
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
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH] usb: dwc3: keystone: switch to use runtime pm
2014-01-31 16:45 ` Felipe Balbi
@ 2014-01-31 19:20 ` Santosh Shilimkar
-1 siblings, 0 replies; 24+ messages in thread
From: Santosh Shilimkar @ 2014-01-31 19:20 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] usb: dwc3: keystone: switch to use runtime pm
@ 2014-01-31 19:20 ` Santosh Shilimkar
0 siblings, 0 replies; 24+ messages in thread
From: Santosh Shilimkar @ 2014-01-31 19:20 UTC (permalink / raw)
To: balbi
Cc: Grygorii Strashko, Greg Kroah-Hartman, ivan.khoronzhuk, linux-usb,
linux-arm-kernel, linux-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH] usb: dwc3: keystone: switch to use runtime pm
2014-01-31 19:20 ` Santosh Shilimkar
@ 2014-01-31 22:15 ` Felipe Balbi
-1 siblings, 0 replies; 24+ messages in thread
From: Felipe Balbi @ 2014-01-31 22:15 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/8ff6eefd/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] usb: dwc3: keystone: switch to use runtime pm
@ 2014-01-31 22:15 ` Felipe Balbi
0 siblings, 0 replies; 24+ messages in thread
From: Felipe Balbi @ 2014-01-31 22:15 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: balbi, Grygorii Strashko, Greg Kroah-Hartman, ivan.khoronzhuk,
linux-usb, linux-arm-kernel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
2014-01-31 22:15 ` Felipe Balbi
@ 2014-01-31 23:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 24+ messages in thread
From: Santosh Shilimkar @ 2014-01-31 23:04 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] usb: dwc3: keystone: switch to use runtime pm
@ 2014-01-31 23:04 ` Santosh Shilimkar
0 siblings, 0 replies; 24+ messages in thread
From: Santosh Shilimkar @ 2014-01-31 23:04 UTC (permalink / raw)
To: balbi
Cc: Grygorii Strashko, Greg Kroah-Hartman, ivan.khoronzhuk, linux-usb,
linux-arm-kernel, linux-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
2014-01-31 16:45 ` Felipe Balbi
@ 2014-01-31 21:13 ` Alan Stern
-1 siblings, 0 replies; 24+ messages in thread
From: Alan Stern @ 2014-01-31 21:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] usb: dwc3: keystone: switch to use runtime pm
@ 2014-01-31 21:13 ` Alan Stern
0 siblings, 0 replies; 24+ messages in thread
From: Alan Stern @ 2014-01-31 21:13 UTC (permalink / raw)
To: Felipe Balbi
Cc: Santosh Shilimkar, Grygorii Strashko, Greg Kroah-Hartman,
ivan.khoronzhuk, linux-usb, linux-arm-kernel, linux-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH] usb: dwc3: keystone: switch to use runtime pm
2014-01-31 21:13 ` Alan Stern
@ 2014-01-31 22:11 ` Felipe Balbi
-1 siblings, 0 replies; 24+ messages in thread
From: Felipe Balbi @ 2014-01-31 22:11 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/f29ba556/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] usb: dwc3: keystone: switch to use runtime pm
@ 2014-01-31 22:11 ` Felipe Balbi
0 siblings, 0 replies; 24+ messages in thread
From: Felipe Balbi @ 2014-01-31 22:11 UTC (permalink / raw)
To: Alan Stern
Cc: Felipe Balbi, Santosh Shilimkar, Grygorii Strashko,
Greg Kroah-Hartman, ivan.khoronzhuk, linux-usb, linux-arm-kernel,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread