On Tue, 2008-06-24 at 11:48 -0700, Alok Kataria wrote: > Evaluates the _CRS object under PCI0 looking for producer resources. > Then searches the e820 memory space for a gap within these producer resources. > > Allows us to find a gap for the unclaimed pci resources or MMIO resources > for hotplug devices within the BIOS allowed pci regions. > > v1->v2: Some changes in the print strings. > Also note the prototype for e820_search_gap has changes in this > iteration, but the return value is ignored while calling it over here. > > Signed-off-by: Alok N Kataria <akataria@xxxxxxxxxx> > > Index: linux-x86-tree.git/arch/x86/pci/acpi.c > =================================================================== > --- linux-x86-tree.git.orig/arch/x86/pci/acpi.c 2008-06-23 17:24:07.000000000 -0700 > +++ linux-x86-tree.git/arch/x86/pci/acpi.c 2008-06-24 10:57:43.000000000 -0700 > @@ -4,6 +4,7 @@ > #include <linux/irq.h> > #include <linux/dmi.h> > #include <asm/numa.h> > +#include <asm/e820.h> > #include "pci.h" > > struct pci_root_info { > @@ -14,6 +15,11 @@ > int busnum; > }; > > +struct gap_info { > + unsigned long gapstart; > + unsigned long gapsize; > +}; > + > static acpi_status > resource_to_addr(struct acpi_resource *resource, > struct acpi_resource_address64 *addr) > @@ -110,6 +116,70 @@ > } > } > > +static acpi_status search_gap(struct acpi_resource *resource, void *data) > +{ > + struct acpi_resource_address64 addr; > + acpi_status status; > + struct gap_info *gap = data; > + > + status = resource_to_addr(resource, &addr); > + if (ACPI_SUCCESS(status) && > + addr.resource_type == ACPI_MEMORY_RANGE && > + addr.address_length > gap->gapsize) { > + e820_search_gap(&gap->gapstart, &gap->gapsize, > + (addr.minimum + addr.translation_offset)); > + } > + > + return AE_OK; > +} > + > +/* > + * Search for a hole in the 32 bit address space for PCI to assign MMIO > + * resources for hotplug or unconfigured resources. > + * We query the CRS object of the PCI root device to look for possible producer > + * resources in the tree and consider these while calulating the start address > + * for this hole. > + */ > +static void pci_setup_gap(acpi_handle *handle) > +{ > + struct gap_info gap; > + acpi_status status; > + > + gap.gapstart = 0; > + gap.gapsize = 0x400000; > + > + status = acpi_walk_resources(handle, METHOD_NAME__CRS, > + search_gap, &gap); > + > + if (ACPI_SUCCESS(status)) { > + unsigned long round; > + > + if (!gap.gapstart) { > + printk(KERN_ERR "ACPI: Warning: Cannot find a gap " > + "in the 32bit address range for PCI\n" > + "ACPI: PCI devices may collide with " > + "hotpluggable memory address range\n"); > + } > + /* > + * Round the gapstart, uses the same logic as in > + * e820_gap_setup > + */ > + round = 0x100000; > + while ((gap.gapsize >> 4) > round) > + round += round; > + /* Fun with two's complement */ > + pci_mem_start = (gap.gapstart + round) & -round; > + > + printk(KERN_INFO "ACPI: PCI resources should " > + "start at %lx (gap: %lx:%lx)\n", > + pci_mem_start, gap.gapstart, gap.gapsize); > + } else { > + printk(KERN_ERR "ACPI: Error while searching for gap in " > + "the 32bit address range for PCI\n"); > + } > +} > + > + > static void > get_current_resources(struct acpi_device *device, int busnum, > int domain, struct pci_bus *bus) > @@ -220,6 +290,8 @@ > > if (bus && (pci_probe & PCI_USE__CRS)) > get_current_resources(device, busnum, domain, bus); > + > + pci_setup_gap(device->handle); > return bus; > } It seems reasonable. But if the resource obtained from the PCI0 _CRS method is incorrect, we will get the incorrect pci_mem_start. At the same time after the patch is applied, pci_mem_start will be parsed in two different ways. If the result is different, maybe the incorrect pci_mem_start will be used. Best regards. Yakui > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html