Date: Tue, 28 Dec 2004 20:04:16 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Julian Elischer <julian@elischer.org> Cc: freebsd-usb@freebsd.org Subject: Re: USB vendore designations.. Message-ID: <200412282004.16958.hselasky@c2i.net> In-Reply-To: <41D08EEF.50807@elischer.org> References: <41CB38A7.5020700@vicor.com> <200412271242.43441.hselasky@c2i.net> <41D08EEF.50807@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 27 December 2004 23:38, Julian Elischer wrote: > Hans Petter Selasky wrote: > >On Monday 27 December 2004 08:15, Julian Elischer wrote: > >>Now, when you do the "doobell trick" as descibed in the spec, > >>there is one little part of it.. that is the catch. > >> > >>The spec says: > >>"Software should first deactivate all active qTDs, wait for the > >>queue head to go inactive, then remove the queue head from > >>the asynchronous list." > >> > >>Note the word "all" > >> > >>Ok, so since we want to remove only SOME of the qTDs from the queue > >>(those corresponding to the aborting command), and we need to read > >>the status word to see which has been completed by whether the > >>active bit is set, and since we are in a race with the hardware > >>to clear the active bit, which of the qTDs, not in the list of > >>qTDs we want to remove, was completed? > > > >Maybe the EHCI driver should not reuse the QH's for transfers on the same > >pipe, but instead like I did, have one QH for each transfer, insterted > > into the asynchronous schedule after that the last QH has been removed? > > It's an interesting idea.. > > where did you do this? In a new driver? > Yes, the one I posted earlier this year: Create a new directory and download the following files and type "make install" (to uninstall type "make deinstall") http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 > > > It has the good point of being "clean" > It has the bad point of only allowing one transaction per interrupt cycle. Thats the way UHCI driver is currently doing it. Transfer more data at a time, and the loss will be less. How about removing the QH from the asynchronous schedule, before removing the TD's and then insert the QH back into the asynchronous schedule? Very few drivers start more than one transfer at an asynchronous pipe at a time, so most of the time there will be a short delay between transfers anyway. Yours --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412282004.16958.hselasky>