From owner-freebsd-usb@FreeBSD.ORG Mon Nov 8 16:39:48 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 9DA4416A4CF for ; Mon, 8 Nov 2004 16:39:48 +0000 (GMT) Received: from mailfe09.swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61E7043D49 for ; Mon, 8 Nov 2004 16:39:47 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: 61HFGGjwdfd+y2VeAxKidw== Received: from [193.217.207.69] (HELO curly.tele2.no) by mailfe09.swip.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 10357293; Mon, 08 Nov 2004 17:39:36 +0100 Received: (from root@localhost) by curly.tele2.no (8.12.5/8.12.3) id iA8GiTWf001730; Mon, 8 Nov 2004 17:44:29 +0100 (CET) (envelope-from hselasky@c2i.net) Date: Mon, 8 Nov 2004 17:44:26 +0100 From: Hans Petter Selasky To: "M. Warner Losh" Message-ID: <20041108174425.A283@curly.tele2.no> References: <20041107194658.B466@curly.tele2.no> <20041107.130436.91313722.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20041107.130436.91313722.imp@bsdimp.com>; from imp@bsdimp.com on Sun, Nov 07, 2004 at 01:04:36PM -0700 cc: freebsd-usb@freebsd.org Subject: Re: new USB driver X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 16:39:48 -0000 On Sun, Nov 07, 2004 at 01:04:36PM -0700, M. Warner Losh wrote: > In message: <20041107194658.B466@curly.tele2.no> > Hans Petter Selasky writes: > : I wondered if I could have my new USB driver up for discussion? > > Sure. > > : What do you think about it? > > There seems to be a whole lot of changes swizzled into this new driver > that aren't documented in your mail. > Looking at ums.c shows huge > differences, for example. It mostly looks like there's about a month > of changes into current that just aren't present. this makes it hard > to diff and compare the drivers. > It is difficult to diff this USB driver with the existing one, because much code has been rewritten. A short introduction to my USB-setup sequence: (see the function usbd_do_request_flags() in the file _usb_transfer.c for an example) 1) usbd_transfer_setup() This routine sets up a list of usbd_xfer pointers. This routine takes basically three arguments: A usbd_device pointer, an iface index and a pointer to a structure of type usbd_config. This call is similar to usbd_open_pipe, except that all memory needed for the transfer, transfer buffer, TD's and QH's are allocated in one memory block. This reduce the amount of error handling code, hence there is only one place where memory allocation may fail. This ensures that all memory is freed when the transfer is done (unlike the current USB driver which never frees the TD's and QH's used). This optimizes the drivers, by enabling the drivers to write directly into the memory buffer being used for transfer. 2) usbd_start_transfer() 2) usbd_start_transfer() This function calls the callback which starts the transfer, if the transfer was not started. This function can be called more than one time without having the callback called twice for convenience. 3) usbd_stop_transfer() This function stops the transfer, and can be called even if usbd_start_transfer() was not previously called. usbd_start_transfer() can be called after that usbd_stop_transfer() has been called to re-start the transfer. If usbd_stop_transfer() is called when the transfer was started, the callback is called with ``xfer->error'' set to USBD_CANCELLED. 4) usbd_transfer_unsetup() This function unlinks TD's and QH's from the controllers memory and frees all memory. About the callbacks: * the USB-driver automatically recovers from errors if * ``xfer->clearstall_xfer'' is set * * Host-transmit callback example (bulk/interrupt/isochronous): * ============================================================ * static void * usb_callback_tx(struct usbd_xfer *xfer) * { * USBD_CHECK_STATUS(xfer); * * tr_transferred: * tr_setup: * * ... setup ``xfer->length'' ... * * ... write data to buffer ... * * tr_error: * * ... [re-]transfer ``xfer->buffer'' ... * * usbd_start_hardware(xfer); * return; * } * * Host-receive callback example (bulk/interrupt/isochronous): * =========================================================== * static void * usb_callback_rx(struct usbd_xfer *xfer) * { * USBD_CHECK_STATUS(xfer); * * tr_transferred: * * ... process data in buffer ... * * tr_setup: * * ... setup ``xfer->length'' ... * * tr_error: * * ... [re-]transfer ``xfer->buffer'' ... * * usbd_start_hardware(xfer); * return; * } The callback system handles recursation. It is possible to start/stop another xfer from a "callback". The callbacks are protected by the mutex pointed to by xfer->priv_mtx; All memory is allocated before transfer, and not during transfer. There are some more differences, but that will be details. My new USB driver is built upon the FreeBSD-5-current USB driver, but it is not fully compatible with it. So is it a candidate for a new /sys/ directory? By the way, some BUGS in the FreeBSD-5-current USB driver: Last time I tried to abort a transfer and then start it again it didn't work. The current USB driver does not handle isochronous over-/under-flow very well. There is no check after that the first transfer has been started to see if the frames are inserted at the correct position in time. After XDU, isochronous transfers are not usable. Yours -HPS