I agree with you, but the fact remains that the only way to talk to an interrupt endpoint via usbdevfs is either with Bulk URBs or a "one-shot" (i.e. zero-interval) Interrupt URB. And I think Duncan originally asked about what URB type(s) could be used to talk to an Interrupt endpoint.
I hope (as you do) that it will be fixed. On Tue, 25 Jun 2002, David Brownell wrote: >>>E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=50ms >>> >>>Does this mean that an urb for this endpoint must be of >>>interrupt type? >> >> No, you could use an interrupt or bulk URB. > >I wouldn't rely on that, actually. As the USB stack becomes >more mature it's likely to report such things as the errors >they are. > > >> Bulk and Interrupt use the same format (a single data buffer). >For BULK and INTR transfers, the on-wire format for each packet is >the same ... but INTR is guaranteed exactly one packet each fmInterval >(except high bandwidth mode, for highspeed devices, which can do 3KB >per microframe) while BULK can transfer more (fill any frame) or less >(probably not starving, but ...) > >And in the URB API, INTR has a "one-packet-at-a-time" restriction to >match that on-the-wire model. > > >> So really only Bulk URBs can be used on INT endpoints, and vice versa. >> It's not terribly useful to poll a Bulk endpoint with a Interrupt URB >> (since you'd transfer rather slowly) so it winds up the only >> useful cross-use is just Bulk URB to Interrupt endpoint. > >But they're really not correct substitutes for each other, since >BULK transfers violate the service guarantees that are the reason >devices use the INTR endpoint model. > > >> This is useful since Bulk does not use automatic resubmission. >> usbdevfs can't handle auto-resubmit, so to talk to an interrupt >> endpoint via usbdevfs you need to use either Bulk URBs or a "one-shot" >> interrupt URB. > >Or a bugfix to the interrupt transfer model, which I hope to see in >the 2.5 series ... after we get rid of one of the UHCI drivers! :) > > >> "one-shot" interrupt is the exact same as bulk except interrupt is >> scheduled earlier in each USB frame (interrupt has guaranteed >> bandwidth) while bulk is scheduled last in each USB frame (bulk has no >> guarantee). So under heavy bus load (i.e. over 100%) some of the bulk >> polls will be skipped. > >Note that you're describing UHCI-specific behaviors, like "one-shot" >API support (which drivers should care about) and "CONTROL/BULK-last" >scheduling policy (which they shouldn't). > >Unless bandwidth reservation (in the HCDs) isn't working correctly, >it doesn't matter when such the non-periodic transfers (up to 90% >of full/low speed bandwidth, 80% of high speed) are done, since the >basic point remains: Since they don't have reserved slots in the >transfer schedule, they can be almost arbitrarily delayed. Devices >use interrupt transfer types to have service guarantees, and to >avoid hammering the bus with polling with IN/NAK transfer failures. > > >> Also a >> second difference is bulk can be queued and interrupt cannot, at least >> not on UHCI (yet). > >Nobody queues interrupt transfers yet, but I think the appropriate fix >to the interrupt transfer model involves changing that. > > >> Both bulk and 1-shot interrupt poll very fast (I've traced up to 1 >> poll per 16 microsec on USB 1.1) so if you want to slow that down (the >> USB 1.1 spec states you shouldn't poll an interrupt endpoint faster >> than 1 poll per millisec) then turn on USB_NO_FSBR to slow the polling >> to 1 per ms. > >That UHCI-only flag doesn't necessarily take effect unless _all_ pending >control and bulk URBs enable it, I seem to recall. > >In any case, such a flagrant violation of the USB spec is a good reason >to avoid using those UHCI-only "one shot interrupt" requests. > >- Dave > > > > > > > >------------------------------------------------------- >This sf.net email is sponsored by: Jabber Inc. >Don't miss the IM event of the season | Special offer for OSDN members! >JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn >_______________________________________________ >[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! ------------------------------------------------------- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
