On Wed, Oct 21, 2009 at 09:20:26PM -0400, Alan Stern wrote: > > > Finally, one of the things we discussed was allowing drivers to specify > > > urb->start_frame for new streams (to get precise synchronization of two > > > devices, for instance). But with xHCI, the hardware does all the > > > scheduling as soon as an altsetting is installed. How can you tell it, > > > later on when the driver submits the first URB, what the start frame > > > should be? > > > > The xHC reserves bandwidth for the endpoint when it is added to its > > internal structures (currently at device configuration; later I'll add > > alternate interface setting support which will modify the endpoints' > > information). It doesn't schedule any transactions until you ring the > > doorbell for an endpoint when you enqueue buffers from an URB. > > Reserving bandwidth implicitly means making some decisions about which > uframes the transactions will occur in, because some combinations are > too inefficient even though the total bandwidth isn't overcommitted. > For example, suppose there are three streams each with a period of 2 > uframes. Suppose stream A requires 100 us, stream B requires 70 us, > and stream C requires 50 us per transaction. Reserving the bandwidth > is okay; the total doesn't overcommit. But if we happen to schedule > stream B (70-us) in even-numbered uframes and stream C (50-us) in > odd-numbered uframes then it won't be possible to schedule stream A > (100-us). The xHCI spec doesn't say anything about how the hardware should schedule things internally. I'll ping the spec author with your comment and see how the hardware will react in that case. > > The xHCI driver can specify which frame an isoc transfer goes out in. > > It has a "Start Isoch ASAP" flag, and a frame ID field for each isoc > > TRB. If the ASAP flag is not set, and a frame ID is specified, then the > > transfer is sent out when that field matches bits 13:3 of the microframe > > index register. So xHCI has a 2047 frame list length internally. > > Is there an equivalent way to specify in which uframe a high-speed or > super-speed transfer takes place? If there is, what happens if > xhci-hcd tells the hardware to start stream B in uframe 0, stream C in > uframe 1, and then stream A ASAP? > > Or does xHCI allow scheduling only down to the resolution of a frame? Yes, you can only specify what frame the transaction will start in, not microframe. At least for 0.95 and 0.96 xHCI host controllers. Also, the frame ID field is only used for the starting frame. While buffers are still posted within the isochronous scheduling threshold, the xHC will ignore the frame ID and transfer data at the interval specified in the endpoint context. If a buffer isn't posted within the IST, the host controller will send one overrun/underrun event to the driver. It will also stop scheduling transfers for that endpoint, but leave the bandwidth for that endpoint claimed. When the doorbell is rung again for the endpoint, the host controller will restart the transfers, looking at the frame ID if it's set and the ASAP flag isn't set. So, as long as you only use urb->start_frame for the starting *frame*, the xHCI driver should be able to accommodate device drivers. Sarah -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
