On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > Its response to #11 is what is
> > broken. It may be getting confused by the second status request *or*
> > it may have sent the STALL (is that the -32?) before it received the
> > second GET_STATUS.
Or it didn't finish clearing out the STALL status from fetching the
descriptor (which that device doesn't have) before processing the
SETUP for the GET_STATUS request (which should always succeed).
That's an example of something that will tend to work right if the
driver gets a separate IRQ for both cases ("sent STALL", "received
a new SETUP"), but is easy to goof up if the two events come in the
same IRQ. Or in some cases, if the SETUP arrives while clearing
the STALL status ... beware those "write zero to clear" bits that
can get set while you're not looking, or the "write one to clear"
bits similarly.
> If queueing in HCD works well, the device would be presented with the
> second control request before the first one completed, and so the second
> scenario should have played. This is my understanding of it, but I may
> be wrong.
In this case you are. The HCD is *not allowed* to start one transfer before
the preceding one finishes. I have good reason to believe that neither
OHCI nor EHCI will misbehave in that way. UHCI has in the past had some
issues there ... so it's worth seeing if the same failures show up with
the other HCDs, just in case it still does. (To use EHCI to test a full
speed device: connect through an external high speed hub.)
The thing to understand about test #10 is that it's _trying_ to do things
that UDC drivers often get wrong. Trying to trigger races ("both events
in one IRQ"), trying to issue back-to-back faults so that improper cleanup
of one will make the next one go splat (or the request after both), trying
to make sure that the _right_ fault modes appear (both in the HCD and in
the UDC), trying to make sure short packets get handled correctly.
Trying to make those failures happen in the "lab" where they're easy to
reproduce, watch, and fix ... rather than in the field where that's
decidedly untrue. Control transfers are quite complex. It's usually
harder to get them right than it is to get for example bulk DMA to work.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
