Greg KH wrote: > On Sat, Jul 20, 2002 at 06:15:46PM -0700, David Brownell wrote: > >>Part 1: >> >> - HCDs remove special (a) "can't queue" and (b) "only one packet" >> limitations for interrupt transfers (*) > > > Is this _really_ needed? Do any drivers do anything special right now > to work around this? If this is a limitation of UHCI hardware, I don't > think it's worth the extra effort and code to queue these in the host > controller, when no drivers want this right now.
Yes. For "only one packet", I think many folk using INTERRRUPT-OUT work around it. And not that I've spent time with HID, but I understand that multi-packet reports are possible there too ... both directions. This is the guts of why INTR-OUT transfers are painful today. Writing a 73 byte report takes N fullsize and one short packet. Using the one packet model, that's simple enough with queuing; or using bigger writes, the queueing might not be needed. And so on; arbitrary restrictions just making things complicated. Someone once reported they weren't getting 1/msec interrupt transfers in some setup (ISTR), and the generic fix for that is ensuring that the hardware can have a queue to munch on while the host CPU is tied up. It's not a UHCI limitation as near as I can tell. The spec even talks about interrupt TDs living in a QH, and the "breadth first" mode seems designed for this particular usage. >>Part 2: >> >> - HCDs remove (c) automagic resubmit >> - USB device drivers updated to not rely on it (including usbfs) > > > This is something I see as needed, but does "Part 1" really have to > happen before this is done? I don't remember such a dependency, though it might be smoother for some driver updates to sequence it one way or another. If nothing else it's how I'm thinking of staging this stuff. >>I suspect that the best solution here is not to completely remove >>this capability, but just define a new transfer flag to explicitly >>disable the automagic resubmit. > > > No. Let's rip it out. Make the driver do the resubmit, just like they > have to do for bulk urbs. No special cases or flags needed. Nicer for sure, but unmodified drivers will have silent failures. I suppose that'll show ... somebody something! :) >>Note that this doesn't address the SL-811 and CRIS host controller >>drivers, both of which are in the 2.5 tree. I've cc'd the author >>of the SL-811 code; there's no email address on the CRIS code. >>Or any of the various host controller drivers that aren't living in >>any of the standard Linux kernel trees. > > > If it isn't in the kernel tree, don't worry about it :) OK. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
