David Brownell wrote: > On Thursday 05 July 2007, Mike Nuss wrote: >> I'm at a loss. It really looks like the HC just "skipped" a step for no >> reason. > > I forget ... did you already try removing that special case > at the top of the IRQ handler, where it checks the low bit > of the hcca->done_head? That's a speedup, but there's at > least one implementation that doesn't support that part of > the OHCI spec correctly. (SA1111, which is ancient and out > of production, but still ... there could be others.)
Yes. I didn't take the check out, but I put in extra code that builds up a history of the value of HccaDoneHead whenever the IRQ comes in, regardless of any of the other checks in the function. > On Fri, 6 Jul 2007, Mike Nuss wrote: > > > All the other endpoints continue to function normally. Since NextED > > happens to be null in the cases I've seen, that means that it's on the > > end of its list and the other endpoints must be on other lists, which > > implies that at least one frame boundary must be crossed between > > handling the 'hung' endpoint and any others. Is that right? > I don't think so. Maybe the spec says something, but ISTR that > there's nothing particular about end-of-frame. It'll just keep > scanning the schedule(s) until there's no more space left in > the frame. Yes, you're right. To make sure, I put in some code to turn on SOF for a frame, and verified that frame_no is being incremented. > However, the whole point of the existing ZF micro quirk is to > add extra should-never-be-necessary delays in code paths which > are related to what you're fighting right now... I'm not sure that any Linux code could affect this at all, though. The device driver submits a URB, and ohci-hcd queues up a TD and passes it off to the host controller. Given the fact that it starts to process the TD normally, that leads me to think that there's nothing wrong with the submission code. While the HC is processing the queue, ohci-hcd has nothing more to do until it gets an interrupt (which never happens in the bad case) or if another URB is submitted (which will not happen in my test case). The only ohci-hcd code that might be running at the exact moment the glitch occurs would be the code that polls the root hub, which I haven't looked at (yet). Or if there's any other code that runs on a timer, but I think that's the only one. I'm very interested in the source of the existing quirk though. Do we know who wrote that code, and where the insight came from? Did s/he discover it experimentally or is there mention of the issue in the ZF data book somewhere? 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
