On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>>>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.

Uhh, looking at the OHCI code, why is it doing that stuff itself?

Why isn't it using the code that Randy developed?

> >>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.

Yes, that's correct. I forgot that.

> 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).

But isochronous isn't the only transfer that needs to reserve bandwidth.

Interrupts do as well.

> > 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.

Actually, it's done for every URB. Not only is all of that math
unncessary. It can cause a case where in between freeing the bandwidth
and allocating it again, someone else comes and grabs it.

It's a misnomer to call it "reserving" if someone can steal it from you.

> > 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.

The only reason we have the HCD's do it right now is that the core isn't
in the finish path for the URB (except for an explicit unlink). The
completion handler bypasses the core.

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

Reply via email to