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.
I was talking more about reserving the bandwidth and also enforcing
reservations to make sure we don't oversubscribe the bus.
So was I. Both "enforcing" and "not oversubscribing" are decisions.
Uhh, looking at the OHCI code, why is it doing that stuff itself?
Why isn't it using the code that Randy developed?
But Randy did provide usb_calc_bus_time() ... it was exactly the
right primitive, once it learned something about high speed! :)
Not using those other calls because they were specific to URBs (not
endpoints), and couldn't access per-frame bandwidth information.
Even for USB 1.1 scheduling, they got in the way.
And then they were _seriously_ in the way when scheduling split
transactions. USB 1.1 scheduling is quite simple, once you get
down to it, unless you want to do funky things like rebalancing
schedule trees to make bigger chunks of bandwidth available.
I also don't see why this information is needed by the HCD's at all.
Which information are you talking about? Clearly HCDs need to know
what's on their schedules before they add or remove entries.
No, I'm talking about bandwidth information. They just process URB's.
The core should be enforcing bandwidth.
I started out thinking that way ... then I got better. :)
- 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
