> > + 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.
>
> Regards,
>
> Tony
>
>
> > @@ -172,7 +171,7 @@ void __init usb_ehci_init(enum ehci_hcd_omap_mode
> phy_mode,
> >
> > /* Setup Pin IO MUX for EHCI */
> > if (cpu_is_omap34xx())
> > - setup_ehci_io_mux();
> > + setup_ehci_io_mux(phy_mode);
> >
> > if (platform_device_register(&ehci_device) < 0) {
> > printk(KERN_ERR "Unable to register HS-USB (EHCI) device\n");
> > --
> > 1.6.2.4
> >
> > --
> > 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
--
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
