Date: Wed, 5 Sep 2007 09:02:34 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org Subject: Re: New USB stack - some updates Message-ID: <200709050902.34416.hselasky@c2i.net> In-Reply-To: <20070904.233843.669286320.imp@bsdimp.com> References: <200709040810.48776.hselasky@c2i.net> <20070904.233843.669286320.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Warner, On Wednesday 05 September 2007, M. Warner Losh wrote: > In message: <200709040810.48776.hselasky@c2i.net> > > Hans Petter Selasky <hselasky@c2i.net> writes: > : Hi, > : > : There hasn't been some many changes during the last month to my SVN > : repository nor P4 tree. Actually that is because my cable provider in > : Norway has been terribly slow providing me decent internet access. So > : there will be a big commit soon with lots of improvements. > > Connectivity problems suck :-( > > : Anyways, there are several changes coming soon, some of which might > : interest you: > : > : 1) Optimisations for embedded platforms > : 1.a) Reduced stack usage > : 1.b) Faster USB control transfers > : 1.c) Loading of DMA buffers with automatic cache synch operations. > > Cool! Which embedded platforms were targeted? All> but the last one > are useful on i386, so I assume thing else? Currently ARM. I've bought a board from KWIKBYTE (ATMEL based) which I will do testing on. > > : 2) End of data bouncing in USB drivers. Using DMA buffers are now > : mandatory. > : > : 3) Some non-critical bug fixes. > : > : 4) Planned "USB device side" support. Currently only the "USB host side" > : is well supported. > > This sounds very interesting. Do you have a design that you can share > at this time? The callback design will be exactly the same as for the USB host side. Actually I am modifying the system so that you setup the USB transfers approximately the same way on the host and device side. This introduces some new things like that "xfer->length" and "xfer->buffer" is removed. Instead you always have to use "xfer->frlengths" and a new "xfer->frbuffers". For control transfers you have three "frlengths" which are now 32-bit. One for the SETUP stage, one for DATA and one for STATUS. This way you can receive SETUP messages in parts when supported by the underlying hardware, and this is a must for USB device support. Also for BULK, note _BULK_, transfers you can now gather multiple transfers in a single USB transfer: xfer->frlengths[0] = X; xfer->frlengths[1] = Y; xfer->frlengths[...] = ...; And you also have to setup where the buffer is by writing to "xfer->frbuffers[n]" if you are not using the default allocated DMA buffer. This should easily allow mbuf loading for example and super-high CDC-ethernet frame rates with some modifications. This also opens up the possibility that we can finally have a zero-copy USB ethernet driver that can receive more than 4000 frames per second, which is the interrupt rate for the EHCI controller. > > : PS: I will be at EuroBSDcon in Denmark next week, available for comments. > > Sadly, I'll not be able to make it to EuroBSDcon, as much as I wanted > to go. Too many work obligations. I can understand that. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709050902.34416.hselasky>