On Thu, 2 May 2013, Sarah Sharp wrote: > On Thu, May 02, 2013 at 04:01:32PM -0400, Alan Stern wrote: > > Sarah: > > > > xhci_queue_isoc_tx_prepare() has a comment saying "Always assume > > URB_ISO_ASAP set". I'd like to see about fixing this, but I don't know > > where to look. It doesn't seem as though any significant computations > > are done for the starting frame; the value always gets set to the > > current (micro)frame number. In particular, the driver doesn't use > > HCS_IST. > > > > Does the hardware expose the scheduling information for isochronous > > endpoints? I couldn't find any mention of this in the xHCI spec. > > That's a big can of worms. I have a larger plan to fix some isochronous > ring performance issues, and I'd like to implement this change along > with that.
Okay. It's not a big deal at the moment. > Can you wait for that change to go in? AFAIK no in-kernel drivers don't > set URB_ISO_ASAP, so I didn't think this was an urgent change. Clemens Ladisch recently posted a patch removing the URB_ISO_ASAP flags from the usb-audio drivers. Of course, as long as xhci-hcd ignores that flag anyway, it won't make any difference. Incidentally, I just noticed something odd while working on the audio issue. Many audio devices use isochronous feedback endpoints for clock synchronization. The audio class specification says that the descriptors for these feedback endpoints should always have bInterval set to 1; the actual interval for the endpoint is stored in the bRefresh field. Lord knows why they did this, but it is something we will have to take into account for scheduling. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
