Re: About zero-length packet design for EHCI
Thanks Alan, that was very helpful. /Bernd Alan Stern wrote: On Tue, 14 Jul 2015, Bernd Porr wrote: I've got a question regarding ISO transfer. If the firmware is not providing data is the ISO urb returning zero packet length and if yes how can I check that in the driver? I'm working on a solution for my USBDUX driver where the ADC for example takes 800us to measure all data so that a couple of zero length packets were generated until new data has been created. I assume you're talking about isoc-IN transfers where the device either sends a 0-length packet or doesn't send any packet at all. When that happens, the corresponding urb_iso_packet_descriptor structure will contain 0 for .actual_length and either 0 for .status (if a 0-length packet was received) or -EXDEV for .status (if no packet was received). Your driver can check these values in the URB's completion routine. Alan Stern -- http://www.berndporr.me.uk http://www.imdb.com/name/nm3293421/ http://www.facebook.com/bernd.porr +44 (0)7840 340069 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
I've got a question regarding ISO transfer. If the firmware is not providing data is the ISO urb returning zero packet length and if yes how can I check that in the driver? I'm working on a solution for my USBDUX driver where the ADC for example takes 800us to measure all data so that a couple of zero length packets were generated until new data has been created. /Bernd Alan Stern wrote: On Fri, 3 Jul 2015, Peter Chen wrote: Thanks, I think I understand it now. Maybe only the case A like below commit needs zero-length packet. usb: chipidea: udc: Disable auto ZLP generation on ep0 953c66469735aed8d2ada639a72b150f01dae605 Case A (as described in that commit) definitely needs a ZLP. The packet could be generated by the software or by the hardware. But not by both -- then there would be two ZLPs! Here is a simplified answer. If a transfer requires more than one qTD, then all the qTDs but the last one will have their Alternate Next qTD Pointers set to a special value. The last qTD doesn't need this. Since ehci-hcd never uses more than one qTD for a control transfer data stage, the issue doesn't comes up. But if you look at how ehci-hcd handles large bulk transfers, you will see what I mean. The case A I list above, it should uses more than one qTD, right? In case A, wLength is 255 bytes. That easily fits into one qTD. In fact, an EHCI qTD can handle up to 20 KB. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- http://www.berndporr.me.uk http://www.imdb.com/name/nm3293421/ http://www.facebook.com/bernd.porr +44 (0)7840 340069 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
On Tue, 14 Jul 2015, Bernd Porr wrote: I've got a question regarding ISO transfer. If the firmware is not providing data is the ISO urb returning zero packet length and if yes how can I check that in the driver? I'm working on a solution for my USBDUX driver where the ADC for example takes 800us to measure all data so that a couple of zero length packets were generated until new data has been created. I assume you're talking about isoc-IN transfers where the device either sends a 0-length packet or doesn't send any packet at all. When that happens, the corresponding urb_iso_packet_descriptor structure will contain 0 for .actual_length and either 0 for .status (if a 0-length packet was received) or -EXDEV for .status (if no packet was received). Your driver can check these values in the URB's completion routine. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
On Fri, 3 Jul 2015, Peter Chen wrote: Thanks, I think I understand it now. Maybe only the case A like below commit needs zero-length packet. usb: chipidea: udc: Disable auto ZLP generation on ep0 953c66469735aed8d2ada639a72b150f01dae605 Case A (as described in that commit) definitely needs a ZLP. The packet could be generated by the software or by the hardware. But not by both -- then there would be two ZLPs! Here is a simplified answer. If a transfer requires more than one qTD, then all the qTDs but the last one will have their Alternate Next qTD Pointers set to a special value. The last qTD doesn't need this. Since ehci-hcd never uses more than one qTD for a control transfer data stage, the issue doesn't comes up. But if you look at how ehci-hcd handles large bulk transfers, you will see what I mean. The case A I list above, it should uses more than one qTD, right? In case A, wLength is 255 bytes. That easily fits into one qTD. In fact, an EHCI qTD can handle up to 20 KB. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
On Wed, Jul 01, 2015 at 10:16:12AM -0400, Alan Stern wrote: On Wed, 1 Jul 2015, Peter Chen wrote: 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? If a control-IN transfer has a data stage that is shorter than wLength and is a multiple of the ep0 maxpacket value, then the peripheral must send a zero-length packet to indicate the end of the data stage. Thus, the UDC driver must prepare a zero-length transaction (DTD). If one is multiple? The wLength at setup packet is 64 bytes, Maximum Packet Length at dQH is 64 bytes, and the Total Bytes at dTD is 64 bytes too, does device must prepare a zero-length packet? I would like to double confirm it since the iPhone (As host after HNP) can't work well with it if I have a zero-length packet after 64 bytes packet which I describe above, if without zero-length packet, the iPhone works well. The host hardware will recognize when this happens, because the HCD will set the appropriate bits in the data-stage qTD. For example, with EHCI the HCD will set the Alternate Next qTD Pointer. Or with UHCI, the HCD will set the SPD (Short Packet Detect) bit. I see it in the code, but it is a null pointer (EHCI_LIST_END), does it mean one qTD (with valid Next qTD Pointer) can handle one 64 byte packet with or without zero-length packet well both? Any reasons why iPhone can't handle zero-length packet well? But the HCD should never prepare a zero-length qTD for an IN transfer. Zero-length packets are the responsibility of the _sender_, and for IN transfers the sender is the peripheral, not the host. Alan Stern -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
On Wed, Jul 1, 2015 at 11:00 PM, Peter Chen peter.c...@freescale.com wrote: If one is multiple? The wLength at setup packet is 64 bytes, Maximum Packet Length at dQH is 64 bytes, and the Total Bytes at dTD is 64 bytes too, does device must prepare a zero-length packet? I would like to double confirm it since the iPhone (As host after HNP) can't work well with it if I have a zero-length packet after 64 bytes packet which I describe above, if without zero-length packet, the iPhone works well. The host hardware will recognize when this happens, because the HCD will set the appropriate bits in the data-stage qTD. For example, with EHCI the HCD will set the Alternate Next qTD Pointer. Or with UHCI, the HCD will set the SPD (Short Packet Detect) bit. I see it in the code, but it is a null pointer (EHCI_LIST_END), does it mean one qTD (with valid Next qTD Pointer) can handle one 64 byte packet with or without zero-length packet well both? Any reasons why iPhone can't handle zero-length packet well? But the HCD should never prepare a zero-length qTD for an IN transfer. Zero-length packets are the responsibility of the _sender_, and for IN transfers the sender is the peripheral, not the host. I can't speak about the details of the ehci driver. But for this issue we can speak about sender and receiver, Host and gadget both send and receive during transfers. If the protocol does not specify a transfer length, then the sender MUST send a zlt if the transfer is less than expected and a multiple (1*, 2*, 3*) of maxpacketsize. If the protocol does specify a transfer length, then exactly that length should be sent and received with NO ZLT. For example USB mass storage sends multiples of maxpacketsize but does not send ZLTs. If you do an analyzer trace between windows and your gadget, then you can see what those guys think the rules for your protocol are. Regards, Steve -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
On Thu, 2 Jul 2015, Peter Chen wrote: If a control-IN transfer has a data stage that is shorter than wLength and is a multiple of the ep0 maxpacket value, then the peripheral must send a zero-length packet to indicate the end of the data stage. Thus, the UDC driver must prepare a zero-length transaction (DTD). If one is multiple? The wLength at setup packet is 64 bytes, Maximum Packet Length at dQH is 64 bytes, and the Total Bytes at dTD is 64 bytes too, does device must prepare a zero-length packet? No. Here is the exact rule for when a device must prepare a 0-length packet for a control-IN data stage. Let wlength = le16_to_cpu(setup-wLength) and let act_length = req-length be the actual data length. Then an extra 0-length packet is needed if: act_length 0 act_length wlength (act_length % maxpacket) == 0. (Note that if act_length == 0 then req already gives rise to a 0-length packet; no additional packets are needed.) Here's another way to describe the same rule: 1. Every packet before the final packet must have size equal to maxpacket. 2. If act_length wlength then the final packet must have size smaller than maxpacket. 3. If act_length == wlength and act_length 0 then the final packet must have size 0. You can check that this is equivalent to the rule above. In the example you gave, act_length == wlength so a 0-length packet isn't needed. I would like to double confirm it since the iPhone (As host after HNP) can't work well with it if I have a zero-length packet after 64 bytes packet which I describe above, if without zero-length packet, the iPhone works well. That means the iPhone is behaving properly. The host hardware will recognize when this happens, because the HCD will set the appropriate bits in the data-stage qTD. For example, with EHCI the HCD will set the Alternate Next qTD Pointer. Or with UHCI, the HCD will set the SPD (Short Packet Detect) bit. I see it in the code, but it is a null pointer (EHCI_LIST_END), does it mean one qTD (with valid Next qTD Pointer) can handle one 64 byte packet with or without zero-length packet well both? That is a tricky question, and the full answer involves the complicated details of how EHCI works. Here is a simplified answer. If a transfer requires more than one qTD, then all the qTDs but the last one will have their Alternate Next qTD Pointers set to a special value. The last qTD doesn't need this. Since ehci-hcd never uses more than one qTD for a control transfer data stage, the issue doesn't comes up. But if you look at how ehci-hcd handles large bulk transfers, you will see what I mean. Any reasons why iPhone can't handle zero-length packet well? When the iPhone receives the 64-byte packet, it thinks the data stage is finished. It moves on to the status stage, where it sends a 0-length packet to the gadget and waits for the acknowledgment. If the gadget is still trying to send a 0-length packet, it won't acknowledge the 0-length packet sent by the iPhone. The status stage will time out and the control transfer will fail. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
On Thu, Jul 02, 2015 at 10:46:36AM -0400, Alan Stern wrote: On Thu, 2 Jul 2015, Peter Chen wrote: If a control-IN transfer has a data stage that is shorter than wLength and is a multiple of the ep0 maxpacket value, then the peripheral must send a zero-length packet to indicate the end of the data stage. Thus, the UDC driver must prepare a zero-length transaction (DTD). If one is multiple? The wLength at setup packet is 64 bytes, Maximum Packet Length at dQH is 64 bytes, and the Total Bytes at dTD is 64 bytes too, does device must prepare a zero-length packet? No. Here is the exact rule for when a device must prepare a 0-length packet for a control-IN data stage. Let wlength = le16_to_cpu(setup-wLength) and let act_length = req-length be the actual data length. Then an extra 0-length packet is needed if: act_length 0 act_length wlength (act_length % maxpacket) == 0. (Note that if act_length == 0 then req already gives rise to a 0-length packet; no additional packets are needed.) Here's another way to describe the same rule: 1. Every packet before the final packet must have size equal to maxpacket. 2. If act_length wlength then the final packet must have size smaller than maxpacket. 3. If act_length == wlength and act_length 0 then the final packet must have size 0. You can check that this is equivalent to the rule above. In the example you gave, act_length == wlength so a 0-length packet isn't needed. Thanks, I think I understand it now. Maybe only the case A like below commit needs zero-length packet. usb: chipidea: udc: Disable auto ZLP generation on ep0 953c66469735aed8d2ada639a72b150f01dae605 The host hardware will recognize when this happens, because the HCD will set the appropriate bits in the data-stage qTD. For example, with EHCI the HCD will set the Alternate Next qTD Pointer. Or with UHCI, the HCD will set the SPD (Short Packet Detect) bit. I see it in the code, but it is a null pointer (EHCI_LIST_END), does it mean one qTD (with valid Next qTD Pointer) can handle one 64 byte packet with or without zero-length packet well both? That is a tricky question, and the full answer involves the complicated details of how EHCI works. Here is a simplified answer. If a transfer requires more than one qTD, then all the qTDs but the last one will have their Alternate Next qTD Pointers set to a special value. The last qTD doesn't need this. Since ehci-hcd never uses more than one qTD for a control transfer data stage, the issue doesn't comes up. But if you look at how ehci-hcd handles large bulk transfers, you will see what I mean. The case A I list above, it should uses more than one qTD, right? Any reasons why iPhone can't handle zero-length packet well? When the iPhone receives the 64-byte packet, it thinks the data stage is finished. It moves on to the status stage, where it sends a 0-length packet to the gadget and waits for the acknowledgment. If the gadget is still trying to send a 0-length packet, it won't acknowledge the 0-length packet sent by the iPhone. The status stage will time out and the control transfer will fail. Alan Stern -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
On Wed, 1 Jul 2015, Peter Chen wrote: 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? If a control-IN transfer has a data stage that is shorter than wLength and is a multiple of the ep0 maxpacket value, then the peripheral must send a zero-length packet to indicate the end of the data stage. Thus, the UDC driver must prepare a zero-length transaction (DTD). The host hardware will recognize when this happens, because the HCD will set the appropriate bits in the data-stage qTD. For example, with EHCI the HCD will set the Alternate Next qTD Pointer. Or with UHCI, the HCD will set the SPD (Short Packet Detect) bit. But the HCD should never prepare a zero-length qTD for an IN transfer. Zero-length packets are the responsibility of the _sender_, and for IN transfers the sender is the peripheral, not the host. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
About zero-length packet design for EHCI
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? - 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 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. Thanks. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About zero-length packet design for EHCI
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. - 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. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
