On Tue, Jun 30, 2015 at 12:03:34PM -0400, Alan Stern wrote: > On Tue, 30 Jun 2015, Peter Chen wrote: > > > Hi Alan, > > > > When reading the code (at qh_urb_transaction) about zero-length packet > > for EHCI, would you please help me on below questions: > > > > - I have not found the zero-length qtd prepared for control read (eg, > > the transfer size is multiple of wMaxPacketSize), Am I missing > > something? > > The status stage transaction for a control-IN transfer has length 0, > but I guess that's not what you mean. > > Control-IN transfers don't have a zero-length QTD in the data stage > because IN transfers _never_ have a zero-length QTD. Then, how to cover the ch 8.5.3.2 Variable-length Data Stage: If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function will return a zero-length packet to indicate the end of the Data stage. By reading your answers below, does it mean neither host nor device need to prepare qtd and dtd for reading zero-length packet, the hardware can handle it, and knows the data stage is over? > > > - Why the IN transfer doesn't need to prepare zero-length qtd? > > In the 2.0 spec, it does not say it is only for OUT. > > > > Ch 5.7.3 & Ch 5.8.3 > > A bulk (interrupt) transfer is complete when the endpoint does one of the following: > > - Has transferred exactly the amount of data expected > > - Transfers a packet with a payload size less than wMaxPacketSize or > > transfers a zero-length packet > > Right. The host doesn't know beforehand how much data the device will > send during an IN transfer. It only knows how much data to expect -- > the device might send less than that amount. Therefore the host must > prepare QTDs for all the data it expects. > > Suppose the host expects the device will send 525 bytes. Then it > prepares a 525-byte QTD. If the device sends a 512-byte packet > followed by a 13-byte packet, all is well. But what if the device > wants to send only 512 bytes? Then it sends a 512-byte packet followed > by a 0-byte packet. When the host controller sees the 0-byte packet, > it knows the transfer is over -- but we still had to prepare a full > 525-byte QTD, because we didn't know beforehand that the device would > send only 512 bytes. > > To put it another way, the sender indicates that he will send less > data than expected by sending a short packet. If the amount of data he > wants to send is _not_ a multiple of the maxpacket size, then nothing > special needs to happen. The last packet will automatically be shorter > than the maxpacket size. But if the amount of data he wants to send > _is_ a multiple of the maxpacket size, then after sending all the data > he still needs to send a short packet. Since there is no more data > left to send, he is forced to send a zero-length packet. > > Thus, when the host is the sender (i.e., for an OUT transfer), the host > has to send a zero-length packet if the amount of data is shorter than > the device expects and is a multiple of the maxpacket size. When the > host is the receiver (i.e., for an IN transfer), the _device_ is > responsible for sending a zero-length packet -- not the host. > > > Ch 5.6.4 > > An isochronous IN endpoint must return a zero-length packet whenever > > data is requested at a faster interval > > than the specified interval and data is not available. > > That's right, but you don't see it in ehci-hcd because for isochronous > transfers, the packet lengths are always specified by the class driver > in the urb_iso_packet_descriptor structures. Get it, thanks. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
