aboutsummaryrefslogtreecommitdiff
path: root/arch/i386/pci/mmconfig.c
AgeCommit message (Collapse)Author
2007-08-12i386: Fix broken mmiocfg accessesLinus Torvalds
Commit 3320ad994afb2c44ad34b3b34c3c5cf0da297331 broke mmio config space accesses totally on i386 - it dropped the "reg" offset to the address. Cc: dean gaudet <dean@arctic.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-08-11x86: Work around mmio config space quirk on AMD Fam10hdean gaudet
Some broken devices have been discovered to require %al/%ax/%eax registers for MMIO config space accesses. Modify mmconfig.c to use these registers explicitly (rather than modify the global readb/writeb/etc inlines). AK: also changed i386 to always use eax AK: moved change to extended space probing to different patch AK: reworked with inlines according to Linus' requirements. AK: improve comments. Signed-off-by: dean gaudet <dean@arctic.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-13[PATCH] mmconfig: fix unreachable_devices()OGAWA Hirofumi
Currently, unreachable_devices() compares value of mmconfig and value of conf1. But it doesn't check the device is reachable or not. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andi Kleen <ak@suse.de>
2007-02-13[PATCH] mmconfig: minor cleanup in mmconfig codeOGAWA Hirofumi
This just cleans up. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andi Kleen <ak@suse.de>
2007-02-13[PATCH] mmconfig: Reject a broken MCFG tables on Asus etcOGAWA Hirofumi
This rejects broken MCFG tables on Asus. When the table looks bogus just disable mmconfig Arjan and Andi suggested this. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andi Kleen <ak@suse.de>
2007-02-13[PATCH] mmconfig: Share parts of mmconfig code between i386 and x86-64Olivier Galibert
i386 and x86-64 pci mmconfig code have a lot in common. So share what's shareable between the two. Signed-off-by: Olivier Galibert <galibert@pobox.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
2007-02-02ACPICA: Remove duplicate table definitions (non-conflicting), contAlexey Starikovskiy
Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-02ACPICA: Remove duplicate table managerAlexey Starikovskiy
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-23[PATCH] arch/i386/pci/mmconfig.c tlb flush fixOGAWA Hirofumi
We use the fixmap for accessing pci config space in pci_mmcfg_read/write(). The problem is in pci_exp_set_dev_base(). It is caching a last accessed address to avoid calling set_fixmap_nocache() whenever pci_mmcfg_read/write() is used. static inline void pci_exp_set_dev_base(int bus, int devfn) { u32 dev_base = base | (bus << 20) | (devfn << 12); if (dev_base != mmcfg_last_accessed_device) { mmcfg_last_accessed_device = dev_base; set_fixmap_nocache(FIX_PCIE_MCFG, dev_base); } } cpu0 cpu1 --------------------------------------------------------------------------- pci_mmcfg_read("device-A") pci_exp_set_dev_base() set_fixmap_nocache() pci_mmcfg_read("device-B") pci_exp_set_dev_base() set_fixmap_nocache() pci_mmcfg_read("device-B") pci_exp_set_dev_base() /* doesn't flush tlb */ But if cpus accessed the above order, the second pci_mmcfg_read() on cpu0 doesn't flush the TLB, because "mmcfg_last_accessed_device" is device-B. So, second pci_mmcfg_read() on cpu0 accesses a device-A via a previous TLB cache. This problem became the cause of several strange behavior. This patches fixes this situation by adds "mmcfg_last_accessed_cpu" check. [ Alternatively, we could make a per-cpu mapping area or something. Not that it's probably worth it, but if we wanted to avoid all locking and instead just disable preemption, that would be the way to go. --Linus ] Signed-off-by: OGAWA Hirofumi <hogawa@miraclelinux.com> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-11-08Revert "[PATCH] i386: Add MMCFG resources to i386 too"Linus Torvalds
This reverts commit de09bddb9d6f96785be470c832b881e6d72d589f. It tried to reserve the MMCONFIG mmio memory ranges, but since the MMCONFIG information is broken and often bogus (which is why we don't dare use it most of the time _anyway_), it does more harm than good. Cc: Jeff Chua <jeff.chua.linux@gmail.com> Cc: Adrian Bunk <bunk@stusta.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-01[PATCH] arch/i386/pci/mmconfig.c tweaksAndrew Morton
- Add soothing comment - uninline thrice-called function Cc: OGAWA Hirofumi <hogawa@miraclelinux.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-26[PATCH] i386: Add MMCFG resources to i386 tooAndi Kleen
Following earlier x86-64 patch Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26[PATCH] i386/x86-64: Only do MCFG e820 check when type 1 worksAndi Kleen
Needs earlier patch to split type 1 probing from use. This patch should fix the x86 macs where type 1 PCI config space access doesn't work, but MCFG does. They also don't have a usable e820 table so the e820 sanity check failed. Instead assume now that if type 1 doesn't work then MCFG must work and don't do the e820 check. Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26[PATCH] i386/x86-64: PCI: split probing and initialization of type 1 config ↵Andi Kleen
space access First probe if type1/2 accesses work, but then only initialize them at the end. This is useful for a later patch that needs this information inbetween. Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-19Revert mmiocfg heuristics and blacklist changesLinus Torvalds
This reverts commits 11012d419cfc0e0f78ca356aca03674217910124 and 40dd2d20f220eda1cd0da8ea3f0f9db8971ba237, which allowed us to use the MMIO accesses for PCI config cycles even without the area being marked reserved in the e820 memory tables. Those changes were needed for EFI-environment Intel macs, but broke some newer Intel 965 boards, so for now it's better to revert to our old 2.6.17 behaviour and at least avoid introducing any new breakage. Andi Kleen has a set of patches that work with both EFI and the broken Intel 965 boards, which will be applied once they get wider testing. Cc: Arjan van de Ven <arjan@infradead.org> Cc: Edgar Hucek <hostmaster@ed-soft.at> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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-08-30[PATCH] x86: Revert e820 MCFG heuristicsAndi Kleen
The check for the MCFG table being reserved in the e820 map was originally added to detect a broken BIOS in a preproduction Intel SDV. However it also breaks the Apple x86 Macs, which can't supply this properly, but need a working MCFG. With this patch they wouldn't use the MCFG and not work. After some discussion I think it's best to remove the heuristic again. It also failed on some other boxes (although it didn't cause much problems there because old style port access for PCI config space still works as fallback), but the preproduction SDVs can just use pci=nommcfg. Supporting production machines properly is more important. Edgar Hucek did all the debugging work. Cc: Arjan van de Ven <arjan@infradead.org> Cc: Edgar Hucek <hostmaster@ed-soft.at> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-08-26[PATCH] PCI: i386 mmconfig: don't forget bus number when setting ↵Daniel Ritz
fallback_slots bits On i386 PCI mmconfig forgets the bus number when setting the fallback_slots bits which means fallback to conf1 only works for bus 0. Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-21[PATCH] PCI: fix issues with extended conf space when MMCONFIG disabled ↵Chuck Ebbert
because of e820 On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote: > Anyways I would say that if the BIOS can't get MCFG right then > it's likely not been validated on that board and shouldn't be used. According to Petr Vandrovec: ... "What is important (and checked) is address of MMCONFIG reported by MCFG table... Unfortunately code does not bother with printing that address :-( "Another problem is that code has hardcoded that MMCONFIG area is 256MB large. Unfortunately for the code PCI specification allows any power of two between 2MB and 256MB if vendor knows that such amount of busses (from 2 to 128) will be sufficient for system. With notebook it is quite possible that not full 8 bits are implemented for MMCONFIG bus number." So here is a patch. Unfortunately my system still fails the test because it doesn't reserve any part of the MMCONFIG area, but this may fix others. Booted on x86_64, only compiled on i386. x86_64 still remaps the max area (256MB) even though only 2MB is checked... but 2.6.16 had no check at all so it is still better. PCI: reduce size of x86 MMCONFIG reserved area check 1. Print the address of the MMCONFIG area when the test for that area being reserved fails. 2. Only check if the first 2MB is reserved, as that is the minimum. Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-04-11[PATCH] i386/x86-64: Remove checks for value == NULL in PCI config space accessAndi Kleen
Nobody should pass NULL here. Could in theory make it a BUG, but the NULL pointer oops will do as well. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] i386/x86-64: Return defined error value for bad PCI config space ↵Andi Kleen
accesses Mostly to get better handling when a extended config space access has to fallback to Type1. Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] i386/x86_64: Check if MCFG works for the first 16 bussesAndi Kleen
Previously only the first bus would be checked against Type 1. Why 16? Checking all would need too much memory and we can assume that systems with more than 16 busses have better than average quality BIOS. This is an additional defense against bad MCFG tables. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] i386/x86-64: Check that MCFG points to an e820 reserved areaArjan van de Ven
This patch introduces a user for the e820_all_mapped function: There have been several machines that don't have a working MMCONFIG, often because of a buggy MCFG table in the ACPI bios. This patch adds a simple sanity check that detects a whole bunch of these cases, and when it detects it, linux now boots rather than crash-and-burns. The accuracy of this detection can in principle be improved if there was a "is this entire range in e820 with THIS attribute", but no such function exist and the complexity needed for this is not really worth it; this simple check already catches most cases anyway. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
2006-01-31[PATCH] PCI: handle bogus MCFG entriesAndi Kleen
Handle more bogus MCFG entries Some Asus P4 boards seem to have broken MCFG tables with only a single entry for busses 0-0. Special case these and assume they mean all busses can be accessed. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-12-16[PATCH] PCI: Fix dumb bug in mmconfig fixAndi Kleen
Use correct address when referencing mmconfig aperture while checking for broken MCFG. This was a typo when porting the code from 64bit to 32bit. It caused oopses at boot on some ThinkPads. Should definitely go into 2.6.15. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-12-15[PATCH] i386,amd64: mmconfig __iomem annotationsAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-12-12[PATCH] i386/x86-64 Correct for broken MCFG tables on K8 systemsAndi Kleen
They report all busses as MMCONFIG capable, but it never works for the internal devices in the CPU's builtin northbridge. It just probes all func 0 devices on bus 0 (the internal northbridge is currently always on bus 0) and if they are not accessible using MCFG they are put into a special fallback bitmap. On systems where it isn't we assume the BIOS vendor supplied correct MCFG. Requires the earlier patch for mmconfig type1 fallback 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-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-09-12[PATCH] x86{-64}: Remove old hack that disabled mmconfig support on AMD systems.Andi Kleen
Now that Greg implemented MCFG/_SEG support this shouldn't be needed anymore Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27[PATCH] PCI: use the MCFG table to properly access pci devices (i386)Greg Kroah-Hartman
Now that we have access to the whole MCFG table, let's properly use it for all pci device accesses (as that's what it is there for, some boxes don't put all the busses into one entry.) If, for some reason, the table is incorrect, we fallback to the "old style" of mmconfig accesses, namely, we just assume the first entry in the table is the one for us, and blindly use it. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-27[PATCH] PCI: add proper MCFG table parsing to ACPI core.Greg Kroah-Hartman
This patch is the first step in properly handling the MCFG PCI table. It defines the structures properly, and saves off the table so that the pci mmconfig code can access it. It moves the parsing of the table a little later in the boot process, but still before the information is needed. 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!