On 11/16/12 12:24, Jan Kiszka wrote: > On 2012-11-16 11:25, Gerd Hoffmann wrote: >> On 11/15/12 16:40, Jan Kiszka wrote: >>> Hi Hans, >>> >>> On 2012-11-15 16:19, Hans de Goede wrote: >>>> Hi Jan, >>>> >>>> I just saw your $subject patch in Gerd's usb-next tree, and I've a question >>>> about it. The token should be enough to uniquely identify a device + ep, >>>> and unless a guest uses multiple qhs for a singe ep, that _should_ be >>>> enough. >>> >>> But what disallows that the guest issues multiple requests (QH + series >>> of TDs) for a single endpoint? I'm not finding any trace in the spec >>> that disallows this. And my special guest is stumbling over that >>> limitation in QEMU. >> >> The order which the TDs from the two QHs are filled is undefined I >> think, so why a guest would do that? > > If short packets are ok, the next one queued would already be ready to > take the next chunk of data.
I don't think you need two queues to model that. IIRC the alt_next is taken on short tansfers, so you can line up all your TDs in one queue and let uhci jump forward to the next buffer start on short transfers using alt_next. The problem with two queues is that you simply don't know in which queue your transfers will end up and thus in which order your buffers are filled. I don't think you want that. If the device happens to NAK a transfer because it isn't ready yet uhci will go on to the next queue, so you can see the second queue being filled before the first is full. Wouldn't happen with qemu's uhci emulation, but I'm pretty sure on real hardware it can happen. cheers, Gerd
