On Thu, 21 Aug 2003, David Brownell wrote: > Alan Stern wrote: > > > > I respectfully disagree: IN to the host means the gadget controller reads > > data from its request buffer and sends that data to the host. OUT to the > > device means the gadget controller takes the data coming from the host and > > writes it into the request buffer. > > I know what you mean; on closer reading I could sometimes agree. > > The thing is, you're talking about an implementation detail of > the gadget controller ... and I was talking about the gadget > driver, which is what really defines the "gadget" behavior. I've > tried to define the API in terms of what the gadget driver does, > not what the controller (or controller driver) does, and that's > how I first read statements about the API. > > The "sometimes agree" works as follows: > > - For PIO cases, the controller never reads memory > to get the IN data ... its driver does. (Both the > net2280 and the pxa2xx always use PIO for ep0.) > When writing such drivers, the difference matters! > > - For DMA cases, it's the DMA controller which does > the reads ... and that's not always part of the > USB controller. When it's part of the controller, > then I'd agree. > > So there are several levels of confusion to avoid by not > talking from the perspective of the controller, and always > using the perspective of the gadget driver.
All right. We can agree that IN transfers move data from the request buffer to the host and OUT transfer do the opposite. > > I'm not worried about STALLing a transfer; I'm concerned about when the > > status for an OUT transfer is sent. Does the controller automatically > > send the status acknowledgment when it receives an IN PID? Or does it > > keep track of setup.wLength and only acknowledge after all the OUT data > > has been received? Or does it wait until the gadget driver queues a > > request (which should have length 0)? > > The gadget driver should do the reight thing: read wLength bytes, > at which point an IN packet marks the status stage beginning. So the gadget driver does _not_ need to queue a zero-length request after reading wLength bytes (to generate the status acknowledgment). I've been assuming that it did. As a corollary, the gadget driver cannot delay delivery of the status acknowledgment once it has read the OUT data. > > In particular, can the gadget driver delay the status acknowledgment for > > an OUT transfer? Parts of the CBI specification mention circumstances > > in which a device might want to do that. See the fourth paragraph of > > 2.3.1 and the second paragraph of 2.3.2.1 for examples. Implied but not > > The fifth para of 2.3.1 claims that it's a "class-specific exemption" > from the USB spec too ... :) I think the exemption part refers to the fact that the delay can be indefinite. The USB spec prescribes some upper bound that normally applies to these things -- something like 5 or 10 seconds, I forget. > But it's also constrained a bit, even in > the rest of that section. That second para of 2.3.2.1 is explicit that > the status ACK only means a command was received -- not completed. Yes, status NAKs are entirely optional. So foregoing them won't cause any big problems. > > stated explicitly (it _is_ stated explicitly in the Bulk-Only spec) is > > that the reset command should not be acknowledged until it is complete -- > > and for CBI the reset command is a non-zero-length OUT control transfer. > > For bulk-only, it's a zero-length OUT, which is no problem. For CBI, I > sure read the spec as expecting status to come back on the interrupt > endpoint, as usual; but I've not eyeballed it as closely as you, and > might have missed something. On re-reading the spec, I think you're right. So that won't be a problem either. > Is "completing a reset" something that can reasonably be done in > the completion handler that's receiving the reset command block? No, at least not for my driver. But it doesn't matter. Thanks for the help. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
