From owner-cvs-src@FreeBSD.ORG Sun Apr 20 15:38:49 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3071237B401; Sun, 20 Apr 2003 15:38:49 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1366943FBF; Sun, 20 Apr 2003 15:38:48 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h3KMZvZ15833; Sun, 20 Apr 2003 15:35:57 -0700 Received: from btc.btc.adaptec.com ([10.100.0.52]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id PAA23881; Sun, 20 Apr 2003 15:38:14 -0700 (PDT) Received: from btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id QAA08811; Sun, 20 Apr 2003 16:38:05 -0600 (MDT) Message-ID: <3EA3214B.1060508@btc.adaptec.com> Date: Sun, 20 Apr 2003 16:38:03 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <200304141404.h3EE48aL034057@repoman.freebsd.org> <20030416101546.GW529@cicely9.cicely.de> <20030420202527.GB42856@locore.ca> <20030420213537.GB20422@cicely9.cicely.de> In-Reply-To: <20030420213537.GB20422@cicely9.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Hidetoshi Shimokawa cc: src-committers@freebsd.org cc: cvs-src@freebsd.org cc: Jake Burkholder cc: Bernd Walter 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 22:38:50 -0000 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