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. > 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. > 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.) - Dave -- 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
