From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 11 13:48:26 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 425DC16A4CE for ; Mon, 11 Apr 2005 13:48:26 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DF4B43D2F for ; Mon, 11 Apr 2005 13:48:25 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 1036865211; Mon, 11 Apr 2005 14:48:08 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25600-03-7; Mon, 11 Apr 2005 14:48:07 +0100 (BST) Received: from empiric.dek.spc.org (66-117-149-249.rdsl.lmi.net [66.117.149.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id D6BCA6520E; Mon, 11 Apr 2005 14:48:06 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 8D089626C; Mon, 11 Apr 2005 06:48:17 -0700 (PDT) Date: Mon, 11 Apr 2005 06:48:17 -0700 From: Bruce M Simpson To: Scott Long Message-ID: <20050411134817.GA4176@empiric.icir.org> Mail-Followup-To: Scott Long , freebsd-hackers@freebsd.org References: <20050411082600.GA735@empiric.icir.org> <425A7AB3.7040908@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425A7AB3.7040908@samsco.org> cc: freebsd-hackers@freebsd.org Subject: Re: A question about hot-pluggable PCI. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 13:48:26 -0000 On Mon, Apr 11, 2005 at 07:25:07AM -0600, Scott Long wrote: > Asking for 'hotplug support' is pretty generic and non-descriptive. Are > you asking for device level hotplug support, where we carefully drain > transactions out of a device, device driver, and whatever I/O or network > or whatever layers are above it? Or are you talking about PCI hotplug > support? If so, which de-facto standard? Compaq? IBM? ACPI? > PCI-SIG? Something else? Sorry, I thought my original post was quite clear; in order to support my hot-pluggable PCI chassis, FreeBSD needs to grow the ability to manage PCI resources without any firmware support (other than possibly the ability to route interrupts). Since I sent that mail I looked at the requirements list for 5-STABLE and realized this is in fact on it. I think there's a fair chance that any other PCI hotplug standard is going to need the same changes I need to make my split bridge work. I looked in src/sys/dev/cardbus/cardbus_cis.c, and Linux's ACPI-based PCI hotplug driver, and realised that at the lowest level, they are all in fact pretty much doing the same thing -- that is, setting all bits in a BAR, and then figuring out the desired aperture size for each BAR, allocating the appropriate resources using rman, figuring out base addresses, etc. We currently rely on the BIOS to do this. The bit I've been discussing with Warner is how to deal with the problem of setting subordinate bus numbers, though because I can get away without doing that for the 'pcib is an immediate child of cardbus' case, I haven't done it. I had also thought of passing down a 'cold' flag, for pcibX to indicate to pciY that this is a 'cold attach' (the BIOS hasn't been anywhere near the devices behind this bridge -- it is as fresh as after a RST# assert). That's enough for me to be getting on with just now, though it would be nice to have some general architectural advice on where exactly this logic should go, because it's something cardbus is using to mop up the edge cases where device resources are not fully described in the CIS. I am undecided as to whether I should try to separate out my changes to src/sys/dev/pci/pci_pci.c into a new driver or not. BMS