On Fri, Oct 05, 2012 at 01:27:10PM +0800, loody wrote: > hi Sarah: > > 2012/10/5 Sarah Sharp <sarah.a.sh...@linux.intel.com>: > > On Thu, Oct 04, 2012 at 01:47:44PM +0800, loody wrote: > >> Hi all: > >> from below out put slot context it shows ep0 consumer cycle bit is 1 > >> but why when we enqueue control transfer we purposely leave setup > >> status cycle bit as 0. > >> (below I purpose dump control trb content and 0xcf01c80c should be > >> 0x00000841 instead of 0x00000840, right?) > >> > >> [192016.504076] address trb: cf01c800: 01000680 00080000 00000008 00000840 > >> [192016.505593] address trb: cf01c810: 30e1fdc0 00000000 00000008 00010c05 > >> [192016.507129] address trb: cf01c820: 00000000 00000000 00000000 00001021 > > > > We leave the setup status cycle bit as zero until we've written the > > status phase to the ring. This is to prevent the host from executing > > the control transfer until it's fully written to the ring. We do the > > same thing for all transfer descriptors (TD) that have more than one > > transfer request buffer (TRB). > does that mean some xHC will steal trbs before we ring the door bell? > Theoretically, xHC will wait until we ring the door bell, right?
The xHC may still be reading TRBs from a previous doorbell ring. Or if it's a periodic endpoint, it may be checking the ring at that interval without needing the doorbell ring. So no, the xHC may not wait until the next doorbell ring to read the TRBs. That's why the driver is very careful about when it writes the cycle bit of the first TRB in a TD. Sarah Sharp -- 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
