[RFC/RFT 0/6] RK3568 PCIe V3 support

[RFC/RFT 0/6] RK3568 PCIe V3 support

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

This series adds Rockchip PCIe V3 support found on rk3568 SOC.

It is based on "Enable rk356x PCIe controller" series of Peter Geis
v7: https://patchwork.kernel.org/project/linux-rockchip/cover/20220416110507.642398-1-pgwipeout@gmail.com/

Compared to PCIeV2 which uses the Naneng combphy, pciev3
uses a dedicated pci-phy.

Frank Wunderlich (6):
  dt-bindings: phy: rockchip: add pcie3 phy
  dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
  phy: rockchip: Support pcie v3
  PCI: rockchip-dwc: add pcie bifurcation
  arm64: dts: rockchip: rk3568: Add PCIe v3 nodes
  arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

 .../bindings/phy/rockchip-pcie3-phy.yaml      |  77 +++++
 .../devicetree/bindings/soc/rockchip/grf.yaml |   2 +
 .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts   |  79 +++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      | 122 ++++++++
 drivers/pci/controller/dwc/pcie-dw-rockchip.c |  11 +
 drivers/phy/rockchip/Kconfig                  |   9 +
 drivers/phy/rockchip/Makefile                 |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
 include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
 include/linux/phy/pcie.h                      |  12 +
 10 files changed, 612 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
 create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
 create mode 100644 include/linux/phy/pcie.h

-- 
2.25.1

[RFC/RFT 0/6] RK3568 PCIe V3 support

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

This series adds Rockchip PCIe V3 support found on rk3568 SOC.

It is based on "Enable rk356x PCIe controller" series of Peter Geis
v7: https://patchwork.kernel.org/project/linux-rockchip/cover/20220416110507.642398-1-pgwipeout@gmail.com/

Compared to PCIeV2 which uses the Naneng combphy, pciev3
uses a dedicated pci-phy.

Frank Wunderlich (6):
  dt-bindings: phy: rockchip: add pcie3 phy
  dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
  phy: rockchip: Support pcie v3
  PCI: rockchip-dwc: add pcie bifurcation
  arm64: dts: rockchip: rk3568: Add PCIe v3 nodes
  arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

 .../bindings/phy/rockchip-pcie3-phy.yaml      |  77 +++++
 .../devicetree/bindings/soc/rockchip/grf.yaml |   2 +
 .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts   |  79 +++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      | 122 ++++++++
 drivers/pci/controller/dwc/pcie-dw-rockchip.c |  11 +
 drivers/phy/rockchip/Kconfig                  |   9 +
 drivers/phy/rockchip/Makefile                 |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
 include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
 include/linux/phy/pcie.h                      |  12 +
 10 files changed, 612 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
 create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
 create mode 100644 include/linux/phy/pcie.h

-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[RFC/RFT 0/6] RK3568 PCIe V3 support

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

This series adds Rockchip PCIe V3 support found on rk3568 SOC.

It is based on "Enable rk356x PCIe controller" series of Peter Geis
v7: https://patchwork.kernel.org/project/linux-rockchip/cover/20220416110507.642398-1-pgwipeout@gmail.com/

Compared to PCIeV2 which uses the Naneng combphy, pciev3
uses a dedicated pci-phy.

Frank Wunderlich (6):
  dt-bindings: phy: rockchip: add pcie3 phy
  dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
  phy: rockchip: Support pcie v3
  PCI: rockchip-dwc: add pcie bifurcation
  arm64: dts: rockchip: rk3568: Add PCIe v3 nodes
  arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

 .../bindings/phy/rockchip-pcie3-phy.yaml      |  77 +++++
 .../devicetree/bindings/soc/rockchip/grf.yaml |   2 +
 .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts   |  79 +++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      | 122 ++++++++
 drivers/pci/controller/dwc/pcie-dw-rockchip.c |  11 +
 drivers/phy/rockchip/Kconfig                  |   9 +
 drivers/phy/rockchip/Makefile                 |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
 include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
 include/linux/phy/pcie.h                      |  12 +
 10 files changed, 612 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
 create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
 create mode 100644 include/linux/phy/pcie.h

-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC/RFT 0/6] RK3568 PCIe V3 support

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

This series adds Rockchip PCIe V3 support found on rk3568 SOC.

It is based on "Enable rk356x PCIe controller" series of Peter Geis
v7: https://patchwork.kernel.org/project/linux-rockchip/cover/20220416110507.642398-1-pgwipeout@gmail.com/

Compared to PCIeV2 which uses the Naneng combphy, pciev3
uses a dedicated pci-phy.

Frank Wunderlich (6):
  dt-bindings: phy: rockchip: add pcie3 phy
  dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
  phy: rockchip: Support pcie v3
  PCI: rockchip-dwc: add pcie bifurcation
  arm64: dts: rockchip: rk3568: Add PCIe v3 nodes
  arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

 .../bindings/phy/rockchip-pcie3-phy.yaml      |  77 +++++
 .../devicetree/bindings/soc/rockchip/grf.yaml |   2 +
 .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts   |  79 +++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      | 122 ++++++++
 drivers/pci/controller/dwc/pcie-dw-rockchip.c |  11 +
 drivers/phy/rockchip/Kconfig                  |   9 +
 drivers/phy/rockchip/Makefile                 |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
 include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
 include/linux/phy/pcie.h                      |  12 +
 10 files changed, 612 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
 create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
 create mode 100644 include/linux/phy/pcie.h

-- 
2.25.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add a new binding file for Rockchip PCIe V3 phy driver.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../bindings/phy/rockchip-pcie3-phy.yaml      | 77 +++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
new file mode 100644
index 000000000000..58a8ce175f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PCIe v3 phy
+
+maintainers:
+  - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,rk3568-pcie3-phy
+      - rockchip,rk3588-pcie3-phy
+
+  reg:
+    maxItems: 2
+
+  clocks:
+    minItems: 1
+    maxItems: 3
+
+  clock-names:
+    contains:
+      anyOf:
+        - enum: [ refclk_m, refclk_n, pclk ]
+
+  "#phy-cells":
+    const: 0
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    const: phy
+
+  rockchip,phy-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the syscon managing the phy "general register files"
+
+  rockchip,pipe-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the syscon managing the pipe "general register files"
+
+  rockchip,pcie30-phymode:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description: |
+      use PHY_MODE_PCIE_AGGREGATION if not defined
+    minimum: 0x0
+    maximum: 0x4
+
+
+required:
+  - compatible
+  - reg
+  - rockchip,phy-grf
+
+additionalProperties: false
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3568-cru.h>
+    pcie30phy: phy@fe8c0000 {
+      compatible = "rockchip,rk3568-pcie3-phy";
+      reg = <0x0 0xfe8c0000 0x0 0x20000>;
+      #phy-cells = <0>;
+      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
+       <&cru PCLK_PCIE30PHY>;
+      clock-names = "refclk_m", "refclk_n", "pclk";
+      resets = <&cru SRST_PCIE30PHY>;
+      reset-names = "phy";
+      rockchip,phy-grf = <&pcie30_phy_grf>;
+    };
-- 
2.25.1

[RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add a new binding file for Rockchip PCIe V3 phy driver.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../bindings/phy/rockchip-pcie3-phy.yaml      | 77 +++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
new file mode 100644
index 000000000000..58a8ce175f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PCIe v3 phy
+
+maintainers:
+  - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,rk3568-pcie3-phy
+      - rockchip,rk3588-pcie3-phy
+
+  reg:
+    maxItems: 2
+
+  clocks:
+    minItems: 1
+    maxItems: 3
+
+  clock-names:
+    contains:
+      anyOf:
+        - enum: [ refclk_m, refclk_n, pclk ]
+
+  "#phy-cells":
+    const: 0
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    const: phy
+
+  rockchip,phy-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the syscon managing the phy "general register files"
+
+  rockchip,pipe-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the syscon managing the pipe "general register files"
+
+  rockchip,pcie30-phymode:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description: |
+      use PHY_MODE_PCIE_AGGREGATION if not defined
+    minimum: 0x0
+    maximum: 0x4
+
+
+required:
+  - compatible
+  - reg
+  - rockchip,phy-grf
+
+additionalProperties: false
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3568-cru.h>
+    pcie30phy: phy@fe8c0000 {
+      compatible = "rockchip,rk3568-pcie3-phy";
+      reg = <0x0 0xfe8c0000 0x0 0x20000>;
+      #phy-cells = <0>;
+      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
+       <&cru PCLK_PCIE30PHY>;
+      clock-names = "refclk_m", "refclk_n", "pclk";
+      resets = <&cru SRST_PCIE30PHY>;
+      reset-names = "phy";
+      rockchip,phy-grf = <&pcie30_phy_grf>;
+    };
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add a new binding file for Rockchip PCIe V3 phy driver.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../bindings/phy/rockchip-pcie3-phy.yaml      | 77 +++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
new file mode 100644
index 000000000000..58a8ce175f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PCIe v3 phy
+
+maintainers:
+  - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,rk3568-pcie3-phy
+      - rockchip,rk3588-pcie3-phy
+
+  reg:
+    maxItems: 2
+
+  clocks:
+    minItems: 1
+    maxItems: 3
+
+  clock-names:
+    contains:
+      anyOf:
+        - enum: [ refclk_m, refclk_n, pclk ]
+
+  "#phy-cells":
+    const: 0
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    const: phy
+
+  rockchip,phy-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the syscon managing the phy "general register files"
+
+  rockchip,pipe-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the syscon managing the pipe "general register files"
+
+  rockchip,pcie30-phymode:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description: |
+      use PHY_MODE_PCIE_AGGREGATION if not defined
+    minimum: 0x0
+    maximum: 0x4
+
+
+required:
+  - compatible
+  - reg
+  - rockchip,phy-grf
+
+additionalProperties: false
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3568-cru.h>
+    pcie30phy: phy@fe8c0000 {
+      compatible = "rockchip,rk3568-pcie3-phy";
+      reg = <0x0 0xfe8c0000 0x0 0x20000>;
+      #phy-cells = <0>;
+      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
+       <&cru PCLK_PCIE30PHY>;
+      clock-names = "refclk_m", "refclk_n", "pclk";
+      resets = <&cru SRST_PCIE30PHY>;
+      reset-names = "phy";
+      rockchip,phy-grf = <&pcie30_phy_grf>;
+    };
-- 
2.25.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add a new binding file for Rockchip PCIe V3 phy driver.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../bindings/phy/rockchip-pcie3-phy.yaml      | 77 +++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
new file mode 100644
index 000000000000..58a8ce175f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PCIe v3 phy
+
+maintainers:
+  - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,rk3568-pcie3-phy
+      - rockchip,rk3588-pcie3-phy
+
+  reg:
+    maxItems: 2
+
+  clocks:
+    minItems: 1
+    maxItems: 3
+
+  clock-names:
+    contains:
+      anyOf:
+        - enum: [ refclk_m, refclk_n, pclk ]
+
+  "#phy-cells":
+    const: 0
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    const: phy
+
+  rockchip,phy-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the syscon managing the phy "general register files"
+
+  rockchip,pipe-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the syscon managing the pipe "general register files"
+
+  rockchip,pcie30-phymode:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description: |
+      use PHY_MODE_PCIE_AGGREGATION if not defined
+    minimum: 0x0
+    maximum: 0x4
+
+
+required:
+  - compatible
+  - reg
+  - rockchip,phy-grf
+
+additionalProperties: false
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3568-cru.h>
+    pcie30phy: phy@fe8c0000 {
+      compatible = "rockchip,rk3568-pcie3-phy";
+      reg = <0x0 0xfe8c0000 0x0 0x20000>;
+      #phy-cells = <0>;
+      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
+       <&cru PCLK_PCIE30PHY>;
+      clock-names = "refclk_m", "refclk_n", "pclk";
+      resets = <&cru SRST_PCIE30PHY>;
+      reset-names = "phy";
+      rockchip,phy-grf = <&pcie30_phy_grf>;
+    };
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> Add a new binding file for Rockchip PCIe V3 phy driver.

Thank you for your patch. There is something to discuss/improve.

> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  .../bindings/phy/rockchip-pcie3-phy.yaml      | 77 +++++++++++++++++++
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> new file mode 100644
> index 000000000000..58a8ce175f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml

Filename: vendor,hardware
so for example "rockchip,pcie3-phy" although Rob proposed recently for
other bindings using compatible as a base:
https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/


> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip PCIe v3 phy
> +
> +maintainers:
> +  - Heiko Stuebner <heiko@sntech.de>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - rockchip,rk3568-pcie3-phy
> +      - rockchip,rk3588-pcie3-phy
> +
> +  reg:
> +    maxItems: 2
> +
> +  clocks:
> +    minItems: 1
> +    maxItems: 3
> +
> +  clock-names:
> +    contains:
> +      anyOf:
> +        - enum: [ refclk_m, refclk_n, pclk ]

The list should be strictly ordered (defined), so:
  items:
    - const: ...
    - const: ...
    - const: ...
  minItems: 1

However the question is - why the clocks have different amount? Is it
per different SoC implementation?

> +
> +  "#phy-cells":
> +    const: 0
> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    const: phy
> +
> +  rockchip,phy-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the syscon managing the phy "general register files"
> +
> +  rockchip,pipe-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the syscon managing the pipe "general register files"
> +
> +  rockchip,pcie30-phymode:
> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> +    description: |
> +      use PHY_MODE_PCIE_AGGREGATION if not defined

I don't understand the description. Do you mean here a case when the
variable is missing?

> +    minimum: 0x0
> +    maximum: 0x4

Please explain these values. Register values should not be part of
bindings, but instead some logical behavior of hardware or its logic.

> +
> +

Just one blank line.

> +required:
> +  - compatible
> +  - reg
> +  - rockchip,phy-grf

phy-cells as well

> +
> +additionalProperties: false
> +
> +unevaluatedProperties: false

Just one please, additionalProperties.

> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3568-cru.h>
> +    pcie30phy: phy@fe8c0000 {
> +      compatible = "rockchip,rk3568-pcie3-phy";
> +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> +      #phy-cells = <0>;
> +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> +       <&cru PCLK_PCIE30PHY>;

Align the entry with opening '<'. Usually the most readable is one clock
per line.

> +      clock-names = "refclk_m", "refclk_n", "pclk";
> +      resets = <&cru SRST_PCIE30PHY>;
> +      reset-names = "phy";
> +      rockchip,phy-grf = <&pcie30_phy_grf>;
> +    };


Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> Add a new binding file for Rockchip PCIe V3 phy driver.

Thank you for your patch. There is something to discuss/improve.

> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  .../bindings/phy/rockchip-pcie3-phy.yaml      | 77 +++++++++++++++++++
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> new file mode 100644
> index 000000000000..58a8ce175f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml

Filename: vendor,hardware
so for example "rockchip,pcie3-phy" although Rob proposed recently for
other bindings using compatible as a base:
https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/


> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip PCIe v3 phy
> +
> +maintainers:
> +  - Heiko Stuebner <heiko@sntech.de>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - rockchip,rk3568-pcie3-phy
> +      - rockchip,rk3588-pcie3-phy
> +
> +  reg:
> +    maxItems: 2
> +
> +  clocks:
> +    minItems: 1
> +    maxItems: 3
> +
> +  clock-names:
> +    contains:
> +      anyOf:
> +        - enum: [ refclk_m, refclk_n, pclk ]

The list should be strictly ordered (defined), so:
  items:
    - const: ...
    - const: ...
    - const: ...
  minItems: 1

However the question is - why the clocks have different amount? Is it
per different SoC implementation?

> +
> +  "#phy-cells":
> +    const: 0
> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    const: phy
> +
> +  rockchip,phy-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the syscon managing the phy "general register files"
> +
> +  rockchip,pipe-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the syscon managing the pipe "general register files"
> +
> +  rockchip,pcie30-phymode:
> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> +    description: |
> +      use PHY_MODE_PCIE_AGGREGATION if not defined

I don't understand the description. Do you mean here a case when the
variable is missing?

> +    minimum: 0x0
> +    maximum: 0x4

Please explain these values. Register values should not be part of
bindings, but instead some logical behavior of hardware or its logic.

> +
> +

Just one blank line.

> +required:
> +  - compatible
> +  - reg
> +  - rockchip,phy-grf

phy-cells as well

> +
> +additionalProperties: false
> +
> +unevaluatedProperties: false

Just one please, additionalProperties.

> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3568-cru.h>
> +    pcie30phy: phy@fe8c0000 {
> +      compatible = "rockchip,rk3568-pcie3-phy";
> +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> +      #phy-cells = <0>;
> +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> +       <&cru PCLK_PCIE30PHY>;

Align the entry with opening '<'. Usually the most readable is one clock
per line.

> +      clock-names = "refclk_m", "refclk_n", "pclk";
> +      resets = <&cru SRST_PCIE30PHY>;
> +      reset-names = "phy";
> +      rockchip,phy-grf = <&pcie30_phy_grf>;
> +    };


Best regards,
Krzysztof

Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> Add a new binding file for Rockchip PCIe V3 phy driver.

Thank you for your patch. There is something to discuss/improve.

> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  .../bindings/phy/rockchip-pcie3-phy.yaml      | 77 +++++++++++++++++++
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> new file mode 100644
> index 000000000000..58a8ce175f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml

Filename: vendor,hardware
so for example "rockchip,pcie3-phy" although Rob proposed recently for
other bindings using compatible as a base:
https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/


> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip PCIe v3 phy
> +
> +maintainers:
> +  - Heiko Stuebner <heiko@sntech.de>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - rockchip,rk3568-pcie3-phy
> +      - rockchip,rk3588-pcie3-phy
> +
> +  reg:
> +    maxItems: 2
> +
> +  clocks:
> +    minItems: 1
> +    maxItems: 3
> +
> +  clock-names:
> +    contains:
> +      anyOf:
> +        - enum: [ refclk_m, refclk_n, pclk ]

The list should be strictly ordered (defined), so:
  items:
    - const: ...
    - const: ...
    - const: ...
  minItems: 1

However the question is - why the clocks have different amount? Is it
per different SoC implementation?

> +
> +  "#phy-cells":
> +    const: 0
> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    const: phy
> +
> +  rockchip,phy-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the syscon managing the phy "general register files"
> +
> +  rockchip,pipe-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the syscon managing the pipe "general register files"
> +
> +  rockchip,pcie30-phymode:
> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> +    description: |
> +      use PHY_MODE_PCIE_AGGREGATION if not defined

I don't understand the description. Do you mean here a case when the
variable is missing?

> +    minimum: 0x0
> +    maximum: 0x4

Please explain these values. Register values should not be part of
bindings, but instead some logical behavior of hardware or its logic.

> +
> +

Just one blank line.

> +required:
> +  - compatible
> +  - reg
> +  - rockchip,phy-grf

phy-cells as well

> +
> +additionalProperties: false
> +
> +unevaluatedProperties: false

Just one please, additionalProperties.

> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3568-cru.h>
> +    pcie30phy: phy@fe8c0000 {
> +      compatible = "rockchip,rk3568-pcie3-phy";
> +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> +      #phy-cells = <0>;
> +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> +       <&cru PCLK_PCIE30PHY>;

Align the entry with opening '<'. Usually the most readable is one clock
per line.

> +      clock-names = "refclk_m", "refclk_n", "pclk";
> +      resets = <&cru SRST_PCIE30PHY>;
> +      reset-names = "phy";
> +      rockchip,phy-grf = <&pcie30_phy_grf>;
> +    };


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> Add a new binding file for Rockchip PCIe V3 phy driver.

Thank you for your patch. There is something to discuss/improve.

> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  .../bindings/phy/rockchip-pcie3-phy.yaml      | 77 +++++++++++++++++++
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> new file mode 100644
> index 000000000000..58a8ce175f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml

Filename: vendor,hardware
so for example "rockchip,pcie3-phy" although Rob proposed recently for
other bindings using compatible as a base:
https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/


> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip PCIe v3 phy
> +
> +maintainers:
> +  - Heiko Stuebner <heiko@sntech.de>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - rockchip,rk3568-pcie3-phy
> +      - rockchip,rk3588-pcie3-phy
> +
> +  reg:
> +    maxItems: 2
> +
> +  clocks:
> +    minItems: 1
> +    maxItems: 3
> +
> +  clock-names:
> +    contains:
> +      anyOf:
> +        - enum: [ refclk_m, refclk_n, pclk ]

The list should be strictly ordered (defined), so:
  items:
    - const: ...
    - const: ...
    - const: ...
  minItems: 1

However the question is - why the clocks have different amount? Is it
per different SoC implementation?

> +
> +  "#phy-cells":
> +    const: 0
> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    const: phy
> +
> +  rockchip,phy-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the syscon managing the phy "general register files"
> +
> +  rockchip,pipe-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the syscon managing the pipe "general register files"
> +
> +  rockchip,pcie30-phymode:
> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> +    description: |
> +      use PHY_MODE_PCIE_AGGREGATION if not defined

I don't understand the description. Do you mean here a case when the
variable is missing?

> +    minimum: 0x0
> +    maximum: 0x4

Please explain these values. Register values should not be part of
bindings, but instead some logical behavior of hardware or its logic.

> +
> +

Just one blank line.

> +required:
> +  - compatible
> +  - reg
> +  - rockchip,phy-grf

phy-cells as well

> +
> +additionalProperties: false
> +
> +unevaluatedProperties: false

Just one please, additionalProperties.

> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3568-cru.h>
> +    pcie30phy: phy@fe8c0000 {
> +      compatible = "rockchip,rk3568-pcie3-phy";
> +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> +      #phy-cells = <0>;
> +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> +       <&cru PCLK_PCIE30PHY>;

Align the entry with opening '<'. Usually the most readable is one clock
per line.

> +      clock-names = "refclk_m", "refclk_n", "pclk";
> +      resets = <&cru SRST_PCIE30PHY>;
> +      reset-names = "phy";
> +      rockchip,phy-grf = <&pcie30_phy_grf>;
> +    };


Best regards,
Krzysztof

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 17:52 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> > new file mode 100644
> > index 000000000000..58a8ce175f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
>
> Filename: vendor,hardware
> so for example "rockchip,pcie3-phy" although Rob proposed recently for
> other bindings using compatible as a base:
> https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/

ok, i rename

> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip PCIe v3 phy
> > +
> > +maintainers:
> > +  - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-pcie3-phy
> > +      - rockchip,rk3588-pcie3-phy
> > +
> > +  reg:
> > +    maxItems: 2
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 3
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - enum: [ refclk_m, refclk_n, pclk ]
>
> The list should be strictly ordered (defined), so:
>   items:
>     - const: ...
>     - const: ...
>     - const: ...
>   minItems: 1
>
> However the question is - why the clocks have different amount? Is it
> per different SoC implementation?

i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.

not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).

> > +
> > +  "#phy-cells":
> > +    const: 0
> > +
> > +  resets:
> > +    maxItems: 1
> > +
> > +  reset-names:
> > +    const: phy
> > +
> > +  rockchip,phy-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: phandle to the syscon managing the phy "general register files"
> > +
> > +  rockchip,pipe-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: phandle to the syscon managing the pipe "general register files"
> > +
> > +  rockchip,pcie30-phymode:
> > +    $ref: '/schemas/types.yaml#/definitions/uint32'
> > +    description: |
> > +      use PHY_MODE_PCIE_AGGREGATION if not defined
>
> I don't understand the description. Do you mean here a case when the
> variable is missing?

yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4

> > +    minimum: 0x0
> > +    maximum: 0x4
>
> Please explain these values. Register values should not be part of
> bindings, but instead some logical behavior of hardware or its logic.

it's a bitmask, so maybe

    description: |
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      use PHY_MODE_PCIE_AGGREGATION (4) as default

> > +
> > +
>
> Just one blank line.
>
> > +required:
> > +  - compatible
> > +  - reg
> > +  - rockchip,phy-grf
>
> phy-cells as well
>
> > +
> > +additionalProperties: false
> > +
> > +unevaluatedProperties: false
>
> Just one please, additionalProperties.
ok

> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rk3568-cru.h>
> > +    pcie30phy: phy@fe8c0000 {
> > +      compatible = "rockchip,rk3568-pcie3-phy";
> > +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> > +      #phy-cells = <0>;
> > +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> > +       <&cru PCLK_PCIE30PHY>;
>
> Align the entry with opening '<'. Usually the most readable is one clock
> per line.

ok

> > +      clock-names = "refclk_m", "refclk_n", "pclk";
> > +      resets = <&cru SRST_PCIE30PHY>;
> > +      reset-names = "phy";
> > +      rockchip,phy-grf = <&pcie30_phy_grf>;
> > +    };

regards Frank

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 17:52 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> > new file mode 100644
> > index 000000000000..58a8ce175f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
>
> Filename: vendor,hardware
> so for example "rockchip,pcie3-phy" although Rob proposed recently for
> other bindings using compatible as a base:
> https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/

ok, i rename

> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip PCIe v3 phy
> > +
> > +maintainers:
> > +  - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-pcie3-phy
> > +      - rockchip,rk3588-pcie3-phy
> > +
> > +  reg:
> > +    maxItems: 2
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 3
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - enum: [ refclk_m, refclk_n, pclk ]
>
> The list should be strictly ordered (defined), so:
>   items:
>     - const: ...
>     - const: ...
>     - const: ...
>   minItems: 1
>
> However the question is - why the clocks have different amount? Is it
> per different SoC implementation?

i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.

not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).

> > +
> > +  "#phy-cells":
> > +    const: 0
> > +
> > +  resets:
> > +    maxItems: 1
> > +
> > +  reset-names:
> > +    const: phy
> > +
> > +  rockchip,phy-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: phandle to the syscon managing the phy "general register files"
> > +
> > +  rockchip,pipe-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: phandle to the syscon managing the pipe "general register files"
> > +
> > +  rockchip,pcie30-phymode:
> > +    $ref: '/schemas/types.yaml#/definitions/uint32'
> > +    description: |
> > +      use PHY_MODE_PCIE_AGGREGATION if not defined
>
> I don't understand the description. Do you mean here a case when the
> variable is missing?

yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4

> > +    minimum: 0x0
> > +    maximum: 0x4
>
> Please explain these values. Register values should not be part of
> bindings, but instead some logical behavior of hardware or its logic.

it's a bitmask, so maybe

    description: |
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      use PHY_MODE_PCIE_AGGREGATION (4) as default

> > +
> > +
>
> Just one blank line.
>
> > +required:
> > +  - compatible
> > +  - reg
> > +  - rockchip,phy-grf
>
> phy-cells as well
>
> > +
> > +additionalProperties: false
> > +
> > +unevaluatedProperties: false
>
> Just one please, additionalProperties.
ok

> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rk3568-cru.h>
> > +    pcie30phy: phy@fe8c0000 {
> > +      compatible = "rockchip,rk3568-pcie3-phy";
> > +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> > +      #phy-cells = <0>;
> > +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> > +       <&cru PCLK_PCIE30PHY>;
>
> Align the entry with opening '<'. Usually the most readable is one clock
> per line.

ok

> > +      clock-names = "refclk_m", "refclk_n", "pclk";
> > +      resets = <&cru SRST_PCIE30PHY>;
> > +      reset-names = "phy";
> > +      rockchip,phy-grf = <&pcie30_phy_grf>;
> > +    };

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 17:52 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> > new file mode 100644
> > index 000000000000..58a8ce175f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
>
> Filename: vendor,hardware
> so for example "rockchip,pcie3-phy" although Rob proposed recently for
> other bindings using compatible as a base:
> https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/

ok, i rename

> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip PCIe v3 phy
> > +
> > +maintainers:
> > +  - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-pcie3-phy
> > +      - rockchip,rk3588-pcie3-phy
> > +
> > +  reg:
> > +    maxItems: 2
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 3
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - enum: [ refclk_m, refclk_n, pclk ]
>
> The list should be strictly ordered (defined), so:
>   items:
>     - const: ...
>     - const: ...
>     - const: ...
>   minItems: 1
>
> However the question is - why the clocks have different amount? Is it
> per different SoC implementation?

i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.

not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).

> > +
> > +  "#phy-cells":
> > +    const: 0
> > +
> > +  resets:
> > +    maxItems: 1
> > +
> > +  reset-names:
> > +    const: phy
> > +
> > +  rockchip,phy-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: phandle to the syscon managing the phy "general register files"
> > +
> > +  rockchip,pipe-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: phandle to the syscon managing the pipe "general register files"
> > +
> > +  rockchip,pcie30-phymode:
> > +    $ref: '/schemas/types.yaml#/definitions/uint32'
> > +    description: |
> > +      use PHY_MODE_PCIE_AGGREGATION if not defined
>
> I don't understand the description. Do you mean here a case when the
> variable is missing?

yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4

> > +    minimum: 0x0
> > +    maximum: 0x4
>
> Please explain these values. Register values should not be part of
> bindings, but instead some logical behavior of hardware or its logic.

it's a bitmask, so maybe

    description: |
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      use PHY_MODE_PCIE_AGGREGATION (4) as default

> > +
> > +
>
> Just one blank line.
>
> > +required:
> > +  - compatible
> > +  - reg
> > +  - rockchip,phy-grf
>
> phy-cells as well
>
> > +
> > +additionalProperties: false
> > +
> > +unevaluatedProperties: false
>
> Just one please, additionalProperties.
ok

> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rk3568-cru.h>
> > +    pcie30phy: phy@fe8c0000 {
> > +      compatible = "rockchip,rk3568-pcie3-phy";
> > +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> > +      #phy-cells = <0>;
> > +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> > +       <&cru PCLK_PCIE30PHY>;
>
> Align the entry with opening '<'. Usually the most readable is one clock
> per line.

ok

> > +      clock-names = "refclk_m", "refclk_n", "pclk";
> > +      resets = <&cru SRST_PCIE30PHY>;
> > +      reset-names = "phy";
> > +      rockchip,phy-grf = <&pcie30_phy_grf>;
> > +    };

regards Frank

Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 17:52 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> > new file mode 100644
> > index 000000000000..58a8ce175f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
>
> Filename: vendor,hardware
> so for example "rockchip,pcie3-phy" although Rob proposed recently for
> other bindings using compatible as a base:
> https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/

ok, i rename

> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip PCIe v3 phy
> > +
> > +maintainers:
> > +  - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-pcie3-phy
> > +      - rockchip,rk3588-pcie3-phy
> > +
> > +  reg:
> > +    maxItems: 2
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 3
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - enum: [ refclk_m, refclk_n, pclk ]
>
> The list should be strictly ordered (defined), so:
>   items:
>     - const: ...
>     - const: ...
>     - const: ...
>   minItems: 1
>
> However the question is - why the clocks have different amount? Is it
> per different SoC implementation?

i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.

not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).

> > +
> > +  "#phy-cells":
> > +    const: 0
> > +
> > +  resets:
> > +    maxItems: 1
> > +
> > +  reset-names:
> > +    const: phy
> > +
> > +  rockchip,phy-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: phandle to the syscon managing the phy "general register files"
> > +
> > +  rockchip,pipe-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: phandle to the syscon managing the pipe "general register files"
> > +
> > +  rockchip,pcie30-phymode:
> > +    $ref: '/schemas/types.yaml#/definitions/uint32'
> > +    description: |
> > +      use PHY_MODE_PCIE_AGGREGATION if not defined
>
> I don't understand the description. Do you mean here a case when the
> variable is missing?

yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4

> > +    minimum: 0x0
> > +    maximum: 0x4
>
> Please explain these values. Register values should not be part of
> bindings, but instead some logical behavior of hardware or its logic.

it's a bitmask, so maybe

    description: |
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      use PHY_MODE_PCIE_AGGREGATION (4) as default

> > +
> > +
>
> Just one blank line.
>
> > +required:
> > +  - compatible
> > +  - reg
> > +  - rockchip,phy-grf
>
> phy-cells as well
>
> > +
> > +additionalProperties: false
> > +
> > +unevaluatedProperties: false
>
> Just one please, additionalProperties.
ok

> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rk3568-cru.h>
> > +    pcie30phy: phy@fe8c0000 {
> > +      compatible = "rockchip,rk3568-pcie3-phy";
> > +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> > +      #phy-cells = <0>;
> > +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> > +       <&cru PCLK_PCIE30PHY>;
>
> Align the entry with opening '<'. Usually the most readable is one clock
> per line.

ok

> > +      clock-names = "refclk_m", "refclk_n", "pclk";
> > +      resets = <&cru SRST_PCIE30PHY>;
> > +      reset-names = "phy";
> > +      rockchip,phy-grf = <&pcie30_phy_grf>;
> > +    };

regards Frank

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 19/04/2022 19:49, Frank Wunderlich wrote:
>> The list should be strictly ordered (defined), so:
>>   items:
>>     - const: ...
>>     - const: ...
>>     - const: ...
>>   minItems: 1
>>
>> However the question is - why the clocks have different amount? Is it
>> per different SoC implementation?
> 
> i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> 
> not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).

You can skip RK3588 compatible or define it this strictly also for that
chip.

> 
>>> +
>>> +  "#phy-cells":
>>> +    const: 0
>>> +
>>> +  resets:
>>> +    maxItems: 1
>>> +
>>> +  reset-names:
>>> +    const: phy
>>> +
>>> +  rockchip,phy-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: phandle to the syscon managing the phy "general register files"
>>> +
>>> +  rockchip,pipe-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: phandle to the syscon managing the pipe "general register files"
>>> +
>>> +  rockchip,pcie30-phymode:
>>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
>>> +    description: |
>>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
>>
>> I don't understand the description. Do you mean here a case when the
>> variable is missing?
> 
> yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4

Then just use "default: 4"

> 
>>> +    minimum: 0x0
>>> +    maximum: 0x4
>>
>> Please explain these values. Register values should not be part of
>> bindings, but instead some logical behavior of hardware or its logic.
> 
> it's a bitmask, so maybe
> 
>     description: |
>       bit0: bifurcation for port 0
>       bit1: bifurcation for port 1
>       bit2: aggregation

That's good. I got impression you have a header with these values. If
yes - mention it here.

>       use PHY_MODE_PCIE_AGGREGATION (4) as default

Just use default as I wrote above.

Best regards,
Krzysztof

Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 19/04/2022 19:49, Frank Wunderlich wrote:
>> The list should be strictly ordered (defined), so:
>>   items:
>>     - const: ...
>>     - const: ...
>>     - const: ...
>>   minItems: 1
>>
>> However the question is - why the clocks have different amount? Is it
>> per different SoC implementation?
> 
> i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> 
> not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).

You can skip RK3588 compatible or define it this strictly also for that
chip.

> 
>>> +
>>> +  "#phy-cells":
>>> +    const: 0
>>> +
>>> +  resets:
>>> +    maxItems: 1
>>> +
>>> +  reset-names:
>>> +    const: phy
>>> +
>>> +  rockchip,phy-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: phandle to the syscon managing the phy "general register files"
>>> +
>>> +  rockchip,pipe-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: phandle to the syscon managing the pipe "general register files"
>>> +
>>> +  rockchip,pcie30-phymode:
>>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
>>> +    description: |
>>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
>>
>> I don't understand the description. Do you mean here a case when the
>> variable is missing?
> 
> yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4

Then just use "default: 4"

> 
>>> +    minimum: 0x0
>>> +    maximum: 0x4
>>
>> Please explain these values. Register values should not be part of
>> bindings, but instead some logical behavior of hardware or its logic.
> 
> it's a bitmask, so maybe
> 
>     description: |
>       bit0: bifurcation for port 0
>       bit1: bifurcation for port 1
>       bit2: aggregation

That's good. I got impression you have a header with these values. If
yes - mention it here.

>       use PHY_MODE_PCIE_AGGREGATION (4) as default

Just use default as I wrote above.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 19/04/2022 19:49, Frank Wunderlich wrote:
>> The list should be strictly ordered (defined), so:
>>   items:
>>     - const: ...
>>     - const: ...
>>     - const: ...
>>   minItems: 1
>>
>> However the question is - why the clocks have different amount? Is it
>> per different SoC implementation?
> 
> i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> 
> not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).

You can skip RK3588 compatible or define it this strictly also for that
chip.

> 
>>> +
>>> +  "#phy-cells":
>>> +    const: 0
>>> +
>>> +  resets:
>>> +    maxItems: 1
>>> +
>>> +  reset-names:
>>> +    const: phy
>>> +
>>> +  rockchip,phy-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: phandle to the syscon managing the phy "general register files"
>>> +
>>> +  rockchip,pipe-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: phandle to the syscon managing the pipe "general register files"
>>> +
>>> +  rockchip,pcie30-phymode:
>>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
>>> +    description: |
>>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
>>
>> I don't understand the description. Do you mean here a case when the
>> variable is missing?
> 
> yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4

Then just use "default: 4"

> 
>>> +    minimum: 0x0
>>> +    maximum: 0x4
>>
>> Please explain these values. Register values should not be part of
>> bindings, but instead some logical behavior of hardware or its logic.
> 
> it's a bitmask, so maybe
> 
>     description: |
>       bit0: bifurcation for port 0
>       bit1: bifurcation for port 1
>       bit2: aggregation

That's good. I got impression you have a header with these values. If
yes - mention it here.

>       use PHY_MODE_PCIE_AGGREGATION (4) as default

Just use default as I wrote above.

Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 19/04/2022 19:49, Frank Wunderlich wrote:
>> The list should be strictly ordered (defined), so:
>>   items:
>>     - const: ...
>>     - const: ...
>>     - const: ...
>>   minItems: 1
>>
>> However the question is - why the clocks have different amount? Is it
>> per different SoC implementation?
> 
> i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> 
> not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).

You can skip RK3588 compatible or define it this strictly also for that
chip.

> 
>>> +
>>> +  "#phy-cells":
>>> +    const: 0
>>> +
>>> +  resets:
>>> +    maxItems: 1
>>> +
>>> +  reset-names:
>>> +    const: phy
>>> +
>>> +  rockchip,phy-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: phandle to the syscon managing the phy "general register files"
>>> +
>>> +  rockchip,pipe-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: phandle to the syscon managing the pipe "general register files"
>>> +
>>> +  rockchip,pcie30-phymode:
>>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
>>> +    description: |
>>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
>>
>> I don't understand the description. Do you mean here a case when the
>> variable is missing?
> 
> yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4

Then just use "default: 4"

> 
>>> +    minimum: 0x0
>>> +    maximum: 0x4
>>
>> Please explain these values. Register values should not be part of
>> bindings, but instead some logical behavior of hardware or its logic.
> 
> it's a bitmask, so maybe
> 
>     description: |
>       bit0: bifurcation for port 0
>       bit1: bifurcation for port 1
>       bit2: aggregation

That's good. I got impression you have a header with these values. If
yes - mention it here.

>       use PHY_MODE_PCIE_AGGREGATION (4) as default

Just use default as I wrote above.

Best regards,
Krzysztof

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

> Gesendet: Dienstag, 19. April 2022 um 21:43 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: "Frank Wunderlich" <linux@fw-web.de>, linux-rockchip@lists.infradead.org, "Kishon Vijay Abraham I" <kishon@ti.com>, "Vinod Koul" <vkoul@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "Heiko Stuebner" <heiko@sntech.de>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Krzysztof Wilczyński" <kw@linux.com>, "Bjorn Helgaas" <bhelgaas@google.com>, "Philipp Zabel" <p.zabel@pengutronix.de>, "Johan Jonker" <jbx6244@gmail.com>, "Peter Geis" <pgwipeout@gmail.com>, "Michael Riesch" <michael.riesch@wolfvision.net>, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
> Betreff: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
>
> On 19/04/2022 19:49, Frank Wunderlich wrote:
> >> The list should be strictly ordered (defined), so:
> >>   items:
> >>     - const: ...
> >>     - const: ...
> >>     - const: ...
> >>   minItems: 1
> >>
> >> However the question is - why the clocks have different amount? Is it
> >> per different SoC implementation?
> > 
> > i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> > in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> > 
> > not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).
> 
> You can skip RK3588 compatible or define it this strictly also for that
> chip.

currently driver does clk_bulk initialization so i would define it like you suggested (without any SoC specific switch):

  clocks:
    minItems: 1
    maxItems: 3

  clock-names:
    items:
      - const: "refclk_m"
      - const: "refclk_n"
      - const: "pclk"

    minItems: 1

> >>> +
> >>> +  "#phy-cells":
> >>> +    const: 0
> >>> +
> >>> +  resets:
> >>> +    maxItems: 1
> >>> +
> >>> +  reset-names:
> >>> +    const: phy
> >>> +
> >>> +  rockchip,phy-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the phy "general register files"
> >>> +
> >>> +  rockchip,pipe-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the pipe "general register files"
> >>> +
> >>> +  rockchip,pcie30-phymode:
> >>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> >>> +    description: |
> >>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
> >>
> >> I don't understand the description. Do you mean here a case when the
> >> variable is missing?
> > 
> > yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4
> 
> Then just use "default: 4"
> 
> > 
> >>> +    minimum: 0x0
> >>> +    maximum: 0x4
> >>
> >> Please explain these values. Register values should not be part of
> >> bindings, but instead some logical behavior of hardware or its logic.
> > 
> > it's a bitmask, so maybe
> > 
> >     description: |
> >       bit0: bifurcation for port 0
> >       bit1: bifurcation for port 1
> >       bit2: aggregation
> 
> That's good. I got impression you have a header with these values. If
> yes - mention it here.
> 
> >       use PHY_MODE_PCIE_AGGREGATION (4) as default
> 
> Just use default as I wrote above.

so like this?

  rockchip,pcie30-phymode:
    $ref: '/schemas/types.yaml#/definitions/uint32'
    description: |
      set the phy-mode for enabling bifurcation
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
    minimum: 0x0
    maximum: 0x4
    default: 0x4

regards Frank

Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

> Gesendet: Dienstag, 19. April 2022 um 21:43 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: "Frank Wunderlich" <linux@fw-web.de>, linux-rockchip@lists.infradead.org, "Kishon Vijay Abraham I" <kishon@ti.com>, "Vinod Koul" <vkoul@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "Heiko Stuebner" <heiko@sntech.de>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Krzysztof Wilczyński" <kw@linux.com>, "Bjorn Helgaas" <bhelgaas@google.com>, "Philipp Zabel" <p.zabel@pengutronix.de>, "Johan Jonker" <jbx6244@gmail.com>, "Peter Geis" <pgwipeout@gmail.com>, "Michael Riesch" <michael.riesch@wolfvision.net>, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
> Betreff: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
>
> On 19/04/2022 19:49, Frank Wunderlich wrote:
> >> The list should be strictly ordered (defined), so:
> >>   items:
> >>     - const: ...
> >>     - const: ...
> >>     - const: ...
> >>   minItems: 1
> >>
> >> However the question is - why the clocks have different amount? Is it
> >> per different SoC implementation?
> > 
> > i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> > in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> > 
> > not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).
> 
> You can skip RK3588 compatible or define it this strictly also for that
> chip.

currently driver does clk_bulk initialization so i would define it like you suggested (without any SoC specific switch):

  clocks:
    minItems: 1
    maxItems: 3

  clock-names:
    items:
      - const: "refclk_m"
      - const: "refclk_n"
      - const: "pclk"

    minItems: 1

> >>> +
> >>> +  "#phy-cells":
> >>> +    const: 0
> >>> +
> >>> +  resets:
> >>> +    maxItems: 1
> >>> +
> >>> +  reset-names:
> >>> +    const: phy
> >>> +
> >>> +  rockchip,phy-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the phy "general register files"
> >>> +
> >>> +  rockchip,pipe-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the pipe "general register files"
> >>> +
> >>> +  rockchip,pcie30-phymode:
> >>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> >>> +    description: |
> >>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
> >>
> >> I don't understand the description. Do you mean here a case when the
> >> variable is missing?
> > 
> > yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4
> 
> Then just use "default: 4"
> 
> > 
> >>> +    minimum: 0x0
> >>> +    maximum: 0x4
> >>
> >> Please explain these values. Register values should not be part of
> >> bindings, but instead some logical behavior of hardware or its logic.
> > 
> > it's a bitmask, so maybe
> > 
> >     description: |
> >       bit0: bifurcation for port 0
> >       bit1: bifurcation for port 1
> >       bit2: aggregation
> 
> That's good. I got impression you have a header with these values. If
> yes - mention it here.
> 
> >       use PHY_MODE_PCIE_AGGREGATION (4) as default
> 
> Just use default as I wrote above.

so like this?

  rockchip,pcie30-phymode:
    $ref: '/schemas/types.yaml#/definitions/uint32'
    description: |
      set the phy-mode for enabling bifurcation
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
    minimum: 0x0
    maximum: 0x4
    default: 0x4

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

> Gesendet: Dienstag, 19. April 2022 um 21:43 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: "Frank Wunderlich" <linux@fw-web.de>, linux-rockchip@lists.infradead.org, "Kishon Vijay Abraham I" <kishon@ti.com>, "Vinod Koul" <vkoul@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "Heiko Stuebner" <heiko@sntech.de>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Krzysztof Wilczyński" <kw@linux.com>, "Bjorn Helgaas" <bhelgaas@google.com>, "Philipp Zabel" <p.zabel@pengutronix.de>, "Johan Jonker" <jbx6244@gmail.com>, "Peter Geis" <pgwipeout@gmail.com>, "Michael Riesch" <michael.riesch@wolfvision.net>, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
> Betreff: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
>
> On 19/04/2022 19:49, Frank Wunderlich wrote:
> >> The list should be strictly ordered (defined), so:
> >>   items:
> >>     - const: ...
> >>     - const: ...
> >>     - const: ...
> >>   minItems: 1
> >>
> >> However the question is - why the clocks have different amount? Is it
> >> per different SoC implementation?
> > 
> > i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> > in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> > 
> > not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).
> 
> You can skip RK3588 compatible or define it this strictly also for that
> chip.

currently driver does clk_bulk initialization so i would define it like you suggested (without any SoC specific switch):

  clocks:
    minItems: 1
    maxItems: 3

  clock-names:
    items:
      - const: "refclk_m"
      - const: "refclk_n"
      - const: "pclk"

    minItems: 1

> >>> +
> >>> +  "#phy-cells":
> >>> +    const: 0
> >>> +
> >>> +  resets:
> >>> +    maxItems: 1
> >>> +
> >>> +  reset-names:
> >>> +    const: phy
> >>> +
> >>> +  rockchip,phy-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the phy "general register files"
> >>> +
> >>> +  rockchip,pipe-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the pipe "general register files"
> >>> +
> >>> +  rockchip,pcie30-phymode:
> >>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> >>> +    description: |
> >>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
> >>
> >> I don't understand the description. Do you mean here a case when the
> >> variable is missing?
> > 
> > yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4
> 
> Then just use "default: 4"
> 
> > 
> >>> +    minimum: 0x0
> >>> +    maximum: 0x4
> >>
> >> Please explain these values. Register values should not be part of
> >> bindings, but instead some logical behavior of hardware or its logic.
> > 
> > it's a bitmask, so maybe
> > 
> >     description: |
> >       bit0: bifurcation for port 0
> >       bit1: bifurcation for port 1
> >       bit2: aggregation
> 
> That's good. I got impression you have a header with these values. If
> yes - mention it here.
> 
> >       use PHY_MODE_PCIE_AGGREGATION (4) as default
> 
> Just use default as I wrote above.

so like this?

  rockchip,pcie30-phymode:
    $ref: '/schemas/types.yaml#/definitions/uint32'
    description: |
      set the phy-mode for enabling bifurcation
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
    minimum: 0x0
    maximum: 0x4
    default: 0x4

regards Frank

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Frank Wunderlich]

> Gesendet: Dienstag, 19. April 2022 um 21:43 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: "Frank Wunderlich" <linux@fw-web.de>, linux-rockchip@lists.infradead.org, "Kishon Vijay Abraham I" <kishon@ti.com>, "Vinod Koul" <vkoul@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "Heiko Stuebner" <heiko@sntech.de>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Krzysztof Wilczyński" <kw@linux.com>, "Bjorn Helgaas" <bhelgaas@google.com>, "Philipp Zabel" <p.zabel@pengutronix.de>, "Johan Jonker" <jbx6244@gmail.com>, "Peter Geis" <pgwipeout@gmail.com>, "Michael Riesch" <michael.riesch@wolfvision.net>, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
> Betreff: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
>
> On 19/04/2022 19:49, Frank Wunderlich wrote:
> >> The list should be strictly ordered (defined), so:
> >>   items:
> >>     - const: ...
> >>     - const: ...
> >>     - const: ...
> >>   minItems: 1
> >>
> >> However the question is - why the clocks have different amount? Is it
> >> per different SoC implementation?
> > 
> > i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> > in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> > 
> > not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).
> 
> You can skip RK3588 compatible or define it this strictly also for that
> chip.

currently driver does clk_bulk initialization so i would define it like you suggested (without any SoC specific switch):

  clocks:
    minItems: 1
    maxItems: 3

  clock-names:
    items:
      - const: "refclk_m"
      - const: "refclk_n"
      - const: "pclk"

    minItems: 1

> >>> +
> >>> +  "#phy-cells":
> >>> +    const: 0
> >>> +
> >>> +  resets:
> >>> +    maxItems: 1
> >>> +
> >>> +  reset-names:
> >>> +    const: phy
> >>> +
> >>> +  rockchip,phy-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the phy "general register files"
> >>> +
> >>> +  rockchip,pipe-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the pipe "general register files"
> >>> +
> >>> +  rockchip,pcie30-phymode:
> >>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> >>> +    description: |
> >>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
> >>
> >> I don't understand the description. Do you mean here a case when the
> >> variable is missing?
> > 
> > yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4
> 
> Then just use "default: 4"
> 
> > 
> >>> +    minimum: 0x0
> >>> +    maximum: 0x4
> >>
> >> Please explain these values. Register values should not be part of
> >> bindings, but instead some logical behavior of hardware or its logic.
> > 
> > it's a bitmask, so maybe
> > 
> >     description: |
> >       bit0: bifurcation for port 0
> >       bit1: bifurcation for port 1
> >       bit2: aggregation
> 
> That's good. I got impression you have a header with these values. If
> yes - mention it here.
> 
> >       use PHY_MODE_PCIE_AGGREGATION (4) as default
> 
> Just use default as I wrote above.

so like this?

  rockchip,pcie30-phymode:
    $ref: '/schemas/types.yaml#/definitions/uint32'
    description: |
      set the phy-mode for enabling bifurcation
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
    minimum: 0x0
    maximum: 0x4
    default: 0x4

regards Frank

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 19/04/2022 22:36, Frank Wunderlich wrote:
>> Just use default as I wrote above.
> 
> so like this?
> 
>   rockchip,pcie30-phymode:
>     $ref: '/schemas/types.yaml#/definitions/uint32'
>     description: |
>       set the phy-mode for enabling bifurcation
>       bit0: bifurcation for port 0
>       bit1: bifurcation for port 1
>       bit2: aggregation
>       constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
>     minimum: 0x0
>     maximum: 0x4
>     default: 0x4

Yes.


Best regards,
Krzysztof

Re: Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 19/04/2022 22:36, Frank Wunderlich wrote:
>> Just use default as I wrote above.
> 
> so like this?
> 
>   rockchip,pcie30-phymode:
>     $ref: '/schemas/types.yaml#/definitions/uint32'
>     description: |
>       set the phy-mode for enabling bifurcation
>       bit0: bifurcation for port 0
>       bit1: bifurcation for port 1
>       bit2: aggregation
>       constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
>     minimum: 0x0
>     maximum: 0x4
>     default: 0x4

Yes.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 19/04/2022 22:36, Frank Wunderlich wrote:
>> Just use default as I wrote above.
> 
> so like this?
> 
>   rockchip,pcie30-phymode:
>     $ref: '/schemas/types.yaml#/definitions/uint32'
>     description: |
>       set the phy-mode for enabling bifurcation
>       bit0: bifurcation for port 0
>       bit1: bifurcation for port 1
>       bit2: aggregation
>       constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
>     minimum: 0x0
>     maximum: 0x4
>     default: 0x4

Yes.


Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

[Krzysztof Kozlowski]

On 19/04/2022 22:36, Frank Wunderlich wrote:
>> Just use default as I wrote above.
> 
> so like this?
> 
>   rockchip,pcie30-phymode:
>     $ref: '/schemas/types.yaml#/definitions/uint32'
>     description: |
>       set the phy-mode for enabling bifurcation
>       bit0: bifurcation for port 0
>       bit1: bifurcation for port 1
>       bit2: aggregation
>       constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
>     minimum: 0x0
>     maximum: 0x4
>     default: 0x4

Yes.


Best regards,
Krzysztof

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add compatibles for PCIe v3 General Register Files.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 3be3cfd52f7b..ae48b58bd062 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -14,6 +14,8 @@ properties:
     oneOf:
       - items:
           - enum:
+              - rockchip,pcie30-phy-grf
+              - rockchip,pcie30-pipe-grf
               - rockchip,rk3288-sgrf
               - rockchip,rk3566-pipe-grf
               - rockchip,rk3568-usb2phy-grf
-- 
2.25.1

[RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add compatibles for PCIe v3 General Register Files.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 3be3cfd52f7b..ae48b58bd062 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -14,6 +14,8 @@ properties:
     oneOf:
       - items:
           - enum:
+              - rockchip,pcie30-phy-grf
+              - rockchip,pcie30-pipe-grf
               - rockchip,rk3288-sgrf
               - rockchip,rk3566-pipe-grf
               - rockchip,rk3568-usb2phy-grf
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add compatibles for PCIe v3 General Register Files.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 3be3cfd52f7b..ae48b58bd062 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -14,6 +14,8 @@ properties:
     oneOf:
       - items:
           - enum:
+              - rockchip,pcie30-phy-grf
+              - rockchip,pcie30-pipe-grf
               - rockchip,rk3288-sgrf
               - rockchip,rk3566-pipe-grf
               - rockchip,rk3568-usb2phy-grf
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add compatibles for PCIe v3 General Register Files.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 3be3cfd52f7b..ae48b58bd062 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -14,6 +14,8 @@ properties:
     oneOf:
       - items:
           - enum:
+              - rockchip,pcie30-phy-grf
+              - rockchip,pcie30-pipe-grf
               - rockchip,rk3288-sgrf
               - rockchip,rk3566-pipe-grf
               - rockchip,rk3568-usb2phy-grf
-- 
2.25.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> Add compatibles for PCIe v3 General Register Files.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> index 3be3cfd52f7b..ae48b58bd062 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> @@ -14,6 +14,8 @@ properties:
>      oneOf:
>        - items:
>            - enum:
> +              - rockchip,pcie30-phy-grf
> +              - rockchip,pcie30-pipe-grf

These are without SoC parts. Are these PCIe v3 General Register Files
part of some PCIe spec?

>                - rockchip,rk3288-sgrf
>                - rockchip,rk3566-pipe-grf
>                - rockchip,rk3568-usb2phy-grf


Best regards,
Krzysztof

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> Add compatibles for PCIe v3 General Register Files.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> index 3be3cfd52f7b..ae48b58bd062 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> @@ -14,6 +14,8 @@ properties:
>      oneOf:
>        - items:
>            - enum:
> +              - rockchip,pcie30-phy-grf
> +              - rockchip,pcie30-pipe-grf

These are without SoC parts. Are these PCIe v3 General Register Files
part of some PCIe spec?

>                - rockchip,rk3288-sgrf
>                - rockchip,rk3566-pipe-grf
>                - rockchip,rk3568-usb2phy-grf


Best regards,
Krzysztof

Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> Add compatibles for PCIe v3 General Register Files.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> index 3be3cfd52f7b..ae48b58bd062 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> @@ -14,6 +14,8 @@ properties:
>      oneOf:
>        - items:
>            - enum:
> +              - rockchip,pcie30-phy-grf
> +              - rockchip,pcie30-pipe-grf

These are without SoC parts. Are these PCIe v3 General Register Files
part of some PCIe spec?

>                - rockchip,rk3288-sgrf
>                - rockchip,rk3566-pipe-grf
>                - rockchip,rk3568-usb2phy-grf


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> Add compatibles for PCIe v3 General Register Files.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> index 3be3cfd52f7b..ae48b58bd062 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> @@ -14,6 +14,8 @@ properties:
>      oneOf:
>        - items:
>            - enum:
> +              - rockchip,pcie30-phy-grf
> +              - rockchip,pcie30-pipe-grf

These are without SoC parts. Are these PCIe v3 General Register Files
part of some PCIe spec?

>                - rockchip,rk3288-sgrf
>                - rockchip,rk3566-pipe-grf
>                - rockchip,rk3568-usb2phy-grf


Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>

> > --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> > +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> > @@ -14,6 +14,8 @@ properties:
> >      oneOf:
> >        - items:
> >            - enum:
> > +              - rockchip,pcie30-phy-grf
> > +              - rockchip,pcie30-pipe-grf
>
> These are without SoC parts. Are these PCIe v3 General Register Files
> part of some PCIe spec?

imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.

pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.

so i have left them SoC independed.

> >                - rockchip,rk3288-sgrf
> >                - rockchip,rk3566-pipe-grf
> >                - rockchip,rk3568-usb2phy-grf

regards Frank

Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>

> > --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> > +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> > @@ -14,6 +14,8 @@ properties:
> >      oneOf:
> >        - items:
> >            - enum:
> > +              - rockchip,pcie30-phy-grf
> > +              - rockchip,pcie30-pipe-grf
>
> These are without SoC parts. Are these PCIe v3 General Register Files
> part of some PCIe spec?

imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.

pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.

so i have left them SoC independed.

> >                - rockchip,rk3288-sgrf
> >                - rockchip,rk3566-pipe-grf
> >                - rockchip,rk3568-usb2phy-grf

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>

> > --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> > +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> > @@ -14,6 +14,8 @@ properties:
> >      oneOf:
> >        - items:
> >            - enum:
> > +              - rockchip,pcie30-phy-grf
> > +              - rockchip,pcie30-pipe-grf
>
> These are without SoC parts. Are these PCIe v3 General Register Files
> part of some PCIe spec?

imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.

pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.

so i have left them SoC independed.

> >                - rockchip,rk3288-sgrf
> >                - rockchip,rk3566-pipe-grf
> >                - rockchip,rk3568-usb2phy-grf

regards Frank

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>

> > --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> > +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> > @@ -14,6 +14,8 @@ properties:
> >      oneOf:
> >        - items:
> >            - enum:
> > +              - rockchip,pcie30-phy-grf
> > +              - rockchip,pcie30-pipe-grf
>
> These are without SoC parts. Are these PCIe v3 General Register Files
> part of some PCIe spec?

imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.

pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.

so i have left them SoC independed.

> >                - rockchip,rk3288-sgrf
> >                - rockchip,rk3566-pipe-grf
> >                - rockchip,rk3568-usb2phy-grf

regards Frank

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Krzysztof Kozlowski]

On 19/04/2022 19:29, Frank Wunderlich wrote:
>> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
>> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> 
>>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> @@ -14,6 +14,8 @@ properties:
>>>      oneOf:
>>>        - items:
>>>            - enum:
>>> +              - rockchip,pcie30-phy-grf
>>> +              - rockchip,pcie30-pipe-grf
>>
>> These are without SoC parts. Are these PCIe v3 General Register Files
>> part of some PCIe spec?
> 
> imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
> 
> pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
> 
> so i have left them SoC independed.

Compatibles should be SoC dependent, with some exceptions. Lack of
documentation or lack of possibility of testing is actually argument
against any exception, so they should be SoC specific/dependent.


Best regards,
Krzysztof

Re: Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Krzysztof Kozlowski]

On 19/04/2022 19:29, Frank Wunderlich wrote:
>> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
>> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> 
>>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> @@ -14,6 +14,8 @@ properties:
>>>      oneOf:
>>>        - items:
>>>            - enum:
>>> +              - rockchip,pcie30-phy-grf
>>> +              - rockchip,pcie30-pipe-grf
>>
>> These are without SoC parts. Are these PCIe v3 General Register Files
>> part of some PCIe spec?
> 
> imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
> 
> pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
> 
> so i have left them SoC independed.

Compatibles should be SoC dependent, with some exceptions. Lack of
documentation or lack of possibility of testing is actually argument
against any exception, so they should be SoC specific/dependent.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Krzysztof Kozlowski]

On 19/04/2022 19:29, Frank Wunderlich wrote:
>> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
>> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> 
>>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> @@ -14,6 +14,8 @@ properties:
>>>      oneOf:
>>>        - items:
>>>            - enum:
>>> +              - rockchip,pcie30-phy-grf
>>> +              - rockchip,pcie30-pipe-grf
>>
>> These are without SoC parts. Are these PCIe v3 General Register Files
>> part of some PCIe spec?
> 
> imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
> 
> pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
> 
> so i have left them SoC independed.

Compatibles should be SoC dependent, with some exceptions. Lack of
documentation or lack of possibility of testing is actually argument
against any exception, so they should be SoC specific/dependent.


Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Krzysztof Kozlowski]

On 19/04/2022 19:29, Frank Wunderlich wrote:
>> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
>> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> 
>>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> @@ -14,6 +14,8 @@ properties:
>>>      oneOf:
>>>        - items:
>>>            - enum:
>>> +              - rockchip,pcie30-phy-grf
>>> +              - rockchip,pcie30-pipe-grf
>>
>> These are without SoC parts. Are these PCIe v3 General Register Files
>> part of some PCIe spec?
> 
> imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
> 
> pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
> 
> so i have left them SoC independed.

Compatibles should be SoC dependent, with some exceptions. Lack of
documentation or lack of possibility of testing is actually argument
against any exception, so they should be SoC specific/dependent.


Best regards,
Krzysztof

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Aw: Re: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

> Gesendet: Dienstag, 19. April 2022 um 21:40 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> On 19/04/2022 19:29, Frank Wunderlich wrote:
> >> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
> >> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> >
> >>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> >>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> >>> @@ -14,6 +14,8 @@ properties:
> >>>      oneOf:
> >>>        - items:
> >>>            - enum:
> >>> +              - rockchip,pcie30-phy-grf
> >>> +              - rockchip,pcie30-pipe-grf
> >>
> >> These are without SoC parts. Are these PCIe v3 General Register Files
> >> part of some PCIe spec?
> >
> > imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> > PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
> >
> > pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
> >
> > so i have left them SoC independed.
>
> Compatibles should be SoC dependent, with some exceptions. Lack of
> documentation or lack of possibility of testing is actually argument
> against any exception, so they should be SoC specific/dependent.

so i will change to

              - rockchip,rk3568-pcie30-phy-grf
              - rockchip,rk3588-pcie30-pipe-grf

and maybe add

              - rockchip,rk3588-pcie30-phy-grf

these compatibles are not directly taken by any driver as the nodes be linked via phandle (rockchip,phy-grf property) from the phy driver (rockchip,rk3568-pcie3-phy / rockchip,rk3588-pcie3-phy). So these compatibles are only in the yaml and dts present.

regards Frank

Aw: Re: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

> Gesendet: Dienstag, 19. April 2022 um 21:40 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> On 19/04/2022 19:29, Frank Wunderlich wrote:
> >> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
> >> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> >
> >>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> >>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> >>> @@ -14,6 +14,8 @@ properties:
> >>>      oneOf:
> >>>        - items:
> >>>            - enum:
> >>> +              - rockchip,pcie30-phy-grf
> >>> +              - rockchip,pcie30-pipe-grf
> >>
> >> These are without SoC parts. Are these PCIe v3 General Register Files
> >> part of some PCIe spec?
> >
> > imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> > PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
> >
> > pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
> >
> > so i have left them SoC independed.
>
> Compatibles should be SoC dependent, with some exceptions. Lack of
> documentation or lack of possibility of testing is actually argument
> against any exception, so they should be SoC specific/dependent.

so i will change to

              - rockchip,rk3568-pcie30-phy-grf
              - rockchip,rk3588-pcie30-pipe-grf

and maybe add

              - rockchip,rk3588-pcie30-phy-grf

these compatibles are not directly taken by any driver as the nodes be linked via phandle (rockchip,phy-grf property) from the phy driver (rockchip,rk3568-pcie3-phy / rockchip,rk3588-pcie3-phy). So these compatibles are only in the yaml and dts present.

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

> Gesendet: Dienstag, 19. April 2022 um 21:40 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> On 19/04/2022 19:29, Frank Wunderlich wrote:
> >> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
> >> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> >
> >>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> >>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> >>> @@ -14,6 +14,8 @@ properties:
> >>>      oneOf:
> >>>        - items:
> >>>            - enum:
> >>> +              - rockchip,pcie30-phy-grf
> >>> +              - rockchip,pcie30-pipe-grf
> >>
> >> These are without SoC parts. Are these PCIe v3 General Register Files
> >> part of some PCIe spec?
> >
> > imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> > PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
> >
> > pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
> >
> > so i have left them SoC independed.
>
> Compatibles should be SoC dependent, with some exceptions. Lack of
> documentation or lack of possibility of testing is actually argument
> against any exception, so they should be SoC specific/dependent.

so i will change to

              - rockchip,rk3568-pcie30-phy-grf
              - rockchip,rk3588-pcie30-pipe-grf

and maybe add

              - rockchip,rk3588-pcie30-phy-grf

these compatibles are not directly taken by any driver as the nodes be linked via phandle (rockchip,phy-grf property) from the phy driver (rockchip,rk3568-pcie3-phy / rockchip,rk3588-pcie3-phy). So these compatibles are only in the yaml and dts present.

regards Frank

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Aw: Re: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf

[Frank Wunderlich]

> Gesendet: Dienstag, 19. April 2022 um 21:40 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> On 19/04/2022 19:29, Frank Wunderlich wrote:
> >> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
> >> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> >
> >>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> >>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> >>> @@ -14,6 +14,8 @@ properties:
> >>>      oneOf:
> >>>        - items:
> >>>            - enum:
> >>> +              - rockchip,pcie30-phy-grf
> >>> +              - rockchip,pcie30-pipe-grf
> >>
> >> These are without SoC parts. Are these PCIe v3 General Register Files
> >> part of some PCIe spec?
> >
> > imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> > PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
> >
> > pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
> >
> > so i have left them SoC independed.
>
> Compatibles should be SoC dependent, with some exceptions. Lack of
> documentation or lack of possibility of testing is actually argument
> against any exception, so they should be SoC specific/dependent.

so i will change to

              - rockchip,rk3568-pcie30-phy-grf
              - rockchip,rk3588-pcie30-pipe-grf

and maybe add

              - rockchip,rk3588-pcie30-phy-grf

these compatibles are not directly taken by any driver as the nodes be linked via phandle (rockchip,phy-grf property) from the phy driver (rockchip,rk3568-pcie3-phy / rockchip,rk3588-pcie3-phy). So these compatibles are only in the yaml and dts present.

regards Frank

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
It use a dedicated pcie-phy. Add support for this.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
driver was taken from linux 5.10 based on in
https://github.com/JeffyCN/mirrors
which now has disappeared
---
 drivers/phy/rockchip/Kconfig                  |   9 +
 drivers/phy/rockchip/Makefile                 |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
 include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
 include/linux/phy/pcie.h                      |  12 +
 5 files changed, 321 insertions(+)
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
 create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
 create mode 100644 include/linux/phy/pcie.h

diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index 9022e395c056..94360fc96a6f 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -83,6 +83,15 @@ config PHY_ROCKCHIP_PCIE
 	help
 	  Enable this to support the Rockchip PCIe PHY.
 
+config PHY_ROCKCHIP_SNPS_PCIE3
+	tristate "Rockchip Snps PCIe3 PHY Driver"
+	depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
+	depends on HAS_IOMEM
+	select GENERIC_PHY
+	select MFD_SYSCON
+	help
+	  Enable this to support the Rockchip snps PCIe3 PHY.
+
 config PHY_ROCKCHIP_TYPEC
 	tristate "Rockchip TYPEC PHY Driver"
 	depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index a5041efb5b8f..7eab129230d1 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)	+= phy-rockchip-inno-hdmi.o
 obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)	+= phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY)	+= phy-rockchip-naneng-combphy.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE)		+= phy-rockchip-pcie.o
+obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)	+= phy-rockchip-snps-pcie3.o
 obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)	+= phy-rockchip-typec.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB)		+= phy-rockchip-usb.o
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
new file mode 100644
index 000000000000..992b9709a97a
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip PCIE3.0 phy driver
+ *
+ * Copyright (C) 2020 Rockchip Electronics Co., Ltd.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/phy/pcie.h>
+#include <linux/phy/phy.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy-snps-pcie3.h>
+
+/* Register for RK3568 */
+#define GRF_PCIE30PHY_CON1 0x4
+#define GRF_PCIE30PHY_CON6 0x18
+#define GRF_PCIE30PHY_CON9 0x24
+#define GRF_PCIE30PHY_STATUS0 0x80
+#define SRAM_INIT_DONE(reg) (reg & BIT(14))
+
+/* Register for RK3588 */
+#define PHP_GRF_PCIESEL_CON 0x100
+#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
+#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
+#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
+#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
+
+struct rockchip_p3phy_ops;
+
+struct rockchip_p3phy_priv {
+	const struct rockchip_p3phy_ops *ops;
+	void __iomem *mmio;
+	/* mode: RC, EP */
+	int mode;
+	/* pcie30_phymode: Aggregation, Bifurcation */
+	int pcie30_phymode;
+	struct regmap *phy_grf;
+	struct regmap *pipe_grf;
+	struct reset_control *p30phy;
+	struct phy *phy;
+	struct clk_bulk_data *clks;
+	int num_clks;
+	bool is_bifurcation;
+};
+
+struct rockchip_p3phy_ops {
+	int (*phy_init)(struct rockchip_p3phy_priv *priv);
+};
+
+static int rockchip_p3phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+
+	/* Actually We don't care EP/RC mode, but just record it */
+	switch (submode) {
+	case PHY_MODE_PCIE_RC:
+		priv->mode = PHY_MODE_PCIE_RC;
+		break;
+	case PHY_MODE_PCIE_EP:
+		priv->mode = PHY_MODE_PCIE_EP;
+		break;
+	case PHY_MODE_PCIE_BIFURCATION:
+		priv->is_bifurcation = true;
+		break;
+	default:
+		pr_info("%s, invalid mode\n", __func__);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int rockchip_p3phy_rk3568_init(struct rockchip_p3phy_priv *priv)
+{
+	int ret = 0;
+	u32 reg;
+
+	/* Deassert PCIe PMA output clamp mode */
+	regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
+		     (0x1 << 15) | (0x1 << 31));
+	/* Set bifurcation if needed, and it doesn't care RC/EP */
+	if (priv->is_bifurcation) {
+		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON6,
+			     0x1 | (0xf << 16));
+		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON1,
+			     (0x1 << 15) | (0x1 << 31));
+	}
+
+	reset_control_deassert(priv->p30phy);
+
+	ret = regmap_read_poll_timeout(priv->phy_grf,
+				       GRF_PCIE30PHY_STATUS0,
+				       reg, SRAM_INIT_DONE(reg),
+				       0, 500);
+	if (ret)
+		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
+		       __func__, reg);
+	return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3568_ops = {
+	.phy_init = rockchip_p3phy_rk3568_init,
+};
+
+static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
+{
+	int ret = 0;
+	u32 reg;
+
+	/* Deassert PCIe PMA output clamp mode */
+	regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+		     (0x1 << 8) | (0x1 << 24));
+
+	reset_control_deassert(priv->p30phy);
+
+	ret = regmap_read_poll_timeout(priv->phy_grf,
+				       RK3588_PCIE3PHY_GRF_PHY0_STATUS1,
+				       reg, RK3588_SRAM_INIT_DONE(reg),
+				       0, 500);
+	ret |= regmap_read_poll_timeout(priv->phy_grf,
+					RK3588_PCIE3PHY_GRF_PHY1_STATUS1,
+					reg, RK3588_SRAM_INIT_DONE(reg),
+					0, 500);
+	if (ret)
+		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
+		       __func__, reg);
+	return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3588_ops = {
+	.phy_init = rockchip_p3phy_rk3588_init,
+};
+
+static int rochchip_p3phy_init(struct phy *phy)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+	int ret;
+
+	ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
+	if (ret) {
+		pr_err("failed to enable PCIe bulk clks %d\n", ret);
+		return ret;
+	}
+
+	reset_control_assert(priv->p30phy);
+	udelay(1);
+
+	if (priv->ops->phy_init) {
+		ret = priv->ops->phy_init(priv);
+		if (ret)
+			clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+	};
+
+	return ret;
+}
+
+static int rochchip_p3phy_exit(struct phy *phy)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+
+	clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+	reset_control_assert(priv->p30phy);
+	return 0;
+}
+
+static const struct phy_ops rochchip_p3phy_ops = {
+	.init = rochchip_p3phy_init,
+	.exit = rochchip_p3phy_exit,
+	.set_mode = rockchip_p3phy_set_mode,
+	.owner = THIS_MODULE,
+};
+
+static int rockchip_p3phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct rockchip_p3phy_priv *priv;
+	struct device_node *np = dev->of_node;
+	struct resource *res;
+	int ret;
+	u32 val, reg;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(priv->mmio)) {
+		ret = PTR_ERR(priv->mmio);
+		return ret;
+	}
+
+	priv->ops = of_device_get_match_data(&pdev->dev);
+	if (!priv->ops) {
+		dev_err(&pdev->dev, "no of match data provided\n");
+		return -EINVAL;
+	}
+
+	priv->phy_grf = syscon_regmap_lookup_by_phandle(np, "rockchip,phy-grf");
+	if (IS_ERR(priv->phy_grf)) {
+		dev_err(dev, "failed to find rockchip,phy_grf regmap\n");
+		return PTR_ERR(priv->phy_grf);
+	}
+
+	priv->pipe_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
+							 "rockchip,pipe-grf");
+	if (IS_ERR(priv->pipe_grf))
+		dev_info(dev, "failed to find rockchip,pipe_grf regmap\n");
+
+	ret = device_property_read_u32(dev, "rockchip,pcie30-phymode", &val);
+	if (!ret)
+		priv->pcie30_phymode = val;
+	else
+		priv->pcie30_phymode = PHY_MODE_PCIE_AGGREGATION;
+
+	/* Select correct pcie30_phymode */
+	if (priv->pcie30_phymode > 4)
+		priv->pcie30_phymode = PHY_MODE_PCIE_AGGREGATION;
+
+	regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+		     (0x7<<16) | priv->pcie30_phymode);
+
+	/* Set pcie1ln_sel in PHP_GRF_PCIESEL_CON */
+	if (!IS_ERR(priv->pipe_grf)) {
+		reg = priv->pcie30_phymode & 3;
+		if (reg)
+			regmap_write(priv->pipe_grf, PHP_GRF_PCIESEL_CON,
+				     (reg << 16) | reg);
+	};
+
+	priv->phy = devm_phy_create(dev, NULL, &rochchip_p3phy_ops);
+	if (IS_ERR(priv->phy)) {
+		dev_err(dev, "failed to create combphy\n");
+		return PTR_ERR(priv->phy);
+	}
+
+	priv->p30phy = devm_reset_control_get(dev, "phy");
+	if (IS_ERR(priv->p30phy)) {
+		dev_warn(dev, "no phy reset control specified\n");
+		priv->p30phy = NULL;
+	}
+
+	priv->num_clks = devm_clk_bulk_get_all(dev, &priv->clks);
+	if (priv->num_clks < 1)
+		return -ENODEV;
+
+	dev_set_drvdata(dev, priv);
+	phy_set_drvdata(priv->phy, priv);
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id rockchip_p3phy_of_match[] = {
+	{ .compatible = "rockchip,rk3568-pcie3-phy", .data = &rk3568_ops },
+	{ .compatible = "rockchip,rk3588-pcie3-phy", .data = &rk3588_ops },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, rockchip_p3phy_of_match);
+
+static struct platform_driver rockchip_p3phy_driver = {
+	.probe	= rockchip_p3phy_probe,
+	.driver = {
+		.name = "rockchip-snps-pcie3-phy",
+		.of_match_table = rockchip_p3phy_of_match,
+	},
+};
+module_platform_driver(rockchip_p3phy_driver);
+MODULE_DESCRIPTION("Rockchip Synopsys PCIe 3.0 PHY driver");
+MODULE_LICENSE("GPL");
diff --git a/include/dt-bindings/phy/phy-snps-pcie3.h b/include/dt-bindings/phy/phy-snps-pcie3.h
new file mode 100644
index 000000000000..5006947f2285
--- /dev/null
+++ b/include/dt-bindings/phy/phy-snps-pcie3.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#ifndef _DT_BINDINGS_PHY_SNPS_PCIE3
+#define _DT_BINDINGS_PHY_SNPS_PCIE3
+
+/*
+ * pcie30_phy_mode[2:0]
+ * bit2: aggregation
+ * bit1: bifurcation for port 1
+ * bit0: bifurcation for port 0
+ */
+#define PHY_MODE_PCIE_AGGREGATION 4	/* PCIe3x4 */
+#define PHY_MODE_PCIE_NANBNB	0	/* P1:PCIe3x2  +  P0:PCIe3x2 */
+#define PHY_MODE_PCIE_NANBBI	1	/* P1:PCIe3x2  +  P0:PCIe3x1*2 */
+#define PHY_MODE_PCIE_NABINB	2	/* P1:PCIe3x1*2 + P0:PCIe3x2 */
+#define PHY_MODE_PCIE_NABIBI	3	/* P1:PCIe3x1*2 + P0:PCIe3x1*2 */
+
+#endif /* _DT_BINDINGS_PHY_SNPS_PCIE3 */
diff --git a/include/linux/phy/pcie.h b/include/linux/phy/pcie.h
new file mode 100644
index 000000000000..93c997f520fe
--- /dev/null
+++ b/include/linux/phy/pcie.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+#ifndef __PHY_PCIE_H
+#define __PHY_PCIE_H
+
+#define PHY_MODE_PCIE_RC 20
+#define PHY_MODE_PCIE_EP 21
+#define PHY_MODE_PCIE_BIFURCATION 22
+
+#endif
-- 
2.25.1

[RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
It use a dedicated pcie-phy. Add support for this.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
driver was taken from linux 5.10 based on in
https://github.com/JeffyCN/mirrors
which now has disappeared
---
 drivers/phy/rockchip/Kconfig                  |   9 +
 drivers/phy/rockchip/Makefile                 |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
 include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
 include/linux/phy/pcie.h                      |  12 +
 5 files changed, 321 insertions(+)
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
 create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
 create mode 100644 include/linux/phy/pcie.h

diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index 9022e395c056..94360fc96a6f 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -83,6 +83,15 @@ config PHY_ROCKCHIP_PCIE
 	help
 	  Enable this to support the Rockchip PCIe PHY.
 
+config PHY_ROCKCHIP_SNPS_PCIE3
+	tristate "Rockchip Snps PCIe3 PHY Driver"
+	depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
+	depends on HAS_IOMEM
+	select GENERIC_PHY
+	select MFD_SYSCON
+	help
+	  Enable this to support the Rockchip snps PCIe3 PHY.
+
 config PHY_ROCKCHIP_TYPEC
 	tristate "Rockchip TYPEC PHY Driver"
 	depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index a5041efb5b8f..7eab129230d1 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)	+= phy-rockchip-inno-hdmi.o
 obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)	+= phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY)	+= phy-rockchip-naneng-combphy.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE)		+= phy-rockchip-pcie.o
+obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)	+= phy-rockchip-snps-pcie3.o
 obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)	+= phy-rockchip-typec.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB)		+= phy-rockchip-usb.o
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
new file mode 100644
index 000000000000..992b9709a97a
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip PCIE3.0 phy driver
+ *
+ * Copyright (C) 2020 Rockchip Electronics Co., Ltd.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/phy/pcie.h>
+#include <linux/phy/phy.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy-snps-pcie3.h>
+
+/* Register for RK3568 */
+#define GRF_PCIE30PHY_CON1 0x4
+#define GRF_PCIE30PHY_CON6 0x18
+#define GRF_PCIE30PHY_CON9 0x24
+#define GRF_PCIE30PHY_STATUS0 0x80
+#define SRAM_INIT_DONE(reg) (reg & BIT(14))
+
+/* Register for RK3588 */
+#define PHP_GRF_PCIESEL_CON 0x100
+#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
+#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
+#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
+#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
+
+struct rockchip_p3phy_ops;
+
+struct rockchip_p3phy_priv {
+	const struct rockchip_p3phy_ops *ops;
+	void __iomem *mmio;
+	/* mode: RC, EP */
+	int mode;
+	/* pcie30_phymode: Aggregation, Bifurcation */
+	int pcie30_phymode;
+	struct regmap *phy_grf;
+	struct regmap *pipe_grf;
+	struct reset_control *p30phy;
+	struct phy *phy;
+	struct clk_bulk_data *clks;
+	int num_clks;
+	bool is_bifurcation;
+};
+
+struct rockchip_p3phy_ops {
+	int (*phy_init)(struct rockchip_p3phy_priv *priv);
+};
+
+static int rockchip_p3phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+
+	/* Actually We don't care EP/RC mode, but just record it */
+	switch (submode) {
+	case PHY_MODE_PCIE_RC:
+		priv->mode = PHY_MODE_PCIE_RC;
+		break;
+	case PHY_MODE_PCIE_EP:
+		priv->mode = PHY_MODE_PCIE_EP;
+		break;
+	case PHY_MODE_PCIE_BIFURCATION:
+		priv->is_bifurcation = true;
+		break;
+	default:
+		pr_info("%s, invalid mode\n", __func__);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int rockchip_p3phy_rk3568_init(struct rockchip_p3phy_priv *priv)
+{
+	int ret = 0;
+	u32 reg;
+
+	/* Deassert PCIe PMA output clamp mode */
+	regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
+		     (0x1 << 15) | (0x1 << 31));
+	/* Set bifurcation if needed, and it doesn't care RC/EP */
+	if (priv->is_bifurcation) {
+		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON6,
+			     0x1 | (0xf << 16));
+		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON1,
+			     (0x1 << 15) | (0x1 << 31));
+	}
+
+	reset_control_deassert(priv->p30phy);
+
+	ret = regmap_read_poll_timeout(priv->phy_grf,
+				       GRF_PCIE30PHY_STATUS0,
+				       reg, SRAM_INIT_DONE(reg),
+				       0, 500);
+	if (ret)
+		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
+		       __func__, reg);
+	return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3568_ops = {
+	.phy_init = rockchip_p3phy_rk3568_init,
+};
+
+static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
+{
+	int ret = 0;
+	u32 reg;
+
+	/* Deassert PCIe PMA output clamp mode */
+	regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+		     (0x1 << 8) | (0x1 << 24));
+
+	reset_control_deassert(priv->p30phy);
+
+	ret = regmap_read_poll_timeout(priv->phy_grf,
+				       RK3588_PCIE3PHY_GRF_PHY0_STATUS1,
+				       reg, RK3588_SRAM_INIT_DONE(reg),
+				       0, 500);
+	ret |= regmap_read_poll_timeout(priv->phy_grf,
+					RK3588_PCIE3PHY_GRF_PHY1_STATUS1,
+					reg, RK3588_SRAM_INIT_DONE(reg),
+					0, 500);
+	if (ret)
+		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
+		       __func__, reg);
+	return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3588_ops = {
+	.phy_init = rockchip_p3phy_rk3588_init,
+};
+
+static int rochchip_p3phy_init(struct phy *phy)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+	int ret;
+
+	ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
+	if (ret) {
+		pr_err("failed to enable PCIe bulk clks %d\n", ret);
+		return ret;
+	}
+
+	reset_control_assert(priv->p30phy);
+	udelay(1);
+
+	if (priv->ops->phy_init) {
+		ret = priv->ops->phy_init(priv);
+		if (ret)
+			clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+	};
+
+	return ret;
+}
+
+static int rochchip_p3phy_exit(struct phy *phy)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+
+	clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+	reset_control_assert(priv->p30phy);
+	return 0;
+}
+
+static const struct phy_ops rochchip_p3phy_ops = {
+	.init = rochchip_p3phy_init,
+	.exit = rochchip_p3phy_exit,
+	.set_mode = rockchip_p3phy_set_mode,
+	.owner = THIS_MODULE,
+};
+
+static int rockchip_p3phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct rockchip_p3phy_priv *priv;
+	struct device_node *np = dev->of_node;
+	struct resource *res;
+	int ret;
+	u32 val, reg;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(priv->mmio)) {
+		ret = PTR_ERR(priv->mmio);
+		return ret;
+	}
+
+	priv->ops = of_device_get_match_data(&pdev->dev);
+	if (!priv->ops) {
+		dev_err(&pdev->dev, "no of match data provided\n");
+		return -EINVAL;
+	}
+
+	priv->phy_grf = syscon_regmap_lookup_by_phandle(np, "rockchip,phy-grf");
+	if (IS_ERR(priv->phy_grf)) {
+		dev_err(dev, "failed to find rockchip,phy_grf regmap\n");
+		return PTR_ERR(priv->phy_grf);
+	}
+
+	priv->pipe_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
+							 "rockchip,pipe-grf");
+	if (IS_ERR(priv->pipe_grf))
+		dev_info(dev, "failed to find rockchip,pipe_grf regmap\n");
+
+	ret = device_property_read_u32(dev, "rockchip,pcie30-phymode", &val);
+	if (!ret)
+		priv->pcie30_phymode = val;
+	else
+		priv->pcie30_phymode = PHY_MODE_PCIE_AGGREGATION;
+
+	/* Select correct pcie30_phymode */
+	if (priv->pcie30_phymode > 4)
+		priv->pcie30_phymode = PHY_MODE_PCIE_AGGREGATION;
+
+	regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+		     (0x7<<16) | priv->pcie30_phymode);
+
+	/* Set pcie1ln_sel in PHP_GRF_PCIESEL_CON */
+	if (!IS_ERR(priv->pipe_grf)) {
+		reg = priv->pcie30_phymode & 3;
+		if (reg)
+			regmap_write(priv->pipe_grf, PHP_GRF_PCIESEL_CON,
+				     (reg << 16) | reg);
+	};
+
+	priv->phy = devm_phy_create(dev, NULL, &rochchip_p3phy_ops);
+	if (IS_ERR(priv->phy)) {
+		dev_err(dev, "failed to create combphy\n");
+		return PTR_ERR(priv->phy);
+	}
+
+	priv->p30phy = devm_reset_control_get(dev, "phy");
+	if (IS_ERR(priv->p30phy)) {
+		dev_warn(dev, "no phy reset control specified\n");
+		priv->p30phy = NULL;
+	}
+
+	priv->num_clks = devm_clk_bulk_get_all(dev, &priv->clks);
+	if (priv->num_clks < 1)
+		return -ENODEV;
+
+	dev_set_drvdata(dev, priv);
+	phy_set_drvdata(priv->phy, priv);
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id rockchip_p3phy_of_match[] = {
+	{ .compatible = "rockchip,rk3568-pcie3-phy", .data = &rk3568_ops },
+	{ .compatible = "rockchip,rk3588-pcie3-phy", .data = &rk3588_ops },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, rockchip_p3phy_of_match);
+
+static struct platform_driver rockchip_p3phy_driver = {
+	.probe	= rockchip_p3phy_probe,
+	.driver = {
+		.name = "rockchip-snps-pcie3-phy",
+		.of_match_table = rockchip_p3phy_of_match,
+	},
+};
+module_platform_driver(rockchip_p3phy_driver);
+MODULE_DESCRIPTION("Rockchip Synopsys PCIe 3.0 PHY driver");
+MODULE_LICENSE("GPL");
diff --git a/include/dt-bindings/phy/phy-snps-pcie3.h b/include/dt-bindings/phy/phy-snps-pcie3.h
new file mode 100644
index 000000000000..5006947f2285
--- /dev/null
+++ b/include/dt-bindings/phy/phy-snps-pcie3.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#ifndef _DT_BINDINGS_PHY_SNPS_PCIE3
+#define _DT_BINDINGS_PHY_SNPS_PCIE3
+
+/*
+ * pcie30_phy_mode[2:0]
+ * bit2: aggregation
+ * bit1: bifurcation for port 1
+ * bit0: bifurcation for port 0
+ */
+#define PHY_MODE_PCIE_AGGREGATION 4	/* PCIe3x4 */
+#define PHY_MODE_PCIE_NANBNB	0	/* P1:PCIe3x2  +  P0:PCIe3x2 */
+#define PHY_MODE_PCIE_NANBBI	1	/* P1:PCIe3x2  +  P0:PCIe3x1*2 */
+#define PHY_MODE_PCIE_NABINB	2	/* P1:PCIe3x1*2 + P0:PCIe3x2 */
+#define PHY_MODE_PCIE_NABIBI	3	/* P1:PCIe3x1*2 + P0:PCIe3x1*2 */
+
+#endif /* _DT_BINDINGS_PHY_SNPS_PCIE3 */
diff --git a/include/linux/phy/pcie.h b/include/linux/phy/pcie.h
new file mode 100644
index 000000000000..93c997f520fe
--- /dev/null
+++ b/include/linux/phy/pcie.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+#ifndef __PHY_PCIE_H
+#define __PHY_PCIE_H
+
+#define PHY_MODE_PCIE_RC 20
+#define PHY_MODE_PCIE_EP 21
+#define PHY_MODE_PCIE_BIFURCATION 22
+
+#endif
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
It use a dedicated pcie-phy. Add support for this.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
driver was taken from linux 5.10 based on in
https://github.com/JeffyCN/mirrors
which now has disappeared
---
 drivers/phy/rockchip/Kconfig                  |   9 +
 drivers/phy/rockchip/Makefile                 |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
 include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
 include/linux/phy/pcie.h                      |  12 +
 5 files changed, 321 insertions(+)
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
 create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
 create mode 100644 include/linux/phy/pcie.h

diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index 9022e395c056..94360fc96a6f 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -83,6 +83,15 @@ config PHY_ROCKCHIP_PCIE
 	help
 	  Enable this to support the Rockchip PCIe PHY.
 
+config PHY_ROCKCHIP_SNPS_PCIE3
+	tristate "Rockchip Snps PCIe3 PHY Driver"
+	depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
+	depends on HAS_IOMEM
+	select GENERIC_PHY
+	select MFD_SYSCON
+	help
+	  Enable this to support the Rockchip snps PCIe3 PHY.
+
 config PHY_ROCKCHIP_TYPEC
 	tristate "Rockchip TYPEC PHY Driver"
 	depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index a5041efb5b8f..7eab129230d1 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)	+= phy-rockchip-inno-hdmi.o
 obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)	+= phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY)	+= phy-rockchip-naneng-combphy.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE)		+= phy-rockchip-pcie.o
+obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)	+= phy-rockchip-snps-pcie3.o
 obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)	+= phy-rockchip-typec.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB)		+= phy-rockchip-usb.o
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
new file mode 100644
index 000000000000..992b9709a97a
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip PCIE3.0 phy driver
+ *
+ * Copyright (C) 2020 Rockchip Electronics Co., Ltd.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/phy/pcie.h>
+#include <linux/phy/phy.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy-snps-pcie3.h>
+
+/* Register for RK3568 */
+#define GRF_PCIE30PHY_CON1 0x4
+#define GRF_PCIE30PHY_CON6 0x18
+#define GRF_PCIE30PHY_CON9 0x24
+#define GRF_PCIE30PHY_STATUS0 0x80
+#define SRAM_INIT_DONE(reg) (reg & BIT(14))
+
+/* Register for RK3588 */
+#define PHP_GRF_PCIESEL_CON 0x100
+#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
+#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
+#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
+#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
+
+struct rockchip_p3phy_ops;
+
+struct rockchip_p3phy_priv {
+	const struct rockchip_p3phy_ops *ops;
+	void __iomem *mmio;
+	/* mode: RC, EP */
+	int mode;
+	/* pcie30_phymode: Aggregation, Bifurcation */
+	int pcie30_phymode;
+	struct regmap *phy_grf;
+	struct regmap *pipe_grf;
+	struct reset_control *p30phy;
+	struct phy *phy;
+	struct clk_bulk_data *clks;
+	int num_clks;
+	bool is_bifurcation;
+};
+
+struct rockchip_p3phy_ops {
+	int (*phy_init)(struct rockchip_p3phy_priv *priv);
+};
+
+static int rockchip_p3phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+
+	/* Actually We don't care EP/RC mode, but just record it */
+	switch (submode) {
+	case PHY_MODE_PCIE_RC:
+		priv->mode = PHY_MODE_PCIE_RC;
+		break;
+	case PHY_MODE_PCIE_EP:
+		priv->mode = PHY_MODE_PCIE_EP;
+		break;
+	case PHY_MODE_PCIE_BIFURCATION:
+		priv->is_bifurcation = true;
+		break;
+	default:
+		pr_info("%s, invalid mode\n", __func__);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int rockchip_p3phy_rk3568_init(struct rockchip_p3phy_priv *priv)
+{
+	int ret = 0;
+	u32 reg;
+
+	/* Deassert PCIe PMA output clamp mode */
+	regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
+		     (0x1 << 15) | (0x1 << 31));
+	/* Set bifurcation if needed, and it doesn't care RC/EP */
+	if (priv->is_bifurcation) {
+		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON6,
+			     0x1 | (0xf << 16));
+		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON1,
+			     (0x1 << 15) | (0x1 << 31));
+	}
+
+	reset_control_deassert(priv->p30phy);
+
+	ret = regmap_read_poll_timeout(priv->phy_grf,
+				       GRF_PCIE30PHY_STATUS0,
+				       reg, SRAM_INIT_DONE(reg),
+				       0, 500);
+	if (ret)
+		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
+		       __func__, reg);
+	return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3568_ops = {
+	.phy_init = rockchip_p3phy_rk3568_init,
+};
+
+static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
+{
+	int ret = 0;
+	u32 reg;
+
+	/* Deassert PCIe PMA output clamp mode */
+	regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+		     (0x1 << 8) | (0x1 << 24));
+
+	reset_control_deassert(priv->p30phy);
+
+	ret = regmap_read_poll_timeout(priv->phy_grf,
+				       RK3588_PCIE3PHY_GRF_PHY0_STATUS1,
+				       reg, RK3588_SRAM_INIT_DONE(reg),
+				       0, 500);
+	ret |= regmap_read_poll_timeout(priv->phy_grf,
+					RK3588_PCIE3PHY_GRF_PHY1_STATUS1,
+					reg, RK3588_SRAM_INIT_DONE(reg),
+					0, 500);
+	if (ret)
+		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
+		       __func__, reg);
+	return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3588_ops = {
+	.phy_init = rockchip_p3phy_rk3588_init,
+};
+
+static int rochchip_p3phy_init(struct phy *phy)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+	int ret;
+
+	ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
+	if (ret) {
+		pr_err("failed to enable PCIe bulk clks %d\n", ret);
+		return ret;
+	}
+
+	reset_control_assert(priv->p30phy);
+	udelay(1);
+
+	if (priv->ops->phy_init) {
+		ret = priv->ops->phy_init(priv);
+		if (ret)
+			clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+	};
+
+	return ret;
+}
+
+static int rochchip_p3phy_exit(struct phy *phy)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+
+	clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+	reset_control_assert(priv->p30phy);
+	return 0;
+}
+
+static const struct phy_ops rochchip_p3phy_ops = {
+	.init = rochchip_p3phy_init,
+	.exit = rochchip_p3phy_exit,
+	.set_mode = rockchip_p3phy_set_mode,
+	.owner = THIS_MODULE,
+};
+
+static int rockchip_p3phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct rockchip_p3phy_priv *priv;
+	struct device_node *np = dev->of_node;
+	struct resource *res;
+	int ret;
+	u32 val, reg;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(priv->mmio)) {
+		ret = PTR_ERR(priv->mmio);
+		return ret;
+	}
+
+	priv->ops = of_device_get_match_data(&pdev->dev);
+	if (!priv->ops) {
+		dev_err(&pdev->dev, "no of match data provided\n");
+		return -EINVAL;
+	}
+
+	priv->phy_grf = syscon_regmap_lookup_by_phandle(np, "rockchip,phy-grf");
+	if (IS_ERR(priv->phy_grf)) {
+		dev_err(dev, "failed to find rockchip,phy_grf regmap\n");
+		return PTR_ERR(priv->phy_grf);
+	}
+
+	priv->pipe_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
+							 "rockchip,pipe-grf");
+	if (IS_ERR(priv->pipe_grf))
+		dev_info(dev, "failed to find rockchip,pipe_grf regmap\n");
+
+	ret = device_property_read_u32(dev, "rockchip,pcie30-phymode", &val);
+	if (!ret)
+		priv->pcie30_phymode = val;
+	else
+		priv->pcie30_phymode = PHY_MODE_PCIE_AGGREGATION;
+
+	/* Select correct pcie30_phymode */
+	if (priv->pcie30_phymode > 4)
+		priv->pcie30_phymode = PHY_MODE_PCIE_AGGREGATION;
+
+	regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+		     (0x7<<16) | priv->pcie30_phymode);
+
+	/* Set pcie1ln_sel in PHP_GRF_PCIESEL_CON */
+	if (!IS_ERR(priv->pipe_grf)) {
+		reg = priv->pcie30_phymode & 3;
+		if (reg)
+			regmap_write(priv->pipe_grf, PHP_GRF_PCIESEL_CON,
+				     (reg << 16) | reg);
+	};
+
+	priv->phy = devm_phy_create(dev, NULL, &rochchip_p3phy_ops);
+	if (IS_ERR(priv->phy)) {
+		dev_err(dev, "failed to create combphy\n");
+		return PTR_ERR(priv->phy);
+	}
+
+	priv->p30phy = devm_reset_control_get(dev, "phy");
+	if (IS_ERR(priv->p30phy)) {
+		dev_warn(dev, "no phy reset control specified\n");
+		priv->p30phy = NULL;
+	}
+
+	priv->num_clks = devm_clk_bulk_get_all(dev, &priv->clks);
+	if (priv->num_clks < 1)
+		return -ENODEV;
+
+	dev_set_drvdata(dev, priv);
+	phy_set_drvdata(priv->phy, priv);
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id rockchip_p3phy_of_match[] = {
+	{ .compatible = "rockchip,rk3568-pcie3-phy", .data = &rk3568_ops },
+	{ .compatible = "rockchip,rk3588-pcie3-phy", .data = &rk3588_ops },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, rockchip_p3phy_of_match);
+
+static struct platform_driver rockchip_p3phy_driver = {
+	.probe	= rockchip_p3phy_probe,
+	.driver = {
+		.name = "rockchip-snps-pcie3-phy",
+		.of_match_table = rockchip_p3phy_of_match,
+	},
+};
+module_platform_driver(rockchip_p3phy_driver);
+MODULE_DESCRIPTION("Rockchip Synopsys PCIe 3.0 PHY driver");
+MODULE_LICENSE("GPL");
diff --git a/include/dt-bindings/phy/phy-snps-pcie3.h b/include/dt-bindings/phy/phy-snps-pcie3.h
new file mode 100644
index 000000000000..5006947f2285
--- /dev/null
+++ b/include/dt-bindings/phy/phy-snps-pcie3.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#ifndef _DT_BINDINGS_PHY_SNPS_PCIE3
+#define _DT_BINDINGS_PHY_SNPS_PCIE3
+
+/*
+ * pcie30_phy_mode[2:0]
+ * bit2: aggregation
+ * bit1: bifurcation for port 1
+ * bit0: bifurcation for port 0
+ */
+#define PHY_MODE_PCIE_AGGREGATION 4	/* PCIe3x4 */
+#define PHY_MODE_PCIE_NANBNB	0	/* P1:PCIe3x2  +  P0:PCIe3x2 */
+#define PHY_MODE_PCIE_NANBBI	1	/* P1:PCIe3x2  +  P0:PCIe3x1*2 */
+#define PHY_MODE_PCIE_NABINB	2	/* P1:PCIe3x1*2 + P0:PCIe3x2 */
+#define PHY_MODE_PCIE_NABIBI	3	/* P1:PCIe3x1*2 + P0:PCIe3x1*2 */
+
+#endif /* _DT_BINDINGS_PHY_SNPS_PCIE3 */
diff --git a/include/linux/phy/pcie.h b/include/linux/phy/pcie.h
new file mode 100644
index 000000000000..93c997f520fe
--- /dev/null
+++ b/include/linux/phy/pcie.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+#ifndef __PHY_PCIE_H
+#define __PHY_PCIE_H
+
+#define PHY_MODE_PCIE_RC 20
+#define PHY_MODE_PCIE_EP 21
+#define PHY_MODE_PCIE_BIFURCATION 22
+
+#endif
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
It use a dedicated pcie-phy. Add support for this.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
driver was taken from linux 5.10 based on in
https://github.com/JeffyCN/mirrors
which now has disappeared
---
 drivers/phy/rockchip/Kconfig                  |   9 +
 drivers/phy/rockchip/Makefile                 |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
 include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
 include/linux/phy/pcie.h                      |  12 +
 5 files changed, 321 insertions(+)
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
 create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
 create mode 100644 include/linux/phy/pcie.h

diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index 9022e395c056..94360fc96a6f 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -83,6 +83,15 @@ config PHY_ROCKCHIP_PCIE
 	help
 	  Enable this to support the Rockchip PCIe PHY.
 
+config PHY_ROCKCHIP_SNPS_PCIE3
+	tristate "Rockchip Snps PCIe3 PHY Driver"
+	depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
+	depends on HAS_IOMEM
+	select GENERIC_PHY
+	select MFD_SYSCON
+	help
+	  Enable this to support the Rockchip snps PCIe3 PHY.
+
 config PHY_ROCKCHIP_TYPEC
 	tristate "Rockchip TYPEC PHY Driver"
 	depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index a5041efb5b8f..7eab129230d1 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)	+= phy-rockchip-inno-hdmi.o
 obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)	+= phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY)	+= phy-rockchip-naneng-combphy.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE)		+= phy-rockchip-pcie.o
+obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)	+= phy-rockchip-snps-pcie3.o
 obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)	+= phy-rockchip-typec.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB)		+= phy-rockchip-usb.o
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
new file mode 100644
index 000000000000..992b9709a97a
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip PCIE3.0 phy driver
+ *
+ * Copyright (C) 2020 Rockchip Electronics Co., Ltd.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/phy/pcie.h>
+#include <linux/phy/phy.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy-snps-pcie3.h>
+
+/* Register for RK3568 */
+#define GRF_PCIE30PHY_CON1 0x4
+#define GRF_PCIE30PHY_CON6 0x18
+#define GRF_PCIE30PHY_CON9 0x24
+#define GRF_PCIE30PHY_STATUS0 0x80
+#define SRAM_INIT_DONE(reg) (reg & BIT(14))
+
+/* Register for RK3588 */
+#define PHP_GRF_PCIESEL_CON 0x100
+#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
+#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
+#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
+#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
+
+struct rockchip_p3phy_ops;
+
+struct rockchip_p3phy_priv {
+	const struct rockchip_p3phy_ops *ops;
+	void __iomem *mmio;
+	/* mode: RC, EP */
+	int mode;
+	/* pcie30_phymode: Aggregation, Bifurcation */
+	int pcie30_phymode;
+	struct regmap *phy_grf;
+	struct regmap *pipe_grf;
+	struct reset_control *p30phy;
+	struct phy *phy;
+	struct clk_bulk_data *clks;
+	int num_clks;
+	bool is_bifurcation;
+};
+
+struct rockchip_p3phy_ops {
+	int (*phy_init)(struct rockchip_p3phy_priv *priv);
+};
+
+static int rockchip_p3phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+
+	/* Actually We don't care EP/RC mode, but just record it */
+	switch (submode) {
+	case PHY_MODE_PCIE_RC:
+		priv->mode = PHY_MODE_PCIE_RC;
+		break;
+	case PHY_MODE_PCIE_EP:
+		priv->mode = PHY_MODE_PCIE_EP;
+		break;
+	case PHY_MODE_PCIE_BIFURCATION:
+		priv->is_bifurcation = true;
+		break;
+	default:
+		pr_info("%s, invalid mode\n", __func__);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int rockchip_p3phy_rk3568_init(struct rockchip_p3phy_priv *priv)
+{
+	int ret = 0;
+	u32 reg;
+
+	/* Deassert PCIe PMA output clamp mode */
+	regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
+		     (0x1 << 15) | (0x1 << 31));
+	/* Set bifurcation if needed, and it doesn't care RC/EP */
+	if (priv->is_bifurcation) {
+		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON6,
+			     0x1 | (0xf << 16));
+		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON1,
+			     (0x1 << 15) | (0x1 << 31));
+	}
+
+	reset_control_deassert(priv->p30phy);
+
+	ret = regmap_read_poll_timeout(priv->phy_grf,
+				       GRF_PCIE30PHY_STATUS0,
+				       reg, SRAM_INIT_DONE(reg),
+				       0, 500);
+	if (ret)
+		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
+		       __func__, reg);
+	return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3568_ops = {
+	.phy_init = rockchip_p3phy_rk3568_init,
+};
+
+static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
+{
+	int ret = 0;
+	u32 reg;
+
+	/* Deassert PCIe PMA output clamp mode */
+	regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+		     (0x1 << 8) | (0x1 << 24));
+
+	reset_control_deassert(priv->p30phy);
+
+	ret = regmap_read_poll_timeout(priv->phy_grf,
+				       RK3588_PCIE3PHY_GRF_PHY0_STATUS1,
+				       reg, RK3588_SRAM_INIT_DONE(reg),
+				       0, 500);
+	ret |= regmap_read_poll_timeout(priv->phy_grf,
+					RK3588_PCIE3PHY_GRF_PHY1_STATUS1,
+					reg, RK3588_SRAM_INIT_DONE(reg),
+					0, 500);
+	if (ret)
+		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
+		       __func__, reg);
+	return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3588_ops = {
+	.phy_init = rockchip_p3phy_rk3588_init,
+};
+
+static int rochchip_p3phy_init(struct phy *phy)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+	int ret;
+
+	ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
+	if (ret) {
+		pr_err("failed to enable PCIe bulk clks %d\n", ret);
+		return ret;
+	}
+
+	reset_control_assert(priv->p30phy);
+	udelay(1);
+
+	if (priv->ops->phy_init) {
+		ret = priv->ops->phy_init(priv);
+		if (ret)
+			clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+	};
+
+	return ret;
+}
+
+static int rochchip_p3phy_exit(struct phy *phy)
+{
+	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
+
+	clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+	reset_control_assert(priv->p30phy);
+	return 0;
+}
+
+static const struct phy_ops rochchip_p3phy_ops = {
+	.init = rochchip_p3phy_init,
+	.exit = rochchip_p3phy_exit,
+	.set_mode = rockchip_p3phy_set_mode,
+	.owner = THIS_MODULE,
+};
+
+static int rockchip_p3phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct rockchip_p3phy_priv *priv;
+	struct device_node *np = dev->of_node;
+	struct resource *res;
+	int ret;
+	u32 val, reg;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(priv->mmio)) {
+		ret = PTR_ERR(priv->mmio);
+		return ret;
+	}
+
+	priv->ops = of_device_get_match_data(&pdev->dev);
+	if (!priv->ops) {
+		dev_err(&pdev->dev, "no of match data provided\n");
+		return -EINVAL;
+	}
+
+	priv->phy_grf = syscon_regmap_lookup_by_phandle(np, "rockchip,phy-grf");
+	if (IS_ERR(priv->phy_grf)) {
+		dev_err(dev, "failed to find rockchip,phy_grf regmap\n");
+		return PTR_ERR(priv->phy_grf);
+	}
+
+	priv->pipe_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
+							 "rockchip,pipe-grf");
+	if (IS_ERR(priv->pipe_grf))
+		dev_info(dev, "failed to find rockchip,pipe_grf regmap\n");
+
+	ret = device_property_read_u32(dev, "rockchip,pcie30-phymode", &val);
+	if (!ret)
+		priv->pcie30_phymode = val;
+	else
+		priv->pcie30_phymode = PHY_MODE_PCIE_AGGREGATION;
+
+	/* Select correct pcie30_phymode */
+	if (priv->pcie30_phymode > 4)
+		priv->pcie30_phymode = PHY_MODE_PCIE_AGGREGATION;
+
+	regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+		     (0x7<<16) | priv->pcie30_phymode);
+
+	/* Set pcie1ln_sel in PHP_GRF_PCIESEL_CON */
+	if (!IS_ERR(priv->pipe_grf)) {
+		reg = priv->pcie30_phymode & 3;
+		if (reg)
+			regmap_write(priv->pipe_grf, PHP_GRF_PCIESEL_CON,
+				     (reg << 16) | reg);
+	};
+
+	priv->phy = devm_phy_create(dev, NULL, &rochchip_p3phy_ops);
+	if (IS_ERR(priv->phy)) {
+		dev_err(dev, "failed to create combphy\n");
+		return PTR_ERR(priv->phy);
+	}
+
+	priv->p30phy = devm_reset_control_get(dev, "phy");
+	if (IS_ERR(priv->p30phy)) {
+		dev_warn(dev, "no phy reset control specified\n");
+		priv->p30phy = NULL;
+	}
+
+	priv->num_clks = devm_clk_bulk_get_all(dev, &priv->clks);
+	if (priv->num_clks < 1)
+		return -ENODEV;
+
+	dev_set_drvdata(dev, priv);
+	phy_set_drvdata(priv->phy, priv);
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id rockchip_p3phy_of_match[] = {
+	{ .compatible = "rockchip,rk3568-pcie3-phy", .data = &rk3568_ops },
+	{ .compatible = "rockchip,rk3588-pcie3-phy", .data = &rk3588_ops },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, rockchip_p3phy_of_match);
+
+static struct platform_driver rockchip_p3phy_driver = {
+	.probe	= rockchip_p3phy_probe,
+	.driver = {
+		.name = "rockchip-snps-pcie3-phy",
+		.of_match_table = rockchip_p3phy_of_match,
+	},
+};
+module_platform_driver(rockchip_p3phy_driver);
+MODULE_DESCRIPTION("Rockchip Synopsys PCIe 3.0 PHY driver");
+MODULE_LICENSE("GPL");
diff --git a/include/dt-bindings/phy/phy-snps-pcie3.h b/include/dt-bindings/phy/phy-snps-pcie3.h
new file mode 100644
index 000000000000..5006947f2285
--- /dev/null
+++ b/include/dt-bindings/phy/phy-snps-pcie3.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#ifndef _DT_BINDINGS_PHY_SNPS_PCIE3
+#define _DT_BINDINGS_PHY_SNPS_PCIE3
+
+/*
+ * pcie30_phy_mode[2:0]
+ * bit2: aggregation
+ * bit1: bifurcation for port 1
+ * bit0: bifurcation for port 0
+ */
+#define PHY_MODE_PCIE_AGGREGATION 4	/* PCIe3x4 */
+#define PHY_MODE_PCIE_NANBNB	0	/* P1:PCIe3x2  +  P0:PCIe3x2 */
+#define PHY_MODE_PCIE_NANBBI	1	/* P1:PCIe3x2  +  P0:PCIe3x1*2 */
+#define PHY_MODE_PCIE_NABINB	2	/* P1:PCIe3x1*2 + P0:PCIe3x2 */
+#define PHY_MODE_PCIE_NABIBI	3	/* P1:PCIe3x1*2 + P0:PCIe3x1*2 */
+
+#endif /* _DT_BINDINGS_PHY_SNPS_PCIE3 */
diff --git a/include/linux/phy/pcie.h b/include/linux/phy/pcie.h
new file mode 100644
index 000000000000..93c997f520fe
--- /dev/null
+++ b/include/linux/phy/pcie.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+#ifndef __PHY_PCIE_H
+#define __PHY_PCIE_H
+
+#define PHY_MODE_PCIE_RC 20
+#define PHY_MODE_PCIE_EP 21
+#define PHY_MODE_PCIE_BIFURCATION 22
+
+#endif
-- 
2.25.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Vinod Koul]

On 16-04-22, 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
>  drivers/phy/rockchip/Kconfig                  |   9 +
>  drivers/phy/rockchip/Makefile                 |   1 +
>  .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
>  include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
>  include/linux/phy/pcie.h                      |  12 +
>  5 files changed, 321 insertions(+)
>  create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
>  create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
>  create mode 100644 include/linux/phy/pcie.h
> 
> diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
> index 9022e395c056..94360fc96a6f 100644
> --- a/drivers/phy/rockchip/Kconfig
> +++ b/drivers/phy/rockchip/Kconfig
> @@ -83,6 +83,15 @@ config PHY_ROCKCHIP_PCIE
>  	help
>  	  Enable this to support the Rockchip PCIe PHY.
>  
> +config PHY_ROCKCHIP_SNPS_PCIE3
> +	tristate "Rockchip Snps PCIe3 PHY Driver"
> +	depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
> +	depends on HAS_IOMEM
> +	select GENERIC_PHY
> +	select MFD_SYSCON
> +	help
> +	  Enable this to support the Rockchip snps PCIe3 PHY.
> +
>  config PHY_ROCKCHIP_TYPEC
>  	tristate "Rockchip TYPEC PHY Driver"
>  	depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
> diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
> index a5041efb5b8f..7eab129230d1 100644
> --- a/drivers/phy/rockchip/Makefile
> +++ b/drivers/phy/rockchip/Makefile
> @@ -8,5 +8,6 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)	+= phy-rockchip-inno-hdmi.o
>  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)	+= phy-rockchip-inno-usb2.o
>  obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY)	+= phy-rockchip-naneng-combphy.o
>  obj-$(CONFIG_PHY_ROCKCHIP_PCIE)		+= phy-rockchip-pcie.o
> +obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)	+= phy-rockchip-snps-pcie3.o
>  obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)	+= phy-rockchip-typec.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB)		+= phy-rockchip-usb.o
> diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> new file mode 100644
> index 000000000000..992b9709a97a
> --- /dev/null
> +++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip PCIE3.0 phy driver
> + *
> + * Copyright (C) 2020 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/phy/pcie.h>
> +#include <linux/phy/phy.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-snps-pcie3.h>
> +
> +/* Register for RK3568 */
> +#define GRF_PCIE30PHY_CON1 0x4
> +#define GRF_PCIE30PHY_CON6 0x18
> +#define GRF_PCIE30PHY_CON9 0x24
> +#define GRF_PCIE30PHY_STATUS0 0x80
> +#define SRAM_INIT_DONE(reg) (reg & BIT(14))
> +
> +/* Register for RK3588 */
> +#define PHP_GRF_PCIESEL_CON 0x100
> +#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
> +#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
> +#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
> +#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
> +
> +struct rockchip_p3phy_ops;
> +
> +struct rockchip_p3phy_priv {
> +	const struct rockchip_p3phy_ops *ops;
> +	void __iomem *mmio;
> +	/* mode: RC, EP */
> +	int mode;
> +	/* pcie30_phymode: Aggregation, Bifurcation */
> +	int pcie30_phymode;
> +	struct regmap *phy_grf;
> +	struct regmap *pipe_grf;
> +	struct reset_control *p30phy;
> +	struct phy *phy;
> +	struct clk_bulk_data *clks;
> +	int num_clks;
> +	bool is_bifurcation;
> +};
> +
> +struct rockchip_p3phy_ops {
> +	int (*phy_init)(struct rockchip_p3phy_priv *priv);
> +};
> +
> +static int rockchip_p3phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> +	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
> +
> +	/* Actually We don't care EP/RC mode, but just record it */
> +	switch (submode) {
> +	case PHY_MODE_PCIE_RC:
> +		priv->mode = PHY_MODE_PCIE_RC;
> +		break;
> +	case PHY_MODE_PCIE_EP:
> +		priv->mode = PHY_MODE_PCIE_EP;
> +		break;
> +	case PHY_MODE_PCIE_BIFURCATION:
> +		priv->is_bifurcation = true;
> +		break;
> +	default:
> +		pr_info("%s, invalid mode\n", __func__);

this should be err log, also make it dev_err pls

> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int rockchip_p3phy_rk3568_init(struct rockchip_p3phy_priv *priv)
> +{
> +	int ret = 0;

initialization seems superfluous

> +	u32 reg;
> +
> +	/* Deassert PCIe PMA output clamp mode */
> +	regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
> +		     (0x1 << 15) | (0x1 << 31));

magic numbers.. sounds like BIT(15) and BIT(31)


> +	/* Set bifurcation if needed, and it doesn't care RC/EP */
> +	if (priv->is_bifurcation) {
> +		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON6,
> +			     0x1 | (0xf << 16));
> +		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON1,
> +			     (0x1 << 15) | (0x1 << 31));
> +	}
> +
> +	reset_control_deassert(priv->p30phy);
> +
> +	ret = regmap_read_poll_timeout(priv->phy_grf,
> +				       GRF_PCIE30PHY_STATUS0,
> +				       reg, SRAM_INIT_DONE(reg),
> +				       0, 500);
> +	if (ret)
> +		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
> +		       __func__, reg);

dev_err() pls

> +	return ret;
> +}
> +
> +static const struct rockchip_p3phy_ops rk3568_ops = {
> +	.phy_init = rockchip_p3phy_rk3568_init,
> +};
> +
> +static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
> +{
> +	int ret = 0;

superfluous init again
-- 
~Vinod

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Vinod Koul]

On 16-04-22, 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
>  drivers/phy/rockchip/Kconfig                  |   9 +
>  drivers/phy/rockchip/Makefile                 |   1 +
>  .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
>  include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
>  include/linux/phy/pcie.h                      |  12 +
>  5 files changed, 321 insertions(+)
>  create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
>  create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
>  create mode 100644 include/linux/phy/pcie.h
> 
> diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
> index 9022e395c056..94360fc96a6f 100644
> --- a/drivers/phy/rockchip/Kconfig
> +++ b/drivers/phy/rockchip/Kconfig
> @@ -83,6 +83,15 @@ config PHY_ROCKCHIP_PCIE
>  	help
>  	  Enable this to support the Rockchip PCIe PHY.
>  
> +config PHY_ROCKCHIP_SNPS_PCIE3
> +	tristate "Rockchip Snps PCIe3 PHY Driver"
> +	depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
> +	depends on HAS_IOMEM
> +	select GENERIC_PHY
> +	select MFD_SYSCON
> +	help
> +	  Enable this to support the Rockchip snps PCIe3 PHY.
> +
>  config PHY_ROCKCHIP_TYPEC
>  	tristate "Rockchip TYPEC PHY Driver"
>  	depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
> diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
> index a5041efb5b8f..7eab129230d1 100644
> --- a/drivers/phy/rockchip/Makefile
> +++ b/drivers/phy/rockchip/Makefile
> @@ -8,5 +8,6 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)	+= phy-rockchip-inno-hdmi.o
>  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)	+= phy-rockchip-inno-usb2.o
>  obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY)	+= phy-rockchip-naneng-combphy.o
>  obj-$(CONFIG_PHY_ROCKCHIP_PCIE)		+= phy-rockchip-pcie.o
> +obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)	+= phy-rockchip-snps-pcie3.o
>  obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)	+= phy-rockchip-typec.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB)		+= phy-rockchip-usb.o
> diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> new file mode 100644
> index 000000000000..992b9709a97a
> --- /dev/null
> +++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip PCIE3.0 phy driver
> + *
> + * Copyright (C) 2020 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/phy/pcie.h>
> +#include <linux/phy/phy.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-snps-pcie3.h>
> +
> +/* Register for RK3568 */
> +#define GRF_PCIE30PHY_CON1 0x4
> +#define GRF_PCIE30PHY_CON6 0x18
> +#define GRF_PCIE30PHY_CON9 0x24
> +#define GRF_PCIE30PHY_STATUS0 0x80
> +#define SRAM_INIT_DONE(reg) (reg & BIT(14))
> +
> +/* Register for RK3588 */
> +#define PHP_GRF_PCIESEL_CON 0x100
> +#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
> +#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
> +#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
> +#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
> +
> +struct rockchip_p3phy_ops;
> +
> +struct rockchip_p3phy_priv {
> +	const struct rockchip_p3phy_ops *ops;
> +	void __iomem *mmio;
> +	/* mode: RC, EP */
> +	int mode;
> +	/* pcie30_phymode: Aggregation, Bifurcation */
> +	int pcie30_phymode;
> +	struct regmap *phy_grf;
> +	struct regmap *pipe_grf;
> +	struct reset_control *p30phy;
> +	struct phy *phy;
> +	struct clk_bulk_data *clks;
> +	int num_clks;
> +	bool is_bifurcation;
> +};
> +
> +struct rockchip_p3phy_ops {
> +	int (*phy_init)(struct rockchip_p3phy_priv *priv);
> +};
> +
> +static int rockchip_p3phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> +	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
> +
> +	/* Actually We don't care EP/RC mode, but just record it */
> +	switch (submode) {
> +	case PHY_MODE_PCIE_RC:
> +		priv->mode = PHY_MODE_PCIE_RC;
> +		break;
> +	case PHY_MODE_PCIE_EP:
> +		priv->mode = PHY_MODE_PCIE_EP;
> +		break;
> +	case PHY_MODE_PCIE_BIFURCATION:
> +		priv->is_bifurcation = true;
> +		break;
> +	default:
> +		pr_info("%s, invalid mode\n", __func__);

this should be err log, also make it dev_err pls

> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int rockchip_p3phy_rk3568_init(struct rockchip_p3phy_priv *priv)
> +{
> +	int ret = 0;

initialization seems superfluous

> +	u32 reg;
> +
> +	/* Deassert PCIe PMA output clamp mode */
> +	regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
> +		     (0x1 << 15) | (0x1 << 31));

magic numbers.. sounds like BIT(15) and BIT(31)


> +	/* Set bifurcation if needed, and it doesn't care RC/EP */
> +	if (priv->is_bifurcation) {
> +		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON6,
> +			     0x1 | (0xf << 16));
> +		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON1,
> +			     (0x1 << 15) | (0x1 << 31));
> +	}
> +
> +	reset_control_deassert(priv->p30phy);
> +
> +	ret = regmap_read_poll_timeout(priv->phy_grf,
> +				       GRF_PCIE30PHY_STATUS0,
> +				       reg, SRAM_INIT_DONE(reg),
> +				       0, 500);
> +	if (ret)
> +		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
> +		       __func__, reg);

dev_err() pls

> +	return ret;
> +}
> +
> +static const struct rockchip_p3phy_ops rk3568_ops = {
> +	.phy_init = rockchip_p3phy_rk3568_init,
> +};
> +
> +static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
> +{
> +	int ret = 0;

superfluous init again
-- 
~Vinod

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Vinod Koul]

On 16-04-22, 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
>  drivers/phy/rockchip/Kconfig                  |   9 +
>  drivers/phy/rockchip/Makefile                 |   1 +
>  .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
>  include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
>  include/linux/phy/pcie.h                      |  12 +
>  5 files changed, 321 insertions(+)
>  create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
>  create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
>  create mode 100644 include/linux/phy/pcie.h
> 
> diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
> index 9022e395c056..94360fc96a6f 100644
> --- a/drivers/phy/rockchip/Kconfig
> +++ b/drivers/phy/rockchip/Kconfig
> @@ -83,6 +83,15 @@ config PHY_ROCKCHIP_PCIE
>  	help
>  	  Enable this to support the Rockchip PCIe PHY.
>  
> +config PHY_ROCKCHIP_SNPS_PCIE3
> +	tristate "Rockchip Snps PCIe3 PHY Driver"
> +	depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
> +	depends on HAS_IOMEM
> +	select GENERIC_PHY
> +	select MFD_SYSCON
> +	help
> +	  Enable this to support the Rockchip snps PCIe3 PHY.
> +
>  config PHY_ROCKCHIP_TYPEC
>  	tristate "Rockchip TYPEC PHY Driver"
>  	depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
> diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
> index a5041efb5b8f..7eab129230d1 100644
> --- a/drivers/phy/rockchip/Makefile
> +++ b/drivers/phy/rockchip/Makefile
> @@ -8,5 +8,6 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)	+= phy-rockchip-inno-hdmi.o
>  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)	+= phy-rockchip-inno-usb2.o
>  obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY)	+= phy-rockchip-naneng-combphy.o
>  obj-$(CONFIG_PHY_ROCKCHIP_PCIE)		+= phy-rockchip-pcie.o
> +obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)	+= phy-rockchip-snps-pcie3.o
>  obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)	+= phy-rockchip-typec.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB)		+= phy-rockchip-usb.o
> diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> new file mode 100644
> index 000000000000..992b9709a97a
> --- /dev/null
> +++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip PCIE3.0 phy driver
> + *
> + * Copyright (C) 2020 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/phy/pcie.h>
> +#include <linux/phy/phy.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-snps-pcie3.h>
> +
> +/* Register for RK3568 */
> +#define GRF_PCIE30PHY_CON1 0x4
> +#define GRF_PCIE30PHY_CON6 0x18
> +#define GRF_PCIE30PHY_CON9 0x24
> +#define GRF_PCIE30PHY_STATUS0 0x80
> +#define SRAM_INIT_DONE(reg) (reg & BIT(14))
> +
> +/* Register for RK3588 */
> +#define PHP_GRF_PCIESEL_CON 0x100
> +#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
> +#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
> +#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
> +#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
> +
> +struct rockchip_p3phy_ops;
> +
> +struct rockchip_p3phy_priv {
> +	const struct rockchip_p3phy_ops *ops;
> +	void __iomem *mmio;
> +	/* mode: RC, EP */
> +	int mode;
> +	/* pcie30_phymode: Aggregation, Bifurcation */
> +	int pcie30_phymode;
> +	struct regmap *phy_grf;
> +	struct regmap *pipe_grf;
> +	struct reset_control *p30phy;
> +	struct phy *phy;
> +	struct clk_bulk_data *clks;
> +	int num_clks;
> +	bool is_bifurcation;
> +};
> +
> +struct rockchip_p3phy_ops {
> +	int (*phy_init)(struct rockchip_p3phy_priv *priv);
> +};
> +
> +static int rockchip_p3phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> +	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
> +
> +	/* Actually We don't care EP/RC mode, but just record it */
> +	switch (submode) {
> +	case PHY_MODE_PCIE_RC:
> +		priv->mode = PHY_MODE_PCIE_RC;
> +		break;
> +	case PHY_MODE_PCIE_EP:
> +		priv->mode = PHY_MODE_PCIE_EP;
> +		break;
> +	case PHY_MODE_PCIE_BIFURCATION:
> +		priv->is_bifurcation = true;
> +		break;
> +	default:
> +		pr_info("%s, invalid mode\n", __func__);

this should be err log, also make it dev_err pls

> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int rockchip_p3phy_rk3568_init(struct rockchip_p3phy_priv *priv)
> +{
> +	int ret = 0;

initialization seems superfluous

> +	u32 reg;
> +
> +	/* Deassert PCIe PMA output clamp mode */
> +	regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
> +		     (0x1 << 15) | (0x1 << 31));

magic numbers.. sounds like BIT(15) and BIT(31)


> +	/* Set bifurcation if needed, and it doesn't care RC/EP */
> +	if (priv->is_bifurcation) {
> +		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON6,
> +			     0x1 | (0xf << 16));
> +		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON1,
> +			     (0x1 << 15) | (0x1 << 31));
> +	}
> +
> +	reset_control_deassert(priv->p30phy);
> +
> +	ret = regmap_read_poll_timeout(priv->phy_grf,
> +				       GRF_PCIE30PHY_STATUS0,
> +				       reg, SRAM_INIT_DONE(reg),
> +				       0, 500);
> +	if (ret)
> +		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
> +		       __func__, reg);

dev_err() pls

> +	return ret;
> +}
> +
> +static const struct rockchip_p3phy_ops rk3568_ops = {
> +	.phy_init = rockchip_p3phy_rk3568_init,
> +};
> +
> +static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
> +{
> +	int ret = 0;

superfluous init again
-- 
~Vinod

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Vinod Koul]

On 16-04-22, 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
>  drivers/phy/rockchip/Kconfig                  |   9 +
>  drivers/phy/rockchip/Makefile                 |   1 +
>  .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
>  include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++
>  include/linux/phy/pcie.h                      |  12 +
>  5 files changed, 321 insertions(+)
>  create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
>  create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h
>  create mode 100644 include/linux/phy/pcie.h
> 
> diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
> index 9022e395c056..94360fc96a6f 100644
> --- a/drivers/phy/rockchip/Kconfig
> +++ b/drivers/phy/rockchip/Kconfig
> @@ -83,6 +83,15 @@ config PHY_ROCKCHIP_PCIE
>  	help
>  	  Enable this to support the Rockchip PCIe PHY.
>  
> +config PHY_ROCKCHIP_SNPS_PCIE3
> +	tristate "Rockchip Snps PCIe3 PHY Driver"
> +	depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
> +	depends on HAS_IOMEM
> +	select GENERIC_PHY
> +	select MFD_SYSCON
> +	help
> +	  Enable this to support the Rockchip snps PCIe3 PHY.
> +
>  config PHY_ROCKCHIP_TYPEC
>  	tristate "Rockchip TYPEC PHY Driver"
>  	depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
> diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
> index a5041efb5b8f..7eab129230d1 100644
> --- a/drivers/phy/rockchip/Makefile
> +++ b/drivers/phy/rockchip/Makefile
> @@ -8,5 +8,6 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)	+= phy-rockchip-inno-hdmi.o
>  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)	+= phy-rockchip-inno-usb2.o
>  obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY)	+= phy-rockchip-naneng-combphy.o
>  obj-$(CONFIG_PHY_ROCKCHIP_PCIE)		+= phy-rockchip-pcie.o
> +obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)	+= phy-rockchip-snps-pcie3.o
>  obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)	+= phy-rockchip-typec.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB)		+= phy-rockchip-usb.o
> diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> new file mode 100644
> index 000000000000..992b9709a97a
> --- /dev/null
> +++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip PCIE3.0 phy driver
> + *
> + * Copyright (C) 2020 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/phy/pcie.h>
> +#include <linux/phy/phy.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-snps-pcie3.h>
> +
> +/* Register for RK3568 */
> +#define GRF_PCIE30PHY_CON1 0x4
> +#define GRF_PCIE30PHY_CON6 0x18
> +#define GRF_PCIE30PHY_CON9 0x24
> +#define GRF_PCIE30PHY_STATUS0 0x80
> +#define SRAM_INIT_DONE(reg) (reg & BIT(14))
> +
> +/* Register for RK3588 */
> +#define PHP_GRF_PCIESEL_CON 0x100
> +#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
> +#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
> +#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
> +#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
> +
> +struct rockchip_p3phy_ops;
> +
> +struct rockchip_p3phy_priv {
> +	const struct rockchip_p3phy_ops *ops;
> +	void __iomem *mmio;
> +	/* mode: RC, EP */
> +	int mode;
> +	/* pcie30_phymode: Aggregation, Bifurcation */
> +	int pcie30_phymode;
> +	struct regmap *phy_grf;
> +	struct regmap *pipe_grf;
> +	struct reset_control *p30phy;
> +	struct phy *phy;
> +	struct clk_bulk_data *clks;
> +	int num_clks;
> +	bool is_bifurcation;
> +};
> +
> +struct rockchip_p3phy_ops {
> +	int (*phy_init)(struct rockchip_p3phy_priv *priv);
> +};
> +
> +static int rockchip_p3phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> +	struct rockchip_p3phy_priv *priv = phy_get_drvdata(phy);
> +
> +	/* Actually We don't care EP/RC mode, but just record it */
> +	switch (submode) {
> +	case PHY_MODE_PCIE_RC:
> +		priv->mode = PHY_MODE_PCIE_RC;
> +		break;
> +	case PHY_MODE_PCIE_EP:
> +		priv->mode = PHY_MODE_PCIE_EP;
> +		break;
> +	case PHY_MODE_PCIE_BIFURCATION:
> +		priv->is_bifurcation = true;
> +		break;
> +	default:
> +		pr_info("%s, invalid mode\n", __func__);

this should be err log, also make it dev_err pls

> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int rockchip_p3phy_rk3568_init(struct rockchip_p3phy_priv *priv)
> +{
> +	int ret = 0;

initialization seems superfluous

> +	u32 reg;
> +
> +	/* Deassert PCIe PMA output clamp mode */
> +	regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
> +		     (0x1 << 15) | (0x1 << 31));

magic numbers.. sounds like BIT(15) and BIT(31)


> +	/* Set bifurcation if needed, and it doesn't care RC/EP */
> +	if (priv->is_bifurcation) {
> +		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON6,
> +			     0x1 | (0xf << 16));
> +		regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON1,
> +			     (0x1 << 15) | (0x1 << 31));
> +	}
> +
> +	reset_control_deassert(priv->p30phy);
> +
> +	ret = regmap_read_poll_timeout(priv->phy_grf,
> +				       GRF_PCIE30PHY_STATUS0,
> +				       reg, SRAM_INIT_DONE(reg),
> +				       0, 500);
> +	if (ret)
> +		pr_err("%s: lock failed 0x%x, check input refclk and power supply\n",
> +		       __func__, reg);

dev_err() pls

> +	return ret;
> +}
> +
> +static const struct rockchip_p3phy_ops rk3568_ops = {
> +	.phy_init = rockchip_p3phy_rk3568_init,
> +};
> +
> +static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
> +{
> +	int ret = 0;

superfluous init again
-- 
~Vinod

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
>  drivers/phy/rockchip/Kconfig                  |   9 +
>  drivers/phy/rockchip/Makefile                 |   1 +
>  .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
>  include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++

This goes to separate patch or to the bindings one. File naming is also
not correct. Who is the vendor here? "rockchip," or "snps,"?

The values look specific to this Rockchip implementation, so the file
should be also mentioned in the bindings (e.g. in property using it).

Best regards,
Krzysztof

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
>  drivers/phy/rockchip/Kconfig                  |   9 +
>  drivers/phy/rockchip/Makefile                 |   1 +
>  .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
>  include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++

This goes to separate patch or to the bindings one. File naming is also
not correct. Who is the vendor here? "rockchip," or "snps,"?

The values look specific to this Rockchip implementation, so the file
should be also mentioned in the bindings (e.g. in property using it).

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
>  drivers/phy/rockchip/Kconfig                  |   9 +
>  drivers/phy/rockchip/Makefile                 |   1 +
>  .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
>  include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++

This goes to separate patch or to the bindings one. File naming is also
not correct. Who is the vendor here? "rockchip," or "snps,"?

The values look specific to this Rockchip implementation, so the file
should be also mentioned in the bindings (e.g. in property using it).

Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
>  drivers/phy/rockchip/Kconfig                  |   9 +
>  drivers/phy/rockchip/Makefile                 |   1 +
>  .../phy/rockchip/phy-rockchip-snps-pcie3.c    | 278 ++++++++++++++++++
>  include/dt-bindings/phy/phy-snps-pcie3.h      |  21 ++

This goes to separate patch or to the bindings one. File naming is also
not correct. Who is the vendor here? "rockchip," or "snps,"?

The values look specific to this Rockchip implementation, so the file
should be also mentioned in the bindings (e.g. in property using it).

Best regards,
Krzysztof

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Philipp Zabel]

On Sa, 2022-04-16 at 15:54 +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
[...]
> +	priv->p30phy = devm_reset_control_get(dev, "phy");

Please use devm_reset_control_get_exclusive() instead. It is
functionally identical but makes clear that this driver requires
exclusive control over the reset line.

regards
Philipp

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Philipp Zabel]

On Sa, 2022-04-16 at 15:54 +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
[...]
> +	priv->p30phy = devm_reset_control_get(dev, "phy");

Please use devm_reset_control_get_exclusive() instead. It is
functionally identical but makes clear that this driver requires
exclusive control over the reset line.

regards
Philipp

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Philipp Zabel]

On Sa, 2022-04-16 at 15:54 +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
[...]
> +	priv->p30phy = devm_reset_control_get(dev, "phy");

Please use devm_reset_control_get_exclusive() instead. It is
functionally identical but makes clear that this driver requires
exclusive control over the reset line.

regards
Philipp

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 3/6] phy: rockchip: Support pcie v3

[Philipp Zabel]

On Sa, 2022-04-16 at 15:54 +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> RK3568 supports PCIe v3 using not Combphy like PCIe v2 on rk3566.
> It use a dedicated pcie-phy. Add support for this.
> 
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> driver was taken from linux 5.10 based on in
> https://github.com/JeffyCN/mirrors
> which now has disappeared
> ---
[...]
> +	priv->p30phy = devm_reset_control_get(dev, "phy");

Please use devm_reset_control_get_exclusive() instead. It is
functionally identical but makes clear that this driver requires
exclusive control over the reset line.

regards
Philipp

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

PCIe Lanes can be split to 2 slots with bifurcation.
Add support for this in existing pcie driver.

Co-developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 drivers/pci/controller/dwc/pcie-dw-rockchip.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 863374604fb1..1b0c2115b32e 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -20,6 +20,7 @@
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
 #include <linux/reset.h>
+#include <linux/phy/pcie.h>
 
 #include "pcie-designware.h"
 
@@ -59,6 +60,7 @@ struct rockchip_pcie {
 	struct regulator                *vpcie3v3;
 	struct irq_domain		*irq_domain;
 	raw_spinlock_t			irq_lock;
+	bool				bifurcation;
 };
 
 static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip,
@@ -273,6 +275,12 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip)
 		return dev_err_probe(dev, PTR_ERR(rockchip->phy),
 				     "missing PHY\n");
 
+	if (rockchip->bifurcation) {
+		ret = phy_set_mode_ext(rockchip->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_BIFURCATION);
+		if (ret)
+			return ret;
+	}
+
 	ret = phy_init(rockchip->phy);
 	if (ret < 0)
 		return ret;
@@ -345,6 +353,9 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (device_property_read_bool(dev, "rockchip,bifurcation"))
+		rockchip->bifurcation = true;
+
 	ret = rockchip_pcie_phy_init(rockchip);
 	if (ret)
 		goto disable_regulator;
-- 
2.25.1

[RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

PCIe Lanes can be split to 2 slots with bifurcation.
Add support for this in existing pcie driver.

Co-developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 drivers/pci/controller/dwc/pcie-dw-rockchip.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 863374604fb1..1b0c2115b32e 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -20,6 +20,7 @@
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
 #include <linux/reset.h>
+#include <linux/phy/pcie.h>
 
 #include "pcie-designware.h"
 
@@ -59,6 +60,7 @@ struct rockchip_pcie {
 	struct regulator                *vpcie3v3;
 	struct irq_domain		*irq_domain;
 	raw_spinlock_t			irq_lock;
+	bool				bifurcation;
 };
 
 static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip,
@@ -273,6 +275,12 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip)
 		return dev_err_probe(dev, PTR_ERR(rockchip->phy),
 				     "missing PHY\n");
 
+	if (rockchip->bifurcation) {
+		ret = phy_set_mode_ext(rockchip->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_BIFURCATION);
+		if (ret)
+			return ret;
+	}
+
 	ret = phy_init(rockchip->phy);
 	if (ret < 0)
 		return ret;
@@ -345,6 +353,9 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (device_property_read_bool(dev, "rockchip,bifurcation"))
+		rockchip->bifurcation = true;
+
 	ret = rockchip_pcie_phy_init(rockchip);
 	if (ret)
 		goto disable_regulator;
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

PCIe Lanes can be split to 2 slots with bifurcation.
Add support for this in existing pcie driver.

Co-developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 drivers/pci/controller/dwc/pcie-dw-rockchip.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 863374604fb1..1b0c2115b32e 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -20,6 +20,7 @@
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
 #include <linux/reset.h>
+#include <linux/phy/pcie.h>
 
 #include "pcie-designware.h"
 
@@ -59,6 +60,7 @@ struct rockchip_pcie {
 	struct regulator                *vpcie3v3;
 	struct irq_domain		*irq_domain;
 	raw_spinlock_t			irq_lock;
+	bool				bifurcation;
 };
 
 static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip,
@@ -273,6 +275,12 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip)
 		return dev_err_probe(dev, PTR_ERR(rockchip->phy),
 				     "missing PHY\n");
 
+	if (rockchip->bifurcation) {
+		ret = phy_set_mode_ext(rockchip->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_BIFURCATION);
+		if (ret)
+			return ret;
+	}
+
 	ret = phy_init(rockchip->phy);
 	if (ret < 0)
 		return ret;
@@ -345,6 +353,9 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (device_property_read_bool(dev, "rockchip,bifurcation"))
+		rockchip->bifurcation = true;
+
 	ret = rockchip_pcie_phy_init(rockchip);
 	if (ret)
 		goto disable_regulator;
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

PCIe Lanes can be split to 2 slots with bifurcation.
Add support for this in existing pcie driver.

Co-developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 drivers/pci/controller/dwc/pcie-dw-rockchip.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 863374604fb1..1b0c2115b32e 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -20,6 +20,7 @@
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
 #include <linux/reset.h>
+#include <linux/phy/pcie.h>
 
 #include "pcie-designware.h"
 
@@ -59,6 +60,7 @@ struct rockchip_pcie {
 	struct regulator                *vpcie3v3;
 	struct irq_domain		*irq_domain;
 	raw_spinlock_t			irq_lock;
+	bool				bifurcation;
 };
 
 static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip,
@@ -273,6 +275,12 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip)
 		return dev_err_probe(dev, PTR_ERR(rockchip->phy),
 				     "missing PHY\n");
 
+	if (rockchip->bifurcation) {
+		ret = phy_set_mode_ext(rockchip->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_BIFURCATION);
+		if (ret)
+			return ret;
+	}
+
 	ret = phy_init(rockchip->phy);
 	if (ret < 0)
 		return ret;
@@ -345,6 +353,9 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (device_property_read_bool(dev, "rockchip,bifurcation"))
+		rockchip->bifurcation = true;
+
 	ret = rockchip_pcie_phy_init(rockchip);
 	if (ret)
 		goto disable_regulator;
-- 
2.25.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Bjorn Helgaas]

On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> PCIe Lanes can be split to 2 slots with bifurcation.
> Add support for this in existing pcie driver.

Please s/pcie/PCIe/ in subject and above to be consistent.  You also
have kind of a random usage in other patches.

Mention the DT property used for this in the commit log.

Is the "rockchip,bifurcation" DT property something that should be
generalized so it's not rockchip-specific?  Other controllers are
likely to support similar functionality.

> Co-developed-by: Peter Geis <pgwipeout@gmail.com>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  drivers/pci/controller/dwc/pcie-dw-rockchip.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 863374604fb1..1b0c2115b32e 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -20,6 +20,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
>  #include <linux/reset.h>
> +#include <linux/phy/pcie.h>
>  
>  #include "pcie-designware.h"
>  
> @@ -59,6 +60,7 @@ struct rockchip_pcie {
>  	struct regulator                *vpcie3v3;
>  	struct irq_domain		*irq_domain;
>  	raw_spinlock_t			irq_lock;
> +	bool				bifurcation;
>  };
>  
>  static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip,
> @@ -273,6 +275,12 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip)
>  		return dev_err_probe(dev, PTR_ERR(rockchip->phy),
>  				     "missing PHY\n");
>  
> +	if (rockchip->bifurcation) {
> +		ret = phy_set_mode_ext(rockchip->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_BIFURCATION);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	ret = phy_init(rockchip->phy);
>  	if (ret < 0)
>  		return ret;
> @@ -345,6 +353,9 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> +	if (device_property_read_bool(dev, "rockchip,bifurcation"))
> +		rockchip->bifurcation = true;
> +
>  	ret = rockchip_pcie_phy_init(rockchip);
>  	if (ret)
>  		goto disable_regulator;
> -- 
> 2.25.1
> 
> 
> -- 
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Bjorn Helgaas]

On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> PCIe Lanes can be split to 2 slots with bifurcation.
> Add support for this in existing pcie driver.

Please s/pcie/PCIe/ in subject and above to be consistent.  You also
have kind of a random usage in other patches.

Mention the DT property used for this in the commit log.

Is the "rockchip,bifurcation" DT property something that should be
generalized so it's not rockchip-specific?  Other controllers are
likely to support similar functionality.

> Co-developed-by: Peter Geis <pgwipeout@gmail.com>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  drivers/pci/controller/dwc/pcie-dw-rockchip.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 863374604fb1..1b0c2115b32e 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -20,6 +20,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
>  #include <linux/reset.h>
> +#include <linux/phy/pcie.h>
>  
>  #include "pcie-designware.h"
>  
> @@ -59,6 +60,7 @@ struct rockchip_pcie {
>  	struct regulator                *vpcie3v3;
>  	struct irq_domain		*irq_domain;
>  	raw_spinlock_t			irq_lock;
> +	bool				bifurcation;
>  };
>  
>  static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip,
> @@ -273,6 +275,12 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip)
>  		return dev_err_probe(dev, PTR_ERR(rockchip->phy),
>  				     "missing PHY\n");
>  
> +	if (rockchip->bifurcation) {
> +		ret = phy_set_mode_ext(rockchip->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_BIFURCATION);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	ret = phy_init(rockchip->phy);
>  	if (ret < 0)
>  		return ret;
> @@ -345,6 +353,9 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> +	if (device_property_read_bool(dev, "rockchip,bifurcation"))
> +		rockchip->bifurcation = true;
> +
>  	ret = rockchip_pcie_phy_init(rockchip);
>  	if (ret)
>  		goto disable_regulator;
> -- 
> 2.25.1
> 
> 
> -- 
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Bjorn Helgaas]

On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> PCIe Lanes can be split to 2 slots with bifurcation.
> Add support for this in existing pcie driver.

Please s/pcie/PCIe/ in subject and above to be consistent.  You also
have kind of a random usage in other patches.

Mention the DT property used for this in the commit log.

Is the "rockchip,bifurcation" DT property something that should be
generalized so it's not rockchip-specific?  Other controllers are
likely to support similar functionality.

> Co-developed-by: Peter Geis <pgwipeout@gmail.com>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  drivers/pci/controller/dwc/pcie-dw-rockchip.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 863374604fb1..1b0c2115b32e 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -20,6 +20,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
>  #include <linux/reset.h>
> +#include <linux/phy/pcie.h>
>  
>  #include "pcie-designware.h"
>  
> @@ -59,6 +60,7 @@ struct rockchip_pcie {
>  	struct regulator                *vpcie3v3;
>  	struct irq_domain		*irq_domain;
>  	raw_spinlock_t			irq_lock;
> +	bool				bifurcation;
>  };
>  
>  static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip,
> @@ -273,6 +275,12 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip)
>  		return dev_err_probe(dev, PTR_ERR(rockchip->phy),
>  				     "missing PHY\n");
>  
> +	if (rockchip->bifurcation) {
> +		ret = phy_set_mode_ext(rockchip->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_BIFURCATION);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	ret = phy_init(rockchip->phy);
>  	if (ret < 0)
>  		return ret;
> @@ -345,6 +353,9 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> +	if (device_property_read_bool(dev, "rockchip,bifurcation"))
> +		rockchip->bifurcation = true;
> +
>  	ret = rockchip_pcie_phy_init(rockchip);
>  	if (ret)
>  		goto disable_regulator;
> -- 
> 2.25.1
> 
> 
> -- 
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Bjorn Helgaas]

On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> PCIe Lanes can be split to 2 slots with bifurcation.
> Add support for this in existing pcie driver.

Please s/pcie/PCIe/ in subject and above to be consistent.  You also
have kind of a random usage in other patches.

Mention the DT property used for this in the commit log.

Is the "rockchip,bifurcation" DT property something that should be
generalized so it's not rockchip-specific?  Other controllers are
likely to support similar functionality.

> Co-developed-by: Peter Geis <pgwipeout@gmail.com>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
>  drivers/pci/controller/dwc/pcie-dw-rockchip.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 863374604fb1..1b0c2115b32e 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -20,6 +20,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
>  #include <linux/reset.h>
> +#include <linux/phy/pcie.h>
>  
>  #include "pcie-designware.h"
>  
> @@ -59,6 +60,7 @@ struct rockchip_pcie {
>  	struct regulator                *vpcie3v3;
>  	struct irq_domain		*irq_domain;
>  	raw_spinlock_t			irq_lock;
> +	bool				bifurcation;
>  };
>  
>  static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip,
> @@ -273,6 +275,12 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip)
>  		return dev_err_probe(dev, PTR_ERR(rockchip->phy),
>  				     "missing PHY\n");
>  
> +	if (rockchip->bifurcation) {
> +		ret = phy_set_mode_ext(rockchip->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_BIFURCATION);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	ret = phy_init(rockchip->phy);
>  	if (ret < 0)
>  		return ret;
> @@ -345,6 +353,9 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> +	if (device_property_read_bool(dev, "rockchip,bifurcation"))
> +		rockchip->bifurcation = true;
> +
>  	ret = rockchip_pcie_phy_init(rockchip);
>  	if (ret)
>  		goto disable_regulator;
> -- 
> 2.25.1
> 
> 
> -- 
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Aw: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

Hi,

> Gesendet: Sonntag, 17. April 2022 um 01:30 Uhr
> Von: "Bjorn Helgaas" <helgaas@kernel.org>

thanks for first review

> On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > From: Frank Wunderlich <frank-w@public-files.de>
> >
> > PCIe Lanes can be split to 2 slots with bifurcation.
> > Add support for this in existing pcie driver.
>
> Please s/pcie/PCIe/ in subject and above to be consistent.  You also
> have kind of a random usage in other patches.

will do

> Mention the DT property used for this in the commit log.

good point

noticed that i forgot to add it to pcie-bindings  (rockchip-dw-pcie.yaml).

> Is the "rockchip,bifurcation" DT property something that should be
> generalized so it's not rockchip-specific?  Other controllers are
> likely to support similar functionality.

I do not know if other controllers support similar functionality, but i ack a property without vendor prefix is better. Should i use "bifurcation" as name or do you think about a different name which is more generic?

regards Frank

Aw: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

Hi,

> Gesendet: Sonntag, 17. April 2022 um 01:30 Uhr
> Von: "Bjorn Helgaas" <helgaas@kernel.org>

thanks for first review

> On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > From: Frank Wunderlich <frank-w@public-files.de>
> >
> > PCIe Lanes can be split to 2 slots with bifurcation.
> > Add support for this in existing pcie driver.
>
> Please s/pcie/PCIe/ in subject and above to be consistent.  You also
> have kind of a random usage in other patches.

will do

> Mention the DT property used for this in the commit log.

good point

noticed that i forgot to add it to pcie-bindings  (rockchip-dw-pcie.yaml).

> Is the "rockchip,bifurcation" DT property something that should be
> generalized so it's not rockchip-specific?  Other controllers are
> likely to support similar functionality.

I do not know if other controllers support similar functionality, but i ack a property without vendor prefix is better. Should i use "bifurcation" as name or do you think about a different name which is more generic?

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

Hi,

> Gesendet: Sonntag, 17. April 2022 um 01:30 Uhr
> Von: "Bjorn Helgaas" <helgaas@kernel.org>

thanks for first review

> On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > From: Frank Wunderlich <frank-w@public-files.de>
> >
> > PCIe Lanes can be split to 2 slots with bifurcation.
> > Add support for this in existing pcie driver.
>
> Please s/pcie/PCIe/ in subject and above to be consistent.  You also
> have kind of a random usage in other patches.

will do

> Mention the DT property used for this in the commit log.

good point

noticed that i forgot to add it to pcie-bindings  (rockchip-dw-pcie.yaml).

> Is the "rockchip,bifurcation" DT property something that should be
> generalized so it's not rockchip-specific?  Other controllers are
> likely to support similar functionality.

I do not know if other controllers support similar functionality, but i ack a property without vendor prefix is better. Should i use "bifurcation" as name or do you think about a different name which is more generic?

regards Frank

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Aw: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

Hi,

> Gesendet: Sonntag, 17. April 2022 um 01:30 Uhr
> Von: "Bjorn Helgaas" <helgaas@kernel.org>

thanks for first review

> On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > From: Frank Wunderlich <frank-w@public-files.de>
> >
> > PCIe Lanes can be split to 2 slots with bifurcation.
> > Add support for this in existing pcie driver.
>
> Please s/pcie/PCIe/ in subject and above to be consistent.  You also
> have kind of a random usage in other patches.

will do

> Mention the DT property used for this in the commit log.

good point

noticed that i forgot to add it to pcie-bindings  (rockchip-dw-pcie.yaml).

> Is the "rockchip,bifurcation" DT property something that should be
> generalized so it's not rockchip-specific?  Other controllers are
> likely to support similar functionality.

I do not know if other controllers support similar functionality, but i ack a property without vendor prefix is better. Should i use "bifurcation" as name or do you think about a different name which is more generic?

regards Frank

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Bjorn Helgaas]

On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > From: Frank Wunderlich <frank-w@public-files.de>
> > >
> > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > Add support for this in existing pcie driver.

> > Is the "rockchip,bifurcation" DT property something that should be
> > generalized so it's not rockchip-specific?  Other controllers are
> > likely to support similar functionality.
> 
> I do not know if other controllers support similar functionality,
> but i ack a property without vendor prefix is better. Should i use
> "bifurcation" as name or do you think about a different name which
> is more generic?

Really a question for Rob about what name would be good and where it
should go.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Bjorn Helgaas]

On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > From: Frank Wunderlich <frank-w@public-files.de>
> > >
> > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > Add support for this in existing pcie driver.

> > Is the "rockchip,bifurcation" DT property something that should be
> > generalized so it's not rockchip-specific?  Other controllers are
> > likely to support similar functionality.
> 
> I do not know if other controllers support similar functionality,
> but i ack a property without vendor prefix is better. Should i use
> "bifurcation" as name or do you think about a different name which
> is more generic?

Really a question for Rob about what name would be good and where it
should go.

Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Bjorn Helgaas]

On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > From: Frank Wunderlich <frank-w@public-files.de>
> > >
> > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > Add support for this in existing pcie driver.

> > Is the "rockchip,bifurcation" DT property something that should be
> > generalized so it's not rockchip-specific?  Other controllers are
> > likely to support similar functionality.
> 
> I do not know if other controllers support similar functionality,
> but i ack a property without vendor prefix is better. Should i use
> "bifurcation" as name or do you think about a different name which
> is more generic?

Really a question for Rob about what name would be good and where it
should go.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Bjorn Helgaas]

On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > From: Frank Wunderlich <frank-w@public-files.de>
> > >
> > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > Add support for this in existing pcie driver.

> > Is the "rockchip,bifurcation" DT property something that should be
> > generalized so it's not rockchip-specific?  Other controllers are
> > likely to support similar functionality.
> 
> I do not know if other controllers support similar functionality,
> but i ack a property without vendor prefix is better. Should i use
> "bifurcation" as name or do you think about a different name which
> is more generic?

Really a question for Rob about what name would be good and where it
should go.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Peter Geis]

On Mon, Apr 18, 2022 at 11:53 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > > From: Frank Wunderlich <frank-w@public-files.de>
> > > >
> > > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > > Add support for this in existing pcie driver.
>
> > > Is the "rockchip,bifurcation" DT property something that should be
> > > generalized so it's not rockchip-specific?  Other controllers are
> > > likely to support similar functionality.
> >
> > I do not know if other controllers support similar functionality,
> > but i ack a property without vendor prefix is better. Should i use
> > "bifurcation" as name or do you think about a different name which
> > is more generic?
>
> Really a question for Rob about what name would be good and where it
> should go.

It might be good to define this as a lane map.
In the Rockchip implementation it's only 2+0 or 1+1, but that isn't
guaranteed if this is made into a standard definition.
So perhaps:
pcie-bifurcation-map = <0>, <1>;
pcie-bifurcation-map = <1>;
pcie-bifurcation-map = <4>, <5>, <6>, <7>;

Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Peter Geis]

On Mon, Apr 18, 2022 at 11:53 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > > From: Frank Wunderlich <frank-w@public-files.de>
> > > >
> > > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > > Add support for this in existing pcie driver.
>
> > > Is the "rockchip,bifurcation" DT property something that should be
> > > generalized so it's not rockchip-specific?  Other controllers are
> > > likely to support similar functionality.
> >
> > I do not know if other controllers support similar functionality,
> > but i ack a property without vendor prefix is better. Should i use
> > "bifurcation" as name or do you think about a different name which
> > is more generic?
>
> Really a question for Rob about what name would be good and where it
> should go.

It might be good to define this as a lane map.
In the Rockchip implementation it's only 2+0 or 1+1, but that isn't
guaranteed if this is made into a standard definition.
So perhaps:
pcie-bifurcation-map = <0>, <1>;
pcie-bifurcation-map = <1>;
pcie-bifurcation-map = <4>, <5>, <6>, <7>;

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Peter Geis]

On Mon, Apr 18, 2022 at 11:53 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > > From: Frank Wunderlich <frank-w@public-files.de>
> > > >
> > > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > > Add support for this in existing pcie driver.
>
> > > Is the "rockchip,bifurcation" DT property something that should be
> > > generalized so it's not rockchip-specific?  Other controllers are
> > > likely to support similar functionality.
> >
> > I do not know if other controllers support similar functionality,
> > but i ack a property without vendor prefix is better. Should i use
> > "bifurcation" as name or do you think about a different name which
> > is more generic?
>
> Really a question for Rob about what name would be good and where it
> should go.

It might be good to define this as a lane map.
In the Rockchip implementation it's only 2+0 or 1+1, but that isn't
guaranteed if this is made into a standard definition.
So perhaps:
pcie-bifurcation-map = <0>, <1>;
pcie-bifurcation-map = <1>;
pcie-bifurcation-map = <4>, <5>, <6>, <7>;

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Peter Geis]

On Mon, Apr 18, 2022 at 11:53 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > > From: Frank Wunderlich <frank-w@public-files.de>
> > > >
> > > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > > Add support for this in existing pcie driver.
>
> > > Is the "rockchip,bifurcation" DT property something that should be
> > > generalized so it's not rockchip-specific?  Other controllers are
> > > likely to support similar functionality.
> >
> > I do not know if other controllers support similar functionality,
> > but i ack a property without vendor prefix is better. Should i use
> > "bifurcation" as name or do you think about a different name which
> > is more generic?
>
> Really a question for Rob about what name would be good and where it
> should go.

It might be good to define this as a lane map.
In the Rockchip implementation it's only 2+0 or 1+1, but that isn't
guaranteed if this is made into a standard definition.
So perhaps:
pcie-bifurcation-map = <0>, <1>;
pcie-bifurcation-map = <1>;
pcie-bifurcation-map = <4>, <5>, <6>, <7>;

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Aw: Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 18:17 Uhr
> Von: "Peter Geis" <pgwipeout@gmail.com>
> > On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > > > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > > > From: Frank Wunderlich <frank-w@public-files.de>
> > > > >
> > > > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > > > Add support for this in existing pcie driver.
> >
> > > > Is the "rockchip,bifurcation" DT property something that should be
> > > > generalized so it's not rockchip-specific?  Other controllers are
> > > > likely to support similar functionality.
> > >
> > > I do not know if other controllers support similar functionality,
> > > but i ack a property without vendor prefix is better. Should i use
> > > "bifurcation" as name or do you think about a different name which
> > > is more generic?
> >
> > Really a question for Rob about what name would be good and where it
> > should go.
>
> It might be good to define this as a lane map.
> In the Rockchip implementation it's only 2+0 or 1+1, but that isn't
> guaranteed if this is made into a standard definition.
> So perhaps:
> pcie-bifurcation-map = <0>, <1>;
> pcie-bifurcation-map = <1>;
> pcie-bifurcation-map = <4>, <5>, <6>, <7>;

how about a lane-map like this (from controllers point of view):

rockchip with only 2 lanes (like rk3568):

controller 1:
lane-map = <1 0>;

controller 2:
lane-map = <0 1>;

here bifurcation is set if a controller does not aquire all lanes.Afaik rk3568 cannot select specific lanes so i end up with bifurcation = true/false (an aggregation-mode on phy) again. but it makes dts-property more usable for other devices/SoC.

this contains the maximum of lanes and as mask the lanes to take by the current controller. It is scalable to support more pcie-lanes (x2 x4 x8)

example for 2 controllers with PCIe x4 (with 8 lanes available):

lane-map=<0 0 0 0 1 1 1 1>;
lane-map=<1 1 1 1 0 0 0 0>;

of course they can be mixed, if driver supports this.

lane-map=<0 1 0 1 0 1 0 1>;
lane-map=<1 0 1 0 1 0 1 0>;

such lane-map is more flexible

regards Frank

Aw: Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 18:17 Uhr
> Von: "Peter Geis" <pgwipeout@gmail.com>
> > On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > > > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > > > From: Frank Wunderlich <frank-w@public-files.de>
> > > > >
> > > > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > > > Add support for this in existing pcie driver.
> >
> > > > Is the "rockchip,bifurcation" DT property something that should be
> > > > generalized so it's not rockchip-specific?  Other controllers are
> > > > likely to support similar functionality.
> > >
> > > I do not know if other controllers support similar functionality,
> > > but i ack a property without vendor prefix is better. Should i use
> > > "bifurcation" as name or do you think about a different name which
> > > is more generic?
> >
> > Really a question for Rob about what name would be good and where it
> > should go.
>
> It might be good to define this as a lane map.
> In the Rockchip implementation it's only 2+0 or 1+1, but that isn't
> guaranteed if this is made into a standard definition.
> So perhaps:
> pcie-bifurcation-map = <0>, <1>;
> pcie-bifurcation-map = <1>;
> pcie-bifurcation-map = <4>, <5>, <6>, <7>;

how about a lane-map like this (from controllers point of view):

rockchip with only 2 lanes (like rk3568):

controller 1:
lane-map = <1 0>;

controller 2:
lane-map = <0 1>;

here bifurcation is set if a controller does not aquire all lanes.Afaik rk3568 cannot select specific lanes so i end up with bifurcation = true/false (an aggregation-mode on phy) again. but it makes dts-property more usable for other devices/SoC.

this contains the maximum of lanes and as mask the lanes to take by the current controller. It is scalable to support more pcie-lanes (x2 x4 x8)

example for 2 controllers with PCIe x4 (with 8 lanes available):

lane-map=<0 0 0 0 1 1 1 1>;
lane-map=<1 1 1 1 0 0 0 0>;

of course they can be mixed, if driver supports this.

lane-map=<0 1 0 1 0 1 0 1>;
lane-map=<1 0 1 0 1 0 1 0>;

such lane-map is more flexible

regards Frank

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Aw: Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 18:17 Uhr
> Von: "Peter Geis" <pgwipeout@gmail.com>
> > On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > > > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > > > From: Frank Wunderlich <frank-w@public-files.de>
> > > > >
> > > > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > > > Add support for this in existing pcie driver.
> >
> > > > Is the "rockchip,bifurcation" DT property something that should be
> > > > generalized so it's not rockchip-specific?  Other controllers are
> > > > likely to support similar functionality.
> > >
> > > I do not know if other controllers support similar functionality,
> > > but i ack a property without vendor prefix is better. Should i use
> > > "bifurcation" as name or do you think about a different name which
> > > is more generic?
> >
> > Really a question for Rob about what name would be good and where it
> > should go.
>
> It might be good to define this as a lane map.
> In the Rockchip implementation it's only 2+0 or 1+1, but that isn't
> guaranteed if this is made into a standard definition.
> So perhaps:
> pcie-bifurcation-map = <0>, <1>;
> pcie-bifurcation-map = <1>;
> pcie-bifurcation-map = <4>, <5>, <6>, <7>;

how about a lane-map like this (from controllers point of view):

rockchip with only 2 lanes (like rk3568):

controller 1:
lane-map = <1 0>;

controller 2:
lane-map = <0 1>;

here bifurcation is set if a controller does not aquire all lanes.Afaik rk3568 cannot select specific lanes so i end up with bifurcation = true/false (an aggregation-mode on phy) again. but it makes dts-property more usable for other devices/SoC.

this contains the maximum of lanes and as mask the lanes to take by the current controller. It is scalable to support more pcie-lanes (x2 x4 x8)

example for 2 controllers with PCIe x4 (with 8 lanes available):

lane-map=<0 0 0 0 1 1 1 1>;
lane-map=<1 1 1 1 0 0 0 0>;

of course they can be mixed, if driver supports this.

lane-map=<0 1 0 1 0 1 0 1>;
lane-map=<1 0 1 0 1 0 1 0>;

such lane-map is more flexible

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: Re: [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation

[Frank Wunderlich]

> Gesendet: Montag, 18. April 2022 um 18:17 Uhr
> Von: "Peter Geis" <pgwipeout@gmail.com>
> > On Sun, Apr 17, 2022 at 11:08:02AM +0200, Frank Wunderlich wrote:
> > > > On Sat, Apr 16, 2022 at 03:54:56PM +0200, Frank Wunderlich wrote:
> > > > > From: Frank Wunderlich <frank-w@public-files.de>
> > > > >
> > > > > PCIe Lanes can be split to 2 slots with bifurcation.
> > > > > Add support for this in existing pcie driver.
> >
> > > > Is the "rockchip,bifurcation" DT property something that should be
> > > > generalized so it's not rockchip-specific?  Other controllers are
> > > > likely to support similar functionality.
> > >
> > > I do not know if other controllers support similar functionality,
> > > but i ack a property without vendor prefix is better. Should i use
> > > "bifurcation" as name or do you think about a different name which
> > > is more generic?
> >
> > Really a question for Rob about what name would be good and where it
> > should go.
>
> It might be good to define this as a lane map.
> In the Rockchip implementation it's only 2+0 or 1+1, but that isn't
> guaranteed if this is made into a standard definition.
> So perhaps:
> pcie-bifurcation-map = <0>, <1>;
> pcie-bifurcation-map = <1>;
> pcie-bifurcation-map = <4>, <5>, <6>, <7>;

how about a lane-map like this (from controllers point of view):

rockchip with only 2 lanes (like rk3568):

controller 1:
lane-map = <1 0>;

controller 2:
lane-map = <0 1>;

here bifurcation is set if a controller does not aquire all lanes.Afaik rk3568 cannot select specific lanes so i end up with bifurcation = true/false (an aggregation-mode on phy) again. but it makes dts-property more usable for other devices/SoC.

this contains the maximum of lanes and as mask the lanes to take by the current controller. It is scalable to support more pcie-lanes (x2 x4 x8)

example for 2 controllers with PCIe x4 (with 8 lanes available):

lane-map=<0 0 0 0 1 1 1 1>;
lane-map=<1 1 1 1 0 0 0 0>;

of course they can be mixed, if driver supports this.

lane-map=<0 1 0 1 0 1 0 1>;
lane-map=<1 0 1 0 1 0 1 0>;

such lane-map is more flexible

regards Frank

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[RFC/RFT 5/6] arm64: dts: rockchip: rk3568: Add PCIe v3 nodes

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add nodes to rk356x devicetree to support PCIe v3.

Co-Developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi | 122 +++++++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
index 5eafddf62edc..083aeaf1d0f8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -42,6 +42,128 @@ qos_sata0: qos@fe190200 {
 		reg = <0x0 0xfe190200 0x0 0x20>;
 	};
 
+	pcie30_phy_grf: syscon@fdcb8000 {
+		compatible = "rockchip,pcie30-phy-grf", "syscon";
+		reg = <0x0 0xfdcb8000 0x0 0x10000>;
+	};
+
+	pcie30phy: phy@fe8c0000 {
+		compatible = "rockchip,rk3568-pcie3-phy";
+		reg = <0x0 0xfe8c0000 0x0 0x20000>;
+		#phy-cells = <0>;
+		clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
+			 <&cru PCLK_PCIE30PHY>;
+		clock-names = "refclk_m", "refclk_n", "pclk";
+		resets = <&cru SRST_PCIE30PHY>;
+		reset-names = "phy";
+		rockchip,phy-grf = <&pcie30_phy_grf>;
+		status = "disabled";
+	};
+
+	pcie3x1: pcie@fe270000 {
+		compatible = "rockchip,rk3568-pcie";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		bus-range = <0x10 0x1f>;
+		clocks = <&cru ACLK_PCIE30X1_MST>, <&cru ACLK_PCIE30X1_SLV>,
+			 <&cru ACLK_PCIE30X1_DBI>, <&cru PCLK_PCIE30X1>,
+			 <&cru CLK_PCIE30X1_AUX_NDFT>;
+		clock-names = "aclk_mst", "aclk_slv",
+			      "aclk_dbi", "pclk", "aux";
+		device_type = "pci";
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie3x1_intc 0>,
+				<0 0 0 2 &pcie3x1_intc 1>,
+				<0 0 0 3 &pcie3x1_intc 2>,
+				<0 0 0 4 &pcie3x1_intc 3>;
+		linux,pci-domain = <1>;
+		num-ib-windows = <6>;
+		num-ob-windows = <2>;
+		max-link-speed = <3>;
+		msi-map = <0x1000 &gic 0x1000 0x1000>;
+		num-lanes = <1>;
+		phys = <&pcie30phy>;
+		phy-names = "pcie-phy";
+		power-domains = <&power RK3568_PD_PIPE>;
+		reg = <0x3 0xc0400000 0x0 0x00400000>,
+		      <0x0 0xfe270000 0x0 0x00010000>,
+		      <0x3 0x40000000 0x0 0x01000000>;
+		ranges = <0x01000000 0x0 0x01000000 0x3 0x41000000 0x0 0x00100000>,
+			 <0x02000000 0x0 0x02000000 0x3 0x41100000 0x0 0x3ef00000>;
+		reg-names = "dbi", "apb", "config";
+		resets = <&cru SRST_PCIE30X1_POWERUP>;
+		reset-names = "pipe";
+		/* rockchip,bifurcation; lane1 when using 1+1 */
+		status = "disabled";
+
+		pcie3x1_intc: legacy-interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 157 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
+	pcie3x2: pcie@fe280000 {
+		compatible = "rockchip,rk3568-pcie";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		bus-range = <0x20 0x2f>;
+		clocks = <&cru ACLK_PCIE30X2_MST>, <&cru ACLK_PCIE30X2_SLV>,
+			 <&cru ACLK_PCIE30X2_DBI>, <&cru PCLK_PCIE30X2>,
+			 <&cru CLK_PCIE30X2_AUX_NDFT>;
+		clock-names = "aclk_mst", "aclk_slv",
+			      "aclk_dbi", "pclk", "aux";
+		device_type = "pci";
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie3x2_intc 0>,
+				<0 0 0 2 &pcie3x2_intc 1>,
+				<0 0 0 3 &pcie3x2_intc 2>,
+				<0 0 0 4 &pcie3x2_intc 3>;
+		linux,pci-domain = <2>;
+		num-ib-windows = <6>;
+		num-ob-windows = <2>;
+		max-link-speed = <3>;
+		msi-map = <0x2000 &gic 0x2000 0x1000>;
+		num-lanes = <2>;
+		phys = <&pcie30phy>;
+		phy-names = "pcie-phy";
+		power-domains = <&power RK3568_PD_PIPE>;
+		reg = <0x3 0xc0800000 0x0 0x00400000>,
+		      <0x0 0xfe280000 0x0 0x00010000>,
+		      <0x3 0x80000000 0x0 0x01000000>;
+		ranges = <0x01000000 0x0 0x01000000 0x3 0x81000000 0x0 0x00100000>,
+			 <0x02000000 0x0 0x02000000 0x3 0x81100000 0x0 0x3ef00000>;
+		reg-names = "dbi", "apb", "config";
+		resets = <&cru SRST_PCIE30X2_POWERUP>;
+		reset-names = "pipe";
+		/* rockchip,bifurcation; lane0 when using 1+1 */
+		status = "disabled";
+
+		pcie3x2_intc: legacy-interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
 	gmac0: ethernet@fe2a0000 {
 		compatible = "rockchip,rk3568-gmac", "snps,dwmac-4.20a";
 		reg = <0x0 0xfe2a0000 0x0 0x10000>;
-- 
2.25.1

[RFC/RFT 5/6] arm64: dts: rockchip: rk3568: Add PCIe v3 nodes

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add nodes to rk356x devicetree to support PCIe v3.

Co-Developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi | 122 +++++++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
index 5eafddf62edc..083aeaf1d0f8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -42,6 +42,128 @@ qos_sata0: qos@fe190200 {
 		reg = <0x0 0xfe190200 0x0 0x20>;
 	};
 
+	pcie30_phy_grf: syscon@fdcb8000 {
+		compatible = "rockchip,pcie30-phy-grf", "syscon";
+		reg = <0x0 0xfdcb8000 0x0 0x10000>;
+	};
+
+	pcie30phy: phy@fe8c0000 {
+		compatible = "rockchip,rk3568-pcie3-phy";
+		reg = <0x0 0xfe8c0000 0x0 0x20000>;
+		#phy-cells = <0>;
+		clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
+			 <&cru PCLK_PCIE30PHY>;
+		clock-names = "refclk_m", "refclk_n", "pclk";
+		resets = <&cru SRST_PCIE30PHY>;
+		reset-names = "phy";
+		rockchip,phy-grf = <&pcie30_phy_grf>;
+		status = "disabled";
+	};
+
+	pcie3x1: pcie@fe270000 {
+		compatible = "rockchip,rk3568-pcie";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		bus-range = <0x10 0x1f>;
+		clocks = <&cru ACLK_PCIE30X1_MST>, <&cru ACLK_PCIE30X1_SLV>,
+			 <&cru ACLK_PCIE30X1_DBI>, <&cru PCLK_PCIE30X1>,
+			 <&cru CLK_PCIE30X1_AUX_NDFT>;
+		clock-names = "aclk_mst", "aclk_slv",
+			      "aclk_dbi", "pclk", "aux";
+		device_type = "pci";
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie3x1_intc 0>,
+				<0 0 0 2 &pcie3x1_intc 1>,
+				<0 0 0 3 &pcie3x1_intc 2>,
+				<0 0 0 4 &pcie3x1_intc 3>;
+		linux,pci-domain = <1>;
+		num-ib-windows = <6>;
+		num-ob-windows = <2>;
+		max-link-speed = <3>;
+		msi-map = <0x1000 &gic 0x1000 0x1000>;
+		num-lanes = <1>;
+		phys = <&pcie30phy>;
+		phy-names = "pcie-phy";
+		power-domains = <&power RK3568_PD_PIPE>;
+		reg = <0x3 0xc0400000 0x0 0x00400000>,
+		      <0x0 0xfe270000 0x0 0x00010000>,
+		      <0x3 0x40000000 0x0 0x01000000>;
+		ranges = <0x01000000 0x0 0x01000000 0x3 0x41000000 0x0 0x00100000>,
+			 <0x02000000 0x0 0x02000000 0x3 0x41100000 0x0 0x3ef00000>;
+		reg-names = "dbi", "apb", "config";
+		resets = <&cru SRST_PCIE30X1_POWERUP>;
+		reset-names = "pipe";
+		/* rockchip,bifurcation; lane1 when using 1+1 */
+		status = "disabled";
+
+		pcie3x1_intc: legacy-interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 157 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
+	pcie3x2: pcie@fe280000 {
+		compatible = "rockchip,rk3568-pcie";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		bus-range = <0x20 0x2f>;
+		clocks = <&cru ACLK_PCIE30X2_MST>, <&cru ACLK_PCIE30X2_SLV>,
+			 <&cru ACLK_PCIE30X2_DBI>, <&cru PCLK_PCIE30X2>,
+			 <&cru CLK_PCIE30X2_AUX_NDFT>;
+		clock-names = "aclk_mst", "aclk_slv",
+			      "aclk_dbi", "pclk", "aux";
+		device_type = "pci";
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie3x2_intc 0>,
+				<0 0 0 2 &pcie3x2_intc 1>,
+				<0 0 0 3 &pcie3x2_intc 2>,
+				<0 0 0 4 &pcie3x2_intc 3>;
+		linux,pci-domain = <2>;
+		num-ib-windows = <6>;
+		num-ob-windows = <2>;
+		max-link-speed = <3>;
+		msi-map = <0x2000 &gic 0x2000 0x1000>;
+		num-lanes = <2>;
+		phys = <&pcie30phy>;
+		phy-names = "pcie-phy";
+		power-domains = <&power RK3568_PD_PIPE>;
+		reg = <0x3 0xc0800000 0x0 0x00400000>,
+		      <0x0 0xfe280000 0x0 0x00010000>,
+		      <0x3 0x80000000 0x0 0x01000000>;
+		ranges = <0x01000000 0x0 0x01000000 0x3 0x81000000 0x0 0x00100000>,
+			 <0x02000000 0x0 0x02000000 0x3 0x81100000 0x0 0x3ef00000>;
+		reg-names = "dbi", "apb", "config";
+		resets = <&cru SRST_PCIE30X2_POWERUP>;
+		reset-names = "pipe";
+		/* rockchip,bifurcation; lane0 when using 1+1 */
+		status = "disabled";
+
+		pcie3x2_intc: legacy-interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
 	gmac0: ethernet@fe2a0000 {
 		compatible = "rockchip,rk3568-gmac", "snps,dwmac-4.20a";
 		reg = <0x0 0xfe2a0000 0x0 0x10000>;
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC/RFT 5/6] arm64: dts: rockchip: rk3568: Add PCIe v3 nodes

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add nodes to rk356x devicetree to support PCIe v3.

Co-Developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi | 122 +++++++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
index 5eafddf62edc..083aeaf1d0f8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -42,6 +42,128 @@ qos_sata0: qos@fe190200 {
 		reg = <0x0 0xfe190200 0x0 0x20>;
 	};
 
+	pcie30_phy_grf: syscon@fdcb8000 {
+		compatible = "rockchip,pcie30-phy-grf", "syscon";
+		reg = <0x0 0xfdcb8000 0x0 0x10000>;
+	};
+
+	pcie30phy: phy@fe8c0000 {
+		compatible = "rockchip,rk3568-pcie3-phy";
+		reg = <0x0 0xfe8c0000 0x0 0x20000>;
+		#phy-cells = <0>;
+		clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
+			 <&cru PCLK_PCIE30PHY>;
+		clock-names = "refclk_m", "refclk_n", "pclk";
+		resets = <&cru SRST_PCIE30PHY>;
+		reset-names = "phy";
+		rockchip,phy-grf = <&pcie30_phy_grf>;
+		status = "disabled";
+	};
+
+	pcie3x1: pcie@fe270000 {
+		compatible = "rockchip,rk3568-pcie";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		bus-range = <0x10 0x1f>;
+		clocks = <&cru ACLK_PCIE30X1_MST>, <&cru ACLK_PCIE30X1_SLV>,
+			 <&cru ACLK_PCIE30X1_DBI>, <&cru PCLK_PCIE30X1>,
+			 <&cru CLK_PCIE30X1_AUX_NDFT>;
+		clock-names = "aclk_mst", "aclk_slv",
+			      "aclk_dbi", "pclk", "aux";
+		device_type = "pci";
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie3x1_intc 0>,
+				<0 0 0 2 &pcie3x1_intc 1>,
+				<0 0 0 3 &pcie3x1_intc 2>,
+				<0 0 0 4 &pcie3x1_intc 3>;
+		linux,pci-domain = <1>;
+		num-ib-windows = <6>;
+		num-ob-windows = <2>;
+		max-link-speed = <3>;
+		msi-map = <0x1000 &gic 0x1000 0x1000>;
+		num-lanes = <1>;
+		phys = <&pcie30phy>;
+		phy-names = "pcie-phy";
+		power-domains = <&power RK3568_PD_PIPE>;
+		reg = <0x3 0xc0400000 0x0 0x00400000>,
+		      <0x0 0xfe270000 0x0 0x00010000>,
+		      <0x3 0x40000000 0x0 0x01000000>;
+		ranges = <0x01000000 0x0 0x01000000 0x3 0x41000000 0x0 0x00100000>,
+			 <0x02000000 0x0 0x02000000 0x3 0x41100000 0x0 0x3ef00000>;
+		reg-names = "dbi", "apb", "config";
+		resets = <&cru SRST_PCIE30X1_POWERUP>;
+		reset-names = "pipe";
+		/* rockchip,bifurcation; lane1 when using 1+1 */
+		status = "disabled";
+
+		pcie3x1_intc: legacy-interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 157 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
+	pcie3x2: pcie@fe280000 {
+		compatible = "rockchip,rk3568-pcie";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		bus-range = <0x20 0x2f>;
+		clocks = <&cru ACLK_PCIE30X2_MST>, <&cru ACLK_PCIE30X2_SLV>,
+			 <&cru ACLK_PCIE30X2_DBI>, <&cru PCLK_PCIE30X2>,
+			 <&cru CLK_PCIE30X2_AUX_NDFT>;
+		clock-names = "aclk_mst", "aclk_slv",
+			      "aclk_dbi", "pclk", "aux";
+		device_type = "pci";
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie3x2_intc 0>,
+				<0 0 0 2 &pcie3x2_intc 1>,
+				<0 0 0 3 &pcie3x2_intc 2>,
+				<0 0 0 4 &pcie3x2_intc 3>;
+		linux,pci-domain = <2>;
+		num-ib-windows = <6>;
+		num-ob-windows = <2>;
+		max-link-speed = <3>;
+		msi-map = <0x2000 &gic 0x2000 0x1000>;
+		num-lanes = <2>;
+		phys = <&pcie30phy>;
+		phy-names = "pcie-phy";
+		power-domains = <&power RK3568_PD_PIPE>;
+		reg = <0x3 0xc0800000 0x0 0x00400000>,
+		      <0x0 0xfe280000 0x0 0x00010000>,
+		      <0x3 0x80000000 0x0 0x01000000>;
+		ranges = <0x01000000 0x0 0x01000000 0x3 0x81000000 0x0 0x00100000>,
+			 <0x02000000 0x0 0x02000000 0x3 0x81100000 0x0 0x3ef00000>;
+		reg-names = "dbi", "apb", "config";
+		resets = <&cru SRST_PCIE30X2_POWERUP>;
+		reset-names = "pipe";
+		/* rockchip,bifurcation; lane0 when using 1+1 */
+		status = "disabled";
+
+		pcie3x2_intc: legacy-interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
 	gmac0: ethernet@fe2a0000 {
 		compatible = "rockchip,rk3568-gmac", "snps,dwmac-4.20a";
 		reg = <0x0 0xfe2a0000 0x0 0x10000>;
-- 
2.25.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[RFC/RFT 5/6] arm64: dts: rockchip: rk3568: Add PCIe v3 nodes

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add nodes to rk356x devicetree to support PCIe v3.

Co-Developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi | 122 +++++++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
index 5eafddf62edc..083aeaf1d0f8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -42,6 +42,128 @@ qos_sata0: qos@fe190200 {
 		reg = <0x0 0xfe190200 0x0 0x20>;
 	};
 
+	pcie30_phy_grf: syscon@fdcb8000 {
+		compatible = "rockchip,pcie30-phy-grf", "syscon";
+		reg = <0x0 0xfdcb8000 0x0 0x10000>;
+	};
+
+	pcie30phy: phy@fe8c0000 {
+		compatible = "rockchip,rk3568-pcie3-phy";
+		reg = <0x0 0xfe8c0000 0x0 0x20000>;
+		#phy-cells = <0>;
+		clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
+			 <&cru PCLK_PCIE30PHY>;
+		clock-names = "refclk_m", "refclk_n", "pclk";
+		resets = <&cru SRST_PCIE30PHY>;
+		reset-names = "phy";
+		rockchip,phy-grf = <&pcie30_phy_grf>;
+		status = "disabled";
+	};
+
+	pcie3x1: pcie@fe270000 {
+		compatible = "rockchip,rk3568-pcie";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		bus-range = <0x10 0x1f>;
+		clocks = <&cru ACLK_PCIE30X1_MST>, <&cru ACLK_PCIE30X1_SLV>,
+			 <&cru ACLK_PCIE30X1_DBI>, <&cru PCLK_PCIE30X1>,
+			 <&cru CLK_PCIE30X1_AUX_NDFT>;
+		clock-names = "aclk_mst", "aclk_slv",
+			      "aclk_dbi", "pclk", "aux";
+		device_type = "pci";
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie3x1_intc 0>,
+				<0 0 0 2 &pcie3x1_intc 1>,
+				<0 0 0 3 &pcie3x1_intc 2>,
+				<0 0 0 4 &pcie3x1_intc 3>;
+		linux,pci-domain = <1>;
+		num-ib-windows = <6>;
+		num-ob-windows = <2>;
+		max-link-speed = <3>;
+		msi-map = <0x1000 &gic 0x1000 0x1000>;
+		num-lanes = <1>;
+		phys = <&pcie30phy>;
+		phy-names = "pcie-phy";
+		power-domains = <&power RK3568_PD_PIPE>;
+		reg = <0x3 0xc0400000 0x0 0x00400000>,
+		      <0x0 0xfe270000 0x0 0x00010000>,
+		      <0x3 0x40000000 0x0 0x01000000>;
+		ranges = <0x01000000 0x0 0x01000000 0x3 0x41000000 0x0 0x00100000>,
+			 <0x02000000 0x0 0x02000000 0x3 0x41100000 0x0 0x3ef00000>;
+		reg-names = "dbi", "apb", "config";
+		resets = <&cru SRST_PCIE30X1_POWERUP>;
+		reset-names = "pipe";
+		/* rockchip,bifurcation; lane1 when using 1+1 */
+		status = "disabled";
+
+		pcie3x1_intc: legacy-interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 157 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
+	pcie3x2: pcie@fe280000 {
+		compatible = "rockchip,rk3568-pcie";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		bus-range = <0x20 0x2f>;
+		clocks = <&cru ACLK_PCIE30X2_MST>, <&cru ACLK_PCIE30X2_SLV>,
+			 <&cru ACLK_PCIE30X2_DBI>, <&cru PCLK_PCIE30X2>,
+			 <&cru CLK_PCIE30X2_AUX_NDFT>;
+		clock-names = "aclk_mst", "aclk_slv",
+			      "aclk_dbi", "pclk", "aux";
+		device_type = "pci";
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie3x2_intc 0>,
+				<0 0 0 2 &pcie3x2_intc 1>,
+				<0 0 0 3 &pcie3x2_intc 2>,
+				<0 0 0 4 &pcie3x2_intc 3>;
+		linux,pci-domain = <2>;
+		num-ib-windows = <6>;
+		num-ob-windows = <2>;
+		max-link-speed = <3>;
+		msi-map = <0x2000 &gic 0x2000 0x1000>;
+		num-lanes = <2>;
+		phys = <&pcie30phy>;
+		phy-names = "pcie-phy";
+		power-domains = <&power RK3568_PD_PIPE>;
+		reg = <0x3 0xc0800000 0x0 0x00400000>,
+		      <0x0 0xfe280000 0x0 0x00010000>,
+		      <0x3 0x80000000 0x0 0x01000000>;
+		ranges = <0x01000000 0x0 0x01000000 0x3 0x81000000 0x0 0x00100000>,
+			 <0x02000000 0x0 0x02000000 0x3 0x81100000 0x0 0x3ef00000>;
+		reg-names = "dbi", "apb", "config";
+		resets = <&cru SRST_PCIE30X2_POWERUP>;
+		reset-names = "pipe";
+		/* rockchip,bifurcation; lane0 when using 1+1 */
+		status = "disabled";
+
+		pcie3x2_intc: legacy-interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
 	gmac0: ethernet@fe2a0000 {
 		compatible = "rockchip,rk3568-gmac", "snps,dwmac-4.20a";
 		reg = <0x0 0xfe2a0000 0x0 0x10000>;
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add Nodes to Bananapi-R2-Pro board to support PCIe v3 and
set pcie regulators to always on.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts   | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
index 2700fb18a3bc..e3a0f7d219a2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
@@ -74,6 +74,67 @@ vcc5v0_sys: vcc5v0-sys {
 		vin-supply = <&dc_12v>;
 	};
 
+	pcie30_avdd0v9: pcie30-avdd0v9 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd0v9";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	pcie30_avdd1v8: pcie30-avdd1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	/* pi6c pcie clock generator feeds both ports */
+	vcc3v3_pi6c_05: vcc3v3_pi6c_05-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_pcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		enable-active-high;
+		gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <20000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	/* actually fed by vcc3v3_sys, dependent on pi6c clock generator */
+	vcc3v3_minipcie: vcc3v3_minipcie-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_minipcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc3v3_pi6c_05>;
+	};
+
+	/* actually fed by vcc3v3_sys, dependent on pi6c clock generator */
+	vcc3v3_ngff: vcc3v3_ngff-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_ngff";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio4 RK_PC1 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc3v3_pi6c_05>;
+	};
+
 	vbus: vbus {
 		compatible = "regulator-fixed";
 		regulator-name = "vbus";
@@ -411,6 +472,24 @@ rgmii_phy1: ethernet-phy@0 {
 	};
 };
 
+&pcie30phy {
+       status = "okay";
+};
+
+&pcie3x1 {
+	rockchip,bifurcation;
+	reset-gpios = <&gpio3 RK_PA1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_ngff>;
+	status = "okay";
+};
+
+&pcie3x2 {
+	rockchip,bifurcation;
+	reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_minipcie>;
+	status = "okay";
+};
+
 &pinctrl {
 	leds {
 		blue_led_pin: blue-led-pin {
-- 
2.25.1

[RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add Nodes to Bananapi-R2-Pro board to support PCIe v3 and
set pcie regulators to always on.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts   | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
index 2700fb18a3bc..e3a0f7d219a2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
@@ -74,6 +74,67 @@ vcc5v0_sys: vcc5v0-sys {
 		vin-supply = <&dc_12v>;
 	};
 
+	pcie30_avdd0v9: pcie30-avdd0v9 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd0v9";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	pcie30_avdd1v8: pcie30-avdd1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	/* pi6c pcie clock generator feeds both ports */
+	vcc3v3_pi6c_05: vcc3v3_pi6c_05-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_pcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		enable-active-high;
+		gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <20000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	/* actually fed by vcc3v3_sys, dependent on pi6c clock generator */
+	vcc3v3_minipcie: vcc3v3_minipcie-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_minipcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc3v3_pi6c_05>;
+	};
+
+	/* actually fed by vcc3v3_sys, dependent on pi6c clock generator */
+	vcc3v3_ngff: vcc3v3_ngff-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_ngff";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio4 RK_PC1 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc3v3_pi6c_05>;
+	};
+
 	vbus: vbus {
 		compatible = "regulator-fixed";
 		regulator-name = "vbus";
@@ -411,6 +472,24 @@ rgmii_phy1: ethernet-phy@0 {
 	};
 };
 
+&pcie30phy {
+       status = "okay";
+};
+
+&pcie3x1 {
+	rockchip,bifurcation;
+	reset-gpios = <&gpio3 RK_PA1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_ngff>;
+	status = "okay";
+};
+
+&pcie3x2 {
+	rockchip,bifurcation;
+	reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_minipcie>;
+	status = "okay";
+};
+
 &pinctrl {
 	leds {
 		blue_led_pin: blue-led-pin {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add Nodes to Bananapi-R2-Pro board to support PCIe v3 and
set pcie regulators to always on.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts   | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
index 2700fb18a3bc..e3a0f7d219a2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
@@ -74,6 +74,67 @@ vcc5v0_sys: vcc5v0-sys {
 		vin-supply = <&dc_12v>;
 	};
 
+	pcie30_avdd0v9: pcie30-avdd0v9 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd0v9";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	pcie30_avdd1v8: pcie30-avdd1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	/* pi6c pcie clock generator feeds both ports */
+	vcc3v3_pi6c_05: vcc3v3_pi6c_05-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_pcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		enable-active-high;
+		gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <20000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	/* actually fed by vcc3v3_sys, dependent on pi6c clock generator */
+	vcc3v3_minipcie: vcc3v3_minipcie-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_minipcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc3v3_pi6c_05>;
+	};
+
+	/* actually fed by vcc3v3_sys, dependent on pi6c clock generator */
+	vcc3v3_ngff: vcc3v3_ngff-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_ngff";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio4 RK_PC1 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc3v3_pi6c_05>;
+	};
+
 	vbus: vbus {
 		compatible = "regulator-fixed";
 		regulator-name = "vbus";
@@ -411,6 +472,24 @@ rgmii_phy1: ethernet-phy@0 {
 	};
 };
 
+&pcie30phy {
+       status = "okay";
+};
+
+&pcie3x1 {
+	rockchip,bifurcation;
+	reset-gpios = <&gpio3 RK_PA1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_ngff>;
+	status = "okay";
+};
+
+&pcie3x2 {
+	rockchip,bifurcation;
+	reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_minipcie>;
+	status = "okay";
+};
+
 &pinctrl {
 	leds {
 		blue_led_pin: blue-led-pin {
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

[Frank Wunderlich]

From: Frank Wunderlich <frank-w@public-files.de>

Add Nodes to Bananapi-R2-Pro board to support PCIe v3 and
set pcie regulators to always on.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../boot/dts/rockchip/rk3568-bpi-r2-pro.dts   | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
index 2700fb18a3bc..e3a0f7d219a2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
@@ -74,6 +74,67 @@ vcc5v0_sys: vcc5v0-sys {
 		vin-supply = <&dc_12v>;
 	};
 
+	pcie30_avdd0v9: pcie30-avdd0v9 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd0v9";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	pcie30_avdd1v8: pcie30-avdd1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	/* pi6c pcie clock generator feeds both ports */
+	vcc3v3_pi6c_05: vcc3v3_pi6c_05-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_pcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		enable-active-high;
+		gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <20000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	/* actually fed by vcc3v3_sys, dependent on pi6c clock generator */
+	vcc3v3_minipcie: vcc3v3_minipcie-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_minipcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc3v3_pi6c_05>;
+	};
+
+	/* actually fed by vcc3v3_sys, dependent on pi6c clock generator */
+	vcc3v3_ngff: vcc3v3_ngff-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_ngff";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio4 RK_PC1 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc3v3_pi6c_05>;
+	};
+
 	vbus: vbus {
 		compatible = "regulator-fixed";
 		regulator-name = "vbus";
@@ -411,6 +472,24 @@ rgmii_phy1: ethernet-phy@0 {
 	};
 };
 
+&pcie30phy {
+       status = "okay";
+};
+
+&pcie3x1 {
+	rockchip,bifurcation;
+	reset-gpios = <&gpio3 RK_PA1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_ngff>;
+	status = "okay";
+};
+
+&pcie3x2 {
+	rockchip,bifurcation;
+	reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_minipcie>;
+	status = "okay";
+};
+
 &pinctrl {
 	leds {
 		blue_led_pin: blue-led-pin {
-- 
2.25.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:

(...)

> +	pcie30_avdd1v8: pcie30-avdd1v8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pcie30_avdd1v8";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
> +	/* pi6c pcie clock generator feeds both ports */
> +	vcc3v3_pi6c_05: vcc3v3_pi6c_05-regulator {

No underscores in node names. Same in other places.


Best regards,
Krzysztof

Re: [RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:

(...)

> +	pcie30_avdd1v8: pcie30-avdd1v8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pcie30_avdd1v8";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
> +	/* pi6c pcie clock generator feeds both ports */
> +	vcc3v3_pi6c_05: vcc3v3_pi6c_05-regulator {

No underscores in node names. Same in other places.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:

(...)

> +	pcie30_avdd1v8: pcie30-avdd1v8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pcie30_avdd1v8";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
> +	/* pi6c pcie clock generator feeds both ports */
> +	vcc3v3_pi6c_05: vcc3v3_pi6c_05-regulator {

No underscores in node names. Same in other places.


Best regards,
Krzysztof

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

[Krzysztof Kozlowski]

On 16/04/2022 15:54, Frank Wunderlich wrote:

(...)

> +	pcie30_avdd1v8: pcie30-avdd1v8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pcie30_avdd1v8";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
> +	/* pi6c pcie clock generator feeds both ports */
> +	vcc3v3_pi6c_05: vcc3v3_pi6c_05-regulator {

No underscores in node names. Same in other places.


Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 0/6] RK3568 PCIe V3 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Frank Wunderlich <linux@fw-web.de> w dniu 16.04.2022, o godz. 15:54:
> 
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> This series adds Rockchip PCIe V3 support found on rk3568 SOC.
> 
> It is based on "Enable rk356x PCIe controller" series of Peter Geis
> v7: https://patchwork.kernel.org/project/linux-rockchip/cover/20220416110507.642398-1-pgwipeout@gmail.com/
> 
> Compared to PCIeV2 which uses the Naneng combphy, pciev3
> uses a dedicated pci-phy.
> 
> Frank Wunderlich (6):
>  dt-bindings: phy: rockchip: add pcie3 phy
>  dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
>  phy: rockchip: Support pcie v3
>  PCI: rockchip-dwc: add pcie bifurcation
>  arm64: dts: rockchip: rk3568: Add PCIe v3 nodes
>  arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

Frank, Peter

FYI: 
This series gives me nicely working PCI-e WiFi M2 iwl7265 module on rock3-a.
Great work!

Re: [RFC/RFT 0/6] RK3568 PCIe V3 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Frank Wunderlich <linux@fw-web.de> w dniu 16.04.2022, o godz. 15:54:
> 
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> This series adds Rockchip PCIe V3 support found on rk3568 SOC.
> 
> It is based on "Enable rk356x PCIe controller" series of Peter Geis
> v7: https://patchwork.kernel.org/project/linux-rockchip/cover/20220416110507.642398-1-pgwipeout@gmail.com/
> 
> Compared to PCIeV2 which uses the Naneng combphy, pciev3
> uses a dedicated pci-phy.
> 
> Frank Wunderlich (6):
>  dt-bindings: phy: rockchip: add pcie3 phy
>  dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
>  phy: rockchip: Support pcie v3
>  PCI: rockchip-dwc: add pcie bifurcation
>  arm64: dts: rockchip: rk3568: Add PCIe v3 nodes
>  arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

Frank, Peter

FYI: 
This series gives me nicely working PCI-e WiFi M2 iwl7265 module on rock3-a.
Great work!



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 0/6] RK3568 PCIe V3 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Frank Wunderlich <linux@fw-web.de> w dniu 16.04.2022, o godz. 15:54:
> 
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> This series adds Rockchip PCIe V3 support found on rk3568 SOC.
> 
> It is based on "Enable rk356x PCIe controller" series of Peter Geis
> v7: https://patchwork.kernel.org/project/linux-rockchip/cover/20220416110507.642398-1-pgwipeout@gmail.com/
> 
> Compared to PCIeV2 which uses the Naneng combphy, pciev3
> uses a dedicated pci-phy.
> 
> Frank Wunderlich (6):
>  dt-bindings: phy: rockchip: add pcie3 phy
>  dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
>  phy: rockchip: Support pcie v3
>  PCI: rockchip-dwc: add pcie bifurcation
>  arm64: dts: rockchip: rk3568: Add PCIe v3 nodes
>  arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

Frank, Peter

FYI: 
This series gives me nicely working PCI-e WiFi M2 iwl7265 module on rock3-a.
Great work!



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 0/6] RK3568 PCIe V3 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Frank Wunderlich <linux@fw-web.de> w dniu 16.04.2022, o godz. 15:54:
> 
> From: Frank Wunderlich <frank-w@public-files.de>
> 
> This series adds Rockchip PCIe V3 support found on rk3568 SOC.
> 
> It is based on "Enable rk356x PCIe controller" series of Peter Geis
> v7: https://patchwork.kernel.org/project/linux-rockchip/cover/20220416110507.642398-1-pgwipeout@gmail.com/
> 
> Compared to PCIeV2 which uses the Naneng combphy, pciev3
> uses a dedicated pci-phy.
> 
> Frank Wunderlich (6):
>  dt-bindings: phy: rockchip: add pcie3 phy
>  dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
>  phy: rockchip: Support pcie v3
>  PCI: rockchip-dwc: add pcie bifurcation
>  arm64: dts: rockchip: rk3568: Add PCIe v3 nodes
>  arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro

Frank, Peter

FYI: 
This series gives me nicely working PCI-e WiFi M2 iwl7265 module on rock3-a.
Great work!



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC/RFT 0/6] RK3568 PCIe V3 support

[Frank Wunderlich]

Am 11. Mai 2022 21:26:09 MESZ schrieb Piotr Oniszczuk <piotr.oniszczuk@gmail.com>:

>Frank, Peter
>
>FYI: 
>This series gives me nicely working PCI-e WiFi M2 iwl7265 module on
>rock3-a.
>Great work!

Hi,

Peter recently made some fixes and improvements. I plan to send new version soon.

You're welcome to test it on your board and give a Tested-by tag
regards Frank

Re: [RFC/RFT 0/6] RK3568 PCIe V3 support

[Frank Wunderlich]

Am 11. Mai 2022 21:26:09 MESZ schrieb Piotr Oniszczuk <piotr.oniszczuk@gmail.com>:

>Frank, Peter
>
>FYI: 
>This series gives me nicely working PCI-e WiFi M2 iwl7265 module on
>rock3-a.
>Great work!

Hi,

Peter recently made some fixes and improvements. I plan to send new version soon.

You're welcome to test it on your board and give a Tested-by tag
regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC/RFT 0/6] RK3568 PCIe V3 support

[Frank Wunderlich]

Am 11. Mai 2022 21:26:09 MESZ schrieb Piotr Oniszczuk <piotr.oniszczuk@gmail.com>:

>Frank, Peter
>
>FYI: 
>This series gives me nicely working PCI-e WiFi M2 iwl7265 module on
>rock3-a.
>Great work!

Hi,

Peter recently made some fixes and improvements. I plan to send new version soon.

You're welcome to test it on your board and give a Tested-by tag
regards Frank

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [RFC/RFT 0/6] RK3568 PCIe V3 support

[Frank Wunderlich]

Am 11. Mai 2022 21:26:09 MESZ schrieb Piotr Oniszczuk <piotr.oniszczuk@gmail.com>:

>Frank, Peter
>
>FYI: 
>This series gives me nicely working PCI-e WiFi M2 iwl7265 module on
>rock3-a.
>Great work!

Hi,

Peter recently made some fixes and improvements. I plan to send new version soon.

You're welcome to test it on your board and give a Tested-by tag
regards Frank

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip