New USB stack - some updates

[Hans Petter Selasky]

Hi Warner,

On Wednesday 05 September 2007, M. Warner Losh wrote:
> In message: <200709040810.48776.hselasky at c2i.net>
>
>             Hans Petter Selasky <hselasky at 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