summaryrefslogtreecommitdiff
path: root/arch/i386/pci
AgeCommit message (Collapse)Author
2007-07-11PCI: Change all drivers to use pci_device->revisionAuke Kok
Instead of all drivers reading pci config space to get the revision ID, they can now use the pci_device->revision member. This exposes some issues where drivers where reading a word or a dword for the revision number, and adding useless error-handling around the read. Some drivers even just read it for no purpose of all. In devices where the revision ID is being copied over and used in what appears to be the equivalent of hotpath, I have left the copy code and the cached copy as not to influence the driver's performance. Compile tested with make all{yes,mod}config on x86_64 and i386. Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> Acked-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-31PCI: i386: fixup for Siemens Nixdorf AG FSC Multiprocessor Interrupt ControllersIvan Kokshaysky
Wolfgang gets: PCI: Cannot allocate resource region 0 of device 0000:00:04.0 PCI: Error while updating region 0000:00:04.0/0 (a8008000 != fec08000) Note that the BAR seems to have high address bits hardwired to fec00000. And device 0000:00:04.0 is 00:04.0 System peripheral: Siemens Nixdorf AG FSC Multiprocessor Interrupt Controller (rev 02) I'd guess that when we try to reassign this resource, PCI interrupts might just stop working. This could explain SCSI timeouts and other weird things. Cc: Wolfgang Erig <Wolfgang.Erig@gmx.de> Cc: Chuck Ebbert <cebbert@redhat.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-09i386 pci: use __maybe_unusedDavid Rientjes
Use the new macro here Cc: Andi Kleen <ak@suse.de> Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-05Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6Linus Torvalds
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: (231 commits) [PATCH] i386: Don't delete cpu_devs data to identify different x86 types in late_initcall [PATCH] i386: type may be unused [PATCH] i386: Some additional chipset register values validation. [PATCH] i386: Add missing !X86_PAE dependincy to the 2G/2G split. [PATCH] x86-64: Don't exclude asm-offsets.c in Documentation/dontdiff [PATCH] i386: avoid redundant preempt_disable in __unlazy_fpu [PATCH] i386: white space fixes in i387.h [PATCH] i386: Drop noisy e820 debugging printks [PATCH] x86-64: Fix allnoconfig error in genapic_flat.c [PATCH] x86-64: Shut up warnings for vfat compat ioctls on other file systems [PATCH] x86-64: Share identical video.S between i386 and x86-64 [PATCH] x86-64: Remove CONFIG_REORDER [PATCH] x86-64: Print type and size correctly for unknown compat ioctls [PATCH] i386: Remove copy_*_user BUG_ONs for (size < 0) [PATCH] i386: Little cleanups in smpboot.c [PATCH] x86-64: Don't enable NUMA for a single node in K8 NUMA scanning [PATCH] x86: Use RDTSCP for synchronous get_cycles if possible [PATCH] i386: Add X86_FEATURE_RDTSCP [PATCH] i386: Implement X86_FEATURE_SYNC_RDTSC on i386 [PATCH] i386: Implement alternative_io for i386 ... Fix up trivial conflict in include/linux/highmem.h manually. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-02PCI: add debug information to resource collision messageChuck Ebbert
Add more information to PCI resource collision message to help with debugging. Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-02PCI: fix sysfs rom file creation for BIOS ROM shadowsJesse Barnes
At one time, if a BIOS ROM shadow was detected for the boot video device (stored at offset 0xc0000), we'd set a special resource flag, IORESOURCE_ROM_SHADOW, so that the sysfs ROM file code could handle it properly. That broke along the way somewhere though, so current kernels will be missing 'rom' files in sysfs if the video device doesn't have an explicit ROM BAR. This patch fixes the regression by moving the video fixup quirk to a little later in the boot cycle (to avoid having its work undone by PCI resource allocation) and checking in the PCI sysfs code whether a rom file should be created due to a shadow resource, which is also moved to a little later in the boot cycle so it will occur after the video fixup. Tested and works on my i386 test box. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-02[PATCH] i386: type may be unusedDavid Rientjes
In the case of !CONFIG_PCI_DIRECT && !CONFIG_PCI_MMCONFIG, type is unreferened. Cc: Andi Kleen <ak@suse.de> Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Andi Kleen <ak@suse.de>
2007-05-02[PATCH] i386: Some additional chipset register values validation.Olivier Galibert
On i945, a mmconfig range hitting the f0000000-ffffffff zone conflicts with the APIC registers and others. Consider it invalid. On E7520, values 0000 and f000 for the window register are defined invalid in the documentation. I haven't seen a bios use these values, but who trusts biosen these days? Signed-off-by: Olivier Galibert <galibert@pobox.com> Signed-off-by: Andi Kleen <ak@suse.de> arch/i386/pci/mmconfig-shared.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-)
2007-03-28[PATCH] MSI-X: fix resume crashEric W. Biederman
So I think the right solution is to simply make pci_enable_device just flip enable bits and move the rest of the work someplace else. However a thorough cleanup is a little extreme for this point in the release cycle, so I think a quick hack that makes the code not stomp the irq when msi irq's are enabled should be the first fix. Then we can later make the code not change the irqs at all. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-26pci: set pci=bfsort for PowerEdge R900Matt Domsch
This patch automatically enables pci=bfsort for the Dell PowerEdge R900. This is necessary to ensure the onboard NICs enumerate in the proper order, similar to the other systems already on the list. Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-16PCI: add systems for automatic breadth-first device sortingAndy Gospodarek
This is an additional list of systems that exhibit the PCI device ordering issue that prompted the following patch: commit 6b4b78fed47e7380dfe9280b154e8b9bfcd4c86c Author: Matt Domsch <Matt_Domsch@dell.com> Date: Fri Sep 29 15:23:23 2006 -0500 PCI: optionally sort device lists breadth-first Adding these systems to the list prevents the need for the additional kernel command line argument. Signed-off-by: Andy Gospodarek <andy@greyhouse.net> Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-13[PATCH] mmconfig: Move e820 check into pci_mmcfg_reject_broken()OGAWA Hirofumi
This is just cleanup. It moves to e820 check into pci_mmcfg_reject_broken(). Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andi Kleen <ak@suse.de>
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: Reserve resources but only when we're sure about them.Olivier Galibert
Put back the resource reservation as per 4c6e052adfe285ede5884e4e8c4d33af33932c13 but use it *only* when the range(s) come from a chipset probe instead of the bios. 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-13[PATCH] mmconfig: Detect and support the E7520 and the 945G/GZ/P/PLOlivier Galibert
It seems that the only way to reliably support mmconfig in the presence of funky biosen is to detect the hostbridge and read where the window is mapped from its registers. Do that for the E7520 and the 945G/GZ/P/PL for a start. 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-13[PATCH] i386: Only call unreachable_devices() when type 1 is available.Olivier Galibert
unreachable_devices compares between the results of pci configuration accesses through type1 and mmconfig, so it should be called only if type1 actually works in the first place. 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-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-12-20PCI: Fix multiple problems with VIA hardwareAlan Cox
This patch is designed to fix: - Disk eating corruptor on KT7 after resume from RAM - VIA IRQ handling - VIA fixups for bus lockups after resume from RAM The core of this is to add a table of resume fixups run at resume time. We need to do this for a variety of boards and features, but particularly we need to do this to get various critical VIA fixups done on resume. The second part of the problem is to handle VIA IRQ number rules which are a bit odd and need special handling for PIC interrupts. Various patches broke various boxes and while this one may not be perfect (hopefully it is) it ensures the workaround is applied to the right devices only. From: Jean Delvare <khali@linux-fr.org> Now that PCI quirks are replayed on software resume, we can safely re-enable the Asus SMBus unhiding quirk even when software suspend support is enabled. [akpm@osdl.org: fix const warning] Signed-off-by: Alan Cox <alan@redhat.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-07[PATCH] x86: add write_pci_config_byte() to direct PCI access routinesSiddha, Suresh B
Mechanism of selecting physical mode in genapic when cpu hotplug is enabled on x86_64, broke the quirk(quirk_intel_irqbalance()) introduced for working around the transposing interrupt message errata in E7520/E7320/E7525 (revision ID 0x9 and below. errata #23 in http://download.intel.com/design/chipsets/specupdt/30304203.pdf). This errata requires the mode to be in logical flat, so that interrupts can be directed to more than one cpu(and thus use hardware IRQ balancing enabled by BIOS on these platforms). Following four patches fixes this by moving the quirk to early quirk and forcing the x86_64 genapic selection to logical flat on these platforms. Thanks to Shaohua for pointing out the breakage. This patch: Add write_pci_config_byte() to direct PCI access routines Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: "Li, Shaohua" <shaohua.li@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-12-07[PATCH] paravirt: Be careful about touching BIOS address spaceRusty Russell
BIOS ROM areas may not be mapped into the guest address space, so be careful when touching those addresses to make sure they appear to be mapped. [akpm@osdl.org: fix unused var warning] AK: Changed __get_user to probe_kernel_address Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-12-07[PATCH] x86: remove last two pci_find offenders in the core codeAlan Cox
Resending as I believe the discussion about them established they were correct. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-12-01PCI: make arch/i386/pci/common.c:pci_bf_sort staticAdrian Bunk
This patch makes the needlessly global pci_bf_sort static. Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-01PCI: irq: irq and pci_ids patch for Intel ICH9Jason Gaston
This updated patch adds the Intel ICH9 LPC and SMBus Controller DID's. Signed-off-by: Jason Gaston <jason.d.gaston@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-01pci/i386: style cleanupsRandy Dunlap
Mostly CodingStyle cleanups for arch/i386/pci/i386.c: - fit in 80 columns; - use a #defined value instead of an inline constant; Also change one resource_size_t (DBG) printk from %08lx to %lx since it can be more than 32 bits (more than 8 hexits). Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-01PCI: quirks: fix the festering mess that claims to handle IDE quirksAlan Cox
The number of permutations of crap we do is amazing and almost all of it has the wrong effect in 2.6. At the heart of this is the PCI SFF magic which says that compatibility mode PCI IDE controllers use ISA IRQ routing and hard coded addresses not the BAR values. The old quirks variously clears them, sets them, adjusts them and then IDE ignores the result. In order to drive all this garbage out and to do it portably we need to handle the SFF rules directly and properly. Because we know the device BAR 0-3 are not used in compatibility mode we load them with the values that are implied (and indeed which many controllers actually thoughtfully put there in this mode anyway). This removes special cases in the IDE layer and libata which now knows that bar 0/1/2/3 always contain the correct address. It means our resource allocation map is accurate from boot, not "mostly accurate" after ide is loaded, and it shoots lots of code. There is also lots more code and magic constant knowledge to shoot once this is in and settled. Been in my test tree for a while both with drivers/ide and with libata. Wants some -mm shakedown in case I've missed something dumb or there are corner cases lurking. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-14[PATCH] fix via586 irq routing for pirq 5Daniel Ritz
Fix interrupt routing for via 586 bridges. pirq can be 5 which needs to be mapped to INTD. But currently the access functions can handle only pirq 1-4. this is similar to the other via chipsets where pirq 4 and 5 are both mapped to INTD. Fixes bugzilla #7490 Cc: Daniel Paschka <monkey20181@gmx.net> Cc: Adrian Bunk <bunk@susta.de> Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> 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-11-02PCI: Revert "PCI: i386/x86_84: disable PCI resource decode on device disable"Greg Kroah-Hartman
This reverts commit 53e4d30dd666d7f83598957ee4a415eefb47c9a6. It was found that it caused unneeded problems (see http://bugzilla.kernel.org/show_bug.cgi?id=7082 for details of one such issue. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-27PCI: fix pci_fixup_video as it blows up on sparc64Eiichiro Oiwa
This reverts much of the original pci_fixup_video change and makes it work for all arches that need it. fixed, and tested on x86, x86_64 and IA64 dig. Signed-off-by: Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> Acked-by: David Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-18PCI: optionally sort device lists breadth-firstMatt Domsch
Problem: New Dell PowerEdge servers have 2 embedded ethernet ports, which are labeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and in the printed documentation. Assuming no other add-in ethernet ports in the system, Linux 2.4 kernels name these eth0 and eth1 respectively. Many people have come to expect this naming. Linux 2.6 kernels name these eth1 and eth0 respectively (backwards from expectations). I also have reports that various Sun and HP servers have similar behavior. Root cause: Linux 2.4 kernels walk the pci_devices list, which happens to be sorted in breadth-first order (or pcbios_find_device order on i386, which most often is breadth-first also). 2.6 kernels have both the pci_devices list and the pci_bus_type.klist_devices list, the latter is what is walked at driver load time to match the pci_id tables; this klist happens to be in depth-first order. On systems where, for physical routing reasons, NIC1 appears on a lower bus number than NIC2, but NIC2's bridge is discovered first in the depth-first ordering, NIC2 will be discovered before NIC1. If the list were sorted breadth-first, NIC1 would be discovered before NIC2. A PowerEdge 1955 system has the following topology which easily exhibits the difference between depth-first and breadth-first device lists. -[0000:00]-+-00.0 Intel Corporation 5000P Chipset Memory Controller Hub +-02.0-[0000:03-08]--+-00.0-[0000:04-07]--+-00.0-[0000:05-06]----00.0-[0000:06]----00.0 Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC2, 2.4 kernel name eth1, 2.6 kernel name eth0) +-1c.0-[0000:01-02]----00.0-[0000:02]----00.0 Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC1, 2.4 kernel name eth0, 2.6 kernel name eth1) Other factors, such as device driver load order and the presence of PCI slots at various points in the bus hierarchy further complicate this problem; I'm not trying to solve those here, just restore the device order, and thus basic behavior, that 2.4 kernels had. Solution: The solution can come in multiple steps. Suggested fix #1: kernel Patch below optionally sorts the two device lists into breadth-first ordering to maintain compatibility with 2.4 kernels. It adds two new command line options: pci=bfsort pci=nobfsort to force the sort order, or not, as you wish. It also adds DMI checks for the specific Dell systems which exhibit "backwards" ordering, to make them "right". Suggested fix #2: udev rules from userland Many people also have the expectation that embedded NICs are always discovered before add-in NICs (which this patch does not try to do). Using the PCI IRQ Routing Table provided by system BIOS, it's easy to determine which PCI devices are embedded, or if add-in, which PCI slot they're in. I'm working on a tool that would allow udev to name ethernet devices in ascending embedded, slot 1 .. slot N order, subsort by PCI bus/dev/fn breadth-first. It'll be possible to use it independent of udev as well for those distributions that don't use udev in their installers. Suggested fix #3: system board routing rules One can constrain the system board layout to put NIC1 ahead of NIC2 regardless of breadth-first or depth-first discovery order. This adds a significant level of complexity to board routing, and may not be possible in all instances (witness the above systems from several major manufacturers). I don't want to encourage this particular train of thought too far, at the expense of not doing #1 or #2 above. Feedback appreciated. Patch tested on a Dell PowerEdge 1955 blade with 2.6.18. You'll also note I took some liberty and temporarily break the klist abstraction to simplify and speed up the sort algorithm. I think that's both safe and appropriate in this instance. Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-18PCI: Turn pci_fixup_video into generic for embedded VGAeiichiro.oiwa.nm@hitachi.com
pci_fixup_video turns into generic code because there are many platforms need this fixup for embedded VGA as well as x86. The Video BIOS integrates into System BIOS on a machine has embedded VGA although embedded VGA generally don't have PCI ROM. As a result, embedded VGA need the way that the sysfs rom points to the Video BIOS of System RAM (0xC0000). PCI-to-PCI Bridge Architecture specification describes the condition whether or not PCI ROM forwards VGA compatible memory address. fixup_video suits this specification. Although the Video ROM generally implements in x86 code regardless of platform, some application such as X Window System can run this code by dosemu86. Therefore, pci_fixup_video should turn into generic code. Signed-off-by: Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> Acked-by: Alan Cox <alan@redhat.com> Acked-by: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-08[PATCH] i386/x86_64: FIX pci_enable_irq to set dev->irq to the irq numberEric W. Biederman
In commit ace80ab796ae30d2c9ee8a84ab6f608a61f8b87b I removed the weird logic that used the vector number as the irq number when MSI was defined. However pci_enable_irq was using a different test in the io_apic_assign_irqs path and I missed it :( This patch removes the wrong code so no one hits this problem. This code is only active when a specific set of boot command line parameters is specified which likely explains why no one has notices this earlier. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-05[PATCH] i386: Fix PCI BIOS config space accessAndi Kleen
Got broken by a earlier change. Also add a printk when no pci config method could be found. Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-04[PATCH] genirq: i386 irq: Remove the msi assumption that irq == vectorEric W. Biederman
This patch removes the change in behavior of the irq allocation code when CONFIG_PCI_MSI is defined. Removing all instances of the assumption that irq == vector. create_irq is rewritten to first allocate a free irq and then to assign that irq a vector. assign_irq_vector is made static and the AUTO_ASSIGN case which allocates an vector not bound to an irq is removed. The ioapic vector methods are removed, and everything now works with irqs. The definition of NR_IRQS no longer depends on CONFIG_PCI_MSI [akpm@osdl.org: cleanup] Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rajesh Shah <rajesh.shah@intel.com> Cc: Andi Kleen <ak@muc.de> Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04[PATCH] genirq: msi: simplify the msi irq limit policyEric W. Biederman
Currently we attempt to predict how many irqs we will be able to allocate with msi using pci_vector_resources and some complicated accounting, and then we only allow each device as many irqs as we think are available on average. Only the s2io driver even takes advantage of this feature all other drivers have a fixed number of irqs they need and bail if they can't get them. pci_vector_resources is inaccurate if anyone ever frees an irq. The whole implmentation is racy. The current irq limit policy does not appear to make sense with current drivers. So I have simplified things. We can revisit this we we need a more sophisticated policy. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rajesh Shah <rajesh.shah@intel.com> Cc: Andi Kleen <ak@muc.de> Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-03Attack of "the the"s in archMatt LaPlante
The patch below corrects multiple occurances of "the the" typos across several files, both in source comments and KConfig files. There is no actual code changed, only text. Note this only affects the /arch directory, and I believe I could find many more elsewhere. :) Signed-off-by: Adrian Bunk <bunk@stusta.de>
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] x86: Allow disabling early pci scans with pci=noearly or disallowing ↵Andi Kleen
conf1 Some buggy systems can machine check when config space accesses happen for some non existent devices. i386/x86-64 do some early device scans that might trigger this. Allow pci=noearly to disable this. Also when type 1 is disabling also don't do any early accesses which are always type1. This moves the pci= configuration parsing to be a early parameter. I don't think this can break anything because it only changes a single global that is only used by PCI. Cc: gregkh@suse.de Cc: Trammell Hudson <hudson@osresearch.net> Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26[PATCH] x86: Move direct PCI scanning functions out of lineAndi Kleen
Saves about 200 bytes of code space. Signed-off-by: Andi Kleen <ak@suse.de>
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>