On 2004-05-02 nathanw@wasabisystems.com wrote:

> Lennart Augustsson <lennart@augustsson.net> writes:
>
> > > While I'm at it, I'll need to make usb_dma_block_t have a larger
> > > array
> > > of bus_dma_segment_t's. It seems like it could need as many as 16 in
> > > the current arrangement (64k block from umass, 4k pages as seen by the
> > > controllers). Is there anything that would want a larger transfer
> > > size? Or, is 16 so large that it should be separately allocated, so it
> > > can be a smaller array for smaller transfers?
> >
> > 64K is the maximum.  I'm not sure 16 is large enough to warrant
> > a separate allocation.
>
> On i386, going from 1 entry to 16 entries will take usb_dma_block_t
> from 44 bytes to 164 bytes. I don't quite have a sense for the
> prevalence of usb_dma_block_t's to judge if that's a problem or not.
>
> > Have you made the change for all 4 host controllers types?
>
> I've worked on ohci and uhci so far. I'm reading up on ehci. The
> fourth is that isa one (slhci)? I haven't even looked at it yet, and I
> won't be able to test it.

  I am working on updating the slhci driver.  The in-tree driver has many
bugs and does not even try to implement bulk or isoc transfers.  I would
be surprised if it worked at all, although apparently it did work
minimally when checked in.

  slhci does not actually do DMA, but currently steals the parent bus DMA
space (it also currently attaches to x68k "intio" bus in addition to isa).
I am working with a Compact Flash card that uses the chip, so this is not
an option (and is a very bad thing to do in any case, particularly for
ISA).  I get around this by allocating a usb dma tag for each buffer
requested, so there is one for each buffer allocated.  However, there are
never that many buffers allocated at once, so the size increase is
unlikely to have a significant effect.

  Buffer management is the worst aspect of NetBSD's current USB code.  In
addition to exposing the assumed use of DMA, many drivers (including
umass) do not even use the existing generic bounce buffer code, even if
that is all they are doing.  Since the maximum packet size of a bus bulk
transfer is 512 bytes even for USB 2, it would be quite possible to break
up any larger transfer to fit available space.  Chips that don't do DMA
have no need for the copy at all.

  While looking at umass, I just noticed that the CBI code passes the data
address to the transfer instead of the buffer address.

  NetBSD's USB code is in need of a major overhaul and actual design
effort.  It appears to be a serious effort to exhibit at least one of
every code and abstraction error imagineable.

Matthew Orgass
darkstar@city-net.com