12 Aug, 2007
1 commit
-
This patch finishes the i386 and x86-64 ->sysdata conversion and hopefully
also fixes Riku's and Andy's observed bugs. It is based on Yinghai Lu's
and Andy Whitcroft's patches (thanks!) with some changes:- introduce pci_scan_bus_with_sysdata() and use it instead of
pci_scan_bus() where appropriate. pci_scan_bus_with_sysdata() will
allocate the sysdata structure and then call pci_scan_bus().
- always allocate pci_sysdata dynamically. The whole point of this
sysdata work is to make it easy to do root-bus specific things
(e.g., support PCI domains and IOMMU's). I dislike using a default
struct pci_sysdata in some places and a dynamically allocated
pci_sysdata elsewhere - the potential for someone indavertantly
changing the default structure is too high.
- this patch only makes the minimal changes necessary, i.e., the NUMA node is
always initialized to -1. Patches to do the right thing with regards
to the NUMA node can build on top of this (either add a 'node'
parameter to pci_scan_bus_with_sysdata() or just update the node
when it becomes known).The patch was compile tested with various configurations (e.g., NUMAQ,
VISWS) and run-time tested on i386 and x86-64. Unfortunately none of my
machines exhibited the bugs so caveat emptor.Andy, could you please see if this fixes the NUMA issues you've seen?
Riku, does this fix "pci=noacpi" on your laptop?Signed-off-by: Muli Ben-Yehuda
Cc: Yinghai Lu
Cc: Andi Kleen
Cc: Chuck Ebbert
Cc:
Cc: Andy Whitcroft
Cc: Jeff Garzik
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Jul, 2007
1 commit
-
This patch introduces struct pci_sysdata to x86 and x86-64, and
converts the existing two users (NUMA, Calgary) to use it.This lays the groundwork for having other users of sysdata, such as
the PCI domains work.The Calgary bits are tested, the NUMA bits just look ok.
Signed-off-by: Jeff Garzik
Signed-off-by: Muli Ben-Yehuda
Signed-off-by: Linus Torvalds
12 Jul, 2007
2 commits
-
Based on replies to a respective query, remove the pci_dac_dma_...() APIs
(except for pci_dac_dma_supported() on Alpha, where this function is used
in non-DAC PCI DMA code).Signed-off-by: Jan Beulich
Cc: Andi Kleen
Cc: Jesse Barnes
Cc: Christoph Hellwig
Acked-by: David Miller
Cc: Jeff Garzik
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
I'm not sure if this is going to fly, weak symbols work on the compilers I'm
using, but whether they work for all of the affected architectures I can't say.
I've cc'ed as many arch maintainers/lists as I could find.But assuming they do, we can use a weak empty definition of
pcibios_add_platform_entries() to avoid having an empty definition on every
arch.Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
26 Apr, 2006
1 commit
-
Signed-off-by: David Woodhouse
15 Aug, 2005
1 commit
-
This reverts commits
71db63acff69618b3d9d3114bd061938150e146b
[PATCH] increase PCIBIOS_MIN_IO on x86and
0b2bfb4e7ff61f286676867c3508569bea6fbf7a
ACPI: increase PCIBIOS_MIN_IO on x86since Lukas Sandströ reports that this breaks
his on-board nvidia audio.We should re-visit this later. For now we revert the change
Signed-off-by: Linus Torvalds
03 Aug, 2005
1 commit
-
There is a number of x86 laptops that have some non-PCI IO ports
in the 0x1000-0x1fff range, and it's quite hard to control the correct
order of resource allocation between PCI and other subsystems controlling
these ports. Especially with modular kernel.So just increase PCIBIOS_MIN_IO to 0x4000 to prevent any new PCI
resource allocations in the problematic range (this limitation must
apply _only_ to the root bus resources - see Linus' change in
pci_bus_alloc_resource). As PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO
are the same now on i386 and x86-64, we can remove the latter.Signed-off-by: Ivan Kokshaysky
Signed-off-by: Linus Torvalds
13 Jul, 2005
1 commit
-
Signed-off-by: Len Brown
12 Jul, 2005
1 commit
-
http://bugme.osdl.org/show_bug.cgi?id=4016
Written-by: David Shaohua Li
Acked-by: Adam Belay
Signed-off-by: Len Brown
28 Jun, 2005
2 commits
-
With CONFIG_PCI=n:
In file included from include/linux/pci.h:917,
from lib/iomap.c:6:
include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list
include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want.
include/asm/pci.h: In function `pci_dma_burst_advice':
include/asm/pci.h:106: dereferencing pointer to incomplete type
include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function)
include/asm/pci.h:106: (Each undeclared identifier is reported only once
include/asm/pci.h:106: for each function it appears in.)
make[1]: *** [lib/iomap.o] Error 1Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
After seeing, at best, "guesses" as to the following kind
of information in several drivers, I decided that we really
need a way for platforms to specifically give advice in this
area for what works best with their PCI controller implementation.Basically, this new interface gives DMA bursting advice on
PCI. There are three forms of the advice:1) Burst as much as possible, it is not necessary to end bursts
on some particular boundary for best performance.2) Burst on some byte count multiple. A DMA burst to some multiple of
number of bytes may be done, but it is important to end the burst
on an exact multiple for best performance.The best example of this I am aware of are the PPC64 PCI
controllers, where if you end a burst mid-cacheline then
chip has to refetch the data and the IOMMU translations
which hurts performance a lot.3) Burst on a single byte count multiple. Bursts shall end
exactly on the next multiple boundary for best performance.Sparc64 and Alpha's PCI controllers operate this way. They
disconnect any device which tries to burst across a cacheline
boundary.Actually, newer sparc64 PCI controllers do not have this behavior.
That is why the "pdev" is passed into the interface, so I can
add code later to check which PCI controller the system is using
and give advice accordingly.Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
17 Apr, 2005
1 commit
-
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!
