Dear Lucas Stach, > Dear Marek Vasut, > > Am Dienstag, den 06.11.2012, 23:35 +0100 schrieb Marek Vasut: > > Dear Lucas Stach, > > > > [...] > > > > > > > > > What do you think? > > > > > > > > > > > > What about passing port private / platform data instead of ID ? > > > > > > > > > > The ID is already passed to ehci_hcd_init(), so we have to live > > > > > with it if we don't want to change the newly introduced > > > > > multi-controller infrastructure. > > > > > > > > Let's change it .... remove the ID and pass some generic pdata. > > > > > > I don't like the idea of passing around data at this level. It's > > > breaking the abstraction, as we have to pass low-level usb information > > > around in the higher USB stack levels. > > > > Good, what do you suggest we do when we apply driver model onto this > > stuff? > > Sadly I have not found the time to take a deeper look into the driver > model. But see below.
You might want to ... I suspect instead of passing ID, we should start passing some USB pdata. EHCI Pdata for ehci I guess ... > > > The USB driver code should be able to do the virt-to-phys controller > > > mapping on it's own. In the Tegra world > > > > Tegra is completely unimportant part of the usb ecosystem. > > I know that your views are centred around a different point, which is > fine with me, but please don't make the mistake to downplay the > importance of _any_ part of the ecosystem. On the contrary, I'm trying to avoid making the mistake of focusing on any SoC too much. > > > we use the information we get > > > from device tree to do so, but I don't see a reason why your USB host > > > driver code wouldn't be able to just require an array with > > > configuration data from the board file. > > > > 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. > In this case the ehci_hcd_init|stop entry points are only used to > init/stop one specific controller, which is completely different matter > from the driver being instantiated and as such should not carry any > platform data. IMHO all platform data should be contained in the boards > global data. I believe you should be passing pdata to the ehci_hcd_init ... they might contain some register frobbing etc., but this is probably the part where we missed each ones point. > Regards, > Lucas Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
