15 Oct, 2011
1 commit
-
The "powernv" platform of the powerpc architecture needs to assign PCI
resources using a specific algorithm to fit some HW constraints of
the IBM "IODA" architecture (related to the ability to create error
handling domains that encompass specific segments of MMIO space).For doing so, it wants to call pci_setup_bridge() from architecture
specific resource management in order to configure bridges after all
resources have been assigned. So make it non-static.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jesse Barnes
02 Aug, 2011
5 commits
-
a) adjust_resource_sorted() is now called reassign_resource_sorted()
b) nice-to-have is now called optional
c) add_list is now called realloc_list.Signed-off-by: Ram Pai
Signed-off-by: Jesse Barnes -
Allocate resources to cardbus bridge only after all other genuine
resources requests are satisfied. Dont retry if resource allocation
for cardbus-bridges fail.Signed-off-by: Ram Pai
Signed-off-by: Jesse Barnes -
From: Yinghai Lu
Allocate resources to SRIOV BARs only after all other required
resource-requests are satisfied. Dont retry if resource allocation for SRIOV
BARs fail.Signed-off-by: Ram Pai
Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
Currently pci-bridges are allocated enough resources to satisfy their immediate
requirements. Any additional resource-requests fail if additional free space,
contiguous to the one already allocated, is not available. This behavior is not
reasonable since sufficient contiguous resources, that can satisfy the request,
are available at a different location.This patch provides the ability to expand and relocate a allocated resource.
v2: Changelog: Fixed size calculation in pci_reassign_resource()
v3: Changelog : Split this patch. The resource.c changes are already
upstream. All the pci driver changes are in here.Signed-off-by: Ram Pai
Signed-off-by: Jesse Barnes -
git commit c8adf9a3e873eddaaec11ac410a99ef6b9656938
"PCI: pre-allocate additional resources to devices only after
successful allocation of essential resources."fails to take into consideration the optional-resources needed by children
devices while calculating the optional-resource needed by the bridge.This can be a problem on some setup. For example, if a hotplug bridge has 8
children hotplug bridges, the bridge should have enough resources to accomodate
the hotplug requirements for each of its children hotplug bridges. Currently
this is not the case.This patch fixes the problem.
Signed-off-by: Yinghai Lu
Reviewed-by: Ram Pai
Signed-off-by: Jesse Barnes
23 Jul, 2011
1 commit
-
I don't think there's enough value in the fact of a bridge window
being disabled to justify cluttering the dmesg log with it.Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
09 Jul, 2011
1 commit
-
Multiple attempts to dynamically reallocate pci resources have
unfortunately lead to regressions. Though we continue to fix the
regressions and fine tune the dynamic-reallocation behavior, we have not
reached a acceptable state yet.This patch provides a interim solution. It disables dynamic reallocation
by default, but adds the ability to enable it through pci=realloc kernel
command line parameter.Tested-by: Oliver Hartkopp
Signed-off-by: Ram Pai
Signed-off-by: Jesse Barnes
24 May, 2011
1 commit
-
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (27 commits)
PCI: Don't use dmi_name_in_vendors in quirk
PCI: remove unused AER functions
PCI/sysfs: move bus cpuaffinity to class dev_attrs
PCI: add rescan to /sys/.../pci_bus/.../
PCI: update bridge resources to get more big ranges when allocating space (again)
KVM: Use pci_store/load_saved_state() around VM device usage
PCI: Add interfaces to store and load the device saved state
PCI: Track the size of each saved capability data area
PCI/e1000e: Add and use pci_disable_link_state_locked()
x86/PCI: derive pcibios_last_bus from ACPI MCFG
PCI: add latency tolerance reporting enable/disable support
PCI: add OBFF enable/disable support
PCI: add ID-based ordering enable/disable support
PCI hotplug: acpiphp: assume device is in state D0 after powering on a slot.
PCI: Set PCIE maxpayload for card during hotplug insertion
PCI/ACPI: Report _OSC control mask returned on failure to get control
x86/PCI: irq and pci_ids patch for Intel Panther Point DeviceIDs
PCI: handle positive error codes
PCI: check pci_vpd_pci22_wait() return
PCI: Use ICH6_GPIO_EN in ich6_lpc_acpi_gpio
...Fix up trivial conflicts in include/linux/pci_ids.h: commit a6e5e2be4461
moved the intel SMBUS ID definitons to the i2c-i801.c driver.
22 May, 2011
1 commit
-
With Ram's fixes, this should be safe to do again. So let's give it
another try.BIOS separates IO ranges between several IOHs, and on some slots, BIOS
assigns resources to a bridge, but stops assigning resources to the
device under that bridge, because the device needs a big resource.So:
1. allocate resources and record the failed device resources
2. clear the BIOS assigned resources of the parent bridge of failing device
3. go back and call pci assign unassigned
4. if it still fails, go up the tree, clear more bridges. and try againNow Ram's allocate requested resource already got into mainline. could
put this one again.Reviewed-by: Ram Pai
Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes
17 May, 2011
1 commit
-
During pci remove/rescan testing found:
pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
pci 0000:c0:03.0: bridge window [io 0x1000-0x0fff]
pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff]
pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
pci 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff])
pci 0000:c0:03.0: Error enabling bridge (-22), continuing
pci 0000:c0:03.0: enabling bus mastering
pci 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff])
pcieport: probe of 0000:c0:03.0 failed with error -22This bug was caused by commit c8adf9a3e873 ("PCI: pre-allocate
additional resources to devices only after successful allocation of
essential resources.")After that commit, pci_hotplug_io_size is changed to additional_io_size
from minium size. So it will not go through resource_size(res) != 0
path, and will not be reset.The root cause is: pci_bridge_check_ranges will set RESOURCE_IO flag for
pci bridge, and later if children do not need IO resource. those bridge
resources will not need to be allocated. but flags is still there.
that will confuse the the pci_enable_bridges later.related code:
static void assign_requested_resources_sorted(struct resource_list *head,
struct resource_list_x *fail_head)
{
struct resource *res;
struct resource_list *list;
int idx;for (list = head->next; list; list = list->next) {
res = list->res;
idx = res - &list->dev->resource[0];
if (resource_size(res) && pci_assign_resource(list->dev, idx)) {
...
reset_resource(res);
}
}
}At last, We have to clear the flags in pbus_size_mem/io when requested
size == 0 and !add_head. becasue this case it will not go through
adjust_resources_sorted().Just make size1 = size0 when !add_head. it will make flags get cleared.
At the same time when requested size == 0, add_size != 0, will still
have in head and add_list. because we do not clear the flags for it.After this, we will get right result:
pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
pci 0000:c0:03.0: bridge window [io disabled]
pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff]
pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
pci 0000:c0:03.0: enabling bus mastering
pci 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: irq 160 for MSI/MSI-X
pcieport 0000:c0:03.0: Signaling PME through PCIe PME interrupt
pci 0000:c4:00.0: Signaling PME through PCIe PME interrupt
pcie_pme 0000:c0:03.0:pcie01: service driver pcie_pme loaded
aer 0000:c0:03.0:pcie02: service driver aer loaded
pciehp 0000:c0:03.0:pcie04: Hotplug Controller:v3: more simple fix. also fix one typo in pbus_size_mem
Signed-off-by: Yinghai Lu
Reviewed-by: Ram Pai
Cc: Jesse Barnes
Cc: Bjorn Helgaas
Signed-off-by: Linus Torvalds
12 Apr, 2011
1 commit
-
In commit 13583b16592a ("PCI: refactor io size calculation code") Ram
had a thinko in the refactorization of the code: the end result used the
variable 'align' for the bus alignment, but the original code used
'min_align'.Since then, another use of that 'align' variable got introduced by
commit c8adf9a3e873 ("PCI: pre-allocate additional resources to devices
only after successful allocation of essential resources.")Fix both of those uses to use 'min_align' as they should.
Daniel Hellstrom
Acked-by: Ram Pai
Acked-by: Jesse Barnes
Signed-off-by: Linus Torvalds
05 Mar, 2011
4 commits
-
…on of essential resources.
Linux tries to pre-allocate minimal resources to hotplug bridges. This
works fine as long as there are enough resources to satisfy all other
genuine resource requirements. However if enough resources are not
available to satisfy any of these nice-to-have pre-allocations, the
resource-allocator reports errors and returns failure.This patch distinguishes between must-have resource from nice-to-have
resource. Any failure to allocate nice-to-have resources are ignored.This behavior can be particularly useful to trigger automatic
reallocation when the OS discovers genuine allocation-conflicts or
genuine unallocated-requests caused by buggy allocation behavior of the
native BIOS/uEFI.https://bugzilla.kernel.org/show_bug.cgi?id=15960 captures the
movitation behind the patch. This patch is verified to resolve the above
bug.changelog v2: o fixed a bug where pci_assign_resource() was called on a
resource of zero resource size.changelog v3: addressed Bjorn's comment
o "Please don't indent and right-justify the changelog".
o removed add_size from struct resource. The additional
size is now tracked using a linked list.changelog v4: o moved freeing up of elements in head list from
assign_requested_resources_sorted() to
__assign_resources_sorted().
o removed a wrong reference to 'add_size' in
pbus_size_mem().
o some code optimizations in adjust_resources_sorted()
and assign_requested_resources_sorted()changelog v5: o moved freeing up of elements in head list from
assign_requested_resources_sorted() to
__assign_resources_sorted().
o removed a wrong reference to 'add_size' in
pbus_size_mem().
o some code optimizations in adjust_resources_sorted()
and assign_requested_resources_sorted()changelog v5: o factored out common code and made them into
separate independent patches
o added comments in kdoc format
o added a BUG_ON in pci_assign_unassigned_resources()
to catch for memory leak.Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> -
Introduce reset_resource() which factors out resource reset logic.
Signed-off-by: Ram Pai
Signed-off-by: Jesse Barnes -
Replace free_failed_list() with a free_list() call. free_list() can
handle 'resource_list_x', 'resource_list' and any linked list linked
through ->nextSigned-off-by: Ram Pai
Signed-off-by: Jesse Barnes -
Refactor code that calculates the io size in pbus_size_io() and
pbus_mem_io() into separate functions.Signed-off-by: Ram Pai
Signed-off-by: Jesse Barnes
31 Jul, 2010
1 commit
-
Found one PCIe Module with several bridges built-in where a "cold"
hotadd doesn't work.If we end up reassigning bridge windows at hotadd time, and have to loop
through assigning new ranges, we won't end up enabling the child bridges
because the first assignment pass already tried to enable them, which
prevents __pci_bridge_assign_resource from updating the windows.So try to move enabling of child bridges to the end, and only do it
once.Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes
13 May, 2010
1 commit
-
This reverts commit 977d17bb1749517b353874ccdc9b85abc7a58c2a, because it
can cause problems with some devices not getting any resources at all
when the resource tree is re-allocated.For an example of this, see
https://bugzilla.kernel.org/show_bug.cgi?id=15960
(originally https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4982)
(lkml thread: http://lkml.org/lkml/2010/4/19/20)where Peter Henriksson reported his Xonar DX sound card gone, because
the IO port region was no longer allocated.Reported-bisected-and-tested-by: Peter Henriksson
Requested-by: Andrew Morton
Requested-by: Clemens Ladisch
Acked-by: Jesse Barnes
Cc: Yinghai Lu
Signed-off-by: Linus Torvalds
01 Mar, 2010
1 commit
-
A ROM resource that doesn't fit should not cause us to try to re-assign
all the bus resources. Nobody generally cares, and re-assigning is
going to just cause way more troubles than it tries to solve.Signed-off-by: Yinghai Lu
Signed-off-by: Linus Torvalds
24 Feb, 2010
1 commit
-
No functional change; this converts loops that iterate from 0 to
PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the
pci_bus_for_each_resource() iterator instead.This doesn't change the way resources are stored; it merely removes
dependencies on the fact that they're in a table.Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
23 Feb, 2010
9 commits
-
Make pci_bridge_check_ranges() store the PCI_PREF_RANGE_TYPE_64 in
addition to IORESOURCE_MEM_64. Just like pci_read_bridge_bases().Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
Handle the case where the slot bridge that doesn't get a pre-allocated
resource big enough to handle its child resources.. For example pcie
devices need 256M, but the bridge only gets 2M preallocated.Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
For use by pciehp.
pci_setup_bridge() will not check enabled for the slot bridge, otherwise
update res is not updated to bridge BAR. That is, bridge is already
enabled for port service.Signed-off-by: Yinghai Lu
Reviewed-by: Alex Chiang
Signed-off-by: Jesse Barnes -
BIOS separates IO ranges between several IOHs, and on some slots, BIOS assigns
resources to a bridge, but stops assigning resources to the device under that
bridge, because the device needs a big resource.So:
1. allocate resources and record the failed device resources
2. clear the BIOS assigned resources of the parent bridge of failing device
3. go back and call pci assign unassigned
4. if it still fails, go up the tree, clear more bridges. and try againSigned-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
When clearing leaf bridge resources, trying to get a big enough one, we
could shrink the bridge if there is no resource under it. Confirm
against the old resource side to make sure we're increasing the
allocation.Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
This allows us to track failed allocations for later re-trying with
reallocation.Signed-off-by: Yinghai Lu
Reviewed-by: Alex Chiang
Signed-off-by: Jesse Barnes -
We use this in later patches to free resrouce ranges for reassignment in
an effort to support a wider variety of PCI topologies.Signed-off-by: Yinghai Lu
Reviewed-by: Alex Chiang
Signed-off-by: Jesse Barnes -
Don't print out resources without flags to avoid cluttering up the debug
output.Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
This is a good cleanup in itself, and makes it easier to modify specific
resource types in later code.Signed-off-by: Yinghai Lu
Acked-by: Linus Torvalds
Signed-off-by: Jesse Barnes
05 Dec, 2009
1 commit
-
Prior to 1f82de10 we always initialized the upper 32bits of the
prefetchable memory window, regardless of the address range used.
Now we only touch it for a >32bit address, which means the upper32
registers remain whatever the BIOS initialized them too.It's valid for the BIOS to set the upper32 base/limit to
0xffffffff/0x00000000, which makes us program prefetchable ranges
like 0xffffffffabc00000 - 0x00000000abc00000Revert the chunk of 1f82de10 that made this conditional so we always
write the upper32 registers and remove now unused pref_mem64 variable.Signed-off-by: Alex Williamson
Signed-off-by: Jesse Barnes
05 Nov, 2009
3 commits
-
This makes PCI resource management messages more consistent and adds a few
new messages to aid debugging.Whenever we assign resources to a device, update a BAR, or change a
bridge aperture, it's worth noting it.Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes -
Jesse accidentally applied v1 [1] of the patchset instead of v2 [2]. This
is the diff between v1 and v2.The changes in this patch are:
- tidied vsprintf stack buffer to shrink and compute size more
accurately
- use %pR for decoding and %pr for "raw" (with type and flags) instead
of adding %pRt and %pRf[1] http://lkml.org/lkml/2009/10/6/491
[2] http://lkml.org/lkml/2009/10/13/441Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes -
This uses %pRt to print additional resource information (type, size,
prefetchability, etc.) consistently.Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
28 Oct, 2009
1 commit
-
This reverts commit 308cf8e13f42f476dfd6552aeff58fdc0788e566. This
patch had trouble with transparent bridges, among other things. A more
readable and correct version should land in 2.6.33.Signed-off-by: Jesse Barnes
08 Oct, 2009
1 commit
-
Found one system:
[ 71.120590] pci 0000:40:05.0: scanning behind bridge, config 4f4a40, pass 0
[ 71.138283] PCI: Scanning bus 0000:4a
[ 71.140341] pci 0000:4a:00.0: found [15b3:6278] class 000c06 header type 00
[ 71.157173] pci 0000:4a:00.0: reg 10 64bit mmio: [0x000000-0x0fffff]
[ 71.161697] pci 0000:4a:00.0: reg 18 64bit mmio pref: [0x000000-0x7fffff]
[ 71.179403] pci 0000:4a:00.0: reg 20 64bit mmio pref: [0x000000-0xfffffff]
[ 71.185366] pci 0000:4a:00.0: calling quirk_resource_alignment+0x0/0x1dd
[ 71.200846] pci 0000:4a:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 71.219623] PCI: Fixups for bus 0000:4a
[ 71.222194] pci 0000:40:05.0: bridge 32bit mmio: [0xcf000000-0xcf0fffff]
[ 71.238662] pci 0000:40:05.0: bridge 64bit mmio pref: [0xcd800000-0xcdffffff]
[ 71.255793] PCI: Bus scan for 0000:4a returning with max=4aDevice needs a big pref mmio, but BIOS doesn't allocate mmio to it aside
from a small MMIO range. Later, the kernel will not allocate resources to
that to the device:
[ 99.574030] pci 0000:4a:00.0: BAR 4: can't allocate mem resource [0xd0000000-0xcdffffff]
[ 99.580102] pci 0000:4a:00.0: BAR 2: got res [0xcd800000-0xcdffffff] bus [0xcd800000-0xcdffffff] flags 0x12120c
[ 99.602307] pci 0000:4a:00.0: BAR 2: moved to bus [0xcd800000-0xcdffffff] flags 0x12120c
[ 99.615991] pci 0000:4a:00.0: BAR 0: got res [0xcf000000-0xcf0fffff] bus [0xcf000000-0xcf0fffff] flags 0x120204
[ 99.634499] pci 0000:4a:00.0: BAR 0: moved to bus [0xcf000000-0xcf0fffff] flags 0x120204
[ 99.654318] pci 0000:40:05.0: PCI bridge, secondary bus 0000:4a
[ 99.658766] pci 0000:40:05.0: IO window: disabled
[ 99.675478] pci 0000:40:05.0: MEM window: 0xcf000000-0xcf0fffff
[ 99.681663] pci 0000:40:05.0: PREFETCH window: 0x000000cd800000-0x000000cdffffffSo try to get a big range in the pci bridge if there is no child using
that range. With the patch we get:
[ 99.104525] pci 0000:4a:00.0: BAR 4: got res [0xfc080000000-0xfc08fffffff] bus [0xfc080000000-0xfc08fffffff] flags 0x12120c
[ 99.123624] pci 0000:4a:00.0: BAR 4: moved to bus [0xfc080000000-0xfc08fffffff] flags 0x12120c
[ 99.131977] pci 0000:4a:00.0: BAR 2: got res [0xfc090000000-0xfc0907fffff] bus [0xfc090000000-0xfc0907fffff] flags 0x12120c
[ 99.149788] pci 0000:4a:00.0: BAR 2: moved to bus [0xfc090000000-0xfc0907fffff] flags 0x12120c
[ 99.169248] pci 0000:4a:00.0: BAR 0: got res [0xc0200000-0xc02fffff] bus [0xc0200000-0xc02fffff] flags 0x120204
[ 99.189508] pci 0000:4a:00.0: BAR 0: moved to bus [0xc0200000-0xc02fffff] flags 0x120204
[ 99.206402] pci 0000:40:05.0: PCI bridge, secondary bus 0000:4a
[ 99.210637] pci 0000:40:05.0: IO window: disabled
[ 99.224856] pci 0000:40:05.0: MEM window: 0xc0200000-0xc03fffff
[ 99.230019] pci 0000:40:05.0: PREFETCH window: 0x000fc080000000-0x000fc097ffffffSigned-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes
10 Sep, 2009
1 commit
-
In general a BIOS may goof or we may hotplug in a hotplug controller.
In either case the kernel needs to reserve resources for plugging
in more devices in the future instead of creating a minimal resource
assignment.We already do this for cardbus bridges I am just adding a variant
for pcie bridges.v2: Make testing for pcie hotplug bridges based on a flag.
So far we only set the flag for pcie but a header_quirk
could easily be added for the non-standard pci hotplug
bridges.Signed-off-by: Eric W. Biederman
Signed-off-by: Jesse Barnes
30 Aug, 2009
1 commit
-
An SR-IOV capable device includes an SR-IOV PCIe capability which
describes the Virtual Function (VF) BAR requirements. A typical SR-IOV
device can support multiple VFs whose BARs must be in a contiguous region,
effectively an array of VF BARs. The BAR reports the size requirement
for a single VF. We calculate the full range needed by simply multiplying
the VF BAR size with the number of possible VFs and create a resource
spanning the full range.This all seems sane enough except it artificially inflates the alignment
requirement for the VF BAR. The VF BAR need only be aligned to the size
of a single BAR not the contiguous range of VF BARs. This can cause us
to fail to allocate resources for the BAR despite the fact that we
actually have enough space.This patch adds a thin PCI specific layer over the generic
resource_alignment() function which is aware of the special nature of
VF BARs and does sorting and allocation based on the smaller alignment
requirement.I recognize that while resource_alignment is generic, it's basically a
PCI helper. An alternative to this patch is to add PCI VF BAR specific
information to struct resource. I opted for the extra layer rather than
adding such PCI specific information to struct resource. This does
have the slight downside that we don't cache the BAR size and re-read
for each alignment query (happens a small handful of times during boot
for each VF BAR).Signed-off-by: Chris Wright
Cc: Ivan Kokshaysky
Cc: Linus Torvalds
Cc: Matthew Wilcox
Cc: Yu Zhao
Cc: stable@kernel.org
Signed-off-by: Jesse Barnes
12 Jun, 2009
2 commits
-
We could run out of space under under 4g, but devices under transparent
bridges can use 64bit resources, so keep trying on the parent bus until
we hit a non-transparent bridge.Impact: better support for assigning unassigned resources
Reviewed-by: Ivan Kokshaysky
Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
We should not assign 64bit ranges to PCI devices that only take 32bit
prefetchable addresses.Try to set IORESOURCE_MEM_64 in 64bit resource of pci_device/pci_bridge
and make the bus resource only have that bit set when all devices under
it support 64bit prefetchable memory. Use that flag to allocate
resources from that range.Reported-by: Yannick
Reviewed-by: Ivan Kokshaysky
Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes
23 Apr, 2009
1 commit
-
Remove outputs for 0 sized resources and indicate prefetchability.
Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes