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 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, 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