Re: [Qemu-devel] qemu usb-linux.c vl.h hw/esp.c hw/lsi53c895a.c ...

[Paul Brook <paul@codesourcery.com>]

[following up to record the discussion on IRC]
On Saturday 12 August 2006 13:31, Fabrice Bellard wrote:
> About async USB, maybe some simplifications are possible. When you have
> a real USB controller, there is always a single current request and you
> don't neep to have provisions to handle several ones (of course more
> complicated host controllers could do that, but it is not useful to
> model it now). Moreover, the devices must reply to the request
> immediately so the request are asynchronous just because it takes a few
> uS to send the data, not because the device blocks (I am not sure it is
> clear for you).

Right. It depends which level of the USB spec you're looking at.

At the low level (frames) USB is a bus system. Each TD is send on the bus in 
turn, and the device responds immediately (with a NAK if it is not ready to 
handle the request).

However at a higher level (endpoints) USB Bulk (and Control) transfers can be 
considered to be concurrent packet streams. This is closer to the level at 
which the current async support was intended to work.
With OHCI this matches the interface presented by the host controller. With 
UHCI a bit of guesswork is needed to recover this from the low-level 
frame/queue structures.

Paul