RE: [PATCH 6/6 v2] arm: omap: usb: global Suspend and resume supportof ehci and ohci

[Partha Basak]

>-----Original Message-----
>From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
>owner@xxxxxxxxxxxxxxx] On Behalf Of Alan Stern
>Sent: Monday, July 04, 2011 9:21 PM
>To: Partha Basak
>Cc: Keshava Munegowda; linux-usb@xxxxxxxxxxxxxxx; linux-
>omap@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Felipe Balbi; Anand
>Gadiyar; sameo@xxxxxxxxxxxxxxx; parthab@xxxxxxxxxxxx; tony@xxxxxxxxxxx;
>Kevin Hilman; Benoit Cousson; paul@xxxxxxxxx; johnstul@xxxxxxxxxx;
>Vishwanath Sripathy
>Subject: RE: [PATCH 6/6 v2] arm: omap: usb: global Suspend and resume
>support of ehci and ohci
>
>On Mon, 4 Jul 2011, Partha Basak wrote:
>
>> >I don't see any point in these routines (and likewise for
>> >omap_ohci_suspend/resume).  When the whole system is going to sleep
>> >anyway, what reason is there for enabling runtime PM on the parent
>> >device?
>>
>> Both for EHCI & OHCI, the clocks are owned by the parent (uhh-tll).
>>
>> Calling pm_runtime_put_sync(dev->parent) within omap_ehci_suspend
>> will turn-off the parent clocks in the Suspend path.
>>
>> Similarly, calling pm_runtime_get_sync(dev->parent) within
>> omap_ehci_resume
>> will turn-on the parent clocks in the resume path.
>>
>> This way, all reference counting are implicit within the Runtime PM
>layer
>> and takes care of all combinations of only EHCI insmoded, OHCI
>insmoded,
>> both insmoded etc.
>>
>> When both EHCI & OHCI are suspended, parent clocks will actually be
>> turned OFF and vice-versa.
>>
>> Note that the parent per-se does not have any .suspend & .resume
>hooked
>> up.
>
>Why not?  That sounds like a big bug.

This was a design decision since the parent needs to be activated only
when at-least one child is insmoded.

If the chidren are suspended, automatically the parent is suspended
via the pm_runtime_putsync calls to the parent.

So, effectively, we do not need an explicit suspend for the parent.
>
>> At the end of the _probe of parent, the clocks are turned OFF.
>> Subsequently, enabling
>> the parent clocks are entirely done implicitly by the children
>get_sync()
>> in their _probe.
>>
>> Therefore while .suspend/.resume of children are called they call back
>> into the parent to turn-off the clocks.
>
>You have ignored a few very important points:
>
>Firstly, system suspend is supposed to work even when runtime PM is not
>configured.
>
>Secondly, the user can disable runtime PM via sysfs at any time.  This
>shouldn't mess up system suspend.
>
>Basically, it's a bad idea to mix up system suspend with runtime PM.

Your observations are correct but this is a generic limitation and Kevin
is working
on this problem in parallel.

As of now, all OMAP drivers are mandated to use ONLY runtime pm framework
for enabling/disabling clocks. I will let Kevin comment further.

>
>Alan Stern
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@xxxxxxxxxxxxxxx
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/