usb: gadget: dummy_hcd: complete stream support
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>
Fri, 13 Jan 2012 20:51:47 +0000 (21:51 +0100)
committerFelipe Balbi <balbi@ti.com>
Tue, 24 Jan 2012 09:39:49 +0000 (11:39 +0200)
commita54c979fed31b4230b2e63132f7167206e4e5d69
treead59e0421ad6388876268d82af8293616b14fc52
parent9645f7d3dab346a9d442dca1688740551b8c55f2
usb: gadget: dummy_hcd: complete stream support

dummy_hcd provides (alloc|free)_stream() callbacks but there are not
doing anything. The transfer side also lacks matching of streams. This
patch changes this and implements stream allocation / de-allocation
support and proper urb <=> req matching.
The UDC side exposes a limit of 16 streams. DWC3, the only USB3 UDC has
no limitations in this regard except that it _needs_ to know that
streams will be used at the ep_enable time. At the host side, there is
no real limit either: XHCI can allocate any number of streams as long as
it does not run out of memory. The UAS gadget currently requests 16
streams and the UAS host side fallbacks from the requested 256 down to
16 which is fine.
From the UASP point of view (the only specified user), the number of
used streams does not really matter. The only limitation is that the
host may not use a higher stream than the gadget requested and can deal
with.

The dummy stream support has been modelled after current UAS + XHCI +
DWC3 + UASP usage which helps me testing:
- the device announces that each ep supports 16 streams (even it could
  more than that).
- the device side looks into Companion descriptor at ep_enable time and
  enables them according to it.
- the host side tries to enable the requested number of streams but the
  upper limit is the Comanion descriptor. None (zero streams) is an
  error condition, less is okay.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
drivers/usb/gadget/dummy_hcd.c