summaryrefslogtreecommitdiffstats
path: root/drivers/pci
AgeCommit message (Collapse)Author
2014-09-16PCI: tegra: Add Tegra124 supportThierry Reding
The PCIe controller on Tegra124 has two root ports that can be used in a x4/x1 or x2/x1 configuration and can run at PCIe 2.0 link speeds (up to 5 GT/s). The PHY programming has been moved into a separate controller, so the driver now needs to request an external PHY referenced using the device tree. Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-16PCI: tegra: Make sure the PCIe PLL is really resetEric Yuen
Depending on the prior state of the controller, the PLL reset may not be pulsed. Clear the register bit and set it after a small delay to ensure that the PLL is really reset. Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Eric Yuen <eyuen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-16PCI: tegra: Fix extended configuration space mappingPeter Daifuku
The 16 chunks of 64 KiB that need to be stitched together to make up the configuration space for one bus (1 MiB) are located 24 bits (== 16 MiB) apart in physical address space. This is determined by the start of the extended register field (bits 24-27) in the physical mapping. Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Peter Daifuku <pdaifuku@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-16PCI: tegra: Clear CLKREQ# enable on port disableThierry Reding
When a root port is disabled, disable the CLKREQ# signal if available. Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-16PCI: Increase IBM ipr SAS Crocodile BARs to at least system page sizeDouglas Lehr
The Crocodile chip occasionally comes up with 4k and 8k BAR sizes. Due to an erratum, setting the SR-IOV page size causes the physical function BARs to expand to the system page size. Since ppc64 uses 64k pages, when Linux tries to assign the smaller resource sizes to the now 64k BARs the address will be truncated and the BARs will overlap. Force Linux to allocate the resource as a full page, which avoids the overlap. [bhelgaas: print expanded resource, too] Signed-off-by: Douglas Lehr <dllehr@us.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Milton Miller <miltonm@us.ibm.com> CC: stable@vger.kernel.org
2014-09-16PCI: Use device flag helper functionsEthan Zhao
Use PCI device flag helper functions when checking whether a device is assigned. No functional change. Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-16PCI: keystone: Set device ID based on SoC to support multiple portsMurali Karicheri
K2E SoC has two PCI ports. The SATA controller is connected to second PCI port (port 1). To support multiple port handling in Keystone PCI driver, read the PCI device ID dynamically by iomap/read/unmap during probe and save it in driver's private data and update it in host init code. The PCI device ID field in the RC's config space is not filled by default by the hardware and has to be updated by the PCI driver by reading the same from the SoC register indicated by reg index #2 in DT bindings. Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-16PCI: keystone: Assume controller is already in RC modeMurali Karicheri
Keystone PCI hardware supports both RC and EP modes and devcfg register has bits to boot strap the device to either of these modes. It seems proper to add this functionality to the boot loader rather than in the driver as device will be operating in either mode, not both any time. Currently the driver supports only RC mode and hence register configuration in the driver is not needed and the driver can assume the hardware is in RC mode. Also update the DT documentation accordingly. Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2014-09-16PCI: keystone: Limit MRSS for all downstream devicesMurali Karicheri
Keystone PCIe controller has a limitation that memory read request size must not exceed 256 bytes. This is a hardware limitation. Add a quirk to force this limit on all downstream devices by updating MRRS. Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-16PCI: pciehp: Prevent NULL dereference during probeAndreas Noever
pciehp assumes that dev->subordinate, the struct pci_bus for a bridge's secondary bus, exists. But we do not create that bus if we run out of bus numbers during enumeration. This leads to a NULL dereference in init_slot() (and other places). Change pciehp_probe() to return -ENODEV when no secondary bus is present. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.2+
2014-09-15Merge branch 'pci/hotplug-vga' into for-linusBjorn Helgaas
* pci/hotplug-vga: ACPIPHP / radeon / nouveau: Remove acpi_bus_no_hotplug() PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device
2014-09-12PCI: pciehp: Reduce PCIe slot_ctrl to 16 bitsBjorn Helgaas
4283c70e91dc ("PCI: pciehp: Make pcie_wait_cmd() self-contained") added a cache of the most recent command written to the Slot Control register. This register is only 16 bits wide, but the cache ("slot_ctrl") is 32 bits. Reduce slot_ctrl to a u16 so it matches the register size. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-12PCI: Configure *all* devices, not just hot-added onesBjorn Helgaas
There's not really a good way to determine whether firmware has already configured a device with _HPP/_HPX settings. On legacy systems, the BIOS has probably configured everything, but on UEFI systems it is not required to do so. Per the PCI Firmware Specification, rev 3.1, sec 3.5, if PCI_COMMAND_IO or PCI_COMMAND_MEMORY is set, we can assume firmware has set the corresponding BARs and maybe we can assume it has configured the rest of the device. And if a bridge has PCI_COMMAND_PARITY or PCI_COMMAND_SERR set, we can assume firmware has configured the bridge. But we can't tell much about devices without BARs. I think it should be safe to apply _HPP and _HPX settings anyway, even if firmware has already configured the device, so configure everything we find. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Preserve MPS and MRRS when applying _HPX settingsBjorn Helgaas
Linux manages MPS and MRRS settings to keep them consistent across the PCIe fabric. BIOS doesn't participate in this Linux management, so ignore that part of any _HPX settings it supplies. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Apply _HPP settings to all hot-added PCI devicesBjorn Helgaas
We currently apply _HPP settings only to: - non-bridge devices, and - PCI-to-PCI bridges i.e., we do not apply them to PCI-to-ISA bridges and the like. It has been that way since _HPP support was added by 40abb96c51bb ("pciehp: Fix programming hotplug parameters"), but I don't think there's any reason to exclude these other bridges. Apply _HPP settings to hot-added PCI devices of any type. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Preserve BIOS PCI_COMMAND_SERR and PCI_COMMAND_PARITY settingsBjorn Helgaas
Do not clear PCI_COMMAND_SERR or PCI_COMMAND_PARITY based on _HPP. The spec (ACPI rev 5.0, sec 6.2.7) says that when "Enable SERR" is set to 1, we should enable SERR in the command register. It says nothing about *disabling* SERR or PERR; in fact, the example in 6.2.7.1 says we should leave PERR alone unless "Enable PERR" is 1. For hot-added devices, this probably doesn't matter because they power up with these bits cleared. But in addition to hot-plugged devices, the spec allows the platform to use _HPP for "configuration of PCI devices not configured by the BIOS at system boot," and it may make a difference for devices present at boot. This change means that if BIOS enables SERR or PERR on a device, and it supplies _HPP or _HPX with the SERR or PERR bits *cleared*, we will now leave SERR or PERR reporting enabled on that device instead of disabling it as we previously did. See also 40abb96c51bb ("pciehp: Fix programming hotplug parameters"), where this code was first added. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Apply _HPP settings to PCIe devices as well as PCI and PCI-XBjorn Helgaas
The ACPI _HPP method was defined before PCIe existed, so its documentation only mentions PCI. The _HPX Type 0 setting record is essentially identical to _HPP, but the spec (ACPI rev 5.0, sec 6.2.8.1) says it should be applied to PCI, PCI-X, and PCIe devices, with settings being ignored if they are not applicable. Some platforms with both conventional PCI and PCIe devices provide only _HPP (not _HPX), so treat _HPP the same way as an _HPX Type 0 record and apply it to PCIe devices as well as PCI and PCI-X. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Remove unused pci_configure_slot()Bjorn Helgaas
All pci_configure_slot() uses have been removed, so remove the definition as well. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12ACPI / hotplug / PCI: Remove pci_configure_slot() usageBjorn Helgaas
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in acpiphp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: shpchp: Remove pci_configure_slot() usageBjorn Helgaas
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in shpchp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: pciehp: Remove pci_configure_slot() usageBjorn Helgaas
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in pciehp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Add pci_configure_device() during enumerationBjorn Helgaas
Some platforms can tell the OS how to configure PCI devices, e.g., how to set cache line size, error reporting enables, etc. ACPI defines _HPP and _HPX methods for this purpose. This configuration was previously done by some of the hotplug drivers using pci_configure_slot(). But not all hotplug drivers did this, and per the spec (ACPI rev 5.0, sec 6.2.7), we can also do it for "devices not configured by the BIOS at system boot." Move this configuration into the PCI core by adding pci_configure_device() and calling it from pci_device_add(), so we do this for all devices as we enumerate them. This is based on pci_configure_slot(), which is used by hotplug drivers. I omitted: - pcie_bus_configure_settings() because it configures MPS and MRRS, which requires global knowledge of the fabric and must be done later, and - configuration of subordinate devices; that will happen when we call pci_device_add() for those devices. Because pci_configure_slot() was only done by hotplug drivers, this initial version of pci_configure_device() only configures hot-added devices, ignoring anything added during boot. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Move pci_configure_slot() to drivers/pci/probe.cBjorn Helgaas
Move pci_configure_slot() and related functions from drivers/pci/hotplug/pcihp_slot to drivers/pci/probe.c. This is to prepare for doing device configuration during the normal enumeration process instead of just after hot-add. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-12PCI: Shuffle pci-acpi.c functions to group them logicallyBjorn Helgaas
Move code around to put all the ACPI power management stuff together and all the pieces related to ACPI methods (_CBA, _HPP, _HPX) together. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-12PCI: Whitespace cleanup in pci-acpi.cBjorn Helgaas
Whitespace fixes only; no functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-12PCI: Move pci_get_hp_params() to drivers/pci/pci-acpi.cBjorn Helgaas
Move pci_get_hp_params() and related functions from drivers/pci/hotplug/acpi_pcihp.c to drivers/pci/pci-acpi.c. Previously, pci_get_hp_params() was used only by hotplug drivers. But future changes will move this into the normal device enumeration process, so it will be used even when CONFIG_HOTPLUG_PCI is not set. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-12PCI: pciehp: Configure hot-added display devicesBjorn Helgaas
We configure cache line size and other settings of hot-added devices, e.g., based on ACPI _HPP or _HPX methods. Previously we skipped this for display devices, but ACPI rev 5.0, sec 6.2.7 and 6.2.8 have no requirement to skip them. Remove the check so we configure display devices the same way we configure other devices. See also ac81860ea073 ("PCI: hotplug: pciehp: Removed check for hotplug of display devices"). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Remove "no hotplug settings from platform" warningBjorn Helgaas
We print way too many messages like this: pci 0000:00:00.0: no hotplug settings from platform pci 0000:00:00.0: using default PCI settings This usually happens when the platform doesn't supply an ACPI _HPP method, but the method is optional, so there's no point in warning about it. Not only are the messages useless, but we call pci_configure_slot() far too many times, so they're repeated many times. I'll fix the overuse of pci_configure_slot() too, but that will wait until the next merge window. For now, just remove both log messages. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84391 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-10PCI: Add pci_ignore_hotplug() to ignore hotplug events for a deviceBjorn Helgaas
Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold), normally generates a hot-remove event that unbinds the driver. Some drivers expect to remain bound to a device even while they power it off and back on again. This can be dangerous, because if the device is removed or replaced while it is powered off, the driver doesn't know that anything changed. But some drivers accept that risk. Add pci_ignore_hotplug() for use by drivers that know their device cannot be removed. Using pci_ignore_hotplug() tells the PCI core that hot-plug events for the device should be ignored. The radeon and nouveau drivers use this to switch between a low-power, integrated GPU and a higher-power, higher-performance discrete GPU. They power off the unused GPU, but they want to remain bound to it. This is a reimplementation of f244d8b623da ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") but extends it to work with both acpiphp and pciehp. This fixes a problem where systems with dual GPUs using the radeon drivers become unusable, freezing every few seconds (see bugzillas below). The resume of the radeon device may also fail, e.g., This fixes problems on dual GPU systems where the radeon driver becomes unusable because of problems while suspending the device, as in bug 79701: [drm] radeon: finishing device. radeon 0000:01:00.0: Userspace still has active objects ! radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free ... WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]() trying to unbind memory from uninitialized GART ! or while resuming it, as in bug 77261: radeon 0000:01:00.0: ring 0 stalled for more than 10158msec radeon 0000:01:00.0: GPU lockup ... radeon 0000:01:00.0: GPU pci config reset pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1) radeon 0000:01:00.0: GPU reset succeeded, trying to resume *ERROR* radeon: dpm resume failed radeon 0000:01:00.0: Wait for MC idle timedout ! Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701 Reported-by: Shawn Starr <shawn.starr@rogers.com> Reported-by: Jose P. <lbdkmjdf@sharklasers.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Rajat Jain <rajatxjain@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> CC: stable@vger.kernel.org # v3.15+
2014-09-08PCI: Enable CRS Software Visibility for root port if it is supportedRajat Jain
Per PCIe r3.0, sec 2.3.2, an endpoint may respond to a Configuration Request with a Completion with Configuration Request Retry Status (CRS). This terminates the Configuration Request. When the CRS Software Visibility feature is disabled (as it is by default), a Root Complex must handle a CRS Completion by re-issuing the Configuration Request. This is invisible to software. From the CPU's point of view, an endpoint that always responds with CRS causes a hang because the Root Complex never supplies data to complete the CPU read. When CRS Software Visibility is enabled, a Root Complex that receives a CRS Completion for a read of the Vendor ID must return data of 0x0001. The Vendor ID of 0x0001 indicates to software that the endpoint is not ready. We now have more devices that require CRS Software Visibility. For example, a PLX 8713 NT bridge may respond with CRS until it has been configured via I2C, and the I2C configuration is completely independent of PCI enumeration. Enable CRS Software Visibility if it is supported. This allows a system with such a device to work (though the PCI core times out waiting for it to become ready, and we have to rescan the bus after it is ready). This essentially reverts ad7edfe04908 ("[PCI] Do not enable CRS Software Visibility by default"). The failures that led to ad7edfe04908 should be addressed by 89665a6a7140 ("PCI: Check only the Vendor ID to identify Configuration Request Retry"). [bhelgaas: changelog] Link: http://lkml.kernel.org/r/20071029061532.5d10dfc6@snowcone Link: http://lkml.kernel.org/r/alpine.LFD.0.9999.0712271023090.21557@woody.linux-foundation.org Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-08PCI: Check only the Vendor ID to identify Configuration Request RetryRajat Jain
Per PCIe r3.0, sec 2.3.2, if a Root Complex - has Configuration Request Retry Status Software Visibility enabled, - issues a Configuration Read of both bytes of the Vendor ID, and - receives a Completion with Configuration Request Retry Status (CRS), it must complete the request to the host by fabricating data of 0x0001 for the Vendor ID and 0xff for any additional bytes in the request. Linux issues a single config read for the four bytes containing the Vendor ID and the Device ID. Previously we checked all four bytes for 0xffff0001 to identify CRS. However, it is only the Vendor ID that really indicates CRS, because it's sufficient to read only those two bytes. Checking the Device ID verifies spec compliance but doesn't add any information. Some Root Complexes appear to indicate CRS by returning 0x0001 for the Vendor ID along with the actual the Device ID. Previously we interpreted that as a valid Vendor/Device ID pair, although 0x0001 is reserved and cannot be a valid Vendor ID. [bhelgaas: changelog] Link: http://lkml.kernel.org/r/4729FC36.3040000@gmail.com Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-08PCI: Assume all Mellanox devices have broken INTx maskingGavin Shan
The VFIO driver routes LSI interrupts by capturing, masking, and then delivering. When passing though Mellanox adapters from host to guest, interrupt storm are reported from host and guest. That's because the PCI command register INTx Disable bit doesn't work on Mellanox devices. # lspci | grep Mellanox 0001:05:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3] 0005:01:00.0 Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] (rev b0) Amir Vadai confirmed that all Mellanox devices have same problem. The patch marks broken INTx masking for all Mellanox adapters. Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-By: Amir Vadai <amirv@mellanox.com>
2014-09-05PCI: designware: Fold struct pcie_port_info into struct pcie_portPratyush Anand
The struct pcie_port_info doesn't contain any exclusive information compared to other elements of struct pcie_port. So, keeping a separate structure does not seem very logical. Therefore remove this struct and embed its elements directly into struct pcie_port. Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Mohit Kumar <mohit.kumar@st.com>
2014-09-05PCI: imx6: Delay enabling reference clock for SS until it stabilizesTim Harvey
According to the IMX6 reference manuals, REF_SSP_EN (Reference clock enable for SS function) must remain deasserted until the reference clock is running at the appropriate frequency. Delay enabling the reference clock for the SS function until it has stabilized. This prevents a high link failure rate (>5%) on certain IMX6 boards at various temperatures. [bhelgaas: reword changelog slightly] Tested-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Lucas Stach <l.stach@pengutronix.de>
2014-09-05Merge branches 'pci/misc', 'pci/pm', 'pci/host-designware', 'pci/host-imx6', ↵Bjorn Helgaas
'pci/host-keystone', 'pci/host-tegra' and 'pci/host-xilinx' into next * pci/misc: PCI/AER: Make <linux/aer.h> standalone includable PCI: Remove unnecessary variable in pci_add_dynid() * pci/pm: PCI/PM: Allow PCI devices to be put into D3cold during system suspend PCI/PM: Drop unused runtime PM support code for PCIe ports * pci/host-designware: PCI: designware: Check private_data validity in single place PCI: designware: Remove pci_assign_unassigned_resources() from dw_pcie_host_init() PCI: designware: Use pci_create_root_bus() instead of pci_scan_root_bus() PCI: designware: Parse bus-range property from devicetree PCI: designware: Add support for v3.65 hardware * pci/host-imx6: PCI: imx6: Probe in module_init(), not fs_initcall() PCI: designware: Remove pci_assign_unassigned_resources() from dw_pcie_host_init() PCI: designware: Use pci_create_root_bus() instead of pci_scan_root_bus() PCI: designware: Parse bus-range property from devicetree PCI: imx6: Put LTSSM in "Detect" state before disabling it MAINTAINERS: Add Lucas Stach as co-maintainer for i.MX6 PCI driver PCI: designware: Add support for v3.65 hardware * pci/host-keystone: PCI: keystone: Add TI Keystone PCIe driver PCI: designware: Add support for v3.65 hardware * pci/host-tegra: PCI: tegra: Implement a proper resource hierarchy PCI: tegra: Add missing cleanup in error path and tegra_msi_teardown_irq() resources: Add device-managed request/release_resource() * pci/host-xilinx: PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver Conflicts: drivers/pci/host/Kconfig drivers/pci/host/Makefile
2014-09-05PCI: designware: Check private_data validity in single placeLucas Stach
The driver had checks for this sprinkled all over. As we call sys_to_pcie() before every instance of this check, we can move the check to this single location to make things clear. Removing the statements after BUG[_ON]() is safe as the kernel is halted at this point anyway. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Mohit Kumar <mohit.kumar@st.com>
2014-09-05PCI: imx6: Probe in module_init(), not fs_initcall()Lucas Stach
This effectively reverts f216f57ffe6e ("PCI: imx6: Probe the PCIe in fs_initcall()") as the resource allocation issue that prevented the driver from working properly at module_initcall level is now fixed in pcie-designware.c. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Richard Zhu <r65037@freescale.com>
2014-09-05Merge branch 'pci/host-designware' into pci/host-imx6Bjorn Helgaas
* pci/host-designware: PCI: designware: Remove pci_assign_unassigned_resources() from dw_pcie_host_init() PCI: designware: Use pci_create_root_bus() instead of pci_scan_root_bus() PCI: designware: Parse bus-range property from devicetree PCI: designware: Add support for v3.65 hardware
2014-09-04PCI: designware: Remove pci_assign_unassigned_resources() from ↵Lucas Stach
dw_pcie_host_init() The pci_common_init_dev() call right before will already handle the device resource allocation, so this call was a no-op. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Mohit Kumar <mohit.kumar@st.com>
2014-09-04PCI: designware: Use pci_create_root_bus() instead of pci_scan_root_bus()Lucas Stach
Use pci_create_root_bus() similar to other PCI host controller drivers. The main problem with pci_scan_root_bus() is that it not only creates the root bus, but also activates all devices on the bus. This triggers PCI device driver probe routines, which fail because resources haven't been allocated. To work around this we made sure that the host controller driver is probed early and finishes resource allocation before any other device drivers are registered. Switching to pci_create_root_bus() allows us to get rid of this special handling. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Mohit Kumar <mohit.kumar@st.com>
2014-09-04PCI: designware: Parse bus-range property from devicetreeLucas Stach
This allows to explicitly specify the covered bus numbers in the devicetree, which will come in handy once we see a SoC with more than one PCIe host controller instance. Previously the driver relied on the behavior of pci_scan_root_bus() to fill in a range of 0x00-0xff if no valid range was found. We fall back to the same range if no valid DT entry was found to keep backwards compatibility, but now do it explicitly. [bhelgaas: use %pR in error message to avoid duplication] Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Mohit Kumar <mohit.kumar@st.com>
2014-09-04PCI: keystone: Add TI Keystone PCIe driverMurali Karicheri
The Keystone PCIe controller is based on v3.65 version of the Designware h/w. Main differences are: 1. No ATU support 2. Legacy and MSI IRQ functions are implemented in application register space 3. MSI interrupts are multiplexed over 8 IRQ lines to the Host side. All of the application register space handing code is organized into pci-keystone-dw.c and the functions are called from pci-keystone.c to implement PCI controller driver. Also add necessary DT documentation and update the MAINTAINERS file for the driver. [bhelgaas: spelling and whitespace fixes] Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> CC: Russell King <linux@arm.linux.org.uk> CC: Grant Likely <grant.likely@linaro.org> CC: Rob Herring <robh+dt@kernel.org> CC: Mohit Kumar <mohit.kumar@st.com> CC: Pratyush Anand <pratyush.anand@st.com> CC: Jingoo Han <jg1.han@samsung.com> CC: Richard Zhu <r65037@freescale.com> CC: Kishon Vijay Abraham I <kishon@ti.com> CC: Marek Vasut <marex@denx.de> CC: Arnd Bergmann <arnd@arndb.de> CC: Pawel Moll <pawel.moll@arm.com> CC: Mark Rutland <mark.rutland@arm.com> CC: Ian Campbell <ijc+devicetree@hellion.org.uk> CC: Kumar Gala <galak@codeaurora.org> CC: Randy Dunlap <rdunlap@infradead.org> CC: Grant Likely <grant.likely@linaro.org>
2014-09-04PCI: tegra: Implement a proper resource hierarchyThierry Reding
Currently the resource hierarchy generated from the PCIe host bridge is completely flat: $ cat /proc/iomem 00000000-00000fff : /pcie-controller@00003000/pci@1,0 00003000-000037ff : pads 00003800-000039ff : afi 10000000-1fffffff : cs 28000000-28003fff : r8169 28004000-28004fff : r8169 ... The host bridge driver doesn't request all the resources that are used. Windows allocated to each of the root ports aren't tracked, so there is no way for resources allocated to individual devices to be matched up with the correct parent resource by the PCI core. This patch addresses this in two steps. It first takes the union of all regions associated with the PCIe host bridge (control registers, root port registers, configuration space, I/O and prefetchable as well as non- prefetchable memory regions) and uses it as the new root of the resource hierarchy. Subsequently, regions are allocated from within this new root resource so that the resource tree looks much more like what's expected: # cat /proc/iomem 00000000-3fffffff : /pcie-controller@00003000 00000000-00000fff : /pcie-controller@00003000/pci@1,0 00003000-000037ff : pads 00003800-000039ff : afi 10000000-1fffffff : cs 20000000-27ffffff : non-prefetchable 28000000-3fffffff : prefetchable 28000000-280fffff : PCI Bus 0000:01 28000000-28003fff : 0000:01:00.0 28000000-28003fff : r8169 28004000-28004fff : 0000:01:00.0 28004000-28004fff : r8169 ... Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-04PCI: tegra: Add missing cleanup in error path and tegra_msi_teardown_irq()Jisheng Zhang
We should call tegra_msi_free() to free the MSI bit if irq_create_mapping() fails. And we need to dispose the IRQ mapping during IRQ teardown. [bhelgaas: made irqd_to_hwirq() change suggested by Thierry] Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com>
2014-09-04PCI: imx6: Put LTSSM in "Detect" state before disabling itLucas Stach
This fixes a boot hang observed when the bootloader already enabled the PCIe link for its own use. The fundamental problem is that Freescale forgot to wire up the core reset, so software doesn't have a sane way to get the core into a defined state. According to the DW PCIe core reference manual, configuration of the core may only happen when the LTSSM is disabled, so this is one of the first things we need to do. Apparently this isn't safe to do when the LTSSM is in any state other than "detect" as we observe an instant machine hang when trying to do so while the link is already up. As a workaround, force LTSSM into detect state right before hitting the disable switch. There is still a race window because the LTSSM may transition out of "detect" before we can disable it, but it's the best we can do for now. [bhelgaas: mention race window] Link: http://lkml.kernel.org/r/1406830565-23450-3-git-send-email-l.stach@pengutronix.de Reported-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Tim Harvey <tharvey@gateworks.com>
2014-09-04PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driverSrikanth Thokala
This is the driver for Xilinx AXI PCIe Host Bridge Soft IP. [bhelgaas: minor whitespace fixes] Signed-off-by: Srikanth Thokala <sthokal@xilinx.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2014-09-03PCI: Remove unnecessary variable in pci_add_dynid()Tobias Klauser
The variable "retval" in pci_add_dynid() is only used to store the return value of driver_attach() and is then directly returned. Remove the variable and directly pass on driver_attach()'s return value. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-03Merge tag 'pci-v3.17-fixes-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fix from Bjorn Helgaas: "This fixes an ARM allmodconfig build problem: Remove module option for ST Microelectronics SPEAr13xx" * tag 'pci-v3.17-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: spear: Remove module option
2014-09-02PCI: designware: Add support for v3.65 hardwareMurali Karicheri
The Keystone PCI controller is based on v3.65 DesignWare hardware. This version differs from newer versions of the hardware in functional areas discussed below that make it necessary to change dw_pcie_host_init() to support v3.65 based PCI controller. 1. No support for ATU port. Any ATU-specific resource handling code is to be bypassed for v3.65 h/w. 2. MSI controller uses application space to implement MSI and 32 MSI interrupts are multiplexed over 8 IRQs to the host. Hence the code to process MSI IRQ needs to be different. This patch allows platform driver to provide its own irq_domain_ops ptr to irq_domain_add_linear() through an API callback from the DesignWare core driver. 3. MSI interrupt generation requires EP to write to the RC's application register. So enhance the driver to allow setup of inbound access to MSI IRQ register as a post scan bus API callback. Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Mohit KUMAR <mohit.kumar@st.com> Acked-by: Jingoo Han <jg1.han@samsung.com> CC: Santosh Shilimkar <santosh.shilimkar@ti.com> CC: Russell King <linux@arm.linux.org.uk> CC: Grant Likely <grant.likely@linaro.org> CC: Rob Herring <robh+dt@kernel.org> CC: Jingoo Han <jg1.han@samsung.com> CC: Richard Zhu <r65037@freescale.com> CC: Kishon Vijay Abraham I <kishon@ti.com> CC: Marek Vasut <marex@denx.de> CC: Arnd Bergmann <arnd@arndb.de> CC: Pawel Moll <pawel.moll@arm.com> CC: Mark Rutland <mark.rutland@arm.com> CC: Ian Campbell <ijc+devicetree@hellion.org.uk> CC: Kumar Gala <galak@codeaurora.org> CC: Randy Dunlap <rdunlap@infradead.org> CC: Grant Likely <grant.likely@linaro.org>
2014-09-02PCI/PM: Allow PCI devices to be put into D3cold during system suspendRafael J. Wysocki
Commit 448bd857d48e ("PCI/PM: add PCIe runtime D3cold support") added a check to prevent PCI devices from being put into D3cold during system suspend without giving any particular reason. Also the check isn't really necessary, because acpi_pci_set_power_state() maps PCI_D3hot to ACPI_STATE_D3_COLD anyway. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>