Reservation should be on a per-endpoint basis, for both ISO and INTR transfer modes, if we try to follow the USB spec. Dan's change makes interrupt transfers work that way ... ISO should too.The tricky bit is that the usb_{claim,release}_bandwidth() calls work on urbs, not endpoints. So I think those calls need to vanish, and HCDs need to switch to more precise math.Exactly. The question now is where should we do that? The current API is specific to URB's so it won't be as easy as just moving the calls to urb_submit_urb or something.
What OHCI does is just update the bandwidth utilization fields directly. Those fields are exported only for viewing in "usbfs", and aren't used for making any scheduling decisions. You may not have noticed, but now usb_calc_bandwidth() is exported to HCDs ... the other math is specific to how a given HCD arranges its periodic transfer schedule, and how hardware (like TTs in usb 2.0 hubs) constrains that schedule.
Maybe we should update usb_submit_urb to ensure that the driver has allocated bandwidth before we accept the URB? This will ensure that all drivers are compliant at the expense of modifying every driver that does asynchronous URB's.
Make that "periodic" urbs ... :) I went back and forth on this a bit, and at this point I really don't see a good way to do this except inside the HCDs as part of queueing an urb to the HC. It's too messy to try abstracting it; there is lots of HC-specific state that should stay available only to the HCD. Of course we _could_ do it inside HCDs when setting configurations or altsettings, given new HCD hooks, but that doesn't seem to be required. - 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
