Hello, sorry for delay...,

I'm now planning to change the API a little.

now we have:
	usbd_xfer_handle usbd_alloc_xfer(usbd_device_handle dev)

proposed API:
	usbd_xfer_handle usbd_alloc_xfer(usbd_device_handle dev,
	    usbd_pipe_handle pipe)
	Also modify usbd_setup_xfer() etc. not to take pipe argument.

This is because pre-allocating resources (such as transfer descriptors (TDs))
requires information on the pipe.
I found allocating TDs on interrupt context causes problems and trying
to allocate them along with allocation of buffer memory.

This change requires modification of each driver, augh.


dima@marvell.com writes:
> Please explain how the patch below should be applied and 
> how it should effect the system performance.

It allows non-contiguous memory for HC operations, and probably
improve VM performance on busy systems.

> As I see inside there are USB files that should be replaced and there is
> usb.diff
> File that contains differences for other files (e.g. umass.c)
> But usb.diff file contains some unresolved symbols
> For example #include <dev/usb/usb_mem_nodma.h> 
> But I don't fount this file anywhere.
> 
>  ftp://ftp.netbsd.org/pub/NetBSD/misc/itohy/usbtest-20070328.tar.gz

Oops, I added usb_mem_nodma.[ch] and put the updated tarball at
ftp://ftp.netbsd.org/pub/NetBSD/misc/itohy/usbtest-20070328-1.tar.gz


dima@marvell.com writes:
> I do system profile and see that cpu spend more than 20% of time in the
> memcpy function (see umass.c)
> while coping all USB data between two kernel buffers and additional 8%
> in memset function.
> 
> I am intresting if somebody tried to skip this copy.

It is not easy for now.
Staring request is performed in the callback function (in interrupt
context) and mapping the buffer into DMA space needs process (or thread)
context.

I'm planning to add API to pre-allocate DMA resources with BUS_DMA_ALLOCNOW
and to map buffer using the resources.

Any ideas?

-- 
ITOH Yasufumi