USB2 patches
Hans Petter Selasky
hselasky at c2i.net
Sun Feb 1 12:57:48 PST 2009
Hi Andrew,
> >
> > This is not correct. The queuing mechanism in USB2 guarantees that the
> > last queued command is last executed:
>
> There are a few options,
>
> - coalesce on a single task (on,off,on = on), the off never happened.
> - drain the task first then resubmit
>
> Those cover both scenarios, (1) you dont care about previous state or
> (2) you do care so ensure the previous state has executed.
>
"2" is not an option. MPSAFETTY cannot sleep! And there is no IOCTL to drain
the DTR command, if I'm not mistaken.
> If for some reason those are not sufficient then the driver is free to
> implement its own queue.
We don't want per-driver queues. We want one queue mechanism for USB.
Like I've pointed out, last queued is last executed is a good requirement. For
simple things like DTR, sure you could coalesque state changes, but again,
that is not optimal, because it is unpredictable. Also see my other e-mail
with same subject to Warner.
It's like with queues. There is SLIST, LIST, TAILQ, STAILQ. Different need
needs different macro. The same should be the case with taskqueues.
I have looked at the internals of the taskqueue and the only reordering
mechanism is a priority mechanism. To some extent my implementation is about
dynamic and efficient priority re-ordering of messages. The
taskqueue_enqueue() can have a complexity of X squared, X*X, given the
iteration accross the messages already queued, in some cases. Mine has a
complexity of 1.
What do you think? Is it impossible to add another queue function to the
taskqueue system?
> The current implementation in usb is quite
> clever but its important not to complicate the internals for situations
> that dont happen in real life.
I would argue that the taskqueue approach is too simple for USB.
--HPS
More information about the freebsd-usb
mailing list