Date: Sun, 1 Feb 2009 11:58:59 -0800 From: Andrew Thompson <thompsa@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB2 patches Message-ID: <20090201195859.GH32503@citylink.fud.org.nz> In-Reply-To: <200902012031.56899.hselasky@c2i.net> References: <200902011220.18745.hselasky@c2i.net> <200902012001.06914.hselasky@c2i.net> <20090201191432.GD32503@citylink.fud.org.nz> <200902012031.56899.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 01, 2009 at 08:31:55PM +0100, Hans Petter Selasky wrote:
> On Sunday 01 February 2009, Andrew Thompson wrote:
> > On Sun, Feb 01, 2009 at 08:01:05PM +0100, Hans Petter Selasky wrote:
> > > Hi Andrew,
> > >
> > > Regarding using taskqueues.
> > >
> > > Yes - USB2 can use taskqueues, but I would very much like to have the
> > > original queueing mechanism intact.
> >
> > Can you explain this further? What is t0 vs t1?
> >
> > A taskqueue will execute tasks sequentially,
>
> Hi Andrew,
>
> I've looked in the taskqueue code:
>
> if (task->ta_pending) {
> task->ta_pending++;
> TQ_UNLOCK(queue);
> return 0;
> }
>
> Take the following for example. Now you changed it a little bit, but I see
> similar issues where other commands are involved:
>
> 1) queue DTR on cmd
> 2) queue DTR off cmd
> 3) queue DTR on cmd
>
> Using the taskqueue there is no guarantee that the last command queued is the
> last command executed! That is dangerous! Because the existing taskqueue
> enqueue will only increment the pending count and return, if the command/task
> is already queued.
>
> In the example above you can end up like this:
>
> DTR on (pending = 2)
> DTR off (pending = 1)
>
> 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.
If for some reason those are not sufficient then the driver is free to
implement its own queue. The current implementation in usb is quite
clever but its important not to complicate the internals for situations
that dont happen in real life.
Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090201195859.GH32503>