Date: Sun, 20 Apr 2003 16:38:03 -0600 From: Scott Long <scott_long@btc.adaptec.com> To: ticso@cicely.de Cc: cvs-all@freebsd.org Subject: Re: 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 Message-ID: <3EA3214B.1060508@btc.adaptec.com> In-Reply-To: <20030420213537.GB20422@cicely9.cicely.de> References: <200304141404.h3EE48aL034057@repoman.freebsd.org> <ybs4r4zqixp.wl@ett.sat.t.u-tokyo.ac.jp> <20030416101546.GW529@cicely9.cicely.de> <20030420202527.GB42856@locore.ca> <20030420213537.GB20422@cicely9.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA3214B.1060508>