On Thu, 21 Aug 2003, David Brownell wrote:
Alan Stern wrote:
David:
It's not clear how the gadget API handles the data and status stages of a control transfer. The impression I have is that the queued requests are bi-directional; the gadget controller reads the request buffer if it gets an IN packet and writes the request buffer if it gets an OUT packet.
Erm, other way around: IN to the host means the gadget writes (but the host reads); and OUT to the device means the gadget reads (host writes).
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.
But what happens for the status stage?
It proceeds automatically, unless the gadget driver tells the controller to stall. We can't get too fancy here because not all hardware gives as much packet-level control for ep0 as the net2280 does ... we need more of a "least common denominator" control model here in the API.
The simplest way a gadget driver tells the controller driver to stall ep0 is to return an error from the setup() callback ... that's easy when the request is bogus or unrecognized. That will likely stall the data stage.
But once the gadget driver writes a buffer IN to the host, the status stage is committed to succeed. (If it weren't going to succeed, then there would be no point in providing the IN buffer...)
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.
If you want to try stalling in the completion handler for the OUT data, some hardware might allow that; net2280 does.
For OUT, it's an error if the controller sees more OUT bytes than the queued request allows. The controller driver should automatically stall, reporting -EOVERFLOW. If that request did not allow enough bytes, it's the fault of the gadget driver; if it did, it's the host's fault. (I've seen some vendor protocols that don't use all the SETUP packet bytes the same way that standard requests do, so wLength isn't necessarily relevant here.)
If the controller sees the status stage start before the request fills with data from OUT packet, that's handled like any other short read case (req->actual < req->length). I don't recall whether the USB spec has any requirements in this case; the current net2280 code doesn't stall or anything.
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 ... :) 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.
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.
Is "completing a reset" something that can reasonably be done in the completion handler that's receiving the reset command block?
This gets into hardware-specifics. If the hardware doesn't allow this, there's not much to be done. It seems like some hardware may not be happy delaying such acks. There's at least one case where older PXA hardware refuses to do so and causes significant problems for gadget drivers. (Fixed in PXA 255; affects config change events.) There may be others.
- Dave
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
