> > bulk is the same as "one-shot interrupt" with the only exception being > > interrupt is earlier in the frame than bulk, so interrupt is > > "guaranteed" to happen while bulk is not (on a heavily loaded bus).
Well, sort of. There's also a restriction that interrupt transfers involve only one packet every N frames (or microframes), while bulk can max out each frame (or microframe) in terms of packets sent. Interrupt (and ISO) transfers are scheduled in advance, that's where the guarantee comes from ... both types of "periodic" transfer use bandwidth that's reserved for it. Host controller drivers schedule those transfers into that bandwidth. And inside USB devices, the "target" drivers may depend on that scheduling. The "asynchronous" transfers (bulk and control) just squeeze in after everything else, in no particular priority, as space allows. They can happen later, or sooner, depending on bandwidth available But yes, "on the wire" if you're only looking at single packets, that'd be the most you would likely notice. The difference becomes apparent with the second packet. > Ok, that explains why it works.. most of the time. Note - I've never > had it fail, but if it does, now I know why! It likely fails all the time, but in ways you may not be able to detect: interrupt transfers executed as bulk won't transfer at most one packet every N frames. > I just wish ohci/uhci/??? all did the same thing when it comes to > interrupt URB's. (both in and out). There's also an issue of doing something close to right ... :) IMO this is best addressed by fixing the URB model so that there are a lot fewer special cases. For one example, interrupt IN and interrupt OUT transfers really have two different models today... there should be just one. (And for that matter, the model should be a natural match for inside USB devices -- "targets" -- not just for USB hosts.) My preferred fix is that 2.5 should get rid of all automagic resubmission. It's a set of error-prone special cases, none of which are really necessary and all of which complicate the code more than they simplify things. Simpler just to have completion handlers re-queue URBs, if it's needed. (In effect, make _all_ interrupt transfers just be one-shot.) And stop singling out interrupt transfers as the only ones that are restricted to single packets (think about larger HID reports that take N packets :), and which can't be queued. All HCDs queue ISO, and bulk. (And most, except, UHCI, do so for control too.) Those are all policy questions that are better left as device driver choices than getting glued into core APIs. - Dave _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
