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