From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julius Werner Date: Thu, 18 Jul 2013 13:53:51 -0700 Subject: [U-Boot] [PATCH 0/7] USB: XHCI: Add xHCI host controller stack driver In-Reply-To: <51DD9269.4030106@ti.com> References: <1372769977-7182-1-git-send-email-gautam.vivek@samsung.com> <51D2F087.7050001@ti.com> <201307022327.00257.marex@denx.de> <51DD9269.4030106@ti.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.