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

[Marek Vasut <marex@denx.de>]

Dear Lucas Stach,

> 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.

You might want to ... I suspect instead of passing ID, we should start passing 
some USB pdata. EHCI Pdata for ehci I guess ...

> > > 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.

On the contrary, I'm trying to avoid making the mistake of focusing on any SoC 
too much.

> > > 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.

Hm ... thinking about it, maybe you can do generic USB Pdata which would contain 
the controller # and additional pdata (like mmap address etc).

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

Good.

> 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.

Yes, but you don't pass such data through the driver (yet). You need to do that 
and that's what I asked you to do.

> 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.

I believe you should be passing pdata to the ehci_hcd_init ... they might 
contain some register frobbing etc., but this is probably the part where we 
missed each ones point.

> Regards,
> Lucas

Best regards,
Marek Vasut