From owner-cvs-all@FreeBSD.ORG Sun Apr 20 16:12:47 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AAB437B404 for ; Sun, 20 Apr 2003 16:12:47 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B5B743FAF for ; Sun, 20 Apr 2003 16:12:46 -0700 (PDT) (envelope-from ticso@cicely9.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h3KNCacx067451 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 21 Apr 2003 01:12:39 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h3KNCYmU008728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2003 01:12:35 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.9/8.12.8) with ESMTP id h3KNCXtA024318; Mon, 21 Apr 2003 01:12:34 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.9/8.12.9/Submit) id h3KNCV3M024317; Mon, 21 Apr 2003 01:12:32 +0200 (CEST) (envelope-from ticso) Date: Mon, 21 Apr 2003 01:12:31 +0200 From: Bernd Walter To: Scott Long Message-ID: <20030420231230.GD20422@cicely9.cicely.de> References: <200304141404.h3EE48aL034057@repoman.freebsd.org> <20030416101546.GW529@cicely9.cicely.de> <20030420202527.GB42856@locore.ca> <20030420213537.GB20422@cicely9.cicely.de> <3EA3214B.1060508@btc.adaptec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA3214B.1060508@btc.adaptec.com> X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i cc: Hidetoshi Shimokawa cc: src-committers@freebsd.org cc: cvs-src@freebsd.org cc: Jake Burkholder cc: Bernd Walter cc: ticso@cicely.de 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 23:12:48 -0000 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