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. > -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. > -moved uhci_find_urb_ep, no code change. > > -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. > -move bandwidth reservation into submit_interrupt and submit_isochronous. > Reserve bandwidth at start of submit_iso, and release on error. Reserve > at end of submit_common (for int only, not bulk). For interrupt, only > reserve if the URB is the first (i.e. not queued). Only release if the > URB is the last (i.e. no more queued). Good point. We should also (in another thread) discuss how we're going to fix bandwidth reservation in the long run. > -For all (control, interrupt, bulk) if URB is queued, do not place > directly onto skelqh - place onto active URB's queue. This is fine for > control and bulk, but for interrupt a side effect is the interval is only > checked for the first URB - if later URBs (on that same endpoint) have a > different interval, it's ignored and the new URB stays on the orginal > interval. this should be ok, since it doesn't really make sense to queue > URBs with different intervals in the same endpoint/pipe. 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. > -fix bug of using different names for create and remove driverfs > entry. That wasn't me! :) > -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? Anyway, I'll test this out ASAP. JE ------------------------------------------------------- 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
