[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 #6 from Nicola Lunghi (nick83ola@gmail.com) ---
(In reply to Alan Stern from comment #5)
> For anyone who wants to know more about how isochronous scheduling is
> intended to work in the Linux USB stack, see the description in the
> kerneldoc for usb_submit_urb() in drivers/usb/core/urb.c.
> 
> In short, the start_frame field in struct urb is output-only.  The host
> controller driver doesn't pay any attention to it when an URB is submitted,
> but the frame assigned to the URB's first isochronous packet gets stored in
> start_frame before the URB completes.  Furthermore, the URB_ISO_ASAP flag
> only affects what happens to an URB that was submitted too late to keep the
> endpoint's queue going (say, because interrupts were blocked for too long). 
> If the queue is just starting up, or the URB isn't already too late,
> URB_ISO_ASAP is ignored.
> 
> Also, host controller drivers are not likely to pay attention to the
> interval field.  They will use the interval specified in the endpoint's
> descriptor.

Sorry Alan I don't understand your considerations. are you saying that this is
not valid? the documentation you pointed out states that

 With few exceptions, USB device drivers should never access URB fields
 * provided by usbcore or the HCD until its complete() is called.
 * The exceptions relate to periodic transfer scheduling.  For both
 * interrupt and isochronous urbs, as part of successful URB submission
 * urb->interval is modified to reflect the actual transfer period used
 * (normally some power of two units).  And for isochronous urbs,
 * urb->start_frame is modified to reflect when the URB's transfers were
 * scheduled to start.

I also found this documentation from intel
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf

pag 219 4.11.2.5 describes the start frame field.

I don't have time today I'll try to play with this during the we.

Can someone tell me if my considerations at the beginning are valid and the
behaviour that we have is missing the start_frame handling, or there's
something I don't see and the driver is actually doing the right thing?

Thanks,
Nicola

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

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