usb dma patch

Bernd Walter ticso at
Wed Jul 9 03:55:23 PDT 2003

On Wed, Jul 09, 2003 at 02:21:06AM -0700, John-Mark Gurney wrote:
> Bernd Walter wrote this message on Wed, Jul 09, 2003 at 01:28 +0200:
> > On Tue, Jul 08, 2003 at 03:45:24PM -0700, John-Mark Gurney wrote:
> > > I have made usb bus_dma aware.  I have only tested this patch so far on
> > > an ohci controller in sparc64.  I do have problems with isochronous
> > > transfers, but I don't have an i386 box to test the original code on to
> > > make sure it isn't my changes.  Currently both umass and ums have been
> > > tested and are working on sparc64.  I would like to receive feed back
> > > on i386 to make sure things don't break there.
> > 
> > ohci code doesn't support isochronous so far.
> > There is a patch to add this kern/52589.
> > 
> > > The patch is at:
> > >
> > 
> > There are more changes than just bus_dma in this patchset.
> > E.g. changing commets for specs and adding verdors.
> I thought I had taken the vendor part out, but I missed it in this
> spin of the patches.   The problem is that since I'm doing my testing
> on sparc64, all the changes have to be rolled into one since I can't
> "make" it work w/o bus_dma.

No - problem - just remember this :)

> > I've seen a number of changes in code places that are very similar to
> > ehci, but there are no such changes in ehci.
> I tried to do some small changes, but since I don't have an ehci card,
> I can't do any testing.  If I had one, I'd do the necessary changes on
> that card also.

OK - unfortunately it seems to be impossible to add bus_dma support
on a per controller basis, so we need to have ehci and uhci as well.
I have a card here, but currently no device.
Asus supported me with a test device for porting the ehci driver.
What I currently can do is testing ohci on alpha if I find enough time
also in a large memory environment.

> > This was just with a quick look into the patchset so there might be
> > other issues as well.
> > 
> > You might also ask Josef Karthauser and Scott Long about this, because
> > they already spend some time into busdma'ing USB and they found some
> > performance issues with the current bus_dma implementation on FreeBSD.
> > You should contact Scott Long about details.
> I asked Joe, and he said go for it.  As for Scott Long, he also knows
> that I'm working on it.

And it great that you do.
I have large memory support for alpha in the queue and without bus_dma
ported USB this would mean no USB on such a system.

> As for performance, the new code will suffer some because it will force
> bounces on code that previously didn't need it.  This is because all
> buffers are forced to be a single segment, instead of n segments of
> max of 4k (or on a per controller option).  This is more of a limitation
> of how NetBSD uses DMAADDR/KERNADDR since they use the macros and assume
> each dma address is pysically contigious.

That's bad, but I think we shouldn't make it a show stopper because
busdma is important.

B.Walter                   BWCT      
ticso at                                  info at

More information about the freebsd-current mailing list