>-----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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
