-----Original Message----- > From: Gadiyar, Anand > Sent: Thursday, August 06, 2009 7:32 PM > To: Gupta, Ajay Kumar; Tony Lindgren > Cc: [email protected]; [email protected]; david- > [email protected] > Subject: RE: [PATCH 1/9] ehci: fix ehci pin mux init > > > > > + omap_cfg_reg(W5_3430_USB3HS_TLL_DATA3); > > > > + omap_cfg_reg(AB12_3430_USB3HS_TLL_DATA4); > > > > + omap_cfg_reg(AB13_3430_USB3HS_TLL_DATA5); > > > > + omap_cfg_reg(AA13_3430_USB3HS_TLL_DATA6); > > > > + omap_cfg_reg(AA12_3430_USB3HS_TLL_DATA7); > > > > + } > > > > > > > > return; > > > > } > > > > > > Hmm, is this safe to do? Or does it remember on the number of data > lines > > > that the transceiver uses? If so, maybe something like the recent mmc > > > muxing could be done where the number of pins is passed from > > > platform_data. > > > > This is actually done in "PATCH[6/9] ehci: portwise > > configurations" where number of ports is being passed from > > platform files and muxing is done only for required lines. > > > > > > > > This is assuming that the data lines do not have alternative pins.. In > > > that case only the common pins can be muxed and the rest > > would have to be > muxed in the board-*.c files. > > > > These are common pins for HS USB ports 1/2/3 but muxing board > > specific pins such as PHY RESET is getting done in board-*.c > > files only. > > > > > > > At the very least, some pins of HSUSB2 are muxed with MMC and MCSPI2. > > So users of those could possibly see something stop working.
In such scenarios where MMC or MCSPI2 is used then board-*.c file would not report those conflicting ports to be in use and so they wouldn't get muxed for EHCI. -Ajay > > - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
