Date: Mon, 11 Apr 2005 06:48:17 -0700 From: Bruce M Simpson <bms@spc.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-hackers@freebsd.org Subject: Re: A question about hot-pluggable PCI. Message-ID: <20050411134817.GA4176@empiric.icir.org> In-Reply-To: <425A7AB3.7040908@samsco.org> References: <20050411082600.GA735@empiric.icir.org> <425A7AB3.7040908@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050411134817.GA4176>