On Fri, 11 Oct 2002, Johannes Erdfelt wrote: >On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote: >> Hi all. Finally got time to work on this...so, this patch is rather >> large, but it (almost) all needs to happen at once. So, I'll list >> essentially what all the changes are, not necessarily in order. I have >> tested control and interrupt queueing, but not bulk (no bulk devices on >> hand...), so if people could test out bulk (and isochronous, although >> that's not really changed) it would be great. >> Note that any drivers who previously expected the HCD to automatically >> resubmit interrupt URBs will not work anymore!! > >I have all of those devices.
yep, that's the major problem with removing interrupt queueing...but it should happen at some point... If noone's looked yet, I can look through the current drivers for any that use interrupt URBs and try to create a patch fixing them all. Of course it also means that ohci and ehci need to remove their interrupt resubmission too... > >> -for places where a td->link was written, added check to make sure HC >> hadn't already wrote that td->link back to the td's qh->element. > >This sounds racy. I think it actually fixes a race. There are only 2 places, in in uhci_append_queued_urb and uhci_delete_queued_urb. My mental picture of the race is this: QH1 -(element)-> TD -> <whatever...QH or TERM> So, let's say the HC is currently processing the TD. It finishes, reads TD->link, and writes it back into QH->element. Then, TD->link is updated by the HCD. But, TD is already out of the frame list! So whatever was put there really should be in QH->element, and whatever's in QH->element shouldn't be there. You can check the 2 places (which do essentially the same thing) in the patch to see if you agree. They both have a comment "If the HC..." >> -changed lowspeed control TDs from depth to breadth. > >Why for? This will guarantee that it will take (# of TD's * 1 ms) time >to complete. Well, mainly to make the code common...but also, making it depth opens the possibility (for a large transfer) of hogging the bus, and, will most lowspeed devices really be able to send more than 1 packet per frame? Anyway I can change it back, or Greg can update the patch. >I agree. It doesn't make sense so we'll just assume the same interval. >We should document this somewhere in the URB/USB docs. I think the docs need updating for the interrupt resubmission change too, so both changes can be made at once... >> -added FIXME to uhci_delete_queued_urb to indicate killing an active URB >> may confuse the device, especially for control transfers, if some data has >> already beed transferred. I'm pretty sure this assumption is correct...? > >Yes. The device will expect the rest of the DATA phase and the STATUS >phase. > >Maybe the correct thing to do here is always do the STATUS phase and let >the device bitch that it wasn't valid? Yeah, this on is tricky...probably some devices would stall the pipe if the control (or other type) was aborted mid-transfer... -- Dan Streetman [EMAIL PROTECTED] --------------------- 186,272 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- 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
