Hello Alan! On Thursday 10 February 2005 22:12, Alan Stern wrote: > On Thu, 10 Feb 2005, Wolfgang Mües wrote: > > My driver (auerswald) tries so send more than one URB to ep0 at a > > time! But - I have learned that this does not work reliable, > > especially with the UHCI hardware. This is mostly because of two > > facts: > > > > a) If there is a spike on the line, the retry mechanism of the host > > controler is so fast that the retry has no effect - the spike is > > much longer than the time needed for the 3 retries. > > This will be true for bulk endpoints as well as for ep0. But maybe > you don't care so much about losing bulk data...
Actualy, my driver doesn't do any bulk data...;-) > > So I think we will get a more reliable solution if the host > > controler will get only one control URB at a time, with retries = > > 0, and a timeout logik in software in the core. > > Do you think we should allow bulk URBs with retries = 0? If the HC hardware retry logik is "rotten", yes, then the fix belongs to the HC driver, I think. > Should > there be a change to usbcore's API allowing drivers to specify > unlimited retries for their URBs? No. It should be handled inside the HC driver. Think about it: will a driver who submits an URB ever expect that the host controler _dont_ do its very best? The UHCI controler does 3 tries in hardware. I have made some tests and found that sometimes about 8 x 3 tries were neccessary until the paket could be sent. So there seem to be a large gap between the ability of the host controler and the duration of spikes on the USB lines. > Or maybe only for control URBs? > Or should every non-iso URB always have unlimited retries? Control: yes Bulk: yes Interrupt: yes ISO: obviously not usefull. > Drivers _can_ stop and restart a queue; it happens every time you > unlink an URB or an URB terminates with an error. (Okay, UHCI > doesn't do this correctly when you unlink an URB, but it's going to > be fixed eventually.) But this is not a function of the API. It is only by implementation. Do you want to code a driver against such a weak fact? > Inserting an URB at the front of a stopped queue is a luxury. You > can live without it, by unlinking everything from the queue first. ... except for endpoint 0. I don't know all URBs... Alan, you are right. Beside from ep0, it is a luxury. I think, the best location for a comfortable queue handling will be the USB core. > Besides, aren't you going to want to decide how to proceed based on > the result of the URB inserted at the front? But you can't get a > result without restarting the queue, and once it's restarted the > queue won't stop after handling just that one URB. That's not what > you want. Right. So I want to stop the queue, send another URB, examine the result and restart the queue again. > > Another lacking feature is un-stalling an > > endpoint from inside the callback function.... before we can > > attempt to retry the packet.... > > There's nothing unique to USB about this. No interrupt-time code is > allowed to block or sleep, ever. Please explain?!? Do you refer to the fact that un-stalling an endpoint is a blocking function? Yes, exactly _this_ is the problem. There should be some sort of asynchronous endpoint clear also... Why have I mentioned it here? Because some devices do a STALL if they receive garbage, and you have to un-stall the endpoint before you can retry the URB.... Talking about STALLs... I assume that every driver knows 100% about the command structure of the USB device. So a "protocol stall" (because of a malformated command) will not happen in practice. (And if: how should the driver cope with this? Anyway, he doesn't know better!). So STALLs do happen because of communication errors.... maybe it's the best if USB core does an automatic unstall command here? Device drivers are many. Host controler drivers are many. USB core is one. So where to put the reliability in? > > IMHO it is OK to unlink all URBs of an endpoint at once (but not > > for ep0), but this function should not be called unlink_urb() any > > more... > > Well, the whole point of doing this is that HCDs would no longer have > to unlink individual URBs. Otherwise there's no real reason for it. > So if the function isn't called unlink_urb any more then there > wouldn't _be_ an unlink_urb, and we would have to change every USB > driver. That's why I mentioned putting off API changes until 2.7. > The nice thing about my suggestion is that it can be implemented now, > without breaking anything. How about int unlink_all(....); #define unlink_urb() unlink_all() // not recommended for new designs But I think that unlink_urb() can't omitted for ep0. What if a driver is removed from memory? best regards Wolfgang Muees ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
