On Wed, 21 Oct 2009, Sarah Sharp wrote: > > There's still a problem. What should happen if an entire URB without > > ISO_ASAP falls within the IST? We can't accept it -- since no siTDs > > would be added to the schedule, we would have no way to recognize when > > the URB had completed and to give it back. But if we fail the > > submission then the stream's ending frame won't advance. > > Is your plan to give errors for some of the packets within an URB that > fall within the IST, and schedule the others in the URB? And by > "stream's ending frame", do you mean stream->next_uframe? Yes and yes. > In the situation you describe, there's another issue. If the whole URB > falls within the IST, and we're not under a heavy load, the driver may > be submitting one URB with one packet each time. In that case, the > driver will continually see an error with each submission. That will > produce the same effect as the bug would (blank video, no audio, etc). > The driver should probably just be fixed in that case. Right. As I said, drivers will need to be able to handle these errors in a reasonable way. > > I suppose we could treat the URB as though the ISO_ASAP flag had been > > set. But this doesn't seem like a very good idea. Really, we don't > > have any sensible way for drivers to handle this sort of error. > > Maybe the completion handlers should, when they encounter an URB with > all packets that have errors, read the microframe register and attempt > to schedule further in the future. Or just set ISO_ASAP. Either would work. But one way or another, the drivers will have to be changed. > > P.S.: I noticed some other bugs today. The new code for checking > > whether an URB extends too far into the future should be invoked for > > new streams as well as continuing ones. > > > > And in usb_submit_urb(), the code that checks whether urb->interval is > > set correctly will reduce the value if it too high. This is fine for > > interrupt URBs but it's a very bad idea for isochronous URBs. We > > should fail those submissions. > > > > 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 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? Alan Stern -- 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
