On Thursday 29 March 2007 1:09 pm, Alan Stern wrote: > On Wed, 28 Mar 2007, David Brownell wrote: > > > > Here's the exact text from the spec: > > > > > > If the endpoint instead responds to the OUT/DATA transaction with > > > a NYET handshake, this means that the endpoint accepted the data > > > but does not have room for another wMaxPacketSize data payload. > > > The host controller must return to using a PING token until the > > > endpoint indicates it has space. > > > > > > This clearly indicates, even though it doesn't say so explicitly, > > > > Disagree. It says explicitly that it "must" return to PING. It does > > not create an exception like the one you ascribe to that text. > > Exactly -- "must return to using a PING token". I would expect that to > have a single unambiguous interpretation. Evidently you do too... but our > interpretations are different!
Return (to using a PING token) is what the state machine says too. > > And implementors are certainly allowed to use the same FIFO for IN > > transfers, > > which could have the same "fifo must be ready" constraint as OUT ones do. > > Of course. They are also perfectly free to reply with NAK to any IN > tokens until the FIFO is ready. There's no need and no requirement for > the host to use PING. Except that the spec says they "must" PING. Both in English and in the state machine. > > > The > > > entire discussion of the PING protocol is centered around the idea of > > > improved handling of OUT transfers; PINGs aren't needed before IN or SETUP > > > transactions at all. > > > > No, but PINGs *are* needed to finish processing an OUT transfer. > > Which is what the text says... > > It does not say that anywhere. Just the contrary; see the discussion of > Fig. 8-27 below. You're misreading the state machine; it does say exactly that (agreeing with the text). Only when it gets an ACK will it go to the next command; which is usually an OUT, but for control-OUT may also be an IN. > > > After all, what reason could there be for sending a PING before an > > > IN/DATA? PING asks whether the endpoint has space to store a new > > > wMaxPacketSize data payload, but with IN transfers the endpoint doesn't > > > have to store anything. > > > > What reason? Well, as noted above, the spec is written so hosts "must" > > send the PING. Accordingly, peripherals are allowed to rely on that. > > 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??? > > > > And ... the OUT/DATA stage can't have completed if a PING was due. > > > > As soon as the OUT/DATA stage completes, then the IN transactions > > > > may do their usual thing, and that different paragraph applies. > > > > > > No. If a PING is due, it means that the data already sent was received > > > correctly and hence the data stage _is_ complete. You can see it in the > > > section I quoted above: "... this means that the endpoint accepted the > > > data...". > > > > You're using a different definition of complete than I am. I'm using > > the same definition that a normal bulk OUT would use: ready to accept > > one more OUT packet. > > Again you are misinterpreting the spec. As far as the host is concerned, > a bulk OUT transaction is complete when either an ACK or a NYET is > received from the device. See Fig. 8-27 and below. The corrected fig 8-27 (that's not a cut/paste error copying fig 8-32) says the HC response to NYET is a PING... **NOT** "go to next command". > > (ISTR that peripherals are expected to handle any > > number of zero length OUT packets at the same point they're expected > > to start handling the status stage, for example ...) > > (I don't think that's right; can you find it in the spec? Certainly the > net2280 driver doesn't behave that way.) I don't have time to search the spec for that, but I do know that I've been asked to fix drivers that don't behave that way. There's at least one vendor selling "chapter 8 tests" which tests for this, so "expected" is correct even if the spec doesn't require it. It may be dubious, but some host drivers act like that ... so it's not unreasonable to expect drivers to act that way. At one point the net2280 driver *did* behave that way, as I recall -- it was a "bugfix" request. > > That is: NYET/PING is a handshake used to mark completion of an exchange. > > Treating the exchange as complete without the full handshake is at best > > error prone ... > > No. ACK is a handshake token used to mark completion of an exchange > together with an indication that the endpoint is ready to accept another > OUT data packet. NYET is a handshake token used to mark completion of an > exchange together with an indication that the endpoint is _not_ ready to > accept another packet. Right, not ready to accept another packet. EP0 can't accept another OUT, or another IN. It's not ready for the next IN or OUT command yet. > By contrast, PING isn't a handshake at all; it is > a poll used to see whether the endpoint is ready to accept another OUT > data packet. As you said above: NYET indicates that it's not ready to accept another packet. In this case PING is how one determines that it's ready. > > > I agree about the meaning of "must"; the question is: must do what? > > > > The text seems clear to me: must PING until the endpoint has space. > > It seems clear to me: must PING before sending another OUT. It doesn't actually say "before sending another OUT", and the corrected figure 8-27 is *also* clear that the response to NYET is a PING. 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.) > > > > I claim the intention of the spec is that the host must send a PING before > > > starting another OUT/DATA transaction. > > > > Thing is, you're inferring an "intention" that's not written, while > > ignoring the text that *IS* written. > > I'm _not_ ignoring it. So there! :-) OK, so you're admiring the edifice but still walking past it. :) > Besides, the figures are described as more explicit and detailed than the > written text in the spec (see p.7 of the Errata document). We should base > our argument on what the figures say instead of the misinterpretable text. As I just did above. The action "Do_next_ping" matches my reading of the text, and that's what NYET triggers. That's distinct from what the eventual ACK will trigger, "Do_next_cmd". > > Given a spec, standard practice is to stick to what's written, unless > > it's ambiguous. (Here, it isn't.) If there's ambiguity, then it's > > fair to use "intention" to make an educated guess ... but then also > > update the spec to remove the ambiguity, once everyone agrees on how > > that should be resolved. > > I certainly agree that updating the spec to make it less ambiguous would > help. But ... as I've pointed out, there is no ambiguity here. The text says one thing, the corrected fig 8-27 says the same thing. This is a case where the RTL used to compile Vikram's version of Mentor's HDRC is clearly not doing what the USB 2.0 spec (with errata) requires. This is *NOT* the first time such issues have turned up in that core, so finding an issue like that is not a surprise. Workarounds aren't always available, or usable; that's the way of such things. It's why there are still new revisions coming out... > > > You seem to think it means the host must send a PING > > > > Period, no matter what, since that's clearly what the spec says. > > It says "return to using a PING token". As I mentioned above, that is > different from "send a PING". And I expressed puzzlement at that convoluted reading; it doesn't match what fig 8-27 says either... > > > Well, the patch is a separate question. Thinking about it some more, I > > > doubt it will actually fix the problem. In fact, my best guess is that > > > for some reason the net2280 doesn't set the DATA_IN_TOKEN_INTERRUPT flag > > > when the IN token arrives. Maybe some sort of low-level hardware timing > > > issue. > > > > Like ... maybe the NetChip folk took the USB spec at its word? :) > > At _your_ word, you mean. Perhaps. Or maybe it's just a hardware bug. At the word of the USB 2.0 spec, which says that after NYET it's not supposed to advance to the next command until after a PING gets ACKed. > > From the corrected figure 8-27 it is clear that SETUP can still be sent > > irrespective of the PING state of the device. I actually don't read fig 8-27 as saying that at all. But it's a moot point since sending a SETUP token resets the device state machine in any case. > 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. Appendix B.1 has a comment desribing do_next_cmd, but you're right that the behavior of RespondHC() could stand elaboration. > 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. 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. > 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. That's initially SETUP (which has special restrictions), then OUT (which uses the same diagram) for one or more transactions, then it goes to HC_DO_BCINTI ... those little purple arrows are a bit misleading, they don't say directly what the next state machine will be in the way that the railroad track pictures do. (That is, Figs 8-30 and 8-37.) > 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. > 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. > Another indication that the people who designed the protocol did not > expect these extra PINGs can be found in the design of the EHCI > controller. While there were some people on both teams, they were in fact separate projects. You can't depend on that level of groupthink, or let the EHCI spec trump the USB 2.0 spec. - Dave ------------------------------------------------------------------------- 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
