I _really_ like usb-ohci's behavior, and I wish usb-uhci/uhci behaved the same way. In particular, I think queueing INTs is essential. Allowing queueing (could) lead to not auto-resubmitting.
If INTs could be queued, there would not really even be a need to 'resubmit' the URBs. The completion handler can simply resubmit a completed URB (if desired) without any loss of data or polling time. This is really a good thing. Anyway, allowing queueing of INTs in the first place is very nice (and, if INTs are ever going to be correctly possible via usbdevfs/usbfs, I think a neccessity) If INTs do not auto-resubmit themselves, the 'problem' of how to handle INT-out is gone. No need to set a flag to -1, or add code to allow re-sizing of the buffer, etc. A INT-out will simply complete, and be done, like any other URB. Multiple INT-outs require multiple URBs (or resubmissions by the completion handler), just like any other URB. The polling will be correct, everyone is happy, etc... Removing special cases is a very nice thing, because special cases only cause headaches. So, if my opinion counts for anything, I would vote for (first) allow INT URBs to be queued and (second) remove URB auto-resubmission entirely. I realize this would require all drivers using INT to add a 'resubmit' call to their completion handlers (and probably submit 2 or more URBs, instead of only 1). But hey, we're in 2.5.x, this is the time to do stuff like this. And is the driver resubmitting really that much different from the HCD resubmitting? IMHO, it's better to have the option in the driver. And I know that not resubmitting is certainly the special case (99% of drivers will want to resubmit) but, putting it in the HCD (first) makes the HCD more complex, (second) removes the option from the driver - the driver must unlink in its completion handler, and last I checked at least one of the HCD will cause the URB to complete again, which just adds more responsibility to the driver to remember that this second completion should be ignored - and (third) causes the problem of how to handle INT-out transfers. And would it really be that hard to add INT queueing to usb-uhci and uhci? I haven't dived too deeply into the UHCI spec (so don't flame me ;) but can't you just put all ints for a specific ep on a QH? Anyway, that's my $.02 and change... On Mon, 25 Feb 2002, Roman Weissgaerber wrote: >David Brownell wrote: > >> >>GOAL: support INTR-OUT and INTR-IN transfers with >>one API model which could also be used for a device >>controller API using an URB-like model. >> >> >>CURRENT MODEL: all interrupt transfers are specified >>with using an URB with transfer_buffer_length set to a >>fixed packet size, and a fixed polling interval. Also, >>current host controller drivers say only one interrupt URB >>(usually of at most maxpacketsize) may be queued. >> >usb-ohci allows to queue interrupt URBs. If you want to keep a 1ms >interrupt endpoint bussy you have to queue interrupt URBs. > >The current model lacks the phase (or offset) of the polling interval. >Also for queued URBs the 'fixed' polling intervall could be changed >from URB to URB ( inconsistently). > >The model as I think it should be: > >For each interrupt endpoint there are scheduled time slots (offset and >interval) >for the transfer of data. This is a property of the endpoint and should >be defined >by 'set interface' >(needs a new API (set_endpoint_properties) call for HCDs because >at least ohci would benefit of static endpoint properties). >Now, at a scheduled time slot if there is a queued URB it will be >transfered - >if there is no queued URB then there is no transfer. > >The resubmition of the URBs is a different story but maybe we should >define a consistent way of resubmition for all kinds of transfers. >Also during the callback the URB is owned by the device driver so >length and databuffer can be changed. > >- Roman > > > > > >_______________________________________________ >[EMAIL PROTECTED] >To unsubscribe, use the last form field at: >https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > -- Dan Streetman [EMAIL PROTECTED] -------------------------------------------------- 186,282 miles per second: It isn't just a good idea, it's the law! _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
