This patch adds USB capabilities to libpayload. It requires some

memalign implementation (eg. the one I sent yesterday).
Features:
 - UHCI controller driver
 - UHCI root hub driver
 - USB MSC (Mass Storage Class) driver
 - skeleton of a USB HID driver
   (requires better interrupt transfer handling, which is TODO)
 - skeleton of a USB hub driver
   (needs several blank spots filled in, eg. power management.
    Again: TODO)

OHCI and EHCI are not supported, though OHCI support should be rather
easy as the stack provides reasonable abstractions (or so I hope). EHCI
will probably be more complicated.

Isochronous transfers (eg. webcams, audio stuff, ...) are not supported.
They can be, but I doubt we'll have a reason for that in the boot
environment.

The MSC driver was tested against a couple of USB flash drives, and
should be reasonably tolerant by now. But I probably underestimate
the amount of bugs present in USB flash drives, so feedback is welcome.

Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>


git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3560 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1

payloads/libpayload/drivers/usb/TODO

@@ -0,0 +1,22 @@
+- handle error conditions
+- handle disconnect more gracefully (ie. make calling layer aware that the device doesn't exist somehow)
+- usbhub:
+  - proper client enumeration (esp. detach)
+  - change detection
+  - power management
+- handle interrupts more cleverly:
+  create a new queue for the interrupt with a couple of TD sequences,
+    - each ending with "breadth first" flag
+    - linked as a chain
+  add that queue at the appropriate times in front of the default structure so the max latency is honored
+    - only one intr chain per framelist item, so it must be arranged appropriately
+  reads from usb device just look at "invalidated" tds and the results they got
+  handled tds get reactivated as a ring structure
+    - added as child of the oldest td
+    - queue header already dropped the td, so no issue there
+  
+  this setup ensures that:
+  - the max latency of the device is honored
+  - the client knows the right order of the data
+  - there is no need for an interrupt handler
+    - but must be polled at least max latency * num tds times -> more tds = less time pressure