From 8267b07526cabe2e2afc834a138ece8644af87ed Mon Sep 17 00:00:00 2001 From: Harunobu Kurokawa Date: Wed, 21 Dec 2016 03:37:06 +0900 Subject: PCI: rcar: Add compatible string for r8a7796 Add support for r8a7796. Signed-off-by: Harunobu Kurokawa Signed-off-by: Yoshihiro Kaneko Signed-off-by: Bjorn Helgaas Reviewed-by: Geert Uytterhoeven Acked-by: Simon Horman Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt index eee518db90b9..34712d6fd253 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt @@ -6,6 +6,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC; "renesas,pcie-r8a7791" for the R8A7791 SoC; "renesas,pcie-r8a7793" for the R8A7793 SoC; "renesas,pcie-r8a7795" for the R8A7795 SoC; + "renesas,pcie-r8a7796" for the R8A7796 SoC; "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device. "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device. -- cgit From afc9595ea4770f0157ae06fb3acedff703e169b6 Mon Sep 17 00:00:00 2001 From: Shawn Lin Date: Thu, 12 Jan 2017 09:53:17 +0800 Subject: PCI: rockchip: Disable RC's ASPM L0s based on DT "aspm-no-l0s" Rockchip's RC produces a 100MHz reference clock but there are two methods for the PHY to generate it: (1) Use the system PLL to generate a 100MHz clock. The PHY will relock it, filter signal noise, and output the reference clock. ASPM L0s works correctly, but circuit noise issues make it difficult to pass the TX compatibility test. (2) Share the SoC's 24MHZ crystal oscillator with the PHY and force the PHY's PLL to generate 100MHz internally. In this case, exit from ASPM L0s sometimes fails due to a design error in the RC receiver circuit. Even if we use extended-synch, the PHY sometimes fails to relock the bits from FTS, which will hang the system. We want the flexibility to use both clocking methods, so add a DT property, "aspm-no-l0s". If that's present, disable L0s to avoid the issues with case (2). [bhelgaas: changelog] Reported-by: Jeffy Chen Signed-off-by: Shawn Lin Signed-off-by: Bjorn Helgaas Reviewed-by: Brian Norris Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/rockchip-pcie.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt index 71aeda1ca055..1453a734c2f5 100644 --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt @@ -43,6 +43,8 @@ Required properties: - interrupt-map-mask and interrupt-map: standard PCI properties Optional Property: +- aspm-no-l0s: RC won't support ASPM L0s. This property is needed if + using 24MHz OSC for RC's PHY. - ep-gpios: contain the entry for pre-reset gpio - num-lanes: number of lanes to use - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe. -- cgit From 4fe0395550aeb6709ea5332f46de3644aef7d328 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 9 Jan 2017 21:37:40 +0100 Subject: PCI/MSI: Remove pci_enable_msi_{exact,range}() All multi-MSI allocations are now done through pci_irq_alloc_vectors(), so remove the old pci_enable_msi_range() and pci_enable_msi_exact() interfaces. Signed-off-by: Christoph Hellwig Signed-off-by: Bjorn Helgaas --- Documentation/PCI/MSI-HOWTO.txt | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index cd9c9f6a7cd9..1e37138027a3 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt @@ -162,8 +162,6 @@ The following old APIs to enable and disable MSI or MSI-X interrupts should not be used in new code: pci_enable_msi() /* deprecated */ - pci_enable_msi_range() /* deprecated */ - pci_enable_msi_exact() /* deprecated */ pci_disable_msi() /* deprecated */ pci_enable_msix_range() /* deprecated */ pci_enable_msix_exact() /* deprecated */ @@ -268,5 +266,5 @@ or disabled (0). If 0 is found in any of the msi_bus files belonging to bridges between the PCI root and the device, MSIs are disabled. It is also worth checking the device driver to see whether it supports MSIs. -For example, it may contain calls to pci_enable_msi_range() or -pci_enable_msix_range(). +For example, it may contain calls to pci_irq_alloc_vectors() with the +PCI_IRQ_MSI or PCI_IRQ_MSIX flags. -- cgit From a2ec1996098c7da0593a0981190316025301eab1 Mon Sep 17 00:00:00 2001 From: Dongdong Liu Date: Mon, 6 Feb 2017 14:25:04 +0800 Subject: PCI: hisi: Add DT almost-ECAM support for Hip06/Hip07 host controllers The PCIe controller in HiSilicon Hip06/Hip07 SoCs is not completely ECAM-compliant. It is non-ECAM only for the RC bus config space; for any other bus underneath the root bus it does support ECAM access. Add DT support for the almost-ECAM Hip06/Hip07 controllers. [bhelgaas: drop dev->of_node test, driver name "hisi-pcie-almost-ecam"] Signed-off-by: Dongdong Liu Signed-off-by: Bjorn Helgaas Reviewed-by: Gabriele Paoloni Reviewed-by: Zhou Wang --- .../devicetree/bindings/pci/hisilicon-pcie.txt | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt index 59c2f47aa303..b7fa3b97986d 100644 --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt @@ -42,3 +42,40 @@ Hip05 Example (note that Hip06 is the same except compatible): 0x0 0 0 4 &mbigen_pcie 4 13>; status = "ok"; }; + +HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description. +The properties and their meanings are identical to those described in +host-generic-pci.txt except as listed below. + +Properties of the host controller node that differ from +host-generic-pci.txt: + +- compatible : Must be "hisilicon,pcie-almost-ecam" + +- reg : Two entries: First the ECAM configuration space for any + other bus underneath the root bus. Second, the base + and size of the HiSilicon host bridge registers include + the RC's own config space. + +Example: + pcie0: pcie@a0090000 { + compatible = "hisilicon,pcie-almost-ecam"; + reg = <0 0xb0000000 0 0x2000000>, /* ECAM configuration space */ + <0 0xa0090000 0 0x10000>; /* host bridge registers */ + bus-range = <0 31>; + msi-map = <0x0000 &its_dsa 0x0000 0x2000>; + msi-map-mask = <0xffff>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + dma-coherent; + ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000 + 0x01000000 0 0 0 0xb7ff0000 0 0x10000>; + #interrupt-cells = <1>; + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4 + 0x0 0 0 2 &mbigen_pcie0 650 4 + 0x0 0 0 3 &mbigen_pcie0 650 4 + 0x0 0 0 4 &mbigen_pcie0 650 4>; + status = "ok"; + }; -- cgit From 8ed81ec82a8c57c3a6ad69b4c4d3e4801163c256 Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Thu, 2 Feb 2017 18:15:31 +0100 Subject: PCI: mvebu: Change delay after reset to the PCIe spec mandated 100ms The current default of 20ms cause some devices, which are slow to initialize, to not show up during the bus scanning. Change this to the PCIe spec mandated 100ms and document this in the DT binding. From PCIe base spec rev 3.0, chapter "6.6.1. Conventional Reset": To allow components to perform internal initialization, system software must wait a specified minimum period following the end of a Conventional Reset of one or more devices before it is permitted to issue Configuration Requests to those devices. With a Downstream Port that does not support Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms before sending a Configuration Request to the device immediately below that Port. Signed-off-by: Lucas Stach Signed-off-by: Bjorn Helgaas Acked-by: Jason Cooper --- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt index 08c716b2c6b6..2de6f65ecfb1 100644 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -78,7 +78,8 @@ and the following optional properties: multiple lanes. If this property is not found, we assume that the value is 0. - reset-gpios: optional gpio to PERST# -- reset-delay-us: delay in us to wait after reset de-assertion +- reset-delay-us: delay in us to wait after reset de-assertion, if not + specified will default to 100ms, as required by the PCIe specification. Example: -- cgit From 2fd260f03b6a365bad48522f3948463928f91c2c Mon Sep 17 00:00:00 2001 From: "Michael S. Tsirkin" Date: Tue, 24 Jan 2017 19:35:56 +0200 Subject: PCI/AER: Remove unused .link_reset() callback No hardware seems to actually call .link_reset(), and no driver implements it as more than a nop stub. Drop mentions of the callback from everywhere. It's dropped from the documentation as well, but the doc really needs to be updated to reflect reality better (e.g., on PCIe, slot reset is the link reset). This will be done in a later patch. Signed-off-by: Michael S. Tsirkin Signed-off-by: Bjorn Helgaas --- Documentation/PCI/pci-error-recovery.txt | 24 +++--------------------- 1 file changed, 3 insertions(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/PCI/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt index ac26869c7db4..da3b2176d5da 100644 --- a/Documentation/PCI/pci-error-recovery.txt +++ b/Documentation/PCI/pci-error-recovery.txt @@ -78,7 +78,6 @@ struct pci_error_handlers { int (*error_detected)(struct pci_dev *dev, enum pci_channel_state); int (*mmio_enabled)(struct pci_dev *dev); - int (*link_reset)(struct pci_dev *dev); int (*slot_reset)(struct pci_dev *dev); void (*resume)(struct pci_dev *dev); }; @@ -104,8 +103,7 @@ if it implements any, it must implement error_detected(). If a callback is not implemented, the corresponding feature is considered unsupported. For example, if mmio_enabled() and resume() aren't there, then it is assumed that the driver is not doing any direct recovery and requires -a slot reset. If link_reset() is not implemented, the card is assumed to -not care about link resets. Typically a driver will want to know about +a slot reset. Typically a driver will want to know about a slot_reset(). The actual steps taken by a platform to recover from a PCI error @@ -232,25 +230,9 @@ proceeds to STEP 4 (Slot Reset) STEP 3: Link Reset ------------------ -The platform resets the link, and then calls the link_reset() callback -on all affected device drivers. This is a PCI-Express specific state +The platform resets the link. This is a PCI-Express specific step and is done whenever a non-fatal error has been detected that can be -"solved" by resetting the link. This call informs the driver of the -reset and the driver should check to see if the device appears to be -in working condition. - -The driver is not supposed to restart normal driver I/O operations -at this point. It should limit itself to "probing" the device to -check its recoverability status. If all is right, then the platform -will call resume() once all drivers have ack'd link_reset(). - - Result codes: - (identical to STEP 3 (MMIO Enabled) - -The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5 -(Resume Operations). - ->>> The current powerpc implementation does not implement this callback. +"solved" by resetting the link. STEP 4: Slot Reset ------------------ -- cgit From c3cf2c61ddc1410424da0ea87717edf16fc296c5 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 15 Feb 2017 08:58:22 +0100 Subject: PCI/MSI: Document pci_alloc_irq_vectors(), deprecate pci_enable_msi() Document pci_alloc_irq_vectors() instead of the deprecated pci_enable_msi() and pci_enable_msix() APIs. Signed-off-by: Christoph Hellwig Signed-off-by: Bjorn Helgaas --- Documentation/PCI/pci.txt | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index 77f49dc5be23..611a75e4366e 100644 --- a/Documentation/PCI/pci.txt +++ b/Documentation/PCI/pci.txt @@ -382,18 +382,18 @@ The fundamental difference between MSI and MSI-X is how multiple "vectors" get allocated. MSI requires contiguous blocks of vectors while MSI-X can allocate several individual ones. -MSI capability can be enabled by calling pci_enable_msi() or -pci_enable_msix() before calling request_irq(). This causes -the PCI support to program CPU vector data into the PCI device -capability registers. - -If your PCI device supports both, try to enable MSI-X first. -Only one can be enabled at a time. Many architectures, chip-sets, -or BIOSes do NOT support MSI or MSI-X and the call to pci_enable_msi/msix -will fail. This is important to note since many drivers have -two (or more) interrupt handlers: one for MSI/MSI-X and another for IRQs. -They choose which handler to register with request_irq() based on the -return value from pci_enable_msi/msix(). +MSI capability can be enabled by calling pci_alloc_irq_vectors() with the +PCI_IRQ_MSI and/or PCI_IRQ_MSIX flags before calling request_irq(). This +causes the PCI support to program CPU vector data into the PCI device +capability registers. Many architectures, chip-sets, or BIOSes do NOT +support MSI or MSI-X and a call to pci_alloc_irq_vectors with just +the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always +specify PCI_IRQ_LEGACY as well. + +Drivers that have different interrupt handlers for MSI/MSI-X and +legacy INTx should chose the right one based on the msi_enabled +and msix_enabled flags in the pci_dev structure after calling +pci_alloc_irq_vectors. There are (at least) two really good reasons for using MSI: 1) MSI is an exclusive interrupt vector by definition. -- cgit From e4e7d59704d485f272061cea9057798dda3cfd99 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 15 Feb 2017 08:58:23 +0100 Subject: PCI/MSI: Update MSI/MSI-X bits in PCIEBUS-HOWTO Update the MSI/MSI-X bits in PCIEBUS-HOWTO. Stop talking about low-level details that mention deprecated APIs and concentrate on what service drivers should do and why. Signed-off-by: Christoph Hellwig Signed-off-by: Bjorn Helgaas --- Documentation/PCI/PCIEBUS-HOWTO.txt | 33 +++++++-------------------------- 1 file changed, 7 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/PCI/PCIEBUS-HOWTO.txt b/Documentation/PCI/PCIEBUS-HOWTO.txt index 6bd5f372adec..15f0bb3b5045 100644 --- a/Documentation/PCI/PCIEBUS-HOWTO.txt +++ b/Documentation/PCI/PCIEBUS-HOWTO.txt @@ -161,21 +161,13 @@ Since all service drivers of a PCI-PCI Bridge Port device are allowed to run simultaneously, below lists a few of possible resource conflicts with proposed solutions. -6.1 MSI Vector Resource - -The MSI capability structure enables a device software driver to call -pci_enable_msi to request MSI based interrupts. Once MSI interrupts -are enabled on a device, it stays in this mode until a device driver -calls pci_disable_msi to disable MSI interrupts and revert back to -INTx emulation mode. Since service drivers of the same PCI-PCI Bridge -port share the same physical device, if an individual service driver -calls pci_enable_msi/pci_disable_msi it may result unpredictable -behavior. For example, two service drivers run simultaneously on the -same physical Root Port. Both service drivers call pci_enable_msi to -request MSI based interrupts. A service driver may not know whether -any other service drivers have run on this Root Port. If either one -of them calls pci_disable_msi, it puts the other service driver -in a wrong interrupt mode. +6.1 MSI and MSI-X Vector Resource + +Once MSI or MSI-X interrupts are enabled on a device, it stays in this +mode until they are disabled again. Since service drivers of the same +PCI-PCI Bridge port share the same physical device, if an individual +service driver enables or disables MSI/MSI-X mode it may result +unpredictable behavior. To avoid this situation all service drivers are not permitted to switch interrupt mode on its device. The PCI Express Port Bus driver @@ -187,17 +179,6 @@ driver. Service drivers should use (struct pcie_device*)dev->irq to call request_irq/free_irq. In addition, the interrupt mode is stored in the field interrupt_mode of struct pcie_device. -6.2 MSI-X Vector Resources - -Similar to the MSI a device driver for an MSI-X capable device can -call pci_enable_msix to request MSI-X interrupts. All service drivers -are not permitted to switch interrupt mode on its device. The PCI -Express Port Bus driver is responsible for determining the interrupt -mode and this should be transparent to service drivers. Any attempt -by service driver to call pci_enable_msix/pci_disable_msix may -result unpredictable behavior. Service drivers should use -(struct pcie_device*)dev->irq and call request_irq/free_irq. - 6.3 PCI Memory/IO Mapped Regions Service drivers for PCI Express Power Management (PME), Advanced -- cgit From ad8ec41afa98615a4154eee0121bcf8276695327 Mon Sep 17 00:00:00 2001 From: Jaehoon Chung Date: Mon, 13 Feb 2017 17:26:10 +0900 Subject: Documentation: samsung-phy: Add exynos-pcie-phy binding Add the exynos-pcie-phy binding for Exynos PCIe PHY. This is for using generic PHY framework. Signed-off-by: Jaehoon Chung Signed-off-by: Bjorn Helgaas Acked-by: Rob Herring --- Documentation/devicetree/bindings/phy/samsung-phy.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 9872ba8546bd..ab80bfe31cb3 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -191,3 +191,20 @@ Example: usbdrdphy0 = &usb3_phy0; usbdrdphy1 = &usb3_phy1; }; + +Samsung Exynos SoC series PCIe PHY controller +-------------------------------------------------- +Required properties: +- compatible : Should be set to "samsung,exynos5440-pcie-phy" +- #phy-cells : Must be zero +- reg : a register used by phy driver. + - First is for phy register, second is for block register. +- reg-names : Must be set to "phy" and "block". + +Example: + pcie_phy0: pcie-phy@270000 { + #phy-cells = <0>; + compatible = "samsung,exynos5440-pcie-phy"; + reg = <0x270000 0x1000>, <0x271000 0x40>; + reg-names = "phy", "block"; + }; -- cgit From 34f80c7ddfffe262bf04fb03e198e64de4cec7fc Mon Sep 17 00:00:00 2001 From: Jaehoon Chung Date: Mon, 13 Feb 2017 17:26:12 +0900 Subject: Documentation: binding: Modify the exynos5440 PCIe binding According to using PHY framework, updates the exynos5440-pcie binding. For maintaining backward compatibility, leaves the current dt-binding. (It should be deprecated.) Recommends to use the PHY Framework and "config" property to follow the designware-pcie binding. If you use the old way, can see "missing *config* reg space" message. Because the getting configuration space address from range is old way. NOTE: When use the "config" property, first name of 'reg-names' must be set to "elbi". Otherwise driver can't maintain the backward capability. Signed-off-by: Jaehoon Chung Signed-off-by: Bjorn Helgaas Reviewed-by: Pankaj Dubey Reviewed-by: Alim Akhtar Acked-by: Rob Herring --- .../bindings/pci/samsung,exynos5440-pcie.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt index 4f9d23d2ed67..7d3b09474657 100644 --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt @@ -7,8 +7,19 @@ Required properties: - compatible: "samsung,exynos5440-pcie" - reg: base addresses and lengths of the pcie controller, the phy controller, additional register for the phy controller. + (Registers for the phy controller are DEPRECATED. + Use the PHY framework.) +- reg-names : First name should be set to "elbi". + And use the "config" instead of getting the confgiruation address space + from "ranges". + NOTE: When use the "config" property, reg-names must be set. - interrupts: A list of interrupt outputs for level interrupt, pulse interrupt, special interrupt. +- phys: From PHY binding. Phandle for the Generic PHY. + Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt + +Other common properties refer to + Documentation/devicetree/binding/pci/designware-pcie.txt Example: @@ -54,6 +65,24 @@ SoC specific DT Entry: num-lanes = <4>; }; +With using PHY framework: + pcie_phy0: pcie-phy@270000 { + ... + reg = <0x270000 0x1000>, <0x271000 0x40>; + reg-names = "phy", "block"; + ... + }; + + pcie@290000 { + ... + reg = <0x290000 0x1000>, <0x40000000 0x1000>; + reg-names = "elbi", "config"; + phys = <&pcie_phy0>; + ranges = <0x81000000 0 0 0x60001000 0 0x00010000 + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; + ... + }; + Board specific DT Entry: pcie@290000 { -- cgit