On 09/24/10 18:09, Gadiyar, Anand wrote: > On Fri, Sep 24, 2010 at 2:45 PM, Benoit Cousson <b-cousson@xxxxxx> wrote: >> omap_mux_read / omap_mux_write should not be accessed directly >> outside the mux framework. >> Do we really have use case that require dynamic mux change beside >> GPIO? >> > > Only case I can think of is for any workarounds for issues that turn up. > No such cases exist today on OMAP3 at least, and none are likely to > appear in future (I hope). So your assumption is valid. > We have a use-case here - granted the code currently is a complete hack and not something clean enough for the mainline kernel. We recently rediscovered the USB3320 PHY suspend issue that is in the errata on the OMAP35x platform (Advisory 3.1.1.193) and we came up with a workaround for it (despite the errata saying there isn't any) where essentially we do: 1) Allow the EHCI controller to suspend the PHY as normal 2) Cut the power to the USB host controller using power domains. This resets the logic states in the USB host controller so that it is usable again. 3) Remux all the pins talking to the PHY into GPIO mode 4) Monitor said pins for changes in status to know when a remote wakeup request occurs 5) Remux pins back to USB PHY mode 6) Reenable power to the USB host controller and reinitialize registers - Tim -- 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
