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

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

Dear Marek Vasut,

On Wednesday, November 7, 2012 3:13:51 PM, Marek Vasut wrote:
> Dear Lucas Stach,
> 
> > Dear Marek Vasut,
> > 
> > Am Mittwoch, den 07.11.2012, 14:25 +0100 schrieb Marek Vasut:
> > 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.

Not only for controller bugs, but also for related board operations through
board_ehci_hcd_init(), or simply to perform a clean new init following a stop
(e.g. in the case of the "usb reset" command).

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

If I understand correctly what you said, ehci_hcd_init() can be left unchanged
because you don't care about what it does, so it will keep using the USB
controller index from the command line. And we should add some
"int ehci_hcd_bind(void *pdata)" that would be called by the board init files to
perform the driver instantiation.

Until the driver model is applied, this instantiation would be an empty
operation except for the drivers like ehci-mxc.c that need some platform data.
Hence, for now, this ehci_hcd_bind() function would have to be implemented only
for such drivers, which would be a small change that can be done step by step.

Correct me if I'm wrong above. My goal here is only to find a quick and simple
solution to take advantage of the multi-controller feature on MXC. I don't have
enough time to rework the whole infrastructure, so if this goal is incompatible
with the current infrastructure and how you want to make it evolve, I'll come
back when the infrastructure allows to truly use this feature.

Best regards,
Beno?t