On Thu, 12 Jan 2012, Sarah Sharp wrote: > On Thu, Jan 12, 2012 at 10:35:28AM -0500, Alan Stern wrote: > > On Thu, 12 Jan 2012, Andiry Xu wrote: > > > > > Sarah, > > > > > > Thanks for the information! I'll check it. > > > > Somewhat out of the blue... > > > > I haven't paid too much attention to the ring-expansion patches, but > > it's obvious that they were difficult and complex. What was the main > > problem? > > There were a couple problems. The first is that the xHCI driver doesn't > keep track of how many free TRBs are on a ring, so the enqueueing code > had to walk across the ring, seeing if each TRB needed was free before > it enqueued any transfers. Isn't keeping track of free TRBs the same thing as keeping track of the dequeue pointer? Every TRB from the dequeue pointer up to the enqueue pointer is in use, and all other TRBs are free (except the link TRBs, of course, which mustn't be overwritten). > To implement your suggestion of not putting > TRBs in the segment where the dequeue pointer is, we'd still need to > know how many free TRBs are leftover in the enqueue segment. Isn't that simply all the TRBs between the enqueue pointer and the link TRB at end of the segment? > So either > way, that code has to change. That code change is what's currently > buggy. > > The other difficulty was inserting a new segment in the middle of the > ring, while making sure that the hardware-owned cycle bit was set > correctly. Otherwise the hardware would think that it owned TRBs in the > new segment before we enqueued any to that segment. What's so hard about managing cycle cits? I admit it can be a little subtle, but it shouldn't be hard. > The trouble with that is the xHCI driver is sometimes a bit uncertain as > to where the actual dequeue pointer is. We don't get an interrupt when > a link TRB at the end of a segment is processed by the host controller > and it starts fetching TRBs in the next segment. We can't get an > interrupt on link TRBs because it would mess up the cancellation code. > Therefore, when we get an event for a TD that ended just before the link > TRB, we don't know if the hardware has processed the link TRB, and > therefore we don't know if we can overwrite it to expand the ring. That merely means you have to be a little pessimistic -- assume the dequeue pointer hasn't advanced if you don't know otherwise. 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
