[Bug 220748] usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220748

--- Comment #15 from Alan Stern (stern@rowland.harvard.edu) ---
When the queue underruns is exactly when URB_ISO_ASAP is supposed to matter. 
If the flag is set in the new URB then that URB should be scheduled for the
first slot in the future, leaving a logical gap in the queue.  If the flag is
clear then the new URB is supposed to be scheduled for the slot that follows
the preceding URB, which means that some of its packets will never be sent
because their slots have already expired.  This will still leave a physical gap
in the queue, of course -- no way to avoid that -- but it will maintain the
logical alignment of URBs and frames.

Thus by submitting all URBs with URB_ISO_ASAP clear, drivers can help ensure
that the queue remains synchronized to within the limits imposed by the host
controller driver.  If xhci-hcd doesn't behave this way then it should be
changed.

As for inserting a gap to resynchronize after detected lost packets, it's
simple enough for drivers to submit isochronous URBs with some of the packet
lengths set to 0.  Figuring out how many packets should have length 0 will be
tricky, but that can be adjusted after the URBs complete, by checking their
starting frame numbers.

I believe drivers can safely assume that the 8 low-order bits of the frame
number will be valid (11 bits for microframe numbers), and that they are
allowed to submit URBs up to 50 ms in the future.  The kerneldoc says 10 - 200
ms, but it's being conservative.  When a driver wants to keep latency to a
minimum, it won't go more than 1 or 2 ms into the future, anyway.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.