[U-Boot] usb: ehci: Take advantage of the new multi-controller feature for MXC
Marek Vasut
marex at denx.de
Wed Nov 7 14:25:22 CET 2012
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
More information about the U-Boot
mailing list