On Wed, 28 Mar 2007, David Brownell wrote:
> On Wednesday 28 March 2007 9:04 am, Alan Stern wrote:
> > On Wed, 28 Mar 2007, David Brownell wrote:
> >
> > > On Wednesday 28 March 2007 2:29 am, Pandita, Vikram wrote:
> > > >
> > > > > (**) 8.5.1 in the USB 2.0 spec says that after a NYET handshake,
> > > > > "the host controller must return to using a PING token until the
> > > > > endpoint indicates it has space".
> > > > >
> > > > > Clearly, the HDRC did not issue any PINGs ... it just went right
> > > > > to the status handshake. Fishy, and quite possibly something
> > > >
> > > > The PING flow-control is only for the OUT tokens.
> > > > So Host should send PING only if next OUT token is to be sent.
> > >
> > > That "must" language is unambiguous: PING "must" be sent.
> > > There is no "should" in that paragraph of the spec.
>
> Re-read that please ... "must". That's what getting a NYET means.
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, that the
host controller must return to using a PING token _before sending the next
OUT/DATA transaction_ until the endpoint indicates it has space. 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.
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.
It's unfortunate that the spec doesn't pay more attention to the case of
control endpoints here. Obviously the focus was on Bulk-Out endpoints.
> > That's not right. Here's what the spec says (section 8.5.1):
> >
> > High-speed devices must support an improved NAK mechanism for Bulk
> > OUT and Control endpoints and transactions. Control endpoints
> > must support this protocol for an OUT transaction in the data and
> > status stages.
>
> 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...".
> ... right, not required for IN transactions, but the preceding OUT
> was still partly pending, so the status stage wasn't ready to begin.
> If the OUT were complete, no PINGs would be needed would they?
Sure they would -- as part of the next control transfer. However until
that transfer begins (and the setup packet has been sent), the host
doesn't need to send a PING. There's no reason to do so; the device
can simply NAK the status stage until the data has been completely
processed.
> Show me that's a misreading of the spec, and I'll agree with you.
> Specifically, that "must" does not seem amenable to any kind of
> misreading. There's no precondition there; not even any kind of
> weasel-wording to support ignoring the "must"-PING sentence.
I agree about the meaning of "must"; the question is: must do what? I
claim the intention of the spec is that the host must send a PING before
starting another OUT/DATA transaction. You seem to think it means the
host must send a PING before starting the IN/DATA transaction for the
status stage. I don't see how we can determine what the authors of the
spec really had in mind other than by asking them... but my interpretation
makes more sense.
It's possible that the net2280 designers used your approach. But I don't
think so; Vikram's workaround wouldn't have fixed the problem if that were
true.
> If your proposed patch helps -- ISTR being puzzled by the preceding
> changes in that area -- that's fine. But I'll still think the spec
> views that packet sequence (PINGs omitted) as an error, and that this
> just works around a host side issue.
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.
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
