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