lkml.org 
[lkml]   [2011]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2011-10-11 03:21    [W:0.449 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site