Re: About zero-length packet design for EHCI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux