> > > The first question is not specific to sl811 hcd: for periodic > > > transfer, does a urb must be resubmitted by the function driver after > > > its transfer completion is called or is it handled by the hcd/core ? > > > > There is no "automagic resubmit" in 2.6 kernels; drivers reissue URBs > > themselves, if that's what they want. (And they handle any errors > > themselves, rather than having usbcore or the hcd ignore them.) > > > > but what happen if you get a NAK on a interrupt transaction ? Should > it be "automagically" rescheduled on the next period ?
Since the NAK prevented the transaction from completing, it'll never be reported to the device driver as completed, and thus it will never get descheduled. (Until later when it completes, either successfully or with some sort of error. NAK is *NOT* an error case.) > In general how > NAKed transactions are managed ? They seem to be retried forever > whatever the transfer type...Is it the hardware that is clever enough > to handle them ? They're retried until they either succeed or report an error. The "sl811-hcd" driver necessarily retries them in software, but more typically the retries are done in hardware ... hardware that reads the schedule directly, with DMA, and doesn't bother the host CPU until one (or more) transactions completes. > > > The second question is specific to sl811: periodic deschedules appear > > > in "finish_request" function. I don't understand the conditions needed > > > to start the periodic deschedule process. Does it happen when no more > > > transfer is pending for the current frame ? > > > > If the periodic endpoint in question has an empty transfer queue when the > > completion function returns, there's no point in leaving that endpoint in > > the schedule ... so it gets descheduled. After all, there'd be no point > > in leaving that part of the schedule reserved, if the driver stops using > > the slot which was temporarily reserved for it. > > hmm, let say "sl811_urb_enqueue" is called with a periodic URB as > parameter. The function schedules the new periodic transfer and > reserved a bandwith for each frame where the transfer may occur (true ?). Sort of true. The thing that's scheduled is an endpoint though. If there's only one transfer queued on that endpoint, you're right. If there's already a transfer queued to it, no scheduling is done since the endpoint is already scheduled. The transfers complete in FIFO order. > Then once the transfer is finished, "finish_request" is called. > This function calls "usb_hcd_giveback_urb" which can reschedulled the > interrupt transfer for the next period. No ... the device driver can "resubmit" the URB, through usbcore to the HCD. There's no "rescheduling" done; that endpoint (re)uses the same schedule slot until it gets descheduled because its queue is empty. (That descheduling might happen after giveback returns.) > But the first interrupt > transfer hasn't released its reserved bandwitdh and it won't until the > periodic endpoint has an empty transfer queue. Is it correct ? Again, _transfers_ don't reserve bandwidth, endpoints do. And when the endpoint's transfer queue is empty, it surrenders its bandwidth reservation. - Dave ------------------------------------------------------- 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
