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/devicetree/bindings/pci') 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 v1.2.1 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/devicetree/bindings/pci') 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 v1.2.1 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/devicetree/bindings/pci') 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 v1.2.1 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/devicetree/bindings/pci') 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 v1.2.1 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/devicetree/bindings/pci') 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 v1.2.1