Messages in this thread | | | Date | Mon, 10 Oct 2011 19:18:42 -0600 (MDT) | From | Paul Walmsley <> | Subject | Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4 |
| |
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
| |