summaryrefslogtreecommitdiffstats
path: root/arch/x86_64/pci/mmconfig.c
AgeCommit message (Collapse)AuthorFilesLines
2007-10-11x86_64: prepare shared pci/mmconfig.cThomas Gleixner1-157/+0
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2007-08-11x86: Work around mmio config space quirk on AMD Fam10hdean gaudet1-6/+6
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 Hirofumi1-0/+6
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 Hirofumi1-12/+4
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: remove #define MMCONFIG_APER_XXXOGAWA Hirofumi1-4/+0
MMCONFIG_APER_XXX is unneeded in arch/x86_64/pci/mmconfig.c. 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 Hirofumi1-36/+14
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: Fix x86_64 ioremap base_addressOGAWA Hirofumi1-11/+35
Current mmconfig has some problems of remapped range. a) In the case of broken MCFG tables on Asus etc., we need to remap 256M range, but currently only remap 1M. b) The base address always corresponds to bus number 0, but currently we are assuming it corresponds to start bus number. This patch fixes the above problems. (akpm: Arjan suggests that if the MCFG table is broken we just shouldn't use it, rather than try to work around things). Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
2007-02-13[PATCH] mmconfig: Share parts of mmconfig code between i386 and x86-64Olivier Galibert1-64/+12
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 Starikovskiy1-14/+15
Signed-off-by: Len Brown <len.brown@intel.com>
2006-11-14Revert "[PATCH] MMCONFIG and new Intel motherboards"Andi Kleen1-32/+0
This reverts 4c6e052adfe285ede5884e4e8c4d33af33932c13 commit. Following Linus' i386 change: revert resource reservation for mmcfg config now. Will be revisited in .20 hopefully.
2006-10-27PCI: x86-64: mmconfig missing printk levelsDave Jones1-2/+3
Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-26[PATCH] Remove outdated comment in x86-64 mmconfig codeAndi Kleen1-1/+0
Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26[PATCH] MMCONFIG and new Intel motherboardsAaron Durbin1-0/+32
On Sat, Sep 09, 2006 at 04:14:29PM +0200, Andi Kleen wrote: > [patch] Looks reasonable, but probably not for 2.6.18 because this stuff > is already too fragile and it is probably too risky to do any big changes now > since not enough testing time is left. Can you please resubmit > it with proper description and signed-off-by line? I can queue it for .19 then > > -Andi Patch inserts PCI memory mapped config region(s) into the resource map. This will allow for the MMCCONFIG regions to be marked as busy in the iomem address space as well as the regions(s) showing up in /proc/iomem. Signed-off-by: Aaron Durbin <adurbin@google.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26[PATCH] i386/x86-64: Only do MCFG e820 check when type 1 worksAndi Kleen1-1/+3
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 Kleen1-1/+1
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-26[PATCH] fix bus numbering format in mmconfig warningBrice Goglin1-3/+2
Make an mmconfig warning print the bus id with a regular format. Signed-off-by: Brice Goglin <brice@myri.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-09-19Revert mmiocfg heuristics and blacklist changesLinus Torvalds1-24/+10
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 Kleen1-1/+24
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 Kleen1-9/+0
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-06-21[PATCH] PCI: fix issues with extended conf space when MMCONFIG disabled ↵Chuck Ebbert1-4/+9
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] x86_64: Fix embarassing typo in mmconfig bus checkAndi Kleen1-1/+1
Surprising that it still worked at all with this - yes it was tested. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] i386/x86-64: Remove checks for value == NULL in PCI config space accessAndi Kleen1-1/+1
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 Kleen1-1/+3
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 Kleen1-15/+24
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 Ven1-0/+10
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-24[PATCH] x86_64: {set,clear,test}_bit() related cleanup and pci_mmcfg_init() fixAkinobu Mita1-11/+7
While working on these patch set, I found several possible cleanup on x86-64 and ia64. akpm: I stole this from Andi's queue. Not only does it clean up bitops. It also unrelatedly changes the prototype of pci_mmcfg_init() and removes its arch_initcall(). It seems that the wrong two patches got joined together, but this is the one which has been tested. This patch fixes the current x86_64 build error (the pci_mmcfg_init() declaration in arch/i386/pci/pci.h disagrees with the definition in arch/x86_64/pci/mmconfig.c) This also means that x86_64's pci_mmcfg_init() gets called in the same (new) manner as x86's: from arch/i386/pci/init.c:pci_access_init(), rather than via initcall. The bitops cleanups came along for free. All this worked OK in -mm testing (since 2.6.16-rc4-mm1) because x86_64 was tested with both patches applied. Signed-off-by: Akinobu Mita <mita@miraclelinux.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Con Kolivas <kernel@kolivas.org> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-07[PATCH] arch/x86_64/pci/mmconfig.c NULL noise removalAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2006-02-04[PATCH] x86_64: Fix zero mcfg entry workaround on x86-64Andi Kleen1-1/+1
I broke this earlier when moving the patch from i386 to x86-64. Need to return the virtual address here, not the physical address. This fixes some boot time crashes on x86-64. Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-31[PATCH] PCI: handle bogus MCFG entriesAndi Kleen1-5/+14
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-15[PATCH] i386,amd64: mmconfig __iomem annotationsAl Viro1-7/+7
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 Kleen1-2/+34
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 Kleen1-9/+20
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 Kleen1-7/+0
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 (x86-64)Greg Kroah-Hartman1-10/+48
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-Hartman1-7/+9
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-rc2v2.6.12-rc2Linus Torvalds1-0/+104
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!