>>Ok, no more arguing, let's see some code, and then we can discuss >>concrete things like that. > > > Implementation isn't the source of contention. It's the overall > architecture of how bandwidth reservation will work.
There is one issue masquerading as an implementation issue, namely whether it's technically possible to have an HCD implement the bandwidth reservation model used by the current API: once you successfully submit an URB to a periodic endpoint, you've reserved the bandwidth needed to keep streaming data to that endpoint, so nobody else can use that bandwidth. Since the current OHCI code implements that, the only code I'd be likely to submit there is a patch to remove the old urb-centric infrastructure. Maybe later after this calms down (and ehci-sched.c resolves the FIXME around its remaining claim_bandwidth call). The question related to architecture is whether there needs to be another reservation mode, where usb's reserved bandwidth would be allocated in preparation for future use (not just for current use). That'd be doable, but I don't see any value in it at this time. Plus, I rather suspect that'd be the tip of an iceberg in terms of similar issues ... like allocating TD memory in advance, querying schedules for capacity (and with USB 2.0 TTs, specific kinds of capacity), and more. Maybe for 2.7 (or 3.1), I'd say. - 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
