On Friday 13 November 2009 03:36:52 pm Ira W. Snyder wrote: > On Fri, Nov 06, 2009 at 02:47:54PM -0600, Bjorn Helgaas wrote: > > On Friday 06 November 2009 12:57:17 pm Ira W. Snyder wrote: > > > On Thu, Nov 05, 2009 at 06:34:56PM -0600, Bjorn Helgaas wrote: > > > > > > [ big snip ] > > > > > > > > > > > Of course, this doesn't help if you actually power off the slot or > > > > press your reset button. In that case, we have to assign things from > > > > scratch, and we really need to know what the host bridge apertures are. > > > > It'd be best if the BIOS gave us an ACPI description, so we could just > > > > use "pci=use_crs". Without that, I think we'll need a host bridge > > > > driver to read them out of the hardware, and it sounds like we don't > > > > have the specs required to write such a driver. > > > > > > > > > > What would actually be needed to write this driver? I ran an the command > > > "lspci -MH1 -vv -xxx", which I found in a very old email. It manages to > > > dump out all 0x100 bytes of configuration space on the bridges. Using > > > this and lspci, it is clear what memory lives behind the bridge, I > > > think. > > > > > > Here is a dump from my Force computer's Broadcom host bridges. Look > > > closely at the 4 16-bit registers starting at 0xC0. If you correlate > > > them with the BAR dump, shown below, it shows: > > > > > > Bridge 00:00.0 > > > non-prefetchable memory from 0xf9000000 - 0xf93fffff > > > prefectchable memory from 0xf9400000 - 0xf96fffff > > > > > > Bridge 00:00.1 > > > non-prefetchable memory from 0xf98c0000 - 0xfaffffff > > > prefectchable memory from NONE PRESENT > > > > Hey, this is cool! Nice detective work :-) > > > > There should also be a bus number range: it looks like the 00.0 > > host bridge has bus 00 below it, and 00.1 has at least buses 01-02 > > below it. > > > > And there should be an I/O port range. Your Freescale device doesn't > > use any I/O ports, but presumably you could plug in a card that did, > > and the BIOS should allocate space for it. > > > > That's basically all the info we should need to write a driver. There's > > not really a good model for one yet because we don't have any kind of > > generic PCI host bridge structure. We do have drivers/acpi/pci_root.c > > and arch/x86/pci/amd_bus.c, which are two different approaches to this. > > amd_bus.c is closer to what we need here, but it's not well integrated > > into PCI, so I don't really want to add more stuff like it. > > > > Ok, I've started to write a driver for this, but I can't get anything to > change when I run the hotplug. I've tried: > > 1) add a quirk on the host bridge, like intel_bus.c > from the quirk, change the dev->bus->resource[] start, end, flags > This totally crashes and burns, it probably isn't what I want to do. This seems like what you want; maybe we just need to debug it. I think you need a quirk like pci_root_bus_res(), but with your Broadcom vendor/device ID. It should call update_res(). Then when we call x86_pci_root_bus_res_quirks() from pcibios_fixup_bus(), it should notice that we've found a host bridge, and it will then update the root bus resources (you probably have to change x86_pci_root_bus_res_quirks() so it does this even if we only found one host bridge). If you post what you've got so far and the dmesg log, I can try to help debug it. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
