> From: David Brownell [david-b@xxxxxxxxxxx] > On Friday 12 September 2008, Gadiyar, Anand wrote: > > 1. TLL vs PHY mode needs to be set somewhere. Me thinks this information ought > > to come from board-specific data and the driver would need to set things up > > accordingly. What would be a good way to do this? > > Define an ehci_omap_platform_data struct and use it for > the stuff that shouldn't be in mach-omap2 ... I seem to > not understand why there would be a question here. Lack of experience. I'm got miles to go... > > > 2. The OHCI driver (not yet in linux-omap and not in a shape to go ought at the > > moment either) would need to touch a lot of common registers during init/exit/re-init. > > Any ideas where to put this code such that we can have the EHCI driver, or the > > OHCI driver, or both loaded and unloaded at will and still working without interfering > > with each other. > > Sounds like code that can live in mach-omap2 and be called > when the drivers start or stop. Yup. Then a lot of the code in that ehci-omap.c file would need to be moved there to avoid duplicating code. Will do that when I add the OHCI bus-glue. > > 3. For OHCI, the transceiver used on the expansion board happens to be an ISP1301 > > for which there currently exists a driver (drivers/i2c/chips/isp1301_omap.c). Since this is > > meant to be an OTG transceiver, the driver does otg_set_transceiver. > > And does OMAP2 have the OMAP1 OTG controller? If not, then > you can't use that driver. > > > > But MUSB is the OTG controller and has it's own transceiver... and we can't have two of > > those, right? :) Ideas welcome. > > You'll need a new driver; since it's host only, it would only > need to be a little stub. The interface shouldn't matter much; > just make it general enough that other hardware could use it. > (Nothing OMAP-specific, etc.) > Okay. Will do. I'll fix the OHCI code too and send it in, but it'll take a while. Thanks for the advice. - 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
