aboutsummaryrefslogtreecommitdiff
path: root/arch/i386/pci/pci.h
AgeCommit message (Collapse)Author
2006-08-30[PATCH] x86: Disable MMCONFIG on Intel SDV using DMI blacklistAndi Kleen
As a replacement for the earlier removal of the e820 MCFG check we blacklist the Intel SDV with the original BIOS bug that motivated that check. On those machines don't use MMCONFIG. This also adds a new pci=mmconf parameter to override the blacklist. Cc: Greg KH <gregkh@suse.de> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-12[PATCH] PCI: poper prototype for arch/i386/pci/pcbios.c:pcibios_sort()Adrian Bunk
This patch adds a proper prototype for pcibios_sort() in arch/i386/pci/pci.h. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-21[PATCH] PCI: i386/x86_84: disable PCI resource decode on device disableRajesh Shah
When a PCI device is disabled via pci_disable_device(), it's still left decoding its BAR resource ranges even though its driver will have likely released those regions (and may even have unloaded). pci_enable_device() already explicitly enables BAR resource decode for the device being enabled. This patch disables resource decode for the PCI device being disabled, making it symmetric with the enable call. I saw this while doing something else, not because of a problem report. Still, seems to be the correct thing to do. Signed-off-by: Rajesh Shah <rajesh.shah@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-23[PATCH] PCI: Give PCI config access initialization a defined orderingAndi Kleen
I moved it to a separate function which is safer. This avoids problems with the linker reordering them and the less useful PCI config space access methods taking priority over the better ones. Fixes some problems with broken MMCONFIG Cc: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-12-12[PATCH] i386/x86-64 Fall back to type 1 access when no entry foundAndi Kleen
When there is no entry for a bus in MCFG fall back to type1. This is especially important on K8 systems where always some devices can't be accessed using mmconfig (in particular the builtin northbridge doesn't support it for its own devices) Cc: <gregkh@suse.de> Cc: <jgarzik@pobox.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-29/home/lenb/src/to-linus branch 'acpi-2.6.12'Len Brown
2005-07-29[ACPI] suspend/resume ACPI PCI Interrupt LinksDavid Shaohua Li
Add reference count and disable ACPI PCI Interrupt Link when no device still uses it. Warn when drivers have not released Link at suspend time. http://bugzilla.kernel.org/show_bug.cgi?id=3469 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-27[PATCH] PCI Allow OutOfRange PIRQ table addressjayalk@intworks.biz
I updated this to remove unnecessary variable initialization, make check_routing be inline only and not __init, switch to strtoul, and formatting fixes as per Randy Dunlap's recommendations. I updated this to change pirq_table_addr to a long, and to add a warning msg if the PIRQ table wasn't found at the specified address, as per thread with Matthew Wilcox. In our hardware situation, the BIOS is unable to store or generate it's PIRQ table in the F0000h-100000h standard range. This patch adds a pci kernel parameter, pirqaddr to allow the bootloader (or BIOS based loader) to inform the kernel where the PIRQ table got stored. A beneficial side-effect is that, if one's BIOS uses a static address each time for it's PIRQ table, then pirqaddr can be used to avoid the $pirq search through that address block each time at boot for normal PIRQ BIOSes. Signed-off-by: Jaya Kumar <jayalk@intworks.biz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!