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.
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.
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.
usb_calc_bandwidth?
I meant "usb_calc_bus_time()" in "hcd.h", sorry.
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.
I don't think that's reasonable. Not all drivers set the configuration
or the altsettings and just use the default ones because they are the
only ones. Many drivers do it specifically because devices aren't
required to support those operations when you don't have more than one.
All drivers using isochronous transfers _must_ set an altsetting,
since it's illegal for a default config to have ISO endpoints.
That's part of the USB spec.
So what I described is completely reasonable according to that spec,
which was written assuming that some USB APIs (MSFT?) will reserve
bandwidth when any altsetting is established ... including the
default config (and the default interface settings).
This should be specifically done at use. For instance when an
application opens /dev/video0 for the CPiA camera, it should reserve the
bandwidth once and then release it when it's done.
Today that's done as a consequence of starting an ISO stream ... that
model works fine, no API changes are needed. As I said, "not required"
to change models for device drivers or HCDs, so long as the HCD doesn't
violate basic scheduling requirements.
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.
- 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
