Re: Scenario: usbtest test-14 failure: MUSBHDRC + Netchip2280

On Fri, 30 Mar 2007, David Brownell wrote:

> > No -- it says that hosts "must return to using a PING token until the
> > endpoint indicates it has space".  "Return to using a PING token" != "send 
> > the PING".
> 
> A curious reading ... how can it use a ping token other than by sending it???

I'll answer this question and then go on to discuss the state machine 
diagram.

To understand this statement, it's necessary to grasp how and why the PING
protocol is supposed to be used.  The motivation is explained right at the
start of 8.5.1; the PING protocol is meant to improve bus utilization by
giving the host a way to avoid sending data until it knows the endpoint
has space for the data.  That's almost a direct quote from the third 
paragraph.

(Note BTW that the second paragraph says that the PING protocol must be
used for OUT transactions in the data and status stages of control
transfers.  By implication, it isn't used for the status stage of an OUT
control transfer because that is an IN transaction.  The reason for this
is also clear: The host doesn't need to send a PING before an IN
transaction because doing so would not improve bus utilization -- it would
worsen it.)

The following text explains how the protocol is used.  The host tracks
whether or not the endpoint can accept another max-sized data packet.  
When it can, the host performs an OUT transaction directly; when it can't
the hold must send a PING before doing another OUT.

Thus, using the PING protocol involves the host switching between two
modes: one where it must send a PING and one where it can send an OUT.  
The phrase "return to using a PING token until the endpoint indicates it
has space" means that the host must switch from the second mode back to 
the first.  "return" == return to the first mode.  "using a PING token" == 
send a PING before doing another OUT != send a PING.


Incidentally, the seventh paragraph states explicitly that following an
ACK response to a PING, "The host controller must generate an OUT
transaction with a DATA phase as the next transaction to the endpoint."  
That's an OUT, not an IN.  Completely unambiguous.

Whether it should be a 0-length OUT is a separate question.  We could
make the net2280 driver accept such things.  However it definitely rules 
out the scenario you've been advocating: Send PINGs until the device 
responds with ACK, then send an IN to begin the status stage.

Regarding these extraneous 0-length OUT transactions at the end of the
data stage, Section 8.5.3 says this:

	If the amount of data exceeds the prenegotiated data packet size, 
	the data is sent in multiple transactions (INs or OUTs) that carry
	the maximum packet size.  Any remaining data is sent as a residual
	in the last transaction.

It follows that the second-to-last transaction must be full-sized.  And in 
particular, you can't end the data stage with a 0-length packet, since the 
last transaction must carry the residual remaining data.


> Admittedly those state machine diagrams in the USB 2.0 spec use some
> strange notation, but it's explained in fig 8-17 ... and the action
> in response to NYET is RespondHC(Do_next_ping), which is distinct
> from the RespondHC(Do_next_cmd) you are describing.  For this transfer,
> the next command would be a zero-length IN (the status phase).
> 
> (Appendix B.1 has comments on do_next_ping and do_next_cmd.)

(Not in my copy of the spec.  B.1 has a comment for do_next_cmd, but there 
is no comment at all for do_next_ping, do_ping, or do_out.  An 
inexplicable and lamentable omission.)

> > In the corrected figure, the questionable state box is labelled "HSU2.PID
> > = NYET" and the action is "RespondHC(Do_next_ping);".  Unfortunately
> > Do_next_ping isn't defined anywhere.
...
> > Apparently it is meant to be much  
> > like Do_next_cmd (the action when the device responds with ACK), except 
> > that HC_cmd.ping is set before proceeding to the next transaction.
> 
> That doesn't match the B.1 text or common sense.  If they were the
> same, they wouldn't have distinct names.

I said one was _much like_ the other, not the same.

>  B.1 says do_next_cmd means
> "do next command for this endpoint, advance data pointer appropriately".
> So do_next_ping doesn't do either of those.

How on earth can you justify this statement, given that B.1 doesn't define
do_next_ping at all?

My own best guess is that do_next_ping means "set HC_cmd.ping, do next
command for this endpoint, advance data pointer appropriately".  This
makes sense because it combines the "do_next_..."  part of the name with
the "_ping" part.

> > Thus, if the next transaction is another OUT/DATA, a PING will be sent
> > first.  In any case, the "Do_next" part of the name, together with the
> > fact that the control flow then exits the diagram, indicates the
> > current transaction _has_ indeed been completed.
> 
> No; it can't leave the HC_HS_BCO state diagram (fig 8-27) until do_next_cmd
> says it has completed the current command.

Or until do_next_ping says it has completed the current command.  Since we 
don't know what do_next_ping actually says, you mustn't dismiss this 
possibility.

> > But now the next transaction is IN/STATUS, 
> 
> Only after do_next_cmd triggers.  Which means not until the do_next_ping
> finishes its work and an ACK is received.

According to Fig. 8-27, when a PING receives an ACK the next action is
"RespondHC(Do_OUT);" which obviously means the host will send an OUT.  
Not an IN.  This would result in sending extraneous 0-length OUT/DATA
packets, in contradiction to 8.5.3.

> > so we have to behave according  
> > to Fig. 8-33 (Bulk/Control/Interrupt IN Transaction Host State Machine).  
> > That figure makes no mention of PING packets.  Hence no PING needs to be 
> > sent.
> 
> That's because the next state after do_next_ping is HC_HS_BCO, always;
> the HC_DO_BCINTI transition follows only after an ACK.

How do you know?  How do you know that it doesn't also follow after a 
NYET?

Alan Stern


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel