cvs commit: src/sys/conf NOTES files src/sys/dev/usb FILESehci.c ehci_pci.c ehcireg.h ehcivar.h usb.c src/sys/modules/usb Makefile

[Scott Long]

Bernd Walter wrote:
> On Sun, Apr 20, 2003 at 04:25:28PM -0400, Jake Burkholder wrote:
> 
>>Apparently, On Wed, Apr 16, 2003 at 12:15:47PM +0200,
>>	Bernd Walter said words to the effect of;
>>
>>>On Wed, Apr 16, 2003 at 11:23:30AM +0900, Hidetoshi Shimokawa wrote:
>>>
>>>>At Mon, 14 Apr 2003 07:04:08 -0700 (PDT),
>>>>Bernd Walter wrote:
>>>>Is this device supposed to work on sparc64?
>>>
>>>I don't know a reason why not.
>>
>>I don't know if this device is an exception, but the USB framework in
>>general does not use busdma, so its not MI and won't work on sparc64.
> 
> 
> This device is not an exception - it wouldn't make much sense without
> doing OHCI first as both are very similar in design.
> joe said he would do busdma for OHCI, but I'm not shure if the porting
> just stalled.
> Is busdma realy an absolute required feature for sparc64?
> OHCI works on alpha and it should be endian clean.
> Unfortunately my test alpha did not initialize more than function 0,
> so I wasn't able to test EHCI on alpha, but I'm almost shure it will
> work.
> 

In sparc64, bus address != physical RAM address.  The IOMMU uses a
translation table of physical<->bus addresses, but it only does this
via the busdma interface.  Without that translation, giving a physical
RAM address to a device is pretty much guaranteed to not do what you
want.

I looked at usb a few months ago with the intent to help Joe convert
it to busdma.  The FreeBSD implementation of usb_mem.h is actually just
a hack as the NetBSD and OpenBSD versions use (their versions of) busdma
already.  Adding in the right pieces for FreeBSD busdma looks trivial on
the surface, but I got caught up in doing it in both a correct and
efficient manner.  USB controller seem to not be able to handle scatter/
gather lists, so data buffers must be contiguous on the bus.  On ia32
this means that any buffer passed to USB must either be copied into a
contiguous segment or mapped contiguous onto the bus using the AGP GART
(similar in function to the IOMMU on sparc64).  Since the former incurs
a performance penalty and the latter has never been implemented in
FreeBSD, I got stuck and had to move on to other things.

Justin Gibbs and I discussed fixing busdma so that bus_dmamap_load()
honors the maxsegs field of the dma tag and transparently uses either
copies or GART tricks to do its business.  This way a device that
doesn't do S/G could be treated as just a case of maxsegs=1 and
everything would be happy.  Unfortunately, real life has interveined
and this hasn't gotten very far.

If someone wants to hack out a FreeBSD version of usb_mem.c that uses
busdma, it can easily be done using bus_dmamem_alloc_size() and bcopy().
However, I'm starting to beleive that busdmamem_alloc_size() was a
mistake and I plan to get rid of it once bus_dmamap_load() is fixed as
described above.

Scott