Subject: Re: USB stack needs early review (Re: Someone should fix our USB stack...)
To: None <tech-kern@netbsd.org>
From: ITOH Yasufumi <itohy@netbsd.org>
List: tech-kern
Date: 03/23/2007 00:25:01
Hello,

thorpej@shagadelic.org writes:
> Well, I think that's premature.  Has any decision been made about  
> adopting a new USB API?

Hm, OK, I finished the work to some extent.
I have modified all host controller drivers (ehci, ohci, slhci, uhci),
but I don't have enough USB hardware to test on.
Please review, test and fix problems.


ftp://ftp.netbsd.org/pub/NetBSD/misc/itohy/usbtest-20070322.tar.gz

This applies to NetBSD 4.99.13 (before caddr_t removal).

Started based on FreeBSD version, excluding
 - removal of portability code

Patch most NetBSD changes, excluding
 - DMA memory "reserve"
 - caddr_t removal, expecting it will soon be reverted :D
 - volatiles in DMA structure, since it should not be needed
   with proper bus_dma_sync(9)s

DMA/non-DMA memory management overhaul
 - Move all DMA related code to usb_mem.[ch]
   (add usb_alloc_buffer_dma(), usb_free_buffer_dma(), etc.).
   XXX Should usb_mem.[ch] be renamed as usb_mem_dma.[ch] ?
 - Add corresponding non-DMA code to usb_mem_nodma.[ch] .
   Currently just use malloc(9).
 - Above files are conditionally used by config framework (added
   attributes to conf/files and dev/usb/files.usb).

Allocate DMA/non-DMA buffer per host interface, not globally.
 advantage:	Buffers can be freed on detaching host interface.
		Activity of a host interface does not affect others.
 disadvantages:	It possibly consumes more memory.

API changes
 - no visible changes to USB driver interface
 - async request will be processed as a task (kernel thread context),
   and delayed to some extent
 - struct usbd_xfer: renamed a member "allocbuf" to "hcbuffer"
   (mapped/allocated/refered buffer for HCI driver)

ohci
 - free resources on detach (but some leaks exist)
 - add lots of bus_dmamap_sync() operations
 - simplify the code of loading std chain
 - rewrite code of looking up TD/ITD from DMA addr by using allocation chunk
 - add workaround for CMD Tech 670 and 673 chipsets

slhci
 - allocate xfer and slhci_xfer at once, and simplify relevant code
 - add slhci_detach()
 - remove second arg of slhci_attach() since it is the same as the first arg.
 - NOT TESTED, missing hardware

ehci
 - add lots of bus_dmamap_sync() operations, possibly too many
 - NOT TESTED, missing hardware

uhci
 - add lots of bus_dmamap_sync() operations, possibly too many
 - NOT TESTED (will be later)

To do
 - review, test, debug

Regards,
-- 
ITOH Yasufumi