Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structuresfor omap4

[Paul Walmsley]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/