[U-Boot] [PATCH 0/7] USB: XHCI: Add xHCI host controller stack driver

[Dan Murphy]

Julius
On 07/18/2013 03:53 PM, Julius Werner wrote:
> Hi Dan,
>
> I've just had a quick glance over the patches you referenced, so
> please let me know if I'm making wrong assumptions. Your approach
> seems to be to copy the relevant drivers (especially the whole XHCI
> stack) from Linux whole and then make as few modifications as possible
> to make them run under U-Boot. Is the code you posted actually
> functional in its current state, i.e. can you access USB devices
> through an XHCI controller?
>
> I think you would need to make major architectural changes to the
> driver stack to make it functional under U-Boot. Linux assumes an
> asynchronous, interrupt-driven event model where multiple USB
> transfers can be enqueued/completed in parallel. Without interrupts
> and kernel threads/completions, you will essentially have to rework
> the whole event handling to use some kind of polling mechanism and
> eventually get back to the single-fire, synchronous USB transfers that
> the U-Boot USB core stack expects. Your approach seems to be focused
> on changing as little as possible, but I fear that by the time you
> have a working solution you will have made so many changes that simply
> "syncing back up" to a new release of Linux will be very hard. You
> will also need to take the whole nightmare of cache invalidation into
> account which Linux easily side-steps through uncacheable memory
> mappings (and maintain correctness when you pull in new updates from
> it).
>
> Vivek has started out with the same Linux stack, but then cut away
> everything that wasn't essential to U-Boot's requirements, reducing
> code size and complexity to a more manageable chunk. I think in the
> long run it would be easier to have a smaller stack that we have to
> maintain ourselves than trying to keep a copy of Linux in sync that
> has still been so heavily modified that it takes a lot of effort to
> backport stuff. I have worked with Vivek's stack and can confirm that
> it's reasonably fast and functional... there are still a few buggy
> edge cases here and there, but at least USB storage and network
> booting works with all devices we tested.
>
> I don't know very much about the gadget side which you also seem to be
> tackling, but I wouldn't be surprised if you are going to have a hard
> time with the same issues there as well (interrupt/event model, data
> cache consistency). Abstracting out the DWC3 stuff and sharing it
> between Exynos/OMAP/... certainly sounds sensible, although I think
> that when you cut away all the non-U-Boot-relevant parts there may
> only be one or two dozen lines left to share.
>
> Just my two cents.
There is nothing you said that I will debate.

There are definite architectural issues in back porting the xHCI linux stack back to uBoot.
And we do have to consider the size of the code stack as well.

I would honestly like to see the dwc code broken out like the musb-new code was broken out.
As Vivek pointed out the DWC3 was done for exynos only so we should make that more general anyway.
We do have a working gadget implementation on the DWC but the patch set is not ready for prime time.

There is also some USB header problems that I tried to address in RFC
http://patchwork.ozlabs.org/patch/256451/

Feedback is always welcome on this as this has a direct impact on this code set.

What I will attempt to do is take my dwc patches and rebase Vivek's xhci code on top of that to see the issues.

Dan

-- 
------------------
Dan Murphy