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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
