Felipe Balbi wrote: > On Wed, Jun 02, 2010 at 04:45:48PM +0200, ext Tony Lindgren wrote: > >Yeah having the modules do the platform device init and registration will > >lead into nasty conflicts. The platform device registration really needs > >to happen in the board-*.c files, not in the drivers. > > yeah, unless you had a way to register a particular platform_device > conditionaly based on the attached daughter card, but then again, if you > can detect the daughter card, you might as well use that information to > do the muxing correctly on the board-*.c file. > > I have to agree modules are not supposed to change platform stuff. On > the other hand, that could be used by EHCI/OHCI to implement port > handoff on runtime: > > mux all usb ports to ehci, if enumeration fails, remux ports to ohci > and try again. >
FWIW, this specific configuration is not supported on OMAP3s today. You cannot dynamically hand off from EHCI to OHCI - the issue being that we don't have a single PHY that can talk both interface languages on the exact same pads as the OMAP. One other case I can think of where you might want to change mux modes dynamically is as a workaround for an errata. For instance, you might want to mux a particular pad to safe-mode when entering off-mode and mux it back to a functional mode after exiting off-mode. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
