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

> -----Original Message-----
> From: David Brownell [mailto:[email protected]]
> Sent: Thursday, March 29, 2007 4:38 AM
> To: Alan Stern
> Cc: Pandita, Vikram; USB development list;
[email protected]
> Subject: Re: [linux-usb-devel] Scenario: usbtest test-14 failure:
MUSBHDRC
> + Netchip2280
> 
> > > > > > > (**) 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.


 The discussion on PING should be based on the Spec Errata -
errata-092800-1207001.pdf, as the figure 8-27 is wrong in the 2.0 sepc: 
Section Incorrect Figure 8-27 (Host High-speed Bulk OUT/Control Ping
State Machine): Page 8.

>From this figure, the PING is related to: 
OUT, SETUP (Do_token1 --> Do_data1)

The confusion is: 
if there is NYET response from a device to a PING, then should the HOST
interpret that as :
a) next OUT cannot be sent yet or 
b) the device is not in a ready state and so keep Pinging till ACK and
then start next transaction

>From the corrected figure 8-27 it is clear that SETUP can still be sent
irrespective of the PING state of the device. So (a) could be the right
interpretation.





> > >
> > > 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,
> 
> Disagree.  It says explicitly that it "must" return to PING.  It does
> not create an exception like the one you ascribe to that text.
> 
> (Note by the way that "wMaxPacketSize" is superfluous.  If it's ready
> for any data at all, it's ready for that much.)
> 
> 
> > 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.
> 
> 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.
> 
> 
> > 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...
> 
> 
> > 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.
> 
> For example, trusting that the FIFO empties before control IN/STATUS
> packets start to arrive.
> 
> 
> > > > 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...".
> 
> 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.  (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 ...)
> 
> 
> > > 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?
> 
> The text seems clear to me:  must PING until the endpoint has space.
> 
> 
> > 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.
> 
> 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.
> 
> 
> > You seem to think it means the host must send a PING
> 
> Period, no matter what, since that's clearly what the spec says.
> 
> 
> > 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.
> 
> See above.
> 
> 
> > 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?  :)
> 
> Or alternatively, some of the recent net2280 patches broke some of
> the more subtle race-avoidance logic in that driver.  As I mentioned,
> I saw something rather fishy go flying by at one point; and that
> particular conditional does look fishy lately.
> 
> - 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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel