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