summaryrefslogtreecommitdiffstats
path: root/drivers/pci/setup-bus.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* pci: don't reassign to ROM res if it is not going to be enabledYinghai Lu2010-03-011-2/+10
| | | | | | | | | 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 <yinghai@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: add pci_bus_for_each_resource(), remove direct bus->resource[] refsBjorn Helgaas2010-02-231-6/+4
| | | | | | | | | | | | 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 <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: set PCI_PREF_RANGE_TYPE_64 in pci_bridge_check_rangesYinghai Lu2010-02-231-1/+4
| | | | | | | | 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 <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: pciehp: second try to get big range for pcie devicesYinghai Lu2010-02-231-1/+50
| | | | | | | | | 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 <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: introduce pci_assign_unassigned_bridge_resourcesYinghai Lu2010-02-231-27/+89
| | | | | | | | | | | | 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 <yinghai@kernel.org> Reviewed-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: update bridge resources to get more big ranges in PCI assign unssignedYinghai Lu2010-02-231-2/+112
| | | | | | | | | | | | | | | 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 again Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: don't shrink bridge resourcesYinghai Lu2010-02-231-2/+12
| | | | | | | | | | 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 <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: add failed_list to pci_bus_assign_resourcesYinghai Lu2010-02-231-4/+57
| | | | | | | | | This allows us to track failed allocations for later re-trying with reallocation. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Reviewed-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: add pci_bridge_release_resources and pci_bus_release_bridge_resourcesYinghai Lu2010-02-231-0/+82
| | | | | | | | | 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 <yinghai@kernel.org> Reviewed-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: don't dump resource when bus resource flags indicates unusedYinghai Lu2010-02-231-1/+2
| | | | | | | | Don't print out resources without flags to avoid cluttering up the debug output. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: separate pci_setup_bridge to small functionsYinghai Lu2010-02-231-16/+50
| | | | | | | | | This is a good cleanup in itself, and makes it easier to modify specific resource types in later code. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Always set prefetchable base/limit upper32 registersAlex Williamson2009-12-051-8/+3
| | | | | | | | | | | | | | | | | 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 - 0x00000000abc00000 Revert 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 <alex.williamson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: improve discovery/configuration messagesBjorn Helgaas2009-11-041-6/+15
| | | | | | | | | | | 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 <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* vsprintf: use %pR, %pr instead of %pRt, %pRfBjorn Helgaas2009-11-041-43/+36
| | | | | | | | | | | | | | | | | 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/441 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: print resources consistently with %pRtBjorn Helgaas2009-11-041-6/+3
| | | | | | | | This uses %pRt to print additional resource information (type, size, prefetchability, etc.) consistently. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Revert "PCI: get larger bridge ranges when space is available"Jesse Barnes2009-10-271-11/+2
| | | | | | | | 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 <jbarnes@virtuousgeek.org>
* PCI: get larger bridge ranges when space is availableYinghai Lu2009-10-071-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=4a Device 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-0x000000cdffffff So 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-0x000fc097ffffff Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: pcie: Ensure hotplug ports have a minimum number of resourcesEric W. Biederman2009-09-091-5/+17
| | | | | | | | | | | | | | | | | | | 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 <ebiederm@aristanetworks.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI SR-IOV: correct broken resource alignment calculationsChris Wright2009-08-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <chrisw@sous-sol.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Yu Zhao <yu.zhao@intel.com> Cc: stable@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: improve resource allocation under transparent bridgesYinghai Lu2009-06-111-1/+0
| | | | | | | | | | | | 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 <ink@jurassic.park.msu.ru> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI/x86: don't assume prefetchable ranges are 64bitYinghai Lu2009-06-111-10/+42
| | | | | | | | | | | | | | | 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 <yannick.roehlly@free.fr> Reviewed-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: cleanup debug output resourcesYinghai Lu2009-04-221-2/+4
| | | | | | | Remove outputs for 0 sized resources and indicate prefetchability. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Setup disabled bridges even if buses are addedYuji Shimada2009-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch sets up disabled bridges even if buses have already been added. pci_assign_unassigned_resources is called after buses are added. pci_assign_unassigned_resources calls pci_bus_assign_resources. pci_bus_assign_resources calls pci_setup_bridge to configure BARs of bridges. Currently pci_setup_bridge returns immediately if the bus have already been added. So pci_assign_unassigned_resources can't configure BARs of bridges that were added in a disabled state; this patch fixes the issue. On logical hot-add, we need to prevent the kernel from re-initializing bridges that have already been initialized. To achieve this, pci_setup_bridge returns immediately if the bridge have already been enabled. We don't need to check whether the specified bus is a root bus or not. pci_setup_bridge is not called on a root bus, because a root bus does not have a bridge. The patch adds a new helper function, pci_is_enabled. I made the function name similar to pci_is_managed. The codes which use enable_cnt directly are changed to use pci_is_enabled. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: do not initialize bridges more than onceAlex Chiang2009-03-201-0/+3
| | | | | | | | | | | | In preparation for PCI core hotplug, we need to ensure that we do not attempt to re-initialize bridges that have already been initialized. We only need to worry about non-root buses, since we will not allow root bus removal. Reported-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: constify pci_bus_assign_resources()Andrew Morton2009-03-201-2/+2
| | | | | | | | drivers/pci/hotplug/fakephp.c: In function 'pci_rescan_bus': drivers/pci/hotplug/fakephp.c:271: warning: passing argument 1 of 'pci_bus_assign_resources' discards qualifiers from pointer target type Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: use dev_printk for PCI bus resource mssagesBjorn Helgaas2009-01-071-3/+2
| | | | | | | | Since pci_bus has a struct device, use dev_printk directly instead of faking it by hand. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: make PCI bus resource messages more meaningfulBjorn Helgaas2009-01-071-3/+3
| | | | | | | | | | | | | | | Change PCI bus resource messages so they have a bit more context and look like the rest of PCI, e.g., - bus: 00 index 0 io port: [0x00-0xffff] - bus: 00 index 1 mmio: [0x000000-0xffffffff] + pci 0000:00: bus resource 0 io : [0x00-0xffff] + pci 0000:00: bus resource 1 mem: [0x000000-0xffffffff] This also changes them from KERN_INFO to KERN_DEBUG. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: use resource_size() everywhere.Zhao, Yu2008-10-201-2/+2
| | | | | | | | This is a cleanup that replaces the resource calculation formula with resource_size(). Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* pci: Use new %pR to print resource rangesBenjamin Herrenschmidt2008-10-201-9/+4
| | | | | | | | | This converts things in drivers/pci to use %pR to printout the content of a struct resource instead of hand-casted %llx or other variants. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
*---. Merge branches 'core/softlockup', 'core/softirq', 'core/resources', ↵Ingo Molnar2008-10-151-5/+4
|\ \ \ | | | | | | | | | | | | 'core/printk' and 'core/misc' into core-v28-for-linus
| | * | generic: redefine resource_size_t as phys_addr_tJeremy Fitzhardinge2008-09-141-5/+4
| |/ / | | | | | | | | | | | | | | | | | | | | | There's no good reason why a resource_size_t shouldn't just be a physical address, so simply redefine it in terms of phys_addr_t. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | | Merge branch 'for-linus' of ↵Linus Torvalds2008-09-131-1/+5
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: re-add debug prints for unmodified BARs PCI: fix pciehp_free_irq() PCI Hotplug: fakephp: fix deadlock... again PCI: Fix printk warnings in setup-bus.c PCI: Fix printk warnings in probe.c PCI/iommu: blacklist DMAR on Intel G31/G33 chipsets
| * | PCI: Fix printk warnings in setup-bus.cJohann Felix Soden2008-09-091-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Again, the cleaned up code introduced some resource warnings: drivers/pci/setup-bus.c: In function 'pci_bus_dump_res': drivers/pci/setup-bus.c:542: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t' drivers/pci/setup-bus.c:542: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t' Fix those up too. Signed-off-by: Johann Felix Soden <johfel@users.sourceforge.net> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | | PCI: fix pbus_size_mem() resource alignment for CardBus controllersLinus Torvalds2008-09-041-2/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 884525655d07fdee9245716b998ecdc45cdd8007 ("PCI: clean up resource alignment management") changed the resource handling to mark how a resource was aligned on a per-resource basis. Thus, instead of looking at the resource number to determine whether it was a bridge resource or a regular resource (they have different alignment rules), we should just ask the resource for its alignment directly. The reason this broke only cardbus resources was that for the other types of resources, the old way of deciding alignment actually still happened to work. But CardBus bridge resources had been changed by commit 934b7024f0ed29003c95cef447d92737ab86dc4f ("Fix cardbus resource allocation") to look more like regular resources than PCI bridge resources from an alignment handling standpoint. Reported-and-tested-by: Andrew Morton <akpm@linux-foundation.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'linus' into pci-for-jesseIngo Molnar2008-07-181-25/+18
|\|
| * PCI: use dev_printk when possibleBjorn Helgaas2008-06-261-25/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert printks to use dev_printk(). I converted pr_debug() to dev_dbg(). Both use KERN_DEBUG and are enabled only when DEBUG is defined. I converted printk(KERN_DEBUG) to dev_printk(KERN_DEBUG), not to dev_dbg(), because dev_dbg() is only enabled when DEBUG is defined. I converted DBG(KERN_INFO) (only in setup-bus.c) to dev_info(). The DBG() name makes it sound like debug, but it's been enabled forever, so dev_info() preserves the previous behavior. I tried to make the resource assignment formats more consistent, e.g., "BAR %d: got res [%#llx-%#llx] bus [%#llx-%#llx] flags %#lx\n" instead of sometimes using "start-end" and sometimes using "size@start". I'm not attached to one or the other; I'd just like them consistent. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | pci: debug extra pci bus resourcesYinghai Lu2008-06-231-0/+35
|/ | | | Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Fix cardbus resource allocationLinus Torvalds2008-04-231-15/+15
| | | | | | | | | | | | | | | | | | | | | | | Commit 884525655d07fdee9245716b998ecdc45cdd8007 ("PCI: clean up resource alignment management") didn't set the alignment information for the cardbus window resources, causing their subsequent allocations to fail miserably with a message like yenta_cardbus 0000:15:00.0: device not available because of BAR 7 [100:1ff] collisions yenta_cardbus: probe of 0000:15:00.0 failed with error -16 or similar. This fixes it and clarifies the code a bit too (we used to have to use the insane PCI bridge alignment logic that put the alignment in the "start" field, this makes it use the slightly easier-to-understand size-based alignment, and allows us to set the resource start to zero until it gets allocated). Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: pci_setup_bridge() mustn't be __devinitAdrian Bunk2008-04-211-2/+1
| | | | | | | | | WARNING: drivers/pci/built-in.o(.text+0x28ee9): Section mismatch in reference from the function pci_bus_assign_resources() to the function .devinit.text:pci_setup_bridge() Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: pci_bus_size_cardbus() mustn't be __devinitAdrian Bunk2008-04-211-2/+1
| | | | | | | | | WARNING: drivers/pci/built-in.o(.text+0x28e1f): Section mismatch in reference from the function pci_bus_size_bridges() to the function .devinit.text:pci_bus_size_cardbus() Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: clean up resource alignment managementIvan Kokshaysky2008-04-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Done per Linus' request and suggestions. Linus has explained that better than I'll be able to explain: On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote: > Actually, before we go any further, there might be a less intrusive > alternative: add just a couple of flags to the resource flags field (we > still have something like 8 unused bits on 32-bit), and use those to > implement a generic "resource_alignment()" routine. > > Two flags would do it: > > - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device > resources) > > - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources > during probing) > > and then the case of both flags zero (or both bits set) would actually be > "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we > actually allocate the resource (so that we don't use the "start" field as > alignment incorrectly when it no longer indicates alignment). > > That wouldn't be totally generic, but it would have the nice property of > automatically at least add sanity checking for that whole "res->start has > the odd meaning of 'alignment' during probing" and remove the need for a > new field, and it would allow us to have a generic "resource_alignment()" > routine that just gets a resource pointer. Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages. Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Revert "PCI: remove transparent bridge sizing"Linus Torvalds2008-03-261-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f, which caused various interesting problems for people, including wrong resource allocations. See for example bugzilla entry "2.6.25-rc2: ohci1394 problem (MMIO broken)" at http://bugzilla.kernel.org/show_bug.cgi?id=10080 And Gary Hade says: "The same change had also exposed an issue reported by Paul Martin that has been causing an Oops while hotplugging ThinkPads to a ThinkPad Dock II. See http://lkml.org/lkml/2008/2/19/405 http://bugzilla.kernel.org/show_bug.cgi?id=9961 I have a fix for the ThinkPad docking Oops but if the issue being discussed here is caused by the transparent bridge sizing removal change I totally agree that it should be reverted." The transparent bridge sizing removal change was motivated by insufficient PCI memory resource for a transparent bridge window that was being created as a result of expansion ROM(s) being included in the transparent bridge sizing calculations. A later "PCI: Remove default PCI expansion ROM memory allocation" change ( re: http://lkml.org/lkml/2007/12/11/361 ) removes the expansion ROM(s) from the transparent bridge sizing calculations which actually resolves the original issue in a different manner. So, even if the "PCI: remove transparent bridge sizing" is not problematic it is no longer needed anyway." Identified-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Tested-by: Thomas Meyer <thomas@m3y3r.de> Acked-by: Gary Hade <garyhade@us.ibm.com> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: fix up setup-bus.c #ifdefAndrew Morton2008-02-221-4/+2
| | | | | | | | | Use upper_32_bits(): no code changes, one less ifdef. Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: fix 4x section mismatch warningsSam Ravnborg2008-02-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | The following warnings were issued during build of drivers/pci with an allyesconfig build: WARNING: o-x86_64/drivers/pci/built-in.o(.text+0xdaf): Section mismatch in reference from the function pci_add_new_bus() to the function .devinit.text:pci_alloc_child_bus() WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x15e2): Section mismatch in reference from the function pci_scan_single_device() to the function .devinit.text:pci_scan_device() WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x1b0c5): Section mismatch in reference from the function pci_bus_assign_resources() to the function .devinit.text:pci_setup_bridge() WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x1b32d): Section mismatch in reference from the function pci_bus_size_bridges() to the function .devinit.text:pci_bus_size_cardbus() Investigating each case closer it looked like all referred functions are only used in the init phase or during hotplug. So to avoid wasting too much memory in the non-hotplug case the simpler fix was to allow the fuctions to use code/data from the __devinit sections. This was done in all four case by adding the __ref annotation. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Adrian Bunk <bunk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: Fix bus resource assignment on 32 bits with 64b resourcesBenjamin Herrenschmidt2008-02-021-24/+40
| | | | | | | | | | | | | The current pci_assign_unassigned_resources() code doesn't work properly on 32 bits platforms with 64 bits resources. The main reason is the use of unsigned long in various places instead of resource_size_t. This is a pre-requisite for making powerpc use the generic code instead of its own half-useful implementation. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: remove transparent bridge sizingGary Hade2007-10-131-0/+5
| | | | | | | | | | | | | | | Remove transparent bridge sizing. Due to code in pci_read_bridge_bases() [drivers/pci/probe.c] the child bus of a transparent bridge already has access to the parent bus resources so transparent bridge sizing appears unnecessary. The bridge sizing includes alignment and granularity adjustments that can cause significantly more memory to be reserved from the parant bus than required by devices on the child bus and allotted by _CRS. Signed-off-by: Gary Hade <gary.hade@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: ROUND_UP macro cleanup in drivers/pciMilind Arun Choudhary2007-07-121-5/+3
| | | | | | | | | | ROUND_UP macro cleanup, use ALIGN where ever appropriate Signed-off-by: Milind Arun Choudhary <milindchoudhary@gmail.com> Acked-by: Scott Murray <scottm@somanetworks.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* pci: do not mark exported functions as __devinitSam Ravnborg2007-05-031-14/+7
| | | | | | | | | | | | | | | | | | | | | | | Functions marked __devinit will be removed after kernel init. But being exported they are potentially called by a module much later. So the safer choice seems to be to keep the function even in the non CONFIG_HOTPLUG case. This silence the follwoing section mismatch warnings: WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_device from __ksymtab_gpl between '__ksymtab_pci_bus_add_device' (at offset 0x20) and '__ksymtab_pci_walk_bus' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_create_bus from __ksymtab_gpl between '__ksymtab_pci_create_bus' (at offset 0x40) and '__ksymtab_pci_stop_bus_device' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_max_busnr from __ksymtab_gpl between '__ksymtab_pci_bus_max_busnr' (at offset 0xc0) and '__ksymtab_pci_assign_resource_fixed' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_claim_resource from __ksymtab_gpl between '__ksymtab_pci_claim_resource' (at offset 0xe0) and '__ksymtab_pcie_port_bus_type' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_devices from __ksymtab between '__ksymtab_pci_bus_add_devices' (at offset 0x70) and '__ksymtab_pci_bus_alloc_resource' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_scan_bus_parented from __ksymtab between '__ksymtab_pci_scan_bus_parented' (at offset 0x90) and '__ksymtab_pci_root_buses' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_assign_resources from __ksymtab between '__ksymtab_pci_bus_assign_resources' (at offset 0x4d0) and '__ksymtab_pci_bus_size_bridges' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_size_bridges from __ksymtab between '__ksymtab_pci_bus_size_bridges' (at offset 0x4e0) and '__ksymtab_pci_setup_cardbus' Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE boot optionsAtsushi Nemoto2007-02-171-17/+10
| | | | | | | | | | | | | | | | CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size might result in allocation failure for the reserving itself on some platforms (for example typical 32bit MIPS). Make it (and CARDBUS_IO_SIZE too) customizable by "pci=" option for such platforms. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] increase CARDBUS_MEM_SIZEAndrew Morton2006-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linus sayeth: Google knows everything, and finds, on MS own site no less: "Windows 2000 default resources: One 4K memory window One 2 MB memory window Two 256-byte I/O windows" which is clearly utterly bogus and insufficient. But Microsoft apparently realized this, and: "Windows XP default resources: Because one memory window of 4K and one window of 2 MB are not sufficient for CardBus controllers in many configurations, Windows XP allocates larger memory windows to CardBus controllers where possible. However, resource windows are static (that is, the operating system does not dynamically allocate larger memory windows if new devices appear.) Under Windows XP, CardBus controllers will be assigned the following resources: One 4K memory window, as in Windows 2000 64 MB memory, if that amount of memory is available. If 64 MB is not available the controller will receive 32 MB; if 32 MB is not available, the controller will receive 16 MB; if 16 MB is not available, the bridge will receive 8 MB; and so on down to a minimum assignment of 1 MB in configurations where memory is too constrained for the operating system to provide a larger window. Two 256-byte I/O windows" So I think we have our answer. Windows uses one 4k window, and one 64MB window. And they are no more dynamic than we are (we _could_ try to do it dynamically, but let's face it, it's fairly painful to dynamically expand PCI bus resources - you may need to reprogram everything up to the root, so it would be absolutely crazy to do that unless you have some serious masochistic tendencies). So let's just increase our default value to 64M too. Cc: Markus Rechberger <mrechberger@gmail.com> Cc: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 19:12:31 +0100