Hi On Fri, 23 Sep 2011, Munegowda, Keshava wrote: > Paul Walmsley <paul@xxxxxxxxx> wrote: > > > So I'd suggest one of two approaches: > > > > 1. If the pin muxing can follow the PM runtime status of the UHH IP block, > > then the pin mux data should be associated with the UHH hwmod. > > No, the mux is applicable only to ehci and ohci , where as sysconfig is > applicable to uhh ( usb_host_hs class). My point is that, as far as I can tell, I/O pad wakeup (caused by USB remote wakeup) is only going to matter when the entire UHH IP block has its clocks cut. Otherwise, while the UHH is clocked, the EHCI and/or OHCI IP blocks will also be clocked, so no I/O pad wakeup will be needed. Do you agree? > > 2. If the pin muxing must follow the EHCI/OHCI IP block PM runtime status, > > then drivers/mfd/omap-usb-host.c is what should be handling the > > remuxing. omap-usb-host.c can set the dev_pm_ops of the EHCI/OHCI > > platform_devices to point to functions either in > > arch/arm/mach-omap2/usb-host.c, or local functions that call into > > mach-omap2/usb-host.c functions to handle pin remuxing. (Those > > function pointers should be provided to the MFD driver in some clean way, > > like via platform_data.) > > The dev_pm_ops of ehci should exist in /drivers/usb/host/ehci-omap.c and > dev_pm_ops of phci should exist in /drivers/usb/host/ohci-omap3.c. In > the existing design, the omap-usb-host.c host can not access the > platform driver of ehci and ohci. But, through function pointers it is > possible to send the platform data to ehci and ohci drivers to handle > pin remuxing; but we will not able to use tero's patches; and it will > prevent our future design activity for remote wakeup of ehci and ohci. Could you please explain in more detail why the dynamic remuxing can't be done when the UHH enters or exits idle? - Paul
