On Tue, 30 Oct 2012, Mohan V wrote: > >> >> ------------------------Device not getting detected when connected--------------------------- > >> >> > >> >> / # [ 135.621002] usbhs_wakeup: Enabling clocks > >> >> [ 135.625762] usbhs_runtime_resume:++++++ > >> >> [ 135.630371] usbhs_runtime_resume:------ > >> >> [ 135.638183] USB IO PAD Wakeup event triggered################## > >> >> [ 135.644958] usbhs_runtime_suspend:++++++ > >> >> [ 135.649749] usbhs_runtime_suspend:----- > >> > > >> > It appears that ohci_irq() didn't run. Did > >> > ohci_finish_controller_resume() get called? > >> > > >> This function is not used in ohci-omap3.c and is used only in ohci-omap.c. > >> Is it necessary to call this function? > > > > It is necessary if the driver supports suspend/resume. As far as I can > > tell, the ohci-omap3 driver does not have this support (at least, not > > in the 3.6 kernel) whereas the ohci-omap driver does. > > > > What driver produced the "usbhs_runtime_suspend" and > > "usbhs_runtime_resume" messages above? (No such messages are present > > in ohci-omap3.c.) Apparently that driver _does_ support > > suspend/resume. > > > This driver is USBHS core driver for OMAP EHCI and OHCI > (drivers/mfd/omap-usb-host.c) Okay. I don't understand why the usbhs_runtime_suspend routine ever got called. Since ohci-omap3 never allows the OHCI controller to be suspended, the parent platform device should never get suspended either. What do the various files in the /sys/devices/.../ohci-omap3.0/power directory show? What about the corresponding files in the power subdirectory of the parent device? 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
