2005/9/6, Alan Stern <[EMAIL PROTECTED]>:
> On Mon, 5 Sep 2005, Franck wrote:
>
> > 2005/9/5, Alan Stern <[EMAIL PROTECTED]>:
> > > On Mon, 5 Sep 2005, Franck wrote:
> > >
> > > > > And NAK response to an interrupt transfer definitely _should_ be
> > > > > retried,
> > > > > at the next interrupt period.
> > > >
> > > > ok so I definetly can't use this feature for interrupt polling and
> > > > isoc transfer.
> > >
> > > I don't understand. How does the feature work, and why can't you use it?
> > >
> >
> > well, the feature allows the hardware to automatically restart a
> > transaction when the function previously handshaked it with a NAK. If
> > the function is a hub and the transaction is used to poll its endpoint
> > 1...the hub will send NAK as long as there's no change on its ports.
> > Therefore the hardware will be busy to restart the transaction until
> > there's a change on the hub's ports...That's why I said that I could
> > not use this feature for interrupt polling.
>
> But _when_ does the hardware restart the transaction? Does it restart
> right away? Does it try to do all the remaining transactions for this
> frame and then restart? Does it wait until the next frame? Or does it
> wait until the next interrupt period (if this is an interrupt
> transaction)?
>
seems to be rigth away...from the shitty documentation :
"When this bit is cleared NAKed transactions will be retried in hardware"
As you see, it's quite short for an explanation. I expect that it will
retry transaction until the next frame because I could stop the
transaction during the "start of frame" interrupt.
> And if it restarts right away, how many times does it restart? If the
> device keeps sending NAK, will the hardware continue to restart the
> transaction until it reaches the end of the frame, without trying any of
> the other transactions remaining in the frame? (Note that this would
> violate the USB protocol, making the restart feature pretty useless.)
>
yeah, that's why I said that it's pretty useless for periodic transfers....
>
> > When you say that I should just keep retrying until transfer completes
> > or unlinked. Does that mean I should start the next frame with the
> > NAKed transaction even if there are isoc transactions scheduled for
> > that frame ?
>
> No. You should start the next frame with whatever transaction is
> appropriate for the beginning of that frame. For instance, if you
> schedule iso and interrupt transfers before control and bulk, then you
> should start the next frame with its iso and interrupt transfers, even if
> a control or bulk transaction was NAKed during this frame.
>
> Here's how the UHCI driver works. Each frame has a list of endpoints with
> transactions scheduled. All the iso and interrupt endpoints come first on
> the list, followed by all the control endpoints and then all the bulk
> endpoints. The lists for different frames have different iso and
> interrupt endpoints, but all frames share the same control and bulk
> sublist.
>
> When a transaction completes successfully or with an error, it is removed
> from the list. If it fails to complete because the device sent a NAK, the
> transaction remains on the list. Then the controller will execute the
> transaction again the next time it goes through the list. If it's an
> interrupt transaction, that next time won't occur until the next interrupt
> period.
Is it the function driver that will resubmit the interrupt transaction
or is it automatically rescheduled by the hcd ?
> If it's a control or bulk transaction, that next time will occur
> as soon as the current list is finished if Full Speed Bandwidth
> Reclamation is turned on (because after reaching the end of the list, the
> controller goes back to the start of the control endpoints). If FSBR is
> turned off, that next time will occur in the next frame (because after
> reaching the end of the list, the controller stops).
>
Thanks a lot for that !
--
Franck
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
