Date: Tue, 28 Dec 2004 11:19:12 -0800 From: Julian Elischer <julian@elischer.org> To: hselasky@c2i.net Cc: freebsd-usb@freebsd.org Subject: Re: USB vendore designations.. Message-ID: <41D1B1B0.8070003@elischer.org> In-Reply-To: <200412282004.16958.hselasky@c2i.net> References: <41CB38A7.5020700@vicor.com> <200412271242.43441.hselasky@c2i.net> <41D08EEF.50807@elischer.org> <200412282004.16958.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote: >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? > that's what I'm doing now in my test code.. iI'll check it in today maybe. > >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. > > yes, but why break it as a possibility? :-) > >Yours >--HPS >_______________________________________________ >freebsd-usb@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-usb >To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41D1B1B0.8070003>