> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Saturday, August 06, 2011 12:42 AM > To: Xu, Andiry > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: Re: [RFC 2/3] xhci: Fix failed enqueue in the middle of isoch > TD. > > On Fri, Aug 05, 2011 at 01:55:21PM +0800, Xu, Andiry wrote: > > In the patch description you mention "but leave the cycle bit of the > > first TRB (which will show software-owned) intact", but here it > leaves > > both the first_trb and last_trb intact. I think that is because here > the > > cur_td->last_trb actually point to the trb pass the real last trb of > the > > td, right? From driver view, that is correct I think, but maybe this > > casuses some sort of confusion because here the cur_td->last_trb does > > not really belong to the td. Please correct me if I'm wrong. > > Yes, that is correct. last_trb points to one TRB past the last > enqueued > TRB. I have to do it that way, in case there is a link TRB at the very > end of the last TD. The link TRB would have been marked as hardware > owned in inc_enq() when the last TRB of the last TD was enqueued. If > I > only passed in the last TRB of the last enqueued TD, it would have > pointed to the TRB before the link TRB, and the link TRB wouldn't have > its cycle bit flipped back. Since inc_enq() XORs the cycle bit, the > next time something was enqueued up to the link TRB, the cycle would > have been flipped the opposite way we intended (to software owned). > > Is there some comment I can add that would make this more clear? > Thanks for the explanation. I think just add some comment to specify that the last_trb actually points to the TRB past the last enqueued TRB to solve the cycle bit of link TRB handling is enough. Thanks, Andiry -- 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
