On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>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.
I was talking more about reserving the bandwidth and also enforcing
reservations to make sure we don't oversubscribe the bus.
Not to do any intelligent scheduling of transfers (although I can't see
how this information can be used to schedule "better" anyway)
> 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?
devel:~/kernel/usb-2.5% grep usb_calc_bandwidth drivers/usb/**/*.[ch]
include/linux/usb.h
devel:~/kernel/usb-2.5%
I don't see that at all.
> > 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.
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.
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.
I also don't see why this information is needed by the HCD's at all.
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
