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

[Lucas Stach]

Dear Marek Vasut,

Am Mittwoch, den 07.11.2012, 14:25 +0100 schrieb Marek Vasut:
> Dear Lucas Stach,
> 
> > Dear Marek Vasut,
> > 
> > Am Dienstag, den 06.11.2012, 23:35 +0100 schrieb Marek Vasut:
> > > 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.
> 
We do pass this data to the driver in the form of gd->fdt_blob. This
data is driver (not controller) specific, so why would you pass this in
at ehci_hcd_init time?

But while writing this I think I now see why we miss each others point:
the Tegra EHCI driver is only instantiated once and used for all
controllers. This probably has to be reworked for the driver model.

Now I would still argue that we should keep the two step init model,
first we instantiate the driver with some form of pdata (we can
certainly come up with a one-struct-fits-all for this) and later when we
are really going to use one specific controller we do the real hardware
init.

Now we seem to differ about the meaning of the usb stack functions. From
your mails I see that you want ehci_hcd_init as the first init step
where we instantiate the driver (and therefore need the pdata), where I
treated it as the second step, because currently it is the point where
the upper USB stack levels indicate that they are going to use a
specific controller.

We should probably come up with some consensus about this before going
forward. Sadly my free time is really limited right now, so it's hard
for me to keep up even with things I planned to do in the next few
weeks, not to speak about playing around with the driver model.

Regards,
Lucas