On Tue, Feb 19, 2002 at 11:30:02AM -0800, David Brownell wrote: > > > And why there's that issue I mentioned (reported in Janary by > > > Wolfgang Mües) about changing the _length_ of an OUT transfer. > > > I've some comments I hope to send out, but can't do so much before > > > Wednesday. > > > > It would work if most of the time the interrupt OUT URB could have a > > transfer_length of 0 bytes of data, but I'm not surw which HCDs will > > choke on that. > > I'd think that it would be good to let INTR-OUT behave exactly like > INTR-IN, meaning that both (a) zero byte transfers should work, > and (b) if no data is ready, no transfer should happen. I'd expect > that (a) would be little/no problem, but (b) is an API model issue.
Yes, that way it would work. That is, if we can change the number of bytes to be output in a convenient way. > > > > As far as I know the only difference between one-shot out interrupt > > > > > > (which is a UHCI-ism :) > > > > But that's only a driver issue. I don't believe OHCI/EHCI in hardware > > wouldn't be able to implement oneshot interrupt transfers. I may be > > wrong here, though. > > It's also an API model issue. I think OHCI/EHCI could do them > too, but that wouldn't address all the API model issues. Like > (b) above, which might be addressed by a usb_modify_urb() > style approach to change INTR-OUT transfer sizes. > > > > Another factor is when the transfer happens ... if your device is > > > only able to handle data every 16 msec, you're not doing anyone > > > a favor by trying to send/recv it more often, it'll just choke. So use > > > interrupt transfers, not bulk transfers. > > > > If there is such a device, yes. > > I understand there are. It's a fairly typical approach when dealing > with limited processing resources: constrain peak loads. When > folk design "real-time" systems they often pre-allocate loads in > those ways. It'd be like ISO-OUT, but with better error handling. Ok. -- Vojtech Pavlik SuSE Labs _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
