[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 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?

Sorry, I don't understand you.

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

What do you mean "instantiated once"? There ALWAYS has to be only a single 
instance per one controller.

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

No, I don't care what you do in your ehci_hcd_init. And I don't care if you 
instantiate it there. But I suspect I understand your problem. I suspect the 
driver shall be instantiated from elsewhere and ehci_hcd_init() call shall only 
be used to fine-tune (or work around) controller bugs.

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

You're actually free to not work on that. Concensus is, I think the multi-
controller thing is misdesigned and we rather fix it sooner than later.

See my comment above about how I'd like to see it.

> Regards,
> Lucas

Best regards,
Marek Vasut