David Brownell wrote: > Hmm. Here's a theory. The way that the current code unlinks > an ED is to set the SKIP bit *AND* remove the ED from the relevant > part of the schedule. > > Maybe ... the hardware gets confused when the ED doesn't seem > to be on the relevant list. Like maybe it expects it to stay > at the head of the ED list. ISTR some silicon doesn't much > like to see null pointers written into the hardware registers, > and I know for a fact that the ed_deschedule logic was always > a bit racey. > > That suggests that the safest route would be setting SKIP for > one frame (so all pending TDs get properly retired), and > only *THEN* taking it out of the queue.
At least in the case of our device driver, which reuses a single read URB per device, there should only be one outstanding TD at a time. So when ed_deschedule gets called, there would not be any TDs outstanding. This also puts a big hole in my theory, since the timing window I was imagining shouldn't exist in this case. For what it's worth, the sample code in the OHCI spec doesn't wait until the next SOF either when removing an ED from the schedule. But that doesn't necessarily reflect all real world situations ;) And since the TD queue never builds up, it doesn't seem like the type of use the spec was expecting. The ED (de)scheduling code is completely unknown to me at this point. I'll get familiar with it. Mike ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
