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.
Think about how it works with queueing.  The "cost" is stored
per-endpoint (modulo one optimization) which is where it needs
to be.  It doesn't matter how many urbs are queued ... the only
time bandwidth utilization changes is when an endpoint gets
added to (or removed from) the periodic schedule.  If the queue
length can only be one, it looks like the bandwidth is tied to
the urb, but otherwise ...

There's also the balancing issue.  In usbfs a single number is
shown, usec per frame.  But a 640 usec transfer that runs once
every 32msec is not going to cost 640 usecs (out of 900 usec max).
You can run 32 of them at a time, with bandwidth left over.  A better
solution is to report it as 640/32 = 20 usec.

But clearly "20" can't be used to make scheduling decisions, since
it's just an average.   In that scenario only 260 usecs is left
for every-frame transfers, not 880 usecs.  Use all that, and your
average becomes 260+20 = 280 ... plenty of bandwidth available,
but you have ask for it with bigger periods.


The uhci-hcd code isn't currently using per-endpoint data structures,
except maybe the ring of urb_priv queued to it.  That'll make some
per-endpoint reasoning look a bit odd.  But it could store a pointer
to one in its per-endpoint pointer, something like:

      unsigned       index = usb_pipeendpoint (urb->pipe);
      struct uhci_ep *ep;

      if (usb_pipein (urb->pipe) && !usb_pipecontrol (urb->pipe))
            index += 16;
      ep = ((struct hcd_dev *)usb_dev->hcpriv)->ep[index];

Or maybe just store the last urb_priv from the ring.  (I'd sort of
like to see a real "head of list" so it's more natural to use the
list primitives, like list_for_each_entry ...)



Perhaps you should have fixed the code he wrote?
I certainly thought about that for a good amount of time before
fixing that code in this particular way.

- Dave

p.s. Re "I started out thinking that way ... then I got better."
     From Monty Python and the Holy Grail: "But I thought you were
     dead!" "I got better."





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