aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci
diff options
context:
space:
mode:
authorMike Habeck <habeck@sgi.com>2010-05-12 11:14:32 -0700
committerJesse Barnes <jbarnes@virtuousgeek.org>2010-07-30 09:29:12 -0700
commit7bd1c365fd124624191d49dcc1eb9759d6017ec3 (patch)
tree3e193b2061e02f4e04c51d14ce7a066c6e850bb2 /drivers/pci
parent549e15611b4ac1de51ef0e0a79c2704f50a638a2 (diff)
downloadkernel_samsung_tuna-7bd1c365fd124624191d49dcc1eb9759d6017ec3.zip
kernel_samsung_tuna-7bd1c365fd124624191d49dcc1eb9759d6017ec3.tar.gz
kernel_samsung_tuna-7bd1c365fd124624191d49dcc1eb9759d6017ec3.tar.bz2
x86/PCI: Add option to not assign BAR's if not already assigned
The Linux kernel assigns BARs that a BIOS did not assign, most likely to handle broken BIOSes that didn't enumerate the devices correctly. On UV the BIOS purposely doesn't assign I/O BARs for certain devices/ drivers we know don't use them (examples, LSI SAS, Qlogic FC, ...). We purposely don't assign these I/O BARs because I/O Space is a very limited resource. There is only 64k of I/O Space, and in a PCIe topology that space gets divided up into 4k chucks (this is due to the fact that a pci-to-pci bridge's I/O decoder is aligned at 4k)... Thus a system can have at most 16 cards with I/O BARs: (64k / 4k = 16) SGI needs to scale to >16 devices with I/O BARs. So by not assigning I/O BARs on devices we know don't use them, we can do that (iff the kernel doesn't go and assign these BARs that the BIOS purposely didn't assign). This patch will not assign a resource to a device BAR if that BAR was not assigned by the BIOS, and the kernel cmdline option 'pci=nobar' was specified. This patch is closely modeled after the 'pci=norom' option that currently exists in the tree. Signed-off-by: Mike Habeck <habeck@sgi.com> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Diffstat (limited to 'drivers/pci')
0 files changed, 0 insertions, 0 deletions