[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41049fa81376d2973fa760cf061ee460@mail.gmail.com>
Date: Tue, 5 Jul 2011 19:30:26 +0530
From: Partha Basak <p-basak2@...com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Keshava Munegowda <keshava_mgowda@...com>,
linux-usb@...r.kernel.org, linux-omap@...r.kernel.org,
linux-kernel@...r.kernel.org, Felipe Balbi <balbi@...com>,
Anand Gadiyar <gadiyar@...com>, sameo@...ux.intel.com,
parthab@...ia.ti.com, tony@...mide.com,
Kevin Hilman <khilman@...com>,
Benoit Cousson <b-cousson@...com>, paul@...an.com,
johnstul@...ibm.com, Vishwanath Sripathy <vishwanath.bs@...com>
Subject: RE: [PATCH 6/6 v2] arm: omap: usb: global Suspend and resume support
of ehci and ohci
>-----Original Message-----
>From: linux-omap-owner@...r.kernel.org [mailto:linux-omap-
>owner@...r.kernel.org] On Behalf Of Alan Stern
>Sent: Monday, July 04, 2011 9:21 PM
>To: Partha Basak
>Cc: Keshava Munegowda; linux-usb@...r.kernel.org; linux-
>omap@...r.kernel.org; linux-kernel@...r.kernel.org; Felipe Balbi; Anand
>Gadiyar; sameo@...ux.intel.com; parthab@...ia.ti.com; tony@...mide.com;
>Kevin Hilman; Benoit Cousson; paul@...an.com; johnstul@...ibm.com;
>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@...r.kernel.org
>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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists