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

I don't see how your code is different in this respect.

> and couldn't access per-frame bandwidth information.
> Even for USB 1.1 scheduling, they got in the way.

Perhaps you should have fixed the code he wrote?

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

Gotcha, so there were problems with that code.

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

Got better?

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