[PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

refer to the discussion [1] when try to enable i.MX8MM PCIe support,
one standalone PCIe PHY driver should be seperated from i.MX PCIe
driver when enable i.MX8MM PCIe support.

This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
PCIe support[6-9] to have whole view to review this patch-set.

The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
[2] and this PHY driver patch-set.

[1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
[2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/

Main changes v2 --> v3:
- Regarding Lucas' comments.
 - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
 - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
 - split the dts changes to SOC and board DT, and use the enum instead of raw value.
 - update the license of the dt-binding header file.

Changes v1 --> v2:
- Update the license of the dt-binding header file to make the license
  compatible with dts files.
- Fix the dt_binding_check errors.

Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
drivers/phy/freescale/Kconfig                                |   9 ++++
drivers/phy/freescale/Makefile                               |   1 +
drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
9 files changed, 486 insertions(+), 3 deletions(-)

[PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
[PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
[PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
[PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
[PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
[PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
[PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
[PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
[PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

refer to the discussion [1] when try to enable i.MX8MM PCIe support,
one standalone PCIe PHY driver should be seperated from i.MX PCIe
driver when enable i.MX8MM PCIe support.

This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
PCIe support[6-9] to have whole view to review this patch-set.

The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
[2] and this PHY driver patch-set.

[1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
[2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/

Main changes v2 --> v3:
- Regarding Lucas' comments.
 - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
 - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
 - split the dts changes to SOC and board DT, and use the enum instead of raw value.
 - update the license of the dt-binding header file.

Changes v1 --> v2:
- Update the license of the dt-binding header file to make the license
  compatible with dts files.
- Fix the dt_binding_check errors.

Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
drivers/phy/freescale/Kconfig                                |   9 ++++
drivers/phy/freescale/Makefile                               |   1 +
drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
9 files changed, 486 insertions(+), 3 deletions(-)

[PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
[PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
[PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
[PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
[PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
[PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
[PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
[PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
[PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

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

[PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

refer to the discussion [1] when try to enable i.MX8MM PCIe support,
one standalone PCIe PHY driver should be seperated from i.MX PCIe
driver when enable i.MX8MM PCIe support.

This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
PCIe support[6-9] to have whole view to review this patch-set.

The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
[2] and this PHY driver patch-set.

[1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
[2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/

Main changes v2 --> v3:
- Regarding Lucas' comments.
 - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
 - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
 - split the dts changes to SOC and board DT, and use the enum instead of raw value.
 - update the license of the dt-binding header file.

Changes v1 --> v2:
- Update the license of the dt-binding header file to make the license
  compatible with dts files.
- Fix the dt_binding_check errors.

Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
drivers/phy/freescale/Kconfig                                |   9 ++++
drivers/phy/freescale/Makefile                               |   1 +
drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
9 files changed, 486 insertions(+), 3 deletions(-)

[PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
[PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
[PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
[PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
[PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
[PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
[PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
[PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
[PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

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

[PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the pad modes of imx8 pcie phy

[Richard Zhu]

Add binding for reference clock PAD modes of the i.MX8 PCIe PHY.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 include/dt-bindings/phy/phy-imx8-pcie.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 include/dt-bindings/phy/phy-imx8-pcie.h

diff --git a/include/dt-bindings/phy/phy-imx8-pcie.h b/include/dt-bindings/phy/phy-imx8-pcie.h
new file mode 100644
index 000000000000..2bc7f1b31c6b
--- /dev/null
+++ b/include/dt-bindings/phy/phy-imx8-pcie.h
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * This header provides constants for i.MX8 PCIe.
+ */
+
+#ifndef _DT_BINDINGS_IMX8_PCIE_H
+#define _DT_BINDINGS_IMX8_PCIE_H
+
+/* Reference clock PAD mode */
+#define IMX8_PCIE_REFCLK_PAD_UNUSED	0
+#define IMX8_PCIE_REFCLK_PAD_INPUT	1
+#define IMX8_PCIE_REFCLK_PAD_OUTPUT	2
+
+#endif /* _DT_BINDINGS_IMX8_PCIE_H */
-- 
2.25.1

[PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the pad modes of imx8 pcie phy

[Richard Zhu]

Add binding for reference clock PAD modes of the i.MX8 PCIe PHY.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 include/dt-bindings/phy/phy-imx8-pcie.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 include/dt-bindings/phy/phy-imx8-pcie.h

diff --git a/include/dt-bindings/phy/phy-imx8-pcie.h b/include/dt-bindings/phy/phy-imx8-pcie.h
new file mode 100644
index 000000000000..2bc7f1b31c6b
--- /dev/null
+++ b/include/dt-bindings/phy/phy-imx8-pcie.h
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * This header provides constants for i.MX8 PCIe.
+ */
+
+#ifndef _DT_BINDINGS_IMX8_PCIE_H
+#define _DT_BINDINGS_IMX8_PCIE_H
+
+/* Reference clock PAD mode */
+#define IMX8_PCIE_REFCLK_PAD_UNUSED	0
+#define IMX8_PCIE_REFCLK_PAD_INPUT	1
+#define IMX8_PCIE_REFCLK_PAD_OUTPUT	2
+
+#endif /* _DT_BINDINGS_IMX8_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

[PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the pad modes of imx8 pcie phy

[Richard Zhu]

Add binding for reference clock PAD modes of the i.MX8 PCIe PHY.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 include/dt-bindings/phy/phy-imx8-pcie.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 include/dt-bindings/phy/phy-imx8-pcie.h

diff --git a/include/dt-bindings/phy/phy-imx8-pcie.h b/include/dt-bindings/phy/phy-imx8-pcie.h
new file mode 100644
index 000000000000..2bc7f1b31c6b
--- /dev/null
+++ b/include/dt-bindings/phy/phy-imx8-pcie.h
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * This header provides constants for i.MX8 PCIe.
+ */
+
+#ifndef _DT_BINDINGS_IMX8_PCIE_H
+#define _DT_BINDINGS_IMX8_PCIE_H
+
+/* Reference clock PAD mode */
+#define IMX8_PCIE_REFCLK_PAD_UNUSED	0
+#define IMX8_PCIE_REFCLK_PAD_INPUT	1
+#define IMX8_PCIE_REFCLK_PAD_OUTPUT	2
+
+#endif /* _DT_BINDINGS_IMX8_PCIE_H */
-- 
2.25.1


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

[PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Richard Zhu]

Add dt-binding for the standalone i.MX8 PCIe PHY driver.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
new file mode 100644
index 000000000000..7973abf67278
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8 SoC series PCIe PHY Device Tree Bindings
+
+maintainers:
+  - Richard Zhu <hongxing.zhu@nxp.com>
+
+properties:
+  "#phy-cells":
+    const: 0
+
+  compatible:
+    enum:
+      - fsl,imx8mm-pcie-phy
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: PHY module clock
+
+  clock-names:
+    items:
+      - const: ref
+
+  resets:
+    items:
+      - description: Phandles to PCIe-related reset lines exposed by SRC
+          IP block.
+
+  reset-names:
+    items:
+      - const: pciephy
+
+  fsl,refclk-pad-mode:
+    description: |
+      Specifies the mode of the refclk pad used. It can be UNUSED(PHY
+      refclock is derived from SoC internal source), INPUT(PHY refclock
+      is provided externally via the refclk pad) or OUTPUT(PHY refclock
+      is derived from SoC internal source and provided on the refclk pad).
+      Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants
+      to be used.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [ 0, 1, 2 ]
+
+required:
+  - "#phy-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - fsl,refclk-pad-mode
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/imx8mm-clock.h>
+    #include <dt-bindings/phy/phy-imx8-pcie.h>
+
+    pcie_phy: pcie-phy@32f00000 {
+            compatible = "fsl,imx8mm-pcie-phy";
+            reg = <0x32f00000 0x10000>;
+            clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+            clock-names = "ref";
+            assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+            assigned-clock-rates = <100000000>;
+            assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
+            resets = <&src IMX8MQ_RESET_PCIEPHY>;
+            reset-names = "pciephy";
+            fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+            #phy-cells = <0>;
+    };
+...
-- 
2.25.1

[PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Richard Zhu]

Add dt-binding for the standalone i.MX8 PCIe PHY driver.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
new file mode 100644
index 000000000000..7973abf67278
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8 SoC series PCIe PHY Device Tree Bindings
+
+maintainers:
+  - Richard Zhu <hongxing.zhu@nxp.com>
+
+properties:
+  "#phy-cells":
+    const: 0
+
+  compatible:
+    enum:
+      - fsl,imx8mm-pcie-phy
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: PHY module clock
+
+  clock-names:
+    items:
+      - const: ref
+
+  resets:
+    items:
+      - description: Phandles to PCIe-related reset lines exposed by SRC
+          IP block.
+
+  reset-names:
+    items:
+      - const: pciephy
+
+  fsl,refclk-pad-mode:
+    description: |
+      Specifies the mode of the refclk pad used. It can be UNUSED(PHY
+      refclock is derived from SoC internal source), INPUT(PHY refclock
+      is provided externally via the refclk pad) or OUTPUT(PHY refclock
+      is derived from SoC internal source and provided on the refclk pad).
+      Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants
+      to be used.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [ 0, 1, 2 ]
+
+required:
+  - "#phy-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - fsl,refclk-pad-mode
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/imx8mm-clock.h>
+    #include <dt-bindings/phy/phy-imx8-pcie.h>
+
+    pcie_phy: pcie-phy@32f00000 {
+            compatible = "fsl,imx8mm-pcie-phy";
+            reg = <0x32f00000 0x10000>;
+            clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+            clock-names = "ref";
+            assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+            assigned-clock-rates = <100000000>;
+            assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
+            resets = <&src IMX8MQ_RESET_PCIEPHY>;
+            reset-names = "pciephy";
+            fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+            #phy-cells = <0>;
+    };
+...
-- 
2.25.1


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

[PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Richard Zhu]

Add dt-binding for the standalone i.MX8 PCIe PHY driver.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
new file mode 100644
index 000000000000..7973abf67278
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8 SoC series PCIe PHY Device Tree Bindings
+
+maintainers:
+  - Richard Zhu <hongxing.zhu@nxp.com>
+
+properties:
+  "#phy-cells":
+    const: 0
+
+  compatible:
+    enum:
+      - fsl,imx8mm-pcie-phy
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: PHY module clock
+
+  clock-names:
+    items:
+      - const: ref
+
+  resets:
+    items:
+      - description: Phandles to PCIe-related reset lines exposed by SRC
+          IP block.
+
+  reset-names:
+    items:
+      - const: pciephy
+
+  fsl,refclk-pad-mode:
+    description: |
+      Specifies the mode of the refclk pad used. It can be UNUSED(PHY
+      refclock is derived from SoC internal source), INPUT(PHY refclock
+      is provided externally via the refclk pad) or OUTPUT(PHY refclock
+      is derived from SoC internal source and provided on the refclk pad).
+      Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants
+      to be used.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [ 0, 1, 2 ]
+
+required:
+  - "#phy-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - fsl,refclk-pad-mode
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/imx8mm-clock.h>
+    #include <dt-bindings/phy/phy-imx8-pcie.h>
+
+    pcie_phy: pcie-phy@32f00000 {
+            compatible = "fsl,imx8mm-pcie-phy";
+            reg = <0x32f00000 0x10000>;
+            clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+            clock-names = "ref";
+            assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+            assigned-clock-rates = <100000000>;
+            assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
+            resets = <&src IMX8MQ_RESET_PCIEPHY>;
+            reset-names = "pciephy";
+            fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+            #phy-cells = <0>;
+    };
+...
-- 
2.25.1


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

Re: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Rob Herring]

On Tue, 12 Oct 2021 16:41:11 +0800, Richard Zhu wrote:
> Add dt-binding for the standalone i.MX8 PCIe PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79 +++++++++++++++++++
>  1 file changed, 79 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dts:30.32-33 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:385: Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1441: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1539660

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Rob Herring]

On Tue, 12 Oct 2021 16:41:11 +0800, Richard Zhu wrote:
> Add dt-binding for the standalone i.MX8 PCIe PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79 +++++++++++++++++++
>  1 file changed, 79 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dts:30.32-33 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:385: Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1441: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1539660

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


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

Re: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Rob Herring]

On Tue, 12 Oct 2021 16:41:11 +0800, Richard Zhu wrote:
> Add dt-binding for the standalone i.MX8 PCIe PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79 +++++++++++++++++++
>  1 file changed, 79 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dts:30.32-33 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:385: Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1441: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1539660

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


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

RE: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Richard Zhu]

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, October 12, 2021 9:18 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: shawnguo@kernel.org; linux-phy@lists.infradead.org;
> galak@kernel.crashing.org; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; kernel@pengutronix.de;
> linux-kernel@vger.kernel.org; tharvey@gateworks.com; kishon@ti.com;
> dl-linux-imx <linux-imx@nxp.com>; l.stach@pengutronix.de;
> vkoul@kernel.org
> Subject: Re: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> 
> On Tue, 12 Oct 2021 16:41:11 +0800, Richard Zhu wrote:
> > Add dt-binding for the standalone i.MX8 PCIe PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79
> +++++++++++++++++++
> >  1 file changed, 79 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> >
> 
> My bot found errors running 'make DT_CHECKER_FLAGS=-m
> dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Error:
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dts:30.3
> 2-33 syntax error FATAL ERROR: Unable to parse input tree
> make[1]: *** [scripts/Makefile.lib:385:
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dt.yaml]
> Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [Makefile:1441: dt_binding_check] Error 2
> 
[Richard Zhu] I forget to merge to add the "#include <dt-bindings/reset/imx8mq-reset.h>" after add the reset property.
Sorry about that, would add it later.


Best Regards
Richard Zhu
> doc reference errors (make refcheckdocs):
> 
> See
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fpatch%2F1539660&amp;data=04%7C01%7Chongxing.zhu
> %40nxp.com%7C64619a3cd64446cf204008d98d82ca07%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C0%7C637696415146711570%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C1000&amp;sdata=jt2nbxfbKTBm1izvsYvsHEkMfSHqa6t
> 24B1sJICAtXE%3D&amp;reserved=0
> 
> This check can fail if there are any dependencies. The base for a patch series
> is generally the most recent rc1.
> 
> If you already ran 'make dt_binding_check' and didn't see the above error(s),
> then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit.

RE: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Richard Zhu]

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, October 12, 2021 9:18 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: shawnguo@kernel.org; linux-phy@lists.infradead.org;
> galak@kernel.crashing.org; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; kernel@pengutronix.de;
> linux-kernel@vger.kernel.org; tharvey@gateworks.com; kishon@ti.com;
> dl-linux-imx <linux-imx@nxp.com>; l.stach@pengutronix.de;
> vkoul@kernel.org
> Subject: Re: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> 
> On Tue, 12 Oct 2021 16:41:11 +0800, Richard Zhu wrote:
> > Add dt-binding for the standalone i.MX8 PCIe PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79
> +++++++++++++++++++
> >  1 file changed, 79 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> >
> 
> My bot found errors running 'make DT_CHECKER_FLAGS=-m
> dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Error:
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dts:30.3
> 2-33 syntax error FATAL ERROR: Unable to parse input tree
> make[1]: *** [scripts/Makefile.lib:385:
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dt.yaml]
> Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [Makefile:1441: dt_binding_check] Error 2
> 
[Richard Zhu] I forget to merge to add the "#include <dt-bindings/reset/imx8mq-reset.h>" after add the reset property.
Sorry about that, would add it later.


Best Regards
Richard Zhu
> doc reference errors (make refcheckdocs):
> 
> See
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fpatch%2F1539660&amp;data=04%7C01%7Chongxing.zhu
> %40nxp.com%7C64619a3cd64446cf204008d98d82ca07%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C0%7C637696415146711570%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C1000&amp;sdata=jt2nbxfbKTBm1izvsYvsHEkMfSHqa6t
> 24B1sJICAtXE%3D&amp;reserved=0
> 
> This check can fail if there are any dependencies. The base for a patch series
> is generally the most recent rc1.
> 
> If you already ran 'make dt_binding_check' and didn't see the above error(s),
> then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit.


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

RE: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support

[Richard Zhu]

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, October 12, 2021 9:18 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: shawnguo@kernel.org; linux-phy@lists.infradead.org;
> galak@kernel.crashing.org; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; kernel@pengutronix.de;
> linux-kernel@vger.kernel.org; tharvey@gateworks.com; kishon@ti.com;
> dl-linux-imx <linux-imx@nxp.com>; l.stach@pengutronix.de;
> vkoul@kernel.org
> Subject: Re: [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> 
> On Tue, 12 Oct 2021 16:41:11 +0800, Richard Zhu wrote:
> > Add dt-binding for the standalone i.MX8 PCIe PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  .../bindings/phy/fsl,imx8-pcie-phy.yaml       | 79
> +++++++++++++++++++
> >  1 file changed, 79 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> >
> 
> My bot found errors running 'make DT_CHECKER_FLAGS=-m
> dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Error:
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dts:30.3
> 2-33 syntax error FATAL ERROR: Unable to parse input tree
> make[1]: *** [scripts/Makefile.lib:385:
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.example.dt.yaml]
> Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [Makefile:1441: dt_binding_check] Error 2
> 
[Richard Zhu] I forget to merge to add the "#include <dt-bindings/reset/imx8mq-reset.h>" after add the reset property.
Sorry about that, would add it later.


Best Regards
Richard Zhu
> doc reference errors (make refcheckdocs):
> 
> See
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fpatch%2F1539660&amp;data=04%7C01%7Chongxing.zhu
> %40nxp.com%7C64619a3cd64446cf204008d98d82ca07%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C0%7C637696415146711570%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C1000&amp;sdata=jt2nbxfbKTBm1izvsYvsHEkMfSHqa6t
> 24B1sJICAtXE%3D&amp;reserved=0
> 
> This check can fail if there are any dependencies. The base for a patch series
> is generally the most recent rc1.
> 
> If you already ran 'make dt_binding_check' and didn't see the above error(s),
> then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit.


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

[PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Richard Zhu]

Add the PCIe PHY support on iMX8MM platforms.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index c2f3f118f82e..ac5d11466608 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
 				reg = <0x32e50200 0x200>;
 			};
 
+			pcie_phy: pcie-phy@32f00000 {
+				compatible = "fsl,imx8mm-pcie-phy";
+				reg = <0x32f00000 0x10000>;
+				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+				clock-names = "phy";
+				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+				assigned-clock-rates = <100000000>;
+				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
+				resets = <&src IMX8MQ_RESET_PCIEPHY>;
+				reset-names = "pciephy";
+				#phy-cells = <0>;
+				status = "disabled";
+			};
 		};
 
 		dma_apbh: dma-controller@33000000 {
-- 
2.25.1

[PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Richard Zhu]

Add the PCIe PHY support on iMX8MM platforms.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index c2f3f118f82e..ac5d11466608 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
 				reg = <0x32e50200 0x200>;
 			};
 
+			pcie_phy: pcie-phy@32f00000 {
+				compatible = "fsl,imx8mm-pcie-phy";
+				reg = <0x32f00000 0x10000>;
+				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+				clock-names = "phy";
+				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+				assigned-clock-rates = <100000000>;
+				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
+				resets = <&src IMX8MQ_RESET_PCIEPHY>;
+				reset-names = "pciephy";
+				#phy-cells = <0>;
+				status = "disabled";
+			};
 		};
 
 		dma_apbh: dma-controller@33000000 {
-- 
2.25.1


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

[PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Richard Zhu]

Add the PCIe PHY support on iMX8MM platforms.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index c2f3f118f82e..ac5d11466608 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
 				reg = <0x32e50200 0x200>;
 			};
 
+			pcie_phy: pcie-phy@32f00000 {
+				compatible = "fsl,imx8mm-pcie-phy";
+				reg = <0x32f00000 0x10000>;
+				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+				clock-names = "phy";
+				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
+				assigned-clock-rates = <100000000>;
+				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
+				resets = <&src IMX8MQ_RESET_PCIEPHY>;
+				reset-names = "pciephy";
+				#phy-cells = <0>;
+				status = "disabled";
+			};
 		};
 
 		dma_apbh: dma-controller@33000000 {
-- 
2.25.1


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

Re: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe PHY support on iMX8MM platforms.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index c2f3f118f82e..ac5d11466608 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
>  				reg = <0x32e50200 0x200>;
>  			};
>  
> +			pcie_phy: pcie-phy@32f00000 {
> +				compatible = "fsl,imx8mm-pcie-phy";
> +				reg = <0x32f00000 0x10000>;
> +				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> +				clock-names = "phy";

Clock name specified in the binding is "ref".

> +				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> +				assigned-clock-rates = <100000000>;
> +				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
> +				resets = <&src IMX8MQ_RESET_PCIEPHY>;
> +				reset-names = "pciephy";
> +				#phy-cells = <0>;
> +				status = "disabled";
> +			};
>  		};
>  
>  		dma_apbh: dma-controller@33000000 {

Re: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe PHY support on iMX8MM platforms.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index c2f3f118f82e..ac5d11466608 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
>  				reg = <0x32e50200 0x200>;
>  			};
>  
> +			pcie_phy: pcie-phy@32f00000 {
> +				compatible = "fsl,imx8mm-pcie-phy";
> +				reg = <0x32f00000 0x10000>;
> +				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> +				clock-names = "phy";

Clock name specified in the binding is "ref".

> +				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> +				assigned-clock-rates = <100000000>;
> +				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
> +				resets = <&src IMX8MQ_RESET_PCIEPHY>;
> +				reset-names = "pciephy";
> +				#phy-cells = <0>;
> +				status = "disabled";
> +			};
>  		};
>  
>  		dma_apbh: dma-controller@33000000 {



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

Re: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe PHY support on iMX8MM platforms.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index c2f3f118f82e..ac5d11466608 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
>  				reg = <0x32e50200 0x200>;
>  			};
>  
> +			pcie_phy: pcie-phy@32f00000 {
> +				compatible = "fsl,imx8mm-pcie-phy";
> +				reg = <0x32f00000 0x10000>;
> +				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> +				clock-names = "phy";

Clock name specified in the binding is "ref".

> +				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> +				assigned-clock-rates = <100000000>;
> +				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>;
> +				resets = <&src IMX8MQ_RESET_PCIEPHY>;
> +				reset-names = "pciephy";
> +				#phy-cells = <0>;
> +				status = "disabled";
> +			};
>  		};
>  
>  		dma_apbh: dma-controller@33000000 {



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

RE: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:30 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe PHY support on iMX8MM platforms.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > index c2f3f118f82e..ac5d11466608 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > @@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
> >  				reg = <0x32e50200 0x200>;
> >  			};
> >
> > +			pcie_phy: pcie-phy@32f00000 {
> > +				compatible = "fsl,imx8mm-pcie-phy";
> > +				reg = <0x32f00000 0x10000>;
> > +				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> > +				clock-names = "phy";
> 
> Clock name specified in the binding is "ref".
[Richard Zhu] Would changed later, thanks.

Best Regards
Richard Zhu

> 
> > +				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> > +				assigned-clock-rates = <100000000>;
> > +				assigned-clock-parents = <&clk
> IMX8MM_SYS_PLL2_100M>;
> > +				resets = <&src IMX8MQ_RESET_PCIEPHY>;
> > +				reset-names = "pciephy";
> > +				#phy-cells = <0>;
> > +				status = "disabled";
> > +			};
> >  		};
> >
> >  		dma_apbh: dma-controller@33000000 {
> 

RE: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:30 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe PHY support on iMX8MM platforms.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > index c2f3f118f82e..ac5d11466608 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > @@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
> >  				reg = <0x32e50200 0x200>;
> >  			};
> >
> > +			pcie_phy: pcie-phy@32f00000 {
> > +				compatible = "fsl,imx8mm-pcie-phy";
> > +				reg = <0x32f00000 0x10000>;
> > +				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> > +				clock-names = "phy";
> 
> Clock name specified in the binding is "ref".
[Richard Zhu] Would changed later, thanks.

Best Regards
Richard Zhu

> 
> > +				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> > +				assigned-clock-rates = <100000000>;
> > +				assigned-clock-parents = <&clk
> IMX8MM_SYS_PLL2_100M>;
> > +				resets = <&src IMX8MQ_RESET_PCIEPHY>;
> > +				reset-names = "pciephy";
> > +				#phy-cells = <0>;
> > +				status = "disabled";
> > +			};
> >  		};
> >
> >  		dma_apbh: dma-controller@33000000 {
> 

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

RE: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:30 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe PHY support on iMX8MM platforms.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > index c2f3f118f82e..ac5d11466608 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > @@ -1135,6 +1135,19 @@ usbmisc2: usbmisc@32e50200 {
> >  				reg = <0x32e50200 0x200>;
> >  			};
> >
> > +			pcie_phy: pcie-phy@32f00000 {
> > +				compatible = "fsl,imx8mm-pcie-phy";
> > +				reg = <0x32f00000 0x10000>;
> > +				clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> > +				clock-names = "phy";
> 
> Clock name specified in the binding is "ref".
[Richard Zhu] Would changed later, thanks.

Best Regards
Richard Zhu

> 
> > +				assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>;
> > +				assigned-clock-rates = <100000000>;
> > +				assigned-clock-parents = <&clk
> IMX8MM_SYS_PLL2_100M>;
> > +				resets = <&src IMX8MQ_RESET_PCIEPHY>;
> > +				reset-names = "pciephy";
> > +				#phy-cells = <0>;
> > +				status = "disabled";
> > +			};
> >  		};
> >
> >  		dma_apbh: dma-controller@33000000 {
> 

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

[PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Richard Zhu]

Add the PCIe PHY support on iMX8MM EVK boards.
And set the default reference clock mode.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index e033d0257b5a..2d0684ac82f6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/phy/phy-imx8-pcie.h>
 #include <dt-bindings/usb/pd.h>
 #include "imx8mm.dtsi"
 
@@ -289,6 +290,12 @@ pca6416: gpio@20 {
 	};
 };
 
+&pcie_phy {
+	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+	clocks = <&clk IMX8MM_CLK_DUMMY>;
+	status = "okay";
+};
+
 &sai3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_sai3>;
-- 
2.25.1

[PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Richard Zhu]

Add the PCIe PHY support on iMX8MM EVK boards.
And set the default reference clock mode.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index e033d0257b5a..2d0684ac82f6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/phy/phy-imx8-pcie.h>
 #include <dt-bindings/usb/pd.h>
 #include "imx8mm.dtsi"
 
@@ -289,6 +290,12 @@ pca6416: gpio@20 {
 	};
 };
 
+&pcie_phy {
+	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+	clocks = <&clk IMX8MM_CLK_DUMMY>;
+	status = "okay";
+};
+
 &sai3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_sai3>;
-- 
2.25.1


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

[PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Richard Zhu]

Add the PCIe PHY support on iMX8MM EVK boards.
And set the default reference clock mode.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index e033d0257b5a..2d0684ac82f6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/phy/phy-imx8-pcie.h>
 #include <dt-bindings/usb/pd.h>
 #include "imx8mm.dtsi"
 
@@ -289,6 +290,12 @@ pca6416: gpio@20 {
 	};
 };
 
+&pcie_phy {
+	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+	clocks = <&clk IMX8MM_CLK_DUMMY>;
+	status = "okay";
+};
+
 &sai3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_sai3>;
-- 
2.25.1


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

Re: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe PHY support on iMX8MM EVK boards.
> And set the default reference clock mode.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index e033d0257b5a..2d0684ac82f6 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -5,6 +5,7 @@
>  
>  /dts-v1/;
>  
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
>  #include <dt-bindings/usb/pd.h>
>  #include "imx8mm.dtsi"
>  
> @@ -289,6 +290,12 @@ pca6416: gpio@20 {
>  	};
>  };
>  
> +&pcie_phy {
> +	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +	clocks = <&clk IMX8MM_CLK_DUMMY>;

Please add a fixed clock DT node for the external clock generator and
use this one instead of the dummy clock here.

Regards,
Lucas

> +	status = "okay";
> +};
> +
>  &sai3 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_sai3>;

Re: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe PHY support on iMX8MM EVK boards.
> And set the default reference clock mode.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index e033d0257b5a..2d0684ac82f6 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -5,6 +5,7 @@
>  
>  /dts-v1/;
>  
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
>  #include <dt-bindings/usb/pd.h>
>  #include "imx8mm.dtsi"
>  
> @@ -289,6 +290,12 @@ pca6416: gpio@20 {
>  	};
>  };
>  
> +&pcie_phy {
> +	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +	clocks = <&clk IMX8MM_CLK_DUMMY>;

Please add a fixed clock DT node for the external clock generator and
use this one instead of the dummy clock here.

Regards,
Lucas

> +	status = "okay";
> +};
> +
>  &sai3 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_sai3>;



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

Re: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe PHY support on iMX8MM EVK boards.
> And set the default reference clock mode.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index e033d0257b5a..2d0684ac82f6 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -5,6 +5,7 @@
>  
>  /dts-v1/;
>  
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
>  #include <dt-bindings/usb/pd.h>
>  #include "imx8mm.dtsi"
>  
> @@ -289,6 +290,12 @@ pca6416: gpio@20 {
>  	};
>  };
>  
> +&pcie_phy {
> +	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +	clocks = <&clk IMX8MM_CLK_DUMMY>;

Please add a fixed clock DT node for the external clock generator and
use this one instead of the dummy clock here.

Regards,
Lucas

> +	status = "okay";
> +};
> +
>  &sai3 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_sai3>;



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

RE: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:33 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe PHY support on iMX8MM EVK boards.
> > And set the default reference clock mode.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index e033d0257b5a..2d0684ac82f6 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -5,6 +5,7 @@
> >
> >  /dts-v1/;
> >
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> >  #include <dt-bindings/usb/pd.h>
> >  #include "imx8mm.dtsi"
> >
> > @@ -289,6 +290,12 @@ pca6416: gpio@20 {
> >  	};
> >  };
> >
> > +&pcie_phy {
> > +	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> > +	clocks = <&clk IMX8MM_CLK_DUMMY>;
> 
> Please add a fixed clock DT node for the external clock generator and use this
> one instead of the dummy clock here.
[Richard Zhu] Would be changed, and squashed to 8# patch of this series. Thanks.

Best Regards
Richard Zhu

> 
> Regards,
> Lucas
> 
> > +	status = "okay";
> > +};
> > +
> >  &sai3 {
> >  	pinctrl-names = "default";
> >  	pinctrl-0 = <&pinctrl_sai3>;
> 

RE: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:33 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe PHY support on iMX8MM EVK boards.
> > And set the default reference clock mode.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index e033d0257b5a..2d0684ac82f6 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -5,6 +5,7 @@
> >
> >  /dts-v1/;
> >
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> >  #include <dt-bindings/usb/pd.h>
> >  #include "imx8mm.dtsi"
> >
> > @@ -289,6 +290,12 @@ pca6416: gpio@20 {
> >  	};
> >  };
> >
> > +&pcie_phy {
> > +	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> > +	clocks = <&clk IMX8MM_CLK_DUMMY>;
> 
> Please add a fixed clock DT node for the external clock generator and use this
> one instead of the dummy clock here.
[Richard Zhu] Would be changed, and squashed to 8# patch of this series. Thanks.

Best Regards
Richard Zhu

> 
> Regards,
> Lucas
> 
> > +	status = "okay";
> > +};
> > +
> >  &sai3 {
> >  	pinctrl-names = "default";
> >  	pinctrl-0 = <&pinctrl_sai3>;
> 

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

RE: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:33 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe PHY support on iMX8MM EVK boards.
> > And set the default reference clock mode.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index e033d0257b5a..2d0684ac82f6 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -5,6 +5,7 @@
> >
> >  /dts-v1/;
> >
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> >  #include <dt-bindings/usb/pd.h>
> >  #include "imx8mm.dtsi"
> >
> > @@ -289,6 +290,12 @@ pca6416: gpio@20 {
> >  	};
> >  };
> >
> > +&pcie_phy {
> > +	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> > +	clocks = <&clk IMX8MM_CLK_DUMMY>;
> 
> Please add a fixed clock DT node for the external clock generator and use this
> one instead of the dummy clock here.
[Richard Zhu] Would be changed, and squashed to 8# patch of this series. Thanks.

Best Regards
Richard Zhu

> 
> Regards,
> Lucas
> 
> > +	status = "okay";
> > +};
> > +
> >  &sai3 {
> >  	pinctrl-names = "default";
> >  	pinctrl-0 = <&pinctrl_sai3>;
> 

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

[PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

Add the standalone i.MX8 PCIe PHY driver.
Some reset bits should be manipulated between PHY configurations and
status check(internal PLL is locked or not).
So, do the PHY configuration in the phy_calibrate().
And check the PHY is ready or not in the phy_init().

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 drivers/phy/freescale/Kconfig              |   9 +
 drivers/phy/freescale/Makefile             |   1 +
 drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
 3 files changed, 228 insertions(+)
 create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 320630ffe3cd..fb08e5242602 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
 	help
 	  Enable this to add support for the Mixel DSI PHY as found
 	  on NXP's i.MX8 family of SOCs.
+
+config PHY_FSL_IMX8M_PCIE
+	tristate "Freescale i.MX8 PCIE PHY"
+	depends on OF && HAS_IOMEM
+	select GENERIC_PHY
+	default ARCH_MXC
+	help
+	  Enable this to add support for the PCIE PHY as found on
+	  i.MX8M family of SOCs.
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index 1d02e3869b45..55d07c742ab0 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
 obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
+obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
new file mode 100644
index 000000000000..317cf61bff37
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/delay.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
+#include <linux/module.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+
+#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
+#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
+#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
+#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
+#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
+#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
+#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
+#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
+#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
+#define  ANA_AUX_TX_TERM		BIT(2)
+#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
+#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
+#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
+#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
+#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
+#define PCIE_PHY_TRSV_REG5		0x414
+#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
+#define PCIE_PHY_TRSV_REG6		0x418
+#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
+
+#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
+#define IMX8MM_GPR_PCIE_REF_CLK_PLL	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
+#define IMX8MM_GPR_PCIE_REF_CLK_EXT	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
+#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
+#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
+#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
+#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
+#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
+
+struct imx8_pcie_phy {
+	u32			refclk_pad_mode;
+	void __iomem		*base;
+	struct clk		*clk;
+	struct phy		*phy;
+	struct regmap		*iomuxc_gpr;
+	struct reset_control	*reset;
+};
+
+static int imx8_pcie_phy_init(struct phy *phy)
+{
+	int ret;
+	u32 val, pad_mode;
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	reset_control_assert(imx8_phy->reset);
+
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_REF_USE_PAD,
+			   imx8_phy->refclk_pad_mode == 1 ?
+			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_AUX_EN,
+			   IMX8MM_GPR_PCIE_AUX_EN);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_SSC_EN, 0);
+
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
+			   imx8_phy->refclk_pad_mode == 1 ?
+			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
+			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
+	usleep_range(100, 200);
+
+	/* Do the PHY common block reset */
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_CMN_RST,
+			   IMX8MM_GPR_PCIE_CMN_RST);
+	usleep_range(200, 500);
+
+
+	pad_mode = imx8_phy->refclk_pad_mode;
+	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
+		/* Configure the pad as input */
+		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
+		/* Configure the PHY to output the refclock via pad */
+		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
+		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
+		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
+		writel(val | ANA_AUX_RX_TERM_GND_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
+		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
+	}
+
+	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
+	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
+	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
+	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
+	       imx8_phy->base + PCIE_PHY_TRSV_REG6);
+
+	reset_control_deassert(imx8_phy->reset);
+
+	/* Polling to check the phy is ready or not. */
+	ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
+				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
+				 10, 20000);
+	return ret;
+}
+
+static int imx8_pcie_phy_power_on(struct phy *phy)
+{
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	return clk_prepare_enable(imx8_phy->clk);
+}
+
+static int imx8_pcie_phy_power_off(struct phy *phy)
+{
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	clk_disable_unprepare(imx8_phy->clk);
+
+	return 0;
+}
+
+static const struct phy_ops imx8_pcie_phy_ops = {
+	.init		= imx8_pcie_phy_init,
+	.power_on	= imx8_pcie_phy_power_on,
+	.power_off	= imx8_pcie_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int imx8_pcie_phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct imx8_pcie_phy *imx8_phy;
+	struct resource *res;
+
+	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
+	if (!imx8_phy)
+		return -ENOMEM;
+
+	/* get PHY refclk pad mode */
+	of_property_read_u32(np, "fsl,refclk-pad-mode",
+			     &imx8_phy->refclk_pad_mode);
+
+	imx8_phy->clk = devm_clk_get(dev, "phy");
+	if (IS_ERR(imx8_phy->clk)) {
+		dev_err(dev, "failed to get imx pcie phy clock\n");
+		return PTR_ERR(imx8_phy->clk);
+	}
+
+	/* Grab GPR config register range */
+	imx8_phy->iomuxc_gpr =
+		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
+	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
+		dev_err(dev, "unable to find iomuxc registers\n");
+		return PTR_ERR(imx8_phy->iomuxc_gpr);
+	}
+
+	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
+	if (IS_ERR(imx8_phy->reset)) {
+		dev_err(dev, "Failed to get PCIEPHY reset control\n");
+		return PTR_ERR(imx8_phy->reset);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	imx8_phy->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(imx8_phy->base))
+		return PTR_ERR(imx8_phy->base);
+
+	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
+	if (IS_ERR(imx8_phy->phy))
+		return PTR_ERR(imx8_phy->phy);
+
+	phy_set_drvdata(imx8_phy->phy, imx8_phy);
+
+	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 imx8_pcie_phy_of_match[] = {
+	{.compatible = "fsl,imx8mm-pcie-phy",},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
+
+static struct platform_driver imx8_pcie_phy_driver = {
+	.probe	= imx8_pcie_phy_probe,
+	.driver = {
+		.name	= "imx8-pcie-phy",
+		.of_match_table	= imx8_pcie_phy_of_match,
+	}
+};
+module_platform_driver(imx8_pcie_phy_driver);
+
+MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1

[PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

Add the standalone i.MX8 PCIe PHY driver.
Some reset bits should be manipulated between PHY configurations and
status check(internal PLL is locked or not).
So, do the PHY configuration in the phy_calibrate().
And check the PHY is ready or not in the phy_init().

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 drivers/phy/freescale/Kconfig              |   9 +
 drivers/phy/freescale/Makefile             |   1 +
 drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
 3 files changed, 228 insertions(+)
 create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 320630ffe3cd..fb08e5242602 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
 	help
 	  Enable this to add support for the Mixel DSI PHY as found
 	  on NXP's i.MX8 family of SOCs.
+
+config PHY_FSL_IMX8M_PCIE
+	tristate "Freescale i.MX8 PCIE PHY"
+	depends on OF && HAS_IOMEM
+	select GENERIC_PHY
+	default ARCH_MXC
+	help
+	  Enable this to add support for the PCIE PHY as found on
+	  i.MX8M family of SOCs.
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index 1d02e3869b45..55d07c742ab0 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
 obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
+obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
new file mode 100644
index 000000000000..317cf61bff37
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/delay.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
+#include <linux/module.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+
+#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
+#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
+#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
+#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
+#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
+#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
+#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
+#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
+#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
+#define  ANA_AUX_TX_TERM		BIT(2)
+#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
+#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
+#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
+#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
+#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
+#define PCIE_PHY_TRSV_REG5		0x414
+#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
+#define PCIE_PHY_TRSV_REG6		0x418
+#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
+
+#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
+#define IMX8MM_GPR_PCIE_REF_CLK_PLL	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
+#define IMX8MM_GPR_PCIE_REF_CLK_EXT	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
+#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
+#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
+#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
+#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
+#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
+
+struct imx8_pcie_phy {
+	u32			refclk_pad_mode;
+	void __iomem		*base;
+	struct clk		*clk;
+	struct phy		*phy;
+	struct regmap		*iomuxc_gpr;
+	struct reset_control	*reset;
+};
+
+static int imx8_pcie_phy_init(struct phy *phy)
+{
+	int ret;
+	u32 val, pad_mode;
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	reset_control_assert(imx8_phy->reset);
+
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_REF_USE_PAD,
+			   imx8_phy->refclk_pad_mode == 1 ?
+			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_AUX_EN,
+			   IMX8MM_GPR_PCIE_AUX_EN);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_SSC_EN, 0);
+
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
+			   imx8_phy->refclk_pad_mode == 1 ?
+			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
+			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
+	usleep_range(100, 200);
+
+	/* Do the PHY common block reset */
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_CMN_RST,
+			   IMX8MM_GPR_PCIE_CMN_RST);
+	usleep_range(200, 500);
+
+
+	pad_mode = imx8_phy->refclk_pad_mode;
+	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
+		/* Configure the pad as input */
+		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
+		/* Configure the PHY to output the refclock via pad */
+		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
+		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
+		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
+		writel(val | ANA_AUX_RX_TERM_GND_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
+		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
+	}
+
+	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
+	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
+	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
+	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
+	       imx8_phy->base + PCIE_PHY_TRSV_REG6);
+
+	reset_control_deassert(imx8_phy->reset);
+
+	/* Polling to check the phy is ready or not. */
+	ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
+				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
+				 10, 20000);
+	return ret;
+}
+
+static int imx8_pcie_phy_power_on(struct phy *phy)
+{
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	return clk_prepare_enable(imx8_phy->clk);
+}
+
+static int imx8_pcie_phy_power_off(struct phy *phy)
+{
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	clk_disable_unprepare(imx8_phy->clk);
+
+	return 0;
+}
+
+static const struct phy_ops imx8_pcie_phy_ops = {
+	.init		= imx8_pcie_phy_init,
+	.power_on	= imx8_pcie_phy_power_on,
+	.power_off	= imx8_pcie_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int imx8_pcie_phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct imx8_pcie_phy *imx8_phy;
+	struct resource *res;
+
+	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
+	if (!imx8_phy)
+		return -ENOMEM;
+
+	/* get PHY refclk pad mode */
+	of_property_read_u32(np, "fsl,refclk-pad-mode",
+			     &imx8_phy->refclk_pad_mode);
+
+	imx8_phy->clk = devm_clk_get(dev, "phy");
+	if (IS_ERR(imx8_phy->clk)) {
+		dev_err(dev, "failed to get imx pcie phy clock\n");
+		return PTR_ERR(imx8_phy->clk);
+	}
+
+	/* Grab GPR config register range */
+	imx8_phy->iomuxc_gpr =
+		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
+	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
+		dev_err(dev, "unable to find iomuxc registers\n");
+		return PTR_ERR(imx8_phy->iomuxc_gpr);
+	}
+
+	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
+	if (IS_ERR(imx8_phy->reset)) {
+		dev_err(dev, "Failed to get PCIEPHY reset control\n");
+		return PTR_ERR(imx8_phy->reset);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	imx8_phy->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(imx8_phy->base))
+		return PTR_ERR(imx8_phy->base);
+
+	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
+	if (IS_ERR(imx8_phy->phy))
+		return PTR_ERR(imx8_phy->phy);
+
+	phy_set_drvdata(imx8_phy->phy, imx8_phy);
+
+	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 imx8_pcie_phy_of_match[] = {
+	{.compatible = "fsl,imx8mm-pcie-phy",},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
+
+static struct platform_driver imx8_pcie_phy_driver = {
+	.probe	= imx8_pcie_phy_probe,
+	.driver = {
+		.name	= "imx8-pcie-phy",
+		.of_match_table	= imx8_pcie_phy_of_match,
+	}
+};
+module_platform_driver(imx8_pcie_phy_driver);
+
+MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1


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

[PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

Add the standalone i.MX8 PCIe PHY driver.
Some reset bits should be manipulated between PHY configurations and
status check(internal PLL is locked or not).
So, do the PHY configuration in the phy_calibrate().
And check the PHY is ready or not in the phy_init().

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 drivers/phy/freescale/Kconfig              |   9 +
 drivers/phy/freescale/Makefile             |   1 +
 drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
 3 files changed, 228 insertions(+)
 create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 320630ffe3cd..fb08e5242602 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
 	help
 	  Enable this to add support for the Mixel DSI PHY as found
 	  on NXP's i.MX8 family of SOCs.
+
+config PHY_FSL_IMX8M_PCIE
+	tristate "Freescale i.MX8 PCIE PHY"
+	depends on OF && HAS_IOMEM
+	select GENERIC_PHY
+	default ARCH_MXC
+	help
+	  Enable this to add support for the PCIE PHY as found on
+	  i.MX8M family of SOCs.
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index 1d02e3869b45..55d07c742ab0 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
 obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
+obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
new file mode 100644
index 000000000000..317cf61bff37
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/delay.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
+#include <linux/module.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+
+#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
+#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
+#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
+#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
+#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
+#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
+#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
+#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
+#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
+#define  ANA_AUX_TX_TERM		BIT(2)
+#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
+#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
+#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
+#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
+#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
+#define PCIE_PHY_TRSV_REG5		0x414
+#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
+#define PCIE_PHY_TRSV_REG6		0x418
+#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
+
+#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
+#define IMX8MM_GPR_PCIE_REF_CLK_PLL	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
+#define IMX8MM_GPR_PCIE_REF_CLK_EXT	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
+#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
+#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
+#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
+#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
+#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
+
+struct imx8_pcie_phy {
+	u32			refclk_pad_mode;
+	void __iomem		*base;
+	struct clk		*clk;
+	struct phy		*phy;
+	struct regmap		*iomuxc_gpr;
+	struct reset_control	*reset;
+};
+
+static int imx8_pcie_phy_init(struct phy *phy)
+{
+	int ret;
+	u32 val, pad_mode;
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	reset_control_assert(imx8_phy->reset);
+
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_REF_USE_PAD,
+			   imx8_phy->refclk_pad_mode == 1 ?
+			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_AUX_EN,
+			   IMX8MM_GPR_PCIE_AUX_EN);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_SSC_EN, 0);
+
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
+			   imx8_phy->refclk_pad_mode == 1 ?
+			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
+			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
+	usleep_range(100, 200);
+
+	/* Do the PHY common block reset */
+	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
+			   IMX8MM_GPR_PCIE_CMN_RST,
+			   IMX8MM_GPR_PCIE_CMN_RST);
+	usleep_range(200, 500);
+
+
+	pad_mode = imx8_phy->refclk_pad_mode;
+	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
+		/* Configure the pad as input */
+		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
+		/* Configure the PHY to output the refclock via pad */
+		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
+		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
+		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
+		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
+		writel(val | ANA_AUX_RX_TERM_GND_EN,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
+		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
+		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
+	}
+
+	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
+	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
+	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
+	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
+	       imx8_phy->base + PCIE_PHY_TRSV_REG6);
+
+	reset_control_deassert(imx8_phy->reset);
+
+	/* Polling to check the phy is ready or not. */
+	ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
+				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
+				 10, 20000);
+	return ret;
+}
+
+static int imx8_pcie_phy_power_on(struct phy *phy)
+{
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	return clk_prepare_enable(imx8_phy->clk);
+}
+
+static int imx8_pcie_phy_power_off(struct phy *phy)
+{
+	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
+
+	clk_disable_unprepare(imx8_phy->clk);
+
+	return 0;
+}
+
+static const struct phy_ops imx8_pcie_phy_ops = {
+	.init		= imx8_pcie_phy_init,
+	.power_on	= imx8_pcie_phy_power_on,
+	.power_off	= imx8_pcie_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int imx8_pcie_phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct imx8_pcie_phy *imx8_phy;
+	struct resource *res;
+
+	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
+	if (!imx8_phy)
+		return -ENOMEM;
+
+	/* get PHY refclk pad mode */
+	of_property_read_u32(np, "fsl,refclk-pad-mode",
+			     &imx8_phy->refclk_pad_mode);
+
+	imx8_phy->clk = devm_clk_get(dev, "phy");
+	if (IS_ERR(imx8_phy->clk)) {
+		dev_err(dev, "failed to get imx pcie phy clock\n");
+		return PTR_ERR(imx8_phy->clk);
+	}
+
+	/* Grab GPR config register range */
+	imx8_phy->iomuxc_gpr =
+		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
+	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
+		dev_err(dev, "unable to find iomuxc registers\n");
+		return PTR_ERR(imx8_phy->iomuxc_gpr);
+	}
+
+	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
+	if (IS_ERR(imx8_phy->reset)) {
+		dev_err(dev, "Failed to get PCIEPHY reset control\n");
+		return PTR_ERR(imx8_phy->reset);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	imx8_phy->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(imx8_phy->base))
+		return PTR_ERR(imx8_phy->base);
+
+	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
+	if (IS_ERR(imx8_phy->phy))
+		return PTR_ERR(imx8_phy->phy);
+
+	phy_set_drvdata(imx8_phy->phy, imx8_phy);
+
+	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 imx8_pcie_phy_of_match[] = {
+	{.compatible = "fsl,imx8mm-pcie-phy",},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
+
+static struct platform_driver imx8_pcie_phy_driver = {
+	.probe	= imx8_pcie_phy_probe,
+	.driver = {
+		.name	= "imx8-pcie-phy",
+		.of_match_table	= imx8_pcie_phy_of_match,
+	}
+};
+module_platform_driver(imx8_pcie_phy_driver);
+
+MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1


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

Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the standalone i.MX8 PCIe PHY driver.
> Some reset bits should be manipulated between PHY configurations and
> status check(internal PLL is locked or not).
> So, do the PHY configuration in the phy_calibrate().
> And check the PHY is ready or not in the phy_init().
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/phy/freescale/Kconfig              |   9 +
>  drivers/phy/freescale/Makefile             |   1 +
>  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
>  3 files changed, 228 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> 
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 320630ffe3cd..fb08e5242602 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
>  	help
>  	  Enable this to add support for the Mixel DSI PHY as found
>  	  on NXP's i.MX8 family of SOCs.
> +
> +config PHY_FSL_IMX8M_PCIE
> +	tristate "Freescale i.MX8 PCIE PHY"
> +	depends on OF && HAS_IOMEM
> +	select GENERIC_PHY
> +	default ARCH_MXC

Not sure if we need this default, but if you want to keep it add at
least a "&& ARM64" to not enable it on old 32bit i.MX SoCs.

> +	help
> +	  Enable this to add support for the PCIE PHY as found on
> +	  i.MX8M family of SOCs.
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index 1d02e3869b45..55d07c742ab0 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
> +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> new file mode 100644
> index 000000000000..317cf61bff37
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -0,0 +1,218 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> +
> +#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
> +#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
> +#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
> +#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
> +#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
> +#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
> +#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
> +#define  ANA_AUX_TX_TERM		BIT(2)
> +#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
> +#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
> +#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
> +#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
> +#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
> +#define PCIE_PHY_TRSV_REG5		0x414
> +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
> +#define PCIE_PHY_TRSV_REG6		0x418
> +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
> +
> +#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
> +#define IMX8MM_GPR_PCIE_REF_CLK_PLL	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> +#define IMX8MM_GPR_PCIE_REF_CLK_EXT	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> +#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
> +#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
> +#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
> +#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
> +#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
> +
> +struct imx8_pcie_phy {
> +	u32			refclk_pad_mode;

Moving this to the end of the structure will get rid of a hole due to
padding.

> +	void __iomem		*base;
> +	struct clk		*clk;
> +	struct phy		*phy;
> +	struct regmap		*iomuxc_gpr;
> +	struct reset_control	*reset;
> +};
> +
> +static int imx8_pcie_phy_init(struct phy *phy)
> +{
> +	int ret;
> +	u32 val, pad_mode;
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	reset_control_assert(imx8_phy->reset);
> +
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_REF_USE_PAD,
> +			   imx8_phy->refclk_pad_mode == 1 ?
> +			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_AUX_EN,
> +			   IMX8MM_GPR_PCIE_AUX_EN);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_SSC_EN, 0);
> +
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
> +			   imx8_phy->refclk_pad_mode == 1 ?
> +			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
> +			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
> +	usleep_range(100, 200);
> +
> +	/* Do the PHY common block reset */
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_CMN_RST,
> +			   IMX8MM_GPR_PCIE_CMN_RST);
> +	usleep_range(200, 500);
> +
> +
> +	pad_mode = imx8_phy->refclk_pad_mode;
> +	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> +		/* Configure the pad as input */
> +		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> +		/* Configure the PHY to output the refclock via pad */
> +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> +		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> +		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> +		writel(val | ANA_AUX_RX_TERM_GND_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> +		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> +	}
> +
> +	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
> +	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> +	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
> +	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> +	       imx8_phy->base + PCIE_PHY_TRSV_REG6);

I guess those are at least in part board specific. Maybe it would be a
good idea to add DT properties to allow each board to specify the
actual de-emphasis values?

> +
> +	reset_control_deassert(imx8_phy->reset);
> +
> +	/* Polling to check the phy is ready or not. */
> +	ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
> +				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> +				 10, 20000);
> +	return ret;
> +}
> +
> +static int imx8_pcie_phy_power_on(struct phy *phy)
> +{
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	return clk_prepare_enable(imx8_phy->clk);
> +}
> +
> +static int imx8_pcie_phy_power_off(struct phy *phy)
> +{
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	clk_disable_unprepare(imx8_phy->clk);
> +
> +	return 0;
> +}
> +
> +static const struct phy_ops imx8_pcie_phy_ops = {
> +	.init		= imx8_pcie_phy_init,
> +	.power_on	= imx8_pcie_phy_power_on,
> +	.power_off	= imx8_pcie_phy_power_off,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int imx8_pcie_phy_probe(struct platform_device *pdev)
> +{
> +	struct phy_provider *phy_provider;
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct imx8_pcie_phy *imx8_phy;
> +	struct resource *res;
> +
> +	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> +	if (!imx8_phy)
> +		return -ENOMEM;
> +
> +	/* get PHY refclk pad mode */
> +	of_property_read_u32(np, "fsl,refclk-pad-mode",
> +			     &imx8_phy->refclk_pad_mode);
> +
> +	imx8_phy->clk = devm_clk_get(dev, "phy");
> +	if (IS_ERR(imx8_phy->clk)) {
> +		dev_err(dev, "failed to get imx pcie phy clock\n");
> +		return PTR_ERR(imx8_phy->clk);
> +	}
> +
> +	/* Grab GPR config register range */
> +	imx8_phy->iomuxc_gpr =
> +		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");

I would prefer if we could get the syscon via a phandle and make the
GPR register to use another cell of the handle.

That's not really important for the 8MM, where there is only one PCIe
PHY, but if we want to retrofit this model to the i.MX8MQ, we need to
deal with different GPR offsets for both PHYs and I would like to have
this explicit in the DT. Doing the same here would be good for
consistency.

Overall, looks much better than the last submission.

Regards,
Lucas

> +	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> +		dev_err(dev, "unable to find iomuxc registers\n");
> +		return PTR_ERR(imx8_phy->iomuxc_gpr);
> +	}
> +
> +	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> +	if (IS_ERR(imx8_phy->reset)) {
> +		dev_err(dev, "Failed to get PCIEPHY reset control\n");
> +		return PTR_ERR(imx8_phy->reset);
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	imx8_phy->base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(imx8_phy->base))
> +		return PTR_ERR(imx8_phy->base);
> +
> +	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> +	if (IS_ERR(imx8_phy->phy))
> +		return PTR_ERR(imx8_phy->phy);
> +
> +	phy_set_drvdata(imx8_phy->phy, imx8_phy);
> +
> +	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 imx8_pcie_phy_of_match[] = {
> +	{.compatible = "fsl,imx8mm-pcie-phy",},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> +
> +static struct platform_driver imx8_pcie_phy_driver = {
> +	.probe	= imx8_pcie_phy_probe,
> +	.driver = {
> +		.name	= "imx8-pcie-phy",
> +		.of_match_table	= imx8_pcie_phy_of_match,
> +	}
> +};
> +module_platform_driver(imx8_pcie_phy_driver);
> +
> +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> +MODULE_LICENSE("GPL");

Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the standalone i.MX8 PCIe PHY driver.
> Some reset bits should be manipulated between PHY configurations and
> status check(internal PLL is locked or not).
> So, do the PHY configuration in the phy_calibrate().
> And check the PHY is ready or not in the phy_init().
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/phy/freescale/Kconfig              |   9 +
>  drivers/phy/freescale/Makefile             |   1 +
>  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
>  3 files changed, 228 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> 
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 320630ffe3cd..fb08e5242602 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
>  	help
>  	  Enable this to add support for the Mixel DSI PHY as found
>  	  on NXP's i.MX8 family of SOCs.
> +
> +config PHY_FSL_IMX8M_PCIE
> +	tristate "Freescale i.MX8 PCIE PHY"
> +	depends on OF && HAS_IOMEM
> +	select GENERIC_PHY
> +	default ARCH_MXC

Not sure if we need this default, but if you want to keep it add at
least a "&& ARM64" to not enable it on old 32bit i.MX SoCs.

> +	help
> +	  Enable this to add support for the PCIE PHY as found on
> +	  i.MX8M family of SOCs.
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index 1d02e3869b45..55d07c742ab0 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
> +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> new file mode 100644
> index 000000000000..317cf61bff37
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -0,0 +1,218 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> +
> +#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
> +#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
> +#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
> +#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
> +#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
> +#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
> +#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
> +#define  ANA_AUX_TX_TERM		BIT(2)
> +#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
> +#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
> +#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
> +#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
> +#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
> +#define PCIE_PHY_TRSV_REG5		0x414
> +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
> +#define PCIE_PHY_TRSV_REG6		0x418
> +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
> +
> +#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
> +#define IMX8MM_GPR_PCIE_REF_CLK_PLL	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> +#define IMX8MM_GPR_PCIE_REF_CLK_EXT	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> +#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
> +#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
> +#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
> +#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
> +#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
> +
> +struct imx8_pcie_phy {
> +	u32			refclk_pad_mode;

Moving this to the end of the structure will get rid of a hole due to
padding.

> +	void __iomem		*base;
> +	struct clk		*clk;
> +	struct phy		*phy;
> +	struct regmap		*iomuxc_gpr;
> +	struct reset_control	*reset;
> +};
> +
> +static int imx8_pcie_phy_init(struct phy *phy)
> +{
> +	int ret;
> +	u32 val, pad_mode;
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	reset_control_assert(imx8_phy->reset);
> +
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_REF_USE_PAD,
> +			   imx8_phy->refclk_pad_mode == 1 ?
> +			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_AUX_EN,
> +			   IMX8MM_GPR_PCIE_AUX_EN);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_SSC_EN, 0);
> +
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
> +			   imx8_phy->refclk_pad_mode == 1 ?
> +			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
> +			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
> +	usleep_range(100, 200);
> +
> +	/* Do the PHY common block reset */
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_CMN_RST,
> +			   IMX8MM_GPR_PCIE_CMN_RST);
> +	usleep_range(200, 500);
> +
> +
> +	pad_mode = imx8_phy->refclk_pad_mode;
> +	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> +		/* Configure the pad as input */
> +		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> +		/* Configure the PHY to output the refclock via pad */
> +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> +		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> +		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> +		writel(val | ANA_AUX_RX_TERM_GND_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> +		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> +	}
> +
> +	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
> +	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> +	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
> +	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> +	       imx8_phy->base + PCIE_PHY_TRSV_REG6);

I guess those are at least in part board specific. Maybe it would be a
good idea to add DT properties to allow each board to specify the
actual de-emphasis values?

> +
> +	reset_control_deassert(imx8_phy->reset);
> +
> +	/* Polling to check the phy is ready or not. */
> +	ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
> +				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> +				 10, 20000);
> +	return ret;
> +}
> +
> +static int imx8_pcie_phy_power_on(struct phy *phy)
> +{
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	return clk_prepare_enable(imx8_phy->clk);
> +}
> +
> +static int imx8_pcie_phy_power_off(struct phy *phy)
> +{
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	clk_disable_unprepare(imx8_phy->clk);
> +
> +	return 0;
> +}
> +
> +static const struct phy_ops imx8_pcie_phy_ops = {
> +	.init		= imx8_pcie_phy_init,
> +	.power_on	= imx8_pcie_phy_power_on,
> +	.power_off	= imx8_pcie_phy_power_off,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int imx8_pcie_phy_probe(struct platform_device *pdev)
> +{
> +	struct phy_provider *phy_provider;
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct imx8_pcie_phy *imx8_phy;
> +	struct resource *res;
> +
> +	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> +	if (!imx8_phy)
> +		return -ENOMEM;
> +
> +	/* get PHY refclk pad mode */
> +	of_property_read_u32(np, "fsl,refclk-pad-mode",
> +			     &imx8_phy->refclk_pad_mode);
> +
> +	imx8_phy->clk = devm_clk_get(dev, "phy");
> +	if (IS_ERR(imx8_phy->clk)) {
> +		dev_err(dev, "failed to get imx pcie phy clock\n");
> +		return PTR_ERR(imx8_phy->clk);
> +	}
> +
> +	/* Grab GPR config register range */
> +	imx8_phy->iomuxc_gpr =
> +		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");

I would prefer if we could get the syscon via a phandle and make the
GPR register to use another cell of the handle.

That's not really important for the 8MM, where there is only one PCIe
PHY, but if we want to retrofit this model to the i.MX8MQ, we need to
deal with different GPR offsets for both PHYs and I would like to have
this explicit in the DT. Doing the same here would be good for
consistency.

Overall, looks much better than the last submission.

Regards,
Lucas

> +	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> +		dev_err(dev, "unable to find iomuxc registers\n");
> +		return PTR_ERR(imx8_phy->iomuxc_gpr);
> +	}
> +
> +	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> +	if (IS_ERR(imx8_phy->reset)) {
> +		dev_err(dev, "Failed to get PCIEPHY reset control\n");
> +		return PTR_ERR(imx8_phy->reset);
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	imx8_phy->base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(imx8_phy->base))
> +		return PTR_ERR(imx8_phy->base);
> +
> +	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> +	if (IS_ERR(imx8_phy->phy))
> +		return PTR_ERR(imx8_phy->phy);
> +
> +	phy_set_drvdata(imx8_phy->phy, imx8_phy);
> +
> +	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 imx8_pcie_phy_of_match[] = {
> +	{.compatible = "fsl,imx8mm-pcie-phy",},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> +
> +static struct platform_driver imx8_pcie_phy_driver = {
> +	.probe	= imx8_pcie_phy_probe,
> +	.driver = {
> +		.name	= "imx8-pcie-phy",
> +		.of_match_table	= imx8_pcie_phy_of_match,
> +	}
> +};
> +module_platform_driver(imx8_pcie_phy_driver);
> +
> +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> +MODULE_LICENSE("GPL");



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

Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the standalone i.MX8 PCIe PHY driver.
> Some reset bits should be manipulated between PHY configurations and
> status check(internal PLL is locked or not).
> So, do the PHY configuration in the phy_calibrate().
> And check the PHY is ready or not in the phy_init().
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/phy/freescale/Kconfig              |   9 +
>  drivers/phy/freescale/Makefile             |   1 +
>  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
>  3 files changed, 228 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> 
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 320630ffe3cd..fb08e5242602 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
>  	help
>  	  Enable this to add support for the Mixel DSI PHY as found
>  	  on NXP's i.MX8 family of SOCs.
> +
> +config PHY_FSL_IMX8M_PCIE
> +	tristate "Freescale i.MX8 PCIE PHY"
> +	depends on OF && HAS_IOMEM
> +	select GENERIC_PHY
> +	default ARCH_MXC

Not sure if we need this default, but if you want to keep it add at
least a "&& ARM64" to not enable it on old 32bit i.MX SoCs.

> +	help
> +	  Enable this to add support for the PCIE PHY as found on
> +	  i.MX8M family of SOCs.
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index 1d02e3869b45..55d07c742ab0 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
> +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> new file mode 100644
> index 000000000000..317cf61bff37
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -0,0 +1,218 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> +
> +#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
> +#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
> +#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
> +#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
> +#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
> +#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
> +#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
> +#define  ANA_AUX_TX_TERM		BIT(2)
> +#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
> +#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
> +#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
> +#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
> +#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
> +#define PCIE_PHY_TRSV_REG5		0x414
> +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
> +#define PCIE_PHY_TRSV_REG6		0x418
> +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
> +
> +#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
> +#define IMX8MM_GPR_PCIE_REF_CLK_PLL	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> +#define IMX8MM_GPR_PCIE_REF_CLK_EXT	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> +#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
> +#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
> +#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
> +#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
> +#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
> +
> +struct imx8_pcie_phy {
> +	u32			refclk_pad_mode;

Moving this to the end of the structure will get rid of a hole due to
padding.

> +	void __iomem		*base;
> +	struct clk		*clk;
> +	struct phy		*phy;
> +	struct regmap		*iomuxc_gpr;
> +	struct reset_control	*reset;
> +};
> +
> +static int imx8_pcie_phy_init(struct phy *phy)
> +{
> +	int ret;
> +	u32 val, pad_mode;
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	reset_control_assert(imx8_phy->reset);
> +
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_REF_USE_PAD,
> +			   imx8_phy->refclk_pad_mode == 1 ?
> +			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_AUX_EN,
> +			   IMX8MM_GPR_PCIE_AUX_EN);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_SSC_EN, 0);
> +
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
> +			   imx8_phy->refclk_pad_mode == 1 ?
> +			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
> +			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
> +	usleep_range(100, 200);
> +
> +	/* Do the PHY common block reset */
> +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +			   IMX8MM_GPR_PCIE_CMN_RST,
> +			   IMX8MM_GPR_PCIE_CMN_RST);
> +	usleep_range(200, 500);
> +
> +
> +	pad_mode = imx8_phy->refclk_pad_mode;
> +	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> +		/* Configure the pad as input */
> +		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> +		/* Configure the PHY to output the refclock via pad */
> +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> +		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> +		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> +		writel(val | ANA_AUX_RX_TERM_GND_EN,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> +		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> +	}
> +
> +	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
> +	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> +	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
> +	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> +	       imx8_phy->base + PCIE_PHY_TRSV_REG6);

I guess those are at least in part board specific. Maybe it would be a
good idea to add DT properties to allow each board to specify the
actual de-emphasis values?

> +
> +	reset_control_deassert(imx8_phy->reset);
> +
> +	/* Polling to check the phy is ready or not. */
> +	ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
> +				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> +				 10, 20000);
> +	return ret;
> +}
> +
> +static int imx8_pcie_phy_power_on(struct phy *phy)
> +{
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	return clk_prepare_enable(imx8_phy->clk);
> +}
> +
> +static int imx8_pcie_phy_power_off(struct phy *phy)
> +{
> +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +	clk_disable_unprepare(imx8_phy->clk);
> +
> +	return 0;
> +}
> +
> +static const struct phy_ops imx8_pcie_phy_ops = {
> +	.init		= imx8_pcie_phy_init,
> +	.power_on	= imx8_pcie_phy_power_on,
> +	.power_off	= imx8_pcie_phy_power_off,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int imx8_pcie_phy_probe(struct platform_device *pdev)
> +{
> +	struct phy_provider *phy_provider;
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct imx8_pcie_phy *imx8_phy;
> +	struct resource *res;
> +
> +	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> +	if (!imx8_phy)
> +		return -ENOMEM;
> +
> +	/* get PHY refclk pad mode */
> +	of_property_read_u32(np, "fsl,refclk-pad-mode",
> +			     &imx8_phy->refclk_pad_mode);
> +
> +	imx8_phy->clk = devm_clk_get(dev, "phy");
> +	if (IS_ERR(imx8_phy->clk)) {
> +		dev_err(dev, "failed to get imx pcie phy clock\n");
> +		return PTR_ERR(imx8_phy->clk);
> +	}
> +
> +	/* Grab GPR config register range */
> +	imx8_phy->iomuxc_gpr =
> +		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");

I would prefer if we could get the syscon via a phandle and make the
GPR register to use another cell of the handle.

That's not really important for the 8MM, where there is only one PCIe
PHY, but if we want to retrofit this model to the i.MX8MQ, we need to
deal with different GPR offsets for both PHYs and I would like to have
this explicit in the DT. Doing the same here would be good for
consistency.

Overall, looks much better than the last submission.

Regards,
Lucas

> +	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> +		dev_err(dev, "unable to find iomuxc registers\n");
> +		return PTR_ERR(imx8_phy->iomuxc_gpr);
> +	}
> +
> +	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> +	if (IS_ERR(imx8_phy->reset)) {
> +		dev_err(dev, "Failed to get PCIEPHY reset control\n");
> +		return PTR_ERR(imx8_phy->reset);
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	imx8_phy->base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(imx8_phy->base))
> +		return PTR_ERR(imx8_phy->base);
> +
> +	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> +	if (IS_ERR(imx8_phy->phy))
> +		return PTR_ERR(imx8_phy->phy);
> +
> +	phy_set_drvdata(imx8_phy->phy, imx8_phy);
> +
> +	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 imx8_pcie_phy_of_match[] = {
> +	{.compatible = "fsl,imx8mm-pcie-phy",},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> +
> +static struct platform_driver imx8_pcie_phy_driver = {
> +	.probe	= imx8_pcie_phy_probe,
> +	.driver = {
> +		.name	= "imx8-pcie-phy",
> +		.of_match_table	= imx8_pcie_phy_of_match,
> +	}
> +};
> +module_platform_driver(imx8_pcie_phy_driver);
> +
> +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> +MODULE_LICENSE("GPL");



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

RE: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:56 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> standalone phy driver
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the standalone i.MX8 PCIe PHY driver.
> > Some reset bits should be manipulated between PHY configurations and
> > status check(internal PLL is locked or not).
> > So, do the PHY configuration in the phy_calibrate().
> > And check the PHY is ready or not in the phy_init().
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/phy/freescale/Kconfig              |   9 +
> >  drivers/phy/freescale/Makefile             |   1 +
> >  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218
> > +++++++++++++++++++++
> >  3 files changed, 228 insertions(+)
> >  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> >
> > diff --git a/drivers/phy/freescale/Kconfig
> > b/drivers/phy/freescale/Kconfig index 320630ffe3cd..fb08e5242602
> > 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
> >  	help
> >  	  Enable this to add support for the Mixel DSI PHY as found
> >  	  on NXP's i.MX8 family of SOCs.
> > +
> > +config PHY_FSL_IMX8M_PCIE
> > +	tristate "Freescale i.MX8 PCIE PHY"
> > +	depends on OF && HAS_IOMEM
> > +	select GENERIC_PHY
> > +	default ARCH_MXC
> 
> Not sure if we need this default, but if you want to keep it add at least a "&&
> ARM64" to not enable it on old 32bit i.MX SoCs.
[Richard Zhu] Add the "&& ARM64" is preferred. Thanks.
> 
> > +	help
> > +	  Enable this to add support for the PCIE PHY as found on
> > +	  i.MX8M family of SOCs.
> > diff --git a/drivers/phy/freescale/Makefile
> > b/drivers/phy/freescale/Makefile index 1d02e3869b45..55d07c742ab0
> > 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -1,3 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
> >  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
> > +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > new file mode 100644
> > index 000000000000..317cf61bff37
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -0,0 +1,218 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2021 NXP
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/delay.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> > +#include <linux/module.h>
> > +#include <linux/phy/phy.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset.h>
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> > +
> > +#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
> > +#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
> > +#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
> > +#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
> > +#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
> > +#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
> > +#define  ANA_AUX_TX_TERM		BIT(2)
> > +#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
> > +#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
> > +#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
> > +#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
> > +#define PCIE_PHY_TRSV_REG5		0x414
> > +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
> > +#define PCIE_PHY_TRSV_REG6		0x418
> > +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
> > +
> > +#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_PLL
> 	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_EXT
> 	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> > +#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
> > +#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
> > +#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
> > +#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
> > +#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
> > +
> > +struct imx8_pcie_phy {
> > +	u32			refclk_pad_mode;
> 
> Moving this to the end of the structure will get rid of a hole due to padding.
[Richard Zhu] Got that, thanks.

> 
> > +	void __iomem		*base;
> > +	struct clk		*clk;
> > +	struct phy		*phy;
> > +	struct regmap		*iomuxc_gpr;
> > +	struct reset_control	*reset;
> > +};
> > +
> > +static int imx8_pcie_phy_init(struct phy *phy) {
> > +	int ret;
> > +	u32 val, pad_mode;
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	reset_control_assert(imx8_phy->reset);
> > +
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_REF_USE_PAD,
> > +			   imx8_phy->refclk_pad_mode == 1 ?
> > +			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_AUX_EN,
> > +			   IMX8MM_GPR_PCIE_AUX_EN);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_SSC_EN, 0);
> > +
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > +			   imx8_phy->refclk_pad_mode == 1 ?
> > +			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > +			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > +	usleep_range(100, 200);
> > +
> > +	/* Do the PHY common block reset */
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_CMN_RST,
> > +			   IMX8MM_GPR_PCIE_CMN_RST);
> > +	usleep_range(200, 500);
> > +
> > +
> > +	pad_mode = imx8_phy->refclk_pad_mode;
> > +	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> > +		/* Configure the pad as input */
> > +		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> > +		/* Configure the PHY to output the refclock via pad */
> > +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> > +		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> > +		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> > +		writel(val | ANA_AUX_RX_TERM_GND_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> > +		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> > +	}
> > +
> > +	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
> > +	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> > +	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
> > +	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> > +	       imx8_phy->base + PCIE_PHY_TRSV_REG6);
> 
> I guess those are at least in part board specific. Maybe it would be a good
> idea to add DT properties to allow each board to specify the actual
> de-emphasis values?
[Richard Zhu] Agree. Would use two properties to specified them by HW board.
Thanks.

> 
> > +
> > +	reset_control_deassert(imx8_phy->reset);
> > +
> > +	/* Polling to check the phy is ready or not. */
> > +	ret = readl_poll_timeout(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG75,
> > +				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> > +				 10, 20000);
> > +	return ret;
> > +}
> > +
> > +static int imx8_pcie_phy_power_on(struct phy *phy) {
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	return clk_prepare_enable(imx8_phy->clk);
> > +}
> > +
> > +static int imx8_pcie_phy_power_off(struct phy *phy) {
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	clk_disable_unprepare(imx8_phy->clk);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct phy_ops imx8_pcie_phy_ops = {
> > +	.init		= imx8_pcie_phy_init,
> > +	.power_on	= imx8_pcie_phy_power_on,
> > +	.power_off	= imx8_pcie_phy_power_off,
> > +	.owner		= THIS_MODULE,
> > +};
> > +
> > +static int imx8_pcie_phy_probe(struct platform_device *pdev) {
> > +	struct phy_provider *phy_provider;
> > +	struct device *dev = &pdev->dev;
> > +	struct device_node *np = dev->of_node;
> > +	struct imx8_pcie_phy *imx8_phy;
> > +	struct resource *res;
> > +
> > +	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> > +	if (!imx8_phy)
> > +		return -ENOMEM;
> > +
> > +	/* get PHY refclk pad mode */
> > +	of_property_read_u32(np, "fsl,refclk-pad-mode",
> > +			     &imx8_phy->refclk_pad_mode);
> > +
> > +	imx8_phy->clk = devm_clk_get(dev, "phy");
> > +	if (IS_ERR(imx8_phy->clk)) {
> > +		dev_err(dev, "failed to get imx pcie phy clock\n");
> > +		return PTR_ERR(imx8_phy->clk);
> > +	}
> > +
> > +	/* Grab GPR config register range */
> > +	imx8_phy->iomuxc_gpr =
> > +		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> 
> I would prefer if we could get the syscon via a phandle and make the GPR
> register to use another cell of the handle.
> 
> That's not really important for the 8MM, where there is only one PCIe PHY,
> but if we want to retrofit this model to the i.MX8MQ, we need to deal with
> different GPR offsets for both PHYs and I would like to have this explicit in the
> DT. Doing the same here would be good for consistency.
[Richard Zhu] It seems that this is a good idea.
But I'm not clear about how to do about that.
IOMUXC_GPR module had been defined with 64Kbytes size and "syscon" compatible.
On i.MX8MQ, GPR14/15 are used for PCIe0 PHY, and GPR16/17 are used for PCIe1 PHY.
How to explicit these different offset in the different phandles?

BR
Richard

> 
> Overall, looks much better than the last submission.
> 
> Regards,
> Lucas
> 
> > +	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> > +		dev_err(dev, "unable to find iomuxc registers\n");
> > +		return PTR_ERR(imx8_phy->iomuxc_gpr);
> > +	}
> > +
> > +	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> > +	if (IS_ERR(imx8_phy->reset)) {
> > +		dev_err(dev, "Failed to get PCIEPHY reset control\n");
> > +		return PTR_ERR(imx8_phy->reset);
> > +	}
> > +
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	imx8_phy->base = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(imx8_phy->base))
> > +		return PTR_ERR(imx8_phy->base);
> > +
> > +	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> > +	if (IS_ERR(imx8_phy->phy))
> > +		return PTR_ERR(imx8_phy->phy);
> > +
> > +	phy_set_drvdata(imx8_phy->phy, imx8_phy);
> > +
> > +	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 imx8_pcie_phy_of_match[] = {
> > +	{.compatible = "fsl,imx8mm-pcie-phy",},
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> > +
> > +static struct platform_driver imx8_pcie_phy_driver = {
> > +	.probe	= imx8_pcie_phy_probe,
> > +	.driver = {
> > +		.name	= "imx8-pcie-phy",
> > +		.of_match_table	= imx8_pcie_phy_of_match,
> > +	}
> > +};
> > +module_platform_driver(imx8_pcie_phy_driver);
> > +
> > +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> > +MODULE_LICENSE("GPL");
> 

RE: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:56 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> standalone phy driver
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the standalone i.MX8 PCIe PHY driver.
> > Some reset bits should be manipulated between PHY configurations and
> > status check(internal PLL is locked or not).
> > So, do the PHY configuration in the phy_calibrate().
> > And check the PHY is ready or not in the phy_init().
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/phy/freescale/Kconfig              |   9 +
> >  drivers/phy/freescale/Makefile             |   1 +
> >  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218
> > +++++++++++++++++++++
> >  3 files changed, 228 insertions(+)
> >  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> >
> > diff --git a/drivers/phy/freescale/Kconfig
> > b/drivers/phy/freescale/Kconfig index 320630ffe3cd..fb08e5242602
> > 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
> >  	help
> >  	  Enable this to add support for the Mixel DSI PHY as found
> >  	  on NXP's i.MX8 family of SOCs.
> > +
> > +config PHY_FSL_IMX8M_PCIE
> > +	tristate "Freescale i.MX8 PCIE PHY"
> > +	depends on OF && HAS_IOMEM
> > +	select GENERIC_PHY
> > +	default ARCH_MXC
> 
> Not sure if we need this default, but if you want to keep it add at least a "&&
> ARM64" to not enable it on old 32bit i.MX SoCs.
[Richard Zhu] Add the "&& ARM64" is preferred. Thanks.
> 
> > +	help
> > +	  Enable this to add support for the PCIE PHY as found on
> > +	  i.MX8M family of SOCs.
> > diff --git a/drivers/phy/freescale/Makefile
> > b/drivers/phy/freescale/Makefile index 1d02e3869b45..55d07c742ab0
> > 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -1,3 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
> >  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
> > +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > new file mode 100644
> > index 000000000000..317cf61bff37
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -0,0 +1,218 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2021 NXP
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/delay.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> > +#include <linux/module.h>
> > +#include <linux/phy/phy.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset.h>
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> > +
> > +#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
> > +#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
> > +#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
> > +#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
> > +#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
> > +#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
> > +#define  ANA_AUX_TX_TERM		BIT(2)
> > +#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
> > +#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
> > +#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
> > +#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
> > +#define PCIE_PHY_TRSV_REG5		0x414
> > +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
> > +#define PCIE_PHY_TRSV_REG6		0x418
> > +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
> > +
> > +#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_PLL
> 	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_EXT
> 	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> > +#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
> > +#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
> > +#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
> > +#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
> > +#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
> > +
> > +struct imx8_pcie_phy {
> > +	u32			refclk_pad_mode;
> 
> Moving this to the end of the structure will get rid of a hole due to padding.
[Richard Zhu] Got that, thanks.

> 
> > +	void __iomem		*base;
> > +	struct clk		*clk;
> > +	struct phy		*phy;
> > +	struct regmap		*iomuxc_gpr;
> > +	struct reset_control	*reset;
> > +};
> > +
> > +static int imx8_pcie_phy_init(struct phy *phy) {
> > +	int ret;
> > +	u32 val, pad_mode;
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	reset_control_assert(imx8_phy->reset);
> > +
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_REF_USE_PAD,
> > +			   imx8_phy->refclk_pad_mode == 1 ?
> > +			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_AUX_EN,
> > +			   IMX8MM_GPR_PCIE_AUX_EN);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_SSC_EN, 0);
> > +
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > +			   imx8_phy->refclk_pad_mode == 1 ?
> > +			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > +			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > +	usleep_range(100, 200);
> > +
> > +	/* Do the PHY common block reset */
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_CMN_RST,
> > +			   IMX8MM_GPR_PCIE_CMN_RST);
> > +	usleep_range(200, 500);
> > +
> > +
> > +	pad_mode = imx8_phy->refclk_pad_mode;
> > +	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> > +		/* Configure the pad as input */
> > +		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> > +		/* Configure the PHY to output the refclock via pad */
> > +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> > +		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> > +		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> > +		writel(val | ANA_AUX_RX_TERM_GND_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> > +		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> > +	}
> > +
> > +	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
> > +	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> > +	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
> > +	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> > +	       imx8_phy->base + PCIE_PHY_TRSV_REG6);
> 
> I guess those are at least in part board specific. Maybe it would be a good
> idea to add DT properties to allow each board to specify the actual
> de-emphasis values?
[Richard Zhu] Agree. Would use two properties to specified them by HW board.
Thanks.

> 
> > +
> > +	reset_control_deassert(imx8_phy->reset);
> > +
> > +	/* Polling to check the phy is ready or not. */
> > +	ret = readl_poll_timeout(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG75,
> > +				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> > +				 10, 20000);
> > +	return ret;
> > +}
> > +
> > +static int imx8_pcie_phy_power_on(struct phy *phy) {
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	return clk_prepare_enable(imx8_phy->clk);
> > +}
> > +
> > +static int imx8_pcie_phy_power_off(struct phy *phy) {
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	clk_disable_unprepare(imx8_phy->clk);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct phy_ops imx8_pcie_phy_ops = {
> > +	.init		= imx8_pcie_phy_init,
> > +	.power_on	= imx8_pcie_phy_power_on,
> > +	.power_off	= imx8_pcie_phy_power_off,
> > +	.owner		= THIS_MODULE,
> > +};
> > +
> > +static int imx8_pcie_phy_probe(struct platform_device *pdev) {
> > +	struct phy_provider *phy_provider;
> > +	struct device *dev = &pdev->dev;
> > +	struct device_node *np = dev->of_node;
> > +	struct imx8_pcie_phy *imx8_phy;
> > +	struct resource *res;
> > +
> > +	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> > +	if (!imx8_phy)
> > +		return -ENOMEM;
> > +
> > +	/* get PHY refclk pad mode */
> > +	of_property_read_u32(np, "fsl,refclk-pad-mode",
> > +			     &imx8_phy->refclk_pad_mode);
> > +
> > +	imx8_phy->clk = devm_clk_get(dev, "phy");
> > +	if (IS_ERR(imx8_phy->clk)) {
> > +		dev_err(dev, "failed to get imx pcie phy clock\n");
> > +		return PTR_ERR(imx8_phy->clk);
> > +	}
> > +
> > +	/* Grab GPR config register range */
> > +	imx8_phy->iomuxc_gpr =
> > +		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> 
> I would prefer if we could get the syscon via a phandle and make the GPR
> register to use another cell of the handle.
> 
> That's not really important for the 8MM, where there is only one PCIe PHY,
> but if we want to retrofit this model to the i.MX8MQ, we need to deal with
> different GPR offsets for both PHYs and I would like to have this explicit in the
> DT. Doing the same here would be good for consistency.
[Richard Zhu] It seems that this is a good idea.
But I'm not clear about how to do about that.
IOMUXC_GPR module had been defined with 64Kbytes size and "syscon" compatible.
On i.MX8MQ, GPR14/15 are used for PCIe0 PHY, and GPR16/17 are used for PCIe1 PHY.
How to explicit these different offset in the different phandles?

BR
Richard

> 
> Overall, looks much better than the last submission.
> 
> Regards,
> Lucas
> 
> > +	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> > +		dev_err(dev, "unable to find iomuxc registers\n");
> > +		return PTR_ERR(imx8_phy->iomuxc_gpr);
> > +	}
> > +
> > +	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> > +	if (IS_ERR(imx8_phy->reset)) {
> > +		dev_err(dev, "Failed to get PCIEPHY reset control\n");
> > +		return PTR_ERR(imx8_phy->reset);
> > +	}
> > +
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	imx8_phy->base = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(imx8_phy->base))
> > +		return PTR_ERR(imx8_phy->base);
> > +
> > +	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> > +	if (IS_ERR(imx8_phy->phy))
> > +		return PTR_ERR(imx8_phy->phy);
> > +
> > +	phy_set_drvdata(imx8_phy->phy, imx8_phy);
> > +
> > +	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 imx8_pcie_phy_of_match[] = {
> > +	{.compatible = "fsl,imx8mm-pcie-phy",},
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> > +
> > +static struct platform_driver imx8_pcie_phy_driver = {
> > +	.probe	= imx8_pcie_phy_probe,
> > +	.driver = {
> > +		.name	= "imx8-pcie-phy",
> > +		.of_match_table	= imx8_pcie_phy_of_match,
> > +	}
> > +};
> > +module_platform_driver(imx8_pcie_phy_driver);
> > +
> > +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> > +MODULE_LICENSE("GPL");
> 

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

RE: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 2:56 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> standalone phy driver
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the standalone i.MX8 PCIe PHY driver.
> > Some reset bits should be manipulated between PHY configurations and
> > status check(internal PLL is locked or not).
> > So, do the PHY configuration in the phy_calibrate().
> > And check the PHY is ready or not in the phy_init().
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/phy/freescale/Kconfig              |   9 +
> >  drivers/phy/freescale/Makefile             |   1 +
> >  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218
> > +++++++++++++++++++++
> >  3 files changed, 228 insertions(+)
> >  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> >
> > diff --git a/drivers/phy/freescale/Kconfig
> > b/drivers/phy/freescale/Kconfig index 320630ffe3cd..fb08e5242602
> > 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
> >  	help
> >  	  Enable this to add support for the Mixel DSI PHY as found
> >  	  on NXP's i.MX8 family of SOCs.
> > +
> > +config PHY_FSL_IMX8M_PCIE
> > +	tristate "Freescale i.MX8 PCIE PHY"
> > +	depends on OF && HAS_IOMEM
> > +	select GENERIC_PHY
> > +	default ARCH_MXC
> 
> Not sure if we need this default, but if you want to keep it add at least a "&&
> ARM64" to not enable it on old 32bit i.MX SoCs.
[Richard Zhu] Add the "&& ARM64" is preferred. Thanks.
> 
> > +	help
> > +	  Enable this to add support for the PCIE PHY as found on
> > +	  i.MX8M family of SOCs.
> > diff --git a/drivers/phy/freescale/Makefile
> > b/drivers/phy/freescale/Makefile index 1d02e3869b45..55d07c742ab0
> > 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -1,3 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)	+= phy-fsl-imx8mq-usb.o
> >  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
> > +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > new file mode 100644
> > index 000000000000..317cf61bff37
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -0,0 +1,218 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2021 NXP
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/delay.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> > +#include <linux/module.h>
> > +#include <linux/phy/phy.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset.h>
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> > +
> > +#define IMX8MM_PCIE_PHY_CMN_REG061	0x184
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN	BIT(0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG062	0x188
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL	BIT(3)
> > +#define IMX8MM_PCIE_PHY_CMN_REG063	0x18C
> > +#define  AUX_PLL_REFCLK_SEL_SYS_PLL	GENMASK(7, 6)
> > +#define IMX8MM_PCIE_PHY_CMN_REG064	0x190
> > +#define  ANA_AUX_RX_TX_SEL_TX		BIT(7)
> > +#define  ANA_AUX_RX_TERM_GND_EN		BIT(3)
> > +#define  ANA_AUX_TX_TERM		BIT(2)
> > +#define IMX8MM_PCIE_PHY_CMN_REG065	0x194
> > +#define  ANA_AUX_RX_TERM		(BIT(7) | BIT(4))
> > +#define  ANA_AUX_TX_LVL			GENMASK(3, 0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG75	0x1D4
> > +#define  PCIE_PHY_CMN_REG75_PLL_DONE	0x3
> > +#define PCIE_PHY_TRSV_REG5		0x414
> > +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP	0x2D
> > +#define PCIE_PHY_TRSV_REG6		0x418
> > +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP	0xF
> > +
> > +#define IMX8MM_GPR_PCIE_REF_CLK_SEL	GENMASK(25, 24)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_PLL
> 	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_EXT
> 	FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> > +#define IMX8MM_GPR_PCIE_AUX_EN		BIT(19)
> > +#define IMX8MM_GPR_PCIE_CMN_RST		BIT(18)
> > +#define IMX8MM_GPR_PCIE_POWER_OFF	BIT(17)
> > +#define IMX8MM_GPR_PCIE_SSC_EN		BIT(16)
> > +#define IMX8MM_GPR_PCIE_REF_USE_PAD	BIT(9)
> > +
> > +struct imx8_pcie_phy {
> > +	u32			refclk_pad_mode;
> 
> Moving this to the end of the structure will get rid of a hole due to padding.
[Richard Zhu] Got that, thanks.

> 
> > +	void __iomem		*base;
> > +	struct clk		*clk;
> > +	struct phy		*phy;
> > +	struct regmap		*iomuxc_gpr;
> > +	struct reset_control	*reset;
> > +};
> > +
> > +static int imx8_pcie_phy_init(struct phy *phy) {
> > +	int ret;
> > +	u32 val, pad_mode;
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	reset_control_assert(imx8_phy->reset);
> > +
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_REF_USE_PAD,
> > +			   imx8_phy->refclk_pad_mode == 1 ?
> > +			   IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_AUX_EN,
> > +			   IMX8MM_GPR_PCIE_AUX_EN);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_POWER_OFF, 0);
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_SSC_EN, 0);
> > +
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > +			   imx8_phy->refclk_pad_mode == 1 ?
> > +			   IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > +			   IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > +	usleep_range(100, 200);
> > +
> > +	/* Do the PHY common block reset */
> > +	regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +			   IMX8MM_GPR_PCIE_CMN_RST,
> > +			   IMX8MM_GPR_PCIE_CMN_RST);
> > +	usleep_range(200, 500);
> > +
> > +
> > +	pad_mode = imx8_phy->refclk_pad_mode;
> > +	if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> > +		/* Configure the pad as input */
> > +		val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +		writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +	} else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> > +		/* Configure the PHY to output the refclock via pad */
> > +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> > +		writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> > +		writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> > +		val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> > +		writel(val | ANA_AUX_RX_TERM_GND_EN,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> > +		writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> > +		       imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> > +	}
> > +
> > +	/* Tune PHY de-emphasis setting to pass PCIe compliance. */
> > +	writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> > +	       imx8_phy->base + PCIE_PHY_TRSV_REG5);
> > +	writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> > +	       imx8_phy->base + PCIE_PHY_TRSV_REG6);
> 
> I guess those are at least in part board specific. Maybe it would be a good
> idea to add DT properties to allow each board to specify the actual
> de-emphasis values?
[Richard Zhu] Agree. Would use two properties to specified them by HW board.
Thanks.

> 
> > +
> > +	reset_control_deassert(imx8_phy->reset);
> > +
> > +	/* Polling to check the phy is ready or not. */
> > +	ret = readl_poll_timeout(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG75,
> > +				 val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> > +				 10, 20000);
> > +	return ret;
> > +}
> > +
> > +static int imx8_pcie_phy_power_on(struct phy *phy) {
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	return clk_prepare_enable(imx8_phy->clk);
> > +}
> > +
> > +static int imx8_pcie_phy_power_off(struct phy *phy) {
> > +	struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +	clk_disable_unprepare(imx8_phy->clk);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct phy_ops imx8_pcie_phy_ops = {
> > +	.init		= imx8_pcie_phy_init,
> > +	.power_on	= imx8_pcie_phy_power_on,
> > +	.power_off	= imx8_pcie_phy_power_off,
> > +	.owner		= THIS_MODULE,
> > +};
> > +
> > +static int imx8_pcie_phy_probe(struct platform_device *pdev) {
> > +	struct phy_provider *phy_provider;
> > +	struct device *dev = &pdev->dev;
> > +	struct device_node *np = dev->of_node;
> > +	struct imx8_pcie_phy *imx8_phy;
> > +	struct resource *res;
> > +
> > +	imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> > +	if (!imx8_phy)
> > +		return -ENOMEM;
> > +
> > +	/* get PHY refclk pad mode */
> > +	of_property_read_u32(np, "fsl,refclk-pad-mode",
> > +			     &imx8_phy->refclk_pad_mode);
> > +
> > +	imx8_phy->clk = devm_clk_get(dev, "phy");
> > +	if (IS_ERR(imx8_phy->clk)) {
> > +		dev_err(dev, "failed to get imx pcie phy clock\n");
> > +		return PTR_ERR(imx8_phy->clk);
> > +	}
> > +
> > +	/* Grab GPR config register range */
> > +	imx8_phy->iomuxc_gpr =
> > +		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> 
> I would prefer if we could get the syscon via a phandle and make the GPR
> register to use another cell of the handle.
> 
> That's not really important for the 8MM, where there is only one PCIe PHY,
> but if we want to retrofit this model to the i.MX8MQ, we need to deal with
> different GPR offsets for both PHYs and I would like to have this explicit in the
> DT. Doing the same here would be good for consistency.
[Richard Zhu] It seems that this is a good idea.
But I'm not clear about how to do about that.
IOMUXC_GPR module had been defined with 64Kbytes size and "syscon" compatible.
On i.MX8MQ, GPR14/15 are used for PCIe0 PHY, and GPR16/17 are used for PCIe1 PHY.
How to explicit these different offset in the different phandles?

BR
Richard

> 
> Overall, looks much better than the last submission.
> 
> Regards,
> Lucas
> 
> > +	if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> > +		dev_err(dev, "unable to find iomuxc registers\n");
> > +		return PTR_ERR(imx8_phy->iomuxc_gpr);
> > +	}
> > +
> > +	imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> > +	if (IS_ERR(imx8_phy->reset)) {
> > +		dev_err(dev, "Failed to get PCIEPHY reset control\n");
> > +		return PTR_ERR(imx8_phy->reset);
> > +	}
> > +
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	imx8_phy->base = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(imx8_phy->base))
> > +		return PTR_ERR(imx8_phy->base);
> > +
> > +	imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> > +	if (IS_ERR(imx8_phy->phy))
> > +		return PTR_ERR(imx8_phy->phy);
> > +
> > +	phy_set_drvdata(imx8_phy->phy, imx8_phy);
> > +
> > +	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 imx8_pcie_phy_of_match[] = {
> > +	{.compatible = "fsl,imx8mm-pcie-phy",},
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> > +
> > +static struct platform_driver imx8_pcie_phy_driver = {
> > +	.probe	= imx8_pcie_phy_probe,
> > +	.driver = {
> > +		.name	= "imx8-pcie-phy",
> > +		.of_match_table	= imx8_pcie_phy_of_match,
> > +	}
> > +};
> > +module_platform_driver(imx8_pcie_phy_driver);
> > +
> > +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> > +MODULE_LICENSE("GPL");
> 

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

Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Tim Harvey]

On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> Add the standalone i.MX8 PCIe PHY driver.
> Some reset bits should be manipulated between PHY configurations and
> status check(internal PLL is locked or not).
> So, do the PHY configuration in the phy_calibrate().
> And check the PHY is ready or not in the phy_init().
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/phy/freescale/Kconfig              |   9 +
>  drivers/phy/freescale/Makefile             |   1 +
>  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
>  3 files changed, 228 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
>
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 320630ffe3cd..fb08e5242602 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
>         help
>           Enable this to add support for the Mixel DSI PHY as found
>           on NXP's i.MX8 family of SOCs.
> +
> +config PHY_FSL_IMX8M_PCIE
> +       tristate "Freescale i.MX8 PCIE PHY"
> +       depends on OF && HAS_IOMEM
> +       select GENERIC_PHY
> +       default ARCH_MXC
> +       help
> +         Enable this to add support for the PCIE PHY as found on
> +         i.MX8M family of SOCs.
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index 1d02e3869b45..55d07c742ab0 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)       += phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      += phy-fsl-imx8-mipi-dphy.o
> +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> new file mode 100644
> index 000000000000..317cf61bff37
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -0,0 +1,218 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> +
> +#define IMX8MM_PCIE_PHY_CMN_REG061     0x184
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN  BIT(0)
> +#define IMX8MM_PCIE_PHY_CMN_REG062     0x188
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL BIT(3)
> +#define IMX8MM_PCIE_PHY_CMN_REG063     0x18C
> +#define  AUX_PLL_REFCLK_SEL_SYS_PLL    GENMASK(7, 6)
> +#define IMX8MM_PCIE_PHY_CMN_REG064     0x190
> +#define  ANA_AUX_RX_TX_SEL_TX          BIT(7)
> +#define  ANA_AUX_RX_TERM_GND_EN                BIT(3)
> +#define  ANA_AUX_TX_TERM               BIT(2)
> +#define IMX8MM_PCIE_PHY_CMN_REG065     0x194
> +#define  ANA_AUX_RX_TERM               (BIT(7) | BIT(4))
> +#define  ANA_AUX_TX_LVL                        GENMASK(3, 0)
> +#define IMX8MM_PCIE_PHY_CMN_REG75      0x1D4
> +#define  PCIE_PHY_CMN_REG75_PLL_DONE   0x3
> +#define PCIE_PHY_TRSV_REG5             0x414
> +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP 0x2D
> +#define PCIE_PHY_TRSV_REG6             0x418
> +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP 0xF
> +
> +#define IMX8MM_GPR_PCIE_REF_CLK_SEL    GENMASK(25, 24)
> +#define IMX8MM_GPR_PCIE_REF_CLK_PLL    FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> +#define IMX8MM_GPR_PCIE_REF_CLK_EXT    FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> +#define IMX8MM_GPR_PCIE_AUX_EN         BIT(19)
> +#define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> +#define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> +#define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> +#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +
> +struct imx8_pcie_phy {
> +       u32                     refclk_pad_mode;
> +       void __iomem            *base;
> +       struct clk              *clk;
> +       struct phy              *phy;
> +       struct regmap           *iomuxc_gpr;
> +       struct reset_control    *reset;
> +};
> +
> +static int imx8_pcie_phy_init(struct phy *phy)
> +{
> +       int ret;
> +       u32 val, pad_mode;
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       reset_control_assert(imx8_phy->reset);
> +
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> +                          imx8_phy->refclk_pad_mode == 1 ?

Hi Richard,

use the enumerated type for the comparison above for clarity:
imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT

Also, this is the configuration that makes my imx8mm-venice boards
which do not use CLKREQ# hang while waiting for PHY. I am setting in
my dt:
&pcie_phy {
        fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
        clocks = <&clk IMX8MM_CLK_DUMMY>;
        status = "okay";
};

The NXP kernel woudl always set this bit to 0 which makes my board work.

The IMX8MMRM documentation appears incorrect here:
IOMUXC_GPR_GPR14 bit 9: GPR_PCIE1_ PHY_I_AUX_ EN_OVERRIDE_ EN:
{GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN, GPR_PCIE1_PHY_FUNC_I_AUX_EN}
 2'b00 External Reference Clock I/O (for PLL) Disable
 2'b01 External Reference Clock I/O (for PLL) Enable
 2'b10 External Reference Clock I/O (for PLL) Disable
 2'b11 External Reference Clock I/O (for PLL) output is controlled by CLKREQ#

How is it they define this as a single bit then give descriptions for
2 bits? Something is wrong here.

> +                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_AUX_EN,
> +                          IMX8MM_GPR_PCIE_AUX_EN);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_POWER_OFF, 0);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_SSC_EN, 0);
> +
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_REF_CLK_SEL,
> +                          imx8_phy->refclk_pad_mode == 1 ?

imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT

Best regards,

Tim

> +                          IMX8MM_GPR_PCIE_REF_CLK_EXT :
> +                          IMX8MM_GPR_PCIE_REF_CLK_PLL);
> +       usleep_range(100, 200);
> +
> +       /* Do the PHY common block reset */
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_CMN_RST,
> +                          IMX8MM_GPR_PCIE_CMN_RST);
> +       usleep_range(200, 500);
> +
> +
> +       pad_mode = imx8_phy->refclk_pad_mode;
> +       if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> +               /* Configure the pad as input */
> +               val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +               writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +       } else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> +               /* Configure the PHY to output the refclock via pad */
> +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> +               writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> +               val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> +               writel(val | ANA_AUX_RX_TERM_GND_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> +               writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> +       }
> +
> +       /* Tune PHY de-emphasis setting to pass PCIe compliance. */
> +       writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> +              imx8_phy->base + PCIE_PHY_TRSV_REG5);
> +       writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> +              imx8_phy->base + PCIE_PHY_TRSV_REG6);
> +
> +       reset_control_deassert(imx8_phy->reset);
> +
> +       /* Polling to check the phy is ready or not. */
> +       ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
> +                                val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> +                                10, 20000);
> +       return ret;
> +}
> +
> +static int imx8_pcie_phy_power_on(struct phy *phy)
> +{
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       return clk_prepare_enable(imx8_phy->clk);
> +}
> +
> +static int imx8_pcie_phy_power_off(struct phy *phy)
> +{
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       clk_disable_unprepare(imx8_phy->clk);
> +
> +       return 0;
> +}
> +
> +static const struct phy_ops imx8_pcie_phy_ops = {
> +       .init           = imx8_pcie_phy_init,
> +       .power_on       = imx8_pcie_phy_power_on,
> +       .power_off      = imx8_pcie_phy_power_off,
> +       .owner          = THIS_MODULE,
> +};
> +
> +static int imx8_pcie_phy_probe(struct platform_device *pdev)
> +{
> +       struct phy_provider *phy_provider;
> +       struct device *dev = &pdev->dev;
> +       struct device_node *np = dev->of_node;
> +       struct imx8_pcie_phy *imx8_phy;
> +       struct resource *res;
> +
> +       imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> +       if (!imx8_phy)
> +               return -ENOMEM;
> +
> +       /* get PHY refclk pad mode */
> +       of_property_read_u32(np, "fsl,refclk-pad-mode",
> +                            &imx8_phy->refclk_pad_mode);
> +
> +       imx8_phy->clk = devm_clk_get(dev, "phy");
> +       if (IS_ERR(imx8_phy->clk)) {
> +               dev_err(dev, "failed to get imx pcie phy clock\n");
> +               return PTR_ERR(imx8_phy->clk);
> +       }
> +
> +       /* Grab GPR config register range */
> +       imx8_phy->iomuxc_gpr =
> +                syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +       if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> +               dev_err(dev, "unable to find iomuxc registers\n");
> +               return PTR_ERR(imx8_phy->iomuxc_gpr);
> +       }
> +
> +       imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> +       if (IS_ERR(imx8_phy->reset)) {
> +               dev_err(dev, "Failed to get PCIEPHY reset control\n");
> +               return PTR_ERR(imx8_phy->reset);
> +       }
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       imx8_phy->base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(imx8_phy->base))
> +               return PTR_ERR(imx8_phy->base);
> +
> +       imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> +       if (IS_ERR(imx8_phy->phy))
> +               return PTR_ERR(imx8_phy->phy);
> +
> +       phy_set_drvdata(imx8_phy->phy, imx8_phy);
> +
> +       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 imx8_pcie_phy_of_match[] = {
> +       {.compatible = "fsl,imx8mm-pcie-phy",},
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> +
> +static struct platform_driver imx8_pcie_phy_driver = {
> +       .probe  = imx8_pcie_phy_probe,
> +       .driver = {
> +               .name   = "imx8-pcie-phy",
> +               .of_match_table = imx8_pcie_phy_of_match,
> +       }
> +};
> +module_platform_driver(imx8_pcie_phy_driver);
> +
> +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> +MODULE_LICENSE("GPL");
> --
> 2.25.1
>

Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Tim Harvey]

On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> Add the standalone i.MX8 PCIe PHY driver.
> Some reset bits should be manipulated between PHY configurations and
> status check(internal PLL is locked or not).
> So, do the PHY configuration in the phy_calibrate().
> And check the PHY is ready or not in the phy_init().
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/phy/freescale/Kconfig              |   9 +
>  drivers/phy/freescale/Makefile             |   1 +
>  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
>  3 files changed, 228 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
>
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 320630ffe3cd..fb08e5242602 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
>         help
>           Enable this to add support for the Mixel DSI PHY as found
>           on NXP's i.MX8 family of SOCs.
> +
> +config PHY_FSL_IMX8M_PCIE
> +       tristate "Freescale i.MX8 PCIE PHY"
> +       depends on OF && HAS_IOMEM
> +       select GENERIC_PHY
> +       default ARCH_MXC
> +       help
> +         Enable this to add support for the PCIE PHY as found on
> +         i.MX8M family of SOCs.
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index 1d02e3869b45..55d07c742ab0 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)       += phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      += phy-fsl-imx8-mipi-dphy.o
> +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> new file mode 100644
> index 000000000000..317cf61bff37
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -0,0 +1,218 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> +
> +#define IMX8MM_PCIE_PHY_CMN_REG061     0x184
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN  BIT(0)
> +#define IMX8MM_PCIE_PHY_CMN_REG062     0x188
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL BIT(3)
> +#define IMX8MM_PCIE_PHY_CMN_REG063     0x18C
> +#define  AUX_PLL_REFCLK_SEL_SYS_PLL    GENMASK(7, 6)
> +#define IMX8MM_PCIE_PHY_CMN_REG064     0x190
> +#define  ANA_AUX_RX_TX_SEL_TX          BIT(7)
> +#define  ANA_AUX_RX_TERM_GND_EN                BIT(3)
> +#define  ANA_AUX_TX_TERM               BIT(2)
> +#define IMX8MM_PCIE_PHY_CMN_REG065     0x194
> +#define  ANA_AUX_RX_TERM               (BIT(7) | BIT(4))
> +#define  ANA_AUX_TX_LVL                        GENMASK(3, 0)
> +#define IMX8MM_PCIE_PHY_CMN_REG75      0x1D4
> +#define  PCIE_PHY_CMN_REG75_PLL_DONE   0x3
> +#define PCIE_PHY_TRSV_REG5             0x414
> +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP 0x2D
> +#define PCIE_PHY_TRSV_REG6             0x418
> +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP 0xF
> +
> +#define IMX8MM_GPR_PCIE_REF_CLK_SEL    GENMASK(25, 24)
> +#define IMX8MM_GPR_PCIE_REF_CLK_PLL    FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> +#define IMX8MM_GPR_PCIE_REF_CLK_EXT    FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> +#define IMX8MM_GPR_PCIE_AUX_EN         BIT(19)
> +#define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> +#define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> +#define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> +#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +
> +struct imx8_pcie_phy {
> +       u32                     refclk_pad_mode;
> +       void __iomem            *base;
> +       struct clk              *clk;
> +       struct phy              *phy;
> +       struct regmap           *iomuxc_gpr;
> +       struct reset_control    *reset;
> +};
> +
> +static int imx8_pcie_phy_init(struct phy *phy)
> +{
> +       int ret;
> +       u32 val, pad_mode;
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       reset_control_assert(imx8_phy->reset);
> +
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> +                          imx8_phy->refclk_pad_mode == 1 ?

Hi Richard,

use the enumerated type for the comparison above for clarity:
imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT

Also, this is the configuration that makes my imx8mm-venice boards
which do not use CLKREQ# hang while waiting for PHY. I am setting in
my dt:
&pcie_phy {
        fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
        clocks = <&clk IMX8MM_CLK_DUMMY>;
        status = "okay";
};

The NXP kernel woudl always set this bit to 0 which makes my board work.

The IMX8MMRM documentation appears incorrect here:
IOMUXC_GPR_GPR14 bit 9: GPR_PCIE1_ PHY_I_AUX_ EN_OVERRIDE_ EN:
{GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN, GPR_PCIE1_PHY_FUNC_I_AUX_EN}
 2'b00 External Reference Clock I/O (for PLL) Disable
 2'b01 External Reference Clock I/O (for PLL) Enable
 2'b10 External Reference Clock I/O (for PLL) Disable
 2'b11 External Reference Clock I/O (for PLL) output is controlled by CLKREQ#

How is it they define this as a single bit then give descriptions for
2 bits? Something is wrong here.

> +                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_AUX_EN,
> +                          IMX8MM_GPR_PCIE_AUX_EN);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_POWER_OFF, 0);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_SSC_EN, 0);
> +
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_REF_CLK_SEL,
> +                          imx8_phy->refclk_pad_mode == 1 ?

imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT

Best regards,

Tim

> +                          IMX8MM_GPR_PCIE_REF_CLK_EXT :
> +                          IMX8MM_GPR_PCIE_REF_CLK_PLL);
> +       usleep_range(100, 200);
> +
> +       /* Do the PHY common block reset */
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_CMN_RST,
> +                          IMX8MM_GPR_PCIE_CMN_RST);
> +       usleep_range(200, 500);
> +
> +
> +       pad_mode = imx8_phy->refclk_pad_mode;
> +       if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> +               /* Configure the pad as input */
> +               val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +               writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +       } else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> +               /* Configure the PHY to output the refclock via pad */
> +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> +               writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> +               val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> +               writel(val | ANA_AUX_RX_TERM_GND_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> +               writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> +       }
> +
> +       /* Tune PHY de-emphasis setting to pass PCIe compliance. */
> +       writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> +              imx8_phy->base + PCIE_PHY_TRSV_REG5);
> +       writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> +              imx8_phy->base + PCIE_PHY_TRSV_REG6);
> +
> +       reset_control_deassert(imx8_phy->reset);
> +
> +       /* Polling to check the phy is ready or not. */
> +       ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
> +                                val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> +                                10, 20000);
> +       return ret;
> +}
> +
> +static int imx8_pcie_phy_power_on(struct phy *phy)
> +{
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       return clk_prepare_enable(imx8_phy->clk);
> +}
> +
> +static int imx8_pcie_phy_power_off(struct phy *phy)
> +{
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       clk_disable_unprepare(imx8_phy->clk);
> +
> +       return 0;
> +}
> +
> +static const struct phy_ops imx8_pcie_phy_ops = {
> +       .init           = imx8_pcie_phy_init,
> +       .power_on       = imx8_pcie_phy_power_on,
> +       .power_off      = imx8_pcie_phy_power_off,
> +       .owner          = THIS_MODULE,
> +};
> +
> +static int imx8_pcie_phy_probe(struct platform_device *pdev)
> +{
> +       struct phy_provider *phy_provider;
> +       struct device *dev = &pdev->dev;
> +       struct device_node *np = dev->of_node;
> +       struct imx8_pcie_phy *imx8_phy;
> +       struct resource *res;
> +
> +       imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> +       if (!imx8_phy)
> +               return -ENOMEM;
> +
> +       /* get PHY refclk pad mode */
> +       of_property_read_u32(np, "fsl,refclk-pad-mode",
> +                            &imx8_phy->refclk_pad_mode);
> +
> +       imx8_phy->clk = devm_clk_get(dev, "phy");
> +       if (IS_ERR(imx8_phy->clk)) {
> +               dev_err(dev, "failed to get imx pcie phy clock\n");
> +               return PTR_ERR(imx8_phy->clk);
> +       }
> +
> +       /* Grab GPR config register range */
> +       imx8_phy->iomuxc_gpr =
> +                syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +       if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> +               dev_err(dev, "unable to find iomuxc registers\n");
> +               return PTR_ERR(imx8_phy->iomuxc_gpr);
> +       }
> +
> +       imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> +       if (IS_ERR(imx8_phy->reset)) {
> +               dev_err(dev, "Failed to get PCIEPHY reset control\n");
> +               return PTR_ERR(imx8_phy->reset);
> +       }
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       imx8_phy->base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(imx8_phy->base))
> +               return PTR_ERR(imx8_phy->base);
> +
> +       imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> +       if (IS_ERR(imx8_phy->phy))
> +               return PTR_ERR(imx8_phy->phy);
> +
> +       phy_set_drvdata(imx8_phy->phy, imx8_phy);
> +
> +       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 imx8_pcie_phy_of_match[] = {
> +       {.compatible = "fsl,imx8mm-pcie-phy",},
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> +
> +static struct platform_driver imx8_pcie_phy_driver = {
> +       .probe  = imx8_pcie_phy_probe,
> +       .driver = {
> +               .name   = "imx8-pcie-phy",
> +               .of_match_table = imx8_pcie_phy_of_match,
> +       }
> +};
> +module_platform_driver(imx8_pcie_phy_driver);
> +
> +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> +MODULE_LICENSE("GPL");
> --
> 2.25.1
>

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

Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Tim Harvey]

On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> Add the standalone i.MX8 PCIe PHY driver.
> Some reset bits should be manipulated between PHY configurations and
> status check(internal PLL is locked or not).
> So, do the PHY configuration in the phy_calibrate().
> And check the PHY is ready or not in the phy_init().
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/phy/freescale/Kconfig              |   9 +
>  drivers/phy/freescale/Makefile             |   1 +
>  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 +++++++++++++++++++++
>  3 files changed, 228 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
>
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 320630ffe3cd..fb08e5242602 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
>         help
>           Enable this to add support for the Mixel DSI PHY as found
>           on NXP's i.MX8 family of SOCs.
> +
> +config PHY_FSL_IMX8M_PCIE
> +       tristate "Freescale i.MX8 PCIE PHY"
> +       depends on OF && HAS_IOMEM
> +       select GENERIC_PHY
> +       default ARCH_MXC
> +       help
> +         Enable this to add support for the PCIE PHY as found on
> +         i.MX8M family of SOCs.
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index 1d02e3869b45..55d07c742ab0 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)       += phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      += phy-fsl-imx8-mipi-dphy.o
> +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> new file mode 100644
> index 000000000000..317cf61bff37
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -0,0 +1,218 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> +
> +#define IMX8MM_PCIE_PHY_CMN_REG061     0x184
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN  BIT(0)
> +#define IMX8MM_PCIE_PHY_CMN_REG062     0x188
> +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL BIT(3)
> +#define IMX8MM_PCIE_PHY_CMN_REG063     0x18C
> +#define  AUX_PLL_REFCLK_SEL_SYS_PLL    GENMASK(7, 6)
> +#define IMX8MM_PCIE_PHY_CMN_REG064     0x190
> +#define  ANA_AUX_RX_TX_SEL_TX          BIT(7)
> +#define  ANA_AUX_RX_TERM_GND_EN                BIT(3)
> +#define  ANA_AUX_TX_TERM               BIT(2)
> +#define IMX8MM_PCIE_PHY_CMN_REG065     0x194
> +#define  ANA_AUX_RX_TERM               (BIT(7) | BIT(4))
> +#define  ANA_AUX_TX_LVL                        GENMASK(3, 0)
> +#define IMX8MM_PCIE_PHY_CMN_REG75      0x1D4
> +#define  PCIE_PHY_CMN_REG75_PLL_DONE   0x3
> +#define PCIE_PHY_TRSV_REG5             0x414
> +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP 0x2D
> +#define PCIE_PHY_TRSV_REG6             0x418
> +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP 0xF
> +
> +#define IMX8MM_GPR_PCIE_REF_CLK_SEL    GENMASK(25, 24)
> +#define IMX8MM_GPR_PCIE_REF_CLK_PLL    FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> +#define IMX8MM_GPR_PCIE_REF_CLK_EXT    FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> +#define IMX8MM_GPR_PCIE_AUX_EN         BIT(19)
> +#define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> +#define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> +#define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> +#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +
> +struct imx8_pcie_phy {
> +       u32                     refclk_pad_mode;
> +       void __iomem            *base;
> +       struct clk              *clk;
> +       struct phy              *phy;
> +       struct regmap           *iomuxc_gpr;
> +       struct reset_control    *reset;
> +};
> +
> +static int imx8_pcie_phy_init(struct phy *phy)
> +{
> +       int ret;
> +       u32 val, pad_mode;
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       reset_control_assert(imx8_phy->reset);
> +
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> +                          imx8_phy->refclk_pad_mode == 1 ?

Hi Richard,

use the enumerated type for the comparison above for clarity:
imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT

Also, this is the configuration that makes my imx8mm-venice boards
which do not use CLKREQ# hang while waiting for PHY. I am setting in
my dt:
&pcie_phy {
        fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
        clocks = <&clk IMX8MM_CLK_DUMMY>;
        status = "okay";
};

The NXP kernel woudl always set this bit to 0 which makes my board work.

The IMX8MMRM documentation appears incorrect here:
IOMUXC_GPR_GPR14 bit 9: GPR_PCIE1_ PHY_I_AUX_ EN_OVERRIDE_ EN:
{GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN, GPR_PCIE1_PHY_FUNC_I_AUX_EN}
 2'b00 External Reference Clock I/O (for PLL) Disable
 2'b01 External Reference Clock I/O (for PLL) Enable
 2'b10 External Reference Clock I/O (for PLL) Disable
 2'b11 External Reference Clock I/O (for PLL) output is controlled by CLKREQ#

How is it they define this as a single bit then give descriptions for
2 bits? Something is wrong here.

> +                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_AUX_EN,
> +                          IMX8MM_GPR_PCIE_AUX_EN);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_POWER_OFF, 0);
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_SSC_EN, 0);
> +
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_REF_CLK_SEL,
> +                          imx8_phy->refclk_pad_mode == 1 ?

imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT

Best regards,

Tim

> +                          IMX8MM_GPR_PCIE_REF_CLK_EXT :
> +                          IMX8MM_GPR_PCIE_REF_CLK_PLL);
> +       usleep_range(100, 200);
> +
> +       /* Do the PHY common block reset */
> +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> +                          IMX8MM_GPR_PCIE_CMN_RST,
> +                          IMX8MM_GPR_PCIE_CMN_RST);
> +       usleep_range(200, 500);
> +
> +
> +       pad_mode = imx8_phy->refclk_pad_mode;
> +       if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> +               /* Configure the pad as input */
> +               val = readl(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +               writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +       } else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> +               /* Configure the PHY to output the refclock via pad */
> +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG061);
> +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
> +               writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
> +               val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> +               writel(val | ANA_AUX_RX_TERM_GND_EN,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
> +               writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> +                      imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG065);
> +       }
> +
> +       /* Tune PHY de-emphasis setting to pass PCIe compliance. */
> +       writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> +              imx8_phy->base + PCIE_PHY_TRSV_REG5);
> +       writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> +              imx8_phy->base + PCIE_PHY_TRSV_REG6);
> +
> +       reset_control_deassert(imx8_phy->reset);
> +
> +       /* Polling to check the phy is ready or not. */
> +       ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG75,
> +                                val, val == PCIE_PHY_CMN_REG75_PLL_DONE,
> +                                10, 20000);
> +       return ret;
> +}
> +
> +static int imx8_pcie_phy_power_on(struct phy *phy)
> +{
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       return clk_prepare_enable(imx8_phy->clk);
> +}
> +
> +static int imx8_pcie_phy_power_off(struct phy *phy)
> +{
> +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> +
> +       clk_disable_unprepare(imx8_phy->clk);
> +
> +       return 0;
> +}
> +
> +static const struct phy_ops imx8_pcie_phy_ops = {
> +       .init           = imx8_pcie_phy_init,
> +       .power_on       = imx8_pcie_phy_power_on,
> +       .power_off      = imx8_pcie_phy_power_off,
> +       .owner          = THIS_MODULE,
> +};
> +
> +static int imx8_pcie_phy_probe(struct platform_device *pdev)
> +{
> +       struct phy_provider *phy_provider;
> +       struct device *dev = &pdev->dev;
> +       struct device_node *np = dev->of_node;
> +       struct imx8_pcie_phy *imx8_phy;
> +       struct resource *res;
> +
> +       imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> +       if (!imx8_phy)
> +               return -ENOMEM;
> +
> +       /* get PHY refclk pad mode */
> +       of_property_read_u32(np, "fsl,refclk-pad-mode",
> +                            &imx8_phy->refclk_pad_mode);
> +
> +       imx8_phy->clk = devm_clk_get(dev, "phy");
> +       if (IS_ERR(imx8_phy->clk)) {
> +               dev_err(dev, "failed to get imx pcie phy clock\n");
> +               return PTR_ERR(imx8_phy->clk);
> +       }
> +
> +       /* Grab GPR config register range */
> +       imx8_phy->iomuxc_gpr =
> +                syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +       if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> +               dev_err(dev, "unable to find iomuxc registers\n");
> +               return PTR_ERR(imx8_phy->iomuxc_gpr);
> +       }
> +
> +       imx8_phy->reset = devm_reset_control_get_exclusive(dev, "pciephy");
> +       if (IS_ERR(imx8_phy->reset)) {
> +               dev_err(dev, "Failed to get PCIEPHY reset control\n");
> +               return PTR_ERR(imx8_phy->reset);
> +       }
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       imx8_phy->base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(imx8_phy->base))
> +               return PTR_ERR(imx8_phy->base);
> +
> +       imx8_phy->phy = devm_phy_create(dev, NULL, &imx8_pcie_phy_ops);
> +       if (IS_ERR(imx8_phy->phy))
> +               return PTR_ERR(imx8_phy->phy);
> +
> +       phy_set_drvdata(imx8_phy->phy, imx8_phy);
> +
> +       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 imx8_pcie_phy_of_match[] = {
> +       {.compatible = "fsl,imx8mm-pcie-phy",},
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> +
> +static struct platform_driver imx8_pcie_phy_driver = {
> +       .probe  = imx8_pcie_phy_probe,
> +       .driver = {
> +               .name   = "imx8-pcie-phy",
> +               .of_match_table = imx8_pcie_phy_of_match,
> +       }
> +};
> +module_platform_driver(imx8_pcie_phy_driver);
> +
> +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> +MODULE_LICENSE("GPL");
> --
> 2.25.1
>

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

RE: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Friday, October 22, 2021 12:00 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> standalone phy driver
> 
> On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > Add the standalone i.MX8 PCIe PHY driver.
> > Some reset bits should be manipulated between PHY configurations and
> > status check(internal PLL is locked or not).
> > So, do the PHY configuration in the phy_calibrate().
> > And check the PHY is ready or not in the phy_init().
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/phy/freescale/Kconfig              |   9 +
> >  drivers/phy/freescale/Makefile             |   1 +
> >  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218
> > +++++++++++++++++++++
> >  3 files changed, 228 insertions(+)
> >  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> >
> > diff --git a/drivers/phy/freescale/Kconfig
> > b/drivers/phy/freescale/Kconfig index 320630ffe3cd..fb08e5242602
> > 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
> >         help
> >           Enable this to add support for the Mixel DSI PHY as found
> >           on NXP's i.MX8 family of SOCs.
> > +
> > +config PHY_FSL_IMX8M_PCIE
> > +       tristate "Freescale i.MX8 PCIE PHY"
> > +       depends on OF && HAS_IOMEM
> > +       select GENERIC_PHY
> > +       default ARCH_MXC
> > +       help
> > +         Enable this to add support for the PCIE PHY as found on
> > +         i.MX8M family of SOCs.
> > diff --git a/drivers/phy/freescale/Makefile
> > b/drivers/phy/freescale/Makefile index 1d02e3869b45..55d07c742ab0
> > 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -1,3 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)       += phy-fsl-imx8mq-usb.o
> >  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      +=
> phy-fsl-imx8-mipi-dphy.o
> > +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > new file mode 100644
> > index 000000000000..317cf61bff37
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -0,0 +1,218 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2021 NXP
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/delay.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> > +#include <linux/module.h>
> > +#include <linux/phy/phy.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset.h>
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> > +
> > +#define IMX8MM_PCIE_PHY_CMN_REG061     0x184
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN  BIT(0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG062     0x188
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL BIT(3)
> > +#define IMX8MM_PCIE_PHY_CMN_REG063     0x18C
> > +#define  AUX_PLL_REFCLK_SEL_SYS_PLL    GENMASK(7, 6)
> > +#define IMX8MM_PCIE_PHY_CMN_REG064     0x190
> > +#define  ANA_AUX_RX_TX_SEL_TX          BIT(7)
> > +#define  ANA_AUX_RX_TERM_GND_EN                BIT(3)
> > +#define  ANA_AUX_TX_TERM               BIT(2)
> > +#define IMX8MM_PCIE_PHY_CMN_REG065     0x194
> > +#define  ANA_AUX_RX_TERM               (BIT(7) | BIT(4))
> > +#define  ANA_AUX_TX_LVL                        GENMASK(3, 0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG75      0x1D4
> > +#define  PCIE_PHY_CMN_REG75_PLL_DONE   0x3
> > +#define PCIE_PHY_TRSV_REG5             0x414
> > +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP 0x2D
> > +#define PCIE_PHY_TRSV_REG6             0x418
> > +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP 0xF
> > +
> > +#define IMX8MM_GPR_PCIE_REF_CLK_SEL    GENMASK(25, 24)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_PLL
> FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_EXT
> FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> > +#define IMX8MM_GPR_PCIE_AUX_EN         BIT(19)
> > +#define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> > +#define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> > +#define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > +#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +
> > +struct imx8_pcie_phy {
> > +       u32                     refclk_pad_mode;
> > +       void __iomem            *base;
> > +       struct clk              *clk;
> > +       struct phy              *phy;
> > +       struct regmap           *iomuxc_gpr;
> > +       struct reset_control    *reset;
> > +};
> > +
> > +static int imx8_pcie_phy_init(struct phy *phy) {
> > +       int ret;
> > +       u32 val, pad_mode;
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       reset_control_assert(imx8_phy->reset);
> > +
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > +                          imx8_phy->refclk_pad_mode == 1 ?
> 
> Hi Richard,
> 
> use the enumerated type for the comparison above for clarity:
> imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT
> 
> Also, this is the configuration that makes my imx8mm-venice boards which do
> not use CLKREQ# hang while waiting for PHY. I am setting in my dt:
> &pcie_phy {
>         fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
>         clocks = <&clk IMX8MM_CLK_DUMMY>;
>         status = "okay";
> };
> 
> The NXP kernel woudl always set this bit to 0 which makes my board work.
> 
> The IMX8MMRM documentation appears incorrect here:
> IOMUXC_GPR_GPR14 bit 9: GPR_PCIE1_ PHY_I_AUX_ EN_OVERRIDE_ EN:
> {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN,
> GPR_PCIE1_PHY_FUNC_I_AUX_EN}
>  2'b00 External Reference Clock I/O (for PLL) Disable
>  2'b01 External Reference Clock I/O (for PLL) Enable
>  2'b10 External Reference Clock I/O (for PLL) Disable
>  2'b11 External Reference Clock I/O (for PLL) output is controlled by CLKREQ#
> 
> How is it they define this as a single bit then give descriptions for
> 2 bits? Something is wrong here.
> 
[Richard Zhu] The descriptions are not correct, please ignore them.

> > +                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_AUX_EN,
> > +                          IMX8MM_GPR_PCIE_AUX_EN);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_POWER_OFF, 0);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_SSC_EN, 0);
> > +
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > +                          imx8_phy->refclk_pad_mode == 1 ?
> 
> imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT
[Richard Zhu] Got that. Thanks.

BR
Richard
> 
> Best regards,
> 
> Tim
> 
> > +                          IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > +                          IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > +       usleep_range(100, 200);
> > +
> > +       /* Do the PHY common block reset */
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_CMN_RST,
> > +                          IMX8MM_GPR_PCIE_CMN_RST);
> > +       usleep_range(200, 500);
> > +
> > +
> > +       pad_mode = imx8_phy->refclk_pad_mode;
> > +       if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> > +               /* Configure the pad as input */
> > +               val = readl(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +               writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +       } else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> > +               /* Configure the PHY to output the refclock via pad */
> > +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG062);
> > +               writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG063);
> > +               val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> > +               writel(val | ANA_AUX_RX_TERM_GND_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG064);
> > +               writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG065);
> > +       }
> > +
> > +       /* Tune PHY de-emphasis setting to pass PCIe compliance. */
> > +       writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> > +              imx8_phy->base + PCIE_PHY_TRSV_REG5);
> > +       writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> > +              imx8_phy->base + PCIE_PHY_TRSV_REG6);
> > +
> > +       reset_control_deassert(imx8_phy->reset);
> > +
> > +       /* Polling to check the phy is ready or not. */
> > +       ret = readl_poll_timeout(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG75,
> > +                                val, val ==
> PCIE_PHY_CMN_REG75_PLL_DONE,
> > +                                10, 20000);
> > +       return ret;
> > +}
> > +
> > +static int imx8_pcie_phy_power_on(struct phy *phy) {
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       return clk_prepare_enable(imx8_phy->clk);
> > +}
> > +
> > +static int imx8_pcie_phy_power_off(struct phy *phy) {
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       clk_disable_unprepare(imx8_phy->clk);
> > +
> > +       return 0;
> > +}
> > +
> > +static const struct phy_ops imx8_pcie_phy_ops = {
> > +       .init           = imx8_pcie_phy_init,
> > +       .power_on       = imx8_pcie_phy_power_on,
> > +       .power_off      = imx8_pcie_phy_power_off,
> > +       .owner          = THIS_MODULE,
> > +};
> > +
> > +static int imx8_pcie_phy_probe(struct platform_device *pdev) {
> > +       struct phy_provider *phy_provider;
> > +       struct device *dev = &pdev->dev;
> > +       struct device_node *np = dev->of_node;
> > +       struct imx8_pcie_phy *imx8_phy;
> > +       struct resource *res;
> > +
> > +       imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> > +       if (!imx8_phy)
> > +               return -ENOMEM;
> > +
> > +       /* get PHY refclk pad mode */
> > +       of_property_read_u32(np, "fsl,refclk-pad-mode",
> > +                            &imx8_phy->refclk_pad_mode);
> > +
> > +       imx8_phy->clk = devm_clk_get(dev, "phy");
> > +       if (IS_ERR(imx8_phy->clk)) {
> > +               dev_err(dev, "failed to get imx pcie phy clock\n");
> > +               return PTR_ERR(imx8_phy->clk);
> > +       }
> > +
> > +       /* Grab GPR config register range */
> > +       imx8_phy->iomuxc_gpr =
> > +
> syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> > +       if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> > +               dev_err(dev, "unable to find iomuxc registers\n");
> > +               return PTR_ERR(imx8_phy->iomuxc_gpr);
> > +       }
> > +
> > +       imx8_phy->reset = devm_reset_control_get_exclusive(dev,
> "pciephy");
> > +       if (IS_ERR(imx8_phy->reset)) {
> > +               dev_err(dev, "Failed to get PCIEPHY reset control\n");
> > +               return PTR_ERR(imx8_phy->reset);
> > +       }
> > +
> > +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +       imx8_phy->base = devm_ioremap_resource(dev, res);
> > +       if (IS_ERR(imx8_phy->base))
> > +               return PTR_ERR(imx8_phy->base);
> > +
> > +       imx8_phy->phy = devm_phy_create(dev, NULL,
> &imx8_pcie_phy_ops);
> > +       if (IS_ERR(imx8_phy->phy))
> > +               return PTR_ERR(imx8_phy->phy);
> > +
> > +       phy_set_drvdata(imx8_phy->phy, imx8_phy);
> > +
> > +       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 imx8_pcie_phy_of_match[] = {
> > +       {.compatible = "fsl,imx8mm-pcie-phy",},
> > +       { },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> > +
> > +static struct platform_driver imx8_pcie_phy_driver = {
> > +       .probe  = imx8_pcie_phy_probe,
> > +       .driver = {
> > +               .name   = "imx8-pcie-phy",
> > +               .of_match_table = imx8_pcie_phy_of_match,
> > +       }
> > +};
> > +module_platform_driver(imx8_pcie_phy_driver);
> > +
> > +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.25.1
> >

RE: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Friday, October 22, 2021 12:00 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> standalone phy driver
> 
> On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > Add the standalone i.MX8 PCIe PHY driver.
> > Some reset bits should be manipulated between PHY configurations and
> > status check(internal PLL is locked or not).
> > So, do the PHY configuration in the phy_calibrate().
> > And check the PHY is ready or not in the phy_init().
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/phy/freescale/Kconfig              |   9 +
> >  drivers/phy/freescale/Makefile             |   1 +
> >  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218
> > +++++++++++++++++++++
> >  3 files changed, 228 insertions(+)
> >  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> >
> > diff --git a/drivers/phy/freescale/Kconfig
> > b/drivers/phy/freescale/Kconfig index 320630ffe3cd..fb08e5242602
> > 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
> >         help
> >           Enable this to add support for the Mixel DSI PHY as found
> >           on NXP's i.MX8 family of SOCs.
> > +
> > +config PHY_FSL_IMX8M_PCIE
> > +       tristate "Freescale i.MX8 PCIE PHY"
> > +       depends on OF && HAS_IOMEM
> > +       select GENERIC_PHY
> > +       default ARCH_MXC
> > +       help
> > +         Enable this to add support for the PCIE PHY as found on
> > +         i.MX8M family of SOCs.
> > diff --git a/drivers/phy/freescale/Makefile
> > b/drivers/phy/freescale/Makefile index 1d02e3869b45..55d07c742ab0
> > 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -1,3 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)       += phy-fsl-imx8mq-usb.o
> >  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      +=
> phy-fsl-imx8-mipi-dphy.o
> > +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > new file mode 100644
> > index 000000000000..317cf61bff37
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -0,0 +1,218 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2021 NXP
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/delay.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> > +#include <linux/module.h>
> > +#include <linux/phy/phy.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset.h>
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> > +
> > +#define IMX8MM_PCIE_PHY_CMN_REG061     0x184
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN  BIT(0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG062     0x188
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL BIT(3)
> > +#define IMX8MM_PCIE_PHY_CMN_REG063     0x18C
> > +#define  AUX_PLL_REFCLK_SEL_SYS_PLL    GENMASK(7, 6)
> > +#define IMX8MM_PCIE_PHY_CMN_REG064     0x190
> > +#define  ANA_AUX_RX_TX_SEL_TX          BIT(7)
> > +#define  ANA_AUX_RX_TERM_GND_EN                BIT(3)
> > +#define  ANA_AUX_TX_TERM               BIT(2)
> > +#define IMX8MM_PCIE_PHY_CMN_REG065     0x194
> > +#define  ANA_AUX_RX_TERM               (BIT(7) | BIT(4))
> > +#define  ANA_AUX_TX_LVL                        GENMASK(3, 0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG75      0x1D4
> > +#define  PCIE_PHY_CMN_REG75_PLL_DONE   0x3
> > +#define PCIE_PHY_TRSV_REG5             0x414
> > +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP 0x2D
> > +#define PCIE_PHY_TRSV_REG6             0x418
> > +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP 0xF
> > +
> > +#define IMX8MM_GPR_PCIE_REF_CLK_SEL    GENMASK(25, 24)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_PLL
> FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_EXT
> FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> > +#define IMX8MM_GPR_PCIE_AUX_EN         BIT(19)
> > +#define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> > +#define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> > +#define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > +#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +
> > +struct imx8_pcie_phy {
> > +       u32                     refclk_pad_mode;
> > +       void __iomem            *base;
> > +       struct clk              *clk;
> > +       struct phy              *phy;
> > +       struct regmap           *iomuxc_gpr;
> > +       struct reset_control    *reset;
> > +};
> > +
> > +static int imx8_pcie_phy_init(struct phy *phy) {
> > +       int ret;
> > +       u32 val, pad_mode;
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       reset_control_assert(imx8_phy->reset);
> > +
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > +                          imx8_phy->refclk_pad_mode == 1 ?
> 
> Hi Richard,
> 
> use the enumerated type for the comparison above for clarity:
> imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT
> 
> Also, this is the configuration that makes my imx8mm-venice boards which do
> not use CLKREQ# hang while waiting for PHY. I am setting in my dt:
> &pcie_phy {
>         fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
>         clocks = <&clk IMX8MM_CLK_DUMMY>;
>         status = "okay";
> };
> 
> The NXP kernel woudl always set this bit to 0 which makes my board work.
> 
> The IMX8MMRM documentation appears incorrect here:
> IOMUXC_GPR_GPR14 bit 9: GPR_PCIE1_ PHY_I_AUX_ EN_OVERRIDE_ EN:
> {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN,
> GPR_PCIE1_PHY_FUNC_I_AUX_EN}
>  2'b00 External Reference Clock I/O (for PLL) Disable
>  2'b01 External Reference Clock I/O (for PLL) Enable
>  2'b10 External Reference Clock I/O (for PLL) Disable
>  2'b11 External Reference Clock I/O (for PLL) output is controlled by CLKREQ#
> 
> How is it they define this as a single bit then give descriptions for
> 2 bits? Something is wrong here.
> 
[Richard Zhu] The descriptions are not correct, please ignore them.

> > +                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_AUX_EN,
> > +                          IMX8MM_GPR_PCIE_AUX_EN);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_POWER_OFF, 0);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_SSC_EN, 0);
> > +
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > +                          imx8_phy->refclk_pad_mode == 1 ?
> 
> imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT
[Richard Zhu] Got that. Thanks.

BR
Richard
> 
> Best regards,
> 
> Tim
> 
> > +                          IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > +                          IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > +       usleep_range(100, 200);
> > +
> > +       /* Do the PHY common block reset */
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_CMN_RST,
> > +                          IMX8MM_GPR_PCIE_CMN_RST);
> > +       usleep_range(200, 500);
> > +
> > +
> > +       pad_mode = imx8_phy->refclk_pad_mode;
> > +       if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> > +               /* Configure the pad as input */
> > +               val = readl(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +               writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +       } else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> > +               /* Configure the PHY to output the refclock via pad */
> > +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG062);
> > +               writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG063);
> > +               val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> > +               writel(val | ANA_AUX_RX_TERM_GND_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG064);
> > +               writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG065);
> > +       }
> > +
> > +       /* Tune PHY de-emphasis setting to pass PCIe compliance. */
> > +       writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> > +              imx8_phy->base + PCIE_PHY_TRSV_REG5);
> > +       writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> > +              imx8_phy->base + PCIE_PHY_TRSV_REG6);
> > +
> > +       reset_control_deassert(imx8_phy->reset);
> > +
> > +       /* Polling to check the phy is ready or not. */
> > +       ret = readl_poll_timeout(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG75,
> > +                                val, val ==
> PCIE_PHY_CMN_REG75_PLL_DONE,
> > +                                10, 20000);
> > +       return ret;
> > +}
> > +
> > +static int imx8_pcie_phy_power_on(struct phy *phy) {
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       return clk_prepare_enable(imx8_phy->clk);
> > +}
> > +
> > +static int imx8_pcie_phy_power_off(struct phy *phy) {
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       clk_disable_unprepare(imx8_phy->clk);
> > +
> > +       return 0;
> > +}
> > +
> > +static const struct phy_ops imx8_pcie_phy_ops = {
> > +       .init           = imx8_pcie_phy_init,
> > +       .power_on       = imx8_pcie_phy_power_on,
> > +       .power_off      = imx8_pcie_phy_power_off,
> > +       .owner          = THIS_MODULE,
> > +};
> > +
> > +static int imx8_pcie_phy_probe(struct platform_device *pdev) {
> > +       struct phy_provider *phy_provider;
> > +       struct device *dev = &pdev->dev;
> > +       struct device_node *np = dev->of_node;
> > +       struct imx8_pcie_phy *imx8_phy;
> > +       struct resource *res;
> > +
> > +       imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> > +       if (!imx8_phy)
> > +               return -ENOMEM;
> > +
> > +       /* get PHY refclk pad mode */
> > +       of_property_read_u32(np, "fsl,refclk-pad-mode",
> > +                            &imx8_phy->refclk_pad_mode);
> > +
> > +       imx8_phy->clk = devm_clk_get(dev, "phy");
> > +       if (IS_ERR(imx8_phy->clk)) {
> > +               dev_err(dev, "failed to get imx pcie phy clock\n");
> > +               return PTR_ERR(imx8_phy->clk);
> > +       }
> > +
> > +       /* Grab GPR config register range */
> > +       imx8_phy->iomuxc_gpr =
> > +
> syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> > +       if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> > +               dev_err(dev, "unable to find iomuxc registers\n");
> > +               return PTR_ERR(imx8_phy->iomuxc_gpr);
> > +       }
> > +
> > +       imx8_phy->reset = devm_reset_control_get_exclusive(dev,
> "pciephy");
> > +       if (IS_ERR(imx8_phy->reset)) {
> > +               dev_err(dev, "Failed to get PCIEPHY reset control\n");
> > +               return PTR_ERR(imx8_phy->reset);
> > +       }
> > +
> > +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +       imx8_phy->base = devm_ioremap_resource(dev, res);
> > +       if (IS_ERR(imx8_phy->base))
> > +               return PTR_ERR(imx8_phy->base);
> > +
> > +       imx8_phy->phy = devm_phy_create(dev, NULL,
> &imx8_pcie_phy_ops);
> > +       if (IS_ERR(imx8_phy->phy))
> > +               return PTR_ERR(imx8_phy->phy);
> > +
> > +       phy_set_drvdata(imx8_phy->phy, imx8_phy);
> > +
> > +       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 imx8_pcie_phy_of_match[] = {
> > +       {.compatible = "fsl,imx8mm-pcie-phy",},
> > +       { },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> > +
> > +static struct platform_driver imx8_pcie_phy_driver = {
> > +       .probe  = imx8_pcie_phy_probe,
> > +       .driver = {
> > +               .name   = "imx8-pcie-phy",
> > +               .of_match_table = imx8_pcie_phy_of_match,
> > +       }
> > +};
> > +module_platform_driver(imx8_pcie_phy_driver);
> > +
> > +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.25.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Friday, October 22, 2021 12:00 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> standalone phy driver
> 
> On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > Add the standalone i.MX8 PCIe PHY driver.
> > Some reset bits should be manipulated between PHY configurations and
> > status check(internal PLL is locked or not).
> > So, do the PHY configuration in the phy_calibrate().
> > And check the PHY is ready or not in the phy_init().
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/phy/freescale/Kconfig              |   9 +
> >  drivers/phy/freescale/Makefile             |   1 +
> >  drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218
> > +++++++++++++++++++++
> >  3 files changed, 228 insertions(+)
> >  create mode 100644 drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> >
> > diff --git a/drivers/phy/freescale/Kconfig
> > b/drivers/phy/freescale/Kconfig index 320630ffe3cd..fb08e5242602
> > 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -14,3 +14,12 @@ config PHY_MIXEL_MIPI_DPHY
> >         help
> >           Enable this to add support for the Mixel DSI PHY as found
> >           on NXP's i.MX8 family of SOCs.
> > +
> > +config PHY_FSL_IMX8M_PCIE
> > +       tristate "Freescale i.MX8 PCIE PHY"
> > +       depends on OF && HAS_IOMEM
> > +       select GENERIC_PHY
> > +       default ARCH_MXC
> > +       help
> > +         Enable this to add support for the PCIE PHY as found on
> > +         i.MX8M family of SOCs.
> > diff --git a/drivers/phy/freescale/Makefile
> > b/drivers/phy/freescale/Makefile index 1d02e3869b45..55d07c742ab0
> > 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -1,3 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)       += phy-fsl-imx8mq-usb.o
> >  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      +=
> phy-fsl-imx8-mipi-dphy.o
> > +obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > new file mode 100644
> > index 000000000000..317cf61bff37
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -0,0 +1,218 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2021 NXP
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/delay.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> > +#include <linux/module.h>
> > +#include <linux/phy/phy.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset.h>
> > +#include <dt-bindings/phy/phy-imx8-pcie.h>
> > +
> > +#define IMX8MM_PCIE_PHY_CMN_REG061     0x184
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_EN  BIT(0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG062     0x188
> > +#define  ANA_PLL_CLK_OUT_TO_EXT_IO_SEL BIT(3)
> > +#define IMX8MM_PCIE_PHY_CMN_REG063     0x18C
> > +#define  AUX_PLL_REFCLK_SEL_SYS_PLL    GENMASK(7, 6)
> > +#define IMX8MM_PCIE_PHY_CMN_REG064     0x190
> > +#define  ANA_AUX_RX_TX_SEL_TX          BIT(7)
> > +#define  ANA_AUX_RX_TERM_GND_EN                BIT(3)
> > +#define  ANA_AUX_TX_TERM               BIT(2)
> > +#define IMX8MM_PCIE_PHY_CMN_REG065     0x194
> > +#define  ANA_AUX_RX_TERM               (BIT(7) | BIT(4))
> > +#define  ANA_AUX_TX_LVL                        GENMASK(3, 0)
> > +#define IMX8MM_PCIE_PHY_CMN_REG75      0x1D4
> > +#define  PCIE_PHY_CMN_REG75_PLL_DONE   0x3
> > +#define PCIE_PHY_TRSV_REG5             0x414
> > +#define  PCIE_PHY_TRSV_REG5_GEN1_DEEMP 0x2D
> > +#define PCIE_PHY_TRSV_REG6             0x418
> > +#define  PCIE_PHY_TRSV_REG6_GEN2_DEEMP 0xF
> > +
> > +#define IMX8MM_GPR_PCIE_REF_CLK_SEL    GENMASK(25, 24)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_PLL
> FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> > +#define IMX8MM_GPR_PCIE_REF_CLK_EXT
> FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> > +#define IMX8MM_GPR_PCIE_AUX_EN         BIT(19)
> > +#define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> > +#define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> > +#define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > +#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +
> > +struct imx8_pcie_phy {
> > +       u32                     refclk_pad_mode;
> > +       void __iomem            *base;
> > +       struct clk              *clk;
> > +       struct phy              *phy;
> > +       struct regmap           *iomuxc_gpr;
> > +       struct reset_control    *reset;
> > +};
> > +
> > +static int imx8_pcie_phy_init(struct phy *phy) {
> > +       int ret;
> > +       u32 val, pad_mode;
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       reset_control_assert(imx8_phy->reset);
> > +
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > +                          imx8_phy->refclk_pad_mode == 1 ?
> 
> Hi Richard,
> 
> use the enumerated type for the comparison above for clarity:
> imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT
> 
> Also, this is the configuration that makes my imx8mm-venice boards which do
> not use CLKREQ# hang while waiting for PHY. I am setting in my dt:
> &pcie_phy {
>         fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
>         clocks = <&clk IMX8MM_CLK_DUMMY>;
>         status = "okay";
> };
> 
> The NXP kernel woudl always set this bit to 0 which makes my board work.
> 
> The IMX8MMRM documentation appears incorrect here:
> IOMUXC_GPR_GPR14 bit 9: GPR_PCIE1_ PHY_I_AUX_ EN_OVERRIDE_ EN:
> {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN,
> GPR_PCIE1_PHY_FUNC_I_AUX_EN}
>  2'b00 External Reference Clock I/O (for PLL) Disable
>  2'b01 External Reference Clock I/O (for PLL) Enable
>  2'b10 External Reference Clock I/O (for PLL) Disable
>  2'b11 External Reference Clock I/O (for PLL) output is controlled by CLKREQ#
> 
> How is it they define this as a single bit then give descriptions for
> 2 bits? Something is wrong here.
> 
[Richard Zhu] The descriptions are not correct, please ignore them.

> > +                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_AUX_EN,
> > +                          IMX8MM_GPR_PCIE_AUX_EN);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_POWER_OFF, 0);
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_SSC_EN, 0);
> > +
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > +                          imx8_phy->refclk_pad_mode == 1 ?
> 
> imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT
[Richard Zhu] Got that. Thanks.

BR
Richard
> 
> Best regards,
> 
> Tim
> 
> > +                          IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > +                          IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > +       usleep_range(100, 200);
> > +
> > +       /* Do the PHY common block reset */
> > +       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > +                          IMX8MM_GPR_PCIE_CMN_RST,
> > +                          IMX8MM_GPR_PCIE_CMN_RST);
> > +       usleep_range(200, 500);
> > +
> > +
> > +       pad_mode = imx8_phy->refclk_pad_mode;
> > +       if (pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT) {
> > +               /* Configure the pad as input */
> > +               val = readl(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +               writel(val & ~ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +       } else if (pad_mode == IMX8_PCIE_REFCLK_PAD_OUTPUT) {
> > +               /* Configure the PHY to output the refclock via pad */
> > +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG061);
> > +               writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG062);
> > +               writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG063);
> > +               val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
> > +               writel(val | ANA_AUX_RX_TERM_GND_EN,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG064);
> > +               writel(ANA_AUX_RX_TERM | ANA_AUX_TX_LVL,
> > +                      imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG065);
> > +       }
> > +
> > +       /* Tune PHY de-emphasis setting to pass PCIe compliance. */
> > +       writel(PCIE_PHY_TRSV_REG5_GEN1_DEEMP,
> > +              imx8_phy->base + PCIE_PHY_TRSV_REG5);
> > +       writel(PCIE_PHY_TRSV_REG6_GEN2_DEEMP,
> > +              imx8_phy->base + PCIE_PHY_TRSV_REG6);
> > +
> > +       reset_control_deassert(imx8_phy->reset);
> > +
> > +       /* Polling to check the phy is ready or not. */
> > +       ret = readl_poll_timeout(imx8_phy->base +
> IMX8MM_PCIE_PHY_CMN_REG75,
> > +                                val, val ==
> PCIE_PHY_CMN_REG75_PLL_DONE,
> > +                                10, 20000);
> > +       return ret;
> > +}
> > +
> > +static int imx8_pcie_phy_power_on(struct phy *phy) {
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       return clk_prepare_enable(imx8_phy->clk);
> > +}
> > +
> > +static int imx8_pcie_phy_power_off(struct phy *phy) {
> > +       struct imx8_pcie_phy *imx8_phy = phy_get_drvdata(phy);
> > +
> > +       clk_disable_unprepare(imx8_phy->clk);
> > +
> > +       return 0;
> > +}
> > +
> > +static const struct phy_ops imx8_pcie_phy_ops = {
> > +       .init           = imx8_pcie_phy_init,
> > +       .power_on       = imx8_pcie_phy_power_on,
> > +       .power_off      = imx8_pcie_phy_power_off,
> > +       .owner          = THIS_MODULE,
> > +};
> > +
> > +static int imx8_pcie_phy_probe(struct platform_device *pdev) {
> > +       struct phy_provider *phy_provider;
> > +       struct device *dev = &pdev->dev;
> > +       struct device_node *np = dev->of_node;
> > +       struct imx8_pcie_phy *imx8_phy;
> > +       struct resource *res;
> > +
> > +       imx8_phy = devm_kzalloc(dev, sizeof(*imx8_phy), GFP_KERNEL);
> > +       if (!imx8_phy)
> > +               return -ENOMEM;
> > +
> > +       /* get PHY refclk pad mode */
> > +       of_property_read_u32(np, "fsl,refclk-pad-mode",
> > +                            &imx8_phy->refclk_pad_mode);
> > +
> > +       imx8_phy->clk = devm_clk_get(dev, "phy");
> > +       if (IS_ERR(imx8_phy->clk)) {
> > +               dev_err(dev, "failed to get imx pcie phy clock\n");
> > +               return PTR_ERR(imx8_phy->clk);
> > +       }
> > +
> > +       /* Grab GPR config register range */
> > +       imx8_phy->iomuxc_gpr =
> > +
> syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> > +       if (IS_ERR(imx8_phy->iomuxc_gpr)) {
> > +               dev_err(dev, "unable to find iomuxc registers\n");
> > +               return PTR_ERR(imx8_phy->iomuxc_gpr);
> > +       }
> > +
> > +       imx8_phy->reset = devm_reset_control_get_exclusive(dev,
> "pciephy");
> > +       if (IS_ERR(imx8_phy->reset)) {
> > +               dev_err(dev, "Failed to get PCIEPHY reset control\n");
> > +               return PTR_ERR(imx8_phy->reset);
> > +       }
> > +
> > +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +       imx8_phy->base = devm_ioremap_resource(dev, res);
> > +       if (IS_ERR(imx8_phy->base))
> > +               return PTR_ERR(imx8_phy->base);
> > +
> > +       imx8_phy->phy = devm_phy_create(dev, NULL,
> &imx8_pcie_phy_ops);
> > +       if (IS_ERR(imx8_phy->phy))
> > +               return PTR_ERR(imx8_phy->phy);
> > +
> > +       phy_set_drvdata(imx8_phy->phy, imx8_phy);
> > +
> > +       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 imx8_pcie_phy_of_match[] = {
> > +       {.compatible = "fsl,imx8mm-pcie-phy",},
> > +       { },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx8_pcie_phy_of_match);
> > +
> > +static struct platform_driver imx8_pcie_phy_driver = {
> > +       .probe  = imx8_pcie_phy_probe,
> > +       .driver = {
> > +               .name   = "imx8-pcie-phy",
> > +               .of_match_table = imx8_pcie_phy_of_match,
> > +       }
> > +};
> > +module_platform_driver(imx8_pcie_phy_driver);
> > +
> > +MODULE_DESCRIPTION("FSL IMX8 PCIE PHY driver");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.25.1
> >
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Richard Zhu]

i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties
in the binding document.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 2911e565b260..99d9863a69cd 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -128,6 +128,12 @@ properties:
     enum: [1, 2, 3, 4]
     default: 1
 
+  phys:
+    description: Phandle of the Generic PHY to the PCIe PHY.
+
+  phy-names:
+    const: pcie-phy
+
   reset-gpio:
     description: Should specify the GPIO for controlling the PCI bus device
       reset signal. It's not polarity aware and defaults to active-low reset
-- 
2.25.1

[PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Richard Zhu]

i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties
in the binding document.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 2911e565b260..99d9863a69cd 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -128,6 +128,12 @@ properties:
     enum: [1, 2, 3, 4]
     default: 1
 
+  phys:
+    description: Phandle of the Generic PHY to the PCIe PHY.
+
+  phy-names:
+    const: pcie-phy
+
   reset-gpio:
     description: Should specify the GPIO for controlling the PCI bus device
       reset signal. It's not polarity aware and defaults to active-low reset
-- 
2.25.1


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

[PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Richard Zhu]

i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties
in the binding document.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 2911e565b260..99d9863a69cd 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -128,6 +128,12 @@ properties:
     enum: [1, 2, 3, 4]
     default: 1
 
+  phys:
+    description: Phandle of the Generic PHY to the PCIe PHY.
+
+  phy-names:
+    const: pcie-phy
+
   reset-gpio:
     description: Should specify the GPIO for controlling the PCI bus device
       reset signal. It's not polarity aware and defaults to active-low reset
-- 
2.25.1


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

Re: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Rob Herring]

On Tue, Oct 12, 2021 at 04:41:15PM +0800, Richard Zhu wrote:
> i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties
> in the binding document.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index 2911e565b260..99d9863a69cd 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -128,6 +128,12 @@ properties:
>      enum: [1, 2, 3, 4]
>      default: 1
>  
> +  phys:
> +    description: Phandle of the Generic PHY to the PCIe PHY.

maxItems: 1

And drop 'description'

> +
> +  phy-names:
> +    const: pcie-phy
> +
>    reset-gpio:
>      description: Should specify the GPIO for controlling the PCI bus device
>        reset signal. It's not polarity aware and defaults to active-low reset
> -- 
> 2.25.1
> 
> 

Re: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Rob Herring]

On Tue, Oct 12, 2021 at 04:41:15PM +0800, Richard Zhu wrote:
> i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties
> in the binding document.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index 2911e565b260..99d9863a69cd 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -128,6 +128,12 @@ properties:
>      enum: [1, 2, 3, 4]
>      default: 1
>  
> +  phys:
> +    description: Phandle of the Generic PHY to the PCIe PHY.

maxItems: 1

And drop 'description'

> +
> +  phy-names:
> +    const: pcie-phy
> +
>    reset-gpio:
>      description: Should specify the GPIO for controlling the PCI bus device
>        reset signal. It's not polarity aware and defaults to active-low reset
> -- 
> 2.25.1
> 
> 

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

Re: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Rob Herring]

On Tue, Oct 12, 2021 at 04:41:15PM +0800, Richard Zhu wrote:
> i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties
> in the binding document.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index 2911e565b260..99d9863a69cd 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -128,6 +128,12 @@ properties:
>      enum: [1, 2, 3, 4]
>      default: 1
>  
> +  phys:
> +    description: Phandle of the Generic PHY to the PCIe PHY.

maxItems: 1

And drop 'description'

> +
> +  phy-names:
> +    const: pcie-phy
> +
>    reset-gpio:
>      description: Should specify the GPIO for controlling the PCI bus device
>        reset signal. It's not polarity aware and defaults to active-low reset
> -- 
> 2.25.1
> 
> 

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

RE: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Richard Zhu]

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, October 19, 2021 3:18 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: l.stach@pengutronix.de; tharvey@gateworks.com; kishon@ti.com;
> vkoul@kernel.org; galak@kernel.crashing.org; shawnguo@kernel.org;
> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and
> name properties
> 
> On Tue, Oct 12, 2021 at 04:41:15PM +0800, Richard Zhu wrote:
> > i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties in the
> > binding document.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index 2911e565b260..99d9863a69cd 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -128,6 +128,12 @@ properties:
> >      enum: [1, 2, 3, 4]
> >      default: 1
> >
> > +  phys:
> > +    description: Phandle of the Generic PHY to the PCIe PHY.
> 
> maxItems: 1
> 
> And drop 'description'
[Richard Zhu] Hi Rob: 
Do you mean to remove all the description, and just like this?
  phys:
    maxItems: 1
Ok, got that, would be changed as this one in v4 series later.
Thanks.

Best Regards
Richard Zhu

> 
> > +
> > +  phy-names:
> > +    const: pcie-phy
> > +
> >    reset-gpio:
> >      description: Should specify the GPIO for controlling the PCI bus
> device
> >        reset signal. It's not polarity aware and defaults to
> > active-low reset
> > --
> > 2.25.1
> >
> >

RE: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Richard Zhu]

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, October 19, 2021 3:18 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: l.stach@pengutronix.de; tharvey@gateworks.com; kishon@ti.com;
> vkoul@kernel.org; galak@kernel.crashing.org; shawnguo@kernel.org;
> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and
> name properties
> 
> On Tue, Oct 12, 2021 at 04:41:15PM +0800, Richard Zhu wrote:
> > i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties in the
> > binding document.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index 2911e565b260..99d9863a69cd 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -128,6 +128,12 @@ properties:
> >      enum: [1, 2, 3, 4]
> >      default: 1
> >
> > +  phys:
> > +    description: Phandle of the Generic PHY to the PCIe PHY.
> 
> maxItems: 1
> 
> And drop 'description'
[Richard Zhu] Hi Rob: 
Do you mean to remove all the description, and just like this?
  phys:
    maxItems: 1
Ok, got that, would be changed as this one in v4 series later.
Thanks.

Best Regards
Richard Zhu

> 
> > +
> > +  phy-names:
> > +    const: pcie-phy
> > +
> >    reset-gpio:
> >      description: Should specify the GPIO for controlling the PCI bus
> device
> >        reset signal. It's not polarity aware and defaults to
> > active-low reset
> > --
> > 2.25.1
> >
> >

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

RE: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name properties

[Richard Zhu]

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, October 19, 2021 3:18 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: l.stach@pengutronix.de; tharvey@gateworks.com; kishon@ti.com;
> vkoul@kernel.org; galak@kernel.crashing.org; shawnguo@kernel.org;
> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and
> name properties
> 
> On Tue, Oct 12, 2021 at 04:41:15PM +0800, Richard Zhu wrote:
> > i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties in the
> > binding document.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index 2911e565b260..99d9863a69cd 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -128,6 +128,12 @@ properties:
> >      enum: [1, 2, 3, 4]
> >      default: 1
> >
> > +  phys:
> > +    description: Phandle of the Generic PHY to the PCIe PHY.
> 
> maxItems: 1
> 
> And drop 'description'
[Richard Zhu] Hi Rob: 
Do you mean to remove all the description, and just like this?
  phys:
    maxItems: 1
Ok, got that, would be changed as this one in v4 series later.
Thanks.

Best Regards
Richard Zhu

> 
> > +
> > +  phy-names:
> > +    const: pcie-phy
> > +
> >    reset-gpio:
> >      description: Should specify the GPIO for controlling the PCI bus
> device
> >        reset signal. It's not polarity aware and defaults to
> > active-low reset
> > --
> > 2.25.1
> >
> >

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

[PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support

[Richard Zhu]

Add the PCIe support on i.MX8MM platforms.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 33 ++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index ac5d11466608..e4819a811da8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -520,7 +520,7 @@ iomuxc: pinctrl@30330000 {
 			};
 
 			gpr: iomuxc-gpr@30340000 {
-				compatible = "fsl,imx8mm-iomuxc-gpr", "syscon";
+				compatible = "fsl,imx8mm-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon";
 				reg = <0x30340000 0x10000>;
 			};
 
@@ -1179,6 +1179,37 @@ gpmi: nand-controller@33002000{
 			status = "disabled";
 		};
 
+		pcie0: pcie@33800000 {
+			compatible = "fsl,imx8mm-pcie";
+			reg = <0x33800000 0x400000>, <0x1ff00000 0x80000>;
+			reg-names = "dbi", "config";
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			bus-range = <0x00 0xff>;
+			ranges =  <0x81000000 0 0x00000000 0x1ff80000 0 0x00010000 /* downstream I/O 64KB */
+				   0x82000000 0 0x18000000 0x18000000 0 0x07f00000>; /* non-prefetchable memory */
+			num-lanes = <1>;
+			num-viewport = <4>;
+			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "msi";
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &gic GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 2 &gic GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 3 &gic GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 4 &gic GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+			fsl,max-link-speed = <2>;
+			linux,pci-domain = <0>;
+			power-domains = <&pgc_pcie>;
+			resets = <&src IMX8MQ_RESET_PCIE_CTRL_APPS_EN>,
+				 <&src IMX8MQ_RESET_PCIE_CTRL_APPS_TURNOFF>;
+			reset-names = "apps", "turnoff";
+			phys = <&pcie_phy>;
+			phy-names = "pcie-phy";
+			status = "disabled";
+		};
+
 		gpu_3d: gpu@38000000 {
 			compatible = "vivante,gc";
 			reg = <0x38000000 0x8000>;
-- 
2.25.1

[PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support

[Richard Zhu]

Add the PCIe support on i.MX8MM platforms.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 33 ++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index ac5d11466608..e4819a811da8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -520,7 +520,7 @@ iomuxc: pinctrl@30330000 {
 			};
 
 			gpr: iomuxc-gpr@30340000 {
-				compatible = "fsl,imx8mm-iomuxc-gpr", "syscon";
+				compatible = "fsl,imx8mm-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon";
 				reg = <0x30340000 0x10000>;
 			};
 
@@ -1179,6 +1179,37 @@ gpmi: nand-controller@33002000{
 			status = "disabled";
 		};
 
+		pcie0: pcie@33800000 {
+			compatible = "fsl,imx8mm-pcie";
+			reg = <0x33800000 0x400000>, <0x1ff00000 0x80000>;
+			reg-names = "dbi", "config";
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			bus-range = <0x00 0xff>;
+			ranges =  <0x81000000 0 0x00000000 0x1ff80000 0 0x00010000 /* downstream I/O 64KB */
+				   0x82000000 0 0x18000000 0x18000000 0 0x07f00000>; /* non-prefetchable memory */
+			num-lanes = <1>;
+			num-viewport = <4>;
+			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "msi";
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &gic GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 2 &gic GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 3 &gic GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 4 &gic GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+			fsl,max-link-speed = <2>;
+			linux,pci-domain = <0>;
+			power-domains = <&pgc_pcie>;
+			resets = <&src IMX8MQ_RESET_PCIE_CTRL_APPS_EN>,
+				 <&src IMX8MQ_RESET_PCIE_CTRL_APPS_TURNOFF>;
+			reset-names = "apps", "turnoff";
+			phys = <&pcie_phy>;
+			phy-names = "pcie-phy";
+			status = "disabled";
+		};
+
 		gpu_3d: gpu@38000000 {
 			compatible = "vivante,gc";
 			reg = <0x38000000 0x8000>;
-- 
2.25.1


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

[PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support

[Richard Zhu]

Add the PCIe support on i.MX8MM platforms.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 33 ++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index ac5d11466608..e4819a811da8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -520,7 +520,7 @@ iomuxc: pinctrl@30330000 {
 			};
 
 			gpr: iomuxc-gpr@30340000 {
-				compatible = "fsl,imx8mm-iomuxc-gpr", "syscon";
+				compatible = "fsl,imx8mm-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon";
 				reg = <0x30340000 0x10000>;
 			};
 
@@ -1179,6 +1179,37 @@ gpmi: nand-controller@33002000{
 			status = "disabled";
 		};
 
+		pcie0: pcie@33800000 {
+			compatible = "fsl,imx8mm-pcie";
+			reg = <0x33800000 0x400000>, <0x1ff00000 0x80000>;
+			reg-names = "dbi", "config";
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			bus-range = <0x00 0xff>;
+			ranges =  <0x81000000 0 0x00000000 0x1ff80000 0 0x00010000 /* downstream I/O 64KB */
+				   0x82000000 0 0x18000000 0x18000000 0 0x07f00000>; /* non-prefetchable memory */
+			num-lanes = <1>;
+			num-viewport = <4>;
+			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "msi";
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &gic GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 2 &gic GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 3 &gic GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 4 &gic GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+			fsl,max-link-speed = <2>;
+			linux,pci-domain = <0>;
+			power-domains = <&pgc_pcie>;
+			resets = <&src IMX8MQ_RESET_PCIE_CTRL_APPS_EN>,
+				 <&src IMX8MQ_RESET_PCIE_CTRL_APPS_TURNOFF>;
+			reset-names = "apps", "turnoff";
+			phys = <&pcie_phy>;
+			phy-names = "pcie-phy";
+			status = "disabled";
+		};
+
 		gpu_3d: gpu@38000000 {
 			compatible = "vivante,gc";
 			reg = <0x38000000 0x8000>;
-- 
2.25.1


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

[PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Richard Zhu]

Add the PCIe support on i.MX8MM EVK board.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index 2d0684ac82f6..5ce43daa0c8b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -31,6 +31,23 @@ status {
 		};
 	};
 
+	pcie0_refclk: pcie0-refclk {
+		compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <100000000>;
+	};
+
+	reg_pcie0_gpio: regulator-pcie-gpio {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pcie0_reg>;
+		regulator-name = "MPCIE_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
 	reg_usdhc2_vmmc: regulator-usdhc2 {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
@@ -296,6 +313,22 @@ &pcie_phy {
 	status = "okay";
 };
 
+&pcie0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pcie0>;
+	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
+	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
+	assigned-clock-rates = <10000000>, <250000000>;
+	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+				 <&clk IMX8MM_SYS_PLL2_250M>;
+	vpcie-supply = <&reg_pcie0_gpio>;
+	status = "okay";
+};
+
 &sai3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_sai3>;
@@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x400001c3
 		>;
 	};
 
+	pinctrl_pcie0: pcie0grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
+			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
+		>;
+	};
+
+	pinctrl_pcie0_reg: pcie0reggrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
+		>;
+	};
+
 	pinctrl_pmic: pmicirqgrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141
-- 
2.25.1

[PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Richard Zhu]

Add the PCIe support on i.MX8MM EVK board.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index 2d0684ac82f6..5ce43daa0c8b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -31,6 +31,23 @@ status {
 		};
 	};
 
+	pcie0_refclk: pcie0-refclk {
+		compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <100000000>;
+	};
+
+	reg_pcie0_gpio: regulator-pcie-gpio {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pcie0_reg>;
+		regulator-name = "MPCIE_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
 	reg_usdhc2_vmmc: regulator-usdhc2 {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
@@ -296,6 +313,22 @@ &pcie_phy {
 	status = "okay";
 };
 
+&pcie0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pcie0>;
+	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
+	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
+	assigned-clock-rates = <10000000>, <250000000>;
+	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+				 <&clk IMX8MM_SYS_PLL2_250M>;
+	vpcie-supply = <&reg_pcie0_gpio>;
+	status = "okay";
+};
+
 &sai3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_sai3>;
@@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x400001c3
 		>;
 	};
 
+	pinctrl_pcie0: pcie0grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
+			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
+		>;
+	};
+
+	pinctrl_pcie0_reg: pcie0reggrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
+		>;
+	};
+
 	pinctrl_pmic: pmicirqgrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141
-- 
2.25.1


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

[PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Richard Zhu]

Add the PCIe support on i.MX8MM EVK board.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index 2d0684ac82f6..5ce43daa0c8b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -31,6 +31,23 @@ status {
 		};
 	};
 
+	pcie0_refclk: pcie0-refclk {
+		compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <100000000>;
+	};
+
+	reg_pcie0_gpio: regulator-pcie-gpio {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pcie0_reg>;
+		regulator-name = "MPCIE_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
 	reg_usdhc2_vmmc: regulator-usdhc2 {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
@@ -296,6 +313,22 @@ &pcie_phy {
 	status = "okay";
 };
 
+&pcie0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pcie0>;
+	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
+	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
+	assigned-clock-rates = <10000000>, <250000000>;
+	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+				 <&clk IMX8MM_SYS_PLL2_250M>;
+	vpcie-supply = <&reg_pcie0_gpio>;
+	status = "okay";
+};
+
 &sai3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_sai3>;
@@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x400001c3
 		>;
 	};
 
+	pinctrl_pcie0: pcie0grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
+			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
+		>;
+	};
+
+	pinctrl_pcie0_reg: pcie0reggrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
+		>;
+	};
+
 	pinctrl_pmic: pmicirqgrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141
-- 
2.25.1


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

Re: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe support on i.MX8MM EVK board.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index 2d0684ac82f6..5ce43daa0c8b 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -31,6 +31,23 @@ status {
>  		};
>  	};
>  
> +	pcie0_refclk: pcie0-refclk {
> +		compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <100000000>;
> +	};

This is both the PHY reference and bus clock. I guess you could just
squash Patch 4/9 into this one, as they are both required to get PCIe
on the EVK board.

> +
> +	reg_pcie0_gpio: regulator-pcie-gpio {

Drop the gpio suffix.

> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pcie0_reg>;
> +		regulator-name = "MPCIE_3V3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +
>  	reg_usdhc2_vmmc: regulator-usdhc2 {
>  		compatible = "regulator-fixed";
>  		pinctrl-names = "default";
> @@ -296,6 +313,22 @@ &pcie_phy {
>  	status = "okay";
>  };
>  
> +&pcie0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pcie0>;
> +	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
> +	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
> +		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;

The i.MX8MM PCIe driver should not request the pcie_phy clock. Please
add a change in the driver, so we don't need to hook up a useless dummy
clock to this node.

Regards,
Lucas

> +	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +	assigned-clock-rates = <10000000>, <250000000>;
> +	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +				 <&clk IMX8MM_SYS_PLL2_250M>;
> +	vpcie-supply = <&reg_pcie0_gpio>;
> +	status = "okay";
> +};
> +
>  &sai3 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_sai3>;
> @@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x400001c3
>  		>;
>  	};
>  
> +	pinctrl_pcie0: pcie0grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> +			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
> +		>;
> +	};
> +
> +	pinctrl_pcie0_reg: pcie0reggrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
> +		>;
> +	};
> +
>  	pinctrl_pmic: pmicirqgrp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141

Re: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe support on i.MX8MM EVK board.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index 2d0684ac82f6..5ce43daa0c8b 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -31,6 +31,23 @@ status {
>  		};
>  	};
>  
> +	pcie0_refclk: pcie0-refclk {
> +		compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <100000000>;
> +	};

This is both the PHY reference and bus clock. I guess you could just
squash Patch 4/9 into this one, as they are both required to get PCIe
on the EVK board.

> +
> +	reg_pcie0_gpio: regulator-pcie-gpio {

Drop the gpio suffix.

> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pcie0_reg>;
> +		regulator-name = "MPCIE_3V3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +
>  	reg_usdhc2_vmmc: regulator-usdhc2 {
>  		compatible = "regulator-fixed";
>  		pinctrl-names = "default";
> @@ -296,6 +313,22 @@ &pcie_phy {
>  	status = "okay";
>  };
>  
> +&pcie0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pcie0>;
> +	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
> +	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
> +		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;

The i.MX8MM PCIe driver should not request the pcie_phy clock. Please
add a change in the driver, so we don't need to hook up a useless dummy
clock to this node.

Regards,
Lucas

> +	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +	assigned-clock-rates = <10000000>, <250000000>;
> +	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +				 <&clk IMX8MM_SYS_PLL2_250M>;
> +	vpcie-supply = <&reg_pcie0_gpio>;
> +	status = "okay";
> +};
> +
>  &sai3 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_sai3>;
> @@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x400001c3
>  		>;
>  	};
>  
> +	pinctrl_pcie0: pcie0grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> +			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
> +		>;
> +	};
> +
> +	pinctrl_pcie0_reg: pcie0reggrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
> +		>;
> +	};
> +
>  	pinctrl_pmic: pmicirqgrp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141



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

Re: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> Add the PCIe support on i.MX8MM EVK board.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index 2d0684ac82f6..5ce43daa0c8b 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -31,6 +31,23 @@ status {
>  		};
>  	};
>  
> +	pcie0_refclk: pcie0-refclk {
> +		compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <100000000>;
> +	};

This is both the PHY reference and bus clock. I guess you could just
squash Patch 4/9 into this one, as they are both required to get PCIe
on the EVK board.

> +
> +	reg_pcie0_gpio: regulator-pcie-gpio {

Drop the gpio suffix.

> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pcie0_reg>;
> +		regulator-name = "MPCIE_3V3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +
>  	reg_usdhc2_vmmc: regulator-usdhc2 {
>  		compatible = "regulator-fixed";
>  		pinctrl-names = "default";
> @@ -296,6 +313,22 @@ &pcie_phy {
>  	status = "okay";
>  };
>  
> +&pcie0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pcie0>;
> +	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
> +	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
> +		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;

The i.MX8MM PCIe driver should not request the pcie_phy clock. Please
add a change in the driver, so we don't need to hook up a useless dummy
clock to this node.

Regards,
Lucas

> +	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +	assigned-clock-rates = <10000000>, <250000000>;
> +	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +				 <&clk IMX8MM_SYS_PLL2_250M>;
> +	vpcie-supply = <&reg_pcie0_gpio>;
> +	status = "okay";
> +};
> +
>  &sai3 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_sai3>;
> @@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x400001c3
>  		>;
>  	};
>  
> +	pinctrl_pcie0: pcie0grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> +			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
> +		>;
> +	};
> +
> +	pinctrl_pcie0_reg: pcie0reggrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
> +		>;
> +	};
> +
>  	pinctrl_pmic: pmicirqgrp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141



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

RE: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 3:04 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on
> imx8mm evk board
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe support on i.MX8MM EVK board.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46
> > +++++++++++++++++++
> >  1 file changed, 46 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index 2d0684ac82f6..5ce43daa0c8b 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -31,6 +31,23 @@ status {
> >  		};
> >  	};
> >
> > +	pcie0_refclk: pcie0-refclk {
> > +		compatible = "fixed-clock";
> > +			#clock-cells = <0>;
> > +			clock-frequency = <100000000>;
> > +	};
> 
> This is both the PHY reference and bus clock. I guess you could just squash
> Patch 4/9 into this one, as they are both required to get PCIe on the EVK
> board.
> 
[Richard Zhu] Okay, agree with that. Would squash #4 with #8 together.
Thanks.

> > +
> > +	reg_pcie0_gpio: regulator-pcie-gpio {
> 
> Drop the gpio suffix.
[Richard Zhu] Okay, would be dropped.

> 
> > +		compatible = "regulator-fixed";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_pcie0_reg>;
> > +		regulator-name = "MPCIE_3V3";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +	};
> > +
> >  	reg_usdhc2_vmmc: regulator-usdhc2 {
> >  		compatible = "regulator-fixed";
> >  		pinctrl-names = "default";
> > @@ -296,6 +313,22 @@ &pcie_phy {
> >  	status = "okay";
> >  };
> >
> > +&pcie0 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_pcie0>;
> > +	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
> > +	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> > +		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> 
> The i.MX8MM PCIe driver should not request the pcie_phy clock. Please add
> a change in the driver, so we don't need to hook up a useless dummy clock to
> this node.
[Richard Zhu] Okay, thanks.

> 
> Regards,
> Lucas
> 
> > +	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> > +	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> > +			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
> > +	assigned-clock-rates = <10000000>, <250000000>;
> > +	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> > +				 <&clk IMX8MM_SYS_PLL2_250M>;
> > +	vpcie-supply = <&reg_pcie0_gpio>;
> > +	status = "okay";
> > +};
> > +
> >  &sai3 {
> >  	pinctrl-names = "default";
> >  	pinctrl-0 = <&pinctrl_sai3>;
> > @@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA
> 	0x400001c3
> >  		>;
> >  	};
> >
> > +	pinctrl_pcie0: pcie0grp {
> > +		fsl,pins = <
> > +			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > +			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
> > +		>;
> > +	};
> > +
> > +	pinctrl_pcie0_reg: pcie0reggrp {
> > +		fsl,pins = <
> > +			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
> > +		>;
> > +	};
> > +
> >  	pinctrl_pmic: pmicirqgrp {
> >  		fsl,pins = <
> >  			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141
> 

RE: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 3:04 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on
> imx8mm evk board
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe support on i.MX8MM EVK board.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46
> > +++++++++++++++++++
> >  1 file changed, 46 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index 2d0684ac82f6..5ce43daa0c8b 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -31,6 +31,23 @@ status {
> >  		};
> >  	};
> >
> > +	pcie0_refclk: pcie0-refclk {
> > +		compatible = "fixed-clock";
> > +			#clock-cells = <0>;
> > +			clock-frequency = <100000000>;
> > +	};
> 
> This is both the PHY reference and bus clock. I guess you could just squash
> Patch 4/9 into this one, as they are both required to get PCIe on the EVK
> board.
> 
[Richard Zhu] Okay, agree with that. Would squash #4 with #8 together.
Thanks.

> > +
> > +	reg_pcie0_gpio: regulator-pcie-gpio {
> 
> Drop the gpio suffix.
[Richard Zhu] Okay, would be dropped.

> 
> > +		compatible = "regulator-fixed";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_pcie0_reg>;
> > +		regulator-name = "MPCIE_3V3";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +	};
> > +
> >  	reg_usdhc2_vmmc: regulator-usdhc2 {
> >  		compatible = "regulator-fixed";
> >  		pinctrl-names = "default";
> > @@ -296,6 +313,22 @@ &pcie_phy {
> >  	status = "okay";
> >  };
> >
> > +&pcie0 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_pcie0>;
> > +	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
> > +	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> > +		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> 
> The i.MX8MM PCIe driver should not request the pcie_phy clock. Please add
> a change in the driver, so we don't need to hook up a useless dummy clock to
> this node.
[Richard Zhu] Okay, thanks.

> 
> Regards,
> Lucas
> 
> > +	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> > +	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> > +			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
> > +	assigned-clock-rates = <10000000>, <250000000>;
> > +	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> > +				 <&clk IMX8MM_SYS_PLL2_250M>;
> > +	vpcie-supply = <&reg_pcie0_gpio>;
> > +	status = "okay";
> > +};
> > +
> >  &sai3 {
> >  	pinctrl-names = "default";
> >  	pinctrl-0 = <&pinctrl_sai3>;
> > @@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA
> 	0x400001c3
> >  		>;
> >  	};
> >
> > +	pinctrl_pcie0: pcie0grp {
> > +		fsl,pins = <
> > +			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > +			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
> > +		>;
> > +	};
> > +
> > +	pinctrl_pcie0_reg: pcie0reggrp {
> > +		fsl,pins = <
> > +			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
> > +		>;
> > +	};
> > +
> >  	pinctrl_pmic: pmicirqgrp {
> >  		fsl,pins = <
> >  			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141
> 

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

RE: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm evk board

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 3:04 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on
> imx8mm evk board
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > Add the PCIe support on i.MX8MM EVK board.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 46
> > +++++++++++++++++++
> >  1 file changed, 46 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index 2d0684ac82f6..5ce43daa0c8b 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -31,6 +31,23 @@ status {
> >  		};
> >  	};
> >
> > +	pcie0_refclk: pcie0-refclk {
> > +		compatible = "fixed-clock";
> > +			#clock-cells = <0>;
> > +			clock-frequency = <100000000>;
> > +	};
> 
> This is both the PHY reference and bus clock. I guess you could just squash
> Patch 4/9 into this one, as they are both required to get PCIe on the EVK
> board.
> 
[Richard Zhu] Okay, agree with that. Would squash #4 with #8 together.
Thanks.

> > +
> > +	reg_pcie0_gpio: regulator-pcie-gpio {
> 
> Drop the gpio suffix.
[Richard Zhu] Okay, would be dropped.

> 
> > +		compatible = "regulator-fixed";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_pcie0_reg>;
> > +		regulator-name = "MPCIE_3V3";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +	};
> > +
> >  	reg_usdhc2_vmmc: regulator-usdhc2 {
> >  		compatible = "regulator-fixed";
> >  		pinctrl-names = "default";
> > @@ -296,6 +313,22 @@ &pcie_phy {
> >  	status = "okay";
> >  };
> >
> > +&pcie0 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_pcie0>;
> > +	reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
> > +	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> > +		 <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> 
> The i.MX8MM PCIe driver should not request the pcie_phy clock. Please add
> a change in the driver, so we don't need to hook up a useless dummy clock to
> this node.
[Richard Zhu] Okay, thanks.

> 
> Regards,
> Lucas
> 
> > +	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> > +	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> > +			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
> > +	assigned-clock-rates = <10000000>, <250000000>;
> > +	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> > +				 <&clk IMX8MM_SYS_PLL2_250M>;
> > +	vpcie-supply = <&reg_pcie0_gpio>;
> > +	status = "okay";
> > +};
> > +
> >  &sai3 {
> >  	pinctrl-names = "default";
> >  	pinctrl-0 = <&pinctrl_sai3>;
> > @@ -413,6 +446,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA
> 	0x400001c3
> >  		>;
> >  	};
> >
> > +	pinctrl_pcie0: pcie0grp {
> > +		fsl,pins = <
> > +			MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > +			MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
> > +		>;
> > +	};
> > +
> > +	pinctrl_pcie0_reg: pcie0reggrp {
> > +		fsl,pins = <
> > +			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
> > +		>;
> > +	};
> > +
> >  	pinctrl_pmic: pmicirqgrp {
> >  		fsl,pins = <
> >  			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141
> 

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

[PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
and allows to output the internal PHY reference clock via the refclk pad.
Add the i.MX8MM PCIe support based on the standalone PHY driver.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 63 ++++++++++++++++++++++++++-
 1 file changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 26f49f797b0f..73022e37b1c5 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -29,6 +29,7 @@
 #include <linux/types.h>
 #include <linux/interrupt.h>
 #include <linux/reset.h>
+#include <linux/phy/phy.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
@@ -49,6 +50,7 @@ enum imx6_pcie_variants {
 	IMX6QP,
 	IMX7D,
 	IMX8MQ,
+	IMX8MM,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
@@ -80,6 +82,7 @@ struct imx6_pcie {
 	u32			tx_deemph_gen2_6db;
 	u32			tx_swing_full;
 	u32			tx_swing_low;
+	u32			refclk_pad_mode;
 	struct regulator	*vpcie;
 	struct regulator	*vph;
 	void __iomem		*phy_base;
@@ -88,6 +91,7 @@ struct imx6_pcie {
 	struct device		*pd_pcie;
 	/* power domain for pcie phy */
 	struct device		*pd_pcie_phy;
+	struct phy		*phy;
 	const struct imx6_pcie_drvdata *drvdata;
 };
 
@@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 	case IMX7D:
 	case IMX8MQ:
 		reset_control_assert(imx6_pcie->pciephy_reset);
+		fallthrough;
+	case IMX8MM:
 		reset_control_assert(imx6_pcie->apps_reset);
 		break;
 	case IMX6SX:
@@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 
 static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 {
-	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
+	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
+		imx6_pcie->drvdata->variant != IMX8MM);
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
@@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX7D:
 		break;
 	case IMX8MQ:
+	case IMX8MM:
 		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
 		if (ret) {
 			dev_err(dev, "unable to enable pcie_aux clock\n");
@@ -522,6 +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 		goto err_ref_clk;
 	}
 
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX8MM:
+		if (phy_power_on(imx6_pcie->phy))
+			pr_info("unable to enable pcie phy clock\n");
+		break;
+	default:
+		break;
+	}
 	/* allow the clocks to stabilize */
 	usleep_range(200, 500);
 
@@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ:
 		reset_control_deassert(imx6_pcie->pciephy_reset);
 		break;
+	case IMX8MM:
+		if (phy_init(imx6_pcie->phy) != 0)
+			dev_err(dev, "Waiting for PHY ready timeout!\n");
+		break;
 	case IMX7D:
 		reset_control_deassert(imx6_pcie->pciephy_reset);
 
@@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX8MM:
+		break;
 	case IMX8MQ:
 		/*
 		 * TODO: Currently this code assumes external
@@ -753,6 +775,7 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 		break;
 	case IMX7D:
 	case IMX8MQ:
+	case IMX8MM:
 		reset_control_deassert(imx6_pcie->apps_reset);
 		break;
 	}
@@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
 	case IMX7D:
+	case IMX8MM:
 		reset_control_assert(imx6_pcie->apps_reset);
 		break;
 	default:
@@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
 	case IMX8MQ:
+	case IMX8MM:
 		clk_disable_unprepare(imx6_pcie->pcie_aux);
 		break;
 	default:
@@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	struct imx6_pcie *imx6_pcie;
 	struct device_node *np;
 	struct resource *dbi_base;
+	struct device_node *phy_node;
 	struct device_node *node = dev->of_node;
 	int ret;
 	u16 val;
@@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return PTR_ERR(imx6_pcie->phy_base);
 	}
 
+	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+	if (IS_ERR(imx6_pcie->phy)) {
+		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+		/* Set NULL if there is no pcie-phy */
+		imx6_pcie->phy = NULL;
+	}
+
 	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
 	if (IS_ERR(pci->dbi_base))
@@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return PTR_ERR(imx6_pcie->apps_reset);
 		}
 		break;
+	case IMX8MM:
+		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
+		if (IS_ERR(imx6_pcie->pcie_aux))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
+					     "pcie_aux clock source missing or invalid\n");
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
+									 "apps");
+		if (IS_ERR(imx6_pcie->apps_reset)) {
+			dev_err(dev, "Failed to get PCIE APPS reset control\n");
+			return PTR_ERR(imx6_pcie->apps_reset);
+		}
+		break;
 	default:
 		break;
 	}
@@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 				 &imx6_pcie->tx_swing_low))
 		imx6_pcie->tx_swing_low = 127;
 
+	/* get PHY refclk pad mode if there is PHY node */
+	phy_node = of_parse_phandle(node, "phys", 0);
+	if (phy_node) {
+		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
+				     &imx6_pcie->refclk_pad_mode);
+		of_node_put(phy_node);
+	}
+
 	/* Limit link speed */
 	pci->link_gen = 1;
 	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen);
@@ -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
 	},
+	[IMX8MM] = {
+		.variant = IMX8MM,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+	},
 };
 
 static const struct of_device_id imx6_pcie_of_match[] = {
@@ -1209,7 +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
 	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
 	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
-	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
+	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
+	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{},
 };
 
-- 
2.25.1

[PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
and allows to output the internal PHY reference clock via the refclk pad.
Add the i.MX8MM PCIe support based on the standalone PHY driver.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 63 ++++++++++++++++++++++++++-
 1 file changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 26f49f797b0f..73022e37b1c5 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -29,6 +29,7 @@
 #include <linux/types.h>
 #include <linux/interrupt.h>
 #include <linux/reset.h>
+#include <linux/phy/phy.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
@@ -49,6 +50,7 @@ enum imx6_pcie_variants {
 	IMX6QP,
 	IMX7D,
 	IMX8MQ,
+	IMX8MM,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
@@ -80,6 +82,7 @@ struct imx6_pcie {
 	u32			tx_deemph_gen2_6db;
 	u32			tx_swing_full;
 	u32			tx_swing_low;
+	u32			refclk_pad_mode;
 	struct regulator	*vpcie;
 	struct regulator	*vph;
 	void __iomem		*phy_base;
@@ -88,6 +91,7 @@ struct imx6_pcie {
 	struct device		*pd_pcie;
 	/* power domain for pcie phy */
 	struct device		*pd_pcie_phy;
+	struct phy		*phy;
 	const struct imx6_pcie_drvdata *drvdata;
 };
 
@@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 	case IMX7D:
 	case IMX8MQ:
 		reset_control_assert(imx6_pcie->pciephy_reset);
+		fallthrough;
+	case IMX8MM:
 		reset_control_assert(imx6_pcie->apps_reset);
 		break;
 	case IMX6SX:
@@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 
 static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 {
-	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
+	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
+		imx6_pcie->drvdata->variant != IMX8MM);
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
@@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX7D:
 		break;
 	case IMX8MQ:
+	case IMX8MM:
 		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
 		if (ret) {
 			dev_err(dev, "unable to enable pcie_aux clock\n");
@@ -522,6 +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 		goto err_ref_clk;
 	}
 
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX8MM:
+		if (phy_power_on(imx6_pcie->phy))
+			pr_info("unable to enable pcie phy clock\n");
+		break;
+	default:
+		break;
+	}
 	/* allow the clocks to stabilize */
 	usleep_range(200, 500);
 
@@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ:
 		reset_control_deassert(imx6_pcie->pciephy_reset);
 		break;
+	case IMX8MM:
+		if (phy_init(imx6_pcie->phy) != 0)
+			dev_err(dev, "Waiting for PHY ready timeout!\n");
+		break;
 	case IMX7D:
 		reset_control_deassert(imx6_pcie->pciephy_reset);
 
@@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX8MM:
+		break;
 	case IMX8MQ:
 		/*
 		 * TODO: Currently this code assumes external
@@ -753,6 +775,7 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 		break;
 	case IMX7D:
 	case IMX8MQ:
+	case IMX8MM:
 		reset_control_deassert(imx6_pcie->apps_reset);
 		break;
 	}
@@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
 	case IMX7D:
+	case IMX8MM:
 		reset_control_assert(imx6_pcie->apps_reset);
 		break;
 	default:
@@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
 	case IMX8MQ:
+	case IMX8MM:
 		clk_disable_unprepare(imx6_pcie->pcie_aux);
 		break;
 	default:
@@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	struct imx6_pcie *imx6_pcie;
 	struct device_node *np;
 	struct resource *dbi_base;
+	struct device_node *phy_node;
 	struct device_node *node = dev->of_node;
 	int ret;
 	u16 val;
@@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return PTR_ERR(imx6_pcie->phy_base);
 	}
 
+	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+	if (IS_ERR(imx6_pcie->phy)) {
+		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+		/* Set NULL if there is no pcie-phy */
+		imx6_pcie->phy = NULL;
+	}
+
 	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
 	if (IS_ERR(pci->dbi_base))
@@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return PTR_ERR(imx6_pcie->apps_reset);
 		}
 		break;
+	case IMX8MM:
+		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
+		if (IS_ERR(imx6_pcie->pcie_aux))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
+					     "pcie_aux clock source missing or invalid\n");
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
+									 "apps");
+		if (IS_ERR(imx6_pcie->apps_reset)) {
+			dev_err(dev, "Failed to get PCIE APPS reset control\n");
+			return PTR_ERR(imx6_pcie->apps_reset);
+		}
+		break;
 	default:
 		break;
 	}
@@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 				 &imx6_pcie->tx_swing_low))
 		imx6_pcie->tx_swing_low = 127;
 
+	/* get PHY refclk pad mode if there is PHY node */
+	phy_node = of_parse_phandle(node, "phys", 0);
+	if (phy_node) {
+		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
+				     &imx6_pcie->refclk_pad_mode);
+		of_node_put(phy_node);
+	}
+
 	/* Limit link speed */
 	pci->link_gen = 1;
 	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen);
@@ -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
 	},
+	[IMX8MM] = {
+		.variant = IMX8MM,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+	},
 };
 
 static const struct of_device_id imx6_pcie_of_match[] = {
@@ -1209,7 +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
 	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
 	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
-	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
+	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
+	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{},
 };
 
-- 
2.25.1


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

[PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
and allows to output the internal PHY reference clock via the refclk pad.
Add the i.MX8MM PCIe support based on the standalone PHY driver.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 63 ++++++++++++++++++++++++++-
 1 file changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 26f49f797b0f..73022e37b1c5 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -29,6 +29,7 @@
 #include <linux/types.h>
 #include <linux/interrupt.h>
 #include <linux/reset.h>
+#include <linux/phy/phy.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
@@ -49,6 +50,7 @@ enum imx6_pcie_variants {
 	IMX6QP,
 	IMX7D,
 	IMX8MQ,
+	IMX8MM,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
@@ -80,6 +82,7 @@ struct imx6_pcie {
 	u32			tx_deemph_gen2_6db;
 	u32			tx_swing_full;
 	u32			tx_swing_low;
+	u32			refclk_pad_mode;
 	struct regulator	*vpcie;
 	struct regulator	*vph;
 	void __iomem		*phy_base;
@@ -88,6 +91,7 @@ struct imx6_pcie {
 	struct device		*pd_pcie;
 	/* power domain for pcie phy */
 	struct device		*pd_pcie_phy;
+	struct phy		*phy;
 	const struct imx6_pcie_drvdata *drvdata;
 };
 
@@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 	case IMX7D:
 	case IMX8MQ:
 		reset_control_assert(imx6_pcie->pciephy_reset);
+		fallthrough;
+	case IMX8MM:
 		reset_control_assert(imx6_pcie->apps_reset);
 		break;
 	case IMX6SX:
@@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 
 static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 {
-	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
+	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
+		imx6_pcie->drvdata->variant != IMX8MM);
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
@@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX7D:
 		break;
 	case IMX8MQ:
+	case IMX8MM:
 		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
 		if (ret) {
 			dev_err(dev, "unable to enable pcie_aux clock\n");
@@ -522,6 +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 		goto err_ref_clk;
 	}
 
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX8MM:
+		if (phy_power_on(imx6_pcie->phy))
+			pr_info("unable to enable pcie phy clock\n");
+		break;
+	default:
+		break;
+	}
 	/* allow the clocks to stabilize */
 	usleep_range(200, 500);
 
@@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ:
 		reset_control_deassert(imx6_pcie->pciephy_reset);
 		break;
+	case IMX8MM:
+		if (phy_init(imx6_pcie->phy) != 0)
+			dev_err(dev, "Waiting for PHY ready timeout!\n");
+		break;
 	case IMX7D:
 		reset_control_deassert(imx6_pcie->pciephy_reset);
 
@@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX8MM:
+		break;
 	case IMX8MQ:
 		/*
 		 * TODO: Currently this code assumes external
@@ -753,6 +775,7 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 		break;
 	case IMX7D:
 	case IMX8MQ:
+	case IMX8MM:
 		reset_control_deassert(imx6_pcie->apps_reset);
 		break;
 	}
@@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
 	case IMX7D:
+	case IMX8MM:
 		reset_control_assert(imx6_pcie->apps_reset);
 		break;
 	default:
@@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
 	case IMX8MQ:
+	case IMX8MM:
 		clk_disable_unprepare(imx6_pcie->pcie_aux);
 		break;
 	default:
@@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	struct imx6_pcie *imx6_pcie;
 	struct device_node *np;
 	struct resource *dbi_base;
+	struct device_node *phy_node;
 	struct device_node *node = dev->of_node;
 	int ret;
 	u16 val;
@@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return PTR_ERR(imx6_pcie->phy_base);
 	}
 
+	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+	if (IS_ERR(imx6_pcie->phy)) {
+		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+		/* Set NULL if there is no pcie-phy */
+		imx6_pcie->phy = NULL;
+	}
+
 	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
 	if (IS_ERR(pci->dbi_base))
@@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return PTR_ERR(imx6_pcie->apps_reset);
 		}
 		break;
+	case IMX8MM:
+		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
+		if (IS_ERR(imx6_pcie->pcie_aux))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
+					     "pcie_aux clock source missing or invalid\n");
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
+									 "apps");
+		if (IS_ERR(imx6_pcie->apps_reset)) {
+			dev_err(dev, "Failed to get PCIE APPS reset control\n");
+			return PTR_ERR(imx6_pcie->apps_reset);
+		}
+		break;
 	default:
 		break;
 	}
@@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 				 &imx6_pcie->tx_swing_low))
 		imx6_pcie->tx_swing_low = 127;
 
+	/* get PHY refclk pad mode if there is PHY node */
+	phy_node = of_parse_phandle(node, "phys", 0);
+	if (phy_node) {
+		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
+				     &imx6_pcie->refclk_pad_mode);
+		of_node_put(phy_node);
+	}
+
 	/* Limit link speed */
 	pci->link_gen = 1;
 	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen);
@@ -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
 	},
+	[IMX8MM] = {
+		.variant = IMX8MM,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+	},
 };
 
 static const struct of_device_id imx6_pcie_of_match[] = {
@@ -1209,7 +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
 	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
 	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
-	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
+	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
+	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{},
 };
 
-- 
2.25.1


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

Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Matthias Schiffer]

On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
> and allows to output the internal PHY reference clock via the refclk pad.
> Add the i.MX8MM PCIe support based on the standalone PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
> [...]
> @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  				 &imx6_pcie->tx_swing_low))
>  		imx6_pcie->tx_swing_low = 127;
>  
> +	/* get PHY refclk pad mode if there is PHY node */
> +	phy_node = of_parse_phandle(node, "phys", 0);
> +	if (phy_node) {
> +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> +				     &imx6_pcie->refclk_pad_mode);

It seems to me that the refclk_pad_mode is not actually used by this
driver anymore, because it is handled by the PHY driver now. Is there a
reason to read this property here at all?

Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Matthias Schiffer]

On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
> and allows to output the internal PHY reference clock via the refclk pad.
> Add the i.MX8MM PCIe support based on the standalone PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
> [...]
> @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  				 &imx6_pcie->tx_swing_low))
>  		imx6_pcie->tx_swing_low = 127;
>  
> +	/* get PHY refclk pad mode if there is PHY node */
> +	phy_node = of_parse_phandle(node, "phys", 0);
> +	if (phy_node) {
> +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> +				     &imx6_pcie->refclk_pad_mode);

It seems to me that the refclk_pad_mode is not actually used by this
driver anymore, because it is handled by the PHY driver now. Is there a
reason to read this property here at all?



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

Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Matthias Schiffer]

On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
> and allows to output the internal PHY reference clock via the refclk pad.
> Add the i.MX8MM PCIe support based on the standalone PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
> [...]
> @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  				 &imx6_pcie->tx_swing_low))
>  		imx6_pcie->tx_swing_low = 127;
>  
> +	/* get PHY refclk pad mode if there is PHY node */
> +	phy_node = of_parse_phandle(node, "phys", 0);
> +	if (phy_node) {
> +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> +				     &imx6_pcie->refclk_pad_mode);

It seems to me that the refclk_pad_mode is not actually used by this
driver anymore, because it is handled by the PHY driver now. Is there a
reason to read this property here at all?



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

RE: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> Sent: Wednesday, October 13, 2021 8:46 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>;
> l.stach@pengutronix.de; tharvey@gateworks.com; kishon@ti.com;
> vkoul@kernel.org; robh@kernel.org; galak@kernel.crashing.org;
> shawnguo@kernel.org
> Subject: Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
> 
> On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> > i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different
> > PHY and allows to output the internal PHY reference clock via the refclk
> pad.
> > Add the i.MX8MM PCIe support based on the standalone PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> > [...]
> > @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  				 &imx6_pcie->tx_swing_low))
> >  		imx6_pcie->tx_swing_low = 127;
> >
> > +	/* get PHY refclk pad mode if there is PHY node */
> > +	phy_node = of_parse_phandle(node, "phys", 0);
> > +	if (phy_node) {
> > +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> > +				     &imx6_pcie->refclk_pad_mode);
> 
> It seems to me that the refclk_pad_mode is not actually used by this driver
> anymore, because it is handled by the PHY driver now. Is there a reason to
> read this property here at all?
>
[Richard Zhu] Good caught. I forgot to clean up the refclk_pad_mode in controller driver.
Would remove these codes later. Thanks a lot.

Best Regards
Richard Zhu
 

RE: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> Sent: Wednesday, October 13, 2021 8:46 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>;
> l.stach@pengutronix.de; tharvey@gateworks.com; kishon@ti.com;
> vkoul@kernel.org; robh@kernel.org; galak@kernel.crashing.org;
> shawnguo@kernel.org
> Subject: Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
> 
> On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> > i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different
> > PHY and allows to output the internal PHY reference clock via the refclk
> pad.
> > Add the i.MX8MM PCIe support based on the standalone PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> > [...]
> > @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  				 &imx6_pcie->tx_swing_low))
> >  		imx6_pcie->tx_swing_low = 127;
> >
> > +	/* get PHY refclk pad mode if there is PHY node */
> > +	phy_node = of_parse_phandle(node, "phys", 0);
> > +	if (phy_node) {
> > +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> > +				     &imx6_pcie->refclk_pad_mode);
> 
> It seems to me that the refclk_pad_mode is not actually used by this driver
> anymore, because it is handled by the PHY driver now. Is there a reason to
> read this property here at all?
>
[Richard Zhu] Good caught. I forgot to clean up the refclk_pad_mode in controller driver.
Would remove these codes later. Thanks a lot.

Best Regards
Richard Zhu
 

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

RE: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> Sent: Wednesday, October 13, 2021 8:46 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>;
> l.stach@pengutronix.de; tharvey@gateworks.com; kishon@ti.com;
> vkoul@kernel.org; robh@kernel.org; galak@kernel.crashing.org;
> shawnguo@kernel.org
> Subject: Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
> 
> On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> > i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different
> > PHY and allows to output the internal PHY reference clock via the refclk
> pad.
> > Add the i.MX8MM PCIe support based on the standalone PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> > [...]
> > @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  				 &imx6_pcie->tx_swing_low))
> >  		imx6_pcie->tx_swing_low = 127;
> >
> > +	/* get PHY refclk pad mode if there is PHY node */
> > +	phy_node = of_parse_phandle(node, "phys", 0);
> > +	if (phy_node) {
> > +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> > +				     &imx6_pcie->refclk_pad_mode);
> 
> It seems to me that the refclk_pad_mode is not actually used by this driver
> anymore, because it is handled by the PHY driver now. Is there a reason to
> read this property here at all?
>
[Richard Zhu] Good caught. I forgot to clean up the refclk_pad_mode in controller driver.
Would remove these codes later. Thanks a lot.

Best Regards
Richard Zhu
 

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

Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
> and allows to output the internal PHY reference clock via the refclk pad.
> Add the i.MX8MM PCIe support based on the standalone PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 63 ++++++++++++++++++++++++++-
>  1 file changed, 61 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 26f49f797b0f..73022e37b1c5 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -29,6 +29,7 @@
>  #include <linux/types.h>
>  #include <linux/interrupt.h>
>  #include <linux/reset.h>
> +#include <linux/phy/phy.h>
>  #include <linux/pm_domain.h>
>  #include <linux/pm_runtime.h>
>  
> @@ -49,6 +50,7 @@ enum imx6_pcie_variants {
>  	IMX6QP,
>  	IMX7D,
>  	IMX8MQ,
> +	IMX8MM,
>  };
>  
>  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
> @@ -80,6 +82,7 @@ struct imx6_pcie {
>  	u32			tx_deemph_gen2_6db;
>  	u32			tx_swing_full;
>  	u32			tx_swing_low;
> +	u32			refclk_pad_mode;

As Matthias already noticed: drop this.

>  	struct regulator	*vpcie;
>  	struct regulator	*vph;
>  	void __iomem		*phy_base;
> @@ -88,6 +91,7 @@ struct imx6_pcie {
>  	struct device		*pd_pcie;
>  	/* power domain for pcie phy */
>  	struct device		*pd_pcie_phy;
> +	struct phy		*phy;
>  	const struct imx6_pcie_drvdata *drvdata;
>  };
>  
> @@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>  	case IMX7D:
>  	case IMX8MQ:
>  		reset_control_assert(imx6_pcie->pciephy_reset);
> +		fallthrough;
> +	case IMX8MM:
>  		reset_control_assert(imx6_pcie->apps_reset);
>  		break;
>  	case IMX6SX:
> @@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>  
>  static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
>  {
> -	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
> +	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
> +		imx6_pcie->drvdata->variant != IMX8MM);
>  	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
>  }
>  
> @@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
>  	case IMX7D:
>  		break;
>  	case IMX8MQ:
> +	case IMX8MM:
>  		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
>  		if (ret) {
>  			dev_err(dev, "unable to enable pcie_aux clock\n");
> @@ -522,6 +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
>  		goto err_ref_clk;
>  	}
>  
> +	switch (imx6_pcie->drvdata->variant) {
> +	case IMX8MM:
> +		if (phy_power_on(imx6_pcie->phy))
> +			pr_info("unable to enable pcie phy clock\n");

It a implementation detail of the PHY driver that this just turns on
the clock. dev_err("unable to power on PHY\n") or something like that.

> +		break;
> +	default:
> +		break;
> +	}
>  	/* allow the clocks to stabilize */
>  	usleep_range(200, 500);
>  
> @@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
>  	case IMX8MQ:
>  		reset_control_deassert(imx6_pcie->pciephy_reset);
>  		break;
> +	case IMX8MM:
> +		if (phy_init(imx6_pcie->phy) != 0)
> +			dev_err(dev, "Waiting for PHY ready timeout!\n");
> +		break;
>  	case IMX7D:
>  		reset_control_deassert(imx6_pcie->pciephy_reset);
>  
> @@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
>  static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
>  {
>  	switch (imx6_pcie->drvdata->variant) {
> +	case IMX8MM:
> +		break;
>  	case IMX8MQ:
>  		/*
>  		 * TODO: Currently this code assumes external
> @@ -753,6 +775,7 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
>  		break;
>  	case IMX7D:
>  	case IMX8MQ:
> +	case IMX8MM:
>  		reset_control_deassert(imx6_pcie->apps_reset);
>  		break;
>  	}
> @@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
>  				   IMX6Q_GPR12_PCIE_CTL_2, 0);
>  		break;
>  	case IMX7D:
> +	case IMX8MM:
>  		reset_control_assert(imx6_pcie->apps_reset);
>  		break;
>  	default:
> @@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
>  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
>  		break;
>  	case IMX8MQ:
> +	case IMX8MM:
>  		clk_disable_unprepare(imx6_pcie->pcie_aux);
>  		break;
>  	default:
> @@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	struct imx6_pcie *imx6_pcie;
>  	struct device_node *np;
>  	struct resource *dbi_base;
> +	struct device_node *phy_node;
>  	struct device_node *node = dev->of_node;
>  	int ret;
>  	u16 val;
> @@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  			return PTR_ERR(imx6_pcie->phy_base);
>  	}
>  
> +	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> +	if (IS_ERR(imx6_pcie->phy)) {
> +		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +		/* Set NULL if there is no pcie-phy */
> +		imx6_pcie->phy = NULL;
> +	}

Move this into the i.MX8MM specific section below. The PHY is required
on the 8MM and we should not ignore any errors.

Regards,
Lucas

> +
>  	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
>  	if (IS_ERR(pci->dbi_base))
> @@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  			return PTR_ERR(imx6_pcie->apps_reset);
>  		}
>  		break;
> +	case IMX8MM:
> +		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> +		if (IS_ERR(imx6_pcie->pcie_aux))
> +			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> +					     "pcie_aux clock source missing or invalid\n");
> +		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> +									 "apps");
> +		if (IS_ERR(imx6_pcie->apps_reset)) {
> +			dev_err(dev, "Failed to get PCIE APPS reset control\n");
> +			return PTR_ERR(imx6_pcie->apps_reset);
> +		}
> +		break;
>  	default:
>  		break;
>  	}
> @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  				 &imx6_pcie->tx_swing_low))
>  		imx6_pcie->tx_swing_low = 127;
>  
> +	/* get PHY refclk pad mode if there is PHY node */
> +	phy_node = of_parse_phandle(node, "phys", 0);
> +	if (phy_node) {
> +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> +				     &imx6_pcie->refclk_pad_mode);
> +		of_node_put(phy_node);
> +	}
> +
>  	/* Limit link speed */
>  	pci->link_gen = 1;
>  	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen);
> @@ -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
>  	[IMX8MQ] = {
>  		.variant = IMX8MQ,
>  	},
> +	[IMX8MM] = {
> +		.variant = IMX8MM,
> +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +	},
>  };
>  
>  static const struct of_device_id imx6_pcie_of_match[] = {
> @@ -1209,7 +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
>  	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
>  	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
>  	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
> -	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
> +	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
> +	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
>  	{},
>  };
>  

Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
> and allows to output the internal PHY reference clock via the refclk pad.
> Add the i.MX8MM PCIe support based on the standalone PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 63 ++++++++++++++++++++++++++-
>  1 file changed, 61 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 26f49f797b0f..73022e37b1c5 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -29,6 +29,7 @@
>  #include <linux/types.h>
>  #include <linux/interrupt.h>
>  #include <linux/reset.h>
> +#include <linux/phy/phy.h>
>  #include <linux/pm_domain.h>
>  #include <linux/pm_runtime.h>
>  
> @@ -49,6 +50,7 @@ enum imx6_pcie_variants {
>  	IMX6QP,
>  	IMX7D,
>  	IMX8MQ,
> +	IMX8MM,
>  };
>  
>  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
> @@ -80,6 +82,7 @@ struct imx6_pcie {
>  	u32			tx_deemph_gen2_6db;
>  	u32			tx_swing_full;
>  	u32			tx_swing_low;
> +	u32			refclk_pad_mode;

As Matthias already noticed: drop this.

>  	struct regulator	*vpcie;
>  	struct regulator	*vph;
>  	void __iomem		*phy_base;
> @@ -88,6 +91,7 @@ struct imx6_pcie {
>  	struct device		*pd_pcie;
>  	/* power domain for pcie phy */
>  	struct device		*pd_pcie_phy;
> +	struct phy		*phy;
>  	const struct imx6_pcie_drvdata *drvdata;
>  };
>  
> @@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>  	case IMX7D:
>  	case IMX8MQ:
>  		reset_control_assert(imx6_pcie->pciephy_reset);
> +		fallthrough;
> +	case IMX8MM:
>  		reset_control_assert(imx6_pcie->apps_reset);
>  		break;
>  	case IMX6SX:
> @@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>  
>  static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
>  {
> -	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
> +	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
> +		imx6_pcie->drvdata->variant != IMX8MM);
>  	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
>  }
>  
> @@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
>  	case IMX7D:
>  		break;
>  	case IMX8MQ:
> +	case IMX8MM:
>  		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
>  		if (ret) {
>  			dev_err(dev, "unable to enable pcie_aux clock\n");
> @@ -522,6 +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
>  		goto err_ref_clk;
>  	}
>  
> +	switch (imx6_pcie->drvdata->variant) {
> +	case IMX8MM:
> +		if (phy_power_on(imx6_pcie->phy))
> +			pr_info("unable to enable pcie phy clock\n");

It a implementation detail of the PHY driver that this just turns on
the clock. dev_err("unable to power on PHY\n") or something like that.

> +		break;
> +	default:
> +		break;
> +	}
>  	/* allow the clocks to stabilize */
>  	usleep_range(200, 500);
>  
> @@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
>  	case IMX8MQ:
>  		reset_control_deassert(imx6_pcie->pciephy_reset);
>  		break;
> +	case IMX8MM:
> +		if (phy_init(imx6_pcie->phy) != 0)
> +			dev_err(dev, "Waiting for PHY ready timeout!\n");
> +		break;
>  	case IMX7D:
>  		reset_control_deassert(imx6_pcie->pciephy_reset);
>  
> @@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
>  static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
>  {
>  	switch (imx6_pcie->drvdata->variant) {
> +	case IMX8MM:
> +		break;
>  	case IMX8MQ:
>  		/*
>  		 * TODO: Currently this code assumes external
> @@ -753,6 +775,7 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
>  		break;
>  	case IMX7D:
>  	case IMX8MQ:
> +	case IMX8MM:
>  		reset_control_deassert(imx6_pcie->apps_reset);
>  		break;
>  	}
> @@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
>  				   IMX6Q_GPR12_PCIE_CTL_2, 0);
>  		break;
>  	case IMX7D:
> +	case IMX8MM:
>  		reset_control_assert(imx6_pcie->apps_reset);
>  		break;
>  	default:
> @@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
>  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
>  		break;
>  	case IMX8MQ:
> +	case IMX8MM:
>  		clk_disable_unprepare(imx6_pcie->pcie_aux);
>  		break;
>  	default:
> @@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	struct imx6_pcie *imx6_pcie;
>  	struct device_node *np;
>  	struct resource *dbi_base;
> +	struct device_node *phy_node;
>  	struct device_node *node = dev->of_node;
>  	int ret;
>  	u16 val;
> @@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  			return PTR_ERR(imx6_pcie->phy_base);
>  	}
>  
> +	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> +	if (IS_ERR(imx6_pcie->phy)) {
> +		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +		/* Set NULL if there is no pcie-phy */
> +		imx6_pcie->phy = NULL;
> +	}

Move this into the i.MX8MM specific section below. The PHY is required
on the 8MM and we should not ignore any errors.

Regards,
Lucas

> +
>  	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
>  	if (IS_ERR(pci->dbi_base))
> @@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  			return PTR_ERR(imx6_pcie->apps_reset);
>  		}
>  		break;
> +	case IMX8MM:
> +		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> +		if (IS_ERR(imx6_pcie->pcie_aux))
> +			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> +					     "pcie_aux clock source missing or invalid\n");
> +		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> +									 "apps");
> +		if (IS_ERR(imx6_pcie->apps_reset)) {
> +			dev_err(dev, "Failed to get PCIE APPS reset control\n");
> +			return PTR_ERR(imx6_pcie->apps_reset);
> +		}
> +		break;
>  	default:
>  		break;
>  	}
> @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  				 &imx6_pcie->tx_swing_low))
>  		imx6_pcie->tx_swing_low = 127;
>  
> +	/* get PHY refclk pad mode if there is PHY node */
> +	phy_node = of_parse_phandle(node, "phys", 0);
> +	if (phy_node) {
> +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> +				     &imx6_pcie->refclk_pad_mode);
> +		of_node_put(phy_node);
> +	}
> +
>  	/* Limit link speed */
>  	pci->link_gen = 1;
>  	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen);
> @@ -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
>  	[IMX8MQ] = {
>  		.variant = IMX8MQ,
>  	},
> +	[IMX8MM] = {
> +		.variant = IMX8MM,
> +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +	},
>  };
>  
>  static const struct of_device_id imx6_pcie_of_match[] = {
> @@ -1209,7 +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
>  	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
>  	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
>  	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
> -	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
> +	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
> +	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
>  	{},
>  };
>  



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

Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Lucas Stach]

Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
> and allows to output the internal PHY reference clock via the refclk pad.
> Add the i.MX8MM PCIe support based on the standalone PHY driver.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 63 ++++++++++++++++++++++++++-
>  1 file changed, 61 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 26f49f797b0f..73022e37b1c5 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -29,6 +29,7 @@
>  #include <linux/types.h>
>  #include <linux/interrupt.h>
>  #include <linux/reset.h>
> +#include <linux/phy/phy.h>
>  #include <linux/pm_domain.h>
>  #include <linux/pm_runtime.h>
>  
> @@ -49,6 +50,7 @@ enum imx6_pcie_variants {
>  	IMX6QP,
>  	IMX7D,
>  	IMX8MQ,
> +	IMX8MM,
>  };
>  
>  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
> @@ -80,6 +82,7 @@ struct imx6_pcie {
>  	u32			tx_deemph_gen2_6db;
>  	u32			tx_swing_full;
>  	u32			tx_swing_low;
> +	u32			refclk_pad_mode;

As Matthias already noticed: drop this.

>  	struct regulator	*vpcie;
>  	struct regulator	*vph;
>  	void __iomem		*phy_base;
> @@ -88,6 +91,7 @@ struct imx6_pcie {
>  	struct device		*pd_pcie;
>  	/* power domain for pcie phy */
>  	struct device		*pd_pcie_phy;
> +	struct phy		*phy;
>  	const struct imx6_pcie_drvdata *drvdata;
>  };
>  
> @@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>  	case IMX7D:
>  	case IMX8MQ:
>  		reset_control_assert(imx6_pcie->pciephy_reset);
> +		fallthrough;
> +	case IMX8MM:
>  		reset_control_assert(imx6_pcie->apps_reset);
>  		break;
>  	case IMX6SX:
> @@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>  
>  static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
>  {
> -	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
> +	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
> +		imx6_pcie->drvdata->variant != IMX8MM);
>  	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
>  }
>  
> @@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
>  	case IMX7D:
>  		break;
>  	case IMX8MQ:
> +	case IMX8MM:
>  		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
>  		if (ret) {
>  			dev_err(dev, "unable to enable pcie_aux clock\n");
> @@ -522,6 +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
>  		goto err_ref_clk;
>  	}
>  
> +	switch (imx6_pcie->drvdata->variant) {
> +	case IMX8MM:
> +		if (phy_power_on(imx6_pcie->phy))
> +			pr_info("unable to enable pcie phy clock\n");

It a implementation detail of the PHY driver that this just turns on
the clock. dev_err("unable to power on PHY\n") or something like that.

> +		break;
> +	default:
> +		break;
> +	}
>  	/* allow the clocks to stabilize */
>  	usleep_range(200, 500);
>  
> @@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
>  	case IMX8MQ:
>  		reset_control_deassert(imx6_pcie->pciephy_reset);
>  		break;
> +	case IMX8MM:
> +		if (phy_init(imx6_pcie->phy) != 0)
> +			dev_err(dev, "Waiting for PHY ready timeout!\n");
> +		break;
>  	case IMX7D:
>  		reset_control_deassert(imx6_pcie->pciephy_reset);
>  
> @@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
>  static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
>  {
>  	switch (imx6_pcie->drvdata->variant) {
> +	case IMX8MM:
> +		break;
>  	case IMX8MQ:
>  		/*
>  		 * TODO: Currently this code assumes external
> @@ -753,6 +775,7 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
>  		break;
>  	case IMX7D:
>  	case IMX8MQ:
> +	case IMX8MM:
>  		reset_control_deassert(imx6_pcie->apps_reset);
>  		break;
>  	}
> @@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
>  				   IMX6Q_GPR12_PCIE_CTL_2, 0);
>  		break;
>  	case IMX7D:
> +	case IMX8MM:
>  		reset_control_assert(imx6_pcie->apps_reset);
>  		break;
>  	default:
> @@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
>  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
>  		break;
>  	case IMX8MQ:
> +	case IMX8MM:
>  		clk_disable_unprepare(imx6_pcie->pcie_aux);
>  		break;
>  	default:
> @@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	struct imx6_pcie *imx6_pcie;
>  	struct device_node *np;
>  	struct resource *dbi_base;
> +	struct device_node *phy_node;
>  	struct device_node *node = dev->of_node;
>  	int ret;
>  	u16 val;
> @@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  			return PTR_ERR(imx6_pcie->phy_base);
>  	}
>  
> +	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> +	if (IS_ERR(imx6_pcie->phy)) {
> +		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +		/* Set NULL if there is no pcie-phy */
> +		imx6_pcie->phy = NULL;
> +	}

Move this into the i.MX8MM specific section below. The PHY is required
on the 8MM and we should not ignore any errors.

Regards,
Lucas

> +
>  	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
>  	if (IS_ERR(pci->dbi_base))
> @@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  			return PTR_ERR(imx6_pcie->apps_reset);
>  		}
>  		break;
> +	case IMX8MM:
> +		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> +		if (IS_ERR(imx6_pcie->pcie_aux))
> +			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> +					     "pcie_aux clock source missing or invalid\n");
> +		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> +									 "apps");
> +		if (IS_ERR(imx6_pcie->apps_reset)) {
> +			dev_err(dev, "Failed to get PCIE APPS reset control\n");
> +			return PTR_ERR(imx6_pcie->apps_reset);
> +		}
> +		break;
>  	default:
>  		break;
>  	}
> @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  				 &imx6_pcie->tx_swing_low))
>  		imx6_pcie->tx_swing_low = 127;
>  
> +	/* get PHY refclk pad mode if there is PHY node */
> +	phy_node = of_parse_phandle(node, "phys", 0);
> +	if (phy_node) {
> +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> +				     &imx6_pcie->refclk_pad_mode);
> +		of_node_put(phy_node);
> +	}
> +
>  	/* Limit link speed */
>  	pci->link_gen = 1;
>  	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen);
> @@ -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
>  	[IMX8MQ] = {
>  		.variant = IMX8MQ,
>  	},
> +	[IMX8MM] = {
> +		.variant = IMX8MM,
> +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +	},
>  };
>  
>  static const struct of_device_id imx6_pcie_of_match[] = {
> @@ -1209,7 +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
>  	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
>  	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
>  	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
> -	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
> +	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
> +	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
>  	{},
>  };
>  



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

RE: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 3:00 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different
> > PHY and allows to output the internal PHY reference clock via the refclk
> pad.
> > Add the i.MX8MM PCIe support based on the standalone PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/pci/controller/dwc/pci-imx6.c | 63
> > ++++++++++++++++++++++++++-
> >  1 file changed, 61 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 26f49f797b0f..73022e37b1c5 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -29,6 +29,7 @@
> >  #include <linux/types.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/reset.h>
> > +#include <linux/phy/phy.h>
> >  #include <linux/pm_domain.h>
> >  #include <linux/pm_runtime.h>
> >
> > @@ -49,6 +50,7 @@ enum imx6_pcie_variants {
> >  	IMX6QP,
> >  	IMX7D,
> >  	IMX8MQ,
> > +	IMX8MM,
> >  };
> >
> >  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
> > @@ -80,6 +82,7 @@ struct imx6_pcie {
> >  	u32			tx_deemph_gen2_6db;
> >  	u32			tx_swing_full;
> >  	u32			tx_swing_low;
> > +	u32			refclk_pad_mode;
> 
> As Matthias already noticed: drop this.
[Richard Zhu] Got that, thanks.

> 
> >  	struct regulator	*vpcie;
> >  	struct regulator	*vph;
> >  	void __iomem		*phy_base;
> > @@ -88,6 +91,7 @@ struct imx6_pcie {
> >  	struct device		*pd_pcie;
> >  	/* power domain for pcie phy */
> >  	struct device		*pd_pcie_phy;
> > +	struct phy		*phy;
> >  	const struct imx6_pcie_drvdata *drvdata;  };
> >
> > @@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX7D:
> >  	case IMX8MQ:
> >  		reset_control_assert(imx6_pcie->pciephy_reset);
> > +		fallthrough;
> > +	case IMX8MM:
> >  		reset_control_assert(imx6_pcie->apps_reset);
> >  		break;
> >  	case IMX6SX:
> > @@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct
> > imx6_pcie *imx6_pcie)
> >
> >  static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie
> > *imx6_pcie)  {
> > -	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
> > +	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
> > +		imx6_pcie->drvdata->variant != IMX8MM);
> >  	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 :
> IOMUXC_GPR14;
> > }
> >
> > @@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX7D:
> >  		break;
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> >  		if (ret) {
> >  			dev_err(dev, "unable to enable pcie_aux clock\n"); @@ -522,6
> > +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie
> *imx6_pcie)
> >  		goto err_ref_clk;
> >  	}
> >
> > +	switch (imx6_pcie->drvdata->variant) {
> > +	case IMX8MM:
> > +		if (phy_power_on(imx6_pcie->phy))
> > +			pr_info("unable to enable pcie phy clock\n");
> 
> It a implementation detail of the PHY driver that this just turns on the clock.
> dev_err("unable to power on PHY\n") or something like that.
[Richard Zhu] Okay. Thanks.

> 
> > +		break;
> > +	default:
> > +		break;
> > +	}
> >  	/* allow the clocks to stabilize */
> >  	usleep_range(200, 500);
> >
> > @@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX8MQ:
> >  		reset_control_deassert(imx6_pcie->pciephy_reset);
> >  		break;
> > +	case IMX8MM:
> > +		if (phy_init(imx6_pcie->phy) != 0)
> > +			dev_err(dev, "Waiting for PHY ready timeout!\n");
> > +		break;
> >  	case IMX7D:
> >  		reset_control_deassert(imx6_pcie->pciephy_reset);
> >
> > @@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct
> > imx6_pcie *imx6_pcie)  static void imx6_pcie_init_phy(struct imx6_pcie
> > *imx6_pcie)  {
> >  	switch (imx6_pcie->drvdata->variant) {
> > +	case IMX8MM:
> > +		break;
> >  	case IMX8MQ:
> >  		/*
> >  		 * TODO: Currently this code assumes external @@ -753,6 +775,7
> @@
> > static void imx6_pcie_ltssm_enable(struct device *dev)
> >  		break;
> >  	case IMX7D:
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		reset_control_deassert(imx6_pcie->apps_reset);
> >  		break;
> >  	}
> > @@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device
> *dev)
> >  				   IMX6Q_GPR12_PCIE_CTL_2, 0);
> >  		break;
> >  	case IMX7D:
> > +	case IMX8MM:
> >  		reset_control_assert(imx6_pcie->apps_reset);
> >  		break;
> >  	default:
> > @@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie
> *imx6_pcie)
> >  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
> >  		break;
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		clk_disable_unprepare(imx6_pcie->pcie_aux);
> >  		break;
> >  	default:
> > @@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device
> *pdev)
> >  	struct imx6_pcie *imx6_pcie;
> >  	struct device_node *np;
> >  	struct resource *dbi_base;
> > +	struct device_node *phy_node;
> >  	struct device_node *node = dev->of_node;
> >  	int ret;
> >  	u16 val;
> > @@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  			return PTR_ERR(imx6_pcie->phy_base);
> >  	}
> >
> > +	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> > +	if (IS_ERR(imx6_pcie->phy)) {
> > +		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
> > +			return -EPROBE_DEFER;
> > +		/* Set NULL if there is no pcie-phy */
> > +		imx6_pcie->phy = NULL;
> > +	}
> 
> Move this into the i.MX8MM specific section below. The PHY is required on
> the 8MM and we should not ignore any errors.
[Richard Zhu] Okay. Thanks.

Best Regards
Richard Zhu

> 
> Regards,
> Lucas
> 
> > +
> >  	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
> >  	if (IS_ERR(pci->dbi_base))
> > @@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  			return PTR_ERR(imx6_pcie->apps_reset);
> >  		}
> >  		break;
> > +	case IMX8MM:
> > +		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> > +		if (IS_ERR(imx6_pcie->pcie_aux))
> > +			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> > +					     "pcie_aux clock source missing or invalid\n");
> > +		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> > +									 "apps");
> > +		if (IS_ERR(imx6_pcie->apps_reset)) {
> > +			dev_err(dev, "Failed to get PCIE APPS reset control\n");
> > +			return PTR_ERR(imx6_pcie->apps_reset);
> > +		}
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  				 &imx6_pcie->tx_swing_low))
> >  		imx6_pcie->tx_swing_low = 127;
> >
> > +	/* get PHY refclk pad mode if there is PHY node */
> > +	phy_node = of_parse_phandle(node, "phys", 0);
> > +	if (phy_node) {
> > +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> > +				     &imx6_pcie->refclk_pad_mode);
> > +		of_node_put(phy_node);
> > +	}
> > +
> >  	/* Limit link speed */
> >  	pci->link_gen = 1;
> >  	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen); @@
> > -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
> >  	[IMX8MQ] = {
> >  		.variant = IMX8MQ,
> >  	},
> > +	[IMX8MM] = {
> > +		.variant = IMX8MM,
> > +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> > +	},
> >  };
> >
> >  static const struct of_device_id imx6_pcie_of_match[] = { @@ -1209,7
> > +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
> >  	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
> >  	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
> >  	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
> > -	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
> > +	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
> > +	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
> >  	{},
> >  };
> >
> 

RE: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 3:00 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different
> > PHY and allows to output the internal PHY reference clock via the refclk
> pad.
> > Add the i.MX8MM PCIe support based on the standalone PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/pci/controller/dwc/pci-imx6.c | 63
> > ++++++++++++++++++++++++++-
> >  1 file changed, 61 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 26f49f797b0f..73022e37b1c5 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -29,6 +29,7 @@
> >  #include <linux/types.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/reset.h>
> > +#include <linux/phy/phy.h>
> >  #include <linux/pm_domain.h>
> >  #include <linux/pm_runtime.h>
> >
> > @@ -49,6 +50,7 @@ enum imx6_pcie_variants {
> >  	IMX6QP,
> >  	IMX7D,
> >  	IMX8MQ,
> > +	IMX8MM,
> >  };
> >
> >  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
> > @@ -80,6 +82,7 @@ struct imx6_pcie {
> >  	u32			tx_deemph_gen2_6db;
> >  	u32			tx_swing_full;
> >  	u32			tx_swing_low;
> > +	u32			refclk_pad_mode;
> 
> As Matthias already noticed: drop this.
[Richard Zhu] Got that, thanks.

> 
> >  	struct regulator	*vpcie;
> >  	struct regulator	*vph;
> >  	void __iomem		*phy_base;
> > @@ -88,6 +91,7 @@ struct imx6_pcie {
> >  	struct device		*pd_pcie;
> >  	/* power domain for pcie phy */
> >  	struct device		*pd_pcie_phy;
> > +	struct phy		*phy;
> >  	const struct imx6_pcie_drvdata *drvdata;  };
> >
> > @@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX7D:
> >  	case IMX8MQ:
> >  		reset_control_assert(imx6_pcie->pciephy_reset);
> > +		fallthrough;
> > +	case IMX8MM:
> >  		reset_control_assert(imx6_pcie->apps_reset);
> >  		break;
> >  	case IMX6SX:
> > @@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct
> > imx6_pcie *imx6_pcie)
> >
> >  static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie
> > *imx6_pcie)  {
> > -	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
> > +	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
> > +		imx6_pcie->drvdata->variant != IMX8MM);
> >  	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 :
> IOMUXC_GPR14;
> > }
> >
> > @@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX7D:
> >  		break;
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> >  		if (ret) {
> >  			dev_err(dev, "unable to enable pcie_aux clock\n"); @@ -522,6
> > +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie
> *imx6_pcie)
> >  		goto err_ref_clk;
> >  	}
> >
> > +	switch (imx6_pcie->drvdata->variant) {
> > +	case IMX8MM:
> > +		if (phy_power_on(imx6_pcie->phy))
> > +			pr_info("unable to enable pcie phy clock\n");
> 
> It a implementation detail of the PHY driver that this just turns on the clock.
> dev_err("unable to power on PHY\n") or something like that.
[Richard Zhu] Okay. Thanks.

> 
> > +		break;
> > +	default:
> > +		break;
> > +	}
> >  	/* allow the clocks to stabilize */
> >  	usleep_range(200, 500);
> >
> > @@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX8MQ:
> >  		reset_control_deassert(imx6_pcie->pciephy_reset);
> >  		break;
> > +	case IMX8MM:
> > +		if (phy_init(imx6_pcie->phy) != 0)
> > +			dev_err(dev, "Waiting for PHY ready timeout!\n");
> > +		break;
> >  	case IMX7D:
> >  		reset_control_deassert(imx6_pcie->pciephy_reset);
> >
> > @@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct
> > imx6_pcie *imx6_pcie)  static void imx6_pcie_init_phy(struct imx6_pcie
> > *imx6_pcie)  {
> >  	switch (imx6_pcie->drvdata->variant) {
> > +	case IMX8MM:
> > +		break;
> >  	case IMX8MQ:
> >  		/*
> >  		 * TODO: Currently this code assumes external @@ -753,6 +775,7
> @@
> > static void imx6_pcie_ltssm_enable(struct device *dev)
> >  		break;
> >  	case IMX7D:
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		reset_control_deassert(imx6_pcie->apps_reset);
> >  		break;
> >  	}
> > @@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device
> *dev)
> >  				   IMX6Q_GPR12_PCIE_CTL_2, 0);
> >  		break;
> >  	case IMX7D:
> > +	case IMX8MM:
> >  		reset_control_assert(imx6_pcie->apps_reset);
> >  		break;
> >  	default:
> > @@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie
> *imx6_pcie)
> >  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
> >  		break;
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		clk_disable_unprepare(imx6_pcie->pcie_aux);
> >  		break;
> >  	default:
> > @@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device
> *pdev)
> >  	struct imx6_pcie *imx6_pcie;
> >  	struct device_node *np;
> >  	struct resource *dbi_base;
> > +	struct device_node *phy_node;
> >  	struct device_node *node = dev->of_node;
> >  	int ret;
> >  	u16 val;
> > @@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  			return PTR_ERR(imx6_pcie->phy_base);
> >  	}
> >
> > +	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> > +	if (IS_ERR(imx6_pcie->phy)) {
> > +		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
> > +			return -EPROBE_DEFER;
> > +		/* Set NULL if there is no pcie-phy */
> > +		imx6_pcie->phy = NULL;
> > +	}
> 
> Move this into the i.MX8MM specific section below. The PHY is required on
> the 8MM and we should not ignore any errors.
[Richard Zhu] Okay. Thanks.

Best Regards
Richard Zhu

> 
> Regards,
> Lucas
> 
> > +
> >  	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
> >  	if (IS_ERR(pci->dbi_base))
> > @@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  			return PTR_ERR(imx6_pcie->apps_reset);
> >  		}
> >  		break;
> > +	case IMX8MM:
> > +		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> > +		if (IS_ERR(imx6_pcie->pcie_aux))
> > +			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> > +					     "pcie_aux clock source missing or invalid\n");
> > +		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> > +									 "apps");
> > +		if (IS_ERR(imx6_pcie->apps_reset)) {
> > +			dev_err(dev, "Failed to get PCIE APPS reset control\n");
> > +			return PTR_ERR(imx6_pcie->apps_reset);
> > +		}
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  				 &imx6_pcie->tx_swing_low))
> >  		imx6_pcie->tx_swing_low = 127;
> >
> > +	/* get PHY refclk pad mode if there is PHY node */
> > +	phy_node = of_parse_phandle(node, "phys", 0);
> > +	if (phy_node) {
> > +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> > +				     &imx6_pcie->refclk_pad_mode);
> > +		of_node_put(phy_node);
> > +	}
> > +
> >  	/* Limit link speed */
> >  	pci->link_gen = 1;
> >  	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen); @@
> > -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
> >  	[IMX8MQ] = {
> >  		.variant = IMX8MQ,
> >  	},
> > +	[IMX8MM] = {
> > +		.variant = IMX8MM,
> > +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> > +	},
> >  };
> >
> >  static const struct of_device_id imx6_pcie_of_match[] = { @@ -1209,7
> > +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
> >  	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
> >  	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
> >  	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
> > -	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
> > +	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
> > +	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
> >  	{},
> >  };
> >
> 

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

RE: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Lucas Stach <l.stach@pengutronix.de>
> Sent: Saturday, October 16, 2021 3:00 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; tharvey@gateworks.com;
> kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> galak@kernel.crashing.org; shawnguo@kernel.org
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
> 
> Am Dienstag, dem 12.10.2021 um 16:41 +0800 schrieb Richard Zhu:
> > i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different
> > PHY and allows to output the internal PHY reference clock via the refclk
> pad.
> > Add the i.MX8MM PCIe support based on the standalone PHY driver.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> >  drivers/pci/controller/dwc/pci-imx6.c | 63
> > ++++++++++++++++++++++++++-
> >  1 file changed, 61 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 26f49f797b0f..73022e37b1c5 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -29,6 +29,7 @@
> >  #include <linux/types.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/reset.h>
> > +#include <linux/phy/phy.h>
> >  #include <linux/pm_domain.h>
> >  #include <linux/pm_runtime.h>
> >
> > @@ -49,6 +50,7 @@ enum imx6_pcie_variants {
> >  	IMX6QP,
> >  	IMX7D,
> >  	IMX8MQ,
> > +	IMX8MM,
> >  };
> >
> >  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
> > @@ -80,6 +82,7 @@ struct imx6_pcie {
> >  	u32			tx_deemph_gen2_6db;
> >  	u32			tx_swing_full;
> >  	u32			tx_swing_low;
> > +	u32			refclk_pad_mode;
> 
> As Matthias already noticed: drop this.
[Richard Zhu] Got that, thanks.

> 
> >  	struct regulator	*vpcie;
> >  	struct regulator	*vph;
> >  	void __iomem		*phy_base;
> > @@ -88,6 +91,7 @@ struct imx6_pcie {
> >  	struct device		*pd_pcie;
> >  	/* power domain for pcie phy */
> >  	struct device		*pd_pcie_phy;
> > +	struct phy		*phy;
> >  	const struct imx6_pcie_drvdata *drvdata;  };
> >
> > @@ -372,6 +376,8 @@ static void imx6_pcie_assert_core_reset(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX7D:
> >  	case IMX8MQ:
> >  		reset_control_assert(imx6_pcie->pciephy_reset);
> > +		fallthrough;
> > +	case IMX8MM:
> >  		reset_control_assert(imx6_pcie->apps_reset);
> >  		break;
> >  	case IMX6SX:
> > @@ -407,7 +413,8 @@ static void imx6_pcie_assert_core_reset(struct
> > imx6_pcie *imx6_pcie)
> >
> >  static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie
> > *imx6_pcie)  {
> > -	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
> > +	WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ &&
> > +		imx6_pcie->drvdata->variant != IMX8MM);
> >  	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 :
> IOMUXC_GPR14;
> > }
> >
> > @@ -447,6 +454,7 @@ static int imx6_pcie_enable_ref_clk(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX7D:
> >  		break;
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> >  		if (ret) {
> >  			dev_err(dev, "unable to enable pcie_aux clock\n"); @@ -522,6
> > +530,14 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie
> *imx6_pcie)
> >  		goto err_ref_clk;
> >  	}
> >
> > +	switch (imx6_pcie->drvdata->variant) {
> > +	case IMX8MM:
> > +		if (phy_power_on(imx6_pcie->phy))
> > +			pr_info("unable to enable pcie phy clock\n");
> 
> It a implementation detail of the PHY driver that this just turns on the clock.
> dev_err("unable to power on PHY\n") or something like that.
[Richard Zhu] Okay. Thanks.

> 
> > +		break;
> > +	default:
> > +		break;
> > +	}
> >  	/* allow the clocks to stabilize */
> >  	usleep_range(200, 500);
> >
> > @@ -538,6 +554,10 @@ static void imx6_pcie_deassert_core_reset(struct
> imx6_pcie *imx6_pcie)
> >  	case IMX8MQ:
> >  		reset_control_deassert(imx6_pcie->pciephy_reset);
> >  		break;
> > +	case IMX8MM:
> > +		if (phy_init(imx6_pcie->phy) != 0)
> > +			dev_err(dev, "Waiting for PHY ready timeout!\n");
> > +		break;
> >  	case IMX7D:
> >  		reset_control_deassert(imx6_pcie->pciephy_reset);
> >
> > @@ -614,6 +634,8 @@ static void imx6_pcie_configure_type(struct
> > imx6_pcie *imx6_pcie)  static void imx6_pcie_init_phy(struct imx6_pcie
> > *imx6_pcie)  {
> >  	switch (imx6_pcie->drvdata->variant) {
> > +	case IMX8MM:
> > +		break;
> >  	case IMX8MQ:
> >  		/*
> >  		 * TODO: Currently this code assumes external @@ -753,6 +775,7
> @@
> > static void imx6_pcie_ltssm_enable(struct device *dev)
> >  		break;
> >  	case IMX7D:
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		reset_control_deassert(imx6_pcie->apps_reset);
> >  		break;
> >  	}
> > @@ -871,6 +894,7 @@ static void imx6_pcie_ltssm_disable(struct device
> *dev)
> >  				   IMX6Q_GPR12_PCIE_CTL_2, 0);
> >  		break;
> >  	case IMX7D:
> > +	case IMX8MM:
> >  		reset_control_assert(imx6_pcie->apps_reset);
> >  		break;
> >  	default:
> > @@ -930,6 +954,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie
> *imx6_pcie)
> >  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
> >  		break;
> >  	case IMX8MQ:
> > +	case IMX8MM:
> >  		clk_disable_unprepare(imx6_pcie->pcie_aux);
> >  		break;
> >  	default:
> > @@ -985,6 +1010,7 @@ static int imx6_pcie_probe(struct platform_device
> *pdev)
> >  	struct imx6_pcie *imx6_pcie;
> >  	struct device_node *np;
> >  	struct resource *dbi_base;
> > +	struct device_node *phy_node;
> >  	struct device_node *node = dev->of_node;
> >  	int ret;
> >  	u16 val;
> > @@ -1019,6 +1045,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  			return PTR_ERR(imx6_pcie->phy_base);
> >  	}
> >
> > +	imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> > +	if (IS_ERR(imx6_pcie->phy)) {
> > +		if (PTR_ERR(imx6_pcie->phy) == -EPROBE_DEFER)
> > +			return -EPROBE_DEFER;
> > +		/* Set NULL if there is no pcie-phy */
> > +		imx6_pcie->phy = NULL;
> > +	}
> 
> Move this into the i.MX8MM specific section below. The PHY is required on
> the 8MM and we should not ignore any errors.
[Richard Zhu] Okay. Thanks.

Best Regards
Richard Zhu

> 
> Regards,
> Lucas
> 
> > +
> >  	dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
> >  	if (IS_ERR(pci->dbi_base))
> > @@ -1090,6 +1124,18 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  			return PTR_ERR(imx6_pcie->apps_reset);
> >  		}
> >  		break;
> > +	case IMX8MM:
> > +		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> > +		if (IS_ERR(imx6_pcie->pcie_aux))
> > +			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> > +					     "pcie_aux clock source missing or invalid\n");
> > +		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> > +									 "apps");
> > +		if (IS_ERR(imx6_pcie->apps_reset)) {
> > +			dev_err(dev, "Failed to get PCIE APPS reset control\n");
> > +			return PTR_ERR(imx6_pcie->apps_reset);
> > +		}
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -1130,6 +1176,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  				 &imx6_pcie->tx_swing_low))
> >  		imx6_pcie->tx_swing_low = 127;
> >
> > +	/* get PHY refclk pad mode if there is PHY node */
> > +	phy_node = of_parse_phandle(node, "phys", 0);
> > +	if (phy_node) {
> > +		of_property_read_u32(phy_node, "fsl,refclk-pad-mode",
> > +				     &imx6_pcie->refclk_pad_mode);
> > +		of_node_put(phy_node);
> > +	}
> > +
> >  	/* Limit link speed */
> >  	pci->link_gen = 1;
> >  	of_property_read_u32(node, "fsl,max-link-speed", &pci->link_gen); @@
> > -1202,6 +1256,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
> >  	[IMX8MQ] = {
> >  		.variant = IMX8MQ,
> >  	},
> > +	[IMX8MM] = {
> > +		.variant = IMX8MM,
> > +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> > +	},
> >  };
> >
> >  static const struct of_device_id imx6_pcie_of_match[] = { @@ -1209,7
> > +1267,8 @@ static const struct of_device_id imx6_pcie_of_match[] = {
> >  	{ .compatible = "fsl,imx6sx-pcie", .data = &drvdata[IMX6SX], },
> >  	{ .compatible = "fsl,imx6qp-pcie", .data = &drvdata[IMX6QP], },
> >  	{ .compatible = "fsl,imx7d-pcie",  .data = &drvdata[IMX7D],  },
> > -	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], } ,
> > +	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
> > +	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
> >  	{},
> >  };
> >
> 

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> one standalone PCIe PHY driver should be seperated from i.MX PCIe
> driver when enable i.MX8MM PCIe support.
>
> This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
> PCIe support[6-9] to have whole view to review this patch-set.
>
> The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> [2] and this PHY driver patch-set.
>
> [1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/
>
> Main changes v2 --> v3:
> - Regarding Lucas' comments.
>  - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
>  - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
>  - split the dts changes to SOC and board DT, and use the enum instead of raw value.
>  - update the license of the dt-binding header file.
>
> Changes v1 --> v2:
> - Update the license of the dt-binding header file to make the license
>   compatible with dts files.
> - Fix the dt_binding_check errors.
>
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig                                |   9 ++++
> drivers/phy/freescale/Makefile                               |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
> 9 files changed, 486 insertions(+), 3 deletions(-)
>
> [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
> [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
> [PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
> [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
> [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

Richard and Lucas,

Thanks for your collective work on this series!

I have imx8mm-venice boards to test this on both with and without PCIe
bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl
has been merged there) and end up hanging waiting for PHY ready
timeout.

[    1.454308] imx6q-pcie 33800000.pcie:       IO
0x001ff80000..0x001ff8ffff -> 0x0
[    1.466538] imx6q-pcie 33800000.pcie:      MEM
0x0018000000..0x001fefffff -> 0x0
[    1.476344] libphy: fec_enet_mii_bus: probed
[    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
[    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!

I can verify that imx8_pcie_phy_probe returns successfully and the the
phy node (imx6_pcie->phy) was found.

Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
that has no bridge:
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
index 91544576f145..e89e9cf7318e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
@@ -5,6 +5,7 @@

 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>

 / {
        aliases {
@@ -33,6 +34,12 @@
                };
        };

+       pcie0_refclk: pcie0-refclk {
+               compatible = "fixed-clock";
+               #clock-cells = <0>;
+               clock-frequency = <100000000>;
+       };
+
        pps {
                compatible = "pps-gpio";
                pinctrl-names = "default";
@@ -101,6 +108,27 @@
        status = "okay";
 };

+&pcie0 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&pinctrl_pcie0>;
+       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
+       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
+       assigned-clock-rates = <10000000>, <250000000>;
+       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+                                <&clk IMX8MM_SYS_PLL2_250M>;
+       status = "okay";
+};
+
+&pcie_phy {
+       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+       clocks = <&clk IMX8MM_CLK_DUMMY>;
+       status = "okay";
+};
+
 /* GPS */
 &uart1 {
        pinctrl-names = "default";
@@ -162,6 +190,12 @@
                >;
        };

+       pinctrl_pcie0: pciegrp {
+               fsl,pins = <
+                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6        0x41
+               >;
+       };
+
        pinctrl_pps: ppsgrp {
                fsl,pins = <
                        MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x41

and here are the changes to the imx8mm-venice-gw72xx-0x dt - this
board has a PCIe bridge:

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
index b12ead847302..260ea93ebfc2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
@@ -5,9 +5,11 @@

 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>

 / {
        aliases {
+               ethernet1 = &eth1;
                usb0 = &usbotg1;
                usb1 = &usbotg2;
        };
@@ -33,6 +35,12 @@
                };
        };

+       pcie0_refclk: pcie0-refclk {
+               compatible = "fixed-clock";
+               #clock-cells = <0>;
+               clock-frequency = <100000000>;
+       };
+
        pps {
                compatible = "pps-gpio";
                pinctrl-names = "default";
@@ -122,6 +130,53 @@
        status = "okay";
 };

+&pcie0 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&pinctrl_pcie0>;
+       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
+       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
+       assigned-clock-rates = <10000000>, <250000000>;
+       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+                                <&clk IMX8MM_SYS_PLL2_250M>;
+       status = "okay";
+
+       pcie@0,0 {
+               reg = <0x0000 0 0 0 0>;
+               #address-cells = <1>;
+               #size-cells = <0>;
+
+               pcie@1,0 {
+                       reg = <0x0000 0 0 0 0>;
+                       #address-cells = <1>;
+                       #size-cells = <0>;
+
+                       pcie@2,3 {
+                               reg = <0x1800 0 0 0 0>;
+                               #address-cells = <1>;
+                               #size-cells = <0>;
+
+                               eth1: pcie@5,0 {
+                                       reg = <0x0000 0 0 0 0>;
+                                       #address-cells = <1>;
+                                       #size-cells = <0>;
+
+                                       local-mac-address = [00 00 00 00 00 00];
+                               };
+                       };
+               };
+       };
+};
+
+&pcie_phy {
+       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+       clocks = <&clk IMX8MM_CLK_DUMMY>;
+       status = "okay";
+};
+
 /* off-board header */
 &sai3 {
        pinctrl-names = "default";
@@ -214,6 +269,12 @@
                >;
        };

+       pinctrl_pcie0: pciegrp {
+               fsl,pins = <
+                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6        0x41
+               >;
+       };
+
        pinctrl_pps: ppsgrp {
                fsl,pins = <
                        MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x41


Any ideas?

Perhaps

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> one standalone PCIe PHY driver should be seperated from i.MX PCIe
> driver when enable i.MX8MM PCIe support.
>
> This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
> PCIe support[6-9] to have whole view to review this patch-set.
>
> The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> [2] and this PHY driver patch-set.
>
> [1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/
>
> Main changes v2 --> v3:
> - Regarding Lucas' comments.
>  - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
>  - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
>  - split the dts changes to SOC and board DT, and use the enum instead of raw value.
>  - update the license of the dt-binding header file.
>
> Changes v1 --> v2:
> - Update the license of the dt-binding header file to make the license
>   compatible with dts files.
> - Fix the dt_binding_check errors.
>
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig                                |   9 ++++
> drivers/phy/freescale/Makefile                               |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
> 9 files changed, 486 insertions(+), 3 deletions(-)
>
> [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
> [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
> [PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
> [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
> [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

Richard and Lucas,

Thanks for your collective work on this series!

I have imx8mm-venice boards to test this on both with and without PCIe
bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl
has been merged there) and end up hanging waiting for PHY ready
timeout.

[    1.454308] imx6q-pcie 33800000.pcie:       IO
0x001ff80000..0x001ff8ffff -> 0x0
[    1.466538] imx6q-pcie 33800000.pcie:      MEM
0x0018000000..0x001fefffff -> 0x0
[    1.476344] libphy: fec_enet_mii_bus: probed
[    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
[    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!

I can verify that imx8_pcie_phy_probe returns successfully and the the
phy node (imx6_pcie->phy) was found.

Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
that has no bridge:
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
index 91544576f145..e89e9cf7318e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
@@ -5,6 +5,7 @@

 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>

 / {
        aliases {
@@ -33,6 +34,12 @@
                };
        };

+       pcie0_refclk: pcie0-refclk {
+               compatible = "fixed-clock";
+               #clock-cells = <0>;
+               clock-frequency = <100000000>;
+       };
+
        pps {
                compatible = "pps-gpio";
                pinctrl-names = "default";
@@ -101,6 +108,27 @@
        status = "okay";
 };

+&pcie0 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&pinctrl_pcie0>;
+       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
+       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
+       assigned-clock-rates = <10000000>, <250000000>;
+       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+                                <&clk IMX8MM_SYS_PLL2_250M>;
+       status = "okay";
+};
+
+&pcie_phy {
+       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+       clocks = <&clk IMX8MM_CLK_DUMMY>;
+       status = "okay";
+};
+
 /* GPS */
 &uart1 {
        pinctrl-names = "default";
@@ -162,6 +190,12 @@
                >;
        };

+       pinctrl_pcie0: pciegrp {
+               fsl,pins = <
+                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6        0x41
+               >;
+       };
+
        pinctrl_pps: ppsgrp {
                fsl,pins = <
                        MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x41

and here are the changes to the imx8mm-venice-gw72xx-0x dt - this
board has a PCIe bridge:

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
index b12ead847302..260ea93ebfc2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
@@ -5,9 +5,11 @@

 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>

 / {
        aliases {
+               ethernet1 = &eth1;
                usb0 = &usbotg1;
                usb1 = &usbotg2;
        };
@@ -33,6 +35,12 @@
                };
        };

+       pcie0_refclk: pcie0-refclk {
+               compatible = "fixed-clock";
+               #clock-cells = <0>;
+               clock-frequency = <100000000>;
+       };
+
        pps {
                compatible = "pps-gpio";
                pinctrl-names = "default";
@@ -122,6 +130,53 @@
        status = "okay";
 };

+&pcie0 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&pinctrl_pcie0>;
+       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
+       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
+       assigned-clock-rates = <10000000>, <250000000>;
+       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+                                <&clk IMX8MM_SYS_PLL2_250M>;
+       status = "okay";
+
+       pcie@0,0 {
+               reg = <0x0000 0 0 0 0>;
+               #address-cells = <1>;
+               #size-cells = <0>;
+
+               pcie@1,0 {
+                       reg = <0x0000 0 0 0 0>;
+                       #address-cells = <1>;
+                       #size-cells = <0>;
+
+                       pcie@2,3 {
+                               reg = <0x1800 0 0 0 0>;
+                               #address-cells = <1>;
+                               #size-cells = <0>;
+
+                               eth1: pcie@5,0 {
+                                       reg = <0x0000 0 0 0 0>;
+                                       #address-cells = <1>;
+                                       #size-cells = <0>;
+
+                                       local-mac-address = [00 00 00 00 00 00];
+                               };
+                       };
+               };
+       };
+};
+
+&pcie_phy {
+       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+       clocks = <&clk IMX8MM_CLK_DUMMY>;
+       status = "okay";
+};
+
 /* off-board header */
 &sai3 {
        pinctrl-names = "default";
@@ -214,6 +269,12 @@
                >;
        };

+       pinctrl_pcie0: pciegrp {
+               fsl,pins = <
+                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6        0x41
+               >;
+       };
+
        pinctrl_pps: ppsgrp {
                fsl,pins = <
                        MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x41


Any ideas?

Perhaps

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> one standalone PCIe PHY driver should be seperated from i.MX PCIe
> driver when enable i.MX8MM PCIe support.
>
> This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
> PCIe support[6-9] to have whole view to review this patch-set.
>
> The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> [2] and this PHY driver patch-set.
>
> [1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/
>
> Main changes v2 --> v3:
> - Regarding Lucas' comments.
>  - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
>  - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
>  - split the dts changes to SOC and board DT, and use the enum instead of raw value.
>  - update the license of the dt-binding header file.
>
> Changes v1 --> v2:
> - Update the license of the dt-binding header file to make the license
>   compatible with dts files.
> - Fix the dt_binding_check errors.
>
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig                                |   9 ++++
> drivers/phy/freescale/Makefile                               |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
> 9 files changed, 486 insertions(+), 3 deletions(-)
>
> [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
> [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
> [PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
> [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
> [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

Richard and Lucas,

Thanks for your collective work on this series!

I have imx8mm-venice boards to test this on both with and without PCIe
bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl
has been merged there) and end up hanging waiting for PHY ready
timeout.

[    1.454308] imx6q-pcie 33800000.pcie:       IO
0x001ff80000..0x001ff8ffff -> 0x0
[    1.466538] imx6q-pcie 33800000.pcie:      MEM
0x0018000000..0x001fefffff -> 0x0
[    1.476344] libphy: fec_enet_mii_bus: probed
[    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
[    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!

I can verify that imx8_pcie_phy_probe returns successfully and the the
phy node (imx6_pcie->phy) was found.

Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
that has no bridge:
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
index 91544576f145..e89e9cf7318e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
@@ -5,6 +5,7 @@

 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>

 / {
        aliases {
@@ -33,6 +34,12 @@
                };
        };

+       pcie0_refclk: pcie0-refclk {
+               compatible = "fixed-clock";
+               #clock-cells = <0>;
+               clock-frequency = <100000000>;
+       };
+
        pps {
                compatible = "pps-gpio";
                pinctrl-names = "default";
@@ -101,6 +108,27 @@
        status = "okay";
 };

+&pcie0 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&pinctrl_pcie0>;
+       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
+       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
+       assigned-clock-rates = <10000000>, <250000000>;
+       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+                                <&clk IMX8MM_SYS_PLL2_250M>;
+       status = "okay";
+};
+
+&pcie_phy {
+       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+       clocks = <&clk IMX8MM_CLK_DUMMY>;
+       status = "okay";
+};
+
 /* GPS */
 &uart1 {
        pinctrl-names = "default";
@@ -162,6 +190,12 @@
                >;
        };

+       pinctrl_pcie0: pciegrp {
+               fsl,pins = <
+                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6        0x41
+               >;
+       };
+
        pinctrl_pps: ppsgrp {
                fsl,pins = <
                        MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x41

and here are the changes to the imx8mm-venice-gw72xx-0x dt - this
board has a PCIe bridge:

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
index b12ead847302..260ea93ebfc2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
@@ -5,9 +5,11 @@

 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>

 / {
        aliases {
+               ethernet1 = &eth1;
                usb0 = &usbotg1;
                usb1 = &usbotg2;
        };
@@ -33,6 +35,12 @@
                };
        };

+       pcie0_refclk: pcie0-refclk {
+               compatible = "fixed-clock";
+               #clock-cells = <0>;
+               clock-frequency = <100000000>;
+       };
+
        pps {
                compatible = "pps-gpio";
                pinctrl-names = "default";
@@ -122,6 +130,53 @@
        status = "okay";
 };

+&pcie0 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&pinctrl_pcie0>;
+       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
+       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
+       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
+       assigned-clock-rates = <10000000>, <250000000>;
+       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+                                <&clk IMX8MM_SYS_PLL2_250M>;
+       status = "okay";
+
+       pcie@0,0 {
+               reg = <0x0000 0 0 0 0>;
+               #address-cells = <1>;
+               #size-cells = <0>;
+
+               pcie@1,0 {
+                       reg = <0x0000 0 0 0 0>;
+                       #address-cells = <1>;
+                       #size-cells = <0>;
+
+                       pcie@2,3 {
+                               reg = <0x1800 0 0 0 0>;
+                               #address-cells = <1>;
+                               #size-cells = <0>;
+
+                               eth1: pcie@5,0 {
+                                       reg = <0x0000 0 0 0 0>;
+                                       #address-cells = <1>;
+                                       #size-cells = <0>;
+
+                                       local-mac-address = [00 00 00 00 00 00];
+                               };
+                       };
+               };
+       };
+};
+
+&pcie_phy {
+       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+       clocks = <&clk IMX8MM_CLK_DUMMY>;
+       status = "okay";
+};
+
 /* off-board header */
 &sai3 {
        pinctrl-names = "default";
@@ -214,6 +269,12 @@
                >;
        };

+       pinctrl_pcie0: pciegrp {
+               fsl,pins = <
+                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6        0x41
+               >;
+       };
+
        pinctrl_pps: ppsgrp {
                fsl,pins = <
                        MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x41


Any ideas?

Perhaps

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Saturday, October 16, 2021 3:59 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> <l.stach@pengutronix.de>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree Mailing
> List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > driver when enable i.MX8MM PCIe support.
> >
> > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> >
> > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > [2] and this PHY driver patch-set.
> >
> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> 120
> >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> nxp.c
> >
> om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> 99c5c3016
> >
> 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> ;sdata=
> >
> Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> ved=0
> > [2]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> 40
> > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> g.zhu%
> >
> 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> fa92cd99
> >
> c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjo
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp
> > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPYMo
> %3D&amp;rese
> > rved=0
> >
> > Main changes v2 --> v3:
> > - Regarding Lucas' comments.
> >  - to have a whole view to review the patches, send out the i.MX8MM PCIe
> support too.
> >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> PHY driver.
> >  - split the dts changes to SOC and board DT, and use the enum instead of
> raw value.
> >  - update the license of the dt-binding header file.
> >
> > Changes v1 --> v2:
> > - Update the license of the dt-binding header file to make the license
> >   compatible with dts files.
> > - Fix the dt_binding_check errors.
> >
> > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> +++++++++++++++++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53
> ++++++++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> 46 ++++++++++++++++-
> > drivers/pci/controller/dwc/pci-imx6.c                        |  63
> ++++++++++++++++++++++-
> > drivers/phy/freescale/Kconfig                                |   9
> ++++
> > drivers/phy/freescale/Makefile                               |   1
> +
> > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++
> > include/dt-bindings/phy/phy-imx8-pcie.h                      |  14
> ++++++
> > 9 files changed, 486 insertions(+), 3 deletions(-)
> >
> > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > add the imx8mm pcie support
> 
> Richard and Lucas,
> 
> Thanks for your collective work on this series!
> 
> I have imx8mm-venice boards to test this on both with and without PCIe
> bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl has been
> merged there) and end up hanging waiting for PHY ready timeout.
[Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next applied the blk-ctl issue by Lucas [2] in commit.
Can you help to make a re-tests?
As I know that the blk-ctl is not merged yet.
Hi Lucas:
Am I right?

BR
Richard

> 
> [    1.454308] imx6q-pcie 33800000.pcie:       IO
> 0x001ff80000..0x001ff8ffff -> 0x0
> [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> 0x0018000000..0x001fefffff -> 0x0
> [    1.476344] libphy: fec_enet_mii_bus: probed
> [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!
> 
> I can verify that imx8_pcie_phy_probe returns successfully and the the phy
> node (imx6_pcie->phy) was found.
> 
> Here is the dt change I made for the imx8mm-venice-gw71xx-0x board that
> has no bridge:
[Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF clock(same to EVK board design), right?

> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> index 91544576f145..e89e9cf7318e 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> @@ -5,6 +5,7 @@
> 
>  #include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> 
>  / {
>         aliases {
> @@ -33,6 +34,12 @@
>                 };
>         };
> 
> +       pcie0_refclk: pcie0-refclk {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <100000000>;
> +       };
> +
>         pps {
>                 compatible = "pps-gpio";
>                 pinctrl-names = "default"; @@ -101,6 +108,27 @@
>         status = "okay";
>  };
> 
> +&pcie0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_pcie0>;
> +       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
> +       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> +                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> +       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +       assigned-clock-rates = <10000000>, <250000000>;
> +       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +                                <&clk IMX8MM_SYS_PLL2_250M>;
> +       status = "okay";
> +};
> +
> +&pcie_phy {
> +       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +       clocks = <&clk IMX8MM_CLK_DUMMY>;
> +       status = "okay";
> +};
> +
>  /* GPS */
>  &uart1 {
>         pinctrl-names = "default";
> @@ -162,6 +190,12 @@
>                 >;
>         };
> 
> +       pinctrl_pcie0: pciegrp {
> +               fsl,pins = <
> +                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6
> 0x41
> +               >;
> +       };
> +
>         pinctrl_pps: ppsgrp {
>                 fsl,pins = <
>                         MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15
> 0x41
> 
> and here are the changes to the imx8mm-venice-gw72xx-0x dt - this board
> has a PCIe bridge:
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> index b12ead847302..260ea93ebfc2 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> @@ -5,9 +5,11 @@
> 
>  #include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> 
>  / {
>         aliases {
> +               ethernet1 = &eth1;
>                 usb0 = &usbotg1;
>                 usb1 = &usbotg2;
>         };
> @@ -33,6 +35,12 @@
>                 };
>         };
> 
> +       pcie0_refclk: pcie0-refclk {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <100000000>;
> +       };
> +
>         pps {
>                 compatible = "pps-gpio";
>                 pinctrl-names = "default"; @@ -122,6 +130,53 @@
>         status = "okay";
>  };
> 
> +&pcie0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_pcie0>;
> +       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
> +       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> +                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> +       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +       assigned-clock-rates = <10000000>, <250000000>;
> +       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +                                <&clk IMX8MM_SYS_PLL2_250M>;
> +       status = "okay";
> +
> +       pcie@0,0 {
> +               reg = <0x0000 0 0 0 0>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               pcie@1,0 {
> +                       reg = <0x0000 0 0 0 0>;
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +
> +                       pcie@2,3 {
> +                               reg = <0x1800 0 0 0 0>;
> +                               #address-cells = <1>;
> +                               #size-cells = <0>;
> +
> +                               eth1: pcie@5,0 {
> +                                       reg = <0x0000 0 0 0 0>;
> +                                       #address-cells = <1>;
> +                                       #size-cells = <0>;
> +
> +                                       local-mac-address = [00 00
> 00 00 00 00];
> +                               };
> +                       };
> +               };
> +       };
> +};
> +
> +&pcie_phy {
> +       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +       clocks = <&clk IMX8MM_CLK_DUMMY>;
> +       status = "okay";
> +};
> +
>  /* off-board header */
>  &sai3 {
>         pinctrl-names = "default";
> @@ -214,6 +269,12 @@
>                 >;
>         };
> 
> +       pinctrl_pcie0: pciegrp {
> +               fsl,pins = <
> +                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6
> 0x41
> +               >;
> +       };
> +
>         pinctrl_pps: ppsgrp {
>                 fsl,pins = <
>                         MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15
> 0x41
> 
> 
> Any ideas?
> 
> Perhaps

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Saturday, October 16, 2021 3:59 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> <l.stach@pengutronix.de>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree Mailing
> List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > driver when enable i.MX8MM PCIe support.
> >
> > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> >
> > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > [2] and this PHY driver patch-set.
> >
> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> 120
> >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> nxp.c
> >
> om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> 99c5c3016
> >
> 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> ;sdata=
> >
> Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> ved=0
> > [2]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> 40
> > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> g.zhu%
> >
> 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> fa92cd99
> >
> c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjo
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp
> > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPYMo
> %3D&amp;rese
> > rved=0
> >
> > Main changes v2 --> v3:
> > - Regarding Lucas' comments.
> >  - to have a whole view to review the patches, send out the i.MX8MM PCIe
> support too.
> >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> PHY driver.
> >  - split the dts changes to SOC and board DT, and use the enum instead of
> raw value.
> >  - update the license of the dt-binding header file.
> >
> > Changes v1 --> v2:
> > - Update the license of the dt-binding header file to make the license
> >   compatible with dts files.
> > - Fix the dt_binding_check errors.
> >
> > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> +++++++++++++++++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53
> ++++++++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> 46 ++++++++++++++++-
> > drivers/pci/controller/dwc/pci-imx6.c                        |  63
> ++++++++++++++++++++++-
> > drivers/phy/freescale/Kconfig                                |   9
> ++++
> > drivers/phy/freescale/Makefile                               |   1
> +
> > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++
> > include/dt-bindings/phy/phy-imx8-pcie.h                      |  14
> ++++++
> > 9 files changed, 486 insertions(+), 3 deletions(-)
> >
> > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > add the imx8mm pcie support
> 
> Richard and Lucas,
> 
> Thanks for your collective work on this series!
> 
> I have imx8mm-venice boards to test this on both with and without PCIe
> bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl has been
> merged there) and end up hanging waiting for PHY ready timeout.
[Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next applied the blk-ctl issue by Lucas [2] in commit.
Can you help to make a re-tests?
As I know that the blk-ctl is not merged yet.
Hi Lucas:
Am I right?

BR
Richard

> 
> [    1.454308] imx6q-pcie 33800000.pcie:       IO
> 0x001ff80000..0x001ff8ffff -> 0x0
> [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> 0x0018000000..0x001fefffff -> 0x0
> [    1.476344] libphy: fec_enet_mii_bus: probed
> [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!
> 
> I can verify that imx8_pcie_phy_probe returns successfully and the the phy
> node (imx6_pcie->phy) was found.
> 
> Here is the dt change I made for the imx8mm-venice-gw71xx-0x board that
> has no bridge:
[Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF clock(same to EVK board design), right?

> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> index 91544576f145..e89e9cf7318e 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> @@ -5,6 +5,7 @@
> 
>  #include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> 
>  / {
>         aliases {
> @@ -33,6 +34,12 @@
>                 };
>         };
> 
> +       pcie0_refclk: pcie0-refclk {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <100000000>;
> +       };
> +
>         pps {
>                 compatible = "pps-gpio";
>                 pinctrl-names = "default"; @@ -101,6 +108,27 @@
>         status = "okay";
>  };
> 
> +&pcie0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_pcie0>;
> +       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
> +       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> +                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> +       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +       assigned-clock-rates = <10000000>, <250000000>;
> +       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +                                <&clk IMX8MM_SYS_PLL2_250M>;
> +       status = "okay";
> +};
> +
> +&pcie_phy {
> +       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +       clocks = <&clk IMX8MM_CLK_DUMMY>;
> +       status = "okay";
> +};
> +
>  /* GPS */
>  &uart1 {
>         pinctrl-names = "default";
> @@ -162,6 +190,12 @@
>                 >;
>         };
> 
> +       pinctrl_pcie0: pciegrp {
> +               fsl,pins = <
> +                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6
> 0x41
> +               >;
> +       };
> +
>         pinctrl_pps: ppsgrp {
>                 fsl,pins = <
>                         MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15
> 0x41
> 
> and here are the changes to the imx8mm-venice-gw72xx-0x dt - this board
> has a PCIe bridge:
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> index b12ead847302..260ea93ebfc2 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> @@ -5,9 +5,11 @@
> 
>  #include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> 
>  / {
>         aliases {
> +               ethernet1 = &eth1;
>                 usb0 = &usbotg1;
>                 usb1 = &usbotg2;
>         };
> @@ -33,6 +35,12 @@
>                 };
>         };
> 
> +       pcie0_refclk: pcie0-refclk {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <100000000>;
> +       };
> +
>         pps {
>                 compatible = "pps-gpio";
>                 pinctrl-names = "default"; @@ -122,6 +130,53 @@
>         status = "okay";
>  };
> 
> +&pcie0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_pcie0>;
> +       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
> +       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> +                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> +       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +       assigned-clock-rates = <10000000>, <250000000>;
> +       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +                                <&clk IMX8MM_SYS_PLL2_250M>;
> +       status = "okay";
> +
> +       pcie@0,0 {
> +               reg = <0x0000 0 0 0 0>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               pcie@1,0 {
> +                       reg = <0x0000 0 0 0 0>;
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +
> +                       pcie@2,3 {
> +                               reg = <0x1800 0 0 0 0>;
> +                               #address-cells = <1>;
> +                               #size-cells = <0>;
> +
> +                               eth1: pcie@5,0 {
> +                                       reg = <0x0000 0 0 0 0>;
> +                                       #address-cells = <1>;
> +                                       #size-cells = <0>;
> +
> +                                       local-mac-address = [00 00
> 00 00 00 00];
> +                               };
> +                       };
> +               };
> +       };
> +};
> +
> +&pcie_phy {
> +       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +       clocks = <&clk IMX8MM_CLK_DUMMY>;
> +       status = "okay";
> +};
> +
>  /* off-board header */
>  &sai3 {
>         pinctrl-names = "default";
> @@ -214,6 +269,12 @@
>                 >;
>         };
> 
> +       pinctrl_pcie0: pciegrp {
> +               fsl,pins = <
> +                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6
> 0x41
> +               >;
> +       };
> +
>         pinctrl_pps: ppsgrp {
>                 fsl,pins = <
>                         MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15
> 0x41
> 
> 
> Any ideas?
> 
> Perhaps

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Saturday, October 16, 2021 3:59 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> <l.stach@pengutronix.de>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree Mailing
> List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > driver when enable i.MX8MM PCIe support.
> >
> > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> >
> > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > [2] and this PHY driver patch-set.
> >
> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> 120
> >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> nxp.c
> >
> om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> 99c5c3016
> >
> 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> ;sdata=
> >
> Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> ved=0
> > [2]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> 40
> > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> g.zhu%
> >
> 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> fa92cd99
> >
> c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjo
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp
> > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPYMo
> %3D&amp;rese
> > rved=0
> >
> > Main changes v2 --> v3:
> > - Regarding Lucas' comments.
> >  - to have a whole view to review the patches, send out the i.MX8MM PCIe
> support too.
> >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> PHY driver.
> >  - split the dts changes to SOC and board DT, and use the enum instead of
> raw value.
> >  - update the license of the dt-binding header file.
> >
> > Changes v1 --> v2:
> > - Update the license of the dt-binding header file to make the license
> >   compatible with dts files.
> > - Fix the dt_binding_check errors.
> >
> > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> +++++++++++++++++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53
> ++++++++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> 46 ++++++++++++++++-
> > drivers/pci/controller/dwc/pci-imx6.c                        |  63
> ++++++++++++++++++++++-
> > drivers/phy/freescale/Kconfig                                |   9
> ++++
> > drivers/phy/freescale/Makefile                               |   1
> +
> > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++
> > include/dt-bindings/phy/phy-imx8-pcie.h                      |  14
> ++++++
> > 9 files changed, 486 insertions(+), 3 deletions(-)
> >
> > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > add the imx8mm pcie support
> 
> Richard and Lucas,
> 
> Thanks for your collective work on this series!
> 
> I have imx8mm-venice boards to test this on both with and without PCIe
> bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl has been
> merged there) and end up hanging waiting for PHY ready timeout.
[Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next applied the blk-ctl issue by Lucas [2] in commit.
Can you help to make a re-tests?
As I know that the blk-ctl is not merged yet.
Hi Lucas:
Am I right?

BR
Richard

> 
> [    1.454308] imx6q-pcie 33800000.pcie:       IO
> 0x001ff80000..0x001ff8ffff -> 0x0
> [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> 0x0018000000..0x001fefffff -> 0x0
> [    1.476344] libphy: fec_enet_mii_bus: probed
> [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!
> 
> I can verify that imx8_pcie_phy_probe returns successfully and the the phy
> node (imx6_pcie->phy) was found.
> 
> Here is the dt change I made for the imx8mm-venice-gw71xx-0x board that
> has no bridge:
[Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF clock(same to EVK board design), right?

> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> index 91544576f145..e89e9cf7318e 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> @@ -5,6 +5,7 @@
> 
>  #include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> 
>  / {
>         aliases {
> @@ -33,6 +34,12 @@
>                 };
>         };
> 
> +       pcie0_refclk: pcie0-refclk {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <100000000>;
> +       };
> +
>         pps {
>                 compatible = "pps-gpio";
>                 pinctrl-names = "default"; @@ -101,6 +108,27 @@
>         status = "okay";
>  };
> 
> +&pcie0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_pcie0>;
> +       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
> +       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> +                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> +       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +       assigned-clock-rates = <10000000>, <250000000>;
> +       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +                                <&clk IMX8MM_SYS_PLL2_250M>;
> +       status = "okay";
> +};
> +
> +&pcie_phy {
> +       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +       clocks = <&clk IMX8MM_CLK_DUMMY>;
> +       status = "okay";
> +};
> +
>  /* GPS */
>  &uart1 {
>         pinctrl-names = "default";
> @@ -162,6 +190,12 @@
>                 >;
>         };
> 
> +       pinctrl_pcie0: pciegrp {
> +               fsl,pins = <
> +                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6
> 0x41
> +               >;
> +       };
> +
>         pinctrl_pps: ppsgrp {
>                 fsl,pins = <
>                         MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15
> 0x41
> 
> and here are the changes to the imx8mm-venice-gw72xx-0x dt - this board
> has a PCIe bridge:
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> index b12ead847302..260ea93ebfc2 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> @@ -5,9 +5,11 @@
> 
>  #include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> 
>  / {
>         aliases {
> +               ethernet1 = &eth1;
>                 usb0 = &usbotg1;
>                 usb1 = &usbotg2;
>         };
> @@ -33,6 +35,12 @@
>                 };
>         };
> 
> +       pcie0_refclk: pcie0-refclk {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <100000000>;
> +       };
> +
>         pps {
>                 compatible = "pps-gpio";
>                 pinctrl-names = "default"; @@ -122,6 +130,53 @@
>         status = "okay";
>  };
> 
> +&pcie0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_pcie0>;
> +       reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>;
> +       clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk
> IMX8MM_CLK_PCIE1_AUX>,
> +                <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>;
> +       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +       assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> +                         <&clk IMX8MM_CLK_PCIE1_CTRL>;
> +       assigned-clock-rates = <10000000>, <250000000>;
> +       assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> +                                <&clk IMX8MM_SYS_PLL2_250M>;
> +       status = "okay";
> +
> +       pcie@0,0 {
> +               reg = <0x0000 0 0 0 0>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               pcie@1,0 {
> +                       reg = <0x0000 0 0 0 0>;
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +
> +                       pcie@2,3 {
> +                               reg = <0x1800 0 0 0 0>;
> +                               #address-cells = <1>;
> +                               #size-cells = <0>;
> +
> +                               eth1: pcie@5,0 {
> +                                       reg = <0x0000 0 0 0 0>;
> +                                       #address-cells = <1>;
> +                                       #size-cells = <0>;
> +
> +                                       local-mac-address = [00 00
> 00 00 00 00];
> +                               };
> +                       };
> +               };
> +       };
> +};
> +
> +&pcie_phy {
> +       fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> +       clocks = <&clk IMX8MM_CLK_DUMMY>;
> +       status = "okay";
> +};
> +
>  /* off-board header */
>  &sai3 {
>         pinctrl-names = "default";
> @@ -214,6 +269,12 @@
>                 >;
>         };
> 
> +       pinctrl_pcie0: pciegrp {
> +               fsl,pins = <
> +                       MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6
> 0x41
> +               >;
> +       };
> +
>         pinctrl_pps: ppsgrp {
>                 fsl,pins = <
>                         MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15
> 0x41
> 
> 
> Any ideas?
> 
> Perhaps

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Saturday, October 16, 2021 3:59 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > <l.stach@pengutronix.de>
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree Mailing
> > List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > > driver when enable i.MX8MM PCIe support.
> > >
> > > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> > >
> > > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > > [2] and this PHY driver patch-set.
> > >
> > > [1]
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > 120
> > >
> > -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > nxp.c
> > >
> > om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > 99c5c3016
> > >
> > 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLj
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > ;sdata=
> > >
> > Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > ved=0
> > > [2]
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > 40
> > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> > g.zhu%
> > >
> > 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > fa92cd99
> > >
> > c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjo
> > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > 00&amp
> > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPYMo
> > %3D&amp;rese
> > > rved=0
> > >
> > > Main changes v2 --> v3:
> > > - Regarding Lucas' comments.
> > >  - to have a whole view to review the patches, send out the i.MX8MM PCIe
> > support too.
> > >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> > PHY driver.
> > >  - split the dts changes to SOC and board DT, and use the enum instead of
> > raw value.
> > >  - update the license of the dt-binding header file.
> > >
> > > Changes v1 --> v2:
> > > - Update the license of the dt-binding header file to make the license
> > >   compatible with dts files.
> > > - Fix the dt_binding_check errors.
> > >
> > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > +++++++++++++++++++++++++++++
> > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53
> > ++++++++++++++++++++
> > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > 46 ++++++++++++++++-
> > > drivers/pci/controller/dwc/pci-imx6.c                        |  63
> > ++++++++++++++++++++++-
> > > drivers/phy/freescale/Kconfig                                |   9
> > ++++
> > > drivers/phy/freescale/Makefile                               |   1
> > +
> > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > ++++++++++++++++++
> > > include/dt-bindings/phy/phy-imx8-pcie.h                      |  14
> > ++++++
> > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > >
> > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > add the imx8mm pcie support
> >
> > Richard and Lucas,
> >
> > Thanks for your collective work on this series!
> >
> > I have imx8mm-venice boards to test this on both with and without PCIe
> > bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl has been
> > merged there) and end up hanging waiting for PHY ready timeout.
> [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next applied the blk-ctl issue by Lucas [2] in commit.
> Can you help to make a re-tests?
> As I know that the blk-ctl is not merged yet.
> Hi Lucas:
> Am I right?
>

Richard,

v5 of blk-ctl is merged into Shawn's for-next tree.

> >
> > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > 0x001ff80000..0x001ff8ffff -> 0x0
> > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > 0x0018000000..0x001fefffff -> 0x0
> > [    1.476344] libphy: fec_enet_mii_bus: probed
> > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!
> >
> > I can verify that imx8_pcie_phy_probe returns successfully and the the phy
> > node (imx6_pcie->phy) was found.
> >
> > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board that
> > has no bridge:
> [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF clock(same to EVK board design), right?

Correct, an ext osc is used like EVK.

I applied v5 blk-ctl and your v3 series on top of pci/next and came up
with the same issue. Do you have a git repo I could try to make sure
I'm not missing anything?

Also, as Lucas has requested some changes do you have a v4 coming soon
that I should wait for to try? I believe this has something to do with
the phy reset where some of his changes were requested.

Best regards,

Tim

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Saturday, October 16, 2021 3:59 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > <l.stach@pengutronix.de>
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree Mailing
> > List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > > driver when enable i.MX8MM PCIe support.
> > >
> > > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> > >
> > > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > > [2] and this PHY driver patch-set.
> > >
> > > [1]
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > 120
> > >
> > -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > nxp.c
> > >
> > om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > 99c5c3016
> > >
> > 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLj
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > ;sdata=
> > >
> > Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > ved=0
> > > [2]
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > 40
> > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> > g.zhu%
> > >
> > 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > fa92cd99
> > >
> > c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjo
> > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > 00&amp
> > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPYMo
> > %3D&amp;rese
> > > rved=0
> > >
> > > Main changes v2 --> v3:
> > > - Regarding Lucas' comments.
> > >  - to have a whole view to review the patches, send out the i.MX8MM PCIe
> > support too.
> > >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> > PHY driver.
> > >  - split the dts changes to SOC and board DT, and use the enum instead of
> > raw value.
> > >  - update the license of the dt-binding header file.
> > >
> > > Changes v1 --> v2:
> > > - Update the license of the dt-binding header file to make the license
> > >   compatible with dts files.
> > > - Fix the dt_binding_check errors.
> > >
> > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > +++++++++++++++++++++++++++++
> > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53
> > ++++++++++++++++++++
> > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > 46 ++++++++++++++++-
> > > drivers/pci/controller/dwc/pci-imx6.c                        |  63
> > ++++++++++++++++++++++-
> > > drivers/phy/freescale/Kconfig                                |   9
> > ++++
> > > drivers/phy/freescale/Makefile                               |   1
> > +
> > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > ++++++++++++++++++
> > > include/dt-bindings/phy/phy-imx8-pcie.h                      |  14
> > ++++++
> > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > >
> > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > add the imx8mm pcie support
> >
> > Richard and Lucas,
> >
> > Thanks for your collective work on this series!
> >
> > I have imx8mm-venice boards to test this on both with and without PCIe
> > bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl has been
> > merged there) and end up hanging waiting for PHY ready timeout.
> [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next applied the blk-ctl issue by Lucas [2] in commit.
> Can you help to make a re-tests?
> As I know that the blk-ctl is not merged yet.
> Hi Lucas:
> Am I right?
>

Richard,

v5 of blk-ctl is merged into Shawn's for-next tree.

> >
> > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > 0x001ff80000..0x001ff8ffff -> 0x0
> > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > 0x0018000000..0x001fefffff -> 0x0
> > [    1.476344] libphy: fec_enet_mii_bus: probed
> > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!
> >
> > I can verify that imx8_pcie_phy_probe returns successfully and the the phy
> > node (imx6_pcie->phy) was found.
> >
> > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board that
> > has no bridge:
> [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF clock(same to EVK board design), right?

Correct, an ext osc is used like EVK.

I applied v5 blk-ctl and your v3 series on top of pci/next and came up
with the same issue. Do you have a git repo I could try to make sure
I'm not missing anything?

Also, as Lucas has requested some changes do you have a v4 coming soon
that I should wait for to try? I believe this has something to do with
the phy reset where some of his changes were requested.

Best regards,

Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Saturday, October 16, 2021 3:59 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > <l.stach@pengutronix.de>
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree Mailing
> > List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > > driver when enable i.MX8MM PCIe support.
> > >
> > > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> > >
> > > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > > [2] and this PHY driver patch-set.
> > >
> > > [1]
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > 120
> > >
> > -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > nxp.c
> > >
> > om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > 99c5c3016
> > >
> > 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLj
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > ;sdata=
> > >
> > Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > ved=0
> > > [2]
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > 40
> > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> > g.zhu%
> > >
> > 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > fa92cd99
> > >
> > c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjo
> > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > 00&amp
> > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPYMo
> > %3D&amp;rese
> > > rved=0
> > >
> > > Main changes v2 --> v3:
> > > - Regarding Lucas' comments.
> > >  - to have a whole view to review the patches, send out the i.MX8MM PCIe
> > support too.
> > >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> > PHY driver.
> > >  - split the dts changes to SOC and board DT, and use the enum instead of
> > raw value.
> > >  - update the license of the dt-binding header file.
> > >
> > > Changes v1 --> v2:
> > > - Update the license of the dt-binding header file to make the license
> > >   compatible with dts files.
> > > - Fix the dt_binding_check errors.
> > >
> > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > +++++++++++++++++++++++++++++
> > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53
> > ++++++++++++++++++++
> > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > 46 ++++++++++++++++-
> > > drivers/pci/controller/dwc/pci-imx6.c                        |  63
> > ++++++++++++++++++++++-
> > > drivers/phy/freescale/Kconfig                                |   9
> > ++++
> > > drivers/phy/freescale/Makefile                               |   1
> > +
> > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > ++++++++++++++++++
> > > include/dt-bindings/phy/phy-imx8-pcie.h                      |  14
> > ++++++
> > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > >
> > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > add the imx8mm pcie support
> >
> > Richard and Lucas,
> >
> > Thanks for your collective work on this series!
> >
> > I have imx8mm-venice boards to test this on both with and without PCIe
> > bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl has been
> > merged there) and end up hanging waiting for PHY ready timeout.
> [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next applied the blk-ctl issue by Lucas [2] in commit.
> Can you help to make a re-tests?
> As I know that the blk-ctl is not merged yet.
> Hi Lucas:
> Am I right?
>

Richard,

v5 of blk-ctl is merged into Shawn's for-next tree.

> >
> > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > 0x001ff80000..0x001ff8ffff -> 0x0
> > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > 0x0018000000..0x001fefffff -> 0x0
> > [    1.476344] libphy: fec_enet_mii_bus: probed
> > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout!
> >
> > I can verify that imx8_pcie_phy_probe returns successfully and the the phy
> > node (imx6_pcie->phy) was found.
> >
> > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board that
> > has no bridge:
> [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF clock(same to EVK board design), right?

Correct, an ext osc is used like EVK.

I applied v5 blk-ctl and your v3 series on top of pci/next and came up
with the same issue. Do you have a git repo I could try to make sure
I'm not missing anything?

Also, as Lucas has requested some changes do you have a v4 coming soon
that I should wait for to try? I believe this has something to do with
the phy reset where some of his changes were requested.

Best regards,

Tim

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Tuesday, October 19, 2021 11:53 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Saturday, October 16, 2021 3:59 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > > <l.stach@pengutronix.de>
> > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob
> > > Herring <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree
> > > Mailing List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > pcie support
> > >
> > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > refer to the discussion [1] when try to enable i.MX8MM PCIe
> > > > support, one standalone PCIe PHY driver should be seperated from
> > > > i.MX PCIe driver when enable i.MX8MM PCIe support.
> > > >
> > > > This patch-set adds the standalone PCIe PHY driver suport[1-5],
> > > > and i.MX8MM PCIe support[6-9] to have whole view to review this
> patch-set.
> > > >
> > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power
> > > > driver [2] and this PHY driver patch-set.
> > > >
> > > > [1]
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > patc
> > > >
> > >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > > 120
> > > >
> > >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > > nxp.c
> > > >
> > >
> om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > > 99c5c3016
> > > >
> > >
> 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > > JWIjoiMC4wLj
> > > >
> > >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > > ;sdata=
> > > >
> > >
> Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > > ved=0
> > > > [2]
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > patc
> > > >
> > >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > > 40
> > > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chon
> gxin
> > > g.zhu%
> > > >
> > >
> 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > > fa92cd99
> > > >
> > >
> c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > > sb3d8eyJWIjo
> > > >
> > >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > 00&amp
> > > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPY
> Mo
> > > %3D&amp;rese
> > > > rved=0
> > > >
> > > > Main changes v2 --> v3:
> > > > - Regarding Lucas' comments.
> > > >  - to have a whole view to review the patches, send out the
> > > > i.MX8MM PCIe
> > > support too.
> > > >  - move the PHY related bits manipulations of the GPR/SRC to
> > > > standalone
> > > PHY driver.
> > > >  - split the dts changes to SOC and board DT, and use the enum
> > > > instead of
> > > raw value.
> > > >  - update the license of the dt-binding header file.
> > > >
> > > > Changes v1 --> v2:
> > > > - Update the license of the dt-binding header file to make the license
> > > >   compatible with dts files.
> > > > - Fix the dt_binding_check errors.
> > > >
> > > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> +++
> > > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > > +++++++++++++++++++++++++++++
> > > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> 53
> > > ++++++++++++++++++++
> > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > > 46 ++++++++++++++++-
> > > > drivers/pci/controller/dwc/pci-imx6.c                        |
> 63
> > > ++++++++++++++++++++++-
> > > > drivers/phy/freescale/Kconfig                                |
> 9
> > > ++++
> > > > drivers/phy/freescale/Makefile                               |
> 1
> > > +
> > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> 218
> > >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > ++++++++++++++++++
> > > > include/dt-bindings/phy/phy-imx8-pcie.h                      |
> 14
> > > ++++++
> > > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > > >
> > > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for
> > > > the [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver
> > > > support [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy
> > > > support [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> > > > support [PATCH v3 5/9]
> > > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > > add the imx8mm pcie support
> > >
> > > Richard and Lucas,
> > >
> > > Thanks for your collective work on this series!
> > >
> > > I have imx8mm-venice boards to test this on both with and without
> > > PCIe bridges. I've tested this on top of Shawn's imx/for-next (as
> > > blk-ctl has been merged there) and end up hanging waiting for PHY ready
> timeout.
> > [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next
> applied the blk-ctl issue by Lucas [2] in commit.
> > Can you help to make a re-tests?
> > As I know that the blk-ctl is not merged yet.
> > Hi Lucas:
> > Am I right?
> >
> 
> Richard,
> 
> v5 of blk-ctl is merged into Shawn's for-next tree.
> 
[Richard Zhu] Got that.
Thanks.

> > >
> > > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > > 0x001ff80000..0x001ff8ffff -> 0x0
> > > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > > 0x0018000000..0x001fefffff -> 0x0
> > > [    1.476344] libphy: fec_enet_mii_bus: probed
> > > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready
> timeout!
> > >
> > > I can verify that imx8_pcie_phy_probe returns successfully and the
> > > the phy node (imx6_pcie->phy) was found.
> > >
> > > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
> > > that has no bridge:
> > [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF
> clock(same to EVK board design), right?
> 
> Correct, an ext osc is used like EVK.
> 
> I applied v5 blk-ctl and your v3 series on top of pci/next and came up with the
> same issue. Do you have a git repo I could try to make sure I'm not missing
> anything?
> 
> Also, as Lucas has requested some changes do you have a v4 coming soon that
> I should wait for to try? I believe this has something to do with the phy reset
> where some of his changes were requested.
[Richard Zhu] Unfortunately, I don't have personal git repo. But I think we stand on same base-line.
I tried on Shawn's next tree with my v3 series today.
PCIe NVME device works fine on my i.MX8MM EVK board, although there is git-am failure in the last patch when I apply the v3 series.
Part of the logs:
"
root@imx8_all:~# lspci
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
01:00.0 Non-Volatile memory controller: Sandisk Corp Device 5002
root@imx8_all:~# uname -a
Linux imx8_all 5.15.0-rc1-00091-g8bd7cd1cc7f0-dirty #1 SMP PREEMPT Wed Oct 20 09:22:32 CST 2021 aarch64 aarch64 aarch64 GNU/Linux
...
[    1.164144] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
[    1.172114] imx6q-pcie 33800000.pcie:       IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
[    1.182447] imx6q-pcie 33800000.pcie:      MEM 0x0018000000..0x001fefffff -> 0x0018000000
[    1.304429] imx6q-pcie 33800000.pcie: invalid resource
[    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
[    1.429803] imx6q-pcie 33800000.pcie: Link up
[    1.534497] imx6q-pcie 33800000.pcie: Link up
[    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
[    1.550364] imx6q-pcie 33800000.pcie: Link up
[    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
[    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    1.580055] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
[    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    1.606033] pci 0000:00:00.0: supports D1
[    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
[    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff 64bit]
[    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
[    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem 0x18100000-0x181fffff]
[    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem 0x18200000-0x1820ffff pref]
[    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x18103fff 64bit]
[    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem 0x18104000-0x181040ff 64bit]
[    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[    1.705814] pci 0000:00:00.0:   bridge window [mem 0x18100000-0x181fffff]
[    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
"
Regarding the log you pasted, it seems that the clock is not feed to PHY properly.

Anyway, let's waiting for the v4 series, then make a try. Thanks for your great help to make the double tests.

BR
Richard
> 
> Best regards,
> 
> Tim

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Tuesday, October 19, 2021 11:53 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Saturday, October 16, 2021 3:59 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > > <l.stach@pengutronix.de>
> > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob
> > > Herring <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree
> > > Mailing List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > pcie support
> > >
> > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > refer to the discussion [1] when try to enable i.MX8MM PCIe
> > > > support, one standalone PCIe PHY driver should be seperated from
> > > > i.MX PCIe driver when enable i.MX8MM PCIe support.
> > > >
> > > > This patch-set adds the standalone PCIe PHY driver suport[1-5],
> > > > and i.MX8MM PCIe support[6-9] to have whole view to review this
> patch-set.
> > > >
> > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power
> > > > driver [2] and this PHY driver patch-set.
> > > >
> > > > [1]
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > patc
> > > >
> > >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > > 120
> > > >
> > >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > > nxp.c
> > > >
> > >
> om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > > 99c5c3016
> > > >
> > >
> 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > > JWIjoiMC4wLj
> > > >
> > >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > > ;sdata=
> > > >
> > >
> Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > > ved=0
> > > > [2]
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > patc
> > > >
> > >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > > 40
> > > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chon
> gxin
> > > g.zhu%
> > > >
> > >
> 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > > fa92cd99
> > > >
> > >
> c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > > sb3d8eyJWIjo
> > > >
> > >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > 00&amp
> > > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPY
> Mo
> > > %3D&amp;rese
> > > > rved=0
> > > >
> > > > Main changes v2 --> v3:
> > > > - Regarding Lucas' comments.
> > > >  - to have a whole view to review the patches, send out the
> > > > i.MX8MM PCIe
> > > support too.
> > > >  - move the PHY related bits manipulations of the GPR/SRC to
> > > > standalone
> > > PHY driver.
> > > >  - split the dts changes to SOC and board DT, and use the enum
> > > > instead of
> > > raw value.
> > > >  - update the license of the dt-binding header file.
> > > >
> > > > Changes v1 --> v2:
> > > > - Update the license of the dt-binding header file to make the license
> > > >   compatible with dts files.
> > > > - Fix the dt_binding_check errors.
> > > >
> > > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> +++
> > > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > > +++++++++++++++++++++++++++++
> > > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> 53
> > > ++++++++++++++++++++
> > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > > 46 ++++++++++++++++-
> > > > drivers/pci/controller/dwc/pci-imx6.c                        |
> 63
> > > ++++++++++++++++++++++-
> > > > drivers/phy/freescale/Kconfig                                |
> 9
> > > ++++
> > > > drivers/phy/freescale/Makefile                               |
> 1
> > > +
> > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> 218
> > >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > ++++++++++++++++++
> > > > include/dt-bindings/phy/phy-imx8-pcie.h                      |
> 14
> > > ++++++
> > > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > > >
> > > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for
> > > > the [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver
> > > > support [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy
> > > > support [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> > > > support [PATCH v3 5/9]
> > > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > > add the imx8mm pcie support
> > >
> > > Richard and Lucas,
> > >
> > > Thanks for your collective work on this series!
> > >
> > > I have imx8mm-venice boards to test this on both with and without
> > > PCIe bridges. I've tested this on top of Shawn's imx/for-next (as
> > > blk-ctl has been merged there) and end up hanging waiting for PHY ready
> timeout.
> > [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next
> applied the blk-ctl issue by Lucas [2] in commit.
> > Can you help to make a re-tests?
> > As I know that the blk-ctl is not merged yet.
> > Hi Lucas:
> > Am I right?
> >
> 
> Richard,
> 
> v5 of blk-ctl is merged into Shawn's for-next tree.
> 
[Richard Zhu] Got that.
Thanks.

> > >
> > > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > > 0x001ff80000..0x001ff8ffff -> 0x0
> > > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > > 0x0018000000..0x001fefffff -> 0x0
> > > [    1.476344] libphy: fec_enet_mii_bus: probed
> > > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready
> timeout!
> > >
> > > I can verify that imx8_pcie_phy_probe returns successfully and the
> > > the phy node (imx6_pcie->phy) was found.
> > >
> > > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
> > > that has no bridge:
> > [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF
> clock(same to EVK board design), right?
> 
> Correct, an ext osc is used like EVK.
> 
> I applied v5 blk-ctl and your v3 series on top of pci/next and came up with the
> same issue. Do you have a git repo I could try to make sure I'm not missing
> anything?
> 
> Also, as Lucas has requested some changes do you have a v4 coming soon that
> I should wait for to try? I believe this has something to do with the phy reset
> where some of his changes were requested.
[Richard Zhu] Unfortunately, I don't have personal git repo. But I think we stand on same base-line.
I tried on Shawn's next tree with my v3 series today.
PCIe NVME device works fine on my i.MX8MM EVK board, although there is git-am failure in the last patch when I apply the v3 series.
Part of the logs:
"
root@imx8_all:~# lspci
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
01:00.0 Non-Volatile memory controller: Sandisk Corp Device 5002
root@imx8_all:~# uname -a
Linux imx8_all 5.15.0-rc1-00091-g8bd7cd1cc7f0-dirty #1 SMP PREEMPT Wed Oct 20 09:22:32 CST 2021 aarch64 aarch64 aarch64 GNU/Linux
...
[    1.164144] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
[    1.172114] imx6q-pcie 33800000.pcie:       IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
[    1.182447] imx6q-pcie 33800000.pcie:      MEM 0x0018000000..0x001fefffff -> 0x0018000000
[    1.304429] imx6q-pcie 33800000.pcie: invalid resource
[    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
[    1.429803] imx6q-pcie 33800000.pcie: Link up
[    1.534497] imx6q-pcie 33800000.pcie: Link up
[    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
[    1.550364] imx6q-pcie 33800000.pcie: Link up
[    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
[    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    1.580055] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
[    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    1.606033] pci 0000:00:00.0: supports D1
[    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
[    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff 64bit]
[    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
[    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem 0x18100000-0x181fffff]
[    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem 0x18200000-0x1820ffff pref]
[    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x18103fff 64bit]
[    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem 0x18104000-0x181040ff 64bit]
[    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[    1.705814] pci 0000:00:00.0:   bridge window [mem 0x18100000-0x181fffff]
[    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
"
Regarding the log you pasted, it seems that the clock is not feed to PHY properly.

Anyway, let's waiting for the v4 series, then make a try. Thanks for your great help to make the double tests.

BR
Richard
> 
> Best regards,
> 
> Tim

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Tuesday, October 19, 2021 11:53 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Saturday, October 16, 2021 3:59 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > > <l.stach@pengutronix.de>
> > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob
> > > Herring <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree
> > > Mailing List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > pcie support
> > >
> > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > refer to the discussion [1] when try to enable i.MX8MM PCIe
> > > > support, one standalone PCIe PHY driver should be seperated from
> > > > i.MX PCIe driver when enable i.MX8MM PCIe support.
> > > >
> > > > This patch-set adds the standalone PCIe PHY driver suport[1-5],
> > > > and i.MX8MM PCIe support[6-9] to have whole view to review this
> patch-set.
> > > >
> > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power
> > > > driver [2] and this PHY driver patch-set.
> > > >
> > > > [1]
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > patc
> > > >
> > >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > > 120
> > > >
> > >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > > nxp.c
> > > >
> > >
> om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > > 99c5c3016
> > > >
> > >
> 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > > JWIjoiMC4wLj
> > > >
> > >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > > ;sdata=
> > > >
> > >
> Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > > ved=0
> > > > [2]
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > patc
> > > >
> > >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > > 40
> > > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chon
> gxin
> > > g.zhu%
> > > >
> > >
> 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > > fa92cd99
> > > >
> > >
> c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > > sb3d8eyJWIjo
> > > >
> > >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > 00&amp
> > > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPY
> Mo
> > > %3D&amp;rese
> > > > rved=0
> > > >
> > > > Main changes v2 --> v3:
> > > > - Regarding Lucas' comments.
> > > >  - to have a whole view to review the patches, send out the
> > > > i.MX8MM PCIe
> > > support too.
> > > >  - move the PHY related bits manipulations of the GPR/SRC to
> > > > standalone
> > > PHY driver.
> > > >  - split the dts changes to SOC and board DT, and use the enum
> > > > instead of
> > > raw value.
> > > >  - update the license of the dt-binding header file.
> > > >
> > > > Changes v1 --> v2:
> > > > - Update the license of the dt-binding header file to make the license
> > > >   compatible with dts files.
> > > > - Fix the dt_binding_check errors.
> > > >
> > > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> +++
> > > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > > +++++++++++++++++++++++++++++
> > > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> 53
> > > ++++++++++++++++++++
> > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > > 46 ++++++++++++++++-
> > > > drivers/pci/controller/dwc/pci-imx6.c                        |
> 63
> > > ++++++++++++++++++++++-
> > > > drivers/phy/freescale/Kconfig                                |
> 9
> > > ++++
> > > > drivers/phy/freescale/Makefile                               |
> 1
> > > +
> > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> 218
> > >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > ++++++++++++++++++
> > > > include/dt-bindings/phy/phy-imx8-pcie.h                      |
> 14
> > > ++++++
> > > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > > >
> > > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for
> > > > the [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver
> > > > support [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy
> > > > support [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> > > > support [PATCH v3 5/9]
> > > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > > add the imx8mm pcie support
> > >
> > > Richard and Lucas,
> > >
> > > Thanks for your collective work on this series!
> > >
> > > I have imx8mm-venice boards to test this on both with and without
> > > PCIe bridges. I've tested this on top of Shawn's imx/for-next (as
> > > blk-ctl has been merged there) and end up hanging waiting for PHY ready
> timeout.
> > [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next
> applied the blk-ctl issue by Lucas [2] in commit.
> > Can you help to make a re-tests?
> > As I know that the blk-ctl is not merged yet.
> > Hi Lucas:
> > Am I right?
> >
> 
> Richard,
> 
> v5 of blk-ctl is merged into Shawn's for-next tree.
> 
[Richard Zhu] Got that.
Thanks.

> > >
> > > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > > 0x001ff80000..0x001ff8ffff -> 0x0
> > > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > > 0x0018000000..0x001fefffff -> 0x0
> > > [    1.476344] libphy: fec_enet_mii_bus: probed
> > > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready
> timeout!
> > >
> > > I can verify that imx8_pcie_phy_probe returns successfully and the
> > > the phy node (imx6_pcie->phy) was found.
> > >
> > > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
> > > that has no bridge:
> > [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF
> clock(same to EVK board design), right?
> 
> Correct, an ext osc is used like EVK.
> 
> I applied v5 blk-ctl and your v3 series on top of pci/next and came up with the
> same issue. Do you have a git repo I could try to make sure I'm not missing
> anything?
> 
> Also, as Lucas has requested some changes do you have a v4 coming soon that
> I should wait for to try? I believe this has something to do with the phy reset
> where some of his changes were requested.
[Richard Zhu] Unfortunately, I don't have personal git repo. But I think we stand on same base-line.
I tried on Shawn's next tree with my v3 series today.
PCIe NVME device works fine on my i.MX8MM EVK board, although there is git-am failure in the last patch when I apply the v3 series.
Part of the logs:
"
root@imx8_all:~# lspci
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
01:00.0 Non-Volatile memory controller: Sandisk Corp Device 5002
root@imx8_all:~# uname -a
Linux imx8_all 5.15.0-rc1-00091-g8bd7cd1cc7f0-dirty #1 SMP PREEMPT Wed Oct 20 09:22:32 CST 2021 aarch64 aarch64 aarch64 GNU/Linux
...
[    1.164144] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
[    1.172114] imx6q-pcie 33800000.pcie:       IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
[    1.182447] imx6q-pcie 33800000.pcie:      MEM 0x0018000000..0x001fefffff -> 0x0018000000
[    1.304429] imx6q-pcie 33800000.pcie: invalid resource
[    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
[    1.429803] imx6q-pcie 33800000.pcie: Link up
[    1.534497] imx6q-pcie 33800000.pcie: Link up
[    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
[    1.550364] imx6q-pcie 33800000.pcie: Link up
[    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
[    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    1.580055] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
[    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    1.606033] pci 0000:00:00.0: supports D1
[    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
[    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff 64bit]
[    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
[    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem 0x18100000-0x181fffff]
[    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem 0x18200000-0x1820ffff pref]
[    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x18103fff 64bit]
[    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem 0x18104000-0x181040ff 64bit]
[    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[    1.705814] pci 0000:00:00.0:   bridge window [mem 0x18100000-0x181fffff]
[    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
"
Regarding the log you pasted, it seems that the clock is not feed to PHY properly.

Anyway, let's waiting for the v4 series, then make a try. Thanks for your great help to make the double tests.

BR
Richard
> 
> Best regards,
> 
> Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 19, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Tuesday, October 19, 2021 11:53 PM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Saturday, October 16, 2021 3:59 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > > > <l.stach@pengutronix.de>
> > > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob
> > > > Herring <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree
> > > > Mailing List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > > pcie support
> > > >
> > > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > refer to the discussion [1] when try to enable i.MX8MM PCIe
> > > > > support, one standalone PCIe PHY driver should be seperated from
> > > > > i.MX PCIe driver when enable i.MX8MM PCIe support.
> > > > >
> > > > > This patch-set adds the standalone PCIe PHY driver suport[1-5],
> > > > > and i.MX8MM PCIe support[6-9] to have whole view to review this
> > patch-set.
> > > > >
> > > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power
> > > > > driver [2] and this PHY driver patch-set.
> > > > >
> > > > > [1]
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > patc
> > > > >
> > > >
> > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > > > 120
> > > > >
> > > >
> > -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > > > nxp.c
> > > > >
> > > >
> > om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > > > 99c5c3016
> > > > >
> > > >
> > 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > > > JWIjoiMC4wLj
> > > > >
> > > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > > > ;sdata=
> > > > >
> > > >
> > Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > > > ved=0
> > > > > [2]
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > patc
> > > > >
> > > >
> > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > > > 40
> > > > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chon
> > gxin
> > > > g.zhu%
> > > > >
> > > >
> > 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > > > fa92cd99
> > > > >
> > > >
> > c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > > > sb3d8eyJWIjo
> > > > >
> > > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > > 00&amp
> > > > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPY
> > Mo
> > > > %3D&amp;rese
> > > > > rved=0
> > > > >
> > > > > Main changes v2 --> v3:
> > > > > - Regarding Lucas' comments.
> > > > >  - to have a whole view to review the patches, send out the
> > > > > i.MX8MM PCIe
> > > > support too.
> > > > >  - move the PHY related bits manipulations of the GPR/SRC to
> > > > > standalone
> > > > PHY driver.
> > > > >  - split the dts changes to SOC and board DT, and use the enum
> > > > > instead of
> > > > raw value.
> > > > >  - update the license of the dt-binding header file.
> > > > >
> > > > > Changes v1 --> v2:
> > > > > - Update the license of the dt-binding header file to make the license
> > > > >   compatible with dts files.
> > > > > - Fix the dt_binding_check errors.
> > > > >
> > > > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> > +++
> > > > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > > > +++++++++++++++++++++++++++++
> > > > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> > 53
> > > > ++++++++++++++++++++
> > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > > > 46 ++++++++++++++++-
> > > > > drivers/pci/controller/dwc/pci-imx6.c                        |
> > 63
> > > > ++++++++++++++++++++++-
> > > > > drivers/phy/freescale/Kconfig                                |
> > 9
> > > > ++++
> > > > > drivers/phy/freescale/Makefile                               |
> > 1
> > > > +
> > > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> > 218
> > > >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > ++++++++++++++++++
> > > > > include/dt-bindings/phy/phy-imx8-pcie.h                      |
> > 14
> > > > ++++++
> > > > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > > > >
> > > > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for
> > > > > the [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver
> > > > > support [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy
> > > > > support [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> > > > > support [PATCH v3 5/9]
> > > > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > > > add the imx8mm pcie support
> > > >
> > > > Richard and Lucas,
> > > >
> > > > Thanks for your collective work on this series!
> > > >
> > > > I have imx8mm-venice boards to test this on both with and without
> > > > PCIe bridges. I've tested this on top of Shawn's imx/for-next (as
> > > > blk-ctl has been merged there) and end up hanging waiting for PHY ready
> > timeout.
> > > [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next
> > applied the blk-ctl issue by Lucas [2] in commit.
> > > Can you help to make a re-tests?
> > > As I know that the blk-ctl is not merged yet.
> > > Hi Lucas:
> > > Am I right?
> > >
> >
> > Richard,
> >
> > v5 of blk-ctl is merged into Shawn's for-next tree.
> >
> [Richard Zhu] Got that.
> Thanks.
>
> > > >
> > > > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > > > 0x001ff80000..0x001ff8ffff -> 0x0
> > > > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > > > 0x0018000000..0x001fefffff -> 0x0
> > > > [    1.476344] libphy: fec_enet_mii_bus: probed
> > > > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > > > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready
> > timeout!
> > > >
> > > > I can verify that imx8_pcie_phy_probe returns successfully and the
> > > > the phy node (imx6_pcie->phy) was found.
> > > >
> > > > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
> > > > that has no bridge:
> > > [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF
> > clock(same to EVK board design), right?
> >
> > Correct, an ext osc is used like EVK.
> >
> > I applied v5 blk-ctl and your v3 series on top of pci/next and came up with the
> > same issue. Do you have a git repo I could try to make sure I'm not missing
> > anything?
> >
> > Also, as Lucas has requested some changes do you have a v4 coming soon that
> > I should wait for to try? I believe this has something to do with the phy reset
> > where some of his changes were requested.
> [Richard Zhu] Unfortunately, I don't have personal git repo. But I think we stand on same base-line.
> I tried on Shawn's next tree with my v3 series today.
> PCIe NVME device works fine on my i.MX8MM EVK board, although there is git-am failure in the last patch when I apply the v3 series.
> Part of the logs:
> "
> root@imx8_all:~# lspci
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
> 01:00.0 Non-Volatile memory controller: Sandisk Corp Device 5002
> root@imx8_all:~# uname -a
> Linux imx8_all 5.15.0-rc1-00091-g8bd7cd1cc7f0-dirty #1 SMP PREEMPT Wed Oct 20 09:22:32 CST 2021 aarch64 aarch64 aarch64 GNU/Linux
> ...
> [    1.164144] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
> [    1.172114] imx6q-pcie 33800000.pcie:       IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
> [    1.182447] imx6q-pcie 33800000.pcie:      MEM 0x0018000000..0x001fefffff -> 0x0018000000
> [    1.304429] imx6q-pcie 33800000.pcie: invalid resource

Richard,

What is this 'invalid resource' about? I see that with my downstream
IMX8MM PCIe driver as well and have been asked about it.

> [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
> [    1.429803] imx6q-pcie 33800000.pcie: Link up
> [    1.534497] imx6q-pcie 33800000.pcie: Link up
> [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> [    1.550364] imx6q-pcie 33800000.pcie: Link up
> [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> [    1.580055] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
> [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
> [    1.606033] pci 0000:00:00.0: supports D1
> [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
> [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
> [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff 64bit]
> [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
> [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
> [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem 0x18100000-0x181fffff]
> [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem 0x18200000-0x1820ffff pref]
> [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x18103fff 64bit]
> [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem 0x18104000-0x181040ff 64bit]
> [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> [    1.705814] pci 0000:00:00.0:   bridge window [mem 0x18100000-0x181fffff]
> [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> "
> Regarding the log you pasted, it seems that the clock is not feed to PHY properly.
>
> Anyway, let's waiting for the v4 series, then make a try. Thanks for your great help to make the double tests.
>

My boards do not use CLKREQ# so I do not have that defined in pinmux
and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
works on my board but this isn't a solution just a work-around (I have
boards that use the only two possible pins for CLKREQ as other
features).

Similarly you will find on the imx8mm-evk if you comment out the
CLKREQ (which isn't required) the imx8mmevk will end up hanging like
my boards:
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index 5ce43daa0c8b..f0023b48f475 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -448,7 +448,9 @@

        pinctrl_pcie0: pcie0grp {
                fsl,pins = <
+/*
                        MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
+*/
                        MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
                >;
        };

I have PCIe working with a driver that I ported from NXP's kernel
which differs from your driver in that the PCIe PHY is not abstracted
to its own driver so I think this has something to do with the order
in which the phy is reset or initialized? The configuration of gpr14
bits looks correct to me.

Best regards,

Tim

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 19, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Tuesday, October 19, 2021 11:53 PM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Saturday, October 16, 2021 3:59 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > > > <l.stach@pengutronix.de>
> > > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob
> > > > Herring <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree
> > > > Mailing List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > > pcie support
> > > >
> > > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > refer to the discussion [1] when try to enable i.MX8MM PCIe
> > > > > support, one standalone PCIe PHY driver should be seperated from
> > > > > i.MX PCIe driver when enable i.MX8MM PCIe support.
> > > > >
> > > > > This patch-set adds the standalone PCIe PHY driver suport[1-5],
> > > > > and i.MX8MM PCIe support[6-9] to have whole view to review this
> > patch-set.
> > > > >
> > > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power
> > > > > driver [2] and this PHY driver patch-set.
> > > > >
> > > > > [1]
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > patc
> > > > >
> > > >
> > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > > > 120
> > > > >
> > > >
> > -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > > > nxp.c
> > > > >
> > > >
> > om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > > > 99c5c3016
> > > > >
> > > >
> > 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > > > JWIjoiMC4wLj
> > > > >
> > > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > > > ;sdata=
> > > > >
> > > >
> > Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > > > ved=0
> > > > > [2]
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > patc
> > > > >
> > > >
> > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > > > 40
> > > > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chon
> > gxin
> > > > g.zhu%
> > > > >
> > > >
> > 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > > > fa92cd99
> > > > >
> > > >
> > c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > > > sb3d8eyJWIjo
> > > > >
> > > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > > 00&amp
> > > > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPY
> > Mo
> > > > %3D&amp;rese
> > > > > rved=0
> > > > >
> > > > > Main changes v2 --> v3:
> > > > > - Regarding Lucas' comments.
> > > > >  - to have a whole view to review the patches, send out the
> > > > > i.MX8MM PCIe
> > > > support too.
> > > > >  - move the PHY related bits manipulations of the GPR/SRC to
> > > > > standalone
> > > > PHY driver.
> > > > >  - split the dts changes to SOC and board DT, and use the enum
> > > > > instead of
> > > > raw value.
> > > > >  - update the license of the dt-binding header file.
> > > > >
> > > > > Changes v1 --> v2:
> > > > > - Update the license of the dt-binding header file to make the license
> > > > >   compatible with dts files.
> > > > > - Fix the dt_binding_check errors.
> > > > >
> > > > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> > +++
> > > > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > > > +++++++++++++++++++++++++++++
> > > > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> > 53
> > > > ++++++++++++++++++++
> > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > > > 46 ++++++++++++++++-
> > > > > drivers/pci/controller/dwc/pci-imx6.c                        |
> > 63
> > > > ++++++++++++++++++++++-
> > > > > drivers/phy/freescale/Kconfig                                |
> > 9
> > > > ++++
> > > > > drivers/phy/freescale/Makefile                               |
> > 1
> > > > +
> > > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> > 218
> > > >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > ++++++++++++++++++
> > > > > include/dt-bindings/phy/phy-imx8-pcie.h                      |
> > 14
> > > > ++++++
> > > > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > > > >
> > > > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for
> > > > > the [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver
> > > > > support [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy
> > > > > support [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> > > > > support [PATCH v3 5/9]
> > > > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > > > add the imx8mm pcie support
> > > >
> > > > Richard and Lucas,
> > > >
> > > > Thanks for your collective work on this series!
> > > >
> > > > I have imx8mm-venice boards to test this on both with and without
> > > > PCIe bridges. I've tested this on top of Shawn's imx/for-next (as
> > > > blk-ctl has been merged there) and end up hanging waiting for PHY ready
> > timeout.
> > > [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next
> > applied the blk-ctl issue by Lucas [2] in commit.
> > > Can you help to make a re-tests?
> > > As I know that the blk-ctl is not merged yet.
> > > Hi Lucas:
> > > Am I right?
> > >
> >
> > Richard,
> >
> > v5 of blk-ctl is merged into Shawn's for-next tree.
> >
> [Richard Zhu] Got that.
> Thanks.
>
> > > >
> > > > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > > > 0x001ff80000..0x001ff8ffff -> 0x0
> > > > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > > > 0x0018000000..0x001fefffff -> 0x0
> > > > [    1.476344] libphy: fec_enet_mii_bus: probed
> > > > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > > > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready
> > timeout!
> > > >
> > > > I can verify that imx8_pcie_phy_probe returns successfully and the
> > > > the phy node (imx6_pcie->phy) was found.
> > > >
> > > > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
> > > > that has no bridge:
> > > [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF
> > clock(same to EVK board design), right?
> >
> > Correct, an ext osc is used like EVK.
> >
> > I applied v5 blk-ctl and your v3 series on top of pci/next and came up with the
> > same issue. Do you have a git repo I could try to make sure I'm not missing
> > anything?
> >
> > Also, as Lucas has requested some changes do you have a v4 coming soon that
> > I should wait for to try? I believe this has something to do with the phy reset
> > where some of his changes were requested.
> [Richard Zhu] Unfortunately, I don't have personal git repo. But I think we stand on same base-line.
> I tried on Shawn's next tree with my v3 series today.
> PCIe NVME device works fine on my i.MX8MM EVK board, although there is git-am failure in the last patch when I apply the v3 series.
> Part of the logs:
> "
> root@imx8_all:~# lspci
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
> 01:00.0 Non-Volatile memory controller: Sandisk Corp Device 5002
> root@imx8_all:~# uname -a
> Linux imx8_all 5.15.0-rc1-00091-g8bd7cd1cc7f0-dirty #1 SMP PREEMPT Wed Oct 20 09:22:32 CST 2021 aarch64 aarch64 aarch64 GNU/Linux
> ...
> [    1.164144] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
> [    1.172114] imx6q-pcie 33800000.pcie:       IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
> [    1.182447] imx6q-pcie 33800000.pcie:      MEM 0x0018000000..0x001fefffff -> 0x0018000000
> [    1.304429] imx6q-pcie 33800000.pcie: invalid resource

Richard,

What is this 'invalid resource' about? I see that with my downstream
IMX8MM PCIe driver as well and have been asked about it.

> [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
> [    1.429803] imx6q-pcie 33800000.pcie: Link up
> [    1.534497] imx6q-pcie 33800000.pcie: Link up
> [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> [    1.550364] imx6q-pcie 33800000.pcie: Link up
> [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> [    1.580055] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
> [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
> [    1.606033] pci 0000:00:00.0: supports D1
> [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
> [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
> [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff 64bit]
> [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
> [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
> [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem 0x18100000-0x181fffff]
> [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem 0x18200000-0x1820ffff pref]
> [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x18103fff 64bit]
> [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem 0x18104000-0x181040ff 64bit]
> [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> [    1.705814] pci 0000:00:00.0:   bridge window [mem 0x18100000-0x181fffff]
> [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> "
> Regarding the log you pasted, it seems that the clock is not feed to PHY properly.
>
> Anyway, let's waiting for the v4 series, then make a try. Thanks for your great help to make the double tests.
>

My boards do not use CLKREQ# so I do not have that defined in pinmux
and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
works on my board but this isn't a solution just a work-around (I have
boards that use the only two possible pins for CLKREQ as other
features).

Similarly you will find on the imx8mm-evk if you comment out the
CLKREQ (which isn't required) the imx8mmevk will end up hanging like
my boards:
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index 5ce43daa0c8b..f0023b48f475 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -448,7 +448,9 @@

        pinctrl_pcie0: pcie0grp {
                fsl,pins = <
+/*
                        MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
+*/
                        MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
                >;
        };

I have PCIe working with a driver that I ported from NXP's kernel
which differs from your driver in that the PCIe PHY is not abstracted
to its own driver so I think this has something to do with the order
in which the phy is reset or initialized? The configuration of gpr14
bits looks correct to me.

Best regards,

Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 19, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Tuesday, October 19, 2021 11:53 PM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Saturday, October 16, 2021 3:59 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> > > > <l.stach@pengutronix.de>
> > > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob
> > > > Herring <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree
> > > > Mailing List <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > > pcie support
> > > >
> > > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > refer to the discussion [1] when try to enable i.MX8MM PCIe
> > > > > support, one standalone PCIe PHY driver should be seperated from
> > > > > i.MX PCIe driver when enable i.MX8MM PCIe support.
> > > > >
> > > > > This patch-set adds the standalone PCIe PHY driver suport[1-5],
> > > > > and i.MX8MM PCIe support[6-9] to have whole view to review this
> > patch-set.
> > > > >
> > > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power
> > > > > driver [2] and this PHY driver patch-set.
> > > > >
> > > > > [1]
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > patc
> > > > >
> > > >
> > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> > > > 120
> > > > >
> > > >
> > -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> > > > nxp.c
> > > > >
> > > >
> > om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > > > 99c5c3016
> > > > >
> > > >
> > 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > > > JWIjoiMC4wLj
> > > > >
> > > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > > > ;sdata=
> > > > >
> > > >
> > Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&amp;reser
> > > > ved=0
> > > > > [2]
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > patc
> > > > >
> > > >
> > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> > > > 40
> > > > > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chon
> > gxin
> > > > g.zhu%
> > > > >
> > > >
> > 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > > > fa92cd99
> > > > >
> > > >
> > c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > > > sb3d8eyJWIjo
> > > > >
> > > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > > 00&amp
> > > > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPY
> > Mo
> > > > %3D&amp;rese
> > > > > rved=0
> > > > >
> > > > > Main changes v2 --> v3:
> > > > > - Regarding Lucas' comments.
> > > > >  - to have a whole view to review the patches, send out the
> > > > > i.MX8MM PCIe
> > > > support too.
> > > > >  - move the PHY related bits manipulations of the GPR/SRC to
> > > > > standalone
> > > > PHY driver.
> > > > >  - split the dts changes to SOC and board DT, and use the enum
> > > > > instead of
> > > > raw value.
> > > > >  - update the license of the dt-binding header file.
> > > > >
> > > > > Changes v1 --> v2:
> > > > > - Update the license of the dt-binding header file to make the license
> > > > >   compatible with dts files.
> > > > > - Fix the dt_binding_check errors.
> > > > >
> > > > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> > +++
> > > > > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > > > +++++++++++++++++++++++++++++
> > > > > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> > 53
> > > > ++++++++++++++++++++
> > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |
> > > > 46 ++++++++++++++++-
> > > > > drivers/pci/controller/dwc/pci-imx6.c                        |
> > 63
> > > > ++++++++++++++++++++++-
> > > > > drivers/phy/freescale/Kconfig                                |
> > 9
> > > > ++++
> > > > > drivers/phy/freescale/Makefile                               |
> > 1
> > > > +
> > > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> > 218
> > > >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > ++++++++++++++++++
> > > > > include/dt-bindings/phy/phy-imx8-pcie.h                      |
> > 14
> > > > ++++++
> > > > > 9 files changed, 486 insertions(+), 3 deletions(-)
> > > > >
> > > > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for
> > > > > the [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver
> > > > > support [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy
> > > > > support [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy
> > > > > support [PATCH v3 5/9]
> > > > > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > > > > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > > > > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > > > > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > > > > add the imx8mm pcie support
> > > >
> > > > Richard and Lucas,
> > > >
> > > > Thanks for your collective work on this series!
> > > >
> > > > I have imx8mm-venice boards to test this on both with and without
> > > > PCIe bridges. I've tested this on top of Shawn's imx/for-next (as
> > > > blk-ctl has been merged there) and end up hanging waiting for PHY ready
> > timeout.
> > > [Richard Zhu] Sorry to reply late. I run the tests based on pci/for-next
> > applied the blk-ctl issue by Lucas [2] in commit.
> > > Can you help to make a re-tests?
> > > As I know that the blk-ctl is not merged yet.
> > > Hi Lucas:
> > > Am I right?
> > >
> >
> > Richard,
> >
> > v5 of blk-ctl is merged into Shawn's for-next tree.
> >
> [Richard Zhu] Got that.
> Thanks.
>
> > > >
> > > > [    1.454308] imx6q-pcie 33800000.pcie:       IO
> > > > 0x001ff80000..0x001ff8ffff -> 0x0
> > > > [    1.466538] imx6q-pcie 33800000.pcie:      MEM
> > > > 0x0018000000..0x001fefffff -> 0x0
> > > > [    1.476344] libphy: fec_enet_mii_bus: probed
> > > > [    1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110
> > > > [    1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready
> > timeout!
> > > >
> > > > I can verify that imx8_pcie_phy_probe returns successfully and the
> > > > the phy node (imx6_pcie->phy) was found.
> > > >
> > > > Here is the dt change I made for the imx8mm-venice-gw71xx-0x board
> > > > that has no bridge:
> > > [Richard Zhu] Refer to the changes, the external OSC is used as PCIe REF
> > clock(same to EVK board design), right?
> >
> > Correct, an ext osc is used like EVK.
> >
> > I applied v5 blk-ctl and your v3 series on top of pci/next and came up with the
> > same issue. Do you have a git repo I could try to make sure I'm not missing
> > anything?
> >
> > Also, as Lucas has requested some changes do you have a v4 coming soon that
> > I should wait for to try? I believe this has something to do with the phy reset
> > where some of his changes were requested.
> [Richard Zhu] Unfortunately, I don't have personal git repo. But I think we stand on same base-line.
> I tried on Shawn's next tree with my v3 series today.
> PCIe NVME device works fine on my i.MX8MM EVK board, although there is git-am failure in the last patch when I apply the v3 series.
> Part of the logs:
> "
> root@imx8_all:~# lspci
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
> 01:00.0 Non-Volatile memory controller: Sandisk Corp Device 5002
> root@imx8_all:~# uname -a
> Linux imx8_all 5.15.0-rc1-00091-g8bd7cd1cc7f0-dirty #1 SMP PREEMPT Wed Oct 20 09:22:32 CST 2021 aarch64 aarch64 aarch64 GNU/Linux
> ...
> [    1.164144] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
> [    1.172114] imx6q-pcie 33800000.pcie:       IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
> [    1.182447] imx6q-pcie 33800000.pcie:      MEM 0x0018000000..0x001fefffff -> 0x0018000000
> [    1.304429] imx6q-pcie 33800000.pcie: invalid resource

Richard,

What is this 'invalid resource' about? I see that with my downstream
IMX8MM PCIe driver as well and have been asked about it.

> [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
> [    1.429803] imx6q-pcie 33800000.pcie: Link up
> [    1.534497] imx6q-pcie 33800000.pcie: Link up
> [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> [    1.550364] imx6q-pcie 33800000.pcie: Link up
> [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> [    1.580055] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
> [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
> [    1.606033] pci 0000:00:00.0: supports D1
> [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
> [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
> [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff 64bit]
> [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
> [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
> [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem 0x18100000-0x181fffff]
> [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem 0x18200000-0x1820ffff pref]
> [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x18103fff 64bit]
> [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem 0x18104000-0x181040ff 64bit]
> [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> [    1.705814] pci 0000:00:00.0:   bridge window [mem 0x18100000-0x181fffff]
> [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> "
> Regarding the log you pasted, it seems that the clock is not feed to PHY properly.
>
> Anyway, let's waiting for the v4 series, then make a try. Thanks for your great help to make the double tests.
>

My boards do not use CLKREQ# so I do not have that defined in pinmux
and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
works on my board but this isn't a solution just a work-around (I have
boards that use the only two possible pins for CLKREQ as other
features).

Similarly you will find on the imx8mm-evk if you comment out the
CLKREQ (which isn't required) the imx8mmevk will end up hanging like
my boards:
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index 5ce43daa0c8b..f0023b48f475 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -448,7 +448,9 @@

        pinctrl_pcie0: pcie0grp {
                fsl,pins = <
+/*
                        MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
+*/
                        MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21       0x41
                >;
        };

I have PCIe working with a driver that I ported from NXP's kernel
which differs from your driver in that the PCIe PHY is not abstracted
to its own driver so I think this has something to do with the order
in which the phy is reset or initialized? The configuration of gpr14
bits looks correct to me.

Best regards,

Tim

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

<snipped...>
> 
> Richard,
> 
> What is this 'invalid resource' about? I see that with my downstream
> IMX8MM PCIe driver as well and have been asked about it.
> 
[Richard Zhu] Hi Tim:
This complain is caused by the following codes in pcie-designware.c driver.
I'm not sure that why there is only size assignment after the res valid check, and do nothing if the res is invalid.
It seems that it is an expected design logic refer to the later codes.
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
                        if (res)
                                pci->atu_size = resource_size(res);
                        pci->atu_base = devm_ioremap_resource(dev, res);
                        if (IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET;
                }

Since the default offset is used on i.MX8MM, the "atu" is not specified in i.MX8MM PCIe DT node, so there is no real res at all.
Then, devm_ioremap_resource() would complain the invalid resource.

> > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> outbound, 4 inbound
> > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > [    1.580055] pci_bus 0000:00: root bus resource [mem
> 0x18000000-0x1fefffff]
> > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff
> pref]
> > [    1.606033] pci 0000:00:00.0: supports D1
> > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> D3cold
> > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff
> 64bit]
> > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff
> 64bit]
> > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with
> 8.0 GT/s PCIe x4 link)
> > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> 0x18000000-0x180fffff]
> > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> 0x18100000-0x181fffff]
> > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> 0x18200000-0x1820ffff pref]
> > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> 0x18100000-0x18103fff 64bit]
> > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> 0x18104000-0x181040ff 64bit]
> > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> 0x18100000-0x181fffff]
> > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > "
> > Regarding the log you pasted, it seems that the clock is not feed to PHY
> properly.
> >
> > Anyway, let's waiting for the v4 series, then make a try. Thanks for your
> great help to make the double tests.
> >
> 
> My boards do not use CLKREQ# so I do not have that defined in pinmux and I
> found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
> works on my board but this isn't a solution just a work-around (I have boards
> that use the only two possible pins for CLKREQ as other features).
> 
> Similarly you will find on the imx8mm-evk if you comment out the CLKREQ
> (which isn't required) the imx8mmevk will end up hanging like my boards:
[Richard Zhu] Hi Tim:
Regarding the SPEC, the CLKREQ# is mandatory required, and should be configured as an open drain, active low signal.
And this signal should be driven low by the PCIe M.2 device to request the REF clock be available(active low).
So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.

Anyway, I think the external OSC circuit should be always running if there is no CLKREQ# on your HW board design.

> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index 5ce43daa0c8b..f0023b48f475 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -448,7 +448,9 @@
> 
>         pinctrl_pcie0: pcie0grp {
>                 fsl,pins = <
> +/*
> 
> MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> +*/
>                         MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> 0x41
>                 >;
>         };
> 
> I have PCIe working with a driver that I ported from NXP's kernel which differs
> from your driver in that the PCIe PHY is not abstracted to its own driver so I
> think this has something to do with the order in which the phy is reset or
> initialized? The configuration of gpr14 bits looks correct to me.
[Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW compatibility.
That's might the reason why the PCIe works on your HW board although the CLKREQ# PIN is not defined.
This method is a little rude and violate the SPEC, and not recommended although it levels up the HW compatibility.
So I drop this method in this series.

BR
Richard
> 
> Best regards,
> 
> Tim

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

<snipped...>
> 
> Richard,
> 
> What is this 'invalid resource' about? I see that with my downstream
> IMX8MM PCIe driver as well and have been asked about it.
> 
[Richard Zhu] Hi Tim:
This complain is caused by the following codes in pcie-designware.c driver.
I'm not sure that why there is only size assignment after the res valid check, and do nothing if the res is invalid.
It seems that it is an expected design logic refer to the later codes.
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
                        if (res)
                                pci->atu_size = resource_size(res);
                        pci->atu_base = devm_ioremap_resource(dev, res);
                        if (IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET;
                }

Since the default offset is used on i.MX8MM, the "atu" is not specified in i.MX8MM PCIe DT node, so there is no real res at all.
Then, devm_ioremap_resource() would complain the invalid resource.

> > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> outbound, 4 inbound
> > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > [    1.580055] pci_bus 0000:00: root bus resource [mem
> 0x18000000-0x1fefffff]
> > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff
> pref]
> > [    1.606033] pci 0000:00:00.0: supports D1
> > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> D3cold
> > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff
> 64bit]
> > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff
> 64bit]
> > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with
> 8.0 GT/s PCIe x4 link)
> > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> 0x18000000-0x180fffff]
> > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> 0x18100000-0x181fffff]
> > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> 0x18200000-0x1820ffff pref]
> > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> 0x18100000-0x18103fff 64bit]
> > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> 0x18104000-0x181040ff 64bit]
> > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> 0x18100000-0x181fffff]
> > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > "
> > Regarding the log you pasted, it seems that the clock is not feed to PHY
> properly.
> >
> > Anyway, let's waiting for the v4 series, then make a try. Thanks for your
> great help to make the double tests.
> >
> 
> My boards do not use CLKREQ# so I do not have that defined in pinmux and I
> found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
> works on my board but this isn't a solution just a work-around (I have boards
> that use the only two possible pins for CLKREQ as other features).
> 
> Similarly you will find on the imx8mm-evk if you comment out the CLKREQ
> (which isn't required) the imx8mmevk will end up hanging like my boards:
[Richard Zhu] Hi Tim:
Regarding the SPEC, the CLKREQ# is mandatory required, and should be configured as an open drain, active low signal.
And this signal should be driven low by the PCIe M.2 device to request the REF clock be available(active low).
So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.

Anyway, I think the external OSC circuit should be always running if there is no CLKREQ# on your HW board design.

> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index 5ce43daa0c8b..f0023b48f475 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -448,7 +448,9 @@
> 
>         pinctrl_pcie0: pcie0grp {
>                 fsl,pins = <
> +/*
> 
> MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> +*/
>                         MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> 0x41
>                 >;
>         };
> 
> I have PCIe working with a driver that I ported from NXP's kernel which differs
> from your driver in that the PCIe PHY is not abstracted to its own driver so I
> think this has something to do with the order in which the phy is reset or
> initialized? The configuration of gpr14 bits looks correct to me.
[Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW compatibility.
That's might the reason why the PCIe works on your HW board although the CLKREQ# PIN is not defined.
This method is a little rude and violate the SPEC, and not recommended although it levels up the HW compatibility.
So I drop this method in this series.

BR
Richard
> 
> Best regards,
> 
> Tim

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

<snipped...>
> 
> Richard,
> 
> What is this 'invalid resource' about? I see that with my downstream
> IMX8MM PCIe driver as well and have been asked about it.
> 
[Richard Zhu] Hi Tim:
This complain is caused by the following codes in pcie-designware.c driver.
I'm not sure that why there is only size assignment after the res valid check, and do nothing if the res is invalid.
It seems that it is an expected design logic refer to the later codes.
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
                        if (res)
                                pci->atu_size = resource_size(res);
                        pci->atu_base = devm_ioremap_resource(dev, res);
                        if (IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET;
                }

Since the default offset is used on i.MX8MM, the "atu" is not specified in i.MX8MM PCIe DT node, so there is no real res at all.
Then, devm_ioremap_resource() would complain the invalid resource.

> > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> outbound, 4 inbound
> > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > [    1.580055] pci_bus 0000:00: root bus resource [mem
> 0x18000000-0x1fefffff]
> > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff
> pref]
> > [    1.606033] pci 0000:00:00.0: supports D1
> > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> D3cold
> > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff
> 64bit]
> > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff
> 64bit]
> > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with
> 8.0 GT/s PCIe x4 link)
> > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> 0x18000000-0x180fffff]
> > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> 0x18100000-0x181fffff]
> > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> 0x18200000-0x1820ffff pref]
> > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> 0x18100000-0x18103fff 64bit]
> > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> 0x18104000-0x181040ff 64bit]
> > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> 0x18100000-0x181fffff]
> > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > "
> > Regarding the log you pasted, it seems that the clock is not feed to PHY
> properly.
> >
> > Anyway, let's waiting for the v4 series, then make a try. Thanks for your
> great help to make the double tests.
> >
> 
> My boards do not use CLKREQ# so I do not have that defined in pinmux and I
> found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
> works on my board but this isn't a solution just a work-around (I have boards
> that use the only two possible pins for CLKREQ as other features).
> 
> Similarly you will find on the imx8mm-evk if you comment out the CLKREQ
> (which isn't required) the imx8mmevk will end up hanging like my boards:
[Richard Zhu] Hi Tim:
Regarding the SPEC, the CLKREQ# is mandatory required, and should be configured as an open drain, active low signal.
And this signal should be driven low by the PCIe M.2 device to request the REF clock be available(active low).
So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.

Anyway, I think the external OSC circuit should be always running if there is no CLKREQ# on your HW board design.

> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index 5ce43daa0c8b..f0023b48f475 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -448,7 +448,9 @@
> 
>         pinctrl_pcie0: pcie0grp {
>                 fsl,pins = <
> +/*
> 
> MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> +*/
>                         MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> 0x41
>                 >;
>         };
> 
> I have PCIe working with a driver that I ported from NXP's kernel which differs
> from your driver in that the PCIe PHY is not abstracted to its own driver so I
> think this has something to do with the order in which the phy is reset or
> initialized? The configuration of gpr14 bits looks correct to me.
[Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW compatibility.
That's might the reason why the PCIe works on your HW board although the CLKREQ# PIN is not defined.
This method is a little rude and violate the SPEC, and not recommended although it levels up the HW compatibility.
So I drop this method in this series.

BR
Richard
> 
> Best regards,
> 
> Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> <snipped...>
> >
> > Richard,
> >
> > What is this 'invalid resource' about? I see that with my downstream
> > IMX8MM PCIe driver as well and have been asked about it.
> >
> [Richard Zhu] Hi Tim:
> This complain is caused by the following codes in pcie-designware.c driver.
> I'm not sure that why there is only size assignment after the res valid check, and do nothing if the res is invalid.
> It seems that it is an expected design logic refer to the later codes.
>                 if (!pci->atu_base) {
>                         struct resource *res =
>                                 platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
>                         if (res)
>                                 pci->atu_size = resource_size(res);
>                         pci->atu_base = devm_ioremap_resource(dev, res);
>                         if (IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET;
>                 }
>
> Since the default offset is used on i.MX8MM, the "atu" is not specified in i.MX8MM PCIe DT node, so there is no real res at all.
> Then, devm_ioremap_resource() would complain the invalid resource.

I think you are saying a change should be made like this:
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index a945f0c0e73d..3254f60d1713 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev,
IORESOURCE_MEM, "atu");
-                       if (res)
+                       if (res) {
                                pci->atu_size = resource_size(res);
-                       pci->atu_base = devm_ioremap_resource(dev, res);
-                       if (IS_ERR(pci->atu_base))
+                               pci->atu_base = devm_ioremap_resource(dev, res);
+                       }
+                       if (!pci->atu_base || IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base +
DEFAULT_DBI_ATU_OFFSET;
                }

so that it looks like this:
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev,
IORESOURCE_MEM, "atu");
                        if (res) {
                                pci->atu_size = resource_size(res);
                                pci->atu_base = devm_ioremap_resource(dev, res);
                        }
                        if (!pci->atu_base || IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base +
DEFAULT_DBI_ATU_OFFSET;
                }

Right?

>
> > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > outbound, 4 inbound
> > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > 0x18000000-0x1fefffff]
> > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff
> > pref]
> > > [    1.606033] pci 0000:00:00.0: supports D1
> > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > D3cold
> > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff
> > 64bit]
> > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff
> > 64bit]
> > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with
> > 8.0 GT/s PCIe x4 link)
> > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > 0x18000000-0x180fffff]
> > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > 0x18100000-0x181fffff]
> > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > 0x18200000-0x1820ffff pref]
> > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > 0x18100000-0x18103fff 64bit]
> > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > 0x18104000-0x181040ff 64bit]
> > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > 0x18100000-0x181fffff]
> > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > "
> > > Regarding the log you pasted, it seems that the clock is not feed to PHY
> > properly.
> > >
> > > Anyway, let's waiting for the v4 series, then make a try. Thanks for your
> > great help to make the double tests.
> > >
> >
> > My boards do not use CLKREQ# so I do not have that defined in pinmux and I
> > found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
> > works on my board but this isn't a solution just a work-around (I have boards
> > that use the only two possible pins for CLKREQ as other features).
> >
> > Similarly you will find on the imx8mm-evk if you comment out the CLKREQ
> > (which isn't required) the imx8mmevk will end up hanging like my boards:
> [Richard Zhu] Hi Tim:
> Regarding the SPEC, the CLKREQ# is mandatory required, and should be configured as an open drain, active low signal.
> And this signal should be driven low by the PCIe M.2 device to request the REF clock be available(active low).
> So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
>
> Anyway, I think the external OSC circuit should be always running if there is no CLKREQ# on your HW board design.
>

The way I understand it is CLKREQ# allows the host to disable the
REFCLK when not needed for power savings so it would seem optional to
implement that and if not implemented should be left unconnected on
the card.

> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index 5ce43daa0c8b..f0023b48f475 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -448,7 +448,9 @@
> >
> >         pinctrl_pcie0: pcie0grp {
> >                 fsl,pins = <
> > +/*
> >
> > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > +*/
> >                         MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > 0x41
> >                 >;
> >         };
> >
> > I have PCIe working with a driver that I ported from NXP's kernel which differs
> > from your driver in that the PCIe PHY is not abstracted to its own driver so I
> > think this has something to do with the order in which the phy is reset or
> > initialized? The configuration of gpr14 bits looks correct to me.
> [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW compatibility.
> That's might the reason why the PCIe works on your HW board although the CLKREQ# PIN is not defined.
> This method is a little rude and violate the SPEC, and not recommended although it levels up the HW compatibility.
> So I drop this method in this series.
>

Sorry, I don't understand what you are saying here. Is there a change
you are going to make to v4 that will make this work for the evk and
my boards? What is that change exactly?

I responded to your "phy: freescale: pcie: initialize the imx8 pcie
standalone phy driver" submission as I don't understand the GPR14 bit
documentation from the IMX8MMRM.

Best regards,

Tim

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> <snipped...>
> >
> > Richard,
> >
> > What is this 'invalid resource' about? I see that with my downstream
> > IMX8MM PCIe driver as well and have been asked about it.
> >
> [Richard Zhu] Hi Tim:
> This complain is caused by the following codes in pcie-designware.c driver.
> I'm not sure that why there is only size assignment after the res valid check, and do nothing if the res is invalid.
> It seems that it is an expected design logic refer to the later codes.
>                 if (!pci->atu_base) {
>                         struct resource *res =
>                                 platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
>                         if (res)
>                                 pci->atu_size = resource_size(res);
>                         pci->atu_base = devm_ioremap_resource(dev, res);
>                         if (IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET;
>                 }
>
> Since the default offset is used on i.MX8MM, the "atu" is not specified in i.MX8MM PCIe DT node, so there is no real res at all.
> Then, devm_ioremap_resource() would complain the invalid resource.

I think you are saying a change should be made like this:
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index a945f0c0e73d..3254f60d1713 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev,
IORESOURCE_MEM, "atu");
-                       if (res)
+                       if (res) {
                                pci->atu_size = resource_size(res);
-                       pci->atu_base = devm_ioremap_resource(dev, res);
-                       if (IS_ERR(pci->atu_base))
+                               pci->atu_base = devm_ioremap_resource(dev, res);
+                       }
+                       if (!pci->atu_base || IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base +
DEFAULT_DBI_ATU_OFFSET;
                }

so that it looks like this:
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev,
IORESOURCE_MEM, "atu");
                        if (res) {
                                pci->atu_size = resource_size(res);
                                pci->atu_base = devm_ioremap_resource(dev, res);
                        }
                        if (!pci->atu_base || IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base +
DEFAULT_DBI_ATU_OFFSET;
                }

Right?

>
> > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > outbound, 4 inbound
> > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > 0x18000000-0x1fefffff]
> > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff
> > pref]
> > > [    1.606033] pci 0000:00:00.0: supports D1
> > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > D3cold
> > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff
> > 64bit]
> > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff
> > 64bit]
> > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with
> > 8.0 GT/s PCIe x4 link)
> > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > 0x18000000-0x180fffff]
> > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > 0x18100000-0x181fffff]
> > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > 0x18200000-0x1820ffff pref]
> > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > 0x18100000-0x18103fff 64bit]
> > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > 0x18104000-0x181040ff 64bit]
> > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > 0x18100000-0x181fffff]
> > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > "
> > > Regarding the log you pasted, it seems that the clock is not feed to PHY
> > properly.
> > >
> > > Anyway, let's waiting for the v4 series, then make a try. Thanks for your
> > great help to make the double tests.
> > >
> >
> > My boards do not use CLKREQ# so I do not have that defined in pinmux and I
> > found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
> > works on my board but this isn't a solution just a work-around (I have boards
> > that use the only two possible pins for CLKREQ as other features).
> >
> > Similarly you will find on the imx8mm-evk if you comment out the CLKREQ
> > (which isn't required) the imx8mmevk will end up hanging like my boards:
> [Richard Zhu] Hi Tim:
> Regarding the SPEC, the CLKREQ# is mandatory required, and should be configured as an open drain, active low signal.
> And this signal should be driven low by the PCIe M.2 device to request the REF clock be available(active low).
> So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
>
> Anyway, I think the external OSC circuit should be always running if there is no CLKREQ# on your HW board design.
>

The way I understand it is CLKREQ# allows the host to disable the
REFCLK when not needed for power savings so it would seem optional to
implement that and if not implemented should be left unconnected on
the card.

> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index 5ce43daa0c8b..f0023b48f475 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -448,7 +448,9 @@
> >
> >         pinctrl_pcie0: pcie0grp {
> >                 fsl,pins = <
> > +/*
> >
> > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > +*/
> >                         MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > 0x41
> >                 >;
> >         };
> >
> > I have PCIe working with a driver that I ported from NXP's kernel which differs
> > from your driver in that the PCIe PHY is not abstracted to its own driver so I
> > think this has something to do with the order in which the phy is reset or
> > initialized? The configuration of gpr14 bits looks correct to me.
> [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW compatibility.
> That's might the reason why the PCIe works on your HW board although the CLKREQ# PIN is not defined.
> This method is a little rude and violate the SPEC, and not recommended although it levels up the HW compatibility.
> So I drop this method in this series.
>

Sorry, I don't understand what you are saying here. Is there a change
you are going to make to v4 that will make this work for the evk and
my boards? What is that change exactly?

I responded to your "phy: freescale: pcie: initialize the imx8 pcie
standalone phy driver" submission as I don't understand the GPR14 bit
documentation from the IMX8MMRM.

Best regards,

Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> <snipped...>
> >
> > Richard,
> >
> > What is this 'invalid resource' about? I see that with my downstream
> > IMX8MM PCIe driver as well and have been asked about it.
> >
> [Richard Zhu] Hi Tim:
> This complain is caused by the following codes in pcie-designware.c driver.
> I'm not sure that why there is only size assignment after the res valid check, and do nothing if the res is invalid.
> It seems that it is an expected design logic refer to the later codes.
>                 if (!pci->atu_base) {
>                         struct resource *res =
>                                 platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
>                         if (res)
>                                 pci->atu_size = resource_size(res);
>                         pci->atu_base = devm_ioremap_resource(dev, res);
>                         if (IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET;
>                 }
>
> Since the default offset is used on i.MX8MM, the "atu" is not specified in i.MX8MM PCIe DT node, so there is no real res at all.
> Then, devm_ioremap_resource() would complain the invalid resource.

I think you are saying a change should be made like this:
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index a945f0c0e73d..3254f60d1713 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev,
IORESOURCE_MEM, "atu");
-                       if (res)
+                       if (res) {
                                pci->atu_size = resource_size(res);
-                       pci->atu_base = devm_ioremap_resource(dev, res);
-                       if (IS_ERR(pci->atu_base))
+                               pci->atu_base = devm_ioremap_resource(dev, res);
+                       }
+                       if (!pci->atu_base || IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base +
DEFAULT_DBI_ATU_OFFSET;
                }

so that it looks like this:
                if (!pci->atu_base) {
                        struct resource *res =
                                platform_get_resource_byname(pdev,
IORESOURCE_MEM, "atu");
                        if (res) {
                                pci->atu_size = resource_size(res);
                                pci->atu_base = devm_ioremap_resource(dev, res);
                        }
                        if (!pci->atu_base || IS_ERR(pci->atu_base))
                                pci->atu_base = pci->dbi_base +
DEFAULT_DBI_ATU_OFFSET;
                }

Right?

>
> > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > outbound, 4 inbound
> > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
> > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > 0x18000000-0x1fefffff]
> > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff
> > pref]
> > > [    1.606033] pci 0000:00:00.0: supports D1
> > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > D3cold
> > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff
> > 64bit]
> > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff
> > 64bit]
> > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with
> > 8.0 GT/s PCIe x4 link)
> > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > 0x18000000-0x180fffff]
> > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > 0x18100000-0x181fffff]
> > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > 0x18200000-0x1820ffff pref]
> > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > 0x18100000-0x18103fff 64bit]
> > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > 0x18104000-0x181040ff 64bit]
> > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > 0x18100000-0x181fffff]
> > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > "
> > > Regarding the log you pasted, it seems that the clock is not feed to PHY
> > properly.
> > >
> > > Anyway, let's waiting for the v4 series, then make a try. Thanks for your
> > great help to make the double tests.
> > >
> >
> > My boards do not use CLKREQ# so I do not have that defined in pinmux and I
> > found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe
> > works on my board but this isn't a solution just a work-around (I have boards
> > that use the only two possible pins for CLKREQ as other features).
> >
> > Similarly you will find on the imx8mm-evk if you comment out the CLKREQ
> > (which isn't required) the imx8mmevk will end up hanging like my boards:
> [Richard Zhu] Hi Tim:
> Regarding the SPEC, the CLKREQ# is mandatory required, and should be configured as an open drain, active low signal.
> And this signal should be driven low by the PCIe M.2 device to request the REF clock be available(active low).
> So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
>
> Anyway, I think the external OSC circuit should be always running if there is no CLKREQ# on your HW board design.
>

The way I understand it is CLKREQ# allows the host to disable the
REFCLK when not needed for power savings so it would seem optional to
implement that and if not implemented should be left unconnected on
the card.

> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > index 5ce43daa0c8b..f0023b48f475 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > @@ -448,7 +448,9 @@
> >
> >         pinctrl_pcie0: pcie0grp {
> >                 fsl,pins = <
> > +/*
> >
> > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > +*/
> >                         MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > 0x41
> >                 >;
> >         };
> >
> > I have PCIe working with a driver that I ported from NXP's kernel which differs
> > from your driver in that the PCIe PHY is not abstracted to its own driver so I
> > think this has something to do with the order in which the phy is reset or
> > initialized? The configuration of gpr14 bits looks correct to me.
> [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW compatibility.
> That's might the reason why the PCIe works on your HW board although the CLKREQ# PIN is not defined.
> This method is a little rude and violate the SPEC, and not recommended although it levels up the HW compatibility.
> So I drop this method in this series.
>

Sorry, I don't understand what you are saying here. Is there a change
you are going to make to v4 that will make this work for the evk and
my boards? What is that change exactly?

I responded to your "phy: freescale: pcie: initialize the imx8 pcie
standalone phy driver" submission as I don't understand the GPR14 bit
documentation from the IMX8MMRM.

Best regards,

Tim

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Friday, October 22, 2021 12:25 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > <snipped...>
> > >
> > > Richard,
> > >
> > > What is this 'invalid resource' about? I see that with my downstream
> > > IMX8MM PCIe driver as well and have been asked about it.
> > >
> > [Richard Zhu] Hi Tim:
> > This complain is caused by the following codes in pcie-designware.c driver.
> > I'm not sure that why there is only size assignment after the res valid check,
> and do nothing if the res is invalid.
> > It seems that it is an expected design logic refer to the later codes.
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> >                         if (res)
> >                                 pci->atu_size = resource_size(res);
> >                         pci->atu_base =
> devm_ioremap_resource(dev, res);
> >                         if (IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> i.MX8MM PCIe DT node, so there is no real res at all.
> > Then, devm_ioremap_resource() would complain the invalid resource.
> 
> I think you are saying a change should be made like this:
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index a945f0c0e73d..3254f60d1713 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
>                 if (!pci->atu_base) {
>                         struct resource *res =
> 
> platform_get_resource_byname(pdev,
> IORESOURCE_MEM, "atu");
> -                       if (res)
> +                       if (res) {
>                                 pci->atu_size = resource_size(res);
> -                       pci->atu_base = devm_ioremap_resource(dev,
> res);
> -                       if (IS_ERR(pci->atu_base))
> +                               pci->atu_base =
> devm_ioremap_resource(dev, res);
> +                       }
> +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
>                 }
> 
> so that it looks like this:
>                 if (!pci->atu_base) {
>                         struct resource *res =
> 
> platform_get_resource_byname(pdev,
> IORESOURCE_MEM, "atu");
>                         if (res) {
>                                 pci->atu_size = resource_size(res);
>                                 pci->atu_base =
> devm_ioremap_resource(dev, res);
>                         }
>                         if (!pci->atu_base || IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
>                 }
> 
> Right?
[Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.

> 
> >
> > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > outbound, 4 inbound
> > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> 0000:00
> > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > 0x18000000-0x1fefffff]
> > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> 0x00000000-0x000fffff]
> > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> 0x00000000-0x0000ffff
> > > pref]
> > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > D3cold
> > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> 0x00000000-0x00003fff
> > > 64bit]
> > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> 0x00000000-0x000000ff
> > > 64bit]
> > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > Gb/s with
> > > 8.0 GT/s PCIe x4 link)
> > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > 0x18000000-0x180fffff]
> > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > 0x18100000-0x181fffff]
> > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > 0x18200000-0x1820ffff pref]
> > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > 0x18100000-0x18103fff 64bit]
> > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > 0x18104000-0x181040ff 64bit]
> > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > 0x18100000-0x181fffff]
> > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > "
> > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > to PHY
> > > properly.
> > > >
> > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > for your
> > > great help to make the double tests.
> > > >
> > >
> > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> PCIe
> > > works on my board but this isn't a solution just a work-around (I
> > > have boards that use the only two possible pins for CLKREQ as other
> features).
> > >
> > > Similarly you will find on the imx8mm-evk if you comment out the
> > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> boards:
> > [Richard Zhu] Hi Tim:
> > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> configured as an open drain, active low signal.
> > And this signal should be driven low by the PCIe M.2 device to request the
> REF clock be available(active low).
> > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> >
> > Anyway, I think the external OSC circuit should be always running if there is
> no CLKREQ# on your HW board design.
> >
> 
> The way I understand it is CLKREQ# allows the host to disable the REFCLK
> when not needed for power savings so it would seem optional to implement
> that and if not implemented should be left unconnected on the card.
> 
[Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
driven low/high by RC or EP automatically if L1ss modes are enabled.
You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".

> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > index 5ce43daa0c8b..f0023b48f475 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > @@ -448,7 +448,9 @@
> > >
> > >         pinctrl_pcie0: pcie0grp {
> > >                 fsl,pins = <
> > > +/*
> > >
> > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > +*/
> > >
> MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > 0x41
> > >                 >;
> > >         };
> > >
> > > I have PCIe working with a driver that I ported from NXP's kernel
> > > which differs from your driver in that the PCIe PHY is not
> > > abstracted to its own driver so I think this has something to do
> > > with the order in which the phy is reset or initialized? The configuration of
> gpr14 bits looks correct to me.
> > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> compatibility.
> > That's might the reason why the PCIe works on your HW board although the
> CLKREQ# PIN is not defined.
> > This method is a little rude and violate the SPEC, and not recommended
> although it levels up the HW compatibility.
> > So I drop this method in this series.
> >
> 
> Sorry, I don't understand what you are saying here. Is there a change you are
> going to make to v4 that will make this work for the evk and my boards? What
> is that change exactly?
[Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
local BSP kernel. I guess this might be the reason why your board works.

BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).

BR
Richard> 
> I responded to your "phy: freescale: pcie: initialize the imx8 pcie standalone
> phy driver" submission as I don't understand the GPR14 bit documentation
> from the IMX8MMRM.
> 
> Best regards,
> 
> Tim

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Friday, October 22, 2021 12:25 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > <snipped...>
> > >
> > > Richard,
> > >
> > > What is this 'invalid resource' about? I see that with my downstream
> > > IMX8MM PCIe driver as well and have been asked about it.
> > >
> > [Richard Zhu] Hi Tim:
> > This complain is caused by the following codes in pcie-designware.c driver.
> > I'm not sure that why there is only size assignment after the res valid check,
> and do nothing if the res is invalid.
> > It seems that it is an expected design logic refer to the later codes.
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> >                         if (res)
> >                                 pci->atu_size = resource_size(res);
> >                         pci->atu_base =
> devm_ioremap_resource(dev, res);
> >                         if (IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> i.MX8MM PCIe DT node, so there is no real res at all.
> > Then, devm_ioremap_resource() would complain the invalid resource.
> 
> I think you are saying a change should be made like this:
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index a945f0c0e73d..3254f60d1713 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
>                 if (!pci->atu_base) {
>                         struct resource *res =
> 
> platform_get_resource_byname(pdev,
> IORESOURCE_MEM, "atu");
> -                       if (res)
> +                       if (res) {
>                                 pci->atu_size = resource_size(res);
> -                       pci->atu_base = devm_ioremap_resource(dev,
> res);
> -                       if (IS_ERR(pci->atu_base))
> +                               pci->atu_base =
> devm_ioremap_resource(dev, res);
> +                       }
> +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
>                 }
> 
> so that it looks like this:
>                 if (!pci->atu_base) {
>                         struct resource *res =
> 
> platform_get_resource_byname(pdev,
> IORESOURCE_MEM, "atu");
>                         if (res) {
>                                 pci->atu_size = resource_size(res);
>                                 pci->atu_base =
> devm_ioremap_resource(dev, res);
>                         }
>                         if (!pci->atu_base || IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
>                 }
> 
> Right?
[Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.

> 
> >
> > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > outbound, 4 inbound
> > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> 0000:00
> > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > 0x18000000-0x1fefffff]
> > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> 0x00000000-0x000fffff]
> > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> 0x00000000-0x0000ffff
> > > pref]
> > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > D3cold
> > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> 0x00000000-0x00003fff
> > > 64bit]
> > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> 0x00000000-0x000000ff
> > > 64bit]
> > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > Gb/s with
> > > 8.0 GT/s PCIe x4 link)
> > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > 0x18000000-0x180fffff]
> > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > 0x18100000-0x181fffff]
> > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > 0x18200000-0x1820ffff pref]
> > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > 0x18100000-0x18103fff 64bit]
> > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > 0x18104000-0x181040ff 64bit]
> > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > 0x18100000-0x181fffff]
> > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > "
> > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > to PHY
> > > properly.
> > > >
> > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > for your
> > > great help to make the double tests.
> > > >
> > >
> > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> PCIe
> > > works on my board but this isn't a solution just a work-around (I
> > > have boards that use the only two possible pins for CLKREQ as other
> features).
> > >
> > > Similarly you will find on the imx8mm-evk if you comment out the
> > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> boards:
> > [Richard Zhu] Hi Tim:
> > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> configured as an open drain, active low signal.
> > And this signal should be driven low by the PCIe M.2 device to request the
> REF clock be available(active low).
> > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> >
> > Anyway, I think the external OSC circuit should be always running if there is
> no CLKREQ# on your HW board design.
> >
> 
> The way I understand it is CLKREQ# allows the host to disable the REFCLK
> when not needed for power savings so it would seem optional to implement
> that and if not implemented should be left unconnected on the card.
> 
[Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
driven low/high by RC or EP automatically if L1ss modes are enabled.
You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".

> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > index 5ce43daa0c8b..f0023b48f475 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > @@ -448,7 +448,9 @@
> > >
> > >         pinctrl_pcie0: pcie0grp {
> > >                 fsl,pins = <
> > > +/*
> > >
> > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > +*/
> > >
> MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > 0x41
> > >                 >;
> > >         };
> > >
> > > I have PCIe working with a driver that I ported from NXP's kernel
> > > which differs from your driver in that the PCIe PHY is not
> > > abstracted to its own driver so I think this has something to do
> > > with the order in which the phy is reset or initialized? The configuration of
> gpr14 bits looks correct to me.
> > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> compatibility.
> > That's might the reason why the PCIe works on your HW board although the
> CLKREQ# PIN is not defined.
> > This method is a little rude and violate the SPEC, and not recommended
> although it levels up the HW compatibility.
> > So I drop this method in this series.
> >
> 
> Sorry, I don't understand what you are saying here. Is there a change you are
> going to make to v4 that will make this work for the evk and my boards? What
> is that change exactly?
[Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
local BSP kernel. I guess this might be the reason why your board works.

BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).

BR
Richard> 
> I responded to your "phy: freescale: pcie: initialize the imx8 pcie standalone
> phy driver" submission as I don't understand the GPR14 bit documentation
> from the IMX8MMRM.
> 
> Best regards,
> 
> Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Friday, October 22, 2021 12:25 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > <snipped...>
> > >
> > > Richard,
> > >
> > > What is this 'invalid resource' about? I see that with my downstream
> > > IMX8MM PCIe driver as well and have been asked about it.
> > >
> > [Richard Zhu] Hi Tim:
> > This complain is caused by the following codes in pcie-designware.c driver.
> > I'm not sure that why there is only size assignment after the res valid check,
> and do nothing if the res is invalid.
> > It seems that it is an expected design logic refer to the later codes.
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> >                         if (res)
> >                                 pci->atu_size = resource_size(res);
> >                         pci->atu_base =
> devm_ioremap_resource(dev, res);
> >                         if (IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> i.MX8MM PCIe DT node, so there is no real res at all.
> > Then, devm_ioremap_resource() would complain the invalid resource.
> 
> I think you are saying a change should be made like this:
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index a945f0c0e73d..3254f60d1713 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
>                 if (!pci->atu_base) {
>                         struct resource *res =
> 
> platform_get_resource_byname(pdev,
> IORESOURCE_MEM, "atu");
> -                       if (res)
> +                       if (res) {
>                                 pci->atu_size = resource_size(res);
> -                       pci->atu_base = devm_ioremap_resource(dev,
> res);
> -                       if (IS_ERR(pci->atu_base))
> +                               pci->atu_base =
> devm_ioremap_resource(dev, res);
> +                       }
> +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
>                 }
> 
> so that it looks like this:
>                 if (!pci->atu_base) {
>                         struct resource *res =
> 
> platform_get_resource_byname(pdev,
> IORESOURCE_MEM, "atu");
>                         if (res) {
>                                 pci->atu_size = resource_size(res);
>                                 pci->atu_base =
> devm_ioremap_resource(dev, res);
>                         }
>                         if (!pci->atu_base || IS_ERR(pci->atu_base))
>                                 pci->atu_base = pci->dbi_base +
> DEFAULT_DBI_ATU_OFFSET;
>                 }
> 
> Right?
[Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.

> 
> >
> > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > outbound, 4 inbound
> > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> 0000:00
> > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > 0x18000000-0x1fefffff]
> > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> 0x00000000-0x000fffff]
> > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> 0x00000000-0x0000ffff
> > > pref]
> > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > D3cold
> > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> 0x00000000-0x00003fff
> > > 64bit]
> > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> 0x00000000-0x000000ff
> > > 64bit]
> > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > Gb/s with
> > > 8.0 GT/s PCIe x4 link)
> > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > 0x18000000-0x180fffff]
> > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > 0x18100000-0x181fffff]
> > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > 0x18200000-0x1820ffff pref]
> > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > 0x18100000-0x18103fff 64bit]
> > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > 0x18104000-0x181040ff 64bit]
> > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > 0x18100000-0x181fffff]
> > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > "
> > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > to PHY
> > > properly.
> > > >
> > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > for your
> > > great help to make the double tests.
> > > >
> > >
> > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> PCIe
> > > works on my board but this isn't a solution just a work-around (I
> > > have boards that use the only two possible pins for CLKREQ as other
> features).
> > >
> > > Similarly you will find on the imx8mm-evk if you comment out the
> > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> boards:
> > [Richard Zhu] Hi Tim:
> > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> configured as an open drain, active low signal.
> > And this signal should be driven low by the PCIe M.2 device to request the
> REF clock be available(active low).
> > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> >
> > Anyway, I think the external OSC circuit should be always running if there is
> no CLKREQ# on your HW board design.
> >
> 
> The way I understand it is CLKREQ# allows the host to disable the REFCLK
> when not needed for power savings so it would seem optional to implement
> that and if not implemented should be left unconnected on the card.
> 
[Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
driven low/high by RC or EP automatically if L1ss modes are enabled.
You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".

> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > index 5ce43daa0c8b..f0023b48f475 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > @@ -448,7 +448,9 @@
> > >
> > >         pinctrl_pcie0: pcie0grp {
> > >                 fsl,pins = <
> > > +/*
> > >
> > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > +*/
> > >
> MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > 0x41
> > >                 >;
> > >         };
> > >
> > > I have PCIe working with a driver that I ported from NXP's kernel
> > > which differs from your driver in that the PCIe PHY is not
> > > abstracted to its own driver so I think this has something to do
> > > with the order in which the phy is reset or initialized? The configuration of
> gpr14 bits looks correct to me.
> > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> compatibility.
> > That's might the reason why the PCIe works on your HW board although the
> CLKREQ# PIN is not defined.
> > This method is a little rude and violate the SPEC, and not recommended
> although it levels up the HW compatibility.
> > So I drop this method in this series.
> >
> 
> Sorry, I don't understand what you are saying here. Is there a change you are
> going to make to v4 that will make this work for the evk and my boards? What
> is that change exactly?
[Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
local BSP kernel. I guess this might be the reason why your board works.

BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).

BR
Richard> 
> I responded to your "phy: freescale: pcie: initialize the imx8 pcie standalone
> phy driver" submission as I don't understand the GPR14 bit documentation
> from the IMX8MMRM.
> 
> Best regards,
> 
> Tim
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Friday, October 22, 2021 12:25 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > <snipped...>
> > > >
> > > > Richard,
> > > >
> > > > What is this 'invalid resource' about? I see that with my downstream
> > > > IMX8MM PCIe driver as well and have been asked about it.
> > > >
> > > [Richard Zhu] Hi Tim:
> > > This complain is caused by the following codes in pcie-designware.c driver.
> > > I'm not sure that why there is only size assignment after the res valid check,
> > and do nothing if the res is invalid.
> > > It seems that it is an expected design logic refer to the later codes.
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > >                         if (res)
> > >                                 pci->atu_size = resource_size(res);
> > >                         pci->atu_base =
> > devm_ioremap_resource(dev, res);
> > >                         if (IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> > i.MX8MM PCIe DT node, so there is no real res at all.
> > > Then, devm_ioremap_resource() would complain the invalid resource.
> >
> > I think you are saying a change should be made like this:
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index a945f0c0e73d..3254f60d1713 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> > platform_get_resource_byname(pdev,
> > IORESOURCE_MEM, "atu");
> > -                       if (res)
> > +                       if (res) {
> >                                 pci->atu_size = resource_size(res);
> > -                       pci->atu_base = devm_ioremap_resource(dev,
> > res);
> > -                       if (IS_ERR(pci->atu_base))
> > +                               pci->atu_base =
> > devm_ioremap_resource(dev, res);
> > +                       }
> > +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > so that it looks like this:
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> > platform_get_resource_byname(pdev,
> > IORESOURCE_MEM, "atu");
> >                         if (res) {
> >                                 pci->atu_size = resource_size(res);
> >                                 pci->atu_base =
> > devm_ioremap_resource(dev, res);
> >                         }
> >                         if (!pci->atu_base || IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > Right?
> [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.

Ok, I will submit a patch for that.

>
> >
> > >
> > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > > outbound, 4 inbound
> > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > 0000:00
> > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > 0x18000000-0x1fefffff]
> > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > 0x00000000-0x000fffff]
> > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > 0x00000000-0x0000ffff
> > > > pref]
> > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > > D3cold
> > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > 0x00000000-0x00003fff
> > > > 64bit]
> > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > 0x00000000-0x000000ff
> > > > 64bit]
> > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > > Gb/s with
> > > > 8.0 GT/s PCIe x4 link)
> > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > 0x18000000-0x180fffff]
> > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > 0x18100000-0x181fffff]
> > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > 0x18200000-0x1820ffff pref]
> > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > 0x18100000-0x18103fff 64bit]
> > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > 0x18104000-0x181040ff 64bit]
> > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > 0x18100000-0x181fffff]
> > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > > "
> > > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > > to PHY
> > > > properly.
> > > > >
> > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > > for your
> > > > great help to make the double tests.
> > > > >
> > > >
> > > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > PCIe
> > > > works on my board but this isn't a solution just a work-around (I
> > > > have boards that use the only two possible pins for CLKREQ as other
> > features).
> > > >
> > > > Similarly you will find on the imx8mm-evk if you comment out the
> > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> > boards:
> > > [Richard Zhu] Hi Tim:
> > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> > configured as an open drain, active low signal.
> > > And this signal should be driven low by the PCIe M.2 device to request the
> > REF clock be available(active low).
> > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> > >
> > > Anyway, I think the external OSC circuit should be always running if there is
> > no CLKREQ# on your HW board design.
> > >
> >
> > The way I understand it is CLKREQ# allows the host to disable the REFCLK
> > when not needed for power savings so it would seem optional to implement
> > that and if not implemented should be left unconnected on the card.
> >
> [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
> Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
> driven low/high by RC or EP automatically if L1ss modes are enabled.
> You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".
>

CLKREQ is only mandatory if you wish to support clock power
management. Many boards with a PCI host controller do not support
this.

> > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > @@ -448,7 +448,9 @@
> > > >
> > > >         pinctrl_pcie0: pcie0grp {
> > > >                 fsl,pins = <
> > > > +/*
> > > >
> > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > +*/
> > > >
> > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > 0x41
> > > >                 >;
> > > >         };
> > > >
> > > > I have PCIe working with a driver that I ported from NXP's kernel
> > > > which differs from your driver in that the PCIe PHY is not
> > > > abstracted to its own driver so I think this has something to do
> > > > with the order in which the phy is reset or initialized? The configuration of
> > gpr14 bits looks correct to me.
> > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> > compatibility.
> > > That's might the reason why the PCIe works on your HW board although the
> > CLKREQ# PIN is not defined.
> > > This method is a little rude and violate the SPEC, and not recommended
> > although it levels up the HW compatibility.
> > > So I drop this method in this series.
> > >
> >
> > Sorry, I don't understand what you are saying here. Is there a change you are
> > going to make to v4 that will make this work for the evk and my boards? What
> > is that change exactly?
> [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
> local BSP kernel. I guess this might be the reason why your board works.
>
> BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
> Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).
>

Ok, that makes sense. Those bits are not explained well in the
IMX8MMRM. As my board's external REFCLK is always enabled that must
gate the clock internally to the host controller block.

I can confirm that asserting those GPR14 bits does resolve my issue:

#define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
#define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)

       /*
        * for boards that do not connect CLKREQ#,
        * override CLKREQ# and drive it low internally
        */
       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                          IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                          IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);

Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
be set true to implement the above code?

Best regards,

Tim

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Friday, October 22, 2021 12:25 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > <snipped...>
> > > >
> > > > Richard,
> > > >
> > > > What is this 'invalid resource' about? I see that with my downstream
> > > > IMX8MM PCIe driver as well and have been asked about it.
> > > >
> > > [Richard Zhu] Hi Tim:
> > > This complain is caused by the following codes in pcie-designware.c driver.
> > > I'm not sure that why there is only size assignment after the res valid check,
> > and do nothing if the res is invalid.
> > > It seems that it is an expected design logic refer to the later codes.
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > >                         if (res)
> > >                                 pci->atu_size = resource_size(res);
> > >                         pci->atu_base =
> > devm_ioremap_resource(dev, res);
> > >                         if (IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> > i.MX8MM PCIe DT node, so there is no real res at all.
> > > Then, devm_ioremap_resource() would complain the invalid resource.
> >
> > I think you are saying a change should be made like this:
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index a945f0c0e73d..3254f60d1713 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> > platform_get_resource_byname(pdev,
> > IORESOURCE_MEM, "atu");
> > -                       if (res)
> > +                       if (res) {
> >                                 pci->atu_size = resource_size(res);
> > -                       pci->atu_base = devm_ioremap_resource(dev,
> > res);
> > -                       if (IS_ERR(pci->atu_base))
> > +                               pci->atu_base =
> > devm_ioremap_resource(dev, res);
> > +                       }
> > +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > so that it looks like this:
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> > platform_get_resource_byname(pdev,
> > IORESOURCE_MEM, "atu");
> >                         if (res) {
> >                                 pci->atu_size = resource_size(res);
> >                                 pci->atu_base =
> > devm_ioremap_resource(dev, res);
> >                         }
> >                         if (!pci->atu_base || IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > Right?
> [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.

Ok, I will submit a patch for that.

>
> >
> > >
> > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > > outbound, 4 inbound
> > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > 0000:00
> > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > 0x18000000-0x1fefffff]
> > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > 0x00000000-0x000fffff]
> > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > 0x00000000-0x0000ffff
> > > > pref]
> > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > > D3cold
> > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > 0x00000000-0x00003fff
> > > > 64bit]
> > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > 0x00000000-0x000000ff
> > > > 64bit]
> > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > > Gb/s with
> > > > 8.0 GT/s PCIe x4 link)
> > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > 0x18000000-0x180fffff]
> > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > 0x18100000-0x181fffff]
> > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > 0x18200000-0x1820ffff pref]
> > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > 0x18100000-0x18103fff 64bit]
> > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > 0x18104000-0x181040ff 64bit]
> > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > 0x18100000-0x181fffff]
> > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > > "
> > > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > > to PHY
> > > > properly.
> > > > >
> > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > > for your
> > > > great help to make the double tests.
> > > > >
> > > >
> > > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > PCIe
> > > > works on my board but this isn't a solution just a work-around (I
> > > > have boards that use the only two possible pins for CLKREQ as other
> > features).
> > > >
> > > > Similarly you will find on the imx8mm-evk if you comment out the
> > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> > boards:
> > > [Richard Zhu] Hi Tim:
> > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> > configured as an open drain, active low signal.
> > > And this signal should be driven low by the PCIe M.2 device to request the
> > REF clock be available(active low).
> > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> > >
> > > Anyway, I think the external OSC circuit should be always running if there is
> > no CLKREQ# on your HW board design.
> > >
> >
> > The way I understand it is CLKREQ# allows the host to disable the REFCLK
> > when not needed for power savings so it would seem optional to implement
> > that and if not implemented should be left unconnected on the card.
> >
> [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
> Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
> driven low/high by RC or EP automatically if L1ss modes are enabled.
> You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".
>

CLKREQ is only mandatory if you wish to support clock power
management. Many boards with a PCI host controller do not support
this.

> > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > @@ -448,7 +448,9 @@
> > > >
> > > >         pinctrl_pcie0: pcie0grp {
> > > >                 fsl,pins = <
> > > > +/*
> > > >
> > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > +*/
> > > >
> > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > 0x41
> > > >                 >;
> > > >         };
> > > >
> > > > I have PCIe working with a driver that I ported from NXP's kernel
> > > > which differs from your driver in that the PCIe PHY is not
> > > > abstracted to its own driver so I think this has something to do
> > > > with the order in which the phy is reset or initialized? The configuration of
> > gpr14 bits looks correct to me.
> > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> > compatibility.
> > > That's might the reason why the PCIe works on your HW board although the
> > CLKREQ# PIN is not defined.
> > > This method is a little rude and violate the SPEC, and not recommended
> > although it levels up the HW compatibility.
> > > So I drop this method in this series.
> > >
> >
> > Sorry, I don't understand what you are saying here. Is there a change you are
> > going to make to v4 that will make this work for the evk and my boards? What
> > is that change exactly?
> [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
> local BSP kernel. I guess this might be the reason why your board works.
>
> BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
> Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).
>

Ok, that makes sense. Those bits are not explained well in the
IMX8MMRM. As my board's external REFCLK is always enabled that must
gate the clock internally to the host controller block.

I can confirm that asserting those GPR14 bits does resolve my issue:

#define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
#define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)

       /*
        * for boards that do not connect CLKREQ#,
        * override CLKREQ# and drive it low internally
        */
       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                          IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                          IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);

Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
be set true to implement the above code?

Best regards,

Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Friday, October 22, 2021 12:25 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > <snipped...>
> > > >
> > > > Richard,
> > > >
> > > > What is this 'invalid resource' about? I see that with my downstream
> > > > IMX8MM PCIe driver as well and have been asked about it.
> > > >
> > > [Richard Zhu] Hi Tim:
> > > This complain is caused by the following codes in pcie-designware.c driver.
> > > I'm not sure that why there is only size assignment after the res valid check,
> > and do nothing if the res is invalid.
> > > It seems that it is an expected design logic refer to the later codes.
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > >                         if (res)
> > >                                 pci->atu_size = resource_size(res);
> > >                         pci->atu_base =
> > devm_ioremap_resource(dev, res);
> > >                         if (IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> > i.MX8MM PCIe DT node, so there is no real res at all.
> > > Then, devm_ioremap_resource() would complain the invalid resource.
> >
> > I think you are saying a change should be made like this:
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index a945f0c0e73d..3254f60d1713 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> > platform_get_resource_byname(pdev,
> > IORESOURCE_MEM, "atu");
> > -                       if (res)
> > +                       if (res) {
> >                                 pci->atu_size = resource_size(res);
> > -                       pci->atu_base = devm_ioremap_resource(dev,
> > res);
> > -                       if (IS_ERR(pci->atu_base))
> > +                               pci->atu_base =
> > devm_ioremap_resource(dev, res);
> > +                       }
> > +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > so that it looks like this:
> >                 if (!pci->atu_base) {
> >                         struct resource *res =
> >
> > platform_get_resource_byname(pdev,
> > IORESOURCE_MEM, "atu");
> >                         if (res) {
> >                                 pci->atu_size = resource_size(res);
> >                                 pci->atu_base =
> > devm_ioremap_resource(dev, res);
> >                         }
> >                         if (!pci->atu_base || IS_ERR(pci->atu_base))
> >                                 pci->atu_base = pci->dbi_base +
> > DEFAULT_DBI_ATU_OFFSET;
> >                 }
> >
> > Right?
> [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.

Ok, I will submit a patch for that.

>
> >
> > >
> > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > > outbound, 4 inbound
> > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > 0000:00
> > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > 0x18000000-0x1fefffff]
> > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > 0x00000000-0x000fffff]
> > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > 0x00000000-0x0000ffff
> > > > pref]
> > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > > D3cold
> > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > 0x00000000-0x00003fff
> > > > 64bit]
> > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > 0x00000000-0x000000ff
> > > > 64bit]
> > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > > Gb/s with
> > > > 8.0 GT/s PCIe x4 link)
> > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > 0x18000000-0x180fffff]
> > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > 0x18100000-0x181fffff]
> > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > 0x18200000-0x1820ffff pref]
> > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > 0x18100000-0x18103fff 64bit]
> > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > 0x18104000-0x181040ff 64bit]
> > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > 0x18100000-0x181fffff]
> > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > > "
> > > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > > to PHY
> > > > properly.
> > > > >
> > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > > for your
> > > > great help to make the double tests.
> > > > >
> > > >
> > > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > PCIe
> > > > works on my board but this isn't a solution just a work-around (I
> > > > have boards that use the only two possible pins for CLKREQ as other
> > features).
> > > >
> > > > Similarly you will find on the imx8mm-evk if you comment out the
> > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> > boards:
> > > [Richard Zhu] Hi Tim:
> > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> > configured as an open drain, active low signal.
> > > And this signal should be driven low by the PCIe M.2 device to request the
> > REF clock be available(active low).
> > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> > >
> > > Anyway, I think the external OSC circuit should be always running if there is
> > no CLKREQ# on your HW board design.
> > >
> >
> > The way I understand it is CLKREQ# allows the host to disable the REFCLK
> > when not needed for power savings so it would seem optional to implement
> > that and if not implemented should be left unconnected on the card.
> >
> [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
> Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
> driven low/high by RC or EP automatically if L1ss modes are enabled.
> You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".
>

CLKREQ is only mandatory if you wish to support clock power
management. Many boards with a PCI host controller do not support
this.

> > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > @@ -448,7 +448,9 @@
> > > >
> > > >         pinctrl_pcie0: pcie0grp {
> > > >                 fsl,pins = <
> > > > +/*
> > > >
> > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > +*/
> > > >
> > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > 0x41
> > > >                 >;
> > > >         };
> > > >
> > > > I have PCIe working with a driver that I ported from NXP's kernel
> > > > which differs from your driver in that the PCIe PHY is not
> > > > abstracted to its own driver so I think this has something to do
> > > > with the order in which the phy is reset or initialized? The configuration of
> > gpr14 bits looks correct to me.
> > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> > compatibility.
> > > That's might the reason why the PCIe works on your HW board although the
> > CLKREQ# PIN is not defined.
> > > This method is a little rude and violate the SPEC, and not recommended
> > although it levels up the HW compatibility.
> > > So I drop this method in this series.
> > >
> >
> > Sorry, I don't understand what you are saying here. Is there a change you are
> > going to make to v4 that will make this work for the evk and my boards? What
> > is that change exactly?
> [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
> local BSP kernel. I guess this might be the reason why your board works.
>
> BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
> Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).
>

Ok, that makes sense. Those bits are not explained well in the
IMX8MMRM. As my board's external REFCLK is always enabled that must
gate the clock internally to the host controller block.

I can confirm that asserting those GPR14 bits does resolve my issue:

#define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
#define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)

       /*
        * for boards that do not connect CLKREQ#,
        * override CLKREQ# and drive it low internally
        */
       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                          IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
       regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                          IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);

Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
be set true to implement the above code?

Best regards,

Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Friday, October 22, 2021 12:25 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > > dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > > support
> > >
> > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > <snipped...>
> > > > >
> > > > > Richard,
> > > > >
> > > > > What is this 'invalid resource' about? I see that with my downstream
> > > > > IMX8MM PCIe driver as well and have been asked about it.
> > > > >
> > > > [Richard Zhu] Hi Tim:
> > > > This complain is caused by the following codes in pcie-designware.c driver.
> > > > I'm not sure that why there is only size assignment after the res valid check,
> > > and do nothing if the res is invalid.
> > > > It seems that it is an expected design logic refer to the later codes.
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > > >                         if (res)
> > > >                                 pci->atu_size = resource_size(res);
> > > >                         pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > > >                         if (IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> > > i.MX8MM PCIe DT node, so there is no real res at all.
> > > > Then, devm_ioremap_resource() would complain the invalid resource.
> > >
> > > I think you are saying a change should be made like this:
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > index a945f0c0e73d..3254f60d1713 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > > platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM, "atu");
> > > -                       if (res)
> > > +                       if (res) {
> > >                                 pci->atu_size = resource_size(res);
> > > -                       pci->atu_base = devm_ioremap_resource(dev,
> > > res);
> > > -                       if (IS_ERR(pci->atu_base))
> > > +                               pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > > +                       }
> > > +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > so that it looks like this:
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > > platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM, "atu");
> > >                         if (res) {
> > >                                 pci->atu_size = resource_size(res);
> > >                                 pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > >                         }
> > >                         if (!pci->atu_base || IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > Right?
> > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.
>
> Ok, I will submit a patch for that.
>
> >
> > >
> > > >
> > > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > > > outbound, 4 inbound
> > > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > > 0000:00
> > > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > > 0x18000000-0x1fefffff]
> > > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > > 0x00000000-0x000fffff]
> > > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > > 0x00000000-0x0000ffff
> > > > > pref]
> > > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > > > D3cold
> > > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > > 0x00000000-0x00003fff
> > > > > 64bit]
> > > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > > 0x00000000-0x000000ff
> > > > > 64bit]
> > > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > > > Gb/s with
> > > > > 8.0 GT/s PCIe x4 link)
> > > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > > 0x18000000-0x180fffff]
> > > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > > 0x18100000-0x181fffff]
> > > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > > 0x18200000-0x1820ffff pref]
> > > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > > 0x18100000-0x18103fff 64bit]
> > > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > > 0x18104000-0x181040ff 64bit]
> > > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > > 0x18100000-0x181fffff]
> > > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > > > "
> > > > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > > > to PHY
> > > > > properly.
> > > > > >
> > > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > > > for your
> > > > > great help to make the double tests.
> > > > > >
> > > > >
> > > > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > PCIe
> > > > > works on my board but this isn't a solution just a work-around (I
> > > > > have boards that use the only two possible pins for CLKREQ as other
> > > features).
> > > > >
> > > > > Similarly you will find on the imx8mm-evk if you comment out the
> > > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> > > boards:
> > > > [Richard Zhu] Hi Tim:
> > > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> > > configured as an open drain, active low signal.
> > > > And this signal should be driven low by the PCIe M.2 device to request the
> > > REF clock be available(active low).
> > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> > > >
> > > > Anyway, I think the external OSC circuit should be always running if there is
> > > no CLKREQ# on your HW board design.
> > > >
> > >
> > > The way I understand it is CLKREQ# allows the host to disable the REFCLK
> > > when not needed for power savings so it would seem optional to implement
> > > that and if not implemented should be left unconnected on the card.
> > >
> > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
> > Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
> > driven low/high by RC or EP automatically if L1ss modes are enabled.
> > You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> > the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".
> >
>
> CLKREQ is only mandatory if you wish to support clock power
> management. Many boards with a PCI host controller do not support
> this.
>
> > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > @@ -448,7 +448,9 @@
> > > > >
> > > > >         pinctrl_pcie0: pcie0grp {
> > > > >                 fsl,pins = <
> > > > > +/*
> > > > >
> > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > +*/
> > > > >
> > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > 0x41
> > > > >                 >;
> > > > >         };
> > > > >
> > > > > I have PCIe working with a driver that I ported from NXP's kernel
> > > > > which differs from your driver in that the PCIe PHY is not
> > > > > abstracted to its own driver so I think this has something to do
> > > > > with the order in which the phy is reset or initialized? The configuration of
> > > gpr14 bits looks correct to me.
> > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> > > compatibility.
> > > > That's might the reason why the PCIe works on your HW board although the
> > > CLKREQ# PIN is not defined.
> > > > This method is a little rude and violate the SPEC, and not recommended
> > > although it levels up the HW compatibility.
> > > > So I drop this method in this series.
> > > >
> > >
> > > Sorry, I don't understand what you are saying here. Is there a change you are
> > > going to make to v4 that will make this work for the evk and my boards? What
> > > is that change exactly?
> > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
> > local BSP kernel. I guess this might be the reason why your board works.
> >
> > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
> > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).
> >
>
> Ok, that makes sense. Those bits are not explained well in the
> IMX8MMRM. As my board's external REFCLK is always enabled that must
> gate the clock internally to the host controller block.
>
> I can confirm that asserting those GPR14 bits does resolve my issue:
>
> #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
>
>        /*
>         * for boards that do not connect CLKREQ#,
>         * override CLKREQ# and drive it low internally
>         */
>        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                           IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
>        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                           IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
>
> Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
> be set true to implement the above code?
>

Richard,

Sorry - spoke too soon. My test was flawed as I still was pinmuxing
CLKREQ in my dt to work around the issue and after removed the above
did not resolve my issue. The setting of OVERRIDE_EN was wrong above
(should not be set to '1' but BIT(10) instead) but this code already
exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
patch so this is not the issue.

What makes my board work is to clear GPR14 bit9 (like the NXP kernel
does) so I don't think this bit does what we think it does (select
between internal and ext clk). I think setting it enables clock gating
via CLKREQ#.

This also points out that perhaps the CLKREQ_OVERRIDE logic should be
moved to the new phy driver for IMX8MM.

Best regards,

Tim

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Friday, October 22, 2021 12:25 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > > dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > > support
> > >
> > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > <snipped...>
> > > > >
> > > > > Richard,
> > > > >
> > > > > What is this 'invalid resource' about? I see that with my downstream
> > > > > IMX8MM PCIe driver as well and have been asked about it.
> > > > >
> > > > [Richard Zhu] Hi Tim:
> > > > This complain is caused by the following codes in pcie-designware.c driver.
> > > > I'm not sure that why there is only size assignment after the res valid check,
> > > and do nothing if the res is invalid.
> > > > It seems that it is an expected design logic refer to the later codes.
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > > >                         if (res)
> > > >                                 pci->atu_size = resource_size(res);
> > > >                         pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > > >                         if (IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> > > i.MX8MM PCIe DT node, so there is no real res at all.
> > > > Then, devm_ioremap_resource() would complain the invalid resource.
> > >
> > > I think you are saying a change should be made like this:
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > index a945f0c0e73d..3254f60d1713 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > > platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM, "atu");
> > > -                       if (res)
> > > +                       if (res) {
> > >                                 pci->atu_size = resource_size(res);
> > > -                       pci->atu_base = devm_ioremap_resource(dev,
> > > res);
> > > -                       if (IS_ERR(pci->atu_base))
> > > +                               pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > > +                       }
> > > +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > so that it looks like this:
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > > platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM, "atu");
> > >                         if (res) {
> > >                                 pci->atu_size = resource_size(res);
> > >                                 pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > >                         }
> > >                         if (!pci->atu_base || IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > Right?
> > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.
>
> Ok, I will submit a patch for that.
>
> >
> > >
> > > >
> > > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > > > outbound, 4 inbound
> > > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > > 0000:00
> > > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > > 0x18000000-0x1fefffff]
> > > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > > 0x00000000-0x000fffff]
> > > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > > 0x00000000-0x0000ffff
> > > > > pref]
> > > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > > > D3cold
> > > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > > 0x00000000-0x00003fff
> > > > > 64bit]
> > > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > > 0x00000000-0x000000ff
> > > > > 64bit]
> > > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > > > Gb/s with
> > > > > 8.0 GT/s PCIe x4 link)
> > > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > > 0x18000000-0x180fffff]
> > > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > > 0x18100000-0x181fffff]
> > > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > > 0x18200000-0x1820ffff pref]
> > > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > > 0x18100000-0x18103fff 64bit]
> > > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > > 0x18104000-0x181040ff 64bit]
> > > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > > 0x18100000-0x181fffff]
> > > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > > > "
> > > > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > > > to PHY
> > > > > properly.
> > > > > >
> > > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > > > for your
> > > > > great help to make the double tests.
> > > > > >
> > > > >
> > > > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > PCIe
> > > > > works on my board but this isn't a solution just a work-around (I
> > > > > have boards that use the only two possible pins for CLKREQ as other
> > > features).
> > > > >
> > > > > Similarly you will find on the imx8mm-evk if you comment out the
> > > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> > > boards:
> > > > [Richard Zhu] Hi Tim:
> > > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> > > configured as an open drain, active low signal.
> > > > And this signal should be driven low by the PCIe M.2 device to request the
> > > REF clock be available(active low).
> > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> > > >
> > > > Anyway, I think the external OSC circuit should be always running if there is
> > > no CLKREQ# on your HW board design.
> > > >
> > >
> > > The way I understand it is CLKREQ# allows the host to disable the REFCLK
> > > when not needed for power savings so it would seem optional to implement
> > > that and if not implemented should be left unconnected on the card.
> > >
> > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
> > Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
> > driven low/high by RC or EP automatically if L1ss modes are enabled.
> > You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> > the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".
> >
>
> CLKREQ is only mandatory if you wish to support clock power
> management. Many boards with a PCI host controller do not support
> this.
>
> > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > @@ -448,7 +448,9 @@
> > > > >
> > > > >         pinctrl_pcie0: pcie0grp {
> > > > >                 fsl,pins = <
> > > > > +/*
> > > > >
> > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > +*/
> > > > >
> > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > 0x41
> > > > >                 >;
> > > > >         };
> > > > >
> > > > > I have PCIe working with a driver that I ported from NXP's kernel
> > > > > which differs from your driver in that the PCIe PHY is not
> > > > > abstracted to its own driver so I think this has something to do
> > > > > with the order in which the phy is reset or initialized? The configuration of
> > > gpr14 bits looks correct to me.
> > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> > > compatibility.
> > > > That's might the reason why the PCIe works on your HW board although the
> > > CLKREQ# PIN is not defined.
> > > > This method is a little rude and violate the SPEC, and not recommended
> > > although it levels up the HW compatibility.
> > > > So I drop this method in this series.
> > > >
> > >
> > > Sorry, I don't understand what you are saying here. Is there a change you are
> > > going to make to v4 that will make this work for the evk and my boards? What
> > > is that change exactly?
> > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
> > local BSP kernel. I guess this might be the reason why your board works.
> >
> > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
> > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).
> >
>
> Ok, that makes sense. Those bits are not explained well in the
> IMX8MMRM. As my board's external REFCLK is always enabled that must
> gate the clock internally to the host controller block.
>
> I can confirm that asserting those GPR14 bits does resolve my issue:
>
> #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
>
>        /*
>         * for boards that do not connect CLKREQ#,
>         * override CLKREQ# and drive it low internally
>         */
>        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                           IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
>        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                           IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
>
> Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
> be set true to implement the above code?
>

Richard,

Sorry - spoke too soon. My test was flawed as I still was pinmuxing
CLKREQ in my dt to work around the issue and after removed the above
did not resolve my issue. The setting of OVERRIDE_EN was wrong above
(should not be set to '1' but BIT(10) instead) but this code already
exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
patch so this is not the issue.

What makes my board work is to clear GPR14 bit9 (like the NXP kernel
does) so I don't think this bit does what we think it does (select
between internal and ext clk). I think setting it enables clock gating
via CLKREQ#.

This also points out that perhaps the CLKREQ_OVERRIDE logic should be
moved to the new phy driver for IMX8MM.

Best regards,

Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Friday, October 22, 2021 12:25 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > > dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > > support
> > >
> > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > <snipped...>
> > > > >
> > > > > Richard,
> > > > >
> > > > > What is this 'invalid resource' about? I see that with my downstream
> > > > > IMX8MM PCIe driver as well and have been asked about it.
> > > > >
> > > > [Richard Zhu] Hi Tim:
> > > > This complain is caused by the following codes in pcie-designware.c driver.
> > > > I'm not sure that why there is only size assignment after the res valid check,
> > > and do nothing if the res is invalid.
> > > > It seems that it is an expected design logic refer to the later codes.
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > > >                         if (res)
> > > >                                 pci->atu_size = resource_size(res);
> > > >                         pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > > >                         if (IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > Since the default offset is used on i.MX8MM, the "atu" is not specified in
> > > i.MX8MM PCIe DT node, so there is no real res at all.
> > > > Then, devm_ioremap_resource() would complain the invalid resource.
> > >
> > > I think you are saying a change should be made like this:
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > index a945f0c0e73d..3254f60d1713 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci)
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > > platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM, "atu");
> > > -                       if (res)
> > > +                       if (res) {
> > >                                 pci->atu_size = resource_size(res);
> > > -                       pci->atu_base = devm_ioremap_resource(dev,
> > > res);
> > > -                       if (IS_ERR(pci->atu_base))
> > > +                               pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > > +                       }
> > > +                       if (!pci->atu_base || IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > so that it looks like this:
> > >                 if (!pci->atu_base) {
> > >                         struct resource *res =
> > >
> > > platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM, "atu");
> > >                         if (res) {
> > >                                 pci->atu_size = resource_size(res);
> > >                                 pci->atu_base =
> > > devm_ioremap_resource(dev, res);
> > >                         }
> > >                         if (!pci->atu_base || IS_ERR(pci->atu_base))
> > >                                 pci->atu_base = pci->dbi_base +
> > > DEFAULT_DBI_ATU_OFFSET;
> > >                 }
> > >
> > > Right?
> > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory.
>
> Ok, I will submit a patch for that.
>
> >
> > >
> > > >
> > > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4
> > > > > outbound, 4 inbound
> > > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > > 0000:00
> > > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > > [    1.573834] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > > 0x18000000-0x1fefffff]
> > > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > > 0x00000000-0x000fffff]
> > > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > > 0x00000000-0x0000ffff
> > > > > pref]
> > > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > > > > D3cold
> > > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802
> > > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > > 0x00000000-0x00003fff
> > > > > 64bit]
> > > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > > 0x00000000-0x000000ff
> > > > > 64bit]
> > > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504
> > > > > Gb/s with
> > > > > 8.0 GT/s PCIe x4 link)
> > > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > > 0x18000000-0x180fffff]
> > > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > > 0x18100000-0x181fffff]
> > > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > > 0x18200000-0x1820ffff pref]
> > > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > > 0x18100000-0x18103fff 64bit]
> > > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > > 0x18104000-0x181040ff 64bit]
> > > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > > 0x18100000-0x181fffff]
> > > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216
> > > > > > "
> > > > > > Regarding the log you pasted, it seems that the clock is not feed
> > > > > > to PHY
> > > > > properly.
> > > > > >
> > > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks
> > > > > > for your
> > > > > great help to make the double tests.
> > > > > >
> > > > >
> > > > > My boards do not use CLKREQ# so I do not have that defined in pinmux
> > > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > PCIe
> > > > > works on my board but this isn't a solution just a work-around (I
> > > > > have boards that use the only two possible pins for CLKREQ as other
> > > features).
> > > > >
> > > > > Similarly you will find on the imx8mm-evk if you comment out the
> > > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my
> > > boards:
> > > > [Richard Zhu] Hi Tim:
> > > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be
> > > configured as an open drain, active low signal.
> > > > And this signal should be driven low by the PCIe M.2 device to request the
> > > REF clock be available(active low).
> > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board.
> > > >
> > > > Anyway, I think the external OSC circuit should be always running if there is
> > > no CLKREQ# on your HW board design.
> > > >
> > >
> > > The way I understand it is CLKREQ# allows the host to disable the REFCLK
> > > when not needed for power savings so it would seem optional to implement
> > > that and if not implemented should be left unconnected on the card.
> > >
> > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required.
> > Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be
> > driven low/high by RC or EP automatically if L1ss modes are enabled.
> > You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> > the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0".
> >
>
> CLKREQ is only mandatory if you wish to support clock power
> management. Many boards with a PCI host controller do not support
> this.
>
> > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > @@ -448,7 +448,9 @@
> > > > >
> > > > >         pinctrl_pcie0: pcie0grp {
> > > > >                 fsl,pins = <
> > > > > +/*
> > > > >
> > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > +*/
> > > > >
> > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > 0x41
> > > > >                 >;
> > > > >         };
> > > > >
> > > > > I have PCIe working with a driver that I ported from NXP's kernel
> > > > > which differs from your driver in that the PCIe PHY is not
> > > > > abstracted to its own driver so I think this has something to do
> > > > > with the order in which the phy is reset or initialized? The configuration of
> > > gpr14 bits looks correct to me.
> > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW
> > > compatibility.
> > > > That's might the reason why the PCIe works on your HW board although the
> > > CLKREQ# PIN is not defined.
> > > > This method is a little rude and violate the SPEC, and not recommended
> > > although it levels up the HW compatibility.
> > > > So I drop this method in this series.
> > > >
> > >
> > > Sorry, I don't understand what you are saying here. Is there a change you are
> > > going to make to v4 that will make this work for the evk and my boards? What
> > > is that change exactly?
> > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP
> > local BSP kernel. I guess this might be the reason why your board works.
> >
> > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low.
> > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11).
> >
>
> Ok, that makes sense. Those bits are not explained well in the
> IMX8MMRM. As my board's external REFCLK is always enabled that must
> gate the clock internally to the host controller block.
>
> I can confirm that asserting those GPR14 bits does resolve my issue:
>
> #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
>
>        /*
>         * for boards that do not connect CLKREQ#,
>         * override CLKREQ# and drive it low internally
>         */
>        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                           IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
>        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                           IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
>
> Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
> be set true to implement the above code?
>

Richard,

Sorry - spoke too soon. My test was flawed as I still was pinmuxing
CLKREQ in my dt to work around the issue and after removed the above
did not resolve my issue. The setting of OVERRIDE_EN was wrong above
(should not be set to '1' but BIT(10) instead) but this code already
exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
patch so this is not the issue.

What makes my board work is to clear GPR14 bit9 (like the NXP kernel
does) so I don't think this bit does what we think it does (select
between internal and ext clk). I think setting it enables clock gating
via CLKREQ#.

This also points out that perhaps the CLKREQ_OVERRIDE logic should be
moved to the new phy driver for IMX8MM.

Best regards,

Tim

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Saturday, October 23, 2021 12:55 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <tharvey@gateworks.com>
> wrote:
> >
> > On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Friday, October 22, 2021 12:25 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> > > > imx8mm pcie support
> > > >
> > > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > <snipped...>
> > > > > >
> > > > > > Richard,
> > > > > >
> > > > > > What is this 'invalid resource' about? I see that with my
> > > > > > downstream IMX8MM PCIe driver as well and have been asked
> about it.
> > > > > >
> > > > > [Richard Zhu] Hi Tim:
> > > > > This complain is caused by the following codes in pcie-designware.c
> driver.
> > > > > I'm not sure that why there is only size assignment after the
> > > > > res valid check,
> > > > and do nothing if the res is invalid.
> > > > > It seems that it is an expected design logic refer to the later codes.
> > > > >                 if (!pci->atu_base) {
> > > > >                         struct resource *res =
> > > > >
> > > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > > > >                         if (res)
> > > > >                                 pci->atu_size =
> resource_size(res);
> > > > >                         pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > > >                         if (IS_ERR(pci->atu_base))
> > > > >                                 pci->atu_base =
> pci->dbi_base +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > > >                 }
> > > > >
> > > > > Since the default offset is used on i.MX8MM, the "atu" is not
> > > > > specified in
> > > > i.MX8MM PCIe DT node, so there is no real res at all.
> > > > > Then, devm_ioremap_resource() would complain the invalid resource.
> > > >
> > > > I think you are saying a change should be made like this:
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > > index a945f0c0e73d..3254f60d1713 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie
> *pci)
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > > platform_get_resource_byname(pdev,
> > > > IORESOURCE_MEM, "atu");
> > > > -                       if (res)
> > > > +                       if (res) {
> > > >                                 pci->atu_size =
> resource_size(res);
> > > > -                       pci->atu_base =
> devm_ioremap_resource(dev,
> > > > res);
> > > > -                       if (IS_ERR(pci->atu_base))
> > > > +                               pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > > +                       }
> > > > +                       if (!pci->atu_base ||
> > > > + IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base
> +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > so that it looks like this:
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > > platform_get_resource_byname(pdev,
> > > > IORESOURCE_MEM, "atu");
> > > >                         if (res) {
> > > >                                 pci->atu_size =
> resource_size(res);
> > > >                                 pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > >                         }
> > > >                         if (!pci->atu_base ||
> IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base
> +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > Right?
> > > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid
> resource memory.
> >
> > Ok, I will submit a patch for that.
> >
[Richard Zhu] Thanks for your help. Please cc me, if you issue that patch.

> > >
> > > >
> > > > >
> > > > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions:
> 4
> > > > > > outbound, 4 inbound
> > > > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > > > 0000:00
> > > > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > > > [    1.573834] pci_bus 0000:00: root bus resource [io
> 0x0000-0xffff]
> > > > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > > > 0x18000000-0x1fefffff]
> > > > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class
> 0x060400
> > > > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > > > 0x00000000-0x000fffff]
> > > > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > > > 0x00000000-0x0000ffff
> > > > > > pref]
> > > > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1
> D3hot
> > > > > > D3cold
> > > > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class
> 0x010802
> > > > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > > > 0x00000000-0x00003fff
> > > > > > 64bit]
> > > > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > > > 0x00000000-0x000000ff
> > > > > > 64bit]
> > > > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe
> bandwidth,
> > > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of
> > > > > > 31.504 Gb/s with
> > > > > > 8.0 GT/s PCIe x4 link)
> > > > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > > > 0x18000000-0x180fffff]
> > > > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > > > 0x18100000-0x181fffff]
> > > > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > > > 0x18200000-0x1820ffff pref]
> > > > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > > > 0x18100000-0x18103fff 64bit]
> > > > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > > > 0x18104000-0x181040ff 64bit]
> > > > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > > > 0x18100000-0x181fffff]
> > > > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ
> 216
> > > > > > > "
> > > > > > > Regarding the log you pasted, it seems that the clock is not
> > > > > > > feed to PHY
> > > > > > properly.
> > > > > > >
> > > > > > > Anyway, let's waiting for the v4 series, then make a try.
> > > > > > > Thanks for your
> > > > > > great help to make the double tests.
> > > > > > >
> > > > > >
> > > > > > My boards do not use CLKREQ# so I do not have that defined in
> > > > > > pinmux and I found that if I add
> > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > PCIe
> > > > > > works on my board but this isn't a solution just a work-around
> > > > > > (I have boards that use the only two possible pins for CLKREQ
> > > > > > as other
> > > > features).
> > > > > >
> > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > hanging like my
> > > > boards:
> > > > > [Richard Zhu] Hi Tim:
> > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > should be
> > > > configured as an open drain, active low signal.
> > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > request the
> > > > REF clock be available(active low).
> > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK
> board.
> > > > >
> > > > > Anyway, I think the external OSC circuit should be always
> > > > > running if there is
> > > > no CLKREQ# on your HW board design.
> > > > >
> > > >
> > > > The way I understand it is CLKREQ# allows the host to disable the
> > > > REFCLK when not needed for power savings so it would seem optional
> > > > to implement that and if not implemented should be left unconnected on
> the card.
> > > >
> > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> mandatory required.
> > > Especially for the L1ss usages. This signal would be OD(open drain),
> > > bi-directional, and might be driven low/high by RC or EP automatically if
> L1ss modes are enabled.
> > > You can make reference to the
> > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0
> Version 1.0".
> > >
> >
> > CLKREQ is only mandatory if you wish to support clock power
> > management. Many boards with a PCI host controller do not support
> > this.
[Richard Zhu] Okay, understood.

> >
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > @@ -448,7 +448,9 @@
> > > > > >
> > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > >                 fsl,pins = <
> > > > > > +/*
> > > > > >
> > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > +*/
> > > > > >
> > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > 0x41
> > > > > >                 >;
> > > > > >         };
> > > > > >
> > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > kernel which differs from your driver in that the PCIe PHY is
> > > > > > not abstracted to its own driver so I think this has something
> > > > > > to do with the order in which the phy is reset or initialized?
> > > > > > The configuration of
> > > > gpr14 bits looks correct to me.
> > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level
> > > > > up the HW
> > > > compatibility.
> > > > > That's might the reason why the PCIe works on your HW board
> > > > > although the
> > > > CLKREQ# PIN is not defined.
> > > > > This method is a little rude and violate the SPEC, and not
> > > > > recommended
> > > > although it levels up the HW compatibility.
> > > > > So I drop this method in this series.
> > > > >
> > > >
> > > > Sorry, I don't understand what you are saying here. Is there a
> > > > change you are going to make to v4 that will make this work for
> > > > the evk and my boards? What is that change exactly?
> > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to
> > > be low in NXP local BSP kernel. I guess this might be the reason why your
> board works.
> > >
> > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to
> be low.
> > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> CLKREQ_OVERRIDE(bit11).
> > >
> >
> > Ok, that makes sense. Those bits are not explained well in the
> > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > gate the clock internally to the host controller block.
> >
> > I can confirm that asserting those GPR14 bits does resolve my issue:
> >
> > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> >
> >        /*
> >         * for boards that do not connect CLKREQ#,
> >         * override CLKREQ# and drive it low internally
> >         */
> >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >
> IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >
> IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
[Richard Zhu] regmap bits operations should manipulate according bits.
The BIT(10) and BIT(11) should be touched actually.

> >
> > Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
> > be set true to implement the above code?
> >
> 
> Richard,
> 
> Sorry - spoke too soon. My test was flawed as I still was pinmuxing CLKREQ in
> my dt to work around the issue and after removed the above did not resolve
> my issue. The setting of OVERRIDE_EN was wrong above (should not be set to
> '1' but BIT(10) instead) but this code already exists in
> imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch so this is
> not the issue.
> 
> What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> does) so I don't think this bit does what we think it does (select between
> internal and ext clk). I think setting it enables clock gating via CLKREQ#.
> 
> This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> moved to the new phy driver for IMX8MM.
[Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be low.
I will think about that and add this in later v5 patch-set if nobody has different concerns.
Thanks.

BR
Richard
 
> 
> Best regards,
> 
> Tim

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Saturday, October 23, 2021 12:55 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <tharvey@gateworks.com>
> wrote:
> >
> > On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Friday, October 22, 2021 12:25 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> > > > imx8mm pcie support
> > > >
> > > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > <snipped...>
> > > > > >
> > > > > > Richard,
> > > > > >
> > > > > > What is this 'invalid resource' about? I see that with my
> > > > > > downstream IMX8MM PCIe driver as well and have been asked
> about it.
> > > > > >
> > > > > [Richard Zhu] Hi Tim:
> > > > > This complain is caused by the following codes in pcie-designware.c
> driver.
> > > > > I'm not sure that why there is only size assignment after the
> > > > > res valid check,
> > > > and do nothing if the res is invalid.
> > > > > It seems that it is an expected design logic refer to the later codes.
> > > > >                 if (!pci->atu_base) {
> > > > >                         struct resource *res =
> > > > >
> > > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > > > >                         if (res)
> > > > >                                 pci->atu_size =
> resource_size(res);
> > > > >                         pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > > >                         if (IS_ERR(pci->atu_base))
> > > > >                                 pci->atu_base =
> pci->dbi_base +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > > >                 }
> > > > >
> > > > > Since the default offset is used on i.MX8MM, the "atu" is not
> > > > > specified in
> > > > i.MX8MM PCIe DT node, so there is no real res at all.
> > > > > Then, devm_ioremap_resource() would complain the invalid resource.
> > > >
> > > > I think you are saying a change should be made like this:
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > > index a945f0c0e73d..3254f60d1713 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie
> *pci)
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > > platform_get_resource_byname(pdev,
> > > > IORESOURCE_MEM, "atu");
> > > > -                       if (res)
> > > > +                       if (res) {
> > > >                                 pci->atu_size =
> resource_size(res);
> > > > -                       pci->atu_base =
> devm_ioremap_resource(dev,
> > > > res);
> > > > -                       if (IS_ERR(pci->atu_base))
> > > > +                               pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > > +                       }
> > > > +                       if (!pci->atu_base ||
> > > > + IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base
> +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > so that it looks like this:
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > > platform_get_resource_byname(pdev,
> > > > IORESOURCE_MEM, "atu");
> > > >                         if (res) {
> > > >                                 pci->atu_size =
> resource_size(res);
> > > >                                 pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > >                         }
> > > >                         if (!pci->atu_base ||
> IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base
> +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > Right?
> > > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid
> resource memory.
> >
> > Ok, I will submit a patch for that.
> >
[Richard Zhu] Thanks for your help. Please cc me, if you issue that patch.

> > >
> > > >
> > > > >
> > > > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions:
> 4
> > > > > > outbound, 4 inbound
> > > > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > > > 0000:00
> > > > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > > > [    1.573834] pci_bus 0000:00: root bus resource [io
> 0x0000-0xffff]
> > > > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > > > 0x18000000-0x1fefffff]
> > > > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class
> 0x060400
> > > > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > > > 0x00000000-0x000fffff]
> > > > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > > > 0x00000000-0x0000ffff
> > > > > > pref]
> > > > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1
> D3hot
> > > > > > D3cold
> > > > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class
> 0x010802
> > > > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > > > 0x00000000-0x00003fff
> > > > > > 64bit]
> > > > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > > > 0x00000000-0x000000ff
> > > > > > 64bit]
> > > > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe
> bandwidth,
> > > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of
> > > > > > 31.504 Gb/s with
> > > > > > 8.0 GT/s PCIe x4 link)
> > > > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > > > 0x18000000-0x180fffff]
> > > > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > > > 0x18100000-0x181fffff]
> > > > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > > > 0x18200000-0x1820ffff pref]
> > > > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > > > 0x18100000-0x18103fff 64bit]
> > > > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > > > 0x18104000-0x181040ff 64bit]
> > > > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > > > 0x18100000-0x181fffff]
> > > > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ
> 216
> > > > > > > "
> > > > > > > Regarding the log you pasted, it seems that the clock is not
> > > > > > > feed to PHY
> > > > > > properly.
> > > > > > >
> > > > > > > Anyway, let's waiting for the v4 series, then make a try.
> > > > > > > Thanks for your
> > > > > > great help to make the double tests.
> > > > > > >
> > > > > >
> > > > > > My boards do not use CLKREQ# so I do not have that defined in
> > > > > > pinmux and I found that if I add
> > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > PCIe
> > > > > > works on my board but this isn't a solution just a work-around
> > > > > > (I have boards that use the only two possible pins for CLKREQ
> > > > > > as other
> > > > features).
> > > > > >
> > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > hanging like my
> > > > boards:
> > > > > [Richard Zhu] Hi Tim:
> > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > should be
> > > > configured as an open drain, active low signal.
> > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > request the
> > > > REF clock be available(active low).
> > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK
> board.
> > > > >
> > > > > Anyway, I think the external OSC circuit should be always
> > > > > running if there is
> > > > no CLKREQ# on your HW board design.
> > > > >
> > > >
> > > > The way I understand it is CLKREQ# allows the host to disable the
> > > > REFCLK when not needed for power savings so it would seem optional
> > > > to implement that and if not implemented should be left unconnected on
> the card.
> > > >
> > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> mandatory required.
> > > Especially for the L1ss usages. This signal would be OD(open drain),
> > > bi-directional, and might be driven low/high by RC or EP automatically if
> L1ss modes are enabled.
> > > You can make reference to the
> > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0
> Version 1.0".
> > >
> >
> > CLKREQ is only mandatory if you wish to support clock power
> > management. Many boards with a PCI host controller do not support
> > this.
[Richard Zhu] Okay, understood.

> >
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > @@ -448,7 +448,9 @@
> > > > > >
> > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > >                 fsl,pins = <
> > > > > > +/*
> > > > > >
> > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > +*/
> > > > > >
> > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > 0x41
> > > > > >                 >;
> > > > > >         };
> > > > > >
> > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > kernel which differs from your driver in that the PCIe PHY is
> > > > > > not abstracted to its own driver so I think this has something
> > > > > > to do with the order in which the phy is reset or initialized?
> > > > > > The configuration of
> > > > gpr14 bits looks correct to me.
> > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level
> > > > > up the HW
> > > > compatibility.
> > > > > That's might the reason why the PCIe works on your HW board
> > > > > although the
> > > > CLKREQ# PIN is not defined.
> > > > > This method is a little rude and violate the SPEC, and not
> > > > > recommended
> > > > although it levels up the HW compatibility.
> > > > > So I drop this method in this series.
> > > > >
> > > >
> > > > Sorry, I don't understand what you are saying here. Is there a
> > > > change you are going to make to v4 that will make this work for
> > > > the evk and my boards? What is that change exactly?
> > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to
> > > be low in NXP local BSP kernel. I guess this might be the reason why your
> board works.
> > >
> > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to
> be low.
> > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> CLKREQ_OVERRIDE(bit11).
> > >
> >
> > Ok, that makes sense. Those bits are not explained well in the
> > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > gate the clock internally to the host controller block.
> >
> > I can confirm that asserting those GPR14 bits does resolve my issue:
> >
> > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> >
> >        /*
> >         * for boards that do not connect CLKREQ#,
> >         * override CLKREQ# and drive it low internally
> >         */
> >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >
> IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >
> IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
[Richard Zhu] regmap bits operations should manipulate according bits.
The BIT(10) and BIT(11) should be touched actually.

> >
> > Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
> > be set true to implement the above code?
> >
> 
> Richard,
> 
> Sorry - spoke too soon. My test was flawed as I still was pinmuxing CLKREQ in
> my dt to work around the issue and after removed the above did not resolve
> my issue. The setting of OVERRIDE_EN was wrong above (should not be set to
> '1' but BIT(10) instead) but this code already exists in
> imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch so this is
> not the issue.
> 
> What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> does) so I don't think this bit does what we think it does (select between
> internal and ext clk). I think setting it enables clock gating via CLKREQ#.
> 
> This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> moved to the new phy driver for IMX8MM.
[Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be low.
I will think about that and add this in later v5 patch-set if nobody has different concerns.
Thanks.

BR
Richard
 
> 
> Best regards,
> 
> Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Saturday, October 23, 2021 12:55 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <tharvey@gateworks.com>
> wrote:
> >
> > On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Friday, October 22, 2021 12:25 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> > > > imx8mm pcie support
> > > >
> > > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > <snipped...>
> > > > > >
> > > > > > Richard,
> > > > > >
> > > > > > What is this 'invalid resource' about? I see that with my
> > > > > > downstream IMX8MM PCIe driver as well and have been asked
> about it.
> > > > > >
> > > > > [Richard Zhu] Hi Tim:
> > > > > This complain is caused by the following codes in pcie-designware.c
> driver.
> > > > > I'm not sure that why there is only size assignment after the
> > > > > res valid check,
> > > > and do nothing if the res is invalid.
> > > > > It seems that it is an expected design logic refer to the later codes.
> > > > >                 if (!pci->atu_base) {
> > > > >                         struct resource *res =
> > > > >
> > > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> > > > >                         if (res)
> > > > >                                 pci->atu_size =
> resource_size(res);
> > > > >                         pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > > >                         if (IS_ERR(pci->atu_base))
> > > > >                                 pci->atu_base =
> pci->dbi_base +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > > >                 }
> > > > >
> > > > > Since the default offset is used on i.MX8MM, the "atu" is not
> > > > > specified in
> > > > i.MX8MM PCIe DT node, so there is no real res at all.
> > > > > Then, devm_ioremap_resource() would complain the invalid resource.
> > > >
> > > > I think you are saying a change should be made like this:
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > > index a945f0c0e73d..3254f60d1713 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie
> *pci)
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > > platform_get_resource_byname(pdev,
> > > > IORESOURCE_MEM, "atu");
> > > > -                       if (res)
> > > > +                       if (res) {
> > > >                                 pci->atu_size =
> resource_size(res);
> > > > -                       pci->atu_base =
> devm_ioremap_resource(dev,
> > > > res);
> > > > -                       if (IS_ERR(pci->atu_base))
> > > > +                               pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > > +                       }
> > > > +                       if (!pci->atu_base ||
> > > > + IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base
> +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > so that it looks like this:
> > > >                 if (!pci->atu_base) {
> > > >                         struct resource *res =
> > > >
> > > > platform_get_resource_byname(pdev,
> > > > IORESOURCE_MEM, "atu");
> > > >                         if (res) {
> > > >                                 pci->atu_size =
> resource_size(res);
> > > >                                 pci->atu_base =
> > > > devm_ioremap_resource(dev, res);
> > > >                         }
> > > >                         if (!pci->atu_base ||
> IS_ERR(pci->atu_base))
> > > >                                 pci->atu_base = pci->dbi_base
> +
> > > > DEFAULT_DBI_ATU_OFFSET;
> > > >                 }
> > > >
> > > > Right?
> > > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid
> resource memory.
> >
> > Ok, I will submit a patch for that.
> >
[Richard Zhu] Thanks for your help. Please cc me, if you issue that patch.

> > >
> > > >
> > > > >
> > > > > > > [    1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled
> > > > > > > [    1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions:
> 4
> > > > > > outbound, 4 inbound
> > > > > > > [    1.429803] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.534497] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2
> > > > > > > [    1.550364] imx6q-pcie 33800000.pcie: Link up
> > > > > > > [    1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus
> > > > 0000:00
> > > > > > > [    1.565545] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > > > > [    1.573834] pci_bus 0000:00: root bus resource [io
> 0x0000-0xffff]
> > > > > > > [    1.580055] pci_bus 0000:00: root bus resource [mem
> > > > > > 0x18000000-0x1fefffff]
> > > > > > > [    1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class
> 0x060400
> > > > > > > [    1.592997] pci 0000:00:00.0: reg 0x10: [mem
> > > > 0x00000000-0x000fffff]
> > > > > > > [    1.599282] pci 0000:00:00.0: reg 0x38: [mem
> > > > 0x00000000-0x0000ffff
> > > > > > pref]
> > > > > > > [    1.606033] pci 0000:00:00.0: supports D1
> > > > > > > [    1.610053] pci 0000:00:00.0: PME# supported from D0 D1
> D3hot
> > > > > > D3cold
> > > > > > > [    1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class
> 0x010802
> > > > > > > [    1.624293] pci 0000:01:00.0: reg 0x10: [mem
> > > > 0x00000000-0x00003fff
> > > > > > 64bit]
> > > > > > > [    1.631177] pci 0000:01:00.0: reg 0x20: [mem
> > > > 0x00000000-0x000000ff
> > > > > > 64bit]
> > > > > > > [    1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe
> bandwidth,
> > > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of
> > > > > > 31.504 Gb/s with
> > > > > > 8.0 GT/s PCIe x4 link)
> > > > > > > [    1.664931] pci 0000:00:00.0: BAR 0: assigned [mem
> > > > > > 0x18000000-0x180fffff]
> > > > > > > [    1.671745] pci 0000:00:00.0: BAR 14: assigned [mem
> > > > > > 0x18100000-0x181fffff]
> > > > > > > [    1.678634] pci 0000:00:00.0: BAR 6: assigned [mem
> > > > > > 0x18200000-0x1820ffff pref]
> > > > > > > [    1.685873] pci 0000:01:00.0: BAR 0: assigned [mem
> > > > > > 0x18100000-0x18103fff 64bit]
> > > > > > > [    1.693222] pci 0000:01:00.0: BAR 4: assigned [mem
> > > > > > 0x18104000-0x181040ff 64bit]
> > > > > > > [    1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > > > > > > [    1.705814] pci 0000:00:00.0:   bridge window [mem
> > > > > > 0x18100000-0x181fffff]
> > > > > > > [    1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ
> 216
> > > > > > > "
> > > > > > > Regarding the log you pasted, it seems that the clock is not
> > > > > > > feed to PHY
> > > > > > properly.
> > > > > > >
> > > > > > > Anyway, let's waiting for the v4 series, then make a try.
> > > > > > > Thanks for your
> > > > > > great help to make the double tests.
> > > > > > >
> > > > > >
> > > > > > My boards do not use CLKREQ# so I do not have that defined in
> > > > > > pinmux and I found that if I add
> > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > PCIe
> > > > > > works on my board but this isn't a solution just a work-around
> > > > > > (I have boards that use the only two possible pins for CLKREQ
> > > > > > as other
> > > > features).
> > > > > >
> > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > hanging like my
> > > > boards:
> > > > > [Richard Zhu] Hi Tim:
> > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > should be
> > > > configured as an open drain, active low signal.
> > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > request the
> > > > REF clock be available(active low).
> > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK
> board.
> > > > >
> > > > > Anyway, I think the external OSC circuit should be always
> > > > > running if there is
> > > > no CLKREQ# on your HW board design.
> > > > >
> > > >
> > > > The way I understand it is CLKREQ# allows the host to disable the
> > > > REFCLK when not needed for power savings so it would seem optional
> > > > to implement that and if not implemented should be left unconnected on
> the card.
> > > >
> > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> mandatory required.
> > > Especially for the L1ss usages. This signal would be OD(open drain),
> > > bi-directional, and might be driven low/high by RC or EP automatically if
> L1ss modes are enabled.
> > > You can make reference to the
> > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0
> Version 1.0".
> > >
> >
> > CLKREQ is only mandatory if you wish to support clock power
> > management. Many boards with a PCI host controller do not support
> > this.
[Richard Zhu] Okay, understood.

> >
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > @@ -448,7 +448,9 @@
> > > > > >
> > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > >                 fsl,pins = <
> > > > > > +/*
> > > > > >
> > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > +*/
> > > > > >
> > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > 0x41
> > > > > >                 >;
> > > > > >         };
> > > > > >
> > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > kernel which differs from your driver in that the PCIe PHY is
> > > > > > not abstracted to its own driver so I think this has something
> > > > > > to do with the order in which the phy is reset or initialized?
> > > > > > The configuration of
> > > > gpr14 bits looks correct to me.
> > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level
> > > > > up the HW
> > > > compatibility.
> > > > > That's might the reason why the PCIe works on your HW board
> > > > > although the
> > > > CLKREQ# PIN is not defined.
> > > > > This method is a little rude and violate the SPEC, and not
> > > > > recommended
> > > > although it levels up the HW compatibility.
> > > > > So I drop this method in this series.
> > > > >
> > > >
> > > > Sorry, I don't understand what you are saying here. Is there a
> > > > change you are going to make to v4 that will make this work for
> > > > the evk and my boards? What is that change exactly?
> > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to
> > > be low in NXP local BSP kernel. I guess this might be the reason why your
> board works.
> > >
> > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to
> be low.
> > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> CLKREQ_OVERRIDE(bit11).
> > >
> >
> > Ok, that makes sense. Those bits are not explained well in the
> > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > gate the clock internally to the host controller block.
> >
> > I can confirm that asserting those GPR14 bits does resolve my issue:
> >
> > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> >
> >        /*
> >         * for boards that do not connect CLKREQ#,
> >         * override CLKREQ# and drive it low internally
> >         */
> >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >
> IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >
> IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
[Richard Zhu] regmap bits operations should manipulate according bits.
The BIT(10) and BIT(11) should be touched actually.

> >
> > Should this be added as a 'fsl,clkreq-unsupported' flag that needs to
> > be set true to implement the above code?
> >
> 
> Richard,
> 
> Sorry - spoke too soon. My test was flawed as I still was pinmuxing CLKREQ in
> my dt to work around the issue and after removed the above did not resolve
> my issue. The setting of OVERRIDE_EN was wrong above (should not be set to
> '1' but BIT(10) instead) but this code already exists in
> imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch so this is
> not the issue.
> 
> What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> does) so I don't think this bit does what we think it does (select between
> internal and ext clk). I think setting it enables clock gating via CLKREQ#.
> 
> This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> moved to the new phy driver for IMX8MM.
[Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be low.
I will think about that and add this in later v5 patch-set if nobody has different concerns.
Thanks.

BR
Richard
 
> 
> Best regards,
> 
> Tim
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

Snipped...

> > > > > > > My boards do not use CLKREQ# so I do not have that defined
> > > > > > > in pinmux and I found that if I add
> > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > PCIe
> > > > > > > works on my board but this isn't a solution just a
> > > > > > > work-around (I have boards that use the only two possible
> > > > > > > pins for CLKREQ as other
> > > > > features).
> > > > > > >
> > > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > > hanging like my
> > > > > boards:
> > > > > > [Richard Zhu] Hi Tim:
> > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > should be
> > > > > configured as an open drain, active low signal.
> > > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > > request the
> > > > > REF clock be available(active low).
> > > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM
> > > > > > EVK
> > board.
> > > > > >
> > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > running if there is
> > > > > no CLKREQ# on your HW board design.
> > > > > >
> > > > >
> > > > > The way I understand it is CLKREQ# allows the host to disable
> > > > > the REFCLK when not needed for power savings so it would seem
> > > > > optional to implement that and if not implemented should be left
> > > > > unconnected on
> > the card.
> > > > >
> > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> > mandatory required.
> > > > Especially for the L1ss usages. This signal would be OD(open
> > > > drain), bi-directional, and might be driven low/high by RC or EP
> > > > automatically if
> > L1ss modes are enabled.
> > > > You can make reference to the
> > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > 4.0 Version 1.0".
> > > >
> > >
> > > CLKREQ is only mandatory if you wish to support clock power
> > > management. Many boards with a PCI host controller do not support
> > > this.
> [Richard Zhu] Okay, understood.
> 
> > >
> > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > @@ -448,7 +448,9 @@
> > > > > > >
> > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > >                 fsl,pins = <
> > > > > > > +/*
> > > > > > >
> > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > +*/
> > > > > > >
> > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > 0x41
> > > > > > >                 >;
> > > > > > >         };
> > > > > > >
> > > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > > kernel which differs from your driver in that the PCIe PHY
> > > > > > > is not abstracted to its own driver so I think this has
> > > > > > > something to do with the order in which the phy is reset or
> initialized?
> > > > > > > The configuration of
> > > > > gpr14 bits looks correct to me.
> > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > level up the HW
> > > > > compatibility.
> > > > > > That's might the reason why the PCIe works on your HW board
> > > > > > although the
> > > > > CLKREQ# PIN is not defined.
> > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > recommended
> > > > > although it levels up the HW compatibility.
> > > > > > So I drop this method in this series.
> > > > > >
> > > > >
> > > > > Sorry, I don't understand what you are saying here. Is there a
> > > > > change you are going to make to v4 that will make this work for
> > > > > the evk and my boards? What is that change exactly?
> > > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced
> > > > to be low in NXP local BSP kernel. I guess this might be the
> > > > reason why your
> > board works.
> > > >
> > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ#
> > > > to
> > be low.
> > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > CLKREQ_OVERRIDE(bit11).
> > > >
> > >
> > > Ok, that makes sense. Those bits are not explained well in the
> > > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > > gate the clock internally to the host controller block.
> > >
> > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > >
> > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > >
> > >        /*
> > >         * for boards that do not connect CLKREQ#,
> > >         * override CLKREQ# and drive it low internally
> > >         */
> > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > >
> > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > >
> > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> [Richard Zhu] regmap bits operations should manipulate according bits.
> The BIT(10) and BIT(11) should be touched actually.
> 
> > >
> > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs
> > > to be set true to implement the above code?
> > >
> >
> > Richard,
> >
> > Sorry - spoke too soon. My test was flawed as I still was pinmuxing
> > CLKREQ in my dt to work around the issue and after removed the above
> > did not resolve my issue. The setting of OVERRIDE_EN was wrong above
> > (should not be set to '1' but BIT(10) instead) but this code already
> > exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > patch so this is not the issue.
> >
> > What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> > does) so I don't think this bit does what we think it does (select
> > between internal and ext clk). I think setting it enables clock gating via
> CLKREQ#.
> >
> > This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> > moved to the new phy driver for IMX8MM.
> [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be
> low.
> I will think about that and add this in later v5 patch-set if nobody has different
> concerns.
> Thanks.
[Richard Zhu] Hi Tim:
As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on your board, right?
" (I have boards that use the only two possible pins for CLKREQ as other features)"

Did the override configuration of the clkreq# will bring unexpected results for other features on your board?

BR
Richard 

> 
> BR
> Richard
> 
> >
> > Best regards,
> >
> > Tim

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

Snipped...

> > > > > > > My boards do not use CLKREQ# so I do not have that defined
> > > > > > > in pinmux and I found that if I add
> > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > PCIe
> > > > > > > works on my board but this isn't a solution just a
> > > > > > > work-around (I have boards that use the only two possible
> > > > > > > pins for CLKREQ as other
> > > > > features).
> > > > > > >
> > > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > > hanging like my
> > > > > boards:
> > > > > > [Richard Zhu] Hi Tim:
> > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > should be
> > > > > configured as an open drain, active low signal.
> > > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > > request the
> > > > > REF clock be available(active low).
> > > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM
> > > > > > EVK
> > board.
> > > > > >
> > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > running if there is
> > > > > no CLKREQ# on your HW board design.
> > > > > >
> > > > >
> > > > > The way I understand it is CLKREQ# allows the host to disable
> > > > > the REFCLK when not needed for power savings so it would seem
> > > > > optional to implement that and if not implemented should be left
> > > > > unconnected on
> > the card.
> > > > >
> > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> > mandatory required.
> > > > Especially for the L1ss usages. This signal would be OD(open
> > > > drain), bi-directional, and might be driven low/high by RC or EP
> > > > automatically if
> > L1ss modes are enabled.
> > > > You can make reference to the
> > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > 4.0 Version 1.0".
> > > >
> > >
> > > CLKREQ is only mandatory if you wish to support clock power
> > > management. Many boards with a PCI host controller do not support
> > > this.
> [Richard Zhu] Okay, understood.
> 
> > >
> > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > @@ -448,7 +448,9 @@
> > > > > > >
> > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > >                 fsl,pins = <
> > > > > > > +/*
> > > > > > >
> > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > +*/
> > > > > > >
> > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > 0x41
> > > > > > >                 >;
> > > > > > >         };
> > > > > > >
> > > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > > kernel which differs from your driver in that the PCIe PHY
> > > > > > > is not abstracted to its own driver so I think this has
> > > > > > > something to do with the order in which the phy is reset or
> initialized?
> > > > > > > The configuration of
> > > > > gpr14 bits looks correct to me.
> > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > level up the HW
> > > > > compatibility.
> > > > > > That's might the reason why the PCIe works on your HW board
> > > > > > although the
> > > > > CLKREQ# PIN is not defined.
> > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > recommended
> > > > > although it levels up the HW compatibility.
> > > > > > So I drop this method in this series.
> > > > > >
> > > > >
> > > > > Sorry, I don't understand what you are saying here. Is there a
> > > > > change you are going to make to v4 that will make this work for
> > > > > the evk and my boards? What is that change exactly?
> > > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced
> > > > to be low in NXP local BSP kernel. I guess this might be the
> > > > reason why your
> > board works.
> > > >
> > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ#
> > > > to
> > be low.
> > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > CLKREQ_OVERRIDE(bit11).
> > > >
> > >
> > > Ok, that makes sense. Those bits are not explained well in the
> > > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > > gate the clock internally to the host controller block.
> > >
> > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > >
> > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > >
> > >        /*
> > >         * for boards that do not connect CLKREQ#,
> > >         * override CLKREQ# and drive it low internally
> > >         */
> > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > >
> > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > >
> > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> [Richard Zhu] regmap bits operations should manipulate according bits.
> The BIT(10) and BIT(11) should be touched actually.
> 
> > >
> > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs
> > > to be set true to implement the above code?
> > >
> >
> > Richard,
> >
> > Sorry - spoke too soon. My test was flawed as I still was pinmuxing
> > CLKREQ in my dt to work around the issue and after removed the above
> > did not resolve my issue. The setting of OVERRIDE_EN was wrong above
> > (should not be set to '1' but BIT(10) instead) but this code already
> > exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > patch so this is not the issue.
> >
> > What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> > does) so I don't think this bit does what we think it does (select
> > between internal and ext clk). I think setting it enables clock gating via
> CLKREQ#.
> >
> > This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> > moved to the new phy driver for IMX8MM.
> [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be
> low.
> I will think about that and add this in later v5 patch-set if nobody has different
> concerns.
> Thanks.
[Richard Zhu] Hi Tim:
As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on your board, right?
" (I have boards that use the only two possible pins for CLKREQ as other features)"

Did the override configuration of the clkreq# will bring unexpected results for other features on your board?

BR
Richard 

> 
> BR
> Richard
> 
> >
> > Best regards,
> >
> > Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

Snipped...

> > > > > > > My boards do not use CLKREQ# so I do not have that defined
> > > > > > > in pinmux and I found that if I add
> > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > PCIe
> > > > > > > works on my board but this isn't a solution just a
> > > > > > > work-around (I have boards that use the only two possible
> > > > > > > pins for CLKREQ as other
> > > > > features).
> > > > > > >
> > > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > > hanging like my
> > > > > boards:
> > > > > > [Richard Zhu] Hi Tim:
> > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > should be
> > > > > configured as an open drain, active low signal.
> > > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > > request the
> > > > > REF clock be available(active low).
> > > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM
> > > > > > EVK
> > board.
> > > > > >
> > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > running if there is
> > > > > no CLKREQ# on your HW board design.
> > > > > >
> > > > >
> > > > > The way I understand it is CLKREQ# allows the host to disable
> > > > > the REFCLK when not needed for power savings so it would seem
> > > > > optional to implement that and if not implemented should be left
> > > > > unconnected on
> > the card.
> > > > >
> > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> > mandatory required.
> > > > Especially for the L1ss usages. This signal would be OD(open
> > > > drain), bi-directional, and might be driven low/high by RC or EP
> > > > automatically if
> > L1ss modes are enabled.
> > > > You can make reference to the
> > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > 4.0 Version 1.0".
> > > >
> > >
> > > CLKREQ is only mandatory if you wish to support clock power
> > > management. Many boards with a PCI host controller do not support
> > > this.
> [Richard Zhu] Okay, understood.
> 
> > >
> > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > @@ -448,7 +448,9 @@
> > > > > > >
> > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > >                 fsl,pins = <
> > > > > > > +/*
> > > > > > >
> > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > +*/
> > > > > > >
> > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > 0x41
> > > > > > >                 >;
> > > > > > >         };
> > > > > > >
> > > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > > kernel which differs from your driver in that the PCIe PHY
> > > > > > > is not abstracted to its own driver so I think this has
> > > > > > > something to do with the order in which the phy is reset or
> initialized?
> > > > > > > The configuration of
> > > > > gpr14 bits looks correct to me.
> > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > level up the HW
> > > > > compatibility.
> > > > > > That's might the reason why the PCIe works on your HW board
> > > > > > although the
> > > > > CLKREQ# PIN is not defined.
> > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > recommended
> > > > > although it levels up the HW compatibility.
> > > > > > So I drop this method in this series.
> > > > > >
> > > > >
> > > > > Sorry, I don't understand what you are saying here. Is there a
> > > > > change you are going to make to v4 that will make this work for
> > > > > the evk and my boards? What is that change exactly?
> > > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced
> > > > to be low in NXP local BSP kernel. I guess this might be the
> > > > reason why your
> > board works.
> > > >
> > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ#
> > > > to
> > be low.
> > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > CLKREQ_OVERRIDE(bit11).
> > > >
> > >
> > > Ok, that makes sense. Those bits are not explained well in the
> > > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > > gate the clock internally to the host controller block.
> > >
> > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > >
> > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > >
> > >        /*
> > >         * for boards that do not connect CLKREQ#,
> > >         * override CLKREQ# and drive it low internally
> > >         */
> > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > >
> > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > >
> > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> [Richard Zhu] regmap bits operations should manipulate according bits.
> The BIT(10) and BIT(11) should be touched actually.
> 
> > >
> > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs
> > > to be set true to implement the above code?
> > >
> >
> > Richard,
> >
> > Sorry - spoke too soon. My test was flawed as I still was pinmuxing
> > CLKREQ in my dt to work around the issue and after removed the above
> > did not resolve my issue. The setting of OVERRIDE_EN was wrong above
> > (should not be set to '1' but BIT(10) instead) but this code already
> > exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > patch so this is not the issue.
> >
> > What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> > does) so I don't think this bit does what we think it does (select
> > between internal and ext clk). I think setting it enables clock gating via
> CLKREQ#.
> >
> > This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> > moved to the new phy driver for IMX8MM.
> [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be
> low.
> I will think about that and add this in later v5 patch-set if nobody has different
> concerns.
> Thanks.
[Richard Zhu] Hi Tim:
As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on your board, right?
" (I have boards that use the only two possible pins for CLKREQ as other features)"

Did the override configuration of the clkreq# will bring unexpected results for other features on your board?

BR
Richard 

> 
> BR
> Richard
> 
> >
> > Best regards,
> >
> > Tim
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> Snipped...
>
> > > > > > > > My boards do not use CLKREQ# so I do not have that defined
> > > > > > > > in pinmux and I found that if I add
> > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > PCIe
> > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > work-around (I have boards that use the only two possible
> > > > > > > > pins for CLKREQ as other
> > > > > > features).
> > > > > > > >
> > > > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > > > hanging like my
> > > > > > boards:
> > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > should be
> > > > > > configured as an open drain, active low signal.
> > > > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > > > request the
> > > > > > REF clock be available(active low).
> > > > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM
> > > > > > > EVK
> > > board.
> > > > > > >
> > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > running if there is
> > > > > > no CLKREQ# on your HW board design.
> > > > > > >
> > > > > >
> > > > > > The way I understand it is CLKREQ# allows the host to disable
> > > > > > the REFCLK when not needed for power savings so it would seem
> > > > > > optional to implement that and if not implemented should be left
> > > > > > unconnected on
> > > the card.
> > > > > >
> > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> > > mandatory required.
> > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > drain), bi-directional, and might be driven low/high by RC or EP
> > > > > automatically if
> > > L1ss modes are enabled.
> > > > > You can make reference to the
> > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > 4.0 Version 1.0".
> > > > >
> > > >
> > > > CLKREQ is only mandatory if you wish to support clock power
> > > > management. Many boards with a PCI host controller do not support
> > > > this.
> > [Richard Zhu] Okay, understood.
> >
> > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > >
> > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > >                 fsl,pins = <
> > > > > > > > +/*
> > > > > > > >
> > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > +*/
> > > > > > > >
> > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > 0x41
> > > > > > > >                 >;
> > > > > > > >         };
> > > > > > > >
> > > > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > > > kernel which differs from your driver in that the PCIe PHY
> > > > > > > > is not abstracted to its own driver so I think this has
> > > > > > > > something to do with the order in which the phy is reset or
> > initialized?
> > > > > > > > The configuration of
> > > > > > gpr14 bits looks correct to me.
> > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > level up the HW
> > > > > > compatibility.
> > > > > > > That's might the reason why the PCIe works on your HW board
> > > > > > > although the
> > > > > > CLKREQ# PIN is not defined.
> > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > recommended
> > > > > > although it levels up the HW compatibility.
> > > > > > > So I drop this method in this series.
> > > > > > >
> > > > > >
> > > > > > Sorry, I don't understand what you are saying here. Is there a
> > > > > > change you are going to make to v4 that will make this work for
> > > > > > the evk and my boards? What is that change exactly?
> > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced
> > > > > to be low in NXP local BSP kernel. I guess this might be the
> > > > > reason why your
> > > board works.
> > > > >
> > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ#
> > > > > to
> > > be low.
> > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > CLKREQ_OVERRIDE(bit11).
> > > > >
> > > >
> > > > Ok, that makes sense. Those bits are not explained well in the
> > > > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > > > gate the clock internally to the host controller block.
> > > >
> > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > >
> > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > >
> > > >        /*
> > > >         * for boards that do not connect CLKREQ#,
> > > >         * override CLKREQ# and drive it low internally
> > > >         */
> > > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > >
> > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > >
> > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > [Richard Zhu] regmap bits operations should manipulate according bits.
> > The BIT(10) and BIT(11) should be touched actually.
> >
> > > >
> > > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs
> > > > to be set true to implement the above code?
> > > >
> > >
> > > Richard,
> > >
> > > Sorry - spoke too soon. My test was flawed as I still was pinmuxing
> > > CLKREQ in my dt to work around the issue and after removed the above
> > > did not resolve my issue. The setting of OVERRIDE_EN was wrong above
> > > (should not be set to '1' but BIT(10) instead) but this code already
> > > exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > > patch so this is not the issue.
> > >
> > > What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> > > does) so I don't think this bit does what we think it does (select
> > > between internal and ext clk). I think setting it enables clock gating via
> > CLKREQ#.
> > >
> > > This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> > > moved to the new phy driver for IMX8MM.
> > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be
> > low.
> > I will think about that and add this in later v5 patch-set if nobody has different
> > concerns.
> > Thanks.
> [Richard Zhu] Hi Tim:
> As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on your board, right?
> " (I have boards that use the only two possible pins for CLKREQ as other features)"
>
> Did the override configuration of the clkreq# will bring unexpected results for other features on your board?
>

What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
and because I2C4_SCL and UART4_RXD are the only two pads that could be
pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.

Currently your driver only works on my imx8mm-venice-* boards if I add
one of the following on boards that don't connect those pads (or if I
clear IMX8MM_GPR_PCIE_REF_USE_PAD):
MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B

Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
enable this code already in the imx6_pcie_enable_ref_clk function to
override REF_CLK and drive it low:

offset = imx6_pcie_grp_offset(imx6_pcie);
/*
* Set the over ride low and enabled
* make sure that REF_CLK is turned on.
*/
regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
   0);
regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);

So this is already being run and yet my boards still do not work
unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
NXP downstream driver does:
regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
IMX8MM_GPR_PCIE_REF_USE_PAD, 0);

This is why I'm not sure that bit does what you think it does... I
feel like that bit enables 'Use CLKREQ# to enable CLK'.

You tell me the descriptions for GPR14 are wrong in the reference
manual. Please provide correct descriptions for us so we can sort this
out.

Best regards,

Tim
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1634028078-2387-10-git-send-email-hongxing.zhu@nxp.com/

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> Snipped...
>
> > > > > > > > My boards do not use CLKREQ# so I do not have that defined
> > > > > > > > in pinmux and I found that if I add
> > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > PCIe
> > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > work-around (I have boards that use the only two possible
> > > > > > > > pins for CLKREQ as other
> > > > > > features).
> > > > > > > >
> > > > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > > > hanging like my
> > > > > > boards:
> > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > should be
> > > > > > configured as an open drain, active low signal.
> > > > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > > > request the
> > > > > > REF clock be available(active low).
> > > > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM
> > > > > > > EVK
> > > board.
> > > > > > >
> > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > running if there is
> > > > > > no CLKREQ# on your HW board design.
> > > > > > >
> > > > > >
> > > > > > The way I understand it is CLKREQ# allows the host to disable
> > > > > > the REFCLK when not needed for power savings so it would seem
> > > > > > optional to implement that and if not implemented should be left
> > > > > > unconnected on
> > > the card.
> > > > > >
> > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> > > mandatory required.
> > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > drain), bi-directional, and might be driven low/high by RC or EP
> > > > > automatically if
> > > L1ss modes are enabled.
> > > > > You can make reference to the
> > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > 4.0 Version 1.0".
> > > > >
> > > >
> > > > CLKREQ is only mandatory if you wish to support clock power
> > > > management. Many boards with a PCI host controller do not support
> > > > this.
> > [Richard Zhu] Okay, understood.
> >
> > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > >
> > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > >                 fsl,pins = <
> > > > > > > > +/*
> > > > > > > >
> > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > +*/
> > > > > > > >
> > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > 0x41
> > > > > > > >                 >;
> > > > > > > >         };
> > > > > > > >
> > > > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > > > kernel which differs from your driver in that the PCIe PHY
> > > > > > > > is not abstracted to its own driver so I think this has
> > > > > > > > something to do with the order in which the phy is reset or
> > initialized?
> > > > > > > > The configuration of
> > > > > > gpr14 bits looks correct to me.
> > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > level up the HW
> > > > > > compatibility.
> > > > > > > That's might the reason why the PCIe works on your HW board
> > > > > > > although the
> > > > > > CLKREQ# PIN is not defined.
> > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > recommended
> > > > > > although it levels up the HW compatibility.
> > > > > > > So I drop this method in this series.
> > > > > > >
> > > > > >
> > > > > > Sorry, I don't understand what you are saying here. Is there a
> > > > > > change you are going to make to v4 that will make this work for
> > > > > > the evk and my boards? What is that change exactly?
> > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced
> > > > > to be low in NXP local BSP kernel. I guess this might be the
> > > > > reason why your
> > > board works.
> > > > >
> > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ#
> > > > > to
> > > be low.
> > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > CLKREQ_OVERRIDE(bit11).
> > > > >
> > > >
> > > > Ok, that makes sense. Those bits are not explained well in the
> > > > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > > > gate the clock internally to the host controller block.
> > > >
> > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > >
> > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > >
> > > >        /*
> > > >         * for boards that do not connect CLKREQ#,
> > > >         * override CLKREQ# and drive it low internally
> > > >         */
> > > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > >
> > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > >
> > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > [Richard Zhu] regmap bits operations should manipulate according bits.
> > The BIT(10) and BIT(11) should be touched actually.
> >
> > > >
> > > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs
> > > > to be set true to implement the above code?
> > > >
> > >
> > > Richard,
> > >
> > > Sorry - spoke too soon. My test was flawed as I still was pinmuxing
> > > CLKREQ in my dt to work around the issue and after removed the above
> > > did not resolve my issue. The setting of OVERRIDE_EN was wrong above
> > > (should not be set to '1' but BIT(10) instead) but this code already
> > > exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > > patch so this is not the issue.
> > >
> > > What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> > > does) so I don't think this bit does what we think it does (select
> > > between internal and ext clk). I think setting it enables clock gating via
> > CLKREQ#.
> > >
> > > This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> > > moved to the new phy driver for IMX8MM.
> > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be
> > low.
> > I will think about that and add this in later v5 patch-set if nobody has different
> > concerns.
> > Thanks.
> [Richard Zhu] Hi Tim:
> As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on your board, right?
> " (I have boards that use the only two possible pins for CLKREQ as other features)"
>
> Did the override configuration of the clkreq# will bring unexpected results for other features on your board?
>

What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
and because I2C4_SCL and UART4_RXD are the only two pads that could be
pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.

Currently your driver only works on my imx8mm-venice-* boards if I add
one of the following on boards that don't connect those pads (or if I
clear IMX8MM_GPR_PCIE_REF_USE_PAD):
MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B

Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
enable this code already in the imx6_pcie_enable_ref_clk function to
override REF_CLK and drive it low:

offset = imx6_pcie_grp_offset(imx6_pcie);
/*
* Set the over ride low and enabled
* make sure that REF_CLK is turned on.
*/
regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
   0);
regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);

So this is already being run and yet my boards still do not work
unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
NXP downstream driver does:
regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
IMX8MM_GPR_PCIE_REF_USE_PAD, 0);

This is why I'm not sure that bit does what you think it does... I
feel like that bit enables 'Use CLKREQ# to enable CLK'.

You tell me the descriptions for GPR14 are wrong in the reference
manual. Please provide correct descriptions for us so we can sort this
out.

Best regards,

Tim
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1634028078-2387-10-git-send-email-hongxing.zhu@nxp.com/

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> Snipped...
>
> > > > > > > > My boards do not use CLKREQ# so I do not have that defined
> > > > > > > > in pinmux and I found that if I add
> > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > PCIe
> > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > work-around (I have boards that use the only two possible
> > > > > > > > pins for CLKREQ as other
> > > > > > features).
> > > > > > > >
> > > > > > > > Similarly you will find on the imx8mm-evk if you comment out
> > > > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up
> > > > > > > > hanging like my
> > > > > > boards:
> > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > should be
> > > > > > configured as an open drain, active low signal.
> > > > > > > And this signal should be driven low by the PCIe M.2 device to
> > > > > > > request the
> > > > > > REF clock be available(active low).
> > > > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM
> > > > > > > EVK
> > > board.
> > > > > > >
> > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > running if there is
> > > > > > no CLKREQ# on your HW board design.
> > > > > > >
> > > > > >
> > > > > > The way I understand it is CLKREQ# allows the host to disable
> > > > > > the REFCLK when not needed for power savings so it would seem
> > > > > > optional to implement that and if not implemented should be left
> > > > > > unconnected on
> > > the card.
> > > > > >
> > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is
> > > mandatory required.
> > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > drain), bi-directional, and might be driven low/high by RC or EP
> > > > > automatically if
> > > L1ss modes are enabled.
> > > > > You can make reference to the
> > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the
> > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > 4.0 Version 1.0".
> > > > >
> > > >
> > > > CLKREQ is only mandatory if you wish to support clock power
> > > > management. Many boards with a PCI host controller do not support
> > > > this.
> > [Richard Zhu] Okay, understood.
> >
> > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > >
> > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > >                 fsl,pins = <
> > > > > > > > +/*
> > > > > > > >
> > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > +*/
> > > > > > > >
> > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > 0x41
> > > > > > > >                 >;
> > > > > > > >         };
> > > > > > > >
> > > > > > > > I have PCIe working with a driver that I ported from NXP's
> > > > > > > > kernel which differs from your driver in that the PCIe PHY
> > > > > > > > is not abstracted to its own driver so I think this has
> > > > > > > > something to do with the order in which the phy is reset or
> > initialized?
> > > > > > > > The configuration of
> > > > > > gpr14 bits looks correct to me.
> > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > level up the HW
> > > > > > compatibility.
> > > > > > > That's might the reason why the PCIe works on your HW board
> > > > > > > although the
> > > > > > CLKREQ# PIN is not defined.
> > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > recommended
> > > > > > although it levels up the HW compatibility.
> > > > > > > So I drop this method in this series.
> > > > > > >
> > > > > >
> > > > > > Sorry, I don't understand what you are saying here. Is there a
> > > > > > change you are going to make to v4 that will make this work for
> > > > > > the evk and my boards? What is that change exactly?
> > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced
> > > > > to be low in NXP local BSP kernel. I guess this might be the
> > > > > reason why your
> > > board works.
> > > > >
> > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ#
> > > > > to
> > > be low.
> > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > CLKREQ_OVERRIDE(bit11).
> > > > >
> > > >
> > > > Ok, that makes sense. Those bits are not explained well in the
> > > > IMX8MMRM. As my board's external REFCLK is always enabled that must
> > > > gate the clock internally to the host controller block.
> > > >
> > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > >
> > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > >
> > > >        /*
> > > >         * for boards that do not connect CLKREQ#,
> > > >         * override CLKREQ# and drive it low internally
> > > >         */
> > > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > >
> > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > >        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > >
> > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > [Richard Zhu] regmap bits operations should manipulate according bits.
> > The BIT(10) and BIT(11) should be touched actually.
> >
> > > >
> > > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs
> > > > to be set true to implement the above code?
> > > >
> > >
> > > Richard,
> > >
> > > Sorry - spoke too soon. My test was flawed as I still was pinmuxing
> > > CLKREQ in my dt to work around the issue and after removed the above
> > > did not resolve my issue. The setting of OVERRIDE_EN was wrong above
> > > (should not be set to '1' but BIT(10) instead) but this code already
> > > exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > > patch so this is not the issue.
> > >
> > > What makes my board work is to clear GPR14 bit9 (like the NXP kernel
> > > does) so I don't think this bit does what we think it does (select
> > > between internal and ext clk). I think setting it enables clock gating via
> > CLKREQ#.
> > >
> > > This also points out that perhaps the CLKREQ_OVERRIDE logic should be
> > > moved to the new phy driver for IMX8MM.
> > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be
> > low.
> > I will think about that and add this in later v5 patch-set if nobody has different
> > concerns.
> > Thanks.
> [Richard Zhu] Hi Tim:
> As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on your board, right?
> " (I have boards that use the only two possible pins for CLKREQ as other features)"
>
> Did the override configuration of the clkreq# will bring unexpected results for other features on your board?
>

What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
and because I2C4_SCL and UART4_RXD are the only two pads that could be
pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.

Currently your driver only works on my imx8mm-venice-* boards if I add
one of the following on boards that don't connect those pads (or if I
clear IMX8MM_GPR_PCIE_REF_USE_PAD):
MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B

Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
enable this code already in the imx6_pcie_enable_ref_clk function to
override REF_CLK and drive it low:

offset = imx6_pcie_grp_offset(imx6_pcie);
/*
* Set the over ride low and enabled
* make sure that REF_CLK is turned on.
*/
regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
   0);
regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
   IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);

So this is already being run and yet my boards still do not work
unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
NXP downstream driver does:
regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
IMX8MM_GPR_PCIE_REF_USE_PAD, 0);

This is why I'm not sure that bit does what you think it does... I
feel like that bit enables 'Use CLKREQ# to enable CLK'.

You tell me the descriptions for GPR14 are wrong in the reference
manual. Please provide correct descriptions for us so we can sort this
out.

Best regards,

Tim
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1634028078-2387-10-git-send-email-hongxing.zhu@nxp.com/

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Tuesday, October 26, 2021 1:15 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > Snipped...
> >
> > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > PCIe
> > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > possible pins for CLKREQ as other
> > > > > > > features).
> > > > > > > > >
> > > > > > > > > Similarly you will find on the imx8mm-evk if you comment
> > > > > > > > > out the CLKREQ (which isn't required) the imx8mmevk will
> > > > > > > > > end up hanging like my
> > > > > > > boards:
> > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > > should be
> > > > > > > configured as an open drain, active low signal.
> > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > device to request the
> > > > > > > REF clock be available(active low).
> > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > i.MX8MM EVK
> > > > board.
> > > > > > > >
> > > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > > running if there is
> > > > > > > no CLKREQ# on your HW board design.
> > > > > > > >
> > > > > > >
> > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > disable the REFCLK when not needed for power savings so it
> > > > > > > would seem optional to implement that and if not implemented
> > > > > > > should be left unconnected on
> > > > the card.
> > > > > > >
> > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > signal is
> > > > mandatory required.
> > > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > > drain), bi-directional, and might be driven low/high by RC or
> > > > > > EP automatically if
> > > > L1ss modes are enabled.
> > > > > > You can make reference to the
> > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> the
> > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > 4.0 Version 1.0".
> > > > > >
> > > > >
> > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > management. Many boards with a PCI host controller do not
> > > > > support this.
> > > [Richard Zhu] Okay, understood.
> > >
> > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > >
> > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > >                 fsl,pins = <
> > > > > > > > > +/*
> > > > > > > > >
> > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > +*/
> > > > > > > > >
> > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > 0x41
> > > > > > > > >                 >;
> > > > > > > > >         };
> > > > > > > > >
> > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > NXP's kernel which differs from your driver in that the
> > > > > > > > > PCIe PHY is not abstracted to its own driver so I think
> > > > > > > > > this has something to do with the order in which the phy
> > > > > > > > > is reset or
> > > initialized?
> > > > > > > > > The configuration of
> > > > > > > gpr14 bits looks correct to me.
> > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > > level up the HW
> > > > > > > compatibility.
> > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > board although the
> > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > > recommended
> > > > > > > although it levels up the HW compatibility.
> > > > > > > > So I drop this method in this series.
> > > > > > > >
> > > > > > >
> > > > > > > Sorry, I don't understand what you are saying here. Is there
> > > > > > > a change you are going to make to v4 that will make this
> > > > > > > work for the evk and my boards? What is that change exactly?
> > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > forced to be low in NXP local BSP kernel. I guess this might
> > > > > > be the reason why your
> > > > board works.
> > > > > >
> > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > CLKREQ# to
> > > > be low.
> > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > CLKREQ_OVERRIDE(bit11).
> > > > > >
> > > > >
> > > > > Ok, that makes sense. Those bits are not explained well in the
> > > > > IMX8MMRM. As my board's external REFCLK is always enabled that
> > > > > must gate the clock internally to the host controller block.
> > > > >
> > > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > > >
> > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > > >
> > > > >        /*
> > > > >         * for boards that do not connect CLKREQ#,
> > > > >         * override CLKREQ# and drive it low internally
> > > > >         */
> > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > > >
> > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > > >
> > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > [Richard Zhu] regmap bits operations should manipulate according bits.
> > > The BIT(10) and BIT(11) should be touched actually.
> > >
> > > > >
> > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > needs to be set true to implement the above code?
> > > > >
> > > >
> > > > Richard,
> > > >
> > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > removed the above did not resolve my issue. The setting of
> > > > OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10)
> > > > instead) but this code already exists in imx6_pcie_enable_ref_clk
> > > > and is used for IMX8MM per your patch so this is not the issue.
> > > >
> > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > kernel
> > > > does) so I don't think this bit does what we think it does (select
> > > > between internal and ext clk). I think setting it enables clock
> > > > gating via
> > > CLKREQ#.
> > > >
> > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should
> > > > be moved to the new phy driver for IMX8MM.
> > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ#
> > > to be low.
> > > I will think about that and add this in later v5 patch-set if nobody
> > > has different concerns.
> > > Thanks.
> > [Richard Zhu] Hi Tim:
> > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on
> your board, right?
> > " (I have boards that use the only two possible pins for CLKREQ as other
> features)"
> >
> > Did the override configuration of the clkreq# will bring unexpected results
> for other features on your board?
> >
> 
> What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
> and because I2C4_SCL and UART4_RXD are the only two pads that could be
> pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.
> 
> Currently your driver only works on my imx8mm-venice-* boards if I add one
> of the following on boards that don't connect those pads (or if I clear
> IMX8MM_GPR_PCIE_REF_USE_PAD):
> MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> 
> Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this
> code already in the imx6_pcie_enable_ref_clk function to override REF_CLK
> and drive it low:
> 
> offset = imx6_pcie_grp_offset(imx6_pcie);
> /*
> * Set the over ride low and enabled
> * make sure that REF_CLK is turned on.
> */
> regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
>    0);
> regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> 
> So this is already being run and yet my boards still do not work unless I clr
> IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP
> downstream driver does:
> regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> 
> This is why I'm not sure that bit does what you think it does... I feel like that
> bit enables 'Use CLKREQ# to enable CLK'.
> 
> You tell me the descriptions for GPR14 are wrong in the reference manual.
> Please provide correct descriptions for us so we can sort this out.
> 
[Richard Zhu] Hi Tim:
The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
I think the two bits descriptions are used to describe the BIT19 and BIT9 together refer to my guess.
{GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
2'b00: External Reference Clock I/O (for PLL) Disable
2'b01: External Reference Clock I/O (for PLL) Enable
2'b10: External Reference Clock I/O (for PLL) Disable
2'b11: External Reference Clock I/O (for PLL) output is controlled by CLKREQ#

The option1&3 should be forbidden, since the external REF CLK I/O should be enabled on your board and EVK board.
In the option2&4, the BIT19 should be set to be 1'b1.

So, regarding my understand, if the CLKREQ# is not pinmuxed in your use case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.

BR
Richard
> Best regards,
> 
> Tim
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F1634028078-23
> 87-10-git-send-email-hongxing.zhu%40nxp.com%2F&amp;data=04%7C01%7
> Chongxing.zhu%40nxp.com%7Cb796532d98124790154a08d997daf1e4%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637707788885954739%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NRK9mIMkYsgcXzBsL
> I7GE62hy64Bumxr8WdCD1oh59w%3D&amp;reserved=0

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Tuesday, October 26, 2021 1:15 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > Snipped...
> >
> > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > PCIe
> > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > possible pins for CLKREQ as other
> > > > > > > features).
> > > > > > > > >
> > > > > > > > > Similarly you will find on the imx8mm-evk if you comment
> > > > > > > > > out the CLKREQ (which isn't required) the imx8mmevk will
> > > > > > > > > end up hanging like my
> > > > > > > boards:
> > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > > should be
> > > > > > > configured as an open drain, active low signal.
> > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > device to request the
> > > > > > > REF clock be available(active low).
> > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > i.MX8MM EVK
> > > > board.
> > > > > > > >
> > > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > > running if there is
> > > > > > > no CLKREQ# on your HW board design.
> > > > > > > >
> > > > > > >
> > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > disable the REFCLK when not needed for power savings so it
> > > > > > > would seem optional to implement that and if not implemented
> > > > > > > should be left unconnected on
> > > > the card.
> > > > > > >
> > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > signal is
> > > > mandatory required.
> > > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > > drain), bi-directional, and might be driven low/high by RC or
> > > > > > EP automatically if
> > > > L1ss modes are enabled.
> > > > > > You can make reference to the
> > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> the
> > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > 4.0 Version 1.0".
> > > > > >
> > > > >
> > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > management. Many boards with a PCI host controller do not
> > > > > support this.
> > > [Richard Zhu] Okay, understood.
> > >
> > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > >
> > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > >                 fsl,pins = <
> > > > > > > > > +/*
> > > > > > > > >
> > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > +*/
> > > > > > > > >
> > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > 0x41
> > > > > > > > >                 >;
> > > > > > > > >         };
> > > > > > > > >
> > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > NXP's kernel which differs from your driver in that the
> > > > > > > > > PCIe PHY is not abstracted to its own driver so I think
> > > > > > > > > this has something to do with the order in which the phy
> > > > > > > > > is reset or
> > > initialized?
> > > > > > > > > The configuration of
> > > > > > > gpr14 bits looks correct to me.
> > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > > level up the HW
> > > > > > > compatibility.
> > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > board although the
> > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > > recommended
> > > > > > > although it levels up the HW compatibility.
> > > > > > > > So I drop this method in this series.
> > > > > > > >
> > > > > > >
> > > > > > > Sorry, I don't understand what you are saying here. Is there
> > > > > > > a change you are going to make to v4 that will make this
> > > > > > > work for the evk and my boards? What is that change exactly?
> > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > forced to be low in NXP local BSP kernel. I guess this might
> > > > > > be the reason why your
> > > > board works.
> > > > > >
> > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > CLKREQ# to
> > > > be low.
> > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > CLKREQ_OVERRIDE(bit11).
> > > > > >
> > > > >
> > > > > Ok, that makes sense. Those bits are not explained well in the
> > > > > IMX8MMRM. As my board's external REFCLK is always enabled that
> > > > > must gate the clock internally to the host controller block.
> > > > >
> > > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > > >
> > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > > >
> > > > >        /*
> > > > >         * for boards that do not connect CLKREQ#,
> > > > >         * override CLKREQ# and drive it low internally
> > > > >         */
> > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > > >
> > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > > >
> > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > [Richard Zhu] regmap bits operations should manipulate according bits.
> > > The BIT(10) and BIT(11) should be touched actually.
> > >
> > > > >
> > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > needs to be set true to implement the above code?
> > > > >
> > > >
> > > > Richard,
> > > >
> > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > removed the above did not resolve my issue. The setting of
> > > > OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10)
> > > > instead) but this code already exists in imx6_pcie_enable_ref_clk
> > > > and is used for IMX8MM per your patch so this is not the issue.
> > > >
> > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > kernel
> > > > does) so I don't think this bit does what we think it does (select
> > > > between internal and ext clk). I think setting it enables clock
> > > > gating via
> > > CLKREQ#.
> > > >
> > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should
> > > > be moved to the new phy driver for IMX8MM.
> > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ#
> > > to be low.
> > > I will think about that and add this in later v5 patch-set if nobody
> > > has different concerns.
> > > Thanks.
> > [Richard Zhu] Hi Tim:
> > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on
> your board, right?
> > " (I have boards that use the only two possible pins for CLKREQ as other
> features)"
> >
> > Did the override configuration of the clkreq# will bring unexpected results
> for other features on your board?
> >
> 
> What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
> and because I2C4_SCL and UART4_RXD are the only two pads that could be
> pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.
> 
> Currently your driver only works on my imx8mm-venice-* boards if I add one
> of the following on boards that don't connect those pads (or if I clear
> IMX8MM_GPR_PCIE_REF_USE_PAD):
> MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> 
> Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this
> code already in the imx6_pcie_enable_ref_clk function to override REF_CLK
> and drive it low:
> 
> offset = imx6_pcie_grp_offset(imx6_pcie);
> /*
> * Set the over ride low and enabled
> * make sure that REF_CLK is turned on.
> */
> regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
>    0);
> regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> 
> So this is already being run and yet my boards still do not work unless I clr
> IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP
> downstream driver does:
> regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> 
> This is why I'm not sure that bit does what you think it does... I feel like that
> bit enables 'Use CLKREQ# to enable CLK'.
> 
> You tell me the descriptions for GPR14 are wrong in the reference manual.
> Please provide correct descriptions for us so we can sort this out.
> 
[Richard Zhu] Hi Tim:
The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
I think the two bits descriptions are used to describe the BIT19 and BIT9 together refer to my guess.
{GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
2'b00: External Reference Clock I/O (for PLL) Disable
2'b01: External Reference Clock I/O (for PLL) Enable
2'b10: External Reference Clock I/O (for PLL) Disable
2'b11: External Reference Clock I/O (for PLL) output is controlled by CLKREQ#

The option1&3 should be forbidden, since the external REF CLK I/O should be enabled on your board and EVK board.
In the option2&4, the BIT19 should be set to be 1'b1.

So, regarding my understand, if the CLKREQ# is not pinmuxed in your use case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.

BR
Richard
> Best regards,
> 
> Tim
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F1634028078-23
> 87-10-git-send-email-hongxing.zhu%40nxp.com%2F&amp;data=04%7C01%7
> Chongxing.zhu%40nxp.com%7Cb796532d98124790154a08d997daf1e4%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637707788885954739%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NRK9mIMkYsgcXzBsL
> I7GE62hy64Bumxr8WdCD1oh59w%3D&amp;reserved=0

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Tuesday, October 26, 2021 1:15 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > Snipped...
> >
> > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > PCIe
> > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > possible pins for CLKREQ as other
> > > > > > > features).
> > > > > > > > >
> > > > > > > > > Similarly you will find on the imx8mm-evk if you comment
> > > > > > > > > out the CLKREQ (which isn't required) the imx8mmevk will
> > > > > > > > > end up hanging like my
> > > > > > > boards:
> > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > > should be
> > > > > > > configured as an open drain, active low signal.
> > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > device to request the
> > > > > > > REF clock be available(active low).
> > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > i.MX8MM EVK
> > > > board.
> > > > > > > >
> > > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > > running if there is
> > > > > > > no CLKREQ# on your HW board design.
> > > > > > > >
> > > > > > >
> > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > disable the REFCLK when not needed for power savings so it
> > > > > > > would seem optional to implement that and if not implemented
> > > > > > > should be left unconnected on
> > > > the card.
> > > > > > >
> > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > signal is
> > > > mandatory required.
> > > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > > drain), bi-directional, and might be driven low/high by RC or
> > > > > > EP automatically if
> > > > L1ss modes are enabled.
> > > > > > You can make reference to the
> > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> the
> > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > 4.0 Version 1.0".
> > > > > >
> > > > >
> > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > management. Many boards with a PCI host controller do not
> > > > > support this.
> > > [Richard Zhu] Okay, understood.
> > >
> > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > >
> > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > >                 fsl,pins = <
> > > > > > > > > +/*
> > > > > > > > >
> > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > +*/
> > > > > > > > >
> > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > 0x41
> > > > > > > > >                 >;
> > > > > > > > >         };
> > > > > > > > >
> > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > NXP's kernel which differs from your driver in that the
> > > > > > > > > PCIe PHY is not abstracted to its own driver so I think
> > > > > > > > > this has something to do with the order in which the phy
> > > > > > > > > is reset or
> > > initialized?
> > > > > > > > > The configuration of
> > > > > > > gpr14 bits looks correct to me.
> > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > > level up the HW
> > > > > > > compatibility.
> > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > board although the
> > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > > recommended
> > > > > > > although it levels up the HW compatibility.
> > > > > > > > So I drop this method in this series.
> > > > > > > >
> > > > > > >
> > > > > > > Sorry, I don't understand what you are saying here. Is there
> > > > > > > a change you are going to make to v4 that will make this
> > > > > > > work for the evk and my boards? What is that change exactly?
> > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > forced to be low in NXP local BSP kernel. I guess this might
> > > > > > be the reason why your
> > > > board works.
> > > > > >
> > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > CLKREQ# to
> > > > be low.
> > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > CLKREQ_OVERRIDE(bit11).
> > > > > >
> > > > >
> > > > > Ok, that makes sense. Those bits are not explained well in the
> > > > > IMX8MMRM. As my board's external REFCLK is always enabled that
> > > > > must gate the clock internally to the host controller block.
> > > > >
> > > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > > >
> > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > > >
> > > > >        /*
> > > > >         * for boards that do not connect CLKREQ#,
> > > > >         * override CLKREQ# and drive it low internally
> > > > >         */
> > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > > >
> > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > > >
> > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > [Richard Zhu] regmap bits operations should manipulate according bits.
> > > The BIT(10) and BIT(11) should be touched actually.
> > >
> > > > >
> > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > needs to be set true to implement the above code?
> > > > >
> > > >
> > > > Richard,
> > > >
> > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > removed the above did not resolve my issue. The setting of
> > > > OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10)
> > > > instead) but this code already exists in imx6_pcie_enable_ref_clk
> > > > and is used for IMX8MM per your patch so this is not the issue.
> > > >
> > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > kernel
> > > > does) so I don't think this bit does what we think it does (select
> > > > between internal and ext clk). I think setting it enables clock
> > > > gating via
> > > CLKREQ#.
> > > >
> > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should
> > > > be moved to the new phy driver for IMX8MM.
> > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ#
> > > to be low.
> > > I will think about that and add this in later v5 patch-set if nobody
> > > has different concerns.
> > > Thanks.
> > [Richard Zhu] Hi Tim:
> > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on
> your board, right?
> > " (I have boards that use the only two possible pins for CLKREQ as other
> features)"
> >
> > Did the override configuration of the clkreq# will bring unexpected results
> for other features on your board?
> >
> 
> What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
> and because I2C4_SCL and UART4_RXD are the only two pads that could be
> pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.
> 
> Currently your driver only works on my imx8mm-venice-* boards if I add one
> of the following on boards that don't connect those pads (or if I clear
> IMX8MM_GPR_PCIE_REF_USE_PAD):
> MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> 
> Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this
> code already in the imx6_pcie_enable_ref_clk function to override REF_CLK
> and drive it low:
> 
> offset = imx6_pcie_grp_offset(imx6_pcie);
> /*
> * Set the over ride low and enabled
> * make sure that REF_CLK is turned on.
> */
> regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
>    0);
> regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
>    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> 
> So this is already being run and yet my boards still do not work unless I clr
> IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP
> downstream driver does:
> regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> 
> This is why I'm not sure that bit does what you think it does... I feel like that
> bit enables 'Use CLKREQ# to enable CLK'.
> 
> You tell me the descriptions for GPR14 are wrong in the reference manual.
> Please provide correct descriptions for us so we can sort this out.
> 
[Richard Zhu] Hi Tim:
The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
I think the two bits descriptions are used to describe the BIT19 and BIT9 together refer to my guess.
{GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
2'b00: External Reference Clock I/O (for PLL) Disable
2'b01: External Reference Clock I/O (for PLL) Enable
2'b10: External Reference Clock I/O (for PLL) Disable
2'b11: External Reference Clock I/O (for PLL) output is controlled by CLKREQ#

The option1&3 should be forbidden, since the external REF CLK I/O should be enabled on your board and EVK board.
In the option2&4, the BIT19 should be set to be 1'b1.

So, regarding my understand, if the CLKREQ# is not pinmuxed in your use case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.

BR
Richard
> Best regards,
> 
> Tim
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F1634028078-23
> 87-10-git-send-email-hongxing.zhu%40nxp.com%2F&amp;data=04%7C01%7
> Chongxing.zhu%40nxp.com%7Cb796532d98124790154a08d997daf1e4%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637707788885954739%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NRK9mIMkYsgcXzBsL
> I7GE62hy64Bumxr8WdCD1oh59w%3D&amp;reserved=0

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Tuesday, October 26, 2021 1:15 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > Snipped...
> > >
> > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > PCIe
> > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > features).
> > > > > > > > > >
> > > > > > > > > > Similarly you will find on the imx8mm-evk if you comment
> > > > > > > > > > out the CLKREQ (which isn't required) the imx8mmevk will
> > > > > > > > > > end up hanging like my
> > > > > > > > boards:
> > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > > > should be
> > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > device to request the
> > > > > > > > REF clock be available(active low).
> > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > i.MX8MM EVK
> > > > > board.
> > > > > > > > >
> > > > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > > > running if there is
> > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > >
> > > > > > > >
> > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > disable the REFCLK when not needed for power savings so it
> > > > > > > > would seem optional to implement that and if not implemented
> > > > > > > > should be left unconnected on
> > > > > the card.
> > > > > > > >
> > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > signal is
> > > > > mandatory required.
> > > > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > > > drain), bi-directional, and might be driven low/high by RC or
> > > > > > > EP automatically if
> > > > > L1ss modes are enabled.
> > > > > > > You can make reference to the
> > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> > the
> > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > 4.0 Version 1.0".
> > > > > > >
> > > > > >
> > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > management. Many boards with a PCI host controller do not
> > > > > > support this.
> > > > [Richard Zhu] Okay, understood.
> > > >
> > > > > >
> > > > > > > > > > diff --git
> > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > >
> > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > +/*
> > > > > > > > > >
> > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > +*/
> > > > > > > > > >
> > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > 0x41
> > > > > > > > > >                 >;
> > > > > > > > > >         };
> > > > > > > > > >
> > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > NXP's kernel which differs from your driver in that the
> > > > > > > > > > PCIe PHY is not abstracted to its own driver so I think
> > > > > > > > > > this has something to do with the order in which the phy
> > > > > > > > > > is reset or
> > > > initialized?
> > > > > > > > > > The configuration of
> > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > > > level up the HW
> > > > > > > > compatibility.
> > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > board although the
> > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > > > recommended
> > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > So I drop this method in this series.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Sorry, I don't understand what you are saying here. Is there
> > > > > > > > a change you are going to make to v4 that will make this
> > > > > > > > work for the evk and my boards? What is that change exactly?
> > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > forced to be low in NXP local BSP kernel. I guess this might
> > > > > > > be the reason why your
> > > > > board works.
> > > > > > >
> > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > CLKREQ# to
> > > > > be low.
> > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > >
> > > > > >
> > > > > > Ok, that makes sense. Those bits are not explained well in the
> > > > > > IMX8MMRM. As my board's external REFCLK is always enabled that
> > > > > > must gate the clock internally to the host controller block.
> > > > > >
> > > > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > > > >
> > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > > > >
> > > > > >        /*
> > > > > >         * for boards that do not connect CLKREQ#,
> > > > > >         * override CLKREQ# and drive it low internally
> > > > > >         */
> > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > IOMUXC_GPR14,
> > > > > >
> > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > IOMUXC_GPR14,
> > > > > >
> > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > [Richard Zhu] regmap bits operations should manipulate according bits.
> > > > The BIT(10) and BIT(11) should be touched actually.
> > > >
> > > > > >
> > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > needs to be set true to implement the above code?
> > > > > >
> > > > >
> > > > > Richard,
> > > > >
> > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > removed the above did not resolve my issue. The setting of
> > > > > OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10)
> > > > > instead) but this code already exists in imx6_pcie_enable_ref_clk
> > > > > and is used for IMX8MM per your patch so this is not the issue.
> > > > >
> > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > kernel
> > > > > does) so I don't think this bit does what we think it does (select
> > > > > between internal and ext clk). I think setting it enables clock
> > > > > gating via
> > > > CLKREQ#.
> > > > >
> > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should
> > > > > be moved to the new phy driver for IMX8MM.
> > > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ#
> > > > to be low.
> > > > I will think about that and add this in later v5 patch-set if nobody
> > > > has different concerns.
> > > > Thanks.
> > > [Richard Zhu] Hi Tim:
> > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on
> > your board, right?
> > > " (I have boards that use the only two possible pins for CLKREQ as other
> > features)"
> > >
> > > Did the override configuration of the clkreq# will bring unexpected results
> > for other features on your board?
> > >
> >
> > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
> > and because I2C4_SCL and UART4_RXD are the only two pads that could be
> > pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.
> >
> > Currently your driver only works on my imx8mm-venice-* boards if I add one
> > of the following on boards that don't connect those pads (or if I clear
> > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> >
> > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this
> > code already in the imx6_pcie_enable_ref_clk function to override REF_CLK
> > and drive it low:
> >
> > offset = imx6_pcie_grp_offset(imx6_pcie);
> > /*
> > * Set the over ride low and enabled
> > * make sure that REF_CLK is turned on.
> > */
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> >    0);
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> >
> > So this is already being run and yet my boards still do not work unless I clr
> > IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP
> > downstream driver does:
> > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> >
> > This is why I'm not sure that bit does what you think it does... I feel like that
> > bit enables 'Use CLKREQ# to enable CLK'.
> >
> > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > Please provide correct descriptions for us so we can sort this out.
> >
> [Richard Zhu] Hi Tim:
> The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> I think the two bits descriptions are used to describe the BIT19 and BIT9 together refer to my guess.
> {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> 2'b00: External Reference Clock I/O (for PLL) Disable
> 2'b01: External Reference Clock I/O (for PLL) Enable
> 2'b10: External Reference Clock I/O (for PLL) Disable
> 2'b11: External Reference Clock I/O (for PLL) output is controlled by CLKREQ#
>
> The option1&3 should be forbidden, since the external REF CLK I/O should be enabled on your board and EVK board.
> In the option2&4, the BIT19 should be set to be 1'b1.'
>
> So, regarding my understand, if the CLKREQ# is not pinmuxed in your use case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
>

Richard,

Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for
IMX8MM should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm
pcie support' should have this on top and squashed:
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 7c89bd1a6441..458d54c8e385 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
imx6_pcie *imx6_pcie)
                break;
        case IMX7D:
                break;
-       case IMX8MQ:
        case IMX8MM:
+               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
+               if (ret)
+                       dev_err(dev, "unable to enable pcie_aux clock\n");
+               break;
+       case IMX8MQ:
                ret = clk_prepare_enable(imx6_pcie->pcie_aux);
                if (ret) {
                        dev_err(dev, "unable to enable pcie_aux clock\n");


And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie
standalone phy driver' should have this on top and squashed:
diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
index 317cf61bff37..27ca0b9f1d92 100644
--- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -43,7 +43,7 @@
 #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
 #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
 #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
-#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
+#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)

 struct imx8_pcie_phy {
        u32                     refclk_pad_mode;
@@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
        reset_control_assert(imx8_phy->reset);

        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
-                          IMX8MM_GPR_PCIE_REF_USE_PAD,
-                          imx8_phy->refclk_pad_mode == 1 ?
-                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
+                          0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_AUX_EN,
-                          IMX8MM_GPR_PCIE_AUX_EN);
+                          imx8_phy->refclk_pad_mode ==
IMX8_PCIE_REFCLK_PAD_INPUT ?
+                          IMX8MM_GPR_PCIE_AUX_EN : 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_POWER_OFF, 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
@@ -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)

        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_REF_CLK_SEL,
-                          imx8_phy->refclk_pad_mode == 1 ?
+                          imx8_phy->refclk_pad_mode ==
IMX8_PCIE_REFCLK_PAD_INPUT ?
                           IMX8MM_GPR_PCIE_REF_CLK_EXT :
                           IMX8MM_GPR_PCIE_REF_CLK_PLL);
        usleep_range(100, 200);

I tested this and it works both on imx8mm-evk and imx8mm-venice-*
which both have external clkgen.

However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE for
the case where CLKREQ# is connected and thus should be used so I think
we need to add a property for that to define if CLKREQ# is hooked up
or not. I tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as
expected that worked on the imx8mm-evk which hooks up CLKREQ# but not
imx8mm-venice which does not hook up CLKREQ#.

What do you think about adding a property for this?

Best regards,

Tim

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Tuesday, October 26, 2021 1:15 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > Snipped...
> > >
> > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > PCIe
> > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > features).
> > > > > > > > > >
> > > > > > > > > > Similarly you will find on the imx8mm-evk if you comment
> > > > > > > > > > out the CLKREQ (which isn't required) the imx8mmevk will
> > > > > > > > > > end up hanging like my
> > > > > > > > boards:
> > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > > > should be
> > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > device to request the
> > > > > > > > REF clock be available(active low).
> > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > i.MX8MM EVK
> > > > > board.
> > > > > > > > >
> > > > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > > > running if there is
> > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > >
> > > > > > > >
> > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > disable the REFCLK when not needed for power savings so it
> > > > > > > > would seem optional to implement that and if not implemented
> > > > > > > > should be left unconnected on
> > > > > the card.
> > > > > > > >
> > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > signal is
> > > > > mandatory required.
> > > > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > > > drain), bi-directional, and might be driven low/high by RC or
> > > > > > > EP automatically if
> > > > > L1ss modes are enabled.
> > > > > > > You can make reference to the
> > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> > the
> > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > 4.0 Version 1.0".
> > > > > > >
> > > > > >
> > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > management. Many boards with a PCI host controller do not
> > > > > > support this.
> > > > [Richard Zhu] Okay, understood.
> > > >
> > > > > >
> > > > > > > > > > diff --git
> > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > >
> > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > +/*
> > > > > > > > > >
> > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > +*/
> > > > > > > > > >
> > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > 0x41
> > > > > > > > > >                 >;
> > > > > > > > > >         };
> > > > > > > > > >
> > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > NXP's kernel which differs from your driver in that the
> > > > > > > > > > PCIe PHY is not abstracted to its own driver so I think
> > > > > > > > > > this has something to do with the order in which the phy
> > > > > > > > > > is reset or
> > > > initialized?
> > > > > > > > > > The configuration of
> > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > > > level up the HW
> > > > > > > > compatibility.
> > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > board although the
> > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > > > recommended
> > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > So I drop this method in this series.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Sorry, I don't understand what you are saying here. Is there
> > > > > > > > a change you are going to make to v4 that will make this
> > > > > > > > work for the evk and my boards? What is that change exactly?
> > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > forced to be low in NXP local BSP kernel. I guess this might
> > > > > > > be the reason why your
> > > > > board works.
> > > > > > >
> > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > CLKREQ# to
> > > > > be low.
> > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > >
> > > > > >
> > > > > > Ok, that makes sense. Those bits are not explained well in the
> > > > > > IMX8MMRM. As my board's external REFCLK is always enabled that
> > > > > > must gate the clock internally to the host controller block.
> > > > > >
> > > > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > > > >
> > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > > > >
> > > > > >        /*
> > > > > >         * for boards that do not connect CLKREQ#,
> > > > > >         * override CLKREQ# and drive it low internally
> > > > > >         */
> > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > IOMUXC_GPR14,
> > > > > >
> > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > IOMUXC_GPR14,
> > > > > >
> > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > [Richard Zhu] regmap bits operations should manipulate according bits.
> > > > The BIT(10) and BIT(11) should be touched actually.
> > > >
> > > > > >
> > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > needs to be set true to implement the above code?
> > > > > >
> > > > >
> > > > > Richard,
> > > > >
> > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > removed the above did not resolve my issue. The setting of
> > > > > OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10)
> > > > > instead) but this code already exists in imx6_pcie_enable_ref_clk
> > > > > and is used for IMX8MM per your patch so this is not the issue.
> > > > >
> > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > kernel
> > > > > does) so I don't think this bit does what we think it does (select
> > > > > between internal and ext clk). I think setting it enables clock
> > > > > gating via
> > > > CLKREQ#.
> > > > >
> > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should
> > > > > be moved to the new phy driver for IMX8MM.
> > > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ#
> > > > to be low.
> > > > I will think about that and add this in later v5 patch-set if nobody
> > > > has different concerns.
> > > > Thanks.
> > > [Richard Zhu] Hi Tim:
> > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on
> > your board, right?
> > > " (I have boards that use the only two possible pins for CLKREQ as other
> > features)"
> > >
> > > Did the override configuration of the clkreq# will bring unexpected results
> > for other features on your board?
> > >
> >
> > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
> > and because I2C4_SCL and UART4_RXD are the only two pads that could be
> > pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.
> >
> > Currently your driver only works on my imx8mm-venice-* boards if I add one
> > of the following on boards that don't connect those pads (or if I clear
> > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> >
> > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this
> > code already in the imx6_pcie_enable_ref_clk function to override REF_CLK
> > and drive it low:
> >
> > offset = imx6_pcie_grp_offset(imx6_pcie);
> > /*
> > * Set the over ride low and enabled
> > * make sure that REF_CLK is turned on.
> > */
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> >    0);
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> >
> > So this is already being run and yet my boards still do not work unless I clr
> > IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP
> > downstream driver does:
> > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> >
> > This is why I'm not sure that bit does what you think it does... I feel like that
> > bit enables 'Use CLKREQ# to enable CLK'.
> >
> > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > Please provide correct descriptions for us so we can sort this out.
> >
> [Richard Zhu] Hi Tim:
> The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> I think the two bits descriptions are used to describe the BIT19 and BIT9 together refer to my guess.
> {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> 2'b00: External Reference Clock I/O (for PLL) Disable
> 2'b01: External Reference Clock I/O (for PLL) Enable
> 2'b10: External Reference Clock I/O (for PLL) Disable
> 2'b11: External Reference Clock I/O (for PLL) output is controlled by CLKREQ#
>
> The option1&3 should be forbidden, since the external REF CLK I/O should be enabled on your board and EVK board.
> In the option2&4, the BIT19 should be set to be 1'b1.'
>
> So, regarding my understand, if the CLKREQ# is not pinmuxed in your use case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
>

Richard,

Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for
IMX8MM should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm
pcie support' should have this on top and squashed:
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 7c89bd1a6441..458d54c8e385 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
imx6_pcie *imx6_pcie)
                break;
        case IMX7D:
                break;
-       case IMX8MQ:
        case IMX8MM:
+               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
+               if (ret)
+                       dev_err(dev, "unable to enable pcie_aux clock\n");
+               break;
+       case IMX8MQ:
                ret = clk_prepare_enable(imx6_pcie->pcie_aux);
                if (ret) {
                        dev_err(dev, "unable to enable pcie_aux clock\n");


And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie
standalone phy driver' should have this on top and squashed:
diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
index 317cf61bff37..27ca0b9f1d92 100644
--- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -43,7 +43,7 @@
 #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
 #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
 #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
-#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
+#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)

 struct imx8_pcie_phy {
        u32                     refclk_pad_mode;
@@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
        reset_control_assert(imx8_phy->reset);

        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
-                          IMX8MM_GPR_PCIE_REF_USE_PAD,
-                          imx8_phy->refclk_pad_mode == 1 ?
-                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
+                          0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_AUX_EN,
-                          IMX8MM_GPR_PCIE_AUX_EN);
+                          imx8_phy->refclk_pad_mode ==
IMX8_PCIE_REFCLK_PAD_INPUT ?
+                          IMX8MM_GPR_PCIE_AUX_EN : 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_POWER_OFF, 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
@@ -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)

        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_REF_CLK_SEL,
-                          imx8_phy->refclk_pad_mode == 1 ?
+                          imx8_phy->refclk_pad_mode ==
IMX8_PCIE_REFCLK_PAD_INPUT ?
                           IMX8MM_GPR_PCIE_REF_CLK_EXT :
                           IMX8MM_GPR_PCIE_REF_CLK_PLL);
        usleep_range(100, 200);

I tested this and it works both on imx8mm-evk and imx8mm-venice-*
which both have external clkgen.

However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE for
the case where CLKREQ# is connected and thus should be used so I think
we need to add a property for that to define if CLKREQ# is hooked up
or not. I tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as
expected that worked on the imx8mm-evk which hooks up CLKREQ# but not
imx8mm-venice which does not hook up CLKREQ#.

What do you think about adding a property for this?

Best regards,

Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Tuesday, October 26, 2021 1:15 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > Snipped...
> > >
> > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > PCIe
> > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > features).
> > > > > > > > > >
> > > > > > > > > > Similarly you will find on the imx8mm-evk if you comment
> > > > > > > > > > out the CLKREQ (which isn't required) the imx8mmevk will
> > > > > > > > > > end up hanging like my
> > > > > > > > boards:
> > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and
> > > > > > > > > should be
> > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > device to request the
> > > > > > > > REF clock be available(active low).
> > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > i.MX8MM EVK
> > > > > board.
> > > > > > > > >
> > > > > > > > > Anyway, I think the external OSC circuit should be always
> > > > > > > > > running if there is
> > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > >
> > > > > > > >
> > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > disable the REFCLK when not needed for power savings so it
> > > > > > > > would seem optional to implement that and if not implemented
> > > > > > > > should be left unconnected on
> > > > > the card.
> > > > > > > >
> > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > signal is
> > > > > mandatory required.
> > > > > > > Especially for the L1ss usages. This signal would be OD(open
> > > > > > > drain), bi-directional, and might be driven low/high by RC or
> > > > > > > EP automatically if
> > > > > L1ss modes are enabled.
> > > > > > > You can make reference to the
> > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or
> > the
> > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > 4.0 Version 1.0".
> > > > > > >
> > > > > >
> > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > management. Many boards with a PCI host controller do not
> > > > > > support this.
> > > > [Richard Zhu] Okay, understood.
> > > >
> > > > > >
> > > > > > > > > > diff --git
> > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > >
> > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > +/*
> > > > > > > > > >
> > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > +*/
> > > > > > > > > >
> > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > 0x41
> > > > > > > > > >                 >;
> > > > > > > > > >         };
> > > > > > > > > >
> > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > NXP's kernel which differs from your driver in that the
> > > > > > > > > > PCIe PHY is not abstracted to its own driver so I think
> > > > > > > > > > this has something to do with the order in which the phy
> > > > > > > > > > is reset or
> > > > initialized?
> > > > > > > > > > The configuration of
> > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked.
> > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to
> > > > > > > > > level up the HW
> > > > > > > > compatibility.
> > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > board although the
> > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > This method is a little rude and violate the SPEC, and not
> > > > > > > > > recommended
> > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > So I drop this method in this series.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Sorry, I don't understand what you are saying here. Is there
> > > > > > > > a change you are going to make to v4 that will make this
> > > > > > > > work for the evk and my boards? What is that change exactly?
> > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > forced to be low in NXP local BSP kernel. I guess this might
> > > > > > > be the reason why your
> > > > > board works.
> > > > > > >
> > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > CLKREQ# to
> > > > > be low.
> > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > >
> > > > > >
> > > > > > Ok, that makes sense. Those bits are not explained well in the
> > > > > > IMX8MMRM. As my board's external REFCLK is always enabled that
> > > > > > must gate the clock internally to the host controller block.
> > > > > >
> > > > > > I can confirm that asserting those GPR14 bits does resolve my issue:
> > > > > >
> > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN     BIT(10)
> > > > > >
> > > > > >        /*
> > > > > >         * for boards that do not connect CLKREQ#,
> > > > > >         * override CLKREQ# and drive it low internally
> > > > > >         */
> > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > IOMUXC_GPR14,
> > > > > >
> > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > IOMUXC_GPR14,
> > > > > >
> > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > [Richard Zhu] regmap bits operations should manipulate according bits.
> > > > The BIT(10) and BIT(11) should be touched actually.
> > > >
> > > > > >
> > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > needs to be set true to implement the above code?
> > > > > >
> > > > >
> > > > > Richard,
> > > > >
> > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > removed the above did not resolve my issue. The setting of
> > > > > OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10)
> > > > > instead) but this code already exists in imx6_pcie_enable_ref_clk
> > > > > and is used for IMX8MM per your patch so this is not the issue.
> > > > >
> > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > kernel
> > > > > does) so I don't think this bit does what we think it does (select
> > > > > between internal and ext clk). I think setting it enables clock
> > > > > gating via
> > > > CLKREQ#.
> > > > >
> > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should
> > > > > be moved to the new phy driver for IMX8MM.
> > > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ#
> > > > to be low.
> > > > I will think about that and add this in later v5 patch-set if nobody
> > > > has different concerns.
> > > > Thanks.
> > > [Richard Zhu] Hi Tim:
> > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on
> > your board, right?
> > > " (I have boards that use the only two possible pins for CLKREQ as other
> > features)"
> > >
> > > Did the override configuration of the clkreq# will bring unexpected results
> > for other features on your board?
> > >
> >
> > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4
> > and because I2C4_SCL and UART4_RXD are the only two pads that could be
> > pinmuxed for CLKREQ# I can't use the workaround of pin muxing it.
> >
> > Currently your driver only works on my imx8mm-venice-* boards if I add one
> > of the following on boards that don't connect those pads (or if I clear
> > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> >
> > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this
> > code already in the imx6_pcie_enable_ref_clk function to override REF_CLK
> > and drive it low:
> >
> > offset = imx6_pcie_grp_offset(imx6_pcie);
> > /*
> > * Set the over ride low and enabled
> > * make sure that REF_CLK is turned on.
> > */
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> >    0);
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> >
> > So this is already being run and yet my boards still do not work unless I clr
> > IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP
> > downstream driver does:
> > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> >
> > This is why I'm not sure that bit does what you think it does... I feel like that
> > bit enables 'Use CLKREQ# to enable CLK'.
> >
> > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > Please provide correct descriptions for us so we can sort this out.
> >
> [Richard Zhu] Hi Tim:
> The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> I think the two bits descriptions are used to describe the BIT19 and BIT9 together refer to my guess.
> {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> 2'b00: External Reference Clock I/O (for PLL) Disable
> 2'b01: External Reference Clock I/O (for PLL) Enable
> 2'b10: External Reference Clock I/O (for PLL) Disable
> 2'b11: External Reference Clock I/O (for PLL) output is controlled by CLKREQ#
>
> The option1&3 should be forbidden, since the external REF CLK I/O should be enabled on your board and EVK board.
> In the option2&4, the BIT19 should be set to be 1'b1.'
>
> So, regarding my understand, if the CLKREQ# is not pinmuxed in your use case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
>

Richard,

Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for
IMX8MM should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm
pcie support' should have this on top and squashed:
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 7c89bd1a6441..458d54c8e385 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
imx6_pcie *imx6_pcie)
                break;
        case IMX7D:
                break;
-       case IMX8MQ:
        case IMX8MM:
+               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
+               if (ret)
+                       dev_err(dev, "unable to enable pcie_aux clock\n");
+               break;
+       case IMX8MQ:
                ret = clk_prepare_enable(imx6_pcie->pcie_aux);
                if (ret) {
                        dev_err(dev, "unable to enable pcie_aux clock\n");


And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie
standalone phy driver' should have this on top and squashed:
diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
index 317cf61bff37..27ca0b9f1d92 100644
--- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -43,7 +43,7 @@
 #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
 #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
 #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
-#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
+#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)

 struct imx8_pcie_phy {
        u32                     refclk_pad_mode;
@@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
        reset_control_assert(imx8_phy->reset);

        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
-                          IMX8MM_GPR_PCIE_REF_USE_PAD,
-                          imx8_phy->refclk_pad_mode == 1 ?
-                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
+                          0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_AUX_EN,
-                          IMX8MM_GPR_PCIE_AUX_EN);
+                          imx8_phy->refclk_pad_mode ==
IMX8_PCIE_REFCLK_PAD_INPUT ?
+                          IMX8MM_GPR_PCIE_AUX_EN : 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_POWER_OFF, 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
@@ -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)

        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_REF_CLK_SEL,
-                          imx8_phy->refclk_pad_mode == 1 ?
+                          imx8_phy->refclk_pad_mode ==
IMX8_PCIE_REFCLK_PAD_INPUT ?
                           IMX8MM_GPR_PCIE_REF_CLK_EXT :
                           IMX8MM_GPR_PCIE_REF_CLK_PLL);
        usleep_range(100, 200);

I tested this and it works both on imx8mm-evk and imx8mm-venice-*
which both have external clkgen.

However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE for
the case where CLKREQ# is connected and thus should be used so I think
we need to add a property for that to define if CLKREQ# is hooked up
or not. I tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as
expected that worked on the imx8mm-evk which hooks up CLKREQ# but not
imx8mm-venice which does not hook up CLKREQ#.

What do you think about adding a property for this?

Best regards,

Tim

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Wednesday, October 27, 2021 12:06 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > pcie support
> > >
> > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > Snipped...
> > > >
> > > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > PCIe
> > > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > > features).
> > > > > > > > > > >
> > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > comment out the CLKREQ (which isn't required) the
> > > > > > > > > > > imx8mmevk will end up hanging like my
> > > > > > > > > boards:
> > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required,
> > > > > > > > > > and should be
> > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > > device to request the
> > > > > > > > > REF clock be available(active low).
> > > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > > i.MX8MM EVK
> > > > > > board.
> > > > > > > > > >
> > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > always running if there is
> > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > > disable the REFCLK when not needed for power savings so
> > > > > > > > > it would seem optional to implement that and if not
> > > > > > > > > implemented should be left unconnected on
> > > > > > the card.
> > > > > > > > >
> > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > > signal is
> > > > > > mandatory required.
> > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > low/high by RC or EP automatically if
> > > > > > L1ss modes are enabled.
> > > > > > > > You can make reference to the
> > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> or
> > > the
> > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > > 4.0 Version 1.0".
> > > > > > > >
> > > > > > >
> > > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > > management. Many boards with a PCI host controller do not
> > > > > > > support this.
> > > > > [Richard Zhu] Okay, understood.
> > > > >
> > > > > > >
> > > > > > > > > > > diff --git
> > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > >
> > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > +/*
> > > > > > > > > > >
> > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > > +*/
> > > > > > > > > > >
> > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > 0x41
> > > > > > > > > > >                 >;
> > > > > > > > > > >         };
> > > > > > > > > > >
> > > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > > NXP's kernel which differs from your driver in that
> > > > > > > > > > > the PCIe PHY is not abstracted to its own driver so
> > > > > > > > > > > I think this has something to do with the order in
> > > > > > > > > > > which the phy is reset or
> > > > > initialized?
> > > > > > > > > > > The configuration of
> > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be
> masked.
> > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ#
> > > > > > > > > > low to level up the HW
> > > > > > > > > compatibility.
> > > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > > board although the
> > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > This method is a little rude and violate the SPEC, and
> > > > > > > > > > not recommended
> > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > So I drop this method in this series.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Sorry, I don't understand what you are saying here. Is
> > > > > > > > > there a change you are going to make to v4 that will
> > > > > > > > > make this work for the evk and my boards? What is that change
> exactly?
> > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > > forced to be low in NXP local BSP kernel. I guess this
> > > > > > > > might be the reason why your
> > > > > > board works.
> > > > > > > >
> > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > > CLKREQ# to
> > > > > > be low.
> > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > >
> > > > > > >
> > > > > > > Ok, that makes sense. Those bits are not explained well in
> > > > > > > the IMX8MMRM. As my board's external REFCLK is always
> > > > > > > enabled that must gate the clock internally to the host controller
> block.
> > > > > > >
> > > > > > > I can confirm that asserting those GPR14 bits does resolve my
> issue:
> > > > > > >
> > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> BIT(10)
> > > > > > >
> > > > > > >        /*
> > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > >         */
> > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > IOMUXC_GPR14,
> > > > > > >
> > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > IOMUXC_GPR14,
> > > > > > >
> > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > [Richard Zhu] regmap bits operations should manipulate according
> bits.
> > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > >
> > > > > > >
> > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > > needs to be set true to implement the above code?
> > > > > > >
> > > > > >
> > > > > > Richard,
> > > > > >
> > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > > removed the above did not resolve my issue. The setting of
> > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but
> > > > > > BIT(10)
> > > > > > instead) but this code already exists in
> > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch
> so this is not the issue.
> > > > > >
> > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > > kernel
> > > > > > does) so I don't think this bit does what we think it does
> > > > > > (select between internal and ext clk). I think setting it
> > > > > > enables clock gating via
> > > > > CLKREQ#.
> > > > > >
> > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic
> > > > > > should be moved to the new phy driver for IMX8MM.
> > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > CLKREQ# to be low.
> > > > > I will think about that and add this in later v5 patch-set if
> > > > > nobody has different concerns.
> > > > > Thanks.
> > > > [Richard Zhu] Hi Tim:
> > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe
> > > > on
> > > your board, right?
> > > > " (I have boards that use the only two possible pins for CLKREQ as
> > > > other
> > > features)"
> > > >
> > > > Did the override configuration of the clkreq# will bring
> > > > unexpected results
> > > for other features on your board?
> > > >
> > >
> > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and
> > > UART4 and because I2C4_SCL and UART4_RXD are the only two pads that
> > > could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing
> it.
> > >
> > > Currently your driver only works on my imx8mm-venice-* boards if I
> > > add one of the following on boards that don't connect those pads (or
> > > if I clear
> > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > >
> > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > enable this code already in the imx6_pcie_enable_ref_clk function to
> > > override REF_CLK and drive it low:
> > >
> > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > /*
> > > * Set the over ride low and enabled
> > > * make sure that REF_CLK is turned on.
> > > */
> > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > >    0);
> > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > >
> > > So this is already being run and yet my boards still do not work
> > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
> > > NXP downstream driver does:
> > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > >
> > > This is why I'm not sure that bit does what you think it does... I
> > > feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > >
> > > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > > Please provide correct descriptions for us so we can sort this out.
> > >
> > [Richard Zhu] Hi Tim:
> > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> > I think the two bits descriptions are used to describe the BIT19 and BIT9
> together refer to my guess.
> > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > 2'b00: External Reference Clock I/O (for PLL) Disable
> > 2'b01: External Reference Clock I/O (for PLL) Enable
> > 2'b10: External Reference Clock I/O (for PLL) Disable
> > 2'b11: External Reference Clock I/O (for PLL) output is controlled by
> > CLKREQ#
> >
> > The option1&3 should be forbidden, since the external REF CLK I/O should
> be enabled on your board and EVK board.
> > In the option2&4, the BIT19 should be set to be 1'b1.'
> >
> > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use
> case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> >
> 
> Richard,
> 
> Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM
> should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support'
> should have this on top and squashed:
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 7c89bd1a6441..458d54c8e385 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> imx6_pcie *imx6_pcie)
>                 break;
>         case IMX7D:
>                 break;
> -       case IMX8MQ:
>         case IMX8MM:
> +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> +               if (ret)
> +                       dev_err(dev, "unable to enable pcie_aux
> clock\n");
> +               break;
> +       case IMX8MQ:
>                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
>                 if (ret) {
>                         dev_err(dev, "unable to enable pcie_aux
> clock\n");
> 
[Richard Zhu] Sorry, I might don't understand what's meaning of the changes.
What're the differences between before and after the changes?

> 
> And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy
> driver' should have this on top and squashed:
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> index 317cf61bff37..27ca0b9f1d92 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -43,7 +43,7 @@
>  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
>  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
>  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> 
>  struct imx8_pcie_phy {
>         u32                     refclk_pad_mode;
> @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
>         reset_control_assert(imx8_phy->reset);
> 
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> -                          imx8_phy->refclk_pad_mode == 1 ?
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> +                          0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_AUX_EN,
> -                          IMX8MM_GPR_PCIE_AUX_EN);
> +                          imx8_phy->refclk_pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
> +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@
> -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> 
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_REF_CLK_SEL,
> -                          imx8_phy->refclk_pad_mode == 1 ?
> +                          imx8_phy->refclk_pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
>                            IMX8MM_GPR_PCIE_REF_CLK_EXT :
>                            IMX8MM_GPR_PCIE_REF_CLK_PLL);
>         usleep_range(100, 200);
> 
> I tested this and it works both on imx8mm-evk and imx8mm-venice-* which
> both have external clkgen.
> 
> However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> for the case where CLKREQ# is connected and thus should be used so I think
> we need to add a property for that to define if CLKREQ# is hooked up or not. I
> tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected
> that worked on the imx8mm-evk which hooks up CLKREQ# but not
> imx8mm-venice which does not hook up CLKREQ#.
> 
> What do you think about adding a property for this?
[Richard Zhu] First of all, thanks a lot for your help to figure out the details.
Agree with your proposal.
One optional property "fsl,clkreq-unsupported" would be added for the CLKREQ# not hooked case later.

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
index 097ba2a28fb4..2264452924cc 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
@@ -58,6 +58,11 @@ properties:
     $ref: /schemas/types.yaml#/definitions/uint32
     default: 0

+  fsl,clkreq-unsupported:
+    type: boolean
+    description: A boolean property whoes presence indicates the CLKREQ#
+      signal isn't supported in the HW board design (optional required).
+

diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
index 07eea39283ed..4b4402eaddcc 100644
--- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -43,7 +43,7 @@
 #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
 #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
 #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
-#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
+#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)

 struct imx8_pcie_phy {
        void __iomem            *base;
@@ -54,6 +54,7 @@ struct imx8_pcie_phy {
        u32                     refclk_pad_mode;
        u32                     tx_deemph_gen1;
        u32                     tx_deemph_gen2;
+       bool                    clkreq_unused;
 };

 static int imx8_pcie_phy_init(struct phy *phy)
@@ -65,13 +66,15 @@ static int imx8_pcie_phy_init(struct phy *phy)
        reset_control_assert(imx8_phy->reset);

        pad_mode = imx8_phy->refclk_pad_mode;
+       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't hooked */
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
-                          IMX8MM_GPR_PCIE_REF_USE_PAD,
-                          pad_mode == IMX8MM_GPR_PCIE_REF_USE_PAD ?
-                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
+                          imx8_phy->clkreq_unused ?
+                          0 : IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_AUX_EN,
-                          IMX8MM_GPR_PCIE_AUX_EN);
+                          pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ?
+                          IMX8MM_GPR_PCIE_AUX_EN : 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_POWER_OFF, 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
@@ -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct platform_device *pdev)
                                 &imx8_phy->tx_deemph_gen2))
                imx8_phy->tx_deemph_gen2 = 0;

+       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
+               imx8_phy->clkreq_unused = true;
+       else
+               imx8_phy->clkreq_unused = false;
+
        imx8_phy->clk = devm_clk_get(dev, "ref");
        if (IS_ERR(imx8_phy->clk)) {
                dev_err(dev, "failed to get imx pcie phy clock\n");

Best Regards
Richard Zhu

> 
> Best regards,
> 
> Tim

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Wednesday, October 27, 2021 12:06 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > pcie support
> > >
> > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > Snipped...
> > > >
> > > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > PCIe
> > > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > > features).
> > > > > > > > > > >
> > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > comment out the CLKREQ (which isn't required) the
> > > > > > > > > > > imx8mmevk will end up hanging like my
> > > > > > > > > boards:
> > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required,
> > > > > > > > > > and should be
> > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > > device to request the
> > > > > > > > > REF clock be available(active low).
> > > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > > i.MX8MM EVK
> > > > > > board.
> > > > > > > > > >
> > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > always running if there is
> > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > > disable the REFCLK when not needed for power savings so
> > > > > > > > > it would seem optional to implement that and if not
> > > > > > > > > implemented should be left unconnected on
> > > > > > the card.
> > > > > > > > >
> > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > > signal is
> > > > > > mandatory required.
> > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > low/high by RC or EP automatically if
> > > > > > L1ss modes are enabled.
> > > > > > > > You can make reference to the
> > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> or
> > > the
> > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > > 4.0 Version 1.0".
> > > > > > > >
> > > > > > >
> > > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > > management. Many boards with a PCI host controller do not
> > > > > > > support this.
> > > > > [Richard Zhu] Okay, understood.
> > > > >
> > > > > > >
> > > > > > > > > > > diff --git
> > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > >
> > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > +/*
> > > > > > > > > > >
> > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > > +*/
> > > > > > > > > > >
> > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > 0x41
> > > > > > > > > > >                 >;
> > > > > > > > > > >         };
> > > > > > > > > > >
> > > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > > NXP's kernel which differs from your driver in that
> > > > > > > > > > > the PCIe PHY is not abstracted to its own driver so
> > > > > > > > > > > I think this has something to do with the order in
> > > > > > > > > > > which the phy is reset or
> > > > > initialized?
> > > > > > > > > > > The configuration of
> > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be
> masked.
> > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ#
> > > > > > > > > > low to level up the HW
> > > > > > > > > compatibility.
> > > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > > board although the
> > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > This method is a little rude and violate the SPEC, and
> > > > > > > > > > not recommended
> > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > So I drop this method in this series.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Sorry, I don't understand what you are saying here. Is
> > > > > > > > > there a change you are going to make to v4 that will
> > > > > > > > > make this work for the evk and my boards? What is that change
> exactly?
> > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > > forced to be low in NXP local BSP kernel. I guess this
> > > > > > > > might be the reason why your
> > > > > > board works.
> > > > > > > >
> > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > > CLKREQ# to
> > > > > > be low.
> > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > >
> > > > > > >
> > > > > > > Ok, that makes sense. Those bits are not explained well in
> > > > > > > the IMX8MMRM. As my board's external REFCLK is always
> > > > > > > enabled that must gate the clock internally to the host controller
> block.
> > > > > > >
> > > > > > > I can confirm that asserting those GPR14 bits does resolve my
> issue:
> > > > > > >
> > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> BIT(10)
> > > > > > >
> > > > > > >        /*
> > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > >         */
> > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > IOMUXC_GPR14,
> > > > > > >
> > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > IOMUXC_GPR14,
> > > > > > >
> > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > [Richard Zhu] regmap bits operations should manipulate according
> bits.
> > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > >
> > > > > > >
> > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > > needs to be set true to implement the above code?
> > > > > > >
> > > > > >
> > > > > > Richard,
> > > > > >
> > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > > removed the above did not resolve my issue. The setting of
> > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but
> > > > > > BIT(10)
> > > > > > instead) but this code already exists in
> > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch
> so this is not the issue.
> > > > > >
> > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > > kernel
> > > > > > does) so I don't think this bit does what we think it does
> > > > > > (select between internal and ext clk). I think setting it
> > > > > > enables clock gating via
> > > > > CLKREQ#.
> > > > > >
> > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic
> > > > > > should be moved to the new phy driver for IMX8MM.
> > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > CLKREQ# to be low.
> > > > > I will think about that and add this in later v5 patch-set if
> > > > > nobody has different concerns.
> > > > > Thanks.
> > > > [Richard Zhu] Hi Tim:
> > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe
> > > > on
> > > your board, right?
> > > > " (I have boards that use the only two possible pins for CLKREQ as
> > > > other
> > > features)"
> > > >
> > > > Did the override configuration of the clkreq# will bring
> > > > unexpected results
> > > for other features on your board?
> > > >
> > >
> > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and
> > > UART4 and because I2C4_SCL and UART4_RXD are the only two pads that
> > > could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing
> it.
> > >
> > > Currently your driver only works on my imx8mm-venice-* boards if I
> > > add one of the following on boards that don't connect those pads (or
> > > if I clear
> > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > >
> > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > enable this code already in the imx6_pcie_enable_ref_clk function to
> > > override REF_CLK and drive it low:
> > >
> > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > /*
> > > * Set the over ride low and enabled
> > > * make sure that REF_CLK is turned on.
> > > */
> > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > >    0);
> > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > >
> > > So this is already being run and yet my boards still do not work
> > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
> > > NXP downstream driver does:
> > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > >
> > > This is why I'm not sure that bit does what you think it does... I
> > > feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > >
> > > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > > Please provide correct descriptions for us so we can sort this out.
> > >
> > [Richard Zhu] Hi Tim:
> > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> > I think the two bits descriptions are used to describe the BIT19 and BIT9
> together refer to my guess.
> > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > 2'b00: External Reference Clock I/O (for PLL) Disable
> > 2'b01: External Reference Clock I/O (for PLL) Enable
> > 2'b10: External Reference Clock I/O (for PLL) Disable
> > 2'b11: External Reference Clock I/O (for PLL) output is controlled by
> > CLKREQ#
> >
> > The option1&3 should be forbidden, since the external REF CLK I/O should
> be enabled on your board and EVK board.
> > In the option2&4, the BIT19 should be set to be 1'b1.'
> >
> > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use
> case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> >
> 
> Richard,
> 
> Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM
> should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support'
> should have this on top and squashed:
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 7c89bd1a6441..458d54c8e385 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> imx6_pcie *imx6_pcie)
>                 break;
>         case IMX7D:
>                 break;
> -       case IMX8MQ:
>         case IMX8MM:
> +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> +               if (ret)
> +                       dev_err(dev, "unable to enable pcie_aux
> clock\n");
> +               break;
> +       case IMX8MQ:
>                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
>                 if (ret) {
>                         dev_err(dev, "unable to enable pcie_aux
> clock\n");
> 
[Richard Zhu] Sorry, I might don't understand what's meaning of the changes.
What're the differences between before and after the changes?

> 
> And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy
> driver' should have this on top and squashed:
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> index 317cf61bff37..27ca0b9f1d92 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -43,7 +43,7 @@
>  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
>  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
>  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> 
>  struct imx8_pcie_phy {
>         u32                     refclk_pad_mode;
> @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
>         reset_control_assert(imx8_phy->reset);
> 
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> -                          imx8_phy->refclk_pad_mode == 1 ?
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> +                          0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_AUX_EN,
> -                          IMX8MM_GPR_PCIE_AUX_EN);
> +                          imx8_phy->refclk_pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
> +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@
> -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> 
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_REF_CLK_SEL,
> -                          imx8_phy->refclk_pad_mode == 1 ?
> +                          imx8_phy->refclk_pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
>                            IMX8MM_GPR_PCIE_REF_CLK_EXT :
>                            IMX8MM_GPR_PCIE_REF_CLK_PLL);
>         usleep_range(100, 200);
> 
> I tested this and it works both on imx8mm-evk and imx8mm-venice-* which
> both have external clkgen.
> 
> However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> for the case where CLKREQ# is connected and thus should be used so I think
> we need to add a property for that to define if CLKREQ# is hooked up or not. I
> tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected
> that worked on the imx8mm-evk which hooks up CLKREQ# but not
> imx8mm-venice which does not hook up CLKREQ#.
> 
> What do you think about adding a property for this?
[Richard Zhu] First of all, thanks a lot for your help to figure out the details.
Agree with your proposal.
One optional property "fsl,clkreq-unsupported" would be added for the CLKREQ# not hooked case later.

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
index 097ba2a28fb4..2264452924cc 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
@@ -58,6 +58,11 @@ properties:
     $ref: /schemas/types.yaml#/definitions/uint32
     default: 0

+  fsl,clkreq-unsupported:
+    type: boolean
+    description: A boolean property whoes presence indicates the CLKREQ#
+      signal isn't supported in the HW board design (optional required).
+

diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
index 07eea39283ed..4b4402eaddcc 100644
--- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -43,7 +43,7 @@
 #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
 #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
 #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
-#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
+#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)

 struct imx8_pcie_phy {
        void __iomem            *base;
@@ -54,6 +54,7 @@ struct imx8_pcie_phy {
        u32                     refclk_pad_mode;
        u32                     tx_deemph_gen1;
        u32                     tx_deemph_gen2;
+       bool                    clkreq_unused;
 };

 static int imx8_pcie_phy_init(struct phy *phy)
@@ -65,13 +66,15 @@ static int imx8_pcie_phy_init(struct phy *phy)
        reset_control_assert(imx8_phy->reset);

        pad_mode = imx8_phy->refclk_pad_mode;
+       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't hooked */
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
-                          IMX8MM_GPR_PCIE_REF_USE_PAD,
-                          pad_mode == IMX8MM_GPR_PCIE_REF_USE_PAD ?
-                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
+                          imx8_phy->clkreq_unused ?
+                          0 : IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_AUX_EN,
-                          IMX8MM_GPR_PCIE_AUX_EN);
+                          pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ?
+                          IMX8MM_GPR_PCIE_AUX_EN : 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_POWER_OFF, 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
@@ -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct platform_device *pdev)
                                 &imx8_phy->tx_deemph_gen2))
                imx8_phy->tx_deemph_gen2 = 0;

+       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
+               imx8_phy->clkreq_unused = true;
+       else
+               imx8_phy->clkreq_unused = false;
+
        imx8_phy->clk = devm_clk_get(dev, "ref");
        if (IS_ERR(imx8_phy->clk)) {
                dev_err(dev, "failed to get imx pcie phy clock\n");

Best Regards
Richard Zhu

> 
> Best regards,
> 
> Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Wednesday, October 27, 2021 12:06 AM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > pcie support
> > >
> > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > Snipped...
> > > >
> > > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > PCIe
> > > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > > features).
> > > > > > > > > > >
> > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > comment out the CLKREQ (which isn't required) the
> > > > > > > > > > > imx8mmevk will end up hanging like my
> > > > > > > > > boards:
> > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required,
> > > > > > > > > > and should be
> > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > > device to request the
> > > > > > > > > REF clock be available(active low).
> > > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > > i.MX8MM EVK
> > > > > > board.
> > > > > > > > > >
> > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > always running if there is
> > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > > disable the REFCLK when not needed for power savings so
> > > > > > > > > it would seem optional to implement that and if not
> > > > > > > > > implemented should be left unconnected on
> > > > > > the card.
> > > > > > > > >
> > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > > signal is
> > > > > > mandatory required.
> > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > low/high by RC or EP automatically if
> > > > > > L1ss modes are enabled.
> > > > > > > > You can make reference to the
> > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> or
> > > the
> > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > > 4.0 Version 1.0".
> > > > > > > >
> > > > > > >
> > > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > > management. Many boards with a PCI host controller do not
> > > > > > > support this.
> > > > > [Richard Zhu] Okay, understood.
> > > > >
> > > > > > >
> > > > > > > > > > > diff --git
> > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > >
> > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > +/*
> > > > > > > > > > >
> > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > > +*/
> > > > > > > > > > >
> > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > 0x41
> > > > > > > > > > >                 >;
> > > > > > > > > > >         };
> > > > > > > > > > >
> > > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > > NXP's kernel which differs from your driver in that
> > > > > > > > > > > the PCIe PHY is not abstracted to its own driver so
> > > > > > > > > > > I think this has something to do with the order in
> > > > > > > > > > > which the phy is reset or
> > > > > initialized?
> > > > > > > > > > > The configuration of
> > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be
> masked.
> > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ#
> > > > > > > > > > low to level up the HW
> > > > > > > > > compatibility.
> > > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > > board although the
> > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > This method is a little rude and violate the SPEC, and
> > > > > > > > > > not recommended
> > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > So I drop this method in this series.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Sorry, I don't understand what you are saying here. Is
> > > > > > > > > there a change you are going to make to v4 that will
> > > > > > > > > make this work for the evk and my boards? What is that change
> exactly?
> > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > > forced to be low in NXP local BSP kernel. I guess this
> > > > > > > > might be the reason why your
> > > > > > board works.
> > > > > > > >
> > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > > CLKREQ# to
> > > > > > be low.
> > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > >
> > > > > > >
> > > > > > > Ok, that makes sense. Those bits are not explained well in
> > > > > > > the IMX8MMRM. As my board's external REFCLK is always
> > > > > > > enabled that must gate the clock internally to the host controller
> block.
> > > > > > >
> > > > > > > I can confirm that asserting those GPR14 bits does resolve my
> issue:
> > > > > > >
> > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> BIT(10)
> > > > > > >
> > > > > > >        /*
> > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > >         */
> > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > IOMUXC_GPR14,
> > > > > > >
> > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > IOMUXC_GPR14,
> > > > > > >
> > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > [Richard Zhu] regmap bits operations should manipulate according
> bits.
> > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > >
> > > > > > >
> > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > > needs to be set true to implement the above code?
> > > > > > >
> > > > > >
> > > > > > Richard,
> > > > > >
> > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > > removed the above did not resolve my issue. The setting of
> > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but
> > > > > > BIT(10)
> > > > > > instead) but this code already exists in
> > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch
> so this is not the issue.
> > > > > >
> > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > > kernel
> > > > > > does) so I don't think this bit does what we think it does
> > > > > > (select between internal and ext clk). I think setting it
> > > > > > enables clock gating via
> > > > > CLKREQ#.
> > > > > >
> > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic
> > > > > > should be moved to the new phy driver for IMX8MM.
> > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > CLKREQ# to be low.
> > > > > I will think about that and add this in later v5 patch-set if
> > > > > nobody has different concerns.
> > > > > Thanks.
> > > > [Richard Zhu] Hi Tim:
> > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe
> > > > on
> > > your board, right?
> > > > " (I have boards that use the only two possible pins for CLKREQ as
> > > > other
> > > features)"
> > > >
> > > > Did the override configuration of the clkreq# will bring
> > > > unexpected results
> > > for other features on your board?
> > > >
> > >
> > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and
> > > UART4 and because I2C4_SCL and UART4_RXD are the only two pads that
> > > could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing
> it.
> > >
> > > Currently your driver only works on my imx8mm-venice-* boards if I
> > > add one of the following on boards that don't connect those pads (or
> > > if I clear
> > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > >
> > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > enable this code already in the imx6_pcie_enable_ref_clk function to
> > > override REF_CLK and drive it low:
> > >
> > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > /*
> > > * Set the over ride low and enabled
> > > * make sure that REF_CLK is turned on.
> > > */
> > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > >    0);
> > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > >
> > > So this is already being run and yet my boards still do not work
> > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
> > > NXP downstream driver does:
> > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > >
> > > This is why I'm not sure that bit does what you think it does... I
> > > feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > >
> > > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > > Please provide correct descriptions for us so we can sort this out.
> > >
> > [Richard Zhu] Hi Tim:
> > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> > I think the two bits descriptions are used to describe the BIT19 and BIT9
> together refer to my guess.
> > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > 2'b00: External Reference Clock I/O (for PLL) Disable
> > 2'b01: External Reference Clock I/O (for PLL) Enable
> > 2'b10: External Reference Clock I/O (for PLL) Disable
> > 2'b11: External Reference Clock I/O (for PLL) output is controlled by
> > CLKREQ#
> >
> > The option1&3 should be forbidden, since the external REF CLK I/O should
> be enabled on your board and EVK board.
> > In the option2&4, the BIT19 should be set to be 1'b1.'
> >
> > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use
> case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> >
> 
> Richard,
> 
> Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM
> should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support'
> should have this on top and squashed:
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 7c89bd1a6441..458d54c8e385 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> imx6_pcie *imx6_pcie)
>                 break;
>         case IMX7D:
>                 break;
> -       case IMX8MQ:
>         case IMX8MM:
> +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> +               if (ret)
> +                       dev_err(dev, "unable to enable pcie_aux
> clock\n");
> +               break;
> +       case IMX8MQ:
>                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
>                 if (ret) {
>                         dev_err(dev, "unable to enable pcie_aux
> clock\n");
> 
[Richard Zhu] Sorry, I might don't understand what's meaning of the changes.
What're the differences between before and after the changes?

> 
> And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy
> driver' should have this on top and squashed:
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> index 317cf61bff37..27ca0b9f1d92 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -43,7 +43,7 @@
>  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
>  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
>  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> 
>  struct imx8_pcie_phy {
>         u32                     refclk_pad_mode;
> @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
>         reset_control_assert(imx8_phy->reset);
> 
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> -                          imx8_phy->refclk_pad_mode == 1 ?
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> +                          0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_AUX_EN,
> -                          IMX8MM_GPR_PCIE_AUX_EN);
> +                          imx8_phy->refclk_pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
> +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@
> -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> 
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_REF_CLK_SEL,
> -                          imx8_phy->refclk_pad_mode == 1 ?
> +                          imx8_phy->refclk_pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
>                            IMX8MM_GPR_PCIE_REF_CLK_EXT :
>                            IMX8MM_GPR_PCIE_REF_CLK_PLL);
>         usleep_range(100, 200);
> 
> I tested this and it works both on imx8mm-evk and imx8mm-venice-* which
> both have external clkgen.
> 
> However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> for the case where CLKREQ# is connected and thus should be used so I think
> we need to add a property for that to define if CLKREQ# is hooked up or not. I
> tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected
> that worked on the imx8mm-evk which hooks up CLKREQ# but not
> imx8mm-venice which does not hook up CLKREQ#.
> 
> What do you think about adding a property for this?
[Richard Zhu] First of all, thanks a lot for your help to figure out the details.
Agree with your proposal.
One optional property "fsl,clkreq-unsupported" would be added for the CLKREQ# not hooked case later.

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
index 097ba2a28fb4..2264452924cc 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
@@ -58,6 +58,11 @@ properties:
     $ref: /schemas/types.yaml#/definitions/uint32
     default: 0

+  fsl,clkreq-unsupported:
+    type: boolean
+    description: A boolean property whoes presence indicates the CLKREQ#
+      signal isn't supported in the HW board design (optional required).
+

diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
index 07eea39283ed..4b4402eaddcc 100644
--- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -43,7 +43,7 @@
 #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
 #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
 #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
-#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
+#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)

 struct imx8_pcie_phy {
        void __iomem            *base;
@@ -54,6 +54,7 @@ struct imx8_pcie_phy {
        u32                     refclk_pad_mode;
        u32                     tx_deemph_gen1;
        u32                     tx_deemph_gen2;
+       bool                    clkreq_unused;
 };

 static int imx8_pcie_phy_init(struct phy *phy)
@@ -65,13 +66,15 @@ static int imx8_pcie_phy_init(struct phy *phy)
        reset_control_assert(imx8_phy->reset);

        pad_mode = imx8_phy->refclk_pad_mode;
+       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't hooked */
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
-                          IMX8MM_GPR_PCIE_REF_USE_PAD,
-                          pad_mode == IMX8MM_GPR_PCIE_REF_USE_PAD ?
-                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
+                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
+                          imx8_phy->clkreq_unused ?
+                          0 : IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_AUX_EN,
-                          IMX8MM_GPR_PCIE_AUX_EN);
+                          pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ?
+                          IMX8MM_GPR_PCIE_AUX_EN : 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
                           IMX8MM_GPR_PCIE_POWER_OFF, 0);
        regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
@@ -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct platform_device *pdev)
                                 &imx8_phy->tx_deemph_gen2))
                imx8_phy->tx_deemph_gen2 = 0;

+       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
+               imx8_phy->clkreq_unused = true;
+       else
+               imx8_phy->clkreq_unused = false;
+
        imx8_phy->clk = devm_clk_get(dev, "ref");
        if (IS_ERR(imx8_phy->clk)) {
                dev_err(dev, "failed to get imx pcie phy clock\n");

Best Regards
Richard Zhu

> 
> Best regards,
> 
> Tim
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Wednesday, October 27, 2021 12:06 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > > pcie support
> > > >
> > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > Snipped...
> > > > >
> > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > > PCIe
> > > > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > > > features).
> > > > > > > > > > > >
> > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > > comment out the CLKREQ (which isn't required) the
> > > > > > > > > > > > imx8mmevk will end up hanging like my
> > > > > > > > > > boards:
> > > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required,
> > > > > > > > > > > and should be
> > > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > > > device to request the
> > > > > > > > > > REF clock be available(active low).
> > > > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > > > i.MX8MM EVK
> > > > > > > board.
> > > > > > > > > > >
> > > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > > always running if there is
> > > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > > > disable the REFCLK when not needed for power savings so
> > > > > > > > > > it would seem optional to implement that and if not
> > > > > > > > > > implemented should be left unconnected on
> > > > > > > the card.
> > > > > > > > > >
> > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > > > signal is
> > > > > > > mandatory required.
> > > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > > low/high by RC or EP automatically if
> > > > > > > L1ss modes are enabled.
> > > > > > > > > You can make reference to the
> > > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> > or
> > > > the
> > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > > > 4.0 Version 1.0".
> > > > > > > > >
> > > > > > > >
> > > > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > > > management. Many boards with a PCI host controller do not
> > > > > > > > support this.
> > > > > > [Richard Zhu] Okay, understood.
> > > > > >
> > > > > > > >
> > > > > > > > > > > > diff --git
> > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > > >
> > > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > > +/*
> > > > > > > > > > > >
> > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > > > +*/
> > > > > > > > > > > >
> > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > > 0x41
> > > > > > > > > > > >                 >;
> > > > > > > > > > > >         };
> > > > > > > > > > > >
> > > > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > > > NXP's kernel which differs from your driver in that
> > > > > > > > > > > > the PCIe PHY is not abstracted to its own driver so
> > > > > > > > > > > > I think this has something to do with the order in
> > > > > > > > > > > > which the phy is reset or
> > > > > > initialized?
> > > > > > > > > > > > The configuration of
> > > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be
> > masked.
> > > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ#
> > > > > > > > > > > low to level up the HW
> > > > > > > > > > compatibility.
> > > > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > > > board although the
> > > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > > This method is a little rude and violate the SPEC, and
> > > > > > > > > > > not recommended
> > > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > > So I drop this method in this series.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Sorry, I don't understand what you are saying here. Is
> > > > > > > > > > there a change you are going to make to v4 that will
> > > > > > > > > > make this work for the evk and my boards? What is that change
> > exactly?
> > > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > > > forced to be low in NXP local BSP kernel. I guess this
> > > > > > > > > might be the reason why your
> > > > > > > board works.
> > > > > > > > >
> > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > > > CLKREQ# to
> > > > > > > be low.
> > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > > >
> > > > > > > >
> > > > > > > > Ok, that makes sense. Those bits are not explained well in
> > > > > > > > the IMX8MMRM. As my board's external REFCLK is always
> > > > > > > > enabled that must gate the clock internally to the host controller
> > block.
> > > > > > > >
> > > > > > > > I can confirm that asserting those GPR14 bits does resolve my
> > issue:
> > > > > > > >
> > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> > BIT(10)
> > > > > > > >
> > > > > > > >        /*
> > > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > > >         */
> > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > IOMUXC_GPR14,
> > > > > > > >
> > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > IOMUXC_GPR14,
> > > > > > > >
> > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > > [Richard Zhu] regmap bits operations should manipulate according
> > bits.
> > > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > > >
> > > > > > > >
> > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > > > needs to be set true to implement the above code?
> > > > > > > >
> > > > > > >
> > > > > > > Richard,
> > > > > > >
> > > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > > > removed the above did not resolve my issue. The setting of
> > > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but
> > > > > > > BIT(10)
> > > > > > > instead) but this code already exists in
> > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch
> > so this is not the issue.
> > > > > > >
> > > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > > > kernel
> > > > > > > does) so I don't think this bit does what we think it does
> > > > > > > (select between internal and ext clk). I think setting it
> > > > > > > enables clock gating via
> > > > > > CLKREQ#.
> > > > > > >
> > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic
> > > > > > > should be moved to the new phy driver for IMX8MM.
> > > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > > CLKREQ# to be low.
> > > > > > I will think about that and add this in later v5 patch-set if
> > > > > > nobody has different concerns.
> > > > > > Thanks.
> > > > > [Richard Zhu] Hi Tim:
> > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe
> > > > > on
> > > > your board, right?
> > > > > " (I have boards that use the only two possible pins for CLKREQ as
> > > > > other
> > > > features)"
> > > > >
> > > > > Did the override configuration of the clkreq# will bring
> > > > > unexpected results
> > > > for other features on your board?
> > > > >
> > > >
> > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and
> > > > UART4 and because I2C4_SCL and UART4_RXD are the only two pads that
> > > > could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing
> > it.
> > > >
> > > > Currently your driver only works on my imx8mm-venice-* boards if I
> > > > add one of the following on boards that don't connect those pads (or
> > > > if I clear
> > > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > > >
> > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > > enable this code already in the imx6_pcie_enable_ref_clk function to
> > > > override REF_CLK and drive it low:
> > > >
> > > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > > /*
> > > > * Set the over ride low and enabled
> > > > * make sure that REF_CLK is turned on.
> > > > */
> > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > > >    0);
> > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > > >
> > > > So this is already being run and yet my boards still do not work
> > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
> > > > NXP downstream driver does:
> > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > > >
> > > > This is why I'm not sure that bit does what you think it does... I
> > > > feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > > >
> > > > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > > > Please provide correct descriptions for us so we can sort this out.
> > > >
> > > [Richard Zhu] Hi Tim:
> > > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> > > I think the two bits descriptions are used to describe the BIT19 and BIT9
> > together refer to my guess.
> > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > > 2'b00: External Reference Clock I/O (for PLL) Disable
> > > 2'b01: External Reference Clock I/O (for PLL) Enable
> > > 2'b10: External Reference Clock I/O (for PLL) Disable
> > > 2'b11: External Reference Clock I/O (for PLL) output is controlled by
> > > CLKREQ#
> > >
> > > The option1&3 should be forbidden, since the external REF CLK I/O should
> > be enabled on your board and EVK board.
> > > In the option2&4, the BIT19 should be set to be 1'b1.'
> > >
> > > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use
> > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> > >
> >
> > Richard,
> >
> > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM
> > should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support'
> > should have this on top and squashed:
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 7c89bd1a6441..458d54c8e385 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> > imx6_pcie *imx6_pcie)
> >                 break;
> >         case IMX7D:
> >                 break;
> > -       case IMX8MQ:
> >         case IMX8MM:
> > +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > +               if (ret)
> > +                       dev_err(dev, "unable to enable pcie_aux
> > clock\n");
> > +               break;
> > +       case IMX8MQ:
> >                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> >                 if (ret) {
> >                         dev_err(dev, "unable to enable pcie_aux
> > clock\n");
> >
> [Richard Zhu] Sorry, I might don't understand what's meaning of the changes.
> What're the differences between before and after the changes?
>

The above change to your patch 'only' calls clk_prepare_enable for
IMX8MM and does not touch GPR14 bits as the IMX8MQ case does (because
as you point out the GPR14 bits differ between IMX8MM and IMX8MQ).

> >
> > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy
> > driver' should have this on top and squashed:
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > index 317cf61bff37..27ca0b9f1d92 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -43,7 +43,7 @@
> >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> >
> >  struct imx8_pcie_phy {
> >         u32                     refclk_pad_mode;
> > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
> >         reset_control_assert(imx8_phy->reset);
> >
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > -                          imx8_phy->refclk_pad_mode == 1 ?
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > +                          0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_AUX_EN,
> > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > +                          imx8_phy->refclk_pad_mode ==
> > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@
> > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> >
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > -                          imx8_phy->refclk_pad_mode == 1 ?
> > +                          imx8_phy->refclk_pad_mode ==
> > IMX8_PCIE_REFCLK_PAD_INPUT ?
> >                            IMX8MM_GPR_PCIE_REF_CLK_EXT :
> >                            IMX8MM_GPR_PCIE_REF_CLK_PLL);
> >         usleep_range(100, 200);
> >
> > I tested this and it works both on imx8mm-evk and imx8mm-venice-* which
> > both have external clkgen.
> >
> > However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> > for the case where CLKREQ# is connected and thus should be used so I think
> > we need to add a property for that to define if CLKREQ# is hooked up or not. I
> > tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected
> > that worked on the imx8mm-evk which hooks up CLKREQ# but not
> > imx8mm-venice which does not hook up CLKREQ#.
> >
> > What do you think about adding a property for this?
> [Richard Zhu] First of all, thanks a lot for your help to figure out the details.
> Agree with your proposal.
> One optional property "fsl,clkreq-unsupported" would be added for the CLKREQ# not hooked case later.
>
> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> index 097ba2a28fb4..2264452924cc 100644
> --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> @@ -58,6 +58,11 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/uint32
>      default: 0
>
> +  fsl,clkreq-unsupported:
> +    type: boolean
> +    description: A boolean property whoes presence indicates the CLKREQ#
> +      signal isn't supported in the HW board design (optional required).
> +

A boolean property indicating the CLKREQ# signal is not supported in
the board design (optional)

>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> index 07eea39283ed..4b4402eaddcc 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -43,7 +43,7 @@
>  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
>  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
>  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
>
>  struct imx8_pcie_phy {
>         void __iomem            *base;
> @@ -54,6 +54,7 @@ struct imx8_pcie_phy {
>         u32                     refclk_pad_mode;
>         u32                     tx_deemph_gen1;
>         u32                     tx_deemph_gen2;
> +       bool                    clkreq_unused;
>  };
>
>  static int imx8_pcie_phy_init(struct phy *phy)
> @@ -65,13 +66,15 @@ static int imx8_pcie_phy_init(struct phy *phy)
>         reset_control_assert(imx8_phy->reset);
>
>         pad_mode = imx8_phy->refclk_pad_mode;
> +       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't hooked */
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> -                          pad_mode == IMX8MM_GPR_PCIE_REF_USE_PAD ?
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> +                          imx8_phy->clkreq_unused ?
> +                          0 : IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_AUX_EN,
> -                          IMX8MM_GPR_PCIE_AUX_EN);
> +                          pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ?
> +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> @@ -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct platform_device *pdev)
>                                  &imx8_phy->tx_deemph_gen2))
>                 imx8_phy->tx_deemph_gen2 = 0;
>
> +       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
> +               imx8_phy->clkreq_unused = true;
> +       else
> +               imx8_phy->clkreq_unused = false;
> +
>         imx8_phy->clk = devm_clk_get(dev, "ref");
>         if (IS_ERR(imx8_phy->clk)) {
>                 dev_err(dev, "failed to get imx pcie phy clock\n");
>

Yes this looks good and works both on venice (with
'fsl,clkreq-unsupported' added) and on imx8mm-evk.

Thanks for working through this with me and please cc me on your v4 submission.

Best regards,

Tim

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Wednesday, October 27, 2021 12:06 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > > pcie support
> > > >
> > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > Snipped...
> > > > >
> > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > > PCIe
> > > > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > > > features).
> > > > > > > > > > > >
> > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > > comment out the CLKREQ (which isn't required) the
> > > > > > > > > > > > imx8mmevk will end up hanging like my
> > > > > > > > > > boards:
> > > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required,
> > > > > > > > > > > and should be
> > > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > > > device to request the
> > > > > > > > > > REF clock be available(active low).
> > > > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > > > i.MX8MM EVK
> > > > > > > board.
> > > > > > > > > > >
> > > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > > always running if there is
> > > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > > > disable the REFCLK when not needed for power savings so
> > > > > > > > > > it would seem optional to implement that and if not
> > > > > > > > > > implemented should be left unconnected on
> > > > > > > the card.
> > > > > > > > > >
> > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > > > signal is
> > > > > > > mandatory required.
> > > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > > low/high by RC or EP automatically if
> > > > > > > L1ss modes are enabled.
> > > > > > > > > You can make reference to the
> > > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> > or
> > > > the
> > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > > > 4.0 Version 1.0".
> > > > > > > > >
> > > > > > > >
> > > > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > > > management. Many boards with a PCI host controller do not
> > > > > > > > support this.
> > > > > > [Richard Zhu] Okay, understood.
> > > > > >
> > > > > > > >
> > > > > > > > > > > > diff --git
> > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > > >
> > > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > > +/*
> > > > > > > > > > > >
> > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > > > +*/
> > > > > > > > > > > >
> > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > > 0x41
> > > > > > > > > > > >                 >;
> > > > > > > > > > > >         };
> > > > > > > > > > > >
> > > > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > > > NXP's kernel which differs from your driver in that
> > > > > > > > > > > > the PCIe PHY is not abstracted to its own driver so
> > > > > > > > > > > > I think this has something to do with the order in
> > > > > > > > > > > > which the phy is reset or
> > > > > > initialized?
> > > > > > > > > > > > The configuration of
> > > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be
> > masked.
> > > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ#
> > > > > > > > > > > low to level up the HW
> > > > > > > > > > compatibility.
> > > > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > > > board although the
> > > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > > This method is a little rude and violate the SPEC, and
> > > > > > > > > > > not recommended
> > > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > > So I drop this method in this series.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Sorry, I don't understand what you are saying here. Is
> > > > > > > > > > there a change you are going to make to v4 that will
> > > > > > > > > > make this work for the evk and my boards? What is that change
> > exactly?
> > > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > > > forced to be low in NXP local BSP kernel. I guess this
> > > > > > > > > might be the reason why your
> > > > > > > board works.
> > > > > > > > >
> > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > > > CLKREQ# to
> > > > > > > be low.
> > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > > >
> > > > > > > >
> > > > > > > > Ok, that makes sense. Those bits are not explained well in
> > > > > > > > the IMX8MMRM. As my board's external REFCLK is always
> > > > > > > > enabled that must gate the clock internally to the host controller
> > block.
> > > > > > > >
> > > > > > > > I can confirm that asserting those GPR14 bits does resolve my
> > issue:
> > > > > > > >
> > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> > BIT(10)
> > > > > > > >
> > > > > > > >        /*
> > > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > > >         */
> > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > IOMUXC_GPR14,
> > > > > > > >
> > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > IOMUXC_GPR14,
> > > > > > > >
> > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > > [Richard Zhu] regmap bits operations should manipulate according
> > bits.
> > > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > > >
> > > > > > > >
> > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > > > needs to be set true to implement the above code?
> > > > > > > >
> > > > > > >
> > > > > > > Richard,
> > > > > > >
> > > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > > > removed the above did not resolve my issue. The setting of
> > > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but
> > > > > > > BIT(10)
> > > > > > > instead) but this code already exists in
> > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch
> > so this is not the issue.
> > > > > > >
> > > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > > > kernel
> > > > > > > does) so I don't think this bit does what we think it does
> > > > > > > (select between internal and ext clk). I think setting it
> > > > > > > enables clock gating via
> > > > > > CLKREQ#.
> > > > > > >
> > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic
> > > > > > > should be moved to the new phy driver for IMX8MM.
> > > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > > CLKREQ# to be low.
> > > > > > I will think about that and add this in later v5 patch-set if
> > > > > > nobody has different concerns.
> > > > > > Thanks.
> > > > > [Richard Zhu] Hi Tim:
> > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe
> > > > > on
> > > > your board, right?
> > > > > " (I have boards that use the only two possible pins for CLKREQ as
> > > > > other
> > > > features)"
> > > > >
> > > > > Did the override configuration of the clkreq# will bring
> > > > > unexpected results
> > > > for other features on your board?
> > > > >
> > > >
> > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and
> > > > UART4 and because I2C4_SCL and UART4_RXD are the only two pads that
> > > > could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing
> > it.
> > > >
> > > > Currently your driver only works on my imx8mm-venice-* boards if I
> > > > add one of the following on boards that don't connect those pads (or
> > > > if I clear
> > > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > > >
> > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > > enable this code already in the imx6_pcie_enable_ref_clk function to
> > > > override REF_CLK and drive it low:
> > > >
> > > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > > /*
> > > > * Set the over ride low and enabled
> > > > * make sure that REF_CLK is turned on.
> > > > */
> > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > > >    0);
> > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > > >
> > > > So this is already being run and yet my boards still do not work
> > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
> > > > NXP downstream driver does:
> > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > > >
> > > > This is why I'm not sure that bit does what you think it does... I
> > > > feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > > >
> > > > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > > > Please provide correct descriptions for us so we can sort this out.
> > > >
> > > [Richard Zhu] Hi Tim:
> > > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> > > I think the two bits descriptions are used to describe the BIT19 and BIT9
> > together refer to my guess.
> > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > > 2'b00: External Reference Clock I/O (for PLL) Disable
> > > 2'b01: External Reference Clock I/O (for PLL) Enable
> > > 2'b10: External Reference Clock I/O (for PLL) Disable
> > > 2'b11: External Reference Clock I/O (for PLL) output is controlled by
> > > CLKREQ#
> > >
> > > The option1&3 should be forbidden, since the external REF CLK I/O should
> > be enabled on your board and EVK board.
> > > In the option2&4, the BIT19 should be set to be 1'b1.'
> > >
> > > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use
> > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> > >
> >
> > Richard,
> >
> > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM
> > should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support'
> > should have this on top and squashed:
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 7c89bd1a6441..458d54c8e385 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> > imx6_pcie *imx6_pcie)
> >                 break;
> >         case IMX7D:
> >                 break;
> > -       case IMX8MQ:
> >         case IMX8MM:
> > +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > +               if (ret)
> > +                       dev_err(dev, "unable to enable pcie_aux
> > clock\n");
> > +               break;
> > +       case IMX8MQ:
> >                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> >                 if (ret) {
> >                         dev_err(dev, "unable to enable pcie_aux
> > clock\n");
> >
> [Richard Zhu] Sorry, I might don't understand what's meaning of the changes.
> What're the differences between before and after the changes?
>

The above change to your patch 'only' calls clk_prepare_enable for
IMX8MM and does not touch GPR14 bits as the IMX8MQ case does (because
as you point out the GPR14 bits differ between IMX8MM and IMX8MQ).

> >
> > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy
> > driver' should have this on top and squashed:
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > index 317cf61bff37..27ca0b9f1d92 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -43,7 +43,7 @@
> >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> >
> >  struct imx8_pcie_phy {
> >         u32                     refclk_pad_mode;
> > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
> >         reset_control_assert(imx8_phy->reset);
> >
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > -                          imx8_phy->refclk_pad_mode == 1 ?
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > +                          0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_AUX_EN,
> > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > +                          imx8_phy->refclk_pad_mode ==
> > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@
> > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> >
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > -                          imx8_phy->refclk_pad_mode == 1 ?
> > +                          imx8_phy->refclk_pad_mode ==
> > IMX8_PCIE_REFCLK_PAD_INPUT ?
> >                            IMX8MM_GPR_PCIE_REF_CLK_EXT :
> >                            IMX8MM_GPR_PCIE_REF_CLK_PLL);
> >         usleep_range(100, 200);
> >
> > I tested this and it works both on imx8mm-evk and imx8mm-venice-* which
> > both have external clkgen.
> >
> > However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> > for the case where CLKREQ# is connected and thus should be used so I think
> > we need to add a property for that to define if CLKREQ# is hooked up or not. I
> > tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected
> > that worked on the imx8mm-evk which hooks up CLKREQ# but not
> > imx8mm-venice which does not hook up CLKREQ#.
> >
> > What do you think about adding a property for this?
> [Richard Zhu] First of all, thanks a lot for your help to figure out the details.
> Agree with your proposal.
> One optional property "fsl,clkreq-unsupported" would be added for the CLKREQ# not hooked case later.
>
> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> index 097ba2a28fb4..2264452924cc 100644
> --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> @@ -58,6 +58,11 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/uint32
>      default: 0
>
> +  fsl,clkreq-unsupported:
> +    type: boolean
> +    description: A boolean property whoes presence indicates the CLKREQ#
> +      signal isn't supported in the HW board design (optional required).
> +

A boolean property indicating the CLKREQ# signal is not supported in
the board design (optional)

>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> index 07eea39283ed..4b4402eaddcc 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -43,7 +43,7 @@
>  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
>  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
>  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
>
>  struct imx8_pcie_phy {
>         void __iomem            *base;
> @@ -54,6 +54,7 @@ struct imx8_pcie_phy {
>         u32                     refclk_pad_mode;
>         u32                     tx_deemph_gen1;
>         u32                     tx_deemph_gen2;
> +       bool                    clkreq_unused;
>  };
>
>  static int imx8_pcie_phy_init(struct phy *phy)
> @@ -65,13 +66,15 @@ static int imx8_pcie_phy_init(struct phy *phy)
>         reset_control_assert(imx8_phy->reset);
>
>         pad_mode = imx8_phy->refclk_pad_mode;
> +       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't hooked */
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> -                          pad_mode == IMX8MM_GPR_PCIE_REF_USE_PAD ?
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> +                          imx8_phy->clkreq_unused ?
> +                          0 : IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_AUX_EN,
> -                          IMX8MM_GPR_PCIE_AUX_EN);
> +                          pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ?
> +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> @@ -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct platform_device *pdev)
>                                  &imx8_phy->tx_deemph_gen2))
>                 imx8_phy->tx_deemph_gen2 = 0;
>
> +       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
> +               imx8_phy->clkreq_unused = true;
> +       else
> +               imx8_phy->clkreq_unused = false;
> +
>         imx8_phy->clk = devm_clk_get(dev, "ref");
>         if (IS_ERR(imx8_phy->clk)) {
>                 dev_err(dev, "failed to get imx pcie phy clock\n");
>

Yes this looks good and works both on venice (with
'fsl,clkreq-unsupported' added) and on imx8mm-evk.

Thanks for working through this with me and please cc me on your v4 submission.

Best regards,

Tim

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

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Tim Harvey]

On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <hongxing.zhu@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey@gateworks.com>
> > Sent: Wednesday, October 27, 2021 12:06 AM
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > linux-phy@lists.infradead.org; Device Tree Mailing List
> > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > <linux-arm-kernel@lists.infradead.org>; open list
> > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> > support
> >
> > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com>
> > wrote:
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > > <linux-arm-kernel@lists.infradead.org>; open list
> > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> > > > pcie support
> > > >
> > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com>
> > > > wrote:
> > > > >
> > > > > Snipped...
> > > > >
> > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that
> > > > > > > > > > > > defined in pinmux and I found that if I add
> > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > > PCIe
> > > > > > > > > > > > works on my board but this isn't a solution just a
> > > > > > > > > > > > work-around (I have boards that use the only two
> > > > > > > > > > > > possible pins for CLKREQ as other
> > > > > > > > > > features).
> > > > > > > > > > > >
> > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > > comment out the CLKREQ (which isn't required) the
> > > > > > > > > > > > imx8mmevk will end up hanging like my
> > > > > > > > > > boards:
> > > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required,
> > > > > > > > > > > and should be
> > > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > > And this signal should be driven low by the PCIe M.2
> > > > > > > > > > > device to request the
> > > > > > > > > > REF clock be available(active low).
> > > > > > > > > > > So, there is such kind of CLKREQ# pin definition on
> > > > > > > > > > > i.MX8MM EVK
> > > > > > > board.
> > > > > > > > > > >
> > > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > > always running if there is
> > > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The way I understand it is CLKREQ# allows the host to
> > > > > > > > > > disable the REFCLK when not needed for power savings so
> > > > > > > > > > it would seem optional to implement that and if not
> > > > > > > > > > implemented should be left unconnected on
> > > > > > > the card.
> > > > > > > > > >
> > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this
> > > > > > > > > signal is
> > > > > > > mandatory required.
> > > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > > low/high by RC or EP automatically if
> > > > > > > L1ss modes are enabled.
> > > > > > > > > You can make reference to the
> > > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> > or
> > > > the
> > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev.
> > > > > > > 4.0 Version 1.0".
> > > > > > > > >
> > > > > > > >
> > > > > > > > CLKREQ is only mandatory if you wish to support clock power
> > > > > > > > management. Many boards with a PCI host controller do not
> > > > > > > > support this.
> > > > > > [Richard Zhu] Okay, understood.
> > > > > >
> > > > > > > >
> > > > > > > > > > > > diff --git
> > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > > >
> > > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > > +/*
> > > > > > > > > > > >
> > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B    0x61
> > > > > > > > > > > > +*/
> > > > > > > > > > > >
> > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > > 0x41
> > > > > > > > > > > >                 >;
> > > > > > > > > > > >         };
> > > > > > > > > > > >
> > > > > > > > > > > > I have PCIe working with a driver that I ported from
> > > > > > > > > > > > NXP's kernel which differs from your driver in that
> > > > > > > > > > > > the PCIe PHY is not abstracted to its own driver so
> > > > > > > > > > > > I think this has something to do with the order in
> > > > > > > > > > > > which the phy is reset or
> > > > > > initialized?
> > > > > > > > > > > > The configuration of
> > > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be
> > masked.
> > > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ#
> > > > > > > > > > > low to level up the HW
> > > > > > > > > > compatibility.
> > > > > > > > > > > That's might the reason why the PCIe works on your HW
> > > > > > > > > > > board although the
> > > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > > This method is a little rude and violate the SPEC, and
> > > > > > > > > > > not recommended
> > > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > > So I drop this method in this series.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Sorry, I don't understand what you are saying here. Is
> > > > > > > > > > there a change you are going to make to v4 that will
> > > > > > > > > > make this work for the evk and my boards? What is that change
> > exactly?
> > > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is
> > > > > > > > > forced to be low in NXP local BSP kernel. I guess this
> > > > > > > > > might be the reason why your
> > > > > > > board works.
> > > > > > > > >
> > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the
> > > > > > > > > CLKREQ# to
> > > > > > > be low.
> > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to
> > > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > > >
> > > > > > > >
> > > > > > > > Ok, that makes sense. Those bits are not explained well in
> > > > > > > > the IMX8MMRM. As my board's external REFCLK is always
> > > > > > > > enabled that must gate the clock internally to the host controller
> > block.
> > > > > > > >
> > > > > > > > I can confirm that asserting those GPR14 bits does resolve my
> > issue:
> > > > > > > >
> > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL    BIT(11)
> > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> > BIT(10)
> > > > > > > >
> > > > > > > >        /*
> > > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > > >         */
> > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > IOMUXC_GPR14,
> > > > > > > >
> > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > IOMUXC_GPR14,
> > > > > > > >
> > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > > [Richard Zhu] regmap bits operations should manipulate according
> > bits.
> > > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > > >
> > > > > > > >
> > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that
> > > > > > > > needs to be set true to implement the above code?
> > > > > > > >
> > > > > > >
> > > > > > > Richard,
> > > > > > >
> > > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > > pinmuxing CLKREQ in my dt to work around the issue and after
> > > > > > > removed the above did not resolve my issue. The setting of
> > > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but
> > > > > > > BIT(10)
> > > > > > > instead) but this code already exists in
> > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch
> > so this is not the issue.
> > > > > > >
> > > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP
> > > > > > > kernel
> > > > > > > does) so I don't think this bit does what we think it does
> > > > > > > (select between internal and ext clk). I think setting it
> > > > > > > enables clock gating via
> > > > > > CLKREQ#.
> > > > > > >
> > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic
> > > > > > > should be moved to the new phy driver for IMX8MM.
> > > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > > CLKREQ# to be low.
> > > > > > I will think about that and add this in later v5 patch-set if
> > > > > > nobody has different concerns.
> > > > > > Thanks.
> > > > > [Richard Zhu] Hi Tim:
> > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe
> > > > > on
> > > > your board, right?
> > > > > " (I have boards that use the only two possible pins for CLKREQ as
> > > > > other
> > > > features)"
> > > > >
> > > > > Did the override configuration of the clkreq# will bring
> > > > > unexpected results
> > > > for other features on your board?
> > > > >
> > > >
> > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and
> > > > UART4 and because I2C4_SCL and UART4_RXD are the only two pads that
> > > > could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing
> > it.
> > > >
> > > > Currently your driver only works on my imx8mm-venice-* boards if I
> > > > add one of the following on boards that don't connect those pads (or
> > > > if I clear
> > > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > > >
> > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > > enable this code already in the imx6_pcie_enable_ref_clk function to
> > > > override REF_CLK and drive it low:
> > > >
> > > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > > /*
> > > > * Set the over ride low and enabled
> > > > * make sure that REF_CLK is turned on.
> > > > */
> > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > > >    0);
> > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > > >
> > > > So this is already being run and yet my boards still do not work
> > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the
> > > > NXP downstream driver does:
> > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > > >
> > > > This is why I'm not sure that bit does what you think it does... I
> > > > feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > > >
> > > > You tell me the descriptions for GPR14 are wrong in the reference manual.
> > > > Please provide correct descriptions for us so we can sort this out.
> > > >
> > > [Richard Zhu] Hi Tim:
> > > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM.
> > > I think the two bits descriptions are used to describe the BIT19 and BIT9
> > together refer to my guess.
> > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > > 2'b00: External Reference Clock I/O (for PLL) Disable
> > > 2'b01: External Reference Clock I/O (for PLL) Enable
> > > 2'b10: External Reference Clock I/O (for PLL) Disable
> > > 2'b11: External Reference Clock I/O (for PLL) output is controlled by
> > > CLKREQ#
> > >
> > > The option1&3 should be forbidden, since the external REF CLK I/O should
> > be enabled on your board and EVK board.
> > > In the option2&4, the BIT19 should be set to be 1'b1.'
> > >
> > > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use
> > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> > >
> >
> > Richard,
> >
> > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM
> > should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support'
> > should have this on top and squashed:
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 7c89bd1a6441..458d54c8e385 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> > imx6_pcie *imx6_pcie)
> >                 break;
> >         case IMX7D:
> >                 break;
> > -       case IMX8MQ:
> >         case IMX8MM:
> > +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > +               if (ret)
> > +                       dev_err(dev, "unable to enable pcie_aux
> > clock\n");
> > +               break;
> > +       case IMX8MQ:
> >                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> >                 if (ret) {
> >                         dev_err(dev, "unable to enable pcie_aux
> > clock\n");
> >
> [Richard Zhu] Sorry, I might don't understand what's meaning of the changes.
> What're the differences between before and after the changes?
>

The above change to your patch 'only' calls clk_prepare_enable for
IMX8MM and does not touch GPR14 bits as the IMX8MQ case does (because
as you point out the GPR14 bits differ between IMX8MM and IMX8MQ).

> >
> > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy
> > driver' should have this on top and squashed:
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > index 317cf61bff37..27ca0b9f1d92 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -43,7 +43,7 @@
> >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> >
> >  struct imx8_pcie_phy {
> >         u32                     refclk_pad_mode;
> > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
> >         reset_control_assert(imx8_phy->reset);
> >
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > -                          imx8_phy->refclk_pad_mode == 1 ?
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> > +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > +                          0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_AUX_EN,
> > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > +                          imx8_phy->refclk_pad_mode ==
> > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@
> > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> >
> >         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > -                          imx8_phy->refclk_pad_mode == 1 ?
> > +                          imx8_phy->refclk_pad_mode ==
> > IMX8_PCIE_REFCLK_PAD_INPUT ?
> >                            IMX8MM_GPR_PCIE_REF_CLK_EXT :
> >                            IMX8MM_GPR_PCIE_REF_CLK_PLL);
> >         usleep_range(100, 200);
> >
> > I tested this and it works both on imx8mm-evk and imx8mm-venice-* which
> > both have external clkgen.
> >
> > However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> > for the case where CLKREQ# is connected and thus should be used so I think
> > we need to add a property for that to define if CLKREQ# is hooked up or not. I
> > tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected
> > that worked on the imx8mm-evk which hooks up CLKREQ# but not
> > imx8mm-venice which does not hook up CLKREQ#.
> >
> > What do you think about adding a property for this?
> [Richard Zhu] First of all, thanks a lot for your help to figure out the details.
> Agree with your proposal.
> One optional property "fsl,clkreq-unsupported" would be added for the CLKREQ# not hooked case later.
>
> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> index 097ba2a28fb4..2264452924cc 100644
> --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> @@ -58,6 +58,11 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/uint32
>      default: 0
>
> +  fsl,clkreq-unsupported:
> +    type: boolean
> +    description: A boolean property whoes presence indicates the CLKREQ#
> +      signal isn't supported in the HW board design (optional required).
> +

A boolean property indicating the CLKREQ# signal is not supported in
the board design (optional)

>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> index 07eea39283ed..4b4402eaddcc 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> @@ -43,7 +43,7 @@
>  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
>  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
>  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
>
>  struct imx8_pcie_phy {
>         void __iomem            *base;
> @@ -54,6 +54,7 @@ struct imx8_pcie_phy {
>         u32                     refclk_pad_mode;
>         u32                     tx_deemph_gen1;
>         u32                     tx_deemph_gen2;
> +       bool                    clkreq_unused;
>  };
>
>  static int imx8_pcie_phy_init(struct phy *phy)
> @@ -65,13 +66,15 @@ static int imx8_pcie_phy_init(struct phy *phy)
>         reset_control_assert(imx8_phy->reset);
>
>         pad_mode = imx8_phy->refclk_pad_mode;
> +       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't hooked */
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> -                          pad_mode == IMX8MM_GPR_PCIE_REF_USE_PAD ?
> -                          IMX8MM_GPR_PCIE_REF_USE_PAD : 0);
> +                          IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> +                          imx8_phy->clkreq_unused ?
> +                          0 : IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_AUX_EN,
> -                          IMX8MM_GPR_PCIE_AUX_EN);
> +                          pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ?
> +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
>                            IMX8MM_GPR_PCIE_POWER_OFF, 0);
>         regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> @@ -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct platform_device *pdev)
>                                  &imx8_phy->tx_deemph_gen2))
>                 imx8_phy->tx_deemph_gen2 = 0;
>
> +       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
> +               imx8_phy->clkreq_unused = true;
> +       else
> +               imx8_phy->clkreq_unused = false;
> +
>         imx8_phy->clk = devm_clk_get(dev, "ref");
>         if (IS_ERR(imx8_phy->clk)) {
>                 dev_err(dev, "failed to get imx pcie phy clock\n");
>

Yes this looks good and works both on venice (with
'fsl,clkreq-unsupported' added) and on imx8mm-evk.

Thanks for working through this with me and please cc me on your v4 submission.

Best regards,

Tim

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Wednesday, October 27, 2021 11:41 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> pcie support
> 
> On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Wednesday, October 27, 2021 12:06 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> imx8mm
> > > pcie support
> > >
> > > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu
> <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> > > > > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device
> > > > > Tree Mailing List <devicetree@vger.kernel.org>; Linux ARM
> > > > > Mailing List <linux-arm-kernel@lists.infradead.org>; open list
> > > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> > > > > imx8mm pcie support
> > > > >
> > > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu
> > > > > <hongxing.zhu@nxp.com>
> > > > > wrote:
> > > > > >
> > > > > > Snipped...
> > > > > >
> > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have
> > > > > > > > > > > > > that defined in pinmux and I found that if I add
> > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > > > PCIe
> > > > > > > > > > > > > works on my board but this isn't a solution just
> > > > > > > > > > > > > a work-around (I have boards that use the only
> > > > > > > > > > > > > two possible pins for CLKREQ as other
> > > > > > > > > > > features).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > > > comment out the CLKREQ (which isn't required)
> > > > > > > > > > > > > the imx8mmevk will end up hanging like my
> > > > > > > > > > > boards:
> > > > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory
> > > > > > > > > > > > required, and should be
> > > > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > > > And this signal should be driven low by the PCIe
> > > > > > > > > > > > M.2 device to request the
> > > > > > > > > > > REF clock be available(active low).
> > > > > > > > > > > > So, there is such kind of CLKREQ# pin definition
> > > > > > > > > > > > on i.MX8MM EVK
> > > > > > > > board.
> > > > > > > > > > > >
> > > > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > > > always running if there is
> > > > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The way I understand it is CLKREQ# allows the host
> > > > > > > > > > > to disable the REFCLK when not needed for power
> > > > > > > > > > > savings so it would seem optional to implement that
> > > > > > > > > > > and if not implemented should be left unconnected on
> > > > > > > > the card.
> > > > > > > > > > >
> > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC,
> > > > > > > > > > this signal is
> > > > > > > > mandatory required.
> > > > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > > > low/high by RC or EP automatically if
> > > > > > > > L1ss modes are enabled.
> > > > > > > > > > You can make reference to the
> > > > > > > > > >
> "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> > > or
> > > > > the
> > > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base
> Specification, Rev.
> > > > > > > > 4.0 Version 1.0".
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > CLKREQ is only mandatory if you wish to support clock
> > > > > > > > > power management. Many boards with a PCI host
> controller
> > > > > > > > > do not support this.
> > > > > > > [Richard Zhu] Okay, understood.
> > > > > > >
> > > > > > > > >
> > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > +++
> b/arch/arm64/boot/dts/freescale/imx8mm-evk.d
> > > > > > > > > > > > > +++ tsi
> > > > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > > > >
> > > > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > > > +/*
> > > > > > > > > > > > >
> > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> 0x61
> > > > > > > > > > > > > +*/
> > > > > > > > > > > > >
> > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > > > 0x41
> > > > > > > > > > > > >                 >;
> > > > > > > > > > > > >         };
> > > > > > > > > > > > >
> > > > > > > > > > > > > I have PCIe working with a driver that I ported
> > > > > > > > > > > > > from NXP's kernel which differs from your driver
> > > > > > > > > > > > > in that the PCIe PHY is not abstracted to its
> > > > > > > > > > > > > own driver so I think this has something to do
> > > > > > > > > > > > > with the order in which the phy is reset or
> > > > > > > initialized?
> > > > > > > > > > > > > The configuration of
> > > > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't
> > > > > > > > > > > > be
> > > masked.
> > > > > > > > > > > > In the NXP's local BSP kernel, I just force
> > > > > > > > > > > > CLKREQ# low to level up the HW
> > > > > > > > > > > compatibility.
> > > > > > > > > > > > That's might the reason why the PCIe works on your
> > > > > > > > > > > > HW board although the
> > > > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > > > This method is a little rude and violate the SPEC,
> > > > > > > > > > > > and not recommended
> > > > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > > > So I drop this method in this series.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Sorry, I don't understand what you are saying here.
> > > > > > > > > > > Is there a change you are going to make to v4 that
> > > > > > > > > > > will make this work for the evk and my boards? What
> > > > > > > > > > > is that change
> > > exactly?
> > > > > > > > > > [Richard Zhu] No. What I said above is that the
> > > > > > > > > > CLKREQ# is forced to be low in NXP local BSP kernel. I
> > > > > > > > > > guess this might be the reason why your
> > > > > > > > board works.
> > > > > > > > > >
> > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force
> > > > > > > > > > the CLKREQ# to
> > > > > > > > be low.
> > > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one
> zero
> > > > > > > > > > to
> > > > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Ok, that makes sense. Those bits are not explained well
> > > > > > > > > in the IMX8MMRM. As my board's external REFCLK is
> always
> > > > > > > > > enabled that must gate the clock internally to the host
> > > > > > > > > controller
> > > block.
> > > > > > > > >
> > > > > > > > > I can confirm that asserting those GPR14 bits does
> > > > > > > > > resolve my
> > > issue:
> > > > > > > > >
> > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL
> BIT(11)
> > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> > > BIT(10)
> > > > > > > > >
> > > > > > > > >        /*
> > > > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > > > >         */
> > > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > > IOMUXC_GPR14,
> > > > > > > > >
> > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > > IOMUXC_GPR14,
> > > > > > > > >
> > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > > > [Richard Zhu] regmap bits operations should manipulate
> > > > > > > according
> > > bits.
> > > > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > > > >
> > > > > > > > >
> > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag
> > > > > > > > > that needs to be set true to implement the above code?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Richard,
> > > > > > > >
> > > > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > > > pinmuxing CLKREQ in my dt to work around the issue and
> > > > > > > > after removed the above did not resolve my issue. The
> > > > > > > > setting of OVERRIDE_EN was wrong above (should not be set
> > > > > > > > to '1' but
> > > > > > > > BIT(10)
> > > > > > > > instead) but this code already exists in
> > > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > > > > > > > patch
> > > so this is not the issue.
> > > > > > > >
> > > > > > > > What makes my board work is to clear GPR14 bit9 (like the
> > > > > > > > NXP kernel
> > > > > > > > does) so I don't think this bit does what we think it does
> > > > > > > > (select between internal and ext clk). I think setting it
> > > > > > > > enables clock gating via
> > > > > > > CLKREQ#.
> > > > > > > >
> > > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE
> > > > > > > > logic should be moved to the new phy driver for IMX8MM.
> > > > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > > > CLKREQ# to be low.
> > > > > > > I will think about that and add this in later v5 patch-set
> > > > > > > if nobody has different concerns.
> > > > > > > Thanks.
> > > > > > [Richard Zhu] Hi Tim:
> > > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for
> > > > > > PCIe on
> > > > > your board, right?
> > > > > > " (I have boards that use the only two possible pins for
> > > > > > CLKREQ as other
> > > > > features)"
> > > > > >
> > > > > > Did the override configuration of the clkreq# will bring
> > > > > > unexpected results
> > > > > for other features on your board?
> > > > > >
> > > > >
> > > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4
> and
> > > > > UART4 and because I2C4_SCL and UART4_RXD are the only two
> pads
> > > > > that could be pinmuxed for CLKREQ# I can't use the workaround of
> > > > > pin muxing
> > > it.
> > > > >
> > > > > Currently your driver only works on my imx8mm-venice-* boards if
> > > > > I add one of the following on boards that don't connect those
> > > > > pads (or if I clear
> > > > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > > > >
> > > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > > > enable this code already in the imx6_pcie_enable_ref_clk
> > > > > function to override REF_CLK and drive it low:
> > > > >
> > > > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > > > /*
> > > > > * Set the over ride low and enabled
> > > > > * make sure that REF_CLK is turned on.
> > > > > */
> > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > > > >    0);
> > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > > > >
> > > > > So this is already being run and yet my boards still do not work
> > > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is
> what
> > > > > the NXP downstream driver does:
> > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > > > >
> > > > > This is why I'm not sure that bit does what you think it does...
> > > > > I feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > > > >
> > > > > You tell me the descriptions for GPR14 are wrong in the reference
> manual.
> > > > > Please provide correct descriptions for us so we can sort this out.
> > > > >
> > > > [Richard Zhu] Hi Tim:
> > > > The BIT9 of GPR14 is used as
> "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on
> i.MX8MM.
> > > > I think the two bits descriptions are used to describe the BIT19
> > > > and BIT9
> > > together refer to my guess.
> > > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > > > 2'b00: External Reference Clock I/O (for PLL) Disable
> > > > 2'b01: External Reference Clock I/O (for PLL) Enable
> > > > 2'b10: External Reference Clock I/O (for PLL) Disable
> > > > 2'b11: External Reference Clock I/O (for PLL) output is controlled
> > > > by CLKREQ#
> > > >
> > > > The option1&3 should be forbidden, since the external REF CLK I/O
> > > > should
> > > be enabled on your board and EVK board.
> > > > In the option2&4, the BIT19 should be set to be 1'b1.'
> > > >
> > > > So, regarding my understand, if the CLKREQ# is not pinmuxed in
> > > > your use
> > > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> > > >
> > >
> > > Richard,
> > >
> > > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c
> > > for IMX8MM should not touch GPR14 and '[v3,9/9] PCI: imx: add the
> imx8mm pcie support'
> > > should have this on top and squashed:
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 7c89bd1a6441..458d54c8e385 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> > > imx6_pcie *imx6_pcie)
> > >                 break;
> > >         case IMX7D:
> > >                 break;
> > > -       case IMX8MQ:
> > >         case IMX8MM:
> > > +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > > +               if (ret)
> > > +                       dev_err(dev, "unable to enable
> pcie_aux
> > > clock\n");
> > > +               break;
> > > +       case IMX8MQ:
> > >                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > >                 if (ret) {
> > >                         dev_err(dev, "unable to enable
> pcie_aux
> > > clock\n");
> > >
> > [Richard Zhu] Sorry, I might don't understand what's meaning of the
> changes.
> > What're the differences between before and after the changes?
> >
> 
> The above change to your patch 'only' calls clk_prepare_enable for
> IMX8MM and does not touch GPR14 bits as the IMX8MQ case does
> (because as you point out the GPR14 bits differ between IMX8MM and
> IMX8MQ).
[Richard Zhu] Got that, thanks a lot.

> 
> > >
> > > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie
> > > standalone phy driver' should have this on top and squashed:
> > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > index 317cf61bff37..27ca0b9f1d92 100644
> > > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > @@ -43,7 +43,7 @@
> > >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> > >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> > >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> > >
> > >  struct imx8_pcie_phy {
> > >         u32                     refclk_pad_mode;
> > > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
> > >         reset_control_assert(imx8_phy->reset);
> > >
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > > -                          imx8_phy->refclk_pad_mode == 1 ?
> > > -                          IMX8MM_GPR_PCIE_REF_USE_PAD :
> 0);
> > > +
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > > +                          0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >                            IMX8MM_GPR_PCIE_AUX_EN,
> > > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > > +                          imx8_phy->refclk_pad_mode ==
> > > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >                            IMX8MM_GPR_PCIE_POWER_OFF,
> 0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14, @@
> > > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> > >
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >
> IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > > -                          imx8_phy->refclk_pad_mode == 1 ?
> > > +                          imx8_phy->refclk_pad_mode ==
> > > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > >
> IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > >
> IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > >         usleep_range(100, 200);
> > >
> > > I tested this and it works both on imx8mm-evk and imx8mm-venice-*
> > > which both have external clkgen.
> > >
> > > However, the above does not set
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE for
> > > the case where CLKREQ# is connected and thus should be used so I
> > > think we need to add a property for that to define if CLKREQ# is
> > > hooked up or not. I tested enabling
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> > > and as expected that worked on the imx8mm-evk which hooks up
> CLKREQ#
> > > but not imx8mm-venice which does not hook up CLKREQ#.
> > >
> > > What do you think about adding a property for this?
> > [Richard Zhu] First of all, thanks a lot for your help to figure out the
> details.
> > Agree with your proposal.
> > One optional property "fsl,clkreq-unsupported" would be added for the
> CLKREQ# not hooked case later.
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > index 097ba2a28fb4..2264452924cc 100644
> > --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > @@ -58,6 +58,11 @@ properties:
> >      $ref: /schemas/types.yaml#/definitions/uint32
> >      default: 0
> >
> > +  fsl,clkreq-unsupported:
> > +    type: boolean
> > +    description: A boolean property whoes presence indicates the
> CLKREQ#
> > +      signal isn't supported in the HW board design (optional
> required).
> > +
> 
> A boolean property indicating the CLKREQ# signal is not supported in the
> board design (optional)
[Richard Zhu] Okay, would be updated later.

> 
> >
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > index 07eea39283ed..4b4402eaddcc 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -43,7 +43,7 @@
> >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> >
> >  struct imx8_pcie_phy {
> >         void __iomem            *base;
> > @@ -54,6 +54,7 @@ struct imx8_pcie_phy {
> >         u32                     refclk_pad_mode;
> >         u32                     tx_deemph_gen1;
> >         u32                     tx_deemph_gen2;
> > +       bool                    clkreq_unused;
> >  };
> >
> >  static int imx8_pcie_phy_init(struct phy *phy) @@ -65,13 +66,15 @@
> > static int imx8_pcie_phy_init(struct phy *phy)
> >         reset_control_assert(imx8_phy->reset);
> >
> >         pad_mode = imx8_phy->refclk_pad_mode;
> > +       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't
> hooked */
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > -                          pad_mode ==
> IMX8MM_GPR_PCIE_REF_USE_PAD ?
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD :
> 0);
> > +
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > +                          imx8_phy->clkreq_unused ?
> > +                          0 :
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_AUX_EN,
> > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > +                          pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
> > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_POWER_OFF,
> 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14, @@
> > -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct
> platform_device *pdev)
> >
> &imx8_phy->tx_deemph_gen2))
> >                 imx8_phy->tx_deemph_gen2 = 0;
> >
> > +       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
> > +               imx8_phy->clkreq_unused = true;
> > +       else
> > +               imx8_phy->clkreq_unused = false;
> > +
> >         imx8_phy->clk = devm_clk_get(dev, "ref");
> >         if (IS_ERR(imx8_phy->clk)) {
> >                 dev_err(dev, "failed to get imx pcie phy clock\n");
> >
> 
> Yes this looks good and works both on venice (with
> 'fsl,clkreq-unsupported' added) and on imx8mm-evk.
> 
> Thanks for working through this with me and please cc me on your v4
> submission.
[Richard Zhu] Welcome. I'm glad to have your help. Thanks a lot.
> 
> Best regards,
> 
> Tim

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Wednesday, October 27, 2021 11:41 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> pcie support
> 
> On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Wednesday, October 27, 2021 12:06 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> imx8mm
> > > pcie support
> > >
> > > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu
> <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> > > > > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device
> > > > > Tree Mailing List <devicetree@vger.kernel.org>; Linux ARM
> > > > > Mailing List <linux-arm-kernel@lists.infradead.org>; open list
> > > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> > > > > imx8mm pcie support
> > > > >
> > > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu
> > > > > <hongxing.zhu@nxp.com>
> > > > > wrote:
> > > > > >
> > > > > > Snipped...
> > > > > >
> > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have
> > > > > > > > > > > > > that defined in pinmux and I found that if I add
> > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > > > PCIe
> > > > > > > > > > > > > works on my board but this isn't a solution just
> > > > > > > > > > > > > a work-around (I have boards that use the only
> > > > > > > > > > > > > two possible pins for CLKREQ as other
> > > > > > > > > > > features).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > > > comment out the CLKREQ (which isn't required)
> > > > > > > > > > > > > the imx8mmevk will end up hanging like my
> > > > > > > > > > > boards:
> > > > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory
> > > > > > > > > > > > required, and should be
> > > > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > > > And this signal should be driven low by the PCIe
> > > > > > > > > > > > M.2 device to request the
> > > > > > > > > > > REF clock be available(active low).
> > > > > > > > > > > > So, there is such kind of CLKREQ# pin definition
> > > > > > > > > > > > on i.MX8MM EVK
> > > > > > > > board.
> > > > > > > > > > > >
> > > > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > > > always running if there is
> > > > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The way I understand it is CLKREQ# allows the host
> > > > > > > > > > > to disable the REFCLK when not needed for power
> > > > > > > > > > > savings so it would seem optional to implement that
> > > > > > > > > > > and if not implemented should be left unconnected on
> > > > > > > > the card.
> > > > > > > > > > >
> > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC,
> > > > > > > > > > this signal is
> > > > > > > > mandatory required.
> > > > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > > > low/high by RC or EP automatically if
> > > > > > > > L1ss modes are enabled.
> > > > > > > > > > You can make reference to the
> > > > > > > > > >
> "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> > > or
> > > > > the
> > > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base
> Specification, Rev.
> > > > > > > > 4.0 Version 1.0".
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > CLKREQ is only mandatory if you wish to support clock
> > > > > > > > > power management. Many boards with a PCI host
> controller
> > > > > > > > > do not support this.
> > > > > > > [Richard Zhu] Okay, understood.
> > > > > > >
> > > > > > > > >
> > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > +++
> b/arch/arm64/boot/dts/freescale/imx8mm-evk.d
> > > > > > > > > > > > > +++ tsi
> > > > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > > > >
> > > > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > > > +/*
> > > > > > > > > > > > >
> > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> 0x61
> > > > > > > > > > > > > +*/
> > > > > > > > > > > > >
> > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > > > 0x41
> > > > > > > > > > > > >                 >;
> > > > > > > > > > > > >         };
> > > > > > > > > > > > >
> > > > > > > > > > > > > I have PCIe working with a driver that I ported
> > > > > > > > > > > > > from NXP's kernel which differs from your driver
> > > > > > > > > > > > > in that the PCIe PHY is not abstracted to its
> > > > > > > > > > > > > own driver so I think this has something to do
> > > > > > > > > > > > > with the order in which the phy is reset or
> > > > > > > initialized?
> > > > > > > > > > > > > The configuration of
> > > > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't
> > > > > > > > > > > > be
> > > masked.
> > > > > > > > > > > > In the NXP's local BSP kernel, I just force
> > > > > > > > > > > > CLKREQ# low to level up the HW
> > > > > > > > > > > compatibility.
> > > > > > > > > > > > That's might the reason why the PCIe works on your
> > > > > > > > > > > > HW board although the
> > > > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > > > This method is a little rude and violate the SPEC,
> > > > > > > > > > > > and not recommended
> > > > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > > > So I drop this method in this series.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Sorry, I don't understand what you are saying here.
> > > > > > > > > > > Is there a change you are going to make to v4 that
> > > > > > > > > > > will make this work for the evk and my boards? What
> > > > > > > > > > > is that change
> > > exactly?
> > > > > > > > > > [Richard Zhu] No. What I said above is that the
> > > > > > > > > > CLKREQ# is forced to be low in NXP local BSP kernel. I
> > > > > > > > > > guess this might be the reason why your
> > > > > > > > board works.
> > > > > > > > > >
> > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force
> > > > > > > > > > the CLKREQ# to
> > > > > > > > be low.
> > > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one
> zero
> > > > > > > > > > to
> > > > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Ok, that makes sense. Those bits are not explained well
> > > > > > > > > in the IMX8MMRM. As my board's external REFCLK is
> always
> > > > > > > > > enabled that must gate the clock internally to the host
> > > > > > > > > controller
> > > block.
> > > > > > > > >
> > > > > > > > > I can confirm that asserting those GPR14 bits does
> > > > > > > > > resolve my
> > > issue:
> > > > > > > > >
> > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL
> BIT(11)
> > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> > > BIT(10)
> > > > > > > > >
> > > > > > > > >        /*
> > > > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > > > >         */
> > > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > > IOMUXC_GPR14,
> > > > > > > > >
> > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > > IOMUXC_GPR14,
> > > > > > > > >
> > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > > > [Richard Zhu] regmap bits operations should manipulate
> > > > > > > according
> > > bits.
> > > > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > > > >
> > > > > > > > >
> > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag
> > > > > > > > > that needs to be set true to implement the above code?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Richard,
> > > > > > > >
> > > > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > > > pinmuxing CLKREQ in my dt to work around the issue and
> > > > > > > > after removed the above did not resolve my issue. The
> > > > > > > > setting of OVERRIDE_EN was wrong above (should not be set
> > > > > > > > to '1' but
> > > > > > > > BIT(10)
> > > > > > > > instead) but this code already exists in
> > > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > > > > > > > patch
> > > so this is not the issue.
> > > > > > > >
> > > > > > > > What makes my board work is to clear GPR14 bit9 (like the
> > > > > > > > NXP kernel
> > > > > > > > does) so I don't think this bit does what we think it does
> > > > > > > > (select between internal and ext clk). I think setting it
> > > > > > > > enables clock gating via
> > > > > > > CLKREQ#.
> > > > > > > >
> > > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE
> > > > > > > > logic should be moved to the new phy driver for IMX8MM.
> > > > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > > > CLKREQ# to be low.
> > > > > > > I will think about that and add this in later v5 patch-set
> > > > > > > if nobody has different concerns.
> > > > > > > Thanks.
> > > > > > [Richard Zhu] Hi Tim:
> > > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for
> > > > > > PCIe on
> > > > > your board, right?
> > > > > > " (I have boards that use the only two possible pins for
> > > > > > CLKREQ as other
> > > > > features)"
> > > > > >
> > > > > > Did the override configuration of the clkreq# will bring
> > > > > > unexpected results
> > > > > for other features on your board?
> > > > > >
> > > > >
> > > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4
> and
> > > > > UART4 and because I2C4_SCL and UART4_RXD are the only two
> pads
> > > > > that could be pinmuxed for CLKREQ# I can't use the workaround of
> > > > > pin muxing
> > > it.
> > > > >
> > > > > Currently your driver only works on my imx8mm-venice-* boards if
> > > > > I add one of the following on boards that don't connect those
> > > > > pads (or if I clear
> > > > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > > > >
> > > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > > > enable this code already in the imx6_pcie_enable_ref_clk
> > > > > function to override REF_CLK and drive it low:
> > > > >
> > > > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > > > /*
> > > > > * Set the over ride low and enabled
> > > > > * make sure that REF_CLK is turned on.
> > > > > */
> > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > > > >    0);
> > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > > > >
> > > > > So this is already being run and yet my boards still do not work
> > > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is
> what
> > > > > the NXP downstream driver does:
> > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > > > >
> > > > > This is why I'm not sure that bit does what you think it does...
> > > > > I feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > > > >
> > > > > You tell me the descriptions for GPR14 are wrong in the reference
> manual.
> > > > > Please provide correct descriptions for us so we can sort this out.
> > > > >
> > > > [Richard Zhu] Hi Tim:
> > > > The BIT9 of GPR14 is used as
> "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on
> i.MX8MM.
> > > > I think the two bits descriptions are used to describe the BIT19
> > > > and BIT9
> > > together refer to my guess.
> > > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > > > 2'b00: External Reference Clock I/O (for PLL) Disable
> > > > 2'b01: External Reference Clock I/O (for PLL) Enable
> > > > 2'b10: External Reference Clock I/O (for PLL) Disable
> > > > 2'b11: External Reference Clock I/O (for PLL) output is controlled
> > > > by CLKREQ#
> > > >
> > > > The option1&3 should be forbidden, since the external REF CLK I/O
> > > > should
> > > be enabled on your board and EVK board.
> > > > In the option2&4, the BIT19 should be set to be 1'b1.'
> > > >
> > > > So, regarding my understand, if the CLKREQ# is not pinmuxed in
> > > > your use
> > > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> > > >
> > >
> > > Richard,
> > >
> > > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c
> > > for IMX8MM should not touch GPR14 and '[v3,9/9] PCI: imx: add the
> imx8mm pcie support'
> > > should have this on top and squashed:
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 7c89bd1a6441..458d54c8e385 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> > > imx6_pcie *imx6_pcie)
> > >                 break;
> > >         case IMX7D:
> > >                 break;
> > > -       case IMX8MQ:
> > >         case IMX8MM:
> > > +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > > +               if (ret)
> > > +                       dev_err(dev, "unable to enable
> pcie_aux
> > > clock\n");
> > > +               break;
> > > +       case IMX8MQ:
> > >                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > >                 if (ret) {
> > >                         dev_err(dev, "unable to enable
> pcie_aux
> > > clock\n");
> > >
> > [Richard Zhu] Sorry, I might don't understand what's meaning of the
> changes.
> > What're the differences between before and after the changes?
> >
> 
> The above change to your patch 'only' calls clk_prepare_enable for
> IMX8MM and does not touch GPR14 bits as the IMX8MQ case does
> (because as you point out the GPR14 bits differ between IMX8MM and
> IMX8MQ).
[Richard Zhu] Got that, thanks a lot.

> 
> > >
> > > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie
> > > standalone phy driver' should have this on top and squashed:
> > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > index 317cf61bff37..27ca0b9f1d92 100644
> > > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > @@ -43,7 +43,7 @@
> > >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> > >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> > >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> > >
> > >  struct imx8_pcie_phy {
> > >         u32                     refclk_pad_mode;
> > > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
> > >         reset_control_assert(imx8_phy->reset);
> > >
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > > -                          imx8_phy->refclk_pad_mode == 1 ?
> > > -                          IMX8MM_GPR_PCIE_REF_USE_PAD :
> 0);
> > > +
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > > +                          0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >                            IMX8MM_GPR_PCIE_AUX_EN,
> > > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > > +                          imx8_phy->refclk_pad_mode ==
> > > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >                            IMX8MM_GPR_PCIE_POWER_OFF,
> 0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14, @@
> > > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> > >
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >
> IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > > -                          imx8_phy->refclk_pad_mode == 1 ?
> > > +                          imx8_phy->refclk_pad_mode ==
> > > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > >
> IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > >
> IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > >         usleep_range(100, 200);
> > >
> > > I tested this and it works both on imx8mm-evk and imx8mm-venice-*
> > > which both have external clkgen.
> > >
> > > However, the above does not set
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE for
> > > the case where CLKREQ# is connected and thus should be used so I
> > > think we need to add a property for that to define if CLKREQ# is
> > > hooked up or not. I tested enabling
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> > > and as expected that worked on the imx8mm-evk which hooks up
> CLKREQ#
> > > but not imx8mm-venice which does not hook up CLKREQ#.
> > >
> > > What do you think about adding a property for this?
> > [Richard Zhu] First of all, thanks a lot for your help to figure out the
> details.
> > Agree with your proposal.
> > One optional property "fsl,clkreq-unsupported" would be added for the
> CLKREQ# not hooked case later.
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > index 097ba2a28fb4..2264452924cc 100644
> > --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > @@ -58,6 +58,11 @@ properties:
> >      $ref: /schemas/types.yaml#/definitions/uint32
> >      default: 0
> >
> > +  fsl,clkreq-unsupported:
> > +    type: boolean
> > +    description: A boolean property whoes presence indicates the
> CLKREQ#
> > +      signal isn't supported in the HW board design (optional
> required).
> > +
> 
> A boolean property indicating the CLKREQ# signal is not supported in the
> board design (optional)
[Richard Zhu] Okay, would be updated later.

> 
> >
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > index 07eea39283ed..4b4402eaddcc 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -43,7 +43,7 @@
> >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> >
> >  struct imx8_pcie_phy {
> >         void __iomem            *base;
> > @@ -54,6 +54,7 @@ struct imx8_pcie_phy {
> >         u32                     refclk_pad_mode;
> >         u32                     tx_deemph_gen1;
> >         u32                     tx_deemph_gen2;
> > +       bool                    clkreq_unused;
> >  };
> >
> >  static int imx8_pcie_phy_init(struct phy *phy) @@ -65,13 +66,15 @@
> > static int imx8_pcie_phy_init(struct phy *phy)
> >         reset_control_assert(imx8_phy->reset);
> >
> >         pad_mode = imx8_phy->refclk_pad_mode;
> > +       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't
> hooked */
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > -                          pad_mode ==
> IMX8MM_GPR_PCIE_REF_USE_PAD ?
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD :
> 0);
> > +
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > +                          imx8_phy->clkreq_unused ?
> > +                          0 :
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_AUX_EN,
> > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > +                          pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
> > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_POWER_OFF,
> 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14, @@
> > -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct
> platform_device *pdev)
> >
> &imx8_phy->tx_deemph_gen2))
> >                 imx8_phy->tx_deemph_gen2 = 0;
> >
> > +       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
> > +               imx8_phy->clkreq_unused = true;
> > +       else
> > +               imx8_phy->clkreq_unused = false;
> > +
> >         imx8_phy->clk = devm_clk_get(dev, "ref");
> >         if (IS_ERR(imx8_phy->clk)) {
> >                 dev_err(dev, "failed to get imx pcie phy clock\n");
> >
> 
> Yes this looks good and works both on venice (with
> 'fsl,clkreq-unsupported' added) and on imx8mm-evk.
> 
> Thanks for working through this with me and please cc me on your v4
> submission.
[Richard Zhu] Welcome. I'm glad to have your help. Thanks a lot.
> 
> Best regards,
> 
> Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Wednesday, October 27, 2021 11:41 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> linux-phy@lists.infradead.org; Device Tree Mailing List
> <devicetree@vger.kernel.org>; Linux ARM Mailing List
> <linux-arm-kernel@lists.infradead.org>; open list
> <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm
> pcie support
> 
> On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <hongxing.zhu@nxp.com>
> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <tharvey@gateworks.com>
> > > Sent: Wednesday, October 27, 2021 12:06 AM
> > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>;
> > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>;
> > > linux-phy@lists.infradead.org; Device Tree Mailing List
> > > <devicetree@vger.kernel.org>; Linux ARM Mailing List
> > > <linux-arm-kernel@lists.infradead.org>; open list
> > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> imx8mm
> > > pcie support
> > >
> > > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu
> <hongxing.zhu@nxp.com>
> > > wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Tim Harvey <tharvey@gateworks.com>
> > > > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > > > To: Richard Zhu <hongxing.zhu@nxp.com>
> > > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I
> > > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring
> > > > > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo
> > > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device
> > > > > Tree Mailing List <devicetree@vger.kernel.org>; Linux ARM
> > > > > Mailing List <linux-arm-kernel@lists.infradead.org>; open list
> > > > > <linux-kernel@vger.kernel.org>; Sascha Hauer
> > > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>
> > > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and
> > > > > imx8mm pcie support
> > > > >
> > > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu
> > > > > <hongxing.zhu@nxp.com>
> > > > > wrote:
> > > > > >
> > > > > > Snipped...
> > > > > >
> > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have
> > > > > > > > > > > > > that defined in pinmux and I found that if I add
> > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > > > > > > > PCIe
> > > > > > > > > > > > > works on my board but this isn't a solution just
> > > > > > > > > > > > > a work-around (I have boards that use the only
> > > > > > > > > > > > > two possible pins for CLKREQ as other
> > > > > > > > > > > features).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you
> > > > > > > > > > > > > comment out the CLKREQ (which isn't required)
> > > > > > > > > > > > > the imx8mmevk will end up hanging like my
> > > > > > > > > > > boards:
> > > > > > > > > > > > [Richard Zhu] Hi Tim:
> > > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory
> > > > > > > > > > > > required, and should be
> > > > > > > > > > > configured as an open drain, active low signal.
> > > > > > > > > > > > And this signal should be driven low by the PCIe
> > > > > > > > > > > > M.2 device to request the
> > > > > > > > > > > REF clock be available(active low).
> > > > > > > > > > > > So, there is such kind of CLKREQ# pin definition
> > > > > > > > > > > > on i.MX8MM EVK
> > > > > > > > board.
> > > > > > > > > > > >
> > > > > > > > > > > > Anyway, I think the external OSC circuit should be
> > > > > > > > > > > > always running if there is
> > > > > > > > > > > no CLKREQ# on your HW board design.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The way I understand it is CLKREQ# allows the host
> > > > > > > > > > > to disable the REFCLK when not needed for power
> > > > > > > > > > > savings so it would seem optional to implement that
> > > > > > > > > > > and if not implemented should be left unconnected on
> > > > > > > > the card.
> > > > > > > > > > >
> > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC,
> > > > > > > > > > this signal is
> > > > > > > > mandatory required.
> > > > > > > > > > Especially for the L1ss usages. This signal would be
> > > > > > > > > > OD(open drain), bi-directional, and might be driven
> > > > > > > > > > low/high by RC or EP automatically if
> > > > > > > > L1ss modes are enabled.
> > > > > > > > > > You can make reference to the
> > > > > > > > > >
> "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a",
> > > or
> > > > > the
> > > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base
> Specification, Rev.
> > > > > > > > 4.0 Version 1.0".
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > CLKREQ is only mandatory if you wish to support clock
> > > > > > > > > power management. Many boards with a PCI host
> controller
> > > > > > > > > do not support this.
> > > > > > > [Richard Zhu] Okay, understood.
> > > > > > >
> > > > > > > > >
> > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> > > > > > > > > > > > > +++
> b/arch/arm64/boot/dts/freescale/imx8mm-evk.d
> > > > > > > > > > > > > +++ tsi
> > > > > > > > > > > > > @@ -448,7 +448,9 @@
> > > > > > > > > > > > >
> > > > > > > > > > > > >         pinctrl_pcie0: pcie0grp {
> > > > > > > > > > > > >                 fsl,pins = <
> > > > > > > > > > > > > +/*
> > > > > > > > > > > > >
> > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> 0x61
> > > > > > > > > > > > > +*/
> > > > > > > > > > > > >
> > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21
> > > > > > > > > > > > > 0x41
> > > > > > > > > > > > >                 >;
> > > > > > > > > > > > >         };
> > > > > > > > > > > > >
> > > > > > > > > > > > > I have PCIe working with a driver that I ported
> > > > > > > > > > > > > from NXP's kernel which differs from your driver
> > > > > > > > > > > > > in that the PCIe PHY is not abstracted to its
> > > > > > > > > > > > > own driver so I think this has something to do
> > > > > > > > > > > > > with the order in which the phy is reset or
> > > > > > > initialized?
> > > > > > > > > > > > > The configuration of
> > > > > > > > > > > gpr14 bits looks correct to me.
> > > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't
> > > > > > > > > > > > be
> > > masked.
> > > > > > > > > > > > In the NXP's local BSP kernel, I just force
> > > > > > > > > > > > CLKREQ# low to level up the HW
> > > > > > > > > > > compatibility.
> > > > > > > > > > > > That's might the reason why the PCIe works on your
> > > > > > > > > > > > HW board although the
> > > > > > > > > > > CLKREQ# PIN is not defined.
> > > > > > > > > > > > This method is a little rude and violate the SPEC,
> > > > > > > > > > > > and not recommended
> > > > > > > > > > > although it levels up the HW compatibility.
> > > > > > > > > > > > So I drop this method in this series.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Sorry, I don't understand what you are saying here.
> > > > > > > > > > > Is there a change you are going to make to v4 that
> > > > > > > > > > > will make this work for the evk and my boards? What
> > > > > > > > > > > is that change
> > > exactly?
> > > > > > > > > > [Richard Zhu] No. What I said above is that the
> > > > > > > > > > CLKREQ# is forced to be low in NXP local BSP kernel. I
> > > > > > > > > > guess this might be the reason why your
> > > > > > > > board works.
> > > > > > > > > >
> > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force
> > > > > > > > > > the CLKREQ# to
> > > > > > > > be low.
> > > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one
> zero
> > > > > > > > > > to
> > > > > > > > CLKREQ_OVERRIDE(bit11).
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Ok, that makes sense. Those bits are not explained well
> > > > > > > > > in the IMX8MMRM. As my board's external REFCLK is
> always
> > > > > > > > > enabled that must gate the clock internally to the host
> > > > > > > > > controller
> > > block.
> > > > > > > > >
> > > > > > > > > I can confirm that asserting those GPR14 bits does
> > > > > > > > > resolve my
> > > issue:
> > > > > > > > >
> > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL
> BIT(11)
> > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN
> > > BIT(10)
> > > > > > > > >
> > > > > > > > >        /*
> > > > > > > > >         * for boards that do not connect CLKREQ#,
> > > > > > > > >         * override CLKREQ# and drive it low internally
> > > > > > > > >         */
> > > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > > IOMUXC_GPR14,
> > > > > > > > >
> > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0);
> > > > > > > > >        regmap_update_bits(imx8_phy->iomuxc_gpr,
> > > > > IOMUXC_GPR14,
> > > > > > > > >
> > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1);
> > > > > > > [Richard Zhu] regmap bits operations should manipulate
> > > > > > > according
> > > bits.
> > > > > > > The BIT(10) and BIT(11) should be touched actually.
> > > > > > >
> > > > > > > > >
> > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag
> > > > > > > > > that needs to be set true to implement the above code?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Richard,
> > > > > > > >
> > > > > > > > Sorry - spoke too soon. My test was flawed as I still was
> > > > > > > > pinmuxing CLKREQ in my dt to work around the issue and
> > > > > > > > after removed the above did not resolve my issue. The
> > > > > > > > setting of OVERRIDE_EN was wrong above (should not be set
> > > > > > > > to '1' but
> > > > > > > > BIT(10)
> > > > > > > > instead) but this code already exists in
> > > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your
> > > > > > > > patch
> > > so this is not the issue.
> > > > > > > >
> > > > > > > > What makes my board work is to clear GPR14 bit9 (like the
> > > > > > > > NXP kernel
> > > > > > > > does) so I don't think this bit does what we think it does
> > > > > > > > (select between internal and ext clk). I think setting it
> > > > > > > > enables clock gating via
> > > > > > > CLKREQ#.
> > > > > > > >
> > > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE
> > > > > > > > logic should be moved to the new phy driver for IMX8MM.
> > > > > > > [Richard Zhu] It sounds reasonable to consider to force the
> > > > > > > CLKREQ# to be low.
> > > > > > > I will think about that and add this in later v5 patch-set
> > > > > > > if nobody has different concerns.
> > > > > > > Thanks.
> > > > > > [Richard Zhu] Hi Tim:
> > > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for
> > > > > > PCIe on
> > > > > your board, right?
> > > > > > " (I have boards that use the only two possible pins for
> > > > > > CLKREQ as other
> > > > > features)"
> > > > > >
> > > > > > Did the override configuration of the clkreq# will bring
> > > > > > unexpected results
> > > > > for other features on your board?
> > > > > >
> > > > >
> > > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4
> and
> > > > > UART4 and because I2C4_SCL and UART4_RXD are the only two
> pads
> > > > > that could be pinmuxed for CLKREQ# I can't use the workaround of
> > > > > pin muxing
> > > it.
> > > > >
> > > > > Currently your driver only works on my imx8mm-venice-* boards if
> > > > > I add one of the following on boards that don't connect those
> > > > > pads (or if I clear
> > > > > IMX8MM_GPR_PCIE_REF_USE_PAD):
> > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B
> > > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B
> > > > >
> > > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does
> > > > > enable this code already in the imx6_pcie_enable_ref_clk
> > > > > function to override REF_CLK and drive it low:
> > > > >
> > > > > offset = imx6_pcie_grp_offset(imx6_pcie);
> > > > > /*
> > > > > * Set the over ride low and enabled
> > > > > * make sure that REF_CLK is turned on.
> > > > > */
> > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > > > >    0);
> > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > > > >    IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > > > >
> > > > > So this is already being run and yet my boards still do not work
> > > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is
> what
> > > > > the NXP downstream driver does:
> > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0);
> > > > >
> > > > > This is why I'm not sure that bit does what you think it does...
> > > > > I feel like that bit enables 'Use CLKREQ# to enable CLK'.
> > > > >
> > > > > You tell me the descriptions for GPR14 are wrong in the reference
> manual.
> > > > > Please provide correct descriptions for us so we can sort this out.
> > > > >
> > > > [Richard Zhu] Hi Tim:
> > > > The BIT9 of GPR14 is used as
> "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN"
> > > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on
> i.MX8MM.
> > > > I think the two bits descriptions are used to describe the BIT19
> > > > and BIT9
> > > together refer to my guess.
> > > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9),
> > > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) }
> > > > 2'b00: External Reference Clock I/O (for PLL) Disable
> > > > 2'b01: External Reference Clock I/O (for PLL) Enable
> > > > 2'b10: External Reference Clock I/O (for PLL) Disable
> > > > 2'b11: External Reference Clock I/O (for PLL) output is controlled
> > > > by CLKREQ#
> > > >
> > > > The option1&3 should be forbidden, since the external REF CLK I/O
> > > > should
> > > be enabled on your board and EVK board.
> > > > In the option2&4, the BIT19 should be set to be 1'b1.'
> > > >
> > > > So, regarding my understand, if the CLKREQ# is not pinmuxed in
> > > > your use
> > > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0.
> > > >
> > >
> > > Richard,
> > >
> > > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c
> > > for IMX8MM should not touch GPR14 and '[v3,9/9] PCI: imx: add the
> imx8mm pcie support'
> > > should have this on top and squashed:
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 7c89bd1a6441..458d54c8e385 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct
> > > imx6_pcie *imx6_pcie)
> > >                 break;
> > >         case IMX7D:
> > >                 break;
> > > -       case IMX8MQ:
> > >         case IMX8MM:
> > > +               ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > > +               if (ret)
> > > +                       dev_err(dev, "unable to enable
> pcie_aux
> > > clock\n");
> > > +               break;
> > > +       case IMX8MQ:
> > >                 ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > >                 if (ret) {
> > >                         dev_err(dev, "unable to enable
> pcie_aux
> > > clock\n");
> > >
> > [Richard Zhu] Sorry, I might don't understand what's meaning of the
> changes.
> > What're the differences between before and after the changes?
> >
> 
> The above change to your patch 'only' calls clk_prepare_enable for
> IMX8MM and does not touch GPR14 bits as the IMX8MQ case does
> (because as you point out the GPR14 bits differ between IMX8MM and
> IMX8MQ).
[Richard Zhu] Got that, thanks a lot.

> 
> > >
> > > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie
> > > standalone phy driver' should have this on top and squashed:
> > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > index 317cf61bff37..27ca0b9f1d92 100644
> > > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > @@ -43,7 +43,7 @@
> > >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> > >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> > >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> > >
> > >  struct imx8_pcie_phy {
> > >         u32                     refclk_pad_mode;
> > > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy)
> > >         reset_control_assert(imx8_phy->reset);
> > >
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > > -                          imx8_phy->refclk_pad_mode == 1 ?
> > > -                          IMX8MM_GPR_PCIE_REF_USE_PAD :
> 0);
> > > +
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > > +                          0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >                            IMX8MM_GPR_PCIE_AUX_EN,
> > > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > > +                          imx8_phy->refclk_pad_mode ==
> > > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >                            IMX8MM_GPR_PCIE_POWER_OFF,
> 0);
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14, @@
> > > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy)
> > >
> > >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > >
> IMX8MM_GPR_PCIE_REF_CLK_SEL,
> > > -                          imx8_phy->refclk_pad_mode == 1 ?
> > > +                          imx8_phy->refclk_pad_mode ==
> > > IMX8_PCIE_REFCLK_PAD_INPUT ?
> > >
> IMX8MM_GPR_PCIE_REF_CLK_EXT :
> > >
> IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > >         usleep_range(100, 200);
> > >
> > > I tested this and it works both on imx8mm-evk and imx8mm-venice-*
> > > which both have external clkgen.
> > >
> > > However, the above does not set
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE for
> > > the case where CLKREQ# is connected and thus should be used so I
> > > think we need to add a property for that to define if CLKREQ# is
> > > hooked up or not. I tested enabling
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE
> > > and as expected that worked on the imx8mm-evk which hooks up
> CLKREQ#
> > > but not imx8mm-venice which does not hook up CLKREQ#.
> > >
> > > What do you think about adding a property for this?
> > [Richard Zhu] First of all, thanks a lot for your help to figure out the
> details.
> > Agree with your proposal.
> > One optional property "fsl,clkreq-unsupported" would be added for the
> CLKREQ# not hooked case later.
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > index 097ba2a28fb4..2264452924cc 100644
> > --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
> > @@ -58,6 +58,11 @@ properties:
> >      $ref: /schemas/types.yaml#/definitions/uint32
> >      default: 0
> >
> > +  fsl,clkreq-unsupported:
> > +    type: boolean
> > +    description: A boolean property whoes presence indicates the
> CLKREQ#
> > +      signal isn't supported in the HW board design (optional
> required).
> > +
> 
> A boolean property indicating the CLKREQ# signal is not supported in the
> board design (optional)
[Richard Zhu] Okay, would be updated later.

> 
> >
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > index 07eea39283ed..4b4402eaddcc 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > @@ -43,7 +43,7 @@
> >  #define IMX8MM_GPR_PCIE_CMN_RST                BIT(18)
> >  #define IMX8MM_GPR_PCIE_POWER_OFF      BIT(17)
> >  #define IMX8MM_GPR_PCIE_SSC_EN         BIT(16)
> > -#define IMX8MM_GPR_PCIE_REF_USE_PAD    BIT(9)
> > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE        BIT(9)
> >
> >  struct imx8_pcie_phy {
> >         void __iomem            *base;
> > @@ -54,6 +54,7 @@ struct imx8_pcie_phy {
> >         u32                     refclk_pad_mode;
> >         u32                     tx_deemph_gen1;
> >         u32                     tx_deemph_gen2;
> > +       bool                    clkreq_unused;
> >  };
> >
> >  static int imx8_pcie_phy_init(struct phy *phy) @@ -65,13 +66,15 @@
> > static int imx8_pcie_phy_init(struct phy *phy)
> >         reset_control_assert(imx8_phy->reset);
> >
> >         pad_mode = imx8_phy->refclk_pad_mode;
> > +       /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't
> hooked */
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD,
> > -                          pad_mode ==
> IMX8MM_GPR_PCIE_REF_USE_PAD ?
> > -                          IMX8MM_GPR_PCIE_REF_USE_PAD :
> 0);
> > +
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE,
> > +                          imx8_phy->clkreq_unused ?
> > +                          0 :
> IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_AUX_EN,
> > -                          IMX8MM_GPR_PCIE_AUX_EN);
> > +                          pad_mode ==
> IMX8_PCIE_REFCLK_PAD_INPUT ?
> > +                          IMX8MM_GPR_PCIE_AUX_EN : 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14,
> >                            IMX8MM_GPR_PCIE_POWER_OFF,
> 0);
> >         regmap_update_bits(imx8_phy->iomuxc_gpr,
> IOMUXC_GPR14, @@
> > -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct
> platform_device *pdev)
> >
> &imx8_phy->tx_deemph_gen2))
> >                 imx8_phy->tx_deemph_gen2 = 0;
> >
> > +       if (of_property_read_bool(np, "fsl,clkreq-unsupported"))
> > +               imx8_phy->clkreq_unused = true;
> > +       else
> > +               imx8_phy->clkreq_unused = false;
> > +
> >         imx8_phy->clk = devm_clk_get(dev, "ref");
> >         if (IS_ERR(imx8_phy->clk)) {
> >                 dev_err(dev, "failed to get imx pcie phy clock\n");
> >
> 
> Yes this looks good and works both on venice (with
> 'fsl,clkreq-unsupported' added) and on imx8mm-evk.
> 
> Thanks for working through this with me and please cc me on your v4
> submission.
[Richard Zhu] Welcome. I'm glad to have your help. Thanks a lot.
> 
> Best regards,
> 
> Tim
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Marcel Ziswiler]

On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> one standalone PCIe PHY driver should be seperated from i.MX PCIe
> driver when enable i.MX8MM PCIe support.
> 
> This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
> PCIe support[6-9] to have whole view to review this patch-set.
> 
> The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> [2] and this PHY driver patch-set.

Whole series:

Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

BTW: I tested it on Verdin iMX8M Mini V1.1B without an external PCIe oscillator aka setting fsl,refclk-pad-mode
to IMX8_PCIE_REFCLK_PAD_OUTPUT which worked like a charm. Thanks!

> [1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/
> 
> Main changes v2 --> v3:
> - Regarding Lucas' comments.
>  - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
>  - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
>  - split the dts changes to SOC and board DT, and use the enum instead of raw value.
>  - update the license of the dt-binding header file.
> 
> Changes v1 --> v2:
> - Update the license of the dt-binding header file to make the license
>   compatible with dts files.
> - Fix the dt_binding_check errors.
> 
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig                                |   9 ++++
> drivers/phy/freescale/Makefile                               |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
> 9 files changed, 486 insertions(+), 3 deletions(-)
> 
> [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
> [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
> [PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
> [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
> [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Marcel Ziswiler]

On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> one standalone PCIe PHY driver should be seperated from i.MX PCIe
> driver when enable i.MX8MM PCIe support.
> 
> This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
> PCIe support[6-9] to have whole view to review this patch-set.
> 
> The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> [2] and this PHY driver patch-set.

Whole series:

Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

BTW: I tested it on Verdin iMX8M Mini V1.1B without an external PCIe oscillator aka setting fsl,refclk-pad-mode
to IMX8_PCIE_REFCLK_PAD_OUTPUT which worked like a charm. Thanks!

> [1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/
> 
> Main changes v2 --> v3:
> - Regarding Lucas' comments.
>  - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
>  - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
>  - split the dts changes to SOC and board DT, and use the enum instead of raw value.
>  - update the license of the dt-binding header file.
> 
> Changes v1 --> v2:
> - Update the license of the dt-binding header file to make the license
>   compatible with dts files.
> - Fix the dt_binding_check errors.
> 
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig                                |   9 ++++
> drivers/phy/freescale/Makefile                               |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
> 9 files changed, 486 insertions(+), 3 deletions(-)
> 
> [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
> [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
> [PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
> [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
> [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Marcel Ziswiler]

On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> one standalone PCIe PHY driver should be seperated from i.MX PCIe
> driver when enable i.MX8MM PCIe support.
> 
> This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM
> PCIe support[6-9] to have whole view to review this patch-set.
> 
> The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> [2] and this PHY driver patch-set.

Whole series:

Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

BTW: I tested it on Verdin iMX8M Mini V1.1B without an external PCIe oscillator aka setting fsl,refclk-pad-mode
to IMX8_PCIE_REFCLK_PAD_OUTPUT which worked like a charm. Thanks!

> [1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/
> 
> Main changes v2 --> v3:
> - Regarding Lucas' comments.
>  - to have a whole view to review the patches, send out the i.MX8MM PCIe support too.
>  - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver.
>  - split the dts changes to SOC and board DT, and use the enum instead of raw value.
>  - update the license of the dt-binding header file.
> 
> Changes v1 --> v2:
> - Update the license of the dt-binding header file to make the license
>   compatible with dts files.
> - Fix the dt_binding_check errors.
> 
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6 +++
> Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79 +++++++++++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |  53 ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi                    |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c                        |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig                                |   9 ++++
> drivers/phy/freescale/Makefile                               |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   | 218
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/dt-bindings/phy/phy-imx8-pcie.h                      |  14 ++++++
> 9 files changed, 486 insertions(+), 3 deletions(-)
> 
> [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support
> [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support
> [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie
> [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name
> [PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support
> [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm
> [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Sent: Tuesday, October 26, 2021 11:57 PM
> To: kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> l.stach@pengutronix.de; shawnguo@kernel.org; tharvey@gateworks.com;
> galak@kernel.crashing.org; Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-phy@lists.infradead.org; linux-arm-kernel@lists.infradead.org;
> kernel@pengutronix.de; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > driver when enable i.MX8MM PCIe support.
> >
> > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> >
> > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > [2] and this PHY driver patch-set.
> 
> Whole series:
> 
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> 
> BTW: I tested it on Verdin iMX8M Mini V1.1B without an external PCIe
> oscillator aka setting fsl,refclk-pad-mode to
> IMX8_PCIE_REFCLK_PAD_OUTPUT which worked like a charm. Thanks!
> 
[Richard Zhu] Thanks for your tests.

Best Regards
Richard Zhu

> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> 120
> >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> nxp.c
> >
> om%7Cbacb5db20f2d4aa7a4ad08d998993356%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3016
> >
> 35%7C0%7C0%7C637708606037565160%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> ;sdata=
> >
> Mmea0v4pP5VzSM%2F8sIStLkwvA0pY0h2lG4Vzvr8Gk%2F4%3D&amp;reserv
> ed=0
> > [2]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> 40
> > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> g.zhu%
> >
> 40nxp.com%7Cbacb5db20f2d4aa7a4ad08d998993356%7C686ea1d3bc2b4c6
> fa92cd99
> >
> c5c301635%7C0%7C0%7C637708606037565160%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjo
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp
> > ;sdata=5U%2BP0zL0OskhyB0RtH%2FsBwRn0B1Lb27ZSpjjhFD0wUo%3D&a
> mp;reserved
> > =0
> >
> > Main changes v2 --> v3:
> > - Regarding Lucas' comments.
> >  - to have a whole view to review the patches, send out the i.MX8MM
> PCIe support too.
> >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> PHY driver.
> >  - split the dts changes to SOC and board DT, and use the enum instead of
> raw value.
> >  - update the license of the dt-binding header file.
> >
> > Changes v1 --> v2:
> > - Update the license of the dt-binding header file to make the license
> >   compatible with dts files.
> > - Fix the dt_binding_check errors.
> >
> > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> +++
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > +++++++++++++++++++++++++++++
> >
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> 53
> > ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c
> > |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig
> > |   9 ++++
> drivers/phy/freescale/Makefile
> > |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> > 218
> >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++
> >
> include/dt-bindings/phy/phy-imx8-pcie.h                      |
>  14
> > ++++++
> > 9 files changed, 486 insertions(+), 3 deletions(-)
> >
> > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > add the imx8mm pcie support

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Sent: Tuesday, October 26, 2021 11:57 PM
> To: kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> l.stach@pengutronix.de; shawnguo@kernel.org; tharvey@gateworks.com;
> galak@kernel.crashing.org; Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-phy@lists.infradead.org; linux-arm-kernel@lists.infradead.org;
> kernel@pengutronix.de; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > driver when enable i.MX8MM PCIe support.
> >
> > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> >
> > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > [2] and this PHY driver patch-set.
> 
> Whole series:
> 
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> 
> BTW: I tested it on Verdin iMX8M Mini V1.1B without an external PCIe
> oscillator aka setting fsl,refclk-pad-mode to
> IMX8_PCIE_REFCLK_PAD_OUTPUT which worked like a charm. Thanks!
> 
[Richard Zhu] Thanks for your tests.

Best Regards
Richard Zhu

> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> 120
> >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> nxp.c
> >
> om%7Cbacb5db20f2d4aa7a4ad08d998993356%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3016
> >
> 35%7C0%7C0%7C637708606037565160%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> ;sdata=
> >
> Mmea0v4pP5VzSM%2F8sIStLkwvA0pY0h2lG4Vzvr8Gk%2F4%3D&amp;reserv
> ed=0
> > [2]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> 40
> > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> g.zhu%
> >
> 40nxp.com%7Cbacb5db20f2d4aa7a4ad08d998993356%7C686ea1d3bc2b4c6
> fa92cd99
> >
> c5c301635%7C0%7C0%7C637708606037565160%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjo
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp
> > ;sdata=5U%2BP0zL0OskhyB0RtH%2FsBwRn0B1Lb27ZSpjjhFD0wUo%3D&a
> mp;reserved
> > =0
> >
> > Main changes v2 --> v3:
> > - Regarding Lucas' comments.
> >  - to have a whole view to review the patches, send out the i.MX8MM
> PCIe support too.
> >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> PHY driver.
> >  - split the dts changes to SOC and board DT, and use the enum instead of
> raw value.
> >  - update the license of the dt-binding header file.
> >
> > Changes v1 --> v2:
> > - Update the license of the dt-binding header file to make the license
> >   compatible with dts files.
> > - Fix the dt_binding_check errors.
> >
> > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> +++
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > +++++++++++++++++++++++++++++
> >
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> 53
> > ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c
> > |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig
> > |   9 ++++
> drivers/phy/freescale/Makefile
> > |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> > 218
> >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++
> >
> include/dt-bindings/phy/phy-imx8-pcie.h                      |
>  14
> > ++++++
> > 9 files changed, 486 insertions(+), 3 deletions(-)
> >
> > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > add the imx8mm pcie support

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

RE: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie support

[Richard Zhu]

> -----Original Message-----
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Sent: Tuesday, October 26, 2021 11:57 PM
> To: kishon@ti.com; vkoul@kernel.org; robh@kernel.org;
> l.stach@pengutronix.de; shawnguo@kernel.org; tharvey@gateworks.com;
> galak@kernel.crashing.org; Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-phy@lists.infradead.org; linux-arm-kernel@lists.infradead.org;
> kernel@pengutronix.de; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie
> support
> 
> On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote:
> > refer to the discussion [1] when try to enable i.MX8MM PCIe support,
> > one standalone PCIe PHY driver should be seperated from i.MX PCIe
> > driver when enable i.MX8MM PCIe support.
> >
> > This patch-set adds the standalone PCIe PHY driver suport[1-5], and
> > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set.
> >
> > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver
> > [2] and this PHY driver patch-set.
> 
> Whole series:
> 
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> 
> BTW: I tested it on Verdin iMX8M Mini V1.1B without an external PCIe
> oscillator aka setting fsl,refclk-pad-mode to
> IMX8_PCIE_REFCLK_PAD_OUTPUT which worked like a charm. Thanks!
> 
[Richard Zhu] Thanks for your tests.

Best Regards
Richard Zhu

> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929
> 120
> >
> -3-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxing.zhu%40
> nxp.c
> >
> om%7Cbacb5db20f2d4aa7a4ad08d998993356%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3016
> >
> 35%7C0%7C0%7C637708606037565160%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> ;sdata=
> >
> Mmea0v4pP5VzSM%2F8sIStLkwvA0pY0h2lG4Vzvr8Gk%2F4%3D&amp;reserv
> ed=0
> > [2]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F202109102026
> 40
> > .980366-1-l.stach%40pengutronix.de%2F&amp;data=04%7C01%7Chongxin
> g.zhu%
> >
> 40nxp.com%7Cbacb5db20f2d4aa7a4ad08d998993356%7C686ea1d3bc2b4c6
> fa92cd99
> >
> c5c301635%7C0%7C0%7C637708606037565160%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjo
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp
> > ;sdata=5U%2BP0zL0OskhyB0RtH%2FsBwRn0B1Lb27ZSpjjhFD0wUo%3D&a
> mp;reserved
> > =0
> >
> > Main changes v2 --> v3:
> > - Regarding Lucas' comments.
> >  - to have a whole view to review the patches, send out the i.MX8MM
> PCIe support too.
> >  - move the PHY related bits manipulations of the GPR/SRC to standalone
> PHY driver.
> >  - split the dts changes to SOC and board DT, and use the enum instead of
> raw value.
> >  - update the license of the dt-binding header file.
> >
> > Changes v1 --> v2:
> > - Update the license of the dt-binding header file to make the license
> >   compatible with dts files.
> > - Fix the dt_binding_check errors.
> >
> > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml    |   6
> +++
> > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml |  79
> > +++++++++++++++++++++++++++++
> >
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi                |
> 53
> > ++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > |  46 ++++++++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c
> > |  63 ++++++++++++++++++++++-
> drivers/phy/freescale/Kconfig
> > |   9 ++++
> drivers/phy/freescale/Makefile
> > |   1 +
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c                   |
> > 218
> >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++
> >
> include/dt-bindings/phy/phy-imx8-pcie.h                      |
>  14
> > ++++++
> > 9 files changed, 486 insertions(+), 3 deletions(-)
> >
> > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the
> > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support
> > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support [PATCH v3
> > 4/9] arm64: dts: imx8mm-evk: add the pcie phy support [PATCH v3 5/9]
> > phy: freescale: pcie: initialize the imx8 pcie [PATCH v3 6/9]
> > dt-bindings: imx6q-pcie: Add PHY phandles and name [PATCH v3 7/9]
> > arm64: dts: imx8mm: add the pcie support [PATCH v3 8/9] arm64: dts:
> > imx8mm-evk: add the pcie support on imx8mm [PATCH v3 9/9] PCI: imx:
> > add the imx8mm pcie support

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