Age | Commit message (Collapse) | Author |
|
This patch updates the libpayload XHCI stack to run on ARM CPUs (tested
with the DWC3 controller on an Exynos5420). Firstly, it adds support for
64-byte Slot/Endpoint Context sizes. Since the existing context handling
code represented the whole device context as a C struct (whose size has
to be known at compile time), it was necessary to refactor the input and
device context structures to consist of pointers to the actual contexts
instead.
Secondly, it moves all data structures that the xHC accesses through DMA
to cache-coherent memory. With a similar rationale as in the ARM patches
for EHCI, using explicit cache maintenance functions to correctly handle
the actual transfer buffers in all cases is presumably impossible.
Instead this patch also chooses to create a DMA bounce buffer in the
XHCI stack where transfer buffers which are not already cache-coherent
will be copied to/from.
Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169453
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6643
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The USB bulk and control transfer functions in libpayload currently
always return 0 for success and 1 for all errors. This is sufficient for
current use cases (essentially just mass storage), but other classes
(like certain Ethernet adapters) need to be able to tell if a transfer
reached the intended amount of bytes, or if it fell short.
This patch slightly changes that USB API to return -1 on errors, and the
amount of transferred bytes on successes. All drivers in the current
libpayload mainline are modified to conform to the new error detection
model. Any third party users of this API will need to adapt their
if (...<controller>->bulk/control(...)) checks to
if (...<controller>->bulk/control(...) < 0) as well.
The host controller drivers for OHCI and EHCI correctly implement the
new behavior. UHCI and the XHCI stub just comply with the new API by
returning 0 or -1, but do not actually count the returned bytes.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48308
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Updated the patch to support XHCI as well.
Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6
(cherry picked from commit e39e2d84762a3804653d950a228ed2269c651458)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6390
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Well, it turned out to be more as some gaps ;)
but we finally have xHCI running. It's well tested against a QM77 Ivy
Bridge board.
We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not
advertised and USB 3 devices will just work at HighSpeed.
There are still some bit fields in xhci_private.h, so this might need
little more work to run on ARM.
Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3452
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|