>>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
