[U-Boot] usb: ehci: Take advantage of the new multi-controller feature for MXC

[Lucas Stach <dev@lynxeye.de>]

Dear Marek Vasut,

Am Dienstag, den 06.11.2012, 23:35 +0100 schrieb Marek Vasut:
> Dear Lucas Stach,
> 
> [...]
> 
> > > > > > What do you think?
> > > > > 
> > > > > What about passing port private / platform data instead of ID ?
> > > > 
> > > > The ID is already passed to ehci_hcd_init(), so we have to live with it
> > > > if we don't want to change the newly introduced multi-controller
> > > > infrastructure.
> > > 
> > > Let's change it .... remove the ID and pass some generic pdata.
> > 
> > I don't like the idea of passing around data at this level. It's
> > breaking the abstraction, as we have to pass low-level usb information
> > around in the higher USB stack levels.
> 
> Good, what do you suggest we do when we apply driver model onto this stuff?
> 
Sadly I have not found the time to take a deeper look into the driver
model. But see below.

> > The USB driver code should be able to do the virt-to-phys controller
> > mapping on it's own. In the Tegra world
> 
> Tegra is completely unimportant part of the usb ecosystem.
> 
I know that your views are centred around a different point, which is
fine with me, but please don't make the mistake to downplay the
importance of _any_ part of the ecosystem.

> > we use the information we get
> > from device tree to do so, but I don't see a reason why your USB host
> > driver code wouldn't be able to just require an array with configuration
> > data from the board file.
> 
> I don't see how you transfer DT information into controller # ...
> 
> > There is really no need to pass this information through all the USB
> > stack interfaces.
> 
> Please explain.

Tegra has a two step initialisation:

1. Init the driver at board_init time
This is the step where we parse all the DT information and     fill in
all needed driver internal structures. At this point we do the virt to
phys controller ID mapping.

2. For every controller that U-Boot really uses we activate host mode
and do the real hardware initialisation at ehci_hcd_init time.

If I'm not completely mistaken such a model should align nicely with the
upcoming driver model. The driver gets instantiated with information it
gathers from global platform data, may it be device tree or any other
form of driver related information.

In this case the ehci_hcd_init|stop entry points are only used to
init/stop one specific controller, which is completely different matter
from the driver being instantiated and as such should not carry any
platform data. IMHO all platform data should be contained in the boards
global data.

Regards,
Lucas