From owner-freebsd-usb@FreeBSD.ORG Tue Dec 28 19:03:55 2004 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A17F16A4CE for ; Tue, 28 Dec 2004 19:03:55 +0000 (GMT) Received: from mailfe09.swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EF0943D5A for ; Tue, 28 Dec 2004 19:03:54 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== Received: from mp-216-36-122.daxnet.no ([193.216.36.122] verified) by mailfe09.swip.net (CommuniGate Pro SMTP 4.2.7) with ESMTP id 51979310; Tue, 28 Dec 2004 20:03:16 +0100 From: Hans Petter Selasky To: Julian Elischer Date: Tue, 28 Dec 2004 20:04:16 +0100 User-Agent: KMail/1.7 References: <41CB38A7.5020700@vicor.com> <200412271242.43441.hselasky@c2i.net> <41D08EEF.50807@elischer.org> In-Reply-To: <41D08EEF.50807@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412282004.16958.hselasky@c2i.net> cc: freebsd-usb@freebsd.org Subject: Re: USB vendore designations.. X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hselasky@c2i.net List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 19:03:55 -0000 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