From owner-freebsd-current@FreeBSD.ORG Wed Jun 11 08:13:42 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9995B37B401 for ; Wed, 11 Jun 2003 08:13:42 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 504B943F93 for ; Wed, 11 Jun 2003 08:13:41 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 2851 invoked by uid 65534); 11 Jun 2003 15:13:40 -0000 Received: from p508E7CCE.dip.t-dialin.net (EHLO galatea.local) (80.142.124.206) by mail.gmx.net (mp001) with SMTP; 11 Jun 2003 17:13:40 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Q7AV-0004bI-M6; Wed, 11 Jun 2003 17:05:43 +0200 Date: Wed, 11 Jun 2003 17:05:43 +0200 From: Thomas Moestl To: "M. Warner Losh" Message-ID: <20030611150543.GC634@crow.dom2ip.de> Mail-Followup-To: "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, ticso@cicely.de, freebsd-sparc64@freebsd.org References: <20030610230230.GC734@crow.dom2ip.de> <20030610234144.GA39701@funkthat.com> <20030611142627.GB634@crow.dom2ip.de> <20030611.083439.57255263.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030611.083439.57255263.imp@bsdimp.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: ticso@cicely12.cicely.de cc: freebsd-current@freebsd.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 15:13:43 -0000 On Wed, 2003/06/11 at 08:34:39 -0600, M. Warner Losh wrote: > In message: <20030611142627.GB634@crow.dom2ip.de> > Thomas Moestl writes: > : On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: > : > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: > : > Ok, the only problem is that is then we have the same problem the ACPI > : > code does in that hot swapping cards would have a problem. Since it > : > appears to me that the OFW tree doesn't get updated upon a swap. (At > : > least the usb part of the tree doesn't.) > : > : We do not support hotplugging at the moment anyway. If a bridge driver > : would implement that in the future without using any firmware support > : however, it will then need to know everything information about the > : interrupt routing required for its devices if it cannot use the > : firmware for this. in that case, it can just prevent the ofw_pci bus > : from attaching to it (this will be easily possible). > : I'd hope that machines that support hot-plugging of PCI devices would > : have firmware methods available to support that though. > > We'll need to do so for the cardbus bridges. Yes, I was just speaking of PCI. > However, the interupt is routed to the bridge and has to be shared > with the cardbus/pccard cards. That should be far less of a problem with the new code, since it will make interrupt routing work right finally (right now, everything needs to be prerouted). > : > Does this mean that we should eliminate most of the Sun specific pci > : > bus drivers in favor of OFW specific ones like ACPI? or? > : > : No, it means introducing an OFW bus driver, which uses the firmware to > : enumerate the devices and to support interrupt routing. The bridge > : drivers would be mostly unaffected by this. > : The only problem with this approach is that it can change the device > : enumeration; I hope that the resulting one will be the same one that is > : printed on the boxen, so it should be advantageous for new > : installations, but a minor migration problem for old ones. > : > : I've got some code for this already, it just isn't done yet. > > So are you talking about doing something akin to the acpi bridge code > or something else? Would this more properly be called a OFW PCI bus > driver, Yes, that's what I meant to say. It will "override" some of the PCI methods (by using it's own method table), and use the rest of them unaltered. It will attach to PCI bridges which offer an additional method to get the firmware device node (but with a higher priority than the standard PCI bus), so bridges can choose which bus driver they want to have attached by offering or not offering that method. Of course, there will need to be a generic OFW PCI-PCI bridge driver that adds this method, but it's needed anyway to override the standard interrupt routing method. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C