On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman <khilman@xxxxxx> wrote: > On 05/23/2012 05:01 PM, Kevin Hilman wrote: >> >> Hi Keshava, >> >> Using current l-o master, I noticed that CORE was not hitting retention >> in idle on my 3530/Overo. CORE hits retention on suspend just fine. >> >> Debugging this, I found that usbtll_fck was still enabled during idle, >> thus preventing CORE from hitting retention. >> >> To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and >> was then started seeing CORE hit retention in idle again. >> >> I have nothing plugged into the USB host port on this board, so I >> would've expected that runtime PM would've kicked in and shutdown this >> clock. >> >> Any ideas what's going on here? Is this expected behavior? >> > > If it helps, attached is a bootlog after enabling debug for > mfd/omap-usb-host.c as well. Notice there's a couple of clock-related > warnings from this driver as well. Not sure if they're relevant: > > usbhs_omap: alias fck already exists > usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 these clocks were specific to omap4 and it should not cause any problem to omap3 boards. I will try to reproduce this on 3430 sdp to explore further. > > With debug enabled, I see the runtime resume during init followed by the > runtime suspend. > > [ 0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed > error:-22 > [ 0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller > [ 0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume > [ 0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10 > [ 0.944641] usbhs_omap usbhs_omap: OMAP3 ES version > ES2.1 > [ 0.944671] usbhs_omap usbhs_omap: UHH setup done,ry > uhh_hostconfig=8000121d > [ 0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend > > However, later in the boot I see a runtime_resume and never see another > suspend. That seems to be the root cause of CORE not hitting retention. > > From the boot log: > > [ 2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [ 2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 > [ 2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator > [ 2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume > [ 3.030639] ehci-omap ehci-omap.0: phy reset operation timed out > [ 3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 > pcc=3 ordered ports=3 > [ 3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes > 256/512/1024 park > [ 3.030761] ehci-omap ehci-omap.0: reset command 0080b02 park=3 > ithresh=8 period=1024 Reset HALT > [ 3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller > > Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how > this driver is being runtime resumed. Presumably it's due to how the rest > of the USB stack works, which I'm not at all familiar with. > > Hopefully, the above is enough to debug the problem, > > Thanks, > > Kevin -- 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
