- 24 Nov, 2009 30 commits
-
-
Bjorn Helgaas authored
This replaces "typeof(pci_mmcfg_config[0])" with the actual type because I plan to convert pci_mmcfg_config to a list, and then "pci_mmcfg_config[0]" won't mean anything. Reviewed-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Bjorn Helgaas authored
The virtual address is only used for x86_64, but it's so much simpler to manage it as part of the pci_mmcfg_region that I think it's worth wasting a pointer per MMCONFIG region on x86_32. Reviewed-by:
-
Bjorn Helgaas authored
Since pci_mmcfg_region contains the struct resource, no need to pass the pci_mmcfg_region *and* the resource start/size. Reviewed-by:
-
Bjorn Helgaas authored
This patch adds a resource and corresponding name to the MMCONFIG structure. This makes allocation simpler (we can allocate the resource and name at the same time we allocate the pci_mmcfg_region), and gives us a way to hang onto the resource after inserting it. This will be needed so we can release and free it when hot-removing a host bridge. Reviewed-by:
-
Bjorn Helgaas authored
No functional change, but simplifies a future patch to convert the table to a list. Reviewed-by:
-
Bjorn Helgaas authored
This only renames the struct pci_mmcfg_region members; no functional change. Reviewed-by:
-
Bjorn Helgaas authored
This adds a struct pci_mmcfg_region with a little more information than the struct acpi_mcfg_allocation used previously. The acpi_mcfg structure is defined by the spec, so we can't change it. To begin with, struct pci_mmcfg_region is basically the same as the ACPI MCFG version, but future patches will add more information. Reviewed-by:
-
Bjorn Helgaas authored
This factors out the common "bus << 20" expression used when computing the MMCONFIG address. Reviewed-by:
-
Bjorn Helgaas authored
Since all MMCONFIG regions go through pci_mmconfig_add(), we can test the address once there. If the caller supplies an address of zero, we never insert it in the pci_mmcfg_config[] table, so no need to test it elsewhere. Reviewed-by:
-
Bjorn Helgaas authored
We never set pci_mmcfg_config unless we increment pci_mmcfg_config_num, so there's no need to test both pci_mmcfg_config_num and pci_mmcfg_config. Reviewed-by:
-
Bjorn Helgaas authored
This patch encapsulate pci_mmcfg_config[] updates. All alloc/free is now done in pci_mmconfig_add() and free_all_mcfg(), so all updates to pci_mmcfg_config[] and pci_mmcfg_config_num are in those two functions. This replaces the previous sequence of extend_mmcfg(), fill_one_mmcfg() with the single pci_mmconfig_add() interface. This interface is currently static but will eventually be used in the host bridge hot-add path. Reviewed-by:
-
Bjorn Helgaas authored
Step through the ACPI MCFG table, not pci_mmcfg_config[]. No functional change, but simplifies future patches that encapsulate pci_mmcfg_config[]. Reviewed-by:
-
Bjorn Helgaas authored
Use a local variable, not pci_mmcfg_config_num, to count MCFG entries. No functional change, but simplifies future changes. Reviewed-by:
-
Bjorn Helgaas authored
Reviewed-by:
-
Yinghai Lu authored
Those functions are used by intel_bus.c so seperate them to another file. and make amd_bus a bit smaller. Signed-off-by:
-
Jiri Kosina authored
Signed-off-by:
André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Alex Chiang authored
commit db635adc turned -DDEBUG for x86/pci on when CONFIG_PCI_DEBUG is set. In general, I agree with that change. However, it exposes a bunch of very low level PCI debugging in the early x86 path, such as: 0 reading 2 from a: ffff 1 reading 2 from a: ffff 2 reading 2 from a: ffff 3 reading 2 from a: 300 3 reading 2 from 0: 1002 3 reading 2 from 2: 515e These statements add a lot of noise to the boot and aren't likely to be necessary even when handling random upstream bug reports. [In contrast, statements such as these: pci 0000:02:04.0: found [14e4:164a] class 000200 header type 00 pci 0000:02:04.0: reg 10: [mem 0xf8000000-0xf9ffffff 64bit] pci 0000:02:04.0: reg 30: [mem 0x00000000-0x0001ffff pref] are indeed useful when remote debugging users' machines] Remove the noisy printks and save electrons everywhere. Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
-
Kenji Kaneshige authored
Enabling power fault detected event notification in current pciehp might cause power fault interrupt storm on some machines. On those machines. On those machines, power fault detected bit in the slot status register was set again immediately when it is cleared in the interrupt service routine, and next power fault detected interrupt was notified again. Therefore, disable power fault detected event notification for now. This patch also removes unnecessary handling for power fault cleared event because this event is not supported by PCIe spec. Tested-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
Kenji Kaneshige authored
Change for PCI hotplug to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by:
-
Kenji Kaneshige authored
Changes for PCIe AER driver to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by:
-
Kenji Kaneshige authored
Change for PCIe ASPM driver to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by:
-
Kenji Kaneshige authored
Change for PCI core to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by:
-
Kenji Kaneshige authored
Introduce pci_is_pcie() which returns true if the specified PCI device is PCI Express capable, false otherwise. The purpose of pci_is_pcie() is removing 'is_pcie' flag in the struct pci_dev, which is not needed because we can check it using 'pcie_cap' field. To remove 'is_pcie', we need to update user of 'is_pcie' to use pci_is_pcie() instead first. Signed-off-by:
-
Kenji Kaneshige authored
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability offset in pciehp driver. This avoids unnecessary search in PCI configuration space. This patch also removes 'cap_base' field in struct controller, that was used to hold PCIe capability offset by pciehp itself. Signed-off-by:
-
Kenji Kaneshige authored
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCI hotplug core. This avoids unnecessary search in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCIe ASPM driver. This avoids unnecessary search in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCI Express Port Bus driver. This avoids unnecessary serarch in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Use pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCIe AER driver. This avoids unnecessary search in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Use pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCI core code. This avoids unnecessary search in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Introduce pci_pcie_cap() API that returns saved PCIe capability offset (currently it is saved in 'pcie_cap' field in the struct PCI dev). Using pci_pcie_cap() instead of pci_find_capability() avoids unnecessary search in PCI configuration space. Signed-off-by:
-
- 11 Nov, 2009 1 commit
-
-
Linus Torvalds authored
I'm not entirely sure it needs to go into 32, but it's probably the right thing to do. Another way of explaining the patch is: - we currently pick the _first_ exactly matching bus resource entry, but the _last_ inexactly matching one. Normally first/last shouldn't matter, but bus resource entries aren't actually all created equal: in a transparent bus, the last resources will be the parent resources, which we should generally try to avoid unless we have no choice. So "first matching" is the thing we should always aim for. - the patch is a bit bigger than it needs to be, because I simplified the logic at the same time. It used to be a fairly incomprehensible if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH)) best = r; /* Approximating prefetchable by non-prefetchable */ and technically, all the patch did was to make that complex choice be even more complex (it basically added a "&& !best" to say that if we already gound a non-prefetchable window for the prefetchable resource, then we won't override an earlier one with that later one: remember "first matching"). - So instead of that complex one with three separate conditionals in one, I split it up a bit, and am taking advantage of the fact that we already handled the exact case, so if 'res->flags' has the PREFETCH bit, then we already know that 'r->flags' will _not_ have it. So the simplified code drops the redundant test, and does the new '!best' test separately. It also uses 'continue' as a way to ignore the bus resource we know doesn't work (ie a prefetchable bus resource is _not_ acceptable for anything but an exact match), so it turns into: /* We can't insert a non-prefetch resource inside a prefetchable parent .. */ if (r->flags & IORESOURCE_PREFETCH) continue; /* .. but we can put a prefetchable resource inside a non-prefetchable one */ if (!best) best = r; instead. With the comments, it's now six lines instead of two, but it's conceptually simpler, and I _could_ have written it as two lines: if ((res->flags & IORESOURCE_PREFETCH) && !best) best = r; /* Approximating prefetchable by non-prefetchable */ but I thought that was too damn subtle. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- 06 Nov, 2009 6 commits
-
-
Thomas Gleixner authored
SPIN_LOCK_UNLOCKED is deprecated. Use DEFINE_SPINLOCK instead. Make the lock static while at it. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Isaku Yamahata authored
This patch fixes the following compilation error introduced by a PCI related features. The change set of 5dd1af9f84c79bedd589db89e71ca733f3bf0ebd moves some xen related definitions from the arch header file (x86/include/asm/xen/hypervisor.h) to the common header file (include/xen/xen.h). So ia64/xen also follows it. In file included from linux-next/include/xen/grant_table.h:41, from linux-next/drivers/block/xen-blkfront.c:48: linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: nested redefinition of 'enum xen_domain_type' linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: redeclaration of 'enum xen_domain_type' linux-next/arch/ia64/include/asm/xen/hypervisor.h:44: error: redeclaration of enumerator 'XEN_NATIVE' linux-next/include/xen/xen.h:5: error: previous definition of 'XEN_NATIVE' was here linux-next/arch/ia64/include/asm/xen/hypervisor.h:45: error: redeclaration of enumerator 'XEN_PV_DOMAIN' linux-next/include/xen/xen.h:6: error: previous definition of 'XEN_PV_DOMAIN' was here linux-next/arch/ia64/include/asm/xen/hypervisor.h:46: error: redeclaration of enumerator 'XEN_HVM_DOMAIN' linux-next/include/xen/xen.h:7: error: previous definition of 'XEN_HVM_DOMAIN' was here Signed-off-by:Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by:
-
Kenji Kaneshige authored
If firmware doesn't grant over native hotplug control through ACPI _OSC method, we must not evaluate OSHP. Acked-by:
Andrew Patterson <andrew.patterson@hp.com> Signed-off-by:
-
Andreas Herrmann authored
In case of AMD CPU northbridge functions this NUMA information might differ. Here is an example from a 4-socket system. Currently Linux shows root@hagen:/sys/devices/pci0000:00/0000:00:1a.4# cat numa_node 0 root@hagen:/sys/devices/pci0000:00/0000:00:1a.4# cat local_cpu* 0-3 00000000,0000000f which is not correct for northbridge functions as the local CPUs are those of the same socket. With this patch and a quirk for AMD CPU NB functions Linux can do better and correctly show root@hagen:/sys/devices/pci0000:00/0000:00:1a.4# cat numa_node 2 root@hagen:/sys/devices/pci0000:00/0000:00:1a.4# cat local_cpu* 8-11 00000000,00000f00 Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
-
Bjorn Helgaas authored
The roundup() caused a build error (undefined reference to `__udivdi3'). We're aligning to power-of-two boundaries, so it's simpler to just use ALIGN() anyway, which avoids the division. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Kenji Kaneshige authored
There are a lot of codes that searches PCI express capability offset in the PCI configuration space using pci_find_capability(). Caching it in the struct pci_dev will reduce unncecessary search. This patch adds an additional 'pcie_cap' fields into struct pci_dev, which is initialized at pci device scan time (in set_pcie_port_type()). Signed-off-by:
-
- 04 Nov, 2009 3 commits
-
-
Bjorn Helgaas authored
When "allocate_resource(root, new, size, ...)" fails, we currently clobber "new". This is inconvenient for the caller, who might care about the original contents of the resource. For example, when pci_bus_alloc_resource() fails, the "can't allocate mem resource %pR" message from pci_assign_resources() currently contains junk for the resource start/end. This patch delays the "new" update until we're about to return success. Acked-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Bjorn Helgaas authored
PCI device BARs are guaranteed to start and end on at least a four-byte (I/O) or a sixteen-byte (MMIO) boundary because they're aligned on their size and the low BAR bits are reserved. PCI-to-PCI bridge apertures have even larger alignment restrictions. However, some BIOSes (e.g., HP DL360 BIOS P31) report host bridge windows like "[io 0x0000-0x2cfe]". This is wrong because it excludes the last port at 0x2cff: it's impossible for a downstream device to claim 0x2cfe without also claiming 0x2cff. In fact, this BIOS configures a device behind the bridge to "[io 0x2c00-0x2cff]", so we know the window actually does include 0x2cff. This patch rounds the start and end of apertures to the appropriate boundary. I experimentally determined that Windows contains a similar workaround; details here: http://bugzilla.kernel.org/show_bug.cgi?id=14337Signed-off-by: -
Bjorn Helgaas authored
We have occasional problems with PCI resource allocation, and sometimes they could be avoided by paying attention to what ACPI tells us about the host bridges. This patch doesn't change the behavior, but it prints window information that should make debugging easier. Signed-off-by:
-
