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/[email protected]/
[2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/[email protected]/
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
Add the PCIe support on i.MX8MM platforms.
Signed-off-by: Richard Zhu <[email protected]>
---
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
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 <[email protected]>
---
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
Add the PCIe PHY support on iMX8MM EVK boards.
And set the default reference clock mode.
Signed-off-by: Richard Zhu <[email protected]>
---
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
Add dt-binding for the standalone i.MX8 PCIe PHY driver.
Signed-off-by: Richard Zhu <[email protected]>
---
.../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 <[email protected]>
+
+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
i.MX8MM PCIe has the PHY. Add a PHY phandle and name properties
in the binding document.
Signed-off-by: Richard Zhu <[email protected]>
---
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
Add the PCIe support on i.MX8MM EVK board.
Signed-off-by: Richard Zhu <[email protected]>
---
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 = <®_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
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 <[email protected]>
---
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
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 <[email protected]>
> ---
> .../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.
> -----Original Message-----
> From: Rob Herring <[email protected]>
> Sent: Tuesday, October 12, 2021 9:18 PM
> To: Richard Zhu <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> dl-linux-imx <[email protected]>; [email protected];
> [email protected]
> 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 <[email protected]>
> > ---
> > .../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&data=04%7C01%7Chongxing.zhu
> %40nxp.com%7C64619a3cd64446cf204008d98d82ca07%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C0%7C637696415146711570%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C1000&sdata=jt2nbxfbKTBm1izvsYvsHEkMfSHqa6t
> 24B1sJICAtXE%3D&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.
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 <[email protected]>
> ---
> [...]
> @@ -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?
> -----Original Message-----
> From: Matthias Schiffer <[email protected]>
> Sent: Wednesday, October 13, 2021 8:46 PM
> To: Richard Zhu <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]
> 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 <[email protected]>
> > ---
> > [...]
> > @@ -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
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 <[email protected]>
> ---
> 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>;
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 <[email protected]>
> ---
> 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");
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 <[email protected]>
> ---
> 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], },
> {},
> };
>
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 <[email protected]>
> ---
> 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 = <®_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
On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <[email protected]> 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/[email protected]/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/[email protected]/
>
> 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 = ð1;
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
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 <[email protected]>
> ---
> 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
>
>
> -----Original Message-----
> From: Tim Harvey <[email protected]>
> Sent: Saturday, October 16, 2021 3:59 AM
> To: Richard Zhu <[email protected]>; Lucas Stach
> <[email protected]>
> Cc: Kishon Vijay Abraham I <[email protected]>; [email protected]; Rob Herring
> <[email protected]>; [email protected]; Shawn Guo
> <[email protected]>; [email protected]; Device Tree Mailing
> List <[email protected]>; Linux ARM Mailing List
> <[email protected]>; open list
> <[email protected]>; Sascha Hauer <[email protected]>;
> dl-linux-imx <[email protected]>
> 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 <[email protected]>
> 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&data=04%7C01%7Chongxing.zhu%40
> nxp.c
> >
> om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> 99c5c3016
> >
> 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> ;sdata=
> >
> Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&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&data=04%7C01%7Chongxin
> g.zhu%
> >
> 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> fa92cd99
> >
> c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjo
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&
> > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPYMo
> %3D&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 = ð1;
> 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
On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <[email protected]> wrote:
>
>
> > -----Original Message-----
> > From: Tim Harvey <[email protected]>
> > Sent: Saturday, October 16, 2021 3:59 AM
> > To: Richard Zhu <[email protected]>; Lucas Stach
> > <[email protected]>
> > Cc: Kishon Vijay Abraham I <[email protected]>; [email protected]; Rob Herring
> > <[email protected]>; [email protected]; Shawn Guo
> > <[email protected]>; [email protected]; Device Tree Mailing
> > List <[email protected]>; Linux ARM Mailing List
> > <[email protected]>; open list
> > <[email protected]>; Sascha Hauer <[email protected]>;
> > dl-linux-imx <[email protected]>
> > 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 <[email protected]>
> > 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&data=04%7C01%7Chongxing.zhu%40
> > nxp.c
> > >
> > om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > 99c5c3016
> > >
> > 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLj
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> > ;sdata=
> > >
> > Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&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&data=04%7C01%7Chongxin
> > g.zhu%
> > >
> > 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > fa92cd99
> > >
> > c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjo
> > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > 00&
> > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPYMo
> > %3D&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
> -----Original Message-----
> From: Tim Harvey <[email protected]>
> Sent: Tuesday, October 19, 2021 11:53 PM
> To: Richard Zhu <[email protected]>
> Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> [email protected]; Shawn Guo <[email protected]>;
> [email protected]; Device Tree Mailing List
> <[email protected]>; Linux ARM Mailing List
> <[email protected]>; open list
> <[email protected]>; Sascha Hauer <[email protected]>;
> dl-linux-imx <[email protected]>
> 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 <[email protected]>
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Tim Harvey <[email protected]>
> > > Sent: Saturday, October 16, 2021 3:59 AM
> > > To: Richard Zhu <[email protected]>; Lucas Stach
> > > <[email protected]>
> > > Cc: Kishon Vijay Abraham I <[email protected]>; [email protected]; Rob
> > > Herring <[email protected]>; [email protected]; Shawn Guo
> > > <[email protected]>; [email protected]; Device Tree
> > > Mailing List <[email protected]>; Linux ARM Mailing List
> > > <[email protected]>; open list
> > > <[email protected]>; Sascha Hauer
> > > <[email protected]>; dl-linux-imx <[email protected]>
> > > 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 <[email protected]>
> > > 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&data=04%7C01%7Chongxing.zhu%40
> > > nxp.c
> > > >
> > >
> om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > > 99c5c3016
> > > >
> > >
> 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > > JWIjoiMC4wLj
> > > >
> > >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> > > ;sdata=
> > > >
> > >
> Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&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&data=04%7C01%7Chon
> gxin
> > > g.zhu%
> > > >
> > >
> 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > > fa92cd99
> > > >
> > >
> c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > > sb3d8eyJWIjo
> > > >
> > >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > 00&
> > > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPY
> Mo
> > > %3D&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
On Tue, Oct 19, 2021 at 7:10 PM Richard Zhu <[email protected]> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <[email protected]>
> > Sent: Tuesday, October 19, 2021 11:53 PM
> > To: Richard Zhu <[email protected]>
> > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > [email protected]; Shawn Guo <[email protected]>;
> > [email protected]; Device Tree Mailing List
> > <[email protected]>; Linux ARM Mailing List
> > <[email protected]>; open list
> > <[email protected]>; Sascha Hauer <[email protected]>;
> > dl-linux-imx <[email protected]>
> > 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 <[email protected]>
> > wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <[email protected]>
> > > > Sent: Saturday, October 16, 2021 3:59 AM
> > > > To: Richard Zhu <[email protected]>; Lucas Stach
> > > > <[email protected]>
> > > > Cc: Kishon Vijay Abraham I <[email protected]>; [email protected]; Rob
> > > > Herring <[email protected]>; [email protected]; Shawn Guo
> > > > <[email protected]>; [email protected]; Device Tree
> > > > Mailing List <[email protected]>; Linux ARM Mailing List
> > > > <[email protected]>; open list
> > > > <[email protected]>; Sascha Hauer
> > > > <[email protected]>; dl-linux-imx <[email protected]>
> > > > 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 <[email protected]>
> > > > 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&data=04%7C01%7Chongxing.zhu%40
> > > > nxp.c
> > > > >
> > > >
> > om%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6fa92cd
> > > > 99c5c3016
> > > > >
> > > >
> > 35%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZsb3d8ey
> > > > JWIjoiMC4wLj
> > > > >
> > > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> > > > ;sdata=
> > > > >
> > > >
> > Z2TZCpdDUSoqrNB1X%2BXdoYNBe3dBDKUgkA4r%2F0TcdOg%3D&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&data=04%7C01%7Chon
> > gxin
> > > > g.zhu%
> > > > >
> > > >
> > 40nxp.com%7C4e3d8ee008d94327f99108d9901634be%7C686ea1d3bc2b4c6
> > > > fa92cd99
> > > > >
> > > >
> > c5c301635%7C0%7C0%7C637699247319711209%7CUnknown%7CTWFpbGZ
> > > > sb3d8eyJWIjo
> > > > >
> > > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > > 00&
> > > > > ;sdata=5h%2By%2FcBW%2BjFkyplUuN1nB5%2BAFHuwCUJBqvRh1RiPY
> > Mo
> > > > %3D&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
<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
On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <[email protected]> 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 <[email protected]>
> ---
> 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
>
On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <[email protected]> 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
> -----Original Message-----
> From: Tim Harvey <[email protected]>
> Sent: Friday, October 22, 2021 12:25 AM
> To: Richard Zhu <[email protected]>
> Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> [email protected]; Shawn Guo <[email protected]>;
> [email protected]; Device Tree Mailing List
> <[email protected]>; Linux ARM Mailing List
> <[email protected]>; open list
> <[email protected]>; Sascha Hauer <[email protected]>;
> dl-linux-imx <[email protected]>
> 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 <[email protected]>
> 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
> -----Original Message-----
> From: Tim Harvey <[email protected]>
> Sent: Friday, October 22, 2021 12:00 AM
> To: Richard Zhu <[email protected]>
> Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> [email protected]; Shawn Guo <[email protected]>;
> [email protected]; Device Tree Mailing List
> <[email protected]>; Linux ARM Mailing List
> <[email protected]>; open list
> <[email protected]>; Sascha Hauer <[email protected]>;
> dl-linux-imx <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> > ---
> > 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
> >
> -----Original Message-----
> From: Lucas Stach <[email protected]>
> Sent: Saturday, October 16, 2021 2:33 AM
> To: Richard Zhu <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>
> 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 <[email protected]>
> > ---
> > 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>;
>
> -----Original Message-----
> From: Rob Herring <[email protected]>
> Sent: Tuesday, October 19, 2021 3:18 AM
> To: Richard Zhu <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>
> 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 <[email protected]>
> > ---
> > 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
> >
> >
> -----Original Message-----
> From: Lucas Stach <[email protected]>
> Sent: Saturday, October 16, 2021 3:00 AM
> To: Richard Zhu <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>
> 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 <[email protected]>
> > ---
> > 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], },
> > {},
> > };
> >
>
> -----Original Message-----
> From: Lucas Stach <[email protected]>
> Sent: Saturday, October 16, 2021 3:04 AM
> To: Richard Zhu <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>
> 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 <[email protected]>
> > ---
> > 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 = <®_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
>
> -----Original Message-----
> From: Lucas Stach <[email protected]>
> Sent: Saturday, October 16, 2021 2:56 AM
> To: Richard Zhu <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>
> 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 <[email protected]>
> > ---
> > 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");
>
On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <[email protected]> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <[email protected]>
> > Sent: Friday, October 22, 2021 12:25 AM
> > To: Richard Zhu <[email protected]>
> > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > [email protected]; Shawn Guo <[email protected]>;
> > [email protected]; Device Tree Mailing List
> > <[email protected]>; Linux ARM Mailing List
> > <[email protected]>; open list
> > <[email protected]>; Sascha Hauer <[email protected]>;
> > dl-linux-imx <[email protected]>
> > 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 <[email protected]>
> > 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
On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <[email protected]> wrote:
>
> On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <[email protected]> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <[email protected]>
> > > Sent: Friday, October 22, 2021 12:25 AM
> > > To: Richard Zhu <[email protected]>
> > > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > > [email protected]; Shawn Guo <[email protected]>;
> > > [email protected]; Device Tree Mailing List
> > > <[email protected]>; Linux ARM Mailing List
> > > <[email protected]>; open list
> > > <[email protected]>; Sascha Hauer <[email protected]>;
> > > dl-linux-imx <[email protected]>
> > > 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 <[email protected]>
> > > 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
> -----Original Message-----
> From: Tim Harvey <[email protected]>
> Sent: Saturday, October 23, 2021 12:55 AM
> To: Richard Zhu <[email protected]>
> Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> [email protected]; Shawn Guo <[email protected]>;
> [email protected]; Device Tree Mailing List
> <[email protected]>; Linux ARM Mailing List
> <[email protected]>; open list
> <[email protected]>; Sascha Hauer <[email protected]>;
> dl-linux-imx <[email protected]>
> 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 <[email protected]>
> wrote:
> >
> > On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <[email protected]>
> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <[email protected]>
> > > > Sent: Friday, October 22, 2021 12:25 AM
> > > > To: Richard Zhu <[email protected]>
> > > > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > > > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > > > [email protected]; Shawn Guo <[email protected]>;
> > > > [email protected]; Device Tree Mailing List
> > > > <[email protected]>; Linux ARM Mailing List
> > > > <[email protected]>; open list
> > > > <[email protected]>; Sascha Hauer
> > > > <[email protected]>; dl-linux-imx <[email protected]>
> > > > 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 <[email protected]>
> > > > 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
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
On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <[email protected]> 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/[email protected]/
> -----Original Message-----
> From: Tim Harvey <[email protected]>
> Sent: Tuesday, October 26, 2021 1:15 AM
> To: Richard Zhu <[email protected]>
> Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> [email protected]; Shawn Guo <[email protected]>;
> [email protected]; Device Tree Mailing List
> <[email protected]>; Linux ARM Mailing List
> <[email protected]>; open list
> <[email protected]>; Sascha Hauer <[email protected]>;
> dl-linux-imx <[email protected]>
> 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 <[email protected]>
> 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&data=04%7C01%7
> Chongxing.zhu%40nxp.com%7Cb796532d98124790154a08d997daf1e4%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637707788885954739%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NRK9mIMkYsgcXzBsL
> I7GE62hy64Bumxr8WdCD1oh59w%3D&reserved=0
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 <[email protected]>
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/[email protected]/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/[email protected]/
>
> 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
On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <[email protected]> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <[email protected]>
> > Sent: Tuesday, October 26, 2021 1:15 AM
> > To: Richard Zhu <[email protected]>
> > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > [email protected]; Shawn Guo <[email protected]>;
> > [email protected]; Device Tree Mailing List
> > <[email protected]>; Linux ARM Mailing List
> > <[email protected]>; open list
> > <[email protected]>; Sascha Hauer <[email protected]>;
> > dl-linux-imx <[email protected]>
> > 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 <[email protected]>
> > 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
> -----Original Message-----
> From: Marcel Ziswiler <[email protected]>
> Sent: Tuesday, October 26, 2021 11:57 PM
> To: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; Richard Zhu <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>
> 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 <[email protected]>
>
> 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&data=04%7C01%7Chongxing.zhu%40
> nxp.c
> >
> om%7Cbacb5db20f2d4aa7a4ad08d998993356%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3016
> >
> 35%7C0%7C0%7C637708606037565160%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> ;sdata=
> >
> Mmea0v4pP5VzSM%2F8sIStLkwvA0pY0h2lG4Vzvr8Gk%2F4%3D&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&data=04%7C01%7Chongxin
> g.zhu%
> >
> 40nxp.com%7Cbacb5db20f2d4aa7a4ad08d998993356%7C686ea1d3bc2b4c6
> fa92cd99
> >
> c5c301635%7C0%7C0%7C637708606037565160%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjo
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&
> > ;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
> -----Original Message-----
> From: Tim Harvey <[email protected]>
> Sent: Wednesday, October 27, 2021 12:06 AM
> To: Richard Zhu <[email protected]>
> Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> [email protected]; Shawn Guo <[email protected]>;
> [email protected]; Device Tree Mailing List
> <[email protected]>; Linux ARM Mailing List
> <[email protected]>; open list
> <[email protected]>; Sascha Hauer <[email protected]>;
> dl-linux-imx <[email protected]>
> 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 <[email protected]>
> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <[email protected]>
> > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > To: Richard Zhu <[email protected]>
> > > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > > [email protected]; Shawn Guo <[email protected]>;
> > > [email protected]; Device Tree Mailing List
> > > <[email protected]>; Linux ARM Mailing List
> > > <[email protected]>; open list
> > > <[email protected]>; Sascha Hauer
> > > <[email protected]>; dl-linux-imx <[email protected]>
> > > 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 <[email protected]>
> > > 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
On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <[email protected]> wrote:
>
> > -----Original Message-----
> > From: Tim Harvey <[email protected]>
> > Sent: Wednesday, October 27, 2021 12:06 AM
> > To: Richard Zhu <[email protected]>
> > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > [email protected]; Shawn Guo <[email protected]>;
> > [email protected]; Device Tree Mailing List
> > <[email protected]>; Linux ARM Mailing List
> > <[email protected]>; open list
> > <[email protected]>; Sascha Hauer <[email protected]>;
> > dl-linux-imx <[email protected]>
> > 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 <[email protected]>
> > wrote:
> > >
> > > > -----Original Message-----
> > > > From: Tim Harvey <[email protected]>
> > > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > > To: Richard Zhu <[email protected]>
> > > > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > > > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > > > [email protected]; Shawn Guo <[email protected]>;
> > > > [email protected]; Device Tree Mailing List
> > > > <[email protected]>; Linux ARM Mailing List
> > > > <[email protected]>; open list
> > > > <[email protected]>; Sascha Hauer
> > > > <[email protected]>; dl-linux-imx <[email protected]>
> > > > 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 <[email protected]>
> > > > 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
> -----Original Message-----
> From: Tim Harvey <[email protected]>
> Sent: Wednesday, October 27, 2021 11:41 PM
> To: Richard Zhu <[email protected]>
> Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> [email protected]; Shawn Guo <[email protected]>;
> [email protected]; Device Tree Mailing List
> <[email protected]>; Linux ARM Mailing List
> <[email protected]>; open list
> <[email protected]>; Sascha Hauer <[email protected]>;
> dl-linux-imx <[email protected]>
> 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 <[email protected]>
> wrote:
> >
> > > -----Original Message-----
> > > From: Tim Harvey <[email protected]>
> > > Sent: Wednesday, October 27, 2021 12:06 AM
> > > To: Richard Zhu <[email protected]>
> > > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > > <[email protected]>; [email protected]; Rob Herring <[email protected]>;
> > > [email protected]; Shawn Guo <[email protected]>;
> > > [email protected]; Device Tree Mailing List
> > > <[email protected]>; Linux ARM Mailing List
> > > <[email protected]>; open list
> > > <[email protected]>; Sascha Hauer
> > > <[email protected]>; dl-linux-imx <[email protected]>
> > > 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
> <[email protected]>
> > > wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Tim Harvey <[email protected]>
> > > > > Sent: Tuesday, October 26, 2021 1:15 AM
> > > > > To: Richard Zhu <[email protected]>
> > > > > Cc: Lucas Stach <[email protected]>; Kishon Vijay Abraham I
> > > > > <[email protected]>; [email protected]; Rob Herring
> > > > > <[email protected]>; [email protected]; Shawn Guo
> > > > > <[email protected]>; [email protected]; Device
> > > > > Tree Mailing List <[email protected]>; Linux ARM
> > > > > Mailing List <[email protected]>; open list
> > > > > <[email protected]>; Sascha Hauer
> > > > > <[email protected]>; dl-linux-imx <[email protected]>
> > > > > 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
> > > > > <[email protected]>
> > > > > 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