- Mar 20, 2012
-
-
Bjorn Helgaas authored
Move this include to be consistent with other architectures. CC: Guan Xuetao <gxt@mprc.pku.edu.cn> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Bjorn Helgaas authored
Normal PCI enumeration via PCI config space uses __pci_read_base(), where the PCI core applies any bus-to-resource offset. But sparc sometimes reads PCI config space itself, and sometimes it gets addresses from the device tree. In ac1edcc5, I converted sparc to use the PCI core bus-to-resource conversion, but I missed these sparc-specific paths. I don't have a way to test it, but I think sparc is broken between that commit and this one. This patch replaces the sparc-specific pci_resource_adjust() with the generic pcibios_bus_to_resource() in the following paths: pci_cfg_fake_ranges() (addresses read from PCI config) apb_fake_ranges() (addresses computed based on PCI config) of_scan_pci_bridge() (addresses from OF "ranges" property) N.B.: Resources of non-P2P bridge devices are set in pci_parse_of_addrs() and, as far as I can see, never converted to CPU addresses. I do not understand why these would be treated differently than bridge windows. CC: "David S. Miller" <davem@davemloft.net> CC: sparclinux@vger.kernel.org Signed-off-by:
-
Bjorn Helgaas authored
We believe there's no reason to prevent reallocation on PA Semi, so revert to the default of "allow reallocation if necessary." Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: linuxppc-dev@lists.ozlabs.org Tested-by:
Olof Johansson <olof@lixom.net> Acked-by:
-
Bjorn Helgaas authored
Normal PCI enumeration via PCI config space uses __pci_read_base(), where the PCI core applies any bus-to-resource offset. But powerpc doesn't use that path when enumerating via the device tree. In 6c5705fe, I converted powerpc to use the PCI core bus-to-resource conversion, but I missed these powerpc-specific paths. Some powerpc platforms fail to boot ("Cannot allocate resource region," "device not available," etc.) between that commit and this one. This adds the corresponding bus-to-resource conversion in the paths that read BAR values from the OF device tree. CC: Anton Blanchard <anton@samba.org> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
Bjorn Helgaas authored
Make sure we compute CPU addresses (resource start/end) the same way both when we set up the I/O aperture (hose->io_resource) and when we use pcibios_bus_to_resource() to convert BAR values into resources. This fixes a build failure ("cast from pointer to integer of different size" in configs where resource_size_t is 64 bits but pointers are 32 bits) I introduced in 6c5705fe. Acked-By: -
Bjorn Helgaas authored
There's no need to export pci_flags; it's not exported by any other architecture, and no modules reference it. CC: Rob Herring <rob.herring@calxeda.com> CC: Russell King <linux@arm.linux.org.uk> CC: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Bjorn Helgaas authored
In 5bfa14ed, I forgot to initialize res2.flags before calling pcibios_bus_to_resource(), which depends on the resource type to locate the correct aperture. This bug won't hurt x86, which currently never has an offset between bus and CPU addresses, but will affect other architectures. Signed-off-by:
-
- Mar 02, 2012
-
-
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:
-
- Mar 01, 2012
-
-
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:
-
- Feb 27, 2012
-
-
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:
-
- Feb 24, 2012
-
-
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 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:
-
