[U-Boot] [PATCH 8/8] config: smdk5420: Enable support for multiple XHCI controllers

[Marek Vasut]

On Tuesday, January 07, 2014 at 10:37:24 AM, Vivek Gautam wrote:

[...]

> > How I'd do this:
> > 1) Rename all these submit_*() functions to usb_submit_*()
> > 2) Rename all five usb_*() functions to ehci_*() resp. xhci_*()
> 
> This will happen in each controller drivers (ehci/xhci) which would
> eventually be
> called fro upper translation layer you mentioned below, right ?

Yes. Actually, thinking of this some more, to make the transition more fine-
grained, we might go about it like this even:

1) Rename all these submit_*() functions to usb_submit_*()
 -> This one stay the same, just rename them all so they're consistent.
2) Rename all five usb_*() functions to ehci_*() resp. xhci_*()
 -> In here, we should already have a fetus of the translation layer.
    My idea here would be to implement drivers/usb/host/usb_trans.c, which
    would implement all five usb_*() functions only as a wrappers. Each of
    the five function would contain #ifdef and call the respective xhci_*()
    or ehci_*() or [ou]hci_*() implementation depending on the configuration.
    This would preserve the current behavior, which would be nice.
3) Implement real translation layer
  -> Here, the usb_trans.c would need to be extended to track all the 
     controllers in a linked list. The usb core code would not change much,
     all of the logic would live in this usb_trans.c .
  -> Here, the usb_trans.c will no longer contain any of the ifdefs from
     step 2), but it will likely turn out you would need to have ifdefs to
     prevent triggering GCC complaint about missing definition of a functions.

I don't want to impose my ideas on you too hard, so please push back if you see 
some obvious flaws or have a much better idea!

> > 3) Implement translation layer, where the common code would still call
> > usb_*()
> > 
> >    and the layer would determine whether to call ehci_*() or xhci_*()
> >    call.
> > 
> > Surely, you'd need to change the probe() logic a bit, the controller
> > drivers would have to call some "usb_register_driver()" function for
> > each controller. This function would generate a new entry in a linked
> > list of all controllers registered and would add a flag whether this
> > controller is EHCI or XHCI.
> 
> Ok, i can understand this. Will try to put up code for this.

Thank you, this is much appreciated !

> > Effectively, this would even remove the need for
> > CONFIG_USB_MAX_CONTROLLER_COUNT at all, since you'd be tracking all the
> > USB controllers in the USB core code and in a linked list.
> 
> Yeah, right. We won't need the controller count in this case.

Yes, nonexistent preprocessor symbol is a good preprocessor symbol :)

> >> I had plans to add support to use controllers of different types (EHCI
> >> and XHCI etc) simultaneously.
> >> But haven't really put a code for that yet.
> >> Can you suggest some pointers about how would you like to see EHCI and
> >> XHCI or even OHCI work
> >> together :-)
> >> I can take up this.
> > 
> > Thank you, see above please. OHCI might be nastier, but should happen
> > along these lines above as well.
> 
> Ok, so first i will take up EHCI and XHCI then, and later 'll see the OHCI
> part.

Don't forget UHCI too. I think you will need to tackle all four at once, but it 
should be mostly manual work, nothing too frightening. I think your predecessors 
rectified the API nicely already :)

Best regards,
Marek Vasut