Date: Mon, 21 Apr 2003 01:12:31 +0200 From: Bernd Walter <ticso@cicely9.cicely.de> To: Scott Long <scott_long@btc.adaptec.com> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/conf NOTES files src/sys/dev/usb FILES ehci.c ehci_pci.c ehcireg.h ehcivar.h usb.c src/sys/modules/usb Makefile Message-ID: <20030420231230.GD20422@cicely9.cicely.de> In-Reply-To: <3EA3214B.1060508@btc.adaptec.com> 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> <3EA3214B.1060508@btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 20, 2003 at 04:38:03PM -0600, Scott Long wrote: > >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. Yes - that's clear now. > 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 I can't speak for UHCI, but on OHCI and EHCI the data buffers don't have to be continuously on the bus. OHCI can handle one page break and EHCI even more. The current limitation is a code one, not a hardware one. It shouldn't be very hard to fix. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030420231230.GD20422>