- 02 Mar, 2012 1 commit
-
-
Myron Stowe authored
'pcibios_fwaddrmap_lookup()' is used to maintain FW-assigned BIOS BAR values for reinstatement when normal resource assignment attempts fail and must be called with the 'pcibios_fwaddrmap_lock' spinlock held. This patch adds a WARN_ON notification if the spinlock is not currently held by the caller. Signed-off-by:
Myron Stowe <myron.stowe@redhat.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
- 01 Mar, 2012 1 commit
-
-
Rafael J. Wysocki authored
There are PCIe devices on the market that report ARI support but then fail to initialize correctly when ARI is actually used. This leads to situations in which kernels 2.6.34 and newer fail to handle systems where the previous kernels worked without any apparent problems. Unfortunately, it is currently unknown how many such devices are there. For this reason, introduce a new kernel command line option, pci=noari, allowing users to disable PCIe ARI altogether if they see problems with PCIe device initialization. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
- 27 Feb, 2012 4 commits
-
-
Yinghai Lu authored
pci_stop_bus_device gets called before in the same loop. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Yinghai Lu authored
Don't switch to pci_remove_bus_device yet, keep the __ prefix for now (the behavior is still the same: remove without stopping first). This allows other out of tree users or pending patches to get notified from compiler warning. Signed-off-by:
-
Yinghai Lu authored
The old pci_remove_behind_bridge actually do stop and remove. Make the name reflect that to reduce confusion. Suggested-by:
-
Yinghai Lu authored
The old pci_remove_bus_device actually did stop and remove. Make the name reflect that to reduce confusion. This patch is done by sed scripts and changes back some incorrect __pci_remove_bus_device changes. Suggested-by:
-
- 24 Feb, 2012 34 commits
-
-
Yinghai Lu authored
Makes it a little easier to figure out which device may have caused a slow quirk. Signed-off-by:
-
Yinghai Lu authored
This isn't really a quirk; calling it directly from pci_add_device makes more sense. Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Recently added support to allow quirks to report duration also make the boot log very crowded when initcall_debug is specified. One thing we can to do mitigate this is to not call quirks unnecessarily by adding a new quirk declaration macro that takes a class argument. The new macro takes a class value and a class shift value (since it can vary) so that quirks will be limited to certain device classes, greatly reducing the number we call on every PCI device addition. -v2: fix v1 that left over of sparated patch. -v3: according to Jesse, change cls to class, cls_shift, to class_shift. Signed-off-by:
-
Jesse Barnes authored
Merge branch 'pci-next+probe_only+bus2res-fb127cb9' of git://github.com/bjorn-helgaas/linux into linux-next
-
Yinghai Lu authored
Add a new config option, PCI_REALLOC_ENABLE_AUTO, which will automatically try to re-allocate PCI resources if PCI_IOV support is enabled and the SR-IOV resources are unassigned. Behavior can still be controlled using the pci=realloc= parameter. -v2: According to Jesse, adding one CONFIG option for distribution to disable it or enable it. -v3: update Kconfig text (jbarnes) Signed-off-by: -
Yinghai Lu authored
let user know they could try if pci=realloc could help. -v2: update suggestion text. Suggested-by:
-
Yinghai Lu authored
Let the user could enable and disable with pci=realloc=on or pci=realloc=off Also 1. move variable and functions near the place they are used. 2. change macro to function 3. change related functions and variable to static and _init 4. update parameter description accordingly. This will let us add a config option to control default behavior, and still allow the user to turn off automatic reallocation if it fails on their platform until a permanent solution is found. -v2: still honor pci=realloc, and treat it as pci=realloc=on also use enum instead of ... -v3: update kernel-paramenters.txt according to Jesse. Signed-off-by: -
Yinghai Lu authored
When enabling pci reallocation for a pci bridge, we clear the small size in in bridge and re-assign with requested + optional size for first several tries, but Ram mention could have problem with one case: https://bugzilla.kernel.org/show_bug.cgi?id=15960 After checking the booting log in https://lkml.org/lkml/2010/4/19/44 [regression, bisected] Xonar DX invalid PCI I/O range since 977d17bb We should not stop too early for io ports. Apr 19 10:19:38 [kernel] pci 0000:04:00.0: BAR 7: can't assign io (size 0x4000) Apr 19 10:19:38 [kernel] pci 0000:05:01.0: BAR 8: assigned [mem 0x80400000-0x805fffff] Apr 19 10:19:38 [kernel] pci 0000:05:01.0: BAR 7: can't assign io (size 0x2000) Apr 19 10:19:38 [kernel] pci 0000:05:02.0: BAR 7: can't assign io (size 0x1000) Apr 19 10:19:38 [kernel] pci 0000:05:03.0: BAR 7: can't assign io (size 0x1000) Apr 19 10:19:38 [kernel] pci 0000:08:00.0: BAR 7: can't assign io (size 0x1000) Apr 19 10:19:38 [kernel] pci 0000:09:04.0: BAR 0: can't assign io (size 0x100) and clear 00:1c.0 to retry again. This patch removes IORESOUCE_IO checking, and tries one more time. It gives us a chance to get an allocation for the 00:1c.0 io port range because the range from 0x4000 to 0x8000 will be freed and we can use it. Signed-off-by:
-
Bjorn Helgaas authored
Everybody uses the generic pcibios_resource_to_bus() supplied by the core now, so remove the ARCH_HAS_GENERIC_PCI_OFFSETS used during conversion. Signed-off-by:Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: Chris Zankel <chris@zankel.net> Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. N.B. Leon apparently never uses initial BAR values, so it didn't matter that we never fixed up the I/O resources from bus address to CPU addresses. Other sparc uses pci_of_scan_bus(), which sets device resources directly to CPU addresses, not bus addresses, so it didn't need pcibios_fixup_bus() either. But by telling the core about the offsets, we can nuke pcibios_resource_to_bus(). CC: "David S. Miller" <davem@davemloft.net> CC: sparclinux@vger.kernel.org Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: Paul Mundt <lethal@linux-sh.org> Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: linux-parisc@vger.kernel.org Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: David Howells <dhowells@redhat.com> Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. Here's the wrinkle on Cobalt: we can't generate normal I/O port addresses on PCI because the GT-64111 doesn't do any address translation, so we have this: CPU I/O port addresses [io 0x0000-0xffffff] PCI bus I/O port addresses [io 0x10000000-0x10ffffff] Legacy-mode IDE controllers start out with the legacy bus addresses, e.g., 0x1f0, assigned by pci_setup_device(). These are outside the range of addresses GT-64111 can generate on PCI, but pcibios_fixup_device_resources() converted them to CPU addresses anyway by adding io_offset. Therefore, we had to pre-adjust them in cobalt_legacy_ide_fixup(). With io_offset = 0xf0000000, we had this: res->start = 0x1f0 initialized in pci_setup_device() res->start = 0x100001f0 -= io_offset in cobalt_legacy_ide_fixup() res->start = 0x1f0 += io_offset in pcibios_fixup_device_resources() The difference after this patch is that the generic pci_bus_to_resource() only adds the offset if the bus address is inside a host bridge window. Since 0x1f0 is not a valid bus address and is not inside any windows, it is unaffected, so we now have this: region->start = 0x1f0 initialized in pci_setup_device() res->start = 0x1f0 no offset by pci_bus_to_resource() That means we can remove both pcibios_fixup_device_resources() and cobalt_legacy_ide_fixup(). I would *rather* set the host bridge offset to zero (which corresponds to what the GT-64111 actually does), and have both CPU and PCI addresses of [io 0x10000000-0x10ffffff]. However, that would require changes to generic code that assumes legacy I/O addresses, such as pic1_io_resource ([io 0x0020-0x00021]), and we'd have to keep a Cobalt IDE fixup. Of course, none of this changes the fact that references to I/O port 0x1f0 actually go to port 0x100001f0, not 0x1f0, on the Cobalt PCI bus. Fortunately the VT82C586 IDE controller only decodes the low 24 address bits, so it does work. CC: Ralf Baechle <ralf@linux-mips.org> CC: Yoichi Yuasa <yuasa@linux-mips.org> Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: Michal Simek <monstr@monstr.eu> Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: Tony Luck <tony.luck@intel.com> CC: Jack Steiner <steiner@sgi.com> Signed-off-by: -
Bjorn Helgaas authored
Convert from pci_scan_bus() to pci_scan_root_bus(). Supply the root bus resources from bussoft. When we move the resource adjustment from pcibios_fixup_resources() to the PCI core, it will be important to have the root bus resources correct from the beginning. CC: Tony Luck <tony.luck@intel.com> CC: Jack Steiner <steiner@sgi.com> Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: Russell King <linux@arm.linux.org.uk> Signed-off-by: -
Bjorn Helgaas authored
Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: linux-alpha@vger.kernel.org Signed-off-by: -
Bjorn Helgaas authored
This replaces the generic versions of pcibios_resource_to_bus() and pcibios_bus_to_resource() in asm-generic/pci.h with versions that use pci_resource_to_bus() and pci_bus_to_resource(). The replacements are equivalent except that they can apply host bridge window offsets when the arch has supplied them by using pci_add_resource_offset(). Each arch can convert to using pci_add_resource_offset() individually by removing its device resource fixups from pcibios_fixup_bus() and supplying ARCH_HAS_GENERIC_PCI_OFFSETS. ARCH_HAS_GENERIC_PCI_OFFSETS can be removed after all have converted. Signed-off-by: -
Bjorn Helgaas authored
Some PCI host bridges translate CPU addresses to PCI bus addresses. Previously, we initialized pci_dev resources with PCI bus addresses, then converted them to CPU addresses later in arch-specific code (pcibios_fixup_resources()), which leaves a window of time where the pci_dev resources are incorrect. This patch adds support in the core for this address translation. When the arch creates the root bus, it can supply the host bridge address translation information, and the core can use it to set the pci_dev resources correctly from the beginning. This gives us a way to fix the problem that quirks that run between device discovery and pcibios_fixup_resources() fail because they use pci_dev resources that haven't been converted. The reference below is to one such problem that affected ARM and ia64. Note that this patch has no effect until an arch starts using pci_add_resource_offset() with a non-zero offset: before that, all all host bridge windows have a zero offset and pci_bus_to_resource() copies the pci_bus_region directly to the struct resource. Reference: https://lkml.org/lkml/2009/10/12/405Signed-off-by:
-
Bjorn Helgaas authored
Some PCI host bridges apply an address offset, so bus addresses on PCI are different from CPU addresses. This patch adds a way for architectures to tell the PCI core about this offset. For example: LIST_HEAD(resources); pci_add_resource_offset(&resources, host->io_space, host->io_offset); pci_add_resource_offset(&resources, host->mem_space, host->mem_offset); pci_scan_root_bus(parent, bus, ops, sysdata, &resources); Signed-off-by:
-
