Hi On Mon, 10 Oct 2011, Paul Walmsley wrote: > Basically, the existing OMAP USB subsystem MFD driver should create a TLL > device. Then the existing Linux driver probing system can associate the > TLL driver with the TLL device. This part isn't right. After staring at the OMAP34xx TRM, it looks like the TLL modules have a separate interconnect port. See for example the OMAP34xx TRM Rev. ZR Table 2-3 "L4-Core Memory Space Mapping". So then the TLL device should be created by the code in arch/arm/mach-omap2/usb-host.c, as one of Keshava's patches does. And indeed we have separate hwmods for the TLL IP blocks -- although both the OMAP3 and OMAP4 hwmod data that was posted are missing important fields. So drivers/omap-usb-host.c shouldn't create a new TLL device. You just need to pull all of the TLL code and data out of that MFD driver into a new TLL driver under drivers/usb somewhere. Then you'll need some way for the EHCI/OHCI code to figure out which USBTLL device handles each port. I'd suggest that, unless there is some explicit Linux USB core support for associating a TLL port with a host controller port, that the code in arch/arm/mach-omap2/usb-host.c register the USBTLL device first (the opposite of what it does now), then pass the pointer to the USBTLL's struct device via platform_data to drivers/mfd/omap-usb-host.c. Then that can either be passed via platform_data to the EHCI/OHCI drivers, or the EHCI/OHCI drivers can call a drivers/mfd/omap-usb-host.c function to retrieve that struct device pointer. - Paul -- 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
