usb dma patch
gurney_j at efn.org
Wed Jul 9 02:20:53 PDT 2003
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:
> > http://people.FreeBSD.org/~jmg/usb_dma.diff
> 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.
> 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.
> 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.
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.
Thanks for pointing it out.
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-current