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

[Marek Vasut <marex@denx.de>]

Dear Beno?t Th?baudeau,

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

Yes, let's try ehci_hcd_bind().

Best regards,
Marek Vasut