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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel