> > > + 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. - Anand -- 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
