| Message ID | 1634028078-2387-1-git-send-email-hongxing.zhu@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add the imx8m pcie phy driver and imx8mm pcie support | expand |
On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> wrote: > > refer to the discussion [1] when try to enable i.MX8MM PCIe support, > one standalone PCIe PHY driver should be seperated from i.MX PCIe > driver when enable i.MX8MM PCIe support. > > This patch-set adds the standalone PCIe PHY driver suport[1-5], and i.MX8MM > PCIe support[6-9] to have whole view to review this patch-set. > > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver > [2] and this PHY driver patch-set. > > [1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/ > [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/ > > Main changes v2 --> v3: > - Regarding Lucas' comments. > - to have a whole view to review the patches, send out the i.MX8MM PCIe support too. > - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver. > - split the dts changes to SOC and board DT, and use the enum instead of raw value. > - update the license of the dt-binding header file. > > Changes v1 --> v2: > - Update the license of the dt-binding header file to make the license > compatible with dts files. > - Fix the dt_binding_check errors. > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 +++ > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml | 79 +++++++++++++++++++++++++++++ > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 53 ++++++++++++++++++++ > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 46 ++++++++++++++++- > drivers/pci/controller/dwc/pci-imx6.c | 63 ++++++++++++++++++++++- > drivers/phy/freescale/Kconfig | 9 ++++ > drivers/phy/freescale/Makefile | 1 + > drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > include/dt-bindings/phy/phy-imx8-pcie.h | 14 ++++++ > 9 files changed, 486 insertions(+), 3 deletions(-) > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support > [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support > [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie > [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name > [PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support > [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm > [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support Richard and Lucas, Thanks for your collective work on this series! I have imx8mm-venice boards to test this on both with and without PCIe bridges. I've tested this on top of Shawn's imx/for-next (as blk-ctl has been merged there) and end up hanging waiting for PHY ready timeout. [ 1.454308] imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0 [ 1.466538] imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0 [ 1.476344] libphy: fec_enet_mii_bus: probed [ 1.602631] phy phy-32f00000.pcie-phy.0: phy init failed --> -110 [ 1.608775] imx6q-pcie 33800000.pcie: Waiting for PHY ready timeout! I can verify that imx8_pcie_phy_probe returns successfully and the the phy node (imx6_pcie->phy) was found. Here is the dt change I made for the imx8mm-venice-gw71xx-0x board that has no bridge: diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi index 91544576f145..e89e9cf7318e 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi @@ -5,6 +5,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> +#include <dt-bindings/phy/phy-imx8-pcie.h> / { aliases { @@ -33,6 +34,12 @@ }; }; + pcie0_refclk: pcie0-refclk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <100000000>; + }; + pps { compatible = "pps-gpio"; pinctrl-names = "default"; @@ -101,6 +108,27 @@ status = "okay"; }; +&pcie0 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pcie0>; + reset-gpio = <&gpio4 6 GPIO_ACTIVE_LOW>; + clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>, + <&clk IMX8MM_CLK_DUMMY>, <&pcie0_refclk>; + clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus"; + assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>, + <&clk IMX8MM_CLK_PCIE1_CTRL>; + assigned-clock-rates = <10000000>, <250000000>; + assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>, + <&clk IMX8MM_SYS_PLL2_250M>; + status = "okay"; +}; + +&pcie_phy { + fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>; + clocks = <&clk IMX8MM_CLK_DUMMY>; + status = "okay"; +}; + /* GPS */ &uart1 { pinctrl-names = "default"; @@ -162,6 +190,12 @@ >; }; + pinctrl_pcie0: pciegrp { + fsl,pins = < + MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6 0x41 + >; + }; + pinctrl_pps: ppsgrp { fsl,pins = < MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x41 and here are the changes to the imx8mm-venice-gw72xx-0x dt - this board has a PCIe bridge: diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi index b12ead847302..260ea93ebfc2 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi @@ -5,9 +5,11 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> +#include <dt-bindings/phy/phy-imx8-pcie.h> / { aliases { + ethernet1 = ð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
> -----Original Message----- > From: Tim Harvey <tharvey@gateworks.com> > Sent: Saturday, October 16, 2021 3:59 AM > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach > <l.stach@pengutronix.de> > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob Herring > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree Mailing > List <devicetree@vger.kernel.org>; Linux ARM Mailing List > <linux-arm-kernel@lists.infradead.org>; open list > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > support > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> > wrote: > > > > refer to the discussion [1] when try to enable i.MX8MM PCIe support, > > one standalone PCIe PHY driver should be seperated from i.MX PCIe > > driver when enable i.MX8MM PCIe support. > > > > This patch-set adds the standalone PCIe PHY driver suport[1-5], and > > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set. > > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver > > [2] and this PHY driver patch-set. > > > > [1] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > > > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929 > 120 > > > -3-l.stach%40pengutronix.de%2F&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 <hongxing.zhu@nxp.com> wrote: > > > > -----Original Message----- > > From: Tim Harvey <tharvey@gateworks.com> > > Sent: Saturday, October 16, 2021 3:59 AM > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach > > <l.stach@pengutronix.de> > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob Herring > > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree Mailing > > List <devicetree@vger.kernel.org>; Linux ARM Mailing List > > <linux-arm-kernel@lists.infradead.org>; open list > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > > dl-linux-imx <linux-imx@nxp.com> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > > support > > > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> > > wrote: > > > > > > refer to the discussion [1] when try to enable i.MX8MM PCIe support, > > > one standalone PCIe PHY driver should be seperated from i.MX PCIe > > > driver when enable i.MX8MM PCIe support. > > > > > > This patch-set adds the standalone PCIe PHY driver suport[1-5], and > > > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set. > > > > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver > > > [2] and this PHY driver patch-set. > > > > > > [1] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > > > > > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929 > > 120 > > > > > -3-l.stach%40pengutronix.de%2F&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 <tharvey@gateworks.com> > Sent: Tuesday, October 19, 2021 11:53 PM > To: Richard Zhu <hongxing.zhu@nxp.com> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > linux-phy@lists.infradead.org; Device Tree Mailing List > <devicetree@vger.kernel.org>; Linux ARM Mailing List > <linux-arm-kernel@lists.infradead.org>; open list > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > support > > On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com> > wrote: > > > > > > > -----Original Message----- > > > From: Tim Harvey <tharvey@gateworks.com> > > > Sent: Saturday, October 16, 2021 3:59 AM > > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach > > > <l.stach@pengutronix.de> > > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob > > > Herring <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree > > > Mailing List <devicetree@vger.kernel.org>; Linux ARM Mailing List > > > <linux-arm-kernel@lists.infradead.org>; open list > > > <linux-kernel@vger.kernel.org>; Sascha Hauer > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm > > > pcie support > > > > > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> > > > wrote: > > > > > > > > refer to the discussion [1] when try to enable i.MX8MM PCIe > > > > support, one standalone PCIe PHY driver should be seperated from > > > > i.MX PCIe driver when enable i.MX8MM PCIe support. > > > > > > > > This patch-set adds the standalone PCIe PHY driver suport[1-5], > > > > and i.MX8MM PCIe support[6-9] to have whole view to review this > patch-set. > > > > > > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power > > > > driver [2] and this PHY driver patch-set. > > > > > > > > [1] > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > patc > > > > > > > > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929 > > > 120 > > > > > > > > -3-l.stach%40pengutronix.de%2F&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 <hongxing.zhu@nxp.com> wrote: > > > -----Original Message----- > > From: Tim Harvey <tharvey@gateworks.com> > > Sent: Tuesday, October 19, 2021 11:53 PM > > To: Richard Zhu <hongxing.zhu@nxp.com> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > linux-phy@lists.infradead.org; Device Tree Mailing List > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > <linux-arm-kernel@lists.infradead.org>; open list > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > > dl-linux-imx <linux-imx@nxp.com> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > > support > > > > On Mon, Oct 18, 2021 at 7:10 PM Richard Zhu <hongxing.zhu@nxp.com> > > wrote: > > > > > > > > > > -----Original Message----- > > > > From: Tim Harvey <tharvey@gateworks.com> > > > > Sent: Saturday, October 16, 2021 3:59 AM > > > > To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach > > > > <l.stach@pengutronix.de> > > > > Cc: Kishon Vijay Abraham I <kishon@ti.com>; vkoul@kernel.org; Rob > > > > Herring <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo > > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device Tree > > > > Mailing List <devicetree@vger.kernel.org>; Linux ARM Mailing List > > > > <linux-arm-kernel@lists.infradead.org>; open list > > > > <linux-kernel@vger.kernel.org>; Sascha Hauer > > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com> > > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm > > > > pcie support > > > > > > > > On Tue, Oct 12, 2021 at 2:06 AM Richard Zhu <hongxing.zhu@nxp.com> > > > > wrote: > > > > > > > > > > refer to the discussion [1] when try to enable i.MX8MM PCIe > > > > > support, one standalone PCIe PHY driver should be seperated from > > > > > i.MX PCIe driver when enable i.MX8MM PCIe support. > > > > > > > > > > This patch-set adds the standalone PCIe PHY driver suport[1-5], > > > > > and i.MX8MM PCIe support[6-9] to have whole view to review this > > patch-set. > > > > > > > > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power > > > > > driver [2] and this PHY driver patch-set. > > > > > > > > > > [1] > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > > patc > > > > > > > > > > > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929 > > > > 120 > > > > > > > > > > > -3-l.stach%40pengutronix.de%2F&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 Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com> wrote: > > <snipped...> > > > > Richard, > > > > What is this 'invalid resource' about? I see that with my downstream > > IMX8MM PCIe driver as well and have been asked about it. > > > [Richard Zhu] Hi Tim: > This complain is caused by the following codes in pcie-designware.c driver. > I'm not sure that why there is only size assignment after the res valid check, and do nothing if the res is invalid. > It seems that it is an expected design logic refer to the later codes. > if (!pci->atu_base) { > struct resource *res = > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu"); > if (res) > pci->atu_size = resource_size(res); > pci->atu_base = devm_ioremap_resource(dev, res); > if (IS_ERR(pci->atu_base)) > pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET; > } > > Since the default offset is used on i.MX8MM, the "atu" is not specified in i.MX8MM PCIe DT node, so there is no real res at all. > Then, devm_ioremap_resource() would complain the invalid resource. I think you are saying a change should be made like this: diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c index a945f0c0e73d..3254f60d1713 100644 --- a/drivers/pci/controller/dwc/pcie-designware.c +++ b/drivers/pci/controller/dwc/pcie-designware.c @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci) if (!pci->atu_base) { struct resource *res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu"); - if (res) + if (res) { pci->atu_size = resource_size(res); - pci->atu_base = devm_ioremap_resource(dev, res); - if (IS_ERR(pci->atu_base)) + pci->atu_base = devm_ioremap_resource(dev, res); + } + if (!pci->atu_base || IS_ERR(pci->atu_base)) pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET; } so that it looks like this: if (!pci->atu_base) { struct resource *res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu"); if (res) { pci->atu_size = resource_size(res); pci->atu_base = devm_ioremap_resource(dev, res); } if (!pci->atu_base || IS_ERR(pci->atu_base)) pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET; } Right? > > > > [ 1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled > > > [ 1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 > > outbound, 4 inbound > > > [ 1.429803] imx6q-pcie 33800000.pcie: Link up > > > [ 1.534497] imx6q-pcie 33800000.pcie: Link up > > > [ 1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2 > > > [ 1.550364] imx6q-pcie 33800000.pcie: Link up > > > [ 1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00 > > > [ 1.565545] pci_bus 0000:00: root bus resource [bus 00-ff] > > > [ 1.573834] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > > > [ 1.580055] pci_bus 0000:00: root bus resource [mem > > 0x18000000-0x1fefffff] > > > [ 1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 > > > [ 1.592997] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff] > > > [ 1.599282] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff > > pref] > > > [ 1.606033] pci 0000:00:00.0: supports D1 > > > [ 1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot > > D3cold > > > [ 1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802 > > > [ 1.624293] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff > > 64bit] > > > [ 1.631177] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff > > 64bit] > > > [ 1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with > > 8.0 GT/s PCIe x4 link) > > > [ 1.664931] pci 0000:00:00.0: BAR 0: assigned [mem > > 0x18000000-0x180fffff] > > > [ 1.671745] pci 0000:00:00.0: BAR 14: assigned [mem > > 0x18100000-0x181fffff] > > > [ 1.678634] pci 0000:00:00.0: BAR 6: assigned [mem > > 0x18200000-0x1820ffff pref] > > > [ 1.685873] pci 0000:01:00.0: BAR 0: assigned [mem > > 0x18100000-0x18103fff 64bit] > > > [ 1.693222] pci 0000:01:00.0: BAR 4: assigned [mem > > 0x18104000-0x181040ff 64bit] > > > [ 1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff] > > > [ 1.705814] pci 0000:00:00.0: bridge window [mem > > 0x18100000-0x181fffff] > > > [ 1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216 > > > " > > > Regarding the log you pasted, it seems that the clock is not feed to PHY > > properly. > > > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks for your > > great help to make the double tests. > > > > > > > My boards do not use CLKREQ# so I do not have that defined in pinmux and I > > found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B PCIe > > works on my board but this isn't a solution just a work-around (I have boards > > that use the only two possible pins for CLKREQ as other features). > > > > Similarly you will find on the imx8mm-evk if you comment out the CLKREQ > > (which isn't required) the imx8mmevk will end up hanging like my boards: > [Richard Zhu] Hi Tim: > Regarding the SPEC, the CLKREQ# is mandatory required, and should be configured as an open drain, active low signal. > And this signal should be driven low by the PCIe M.2 device to request the REF clock be available(active low). > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board. > > Anyway, I think the external OSC circuit should be always running if there is no CLKREQ# on your HW board design. > The way I understand it is CLKREQ# allows the host to disable the REFCLK when not needed for power savings so it would seem optional to implement that and if not implemented should be left unconnected on the card. > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > index 5ce43daa0c8b..f0023b48f475 100644 > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > @@ -448,7 +448,9 @@ > > > > pinctrl_pcie0: pcie0grp { > > fsl,pins = < > > +/* > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > +*/ > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > 0x41 > > >; > > }; > > > > I have PCIe working with a driver that I ported from NXP's kernel which differs > > from your driver in that the PCIe PHY is not abstracted to its own driver so I > > think this has something to do with the order in which the phy is reset or > > initialized? The configuration of gpr14 bits looks correct to me. > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked. > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW compatibility. > That's might the reason why the PCIe works on your HW board although the CLKREQ# PIN is not defined. > This method is a little rude and violate the SPEC, and not recommended although it levels up the HW compatibility. > So I drop this method in this series. > Sorry, I don't understand what you are saying here. Is there a change you are going to make to v4 that will make this work for the evk and my boards? What is that change exactly? I responded to your "phy: freescale: pcie: initialize the imx8 pcie standalone phy driver" submission as I don't understand the GPR14 bit documentation from the IMX8MMRM. Best regards, Tim
> -----Original Message----- > From: Tim Harvey <tharvey@gateworks.com> > Sent: Friday, October 22, 2021 12:25 AM > To: Richard Zhu <hongxing.zhu@nxp.com> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > linux-phy@lists.infradead.org; Device Tree Mailing List > <devicetree@vger.kernel.org>; Linux ARM Mailing List > <linux-arm-kernel@lists.infradead.org>; open list > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > support > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com> > wrote: > > > > <snipped...> > > > > > > Richard, > > > > > > What is this 'invalid resource' about? I see that with my downstream > > > IMX8MM PCIe driver as well and have been asked about it. > > > > > [Richard Zhu] Hi Tim: > > This complain is caused by the following codes in pcie-designware.c driver. > > I'm not sure that why there is only size assignment after the res valid check, > and do nothing if the res is invalid. > > It seems that it is an expected design logic refer to the later codes. > > if (!pci->atu_base) { > > struct resource *res = > > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu"); > > if (res) > > pci->atu_size = resource_size(res); > > pci->atu_base = > devm_ioremap_resource(dev, res); > > if (IS_ERR(pci->atu_base)) > > pci->atu_base = pci->dbi_base + > DEFAULT_DBI_ATU_OFFSET; > > } > > > > Since the default offset is used on i.MX8MM, the "atu" is not specified in > i.MX8MM PCIe DT node, so there is no real res at all. > > Then, devm_ioremap_resource() would complain the invalid resource. > > I think you are saying a change should be made like this: > diff --git a/drivers/pci/controller/dwc/pcie-designware.c > b/drivers/pci/controller/dwc/pcie-designware.c > index a945f0c0e73d..3254f60d1713 100644 > --- a/drivers/pci/controller/dwc/pcie-designware.c > +++ b/drivers/pci/controller/dwc/pcie-designware.c > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci) > if (!pci->atu_base) { > struct resource *res = > > platform_get_resource_byname(pdev, > IORESOURCE_MEM, "atu"); > - if (res) > + if (res) { > pci->atu_size = resource_size(res); > - pci->atu_base = devm_ioremap_resource(dev, > res); > - if (IS_ERR(pci->atu_base)) > + pci->atu_base = > devm_ioremap_resource(dev, res); > + } > + if (!pci->atu_base || IS_ERR(pci->atu_base)) > pci->atu_base = pci->dbi_base + > DEFAULT_DBI_ATU_OFFSET; > } > > so that it looks like this: > if (!pci->atu_base) { > struct resource *res = > > platform_get_resource_byname(pdev, > IORESOURCE_MEM, "atu"); > if (res) { > pci->atu_size = resource_size(res); > pci->atu_base = > devm_ioremap_resource(dev, res); > } > if (!pci->atu_base || IS_ERR(pci->atu_base)) > pci->atu_base = pci->dbi_base + > DEFAULT_DBI_ATU_OFFSET; > } > > Right? [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory. > > > > > > > [ 1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled > > > > [ 1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 > > > outbound, 4 inbound > > > > [ 1.429803] imx6q-pcie 33800000.pcie: Link up > > > > [ 1.534497] imx6q-pcie 33800000.pcie: Link up > > > > [ 1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2 > > > > [ 1.550364] imx6q-pcie 33800000.pcie: Link up > > > > [ 1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus > 0000:00 > > > > [ 1.565545] pci_bus 0000:00: root bus resource [bus 00-ff] > > > > [ 1.573834] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > > > > [ 1.580055] pci_bus 0000:00: root bus resource [mem > > > 0x18000000-0x1fefffff] > > > > [ 1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 > > > > [ 1.592997] pci 0000:00:00.0: reg 0x10: [mem > 0x00000000-0x000fffff] > > > > [ 1.599282] pci 0000:00:00.0: reg 0x38: [mem > 0x00000000-0x0000ffff > > > pref] > > > > [ 1.606033] pci 0000:00:00.0: supports D1 > > > > [ 1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot > > > D3cold > > > > [ 1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802 > > > > [ 1.624293] pci 0000:01:00.0: reg 0x10: [mem > 0x00000000-0x00003fff > > > 64bit] > > > > [ 1.631177] pci 0000:01:00.0: reg 0x20: [mem > 0x00000000-0x000000ff > > > 64bit] > > > > [ 1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 > > > Gb/s with > > > 8.0 GT/s PCIe x4 link) > > > > [ 1.664931] pci 0000:00:00.0: BAR 0: assigned [mem > > > 0x18000000-0x180fffff] > > > > [ 1.671745] pci 0000:00:00.0: BAR 14: assigned [mem > > > 0x18100000-0x181fffff] > > > > [ 1.678634] pci 0000:00:00.0: BAR 6: assigned [mem > > > 0x18200000-0x1820ffff pref] > > > > [ 1.685873] pci 0000:01:00.0: BAR 0: assigned [mem > > > 0x18100000-0x18103fff 64bit] > > > > [ 1.693222] pci 0000:01:00.0: BAR 4: assigned [mem > > > 0x18104000-0x181040ff 64bit] > > > > [ 1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff] > > > > [ 1.705814] pci 0000:00:00.0: bridge window [mem > > > 0x18100000-0x181fffff] > > > > [ 1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216 > > > > " > > > > Regarding the log you pasted, it seems that the clock is not feed > > > > to PHY > > > properly. > > > > > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks > > > > for your > > > great help to make the double tests. > > > > > > > > > > My boards do not use CLKREQ# so I do not have that defined in pinmux > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > PCIe > > > works on my board but this isn't a solution just a work-around (I > > > have boards that use the only two possible pins for CLKREQ as other > features). > > > > > > Similarly you will find on the imx8mm-evk if you comment out the > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my > boards: > > [Richard Zhu] Hi Tim: > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be > configured as an open drain, active low signal. > > And this signal should be driven low by the PCIe M.2 device to request the > REF clock be available(active low). > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board. > > > > Anyway, I think the external OSC circuit should be always running if there is > no CLKREQ# on your HW board design. > > > > The way I understand it is CLKREQ# allows the host to disable the REFCLK > when not needed for power savings so it would seem optional to implement > that and if not implemented should be left unconnected on the card. > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required. Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be driven low/high by RC or EP automatically if L1ss modes are enabled. You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0". > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > @@ -448,7 +448,9 @@ > > > > > > pinctrl_pcie0: pcie0grp { > > > fsl,pins = < > > > +/* > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > +*/ > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > 0x41 > > > >; > > > }; > > > > > > I have PCIe working with a driver that I ported from NXP's kernel > > > which differs from your driver in that the PCIe PHY is not > > > abstracted to its own driver so I think this has something to do > > > with the order in which the phy is reset or initialized? The configuration of > gpr14 bits looks correct to me. > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked. > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW > compatibility. > > That's might the reason why the PCIe works on your HW board although the > CLKREQ# PIN is not defined. > > This method is a little rude and violate the SPEC, and not recommended > although it levels up the HW compatibility. > > So I drop this method in this series. > > > > Sorry, I don't understand what you are saying here. Is there a change you are > going to make to v4 that will make this work for the evk and my boards? What > is that change exactly? [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP local BSP kernel. I guess this might be the reason why your board works. BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low. Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11). BR Richard> > I responded to your "phy: freescale: pcie: initialize the imx8 pcie standalone > phy driver" submission as I don't understand the GPR14 bit documentation > from the IMX8MMRM. > > Best regards, > > Tim
On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> wrote: > > > -----Original Message----- > > From: Tim Harvey <tharvey@gateworks.com> > > Sent: Friday, October 22, 2021 12:25 AM > > To: Richard Zhu <hongxing.zhu@nxp.com> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > linux-phy@lists.infradead.org; Device Tree Mailing List > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > <linux-arm-kernel@lists.infradead.org>; open list > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > > dl-linux-imx <linux-imx@nxp.com> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > > support > > > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com> > > wrote: > > > > > > <snipped...> > > > > > > > > Richard, > > > > > > > > What is this 'invalid resource' about? I see that with my downstream > > > > IMX8MM PCIe driver as well and have been asked about it. > > > > > > > [Richard Zhu] Hi Tim: > > > This complain is caused by the following codes in pcie-designware.c driver. > > > I'm not sure that why there is only size assignment after the res valid check, > > and do nothing if the res is invalid. > > > It seems that it is an expected design logic refer to the later codes. > > > if (!pci->atu_base) { > > > struct resource *res = > > > > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu"); > > > if (res) > > > pci->atu_size = resource_size(res); > > > pci->atu_base = > > devm_ioremap_resource(dev, res); > > > if (IS_ERR(pci->atu_base)) > > > pci->atu_base = pci->dbi_base + > > DEFAULT_DBI_ATU_OFFSET; > > > } > > > > > > Since the default offset is used on i.MX8MM, the "atu" is not specified in > > i.MX8MM PCIe DT node, so there is no real res at all. > > > Then, devm_ioremap_resource() would complain the invalid resource. > > > > I think you are saying a change should be made like this: > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c > > b/drivers/pci/controller/dwc/pcie-designware.c > > index a945f0c0e73d..3254f60d1713 100644 > > --- a/drivers/pci/controller/dwc/pcie-designware.c > > +++ b/drivers/pci/controller/dwc/pcie-designware.c > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci) > > if (!pci->atu_base) { > > struct resource *res = > > > > platform_get_resource_byname(pdev, > > IORESOURCE_MEM, "atu"); > > - if (res) > > + if (res) { > > pci->atu_size = resource_size(res); > > - pci->atu_base = devm_ioremap_resource(dev, > > res); > > - if (IS_ERR(pci->atu_base)) > > + pci->atu_base = > > devm_ioremap_resource(dev, res); > > + } > > + if (!pci->atu_base || IS_ERR(pci->atu_base)) > > pci->atu_base = pci->dbi_base + > > DEFAULT_DBI_ATU_OFFSET; > > } > > > > so that it looks like this: > > if (!pci->atu_base) { > > struct resource *res = > > > > platform_get_resource_byname(pdev, > > IORESOURCE_MEM, "atu"); > > if (res) { > > pci->atu_size = resource_size(res); > > pci->atu_base = > > devm_ioremap_resource(dev, res); > > } > > if (!pci->atu_base || IS_ERR(pci->atu_base)) > > pci->atu_base = pci->dbi_base + > > DEFAULT_DBI_ATU_OFFSET; > > } > > > > Right? > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory. Ok, I will submit a patch for that. > > > > > > > > > > > [ 1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled > > > > > [ 1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 > > > > outbound, 4 inbound > > > > > [ 1.429803] imx6q-pcie 33800000.pcie: Link up > > > > > [ 1.534497] imx6q-pcie 33800000.pcie: Link up > > > > > [ 1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2 > > > > > [ 1.550364] imx6q-pcie 33800000.pcie: Link up > > > > > [ 1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus > > 0000:00 > > > > > [ 1.565545] pci_bus 0000:00: root bus resource [bus 00-ff] > > > > > [ 1.573834] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > > > > > [ 1.580055] pci_bus 0000:00: root bus resource [mem > > > > 0x18000000-0x1fefffff] > > > > > [ 1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 > > > > > [ 1.592997] pci 0000:00:00.0: reg 0x10: [mem > > 0x00000000-0x000fffff] > > > > > [ 1.599282] pci 0000:00:00.0: reg 0x38: [mem > > 0x00000000-0x0000ffff > > > > pref] > > > > > [ 1.606033] pci 0000:00:00.0: supports D1 > > > > > [ 1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot > > > > D3cold > > > > > [ 1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802 > > > > > [ 1.624293] pci 0000:01:00.0: reg 0x10: [mem > > 0x00000000-0x00003fff > > > > 64bit] > > > > > [ 1.631177] pci 0000:01:00.0: reg 0x20: [mem > > 0x00000000-0x000000ff > > > > 64bit] > > > > > [ 1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 > > > > Gb/s with > > > > 8.0 GT/s PCIe x4 link) > > > > > [ 1.664931] pci 0000:00:00.0: BAR 0: assigned [mem > > > > 0x18000000-0x180fffff] > > > > > [ 1.671745] pci 0000:00:00.0: BAR 14: assigned [mem > > > > 0x18100000-0x181fffff] > > > > > [ 1.678634] pci 0000:00:00.0: BAR 6: assigned [mem > > > > 0x18200000-0x1820ffff pref] > > > > > [ 1.685873] pci 0000:01:00.0: BAR 0: assigned [mem > > > > 0x18100000-0x18103fff 64bit] > > > > > [ 1.693222] pci 0000:01:00.0: BAR 4: assigned [mem > > > > 0x18104000-0x181040ff 64bit] > > > > > [ 1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff] > > > > > [ 1.705814] pci 0000:00:00.0: bridge window [mem > > > > 0x18100000-0x181fffff] > > > > > [ 1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216 > > > > > " > > > > > Regarding the log you pasted, it seems that the clock is not feed > > > > > to PHY > > > > properly. > > > > > > > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks > > > > > for your > > > > great help to make the double tests. > > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that defined in pinmux > > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > PCIe > > > > works on my board but this isn't a solution just a work-around (I > > > > have boards that use the only two possible pins for CLKREQ as other > > features). > > > > > > > > Similarly you will find on the imx8mm-evk if you comment out the > > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my > > boards: > > > [Richard Zhu] Hi Tim: > > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be > > configured as an open drain, active low signal. > > > And this signal should be driven low by the PCIe M.2 device to request the > > REF clock be available(active low). > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board. > > > > > > Anyway, I think the external OSC circuit should be always running if there is > > no CLKREQ# on your HW board design. > > > > > > > The way I understand it is CLKREQ# allows the host to disable the REFCLK > > when not needed for power savings so it would seem optional to implement > > that and if not implemented should be left unconnected on the card. > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required. > Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be > driven low/high by RC or EP automatically if L1ss modes are enabled. > You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or > the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0". > CLKREQ is only mandatory if you wish to support clock power management. Many boards with a PCI host controller do not support this. > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > @@ -448,7 +448,9 @@ > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > fsl,pins = < > > > > +/* > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > > +*/ > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > 0x41 > > > > >; > > > > }; > > > > > > > > I have PCIe working with a driver that I ported from NXP's kernel > > > > which differs from your driver in that the PCIe PHY is not > > > > abstracted to its own driver so I think this has something to do > > > > with the order in which the phy is reset or initialized? The configuration of > > gpr14 bits looks correct to me. > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked. > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW > > compatibility. > > > That's might the reason why the PCIe works on your HW board although the > > CLKREQ# PIN is not defined. > > > This method is a little rude and violate the SPEC, and not recommended > > although it levels up the HW compatibility. > > > So I drop this method in this series. > > > > > > > Sorry, I don't understand what you are saying here. Is there a change you are > > going to make to v4 that will make this work for the evk and my boards? What > > is that change exactly? > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP > local BSP kernel. I guess this might be the reason why your board works. > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low. > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11). > Ok, that makes sense. Those bits are not explained well in the IMX8MMRM. As my board's external REFCLK is always enabled that must gate the clock internally to the host controller block. I can confirm that asserting those GPR14 bits does resolve my issue: #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL BIT(11) #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN BIT(10) /* * for boards that do not connect CLKREQ#, * override CLKREQ# and drive it low internally */ regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); Should this be added as a 'fsl,clkreq-unsupported' flag that needs to be set true to implement the above code? Best regards, Tim
On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <tharvey@gateworks.com> wrote: > > On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> wrote: > > > > > -----Original Message----- > > > From: Tim Harvey <tharvey@gateworks.com> > > > Sent: Friday, October 22, 2021 12:25 AM > > > To: Richard Zhu <hongxing.zhu@nxp.com> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > > linux-phy@lists.infradead.org; Device Tree Mailing List > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > > <linux-arm-kernel@lists.infradead.org>; open list > > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > > > dl-linux-imx <linux-imx@nxp.com> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > > > support > > > > > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com> > > > wrote: > > > > > > > > <snipped...> > > > > > > > > > > Richard, > > > > > > > > > > What is this 'invalid resource' about? I see that with my downstream > > > > > IMX8MM PCIe driver as well and have been asked about it. > > > > > > > > > [Richard Zhu] Hi Tim: > > > > This complain is caused by the following codes in pcie-designware.c driver. > > > > I'm not sure that why there is only size assignment after the res valid check, > > > and do nothing if the res is invalid. > > > > It seems that it is an expected design logic refer to the later codes. > > > > if (!pci->atu_base) { > > > > struct resource *res = > > > > > > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu"); > > > > if (res) > > > > pci->atu_size = resource_size(res); > > > > pci->atu_base = > > > devm_ioremap_resource(dev, res); > > > > if (IS_ERR(pci->atu_base)) > > > > pci->atu_base = pci->dbi_base + > > > DEFAULT_DBI_ATU_OFFSET; > > > > } > > > > > > > > Since the default offset is used on i.MX8MM, the "atu" is not specified in > > > i.MX8MM PCIe DT node, so there is no real res at all. > > > > Then, devm_ioremap_resource() would complain the invalid resource. > > > > > > I think you are saying a change should be made like this: > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c > > > b/drivers/pci/controller/dwc/pcie-designware.c > > > index a945f0c0e73d..3254f60d1713 100644 > > > --- a/drivers/pci/controller/dwc/pcie-designware.c > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c > > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie *pci) > > > if (!pci->atu_base) { > > > struct resource *res = > > > > > > platform_get_resource_byname(pdev, > > > IORESOURCE_MEM, "atu"); > > > - if (res) > > > + if (res) { > > > pci->atu_size = resource_size(res); > > > - pci->atu_base = devm_ioremap_resource(dev, > > > res); > > > - if (IS_ERR(pci->atu_base)) > > > + pci->atu_base = > > > devm_ioremap_resource(dev, res); > > > + } > > > + if (!pci->atu_base || IS_ERR(pci->atu_base)) > > > pci->atu_base = pci->dbi_base + > > > DEFAULT_DBI_ATU_OFFSET; > > > } > > > > > > so that it looks like this: > > > if (!pci->atu_base) { > > > struct resource *res = > > > > > > platform_get_resource_byname(pdev, > > > IORESOURCE_MEM, "atu"); > > > if (res) { > > > pci->atu_size = resource_size(res); > > > pci->atu_base = > > > devm_ioremap_resource(dev, res); > > > } > > > if (!pci->atu_base || IS_ERR(pci->atu_base)) > > > pci->atu_base = pci->dbi_base + > > > DEFAULT_DBI_ATU_OFFSET; > > > } > > > > > > Right? > > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid resource memory. > > Ok, I will submit a patch for that. > > > > > > > > > > > > > > > > [ 1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled > > > > > > [ 1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 > > > > > outbound, 4 inbound > > > > > > [ 1.429803] imx6q-pcie 33800000.pcie: Link up > > > > > > [ 1.534497] imx6q-pcie 33800000.pcie: Link up > > > > > > [ 1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2 > > > > > > [ 1.550364] imx6q-pcie 33800000.pcie: Link up > > > > > > [ 1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus > > > 0000:00 > > > > > > [ 1.565545] pci_bus 0000:00: root bus resource [bus 00-ff] > > > > > > [ 1.573834] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > > > > > > [ 1.580055] pci_bus 0000:00: root bus resource [mem > > > > > 0x18000000-0x1fefffff] > > > > > > [ 1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 > > > > > > [ 1.592997] pci 0000:00:00.0: reg 0x10: [mem > > > 0x00000000-0x000fffff] > > > > > > [ 1.599282] pci 0000:00:00.0: reg 0x38: [mem > > > 0x00000000-0x0000ffff > > > > > pref] > > > > > > [ 1.606033] pci 0000:00:00.0: supports D1 > > > > > > [ 1.610053] pci 0000:00:00.0: PME# supported from D0 D1 D3hot > > > > > D3cold > > > > > > [ 1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class 0x010802 > > > > > > [ 1.624293] pci 0000:01:00.0: reg 0x10: [mem > > > 0x00000000-0x00003fff > > > > > 64bit] > > > > > > [ 1.631177] pci 0000:01:00.0: reg 0x20: [mem > > > 0x00000000-0x000000ff > > > > > 64bit] > > > > > > [ 1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, > > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 > > > > > Gb/s with > > > > > 8.0 GT/s PCIe x4 link) > > > > > > [ 1.664931] pci 0000:00:00.0: BAR 0: assigned [mem > > > > > 0x18000000-0x180fffff] > > > > > > [ 1.671745] pci 0000:00:00.0: BAR 14: assigned [mem > > > > > 0x18100000-0x181fffff] > > > > > > [ 1.678634] pci 0000:00:00.0: BAR 6: assigned [mem > > > > > 0x18200000-0x1820ffff pref] > > > > > > [ 1.685873] pci 0000:01:00.0: BAR 0: assigned [mem > > > > > 0x18100000-0x18103fff 64bit] > > > > > > [ 1.693222] pci 0000:01:00.0: BAR 4: assigned [mem > > > > > 0x18104000-0x181040ff 64bit] > > > > > > [ 1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff] > > > > > > [ 1.705814] pci 0000:00:00.0: bridge window [mem > > > > > 0x18100000-0x181fffff] > > > > > > [ 1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ 216 > > > > > > " > > > > > > Regarding the log you pasted, it seems that the clock is not feed > > > > > > to PHY > > > > > properly. > > > > > > > > > > > > Anyway, let's waiting for the v4 series, then make a try. Thanks > > > > > > for your > > > > > great help to make the double tests. > > > > > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that defined in pinmux > > > > > and I found that if I add MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > PCIe > > > > > works on my board but this isn't a solution just a work-around (I > > > > > have boards that use the only two possible pins for CLKREQ as other > > > features). > > > > > > > > > > Similarly you will find on the imx8mm-evk if you comment out the > > > > > CLKREQ (which isn't required) the imx8mmevk will end up hanging like my > > > boards: > > > > [Richard Zhu] Hi Tim: > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and should be > > > configured as an open drain, active low signal. > > > > And this signal should be driven low by the PCIe M.2 device to request the > > > REF clock be available(active low). > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK board. > > > > > > > > Anyway, I think the external OSC circuit should be always running if there is > > > no CLKREQ# on your HW board design. > > > > > > > > > > The way I understand it is CLKREQ# allows the host to disable the REFCLK > > > when not needed for power savings so it would seem optional to implement > > > that and if not implemented should be left unconnected on the card. > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is mandatory required. > > Especially for the L1ss usages. This signal would be OD(open drain), bi-directional, and might be > > driven low/high by RC or EP automatically if L1ss modes are enabled. > > You can make reference to the "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or > > the chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 Version 1.0". > > > > CLKREQ is only mandatory if you wish to support clock power > management. Many boards with a PCI host controller do not support > this. > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > @@ -448,7 +448,9 @@ > > > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > > fsl,pins = < > > > > > +/* > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > > > +*/ > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > > 0x41 > > > > > >; > > > > > }; > > > > > > > > > > I have PCIe working with a driver that I ported from NXP's kernel > > > > > which differs from your driver in that the PCIe PHY is not > > > > > abstracted to its own driver so I think this has something to do > > > > > with the order in which the phy is reset or initialized? The configuration of > > > gpr14 bits looks correct to me. > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked. > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level up the HW > > > compatibility. > > > > That's might the reason why the PCIe works on your HW board although the > > > CLKREQ# PIN is not defined. > > > > This method is a little rude and violate the SPEC, and not recommended > > > although it levels up the HW compatibility. > > > > So I drop this method in this series. > > > > > > > > > > Sorry, I don't understand what you are saying here. Is there a change you are > > > going to make to v4 that will make this work for the evk and my boards? What > > > is that change exactly? > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to be low in NXP > > local BSP kernel. I guess this might be the reason why your board works. > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to be low. > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to CLKREQ_OVERRIDE(bit11). > > > > Ok, that makes sense. Those bits are not explained well in the > IMX8MMRM. As my board's external REFCLK is always enabled that must > gate the clock internally to the host controller block. > > I can confirm that asserting those GPR14 bits does resolve my issue: > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL BIT(11) > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN BIT(10) > > /* > * for boards that do not connect CLKREQ#, > * override CLKREQ# and drive it low internally > */ > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs to > be set true to implement the above code? > Richard, Sorry - spoke too soon. My test was flawed as I still was pinmuxing CLKREQ in my dt to work around the issue and after removed the above did not resolve my issue. The setting of OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10) instead) but this code already exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch so this is not the issue. What makes my board work is to clear GPR14 bit9 (like the NXP kernel does) so I don't think this bit does what we think it does (select between internal and ext clk). I think setting it enables clock gating via CLKREQ#. This also points out that perhaps the CLKREQ_OVERRIDE logic should be moved to the new phy driver for IMX8MM. Best regards, Tim
> -----Original Message----- > From: Tim Harvey <tharvey@gateworks.com> > Sent: Saturday, October 23, 2021 12:55 AM > To: Richard Zhu <hongxing.zhu@nxp.com> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > linux-phy@lists.infradead.org; Device Tree Mailing List > <devicetree@vger.kernel.org>; Linux ARM Mailing List > <linux-arm-kernel@lists.infradead.org>; open list > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > support > > On Fri, Oct 22, 2021 at 8:59 AM Tim Harvey <tharvey@gateworks.com> > wrote: > > > > On Thu, Oct 21, 2021 at 5:43 PM Richard Zhu <hongxing.zhu@nxp.com> > wrote: > > > > > > > -----Original Message----- > > > > From: Tim Harvey <tharvey@gateworks.com> > > > > Sent: Friday, October 22, 2021 12:25 AM > > > > To: Richard Zhu <hongxing.zhu@nxp.com> > > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > > > linux-phy@lists.infradead.org; Device Tree Mailing List > > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > > > <linux-arm-kernel@lists.infradead.org>; open list > > > > <linux-kernel@vger.kernel.org>; Sascha Hauer > > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com> > > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and > > > > imx8mm pcie support > > > > > > > > On Wed, Oct 20, 2021 at 8:32 PM Richard Zhu <hongxing.zhu@nxp.com> > > > > wrote: > > > > > > > > > > <snipped...> > > > > > > > > > > > > Richard, > > > > > > > > > > > > What is this 'invalid resource' about? I see that with my > > > > > > downstream IMX8MM PCIe driver as well and have been asked > about it. > > > > > > > > > > > [Richard Zhu] Hi Tim: > > > > > This complain is caused by the following codes in pcie-designware.c > driver. > > > > > I'm not sure that why there is only size assignment after the > > > > > res valid check, > > > > and do nothing if the res is invalid. > > > > > It seems that it is an expected design logic refer to the later codes. > > > > > if (!pci->atu_base) { > > > > > struct resource *res = > > > > > > > > > platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu"); > > > > > if (res) > > > > > pci->atu_size = > resource_size(res); > > > > > pci->atu_base = > > > > devm_ioremap_resource(dev, res); > > > > > if (IS_ERR(pci->atu_base)) > > > > > pci->atu_base = > pci->dbi_base + > > > > DEFAULT_DBI_ATU_OFFSET; > > > > > } > > > > > > > > > > Since the default offset is used on i.MX8MM, the "atu" is not > > > > > specified in > > > > i.MX8MM PCIe DT node, so there is no real res at all. > > > > > Then, devm_ioremap_resource() would complain the invalid resource. > > > > > > > > I think you are saying a change should be made like this: > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c > > > > b/drivers/pci/controller/dwc/pcie-designware.c > > > > index a945f0c0e73d..3254f60d1713 100644 > > > > --- a/drivers/pci/controller/dwc/pcie-designware.c > > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c > > > > @@ -671,10 +671,11 @@ void dw_pcie_iatu_detect(struct dw_pcie > *pci) > > > > if (!pci->atu_base) { > > > > struct resource *res = > > > > > > > > platform_get_resource_byname(pdev, > > > > IORESOURCE_MEM, "atu"); > > > > - if (res) > > > > + if (res) { > > > > pci->atu_size = > resource_size(res); > > > > - pci->atu_base = > devm_ioremap_resource(dev, > > > > res); > > > > - if (IS_ERR(pci->atu_base)) > > > > + pci->atu_base = > > > > devm_ioremap_resource(dev, res); > > > > + } > > > > + if (!pci->atu_base || > > > > + IS_ERR(pci->atu_base)) > > > > pci->atu_base = pci->dbi_base > + > > > > DEFAULT_DBI_ATU_OFFSET; > > > > } > > > > > > > > so that it looks like this: > > > > if (!pci->atu_base) { > > > > struct resource *res = > > > > > > > > platform_get_resource_byname(pdev, > > > > IORESOURCE_MEM, "atu"); > > > > if (res) { > > > > pci->atu_size = > resource_size(res); > > > > pci->atu_base = > > > > devm_ioremap_resource(dev, res); > > > > } > > > > if (!pci->atu_base || > IS_ERR(pci->atu_base)) > > > > pci->atu_base = pci->dbi_base > + > > > > DEFAULT_DBI_ATU_OFFSET; > > > > } > > > > > > > > Right? > > > [Richard Zhu] Yes, it is. The res shouldn't be remapped if it is invalid > resource memory. > > > > Ok, I will submit a patch for that. > > [Richard Zhu] Thanks for your help. Please cc me, if you issue that patch. > > > > > > > > > > > > > > > > > > > [ 1.316305] imx6q-pcie 33800000.pcie: iATU unroll: enabled > > > > > > > [ 1.321799] imx6q-pcie 33800000.pcie: Detected iATU regions: > 4 > > > > > > outbound, 4 inbound > > > > > > > [ 1.429803] imx6q-pcie 33800000.pcie: Link up > > > > > > > [ 1.534497] imx6q-pcie 33800000.pcie: Link up > > > > > > > [ 1.538870] imx6q-pcie 33800000.pcie: Link up, Gen2 > > > > > > > [ 1.550364] imx6q-pcie 33800000.pcie: Link up > > > > > > > [ 1.550487] imx6q-pcie 33800000.pcie: PCI host bridge to bus > > > > 0000:00 > > > > > > > [ 1.565545] pci_bus 0000:00: root bus resource [bus 00-ff] > > > > > > > [ 1.573834] pci_bus 0000:00: root bus resource [io > 0x0000-0xffff] > > > > > > > [ 1.580055] pci_bus 0000:00: root bus resource [mem > > > > > > 0x18000000-0x1fefffff] > > > > > > > [ 1.586968] pci 0000:00:00.0: [16c3:abcd] type 01 class > 0x060400 > > > > > > > [ 1.592997] pci 0000:00:00.0: reg 0x10: [mem > > > > 0x00000000-0x000fffff] > > > > > > > [ 1.599282] pci 0000:00:00.0: reg 0x38: [mem > > > > 0x00000000-0x0000ffff > > > > > > pref] > > > > > > > [ 1.606033] pci 0000:00:00.0: supports D1 > > > > > > > [ 1.610053] pci 0000:00:00.0: PME# supported from D0 D1 > D3hot > > > > > > D3cold > > > > > > > [ 1.618206] pci 0000:01:00.0: [15b7:5002] type 00 class > 0x010802 > > > > > > > [ 1.624293] pci 0000:01:00.0: reg 0x10: [mem > > > > 0x00000000-0x00003fff > > > > > > 64bit] > > > > > > > [ 1.631177] pci 0000:01:00.0: reg 0x20: [mem > > > > 0x00000000-0x000000ff > > > > > > 64bit] > > > > > > > [ 1.638409] pci 0000:01:00.0: 4.000 Gb/s available PCIe > bandwidth, > > > > > > limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of > > > > > > 31.504 Gb/s with > > > > > > 8.0 GT/s PCIe x4 link) > > > > > > > [ 1.664931] pci 0000:00:00.0: BAR 0: assigned [mem > > > > > > 0x18000000-0x180fffff] > > > > > > > [ 1.671745] pci 0000:00:00.0: BAR 14: assigned [mem > > > > > > 0x18100000-0x181fffff] > > > > > > > [ 1.678634] pci 0000:00:00.0: BAR 6: assigned [mem > > > > > > 0x18200000-0x1820ffff pref] > > > > > > > [ 1.685873] pci 0000:01:00.0: BAR 0: assigned [mem > > > > > > 0x18100000-0x18103fff 64bit] > > > > > > > [ 1.693222] pci 0000:01:00.0: BAR 4: assigned [mem > > > > > > 0x18104000-0x181040ff 64bit] > > > > > > > [ 1.700577] pci 0000:00:00.0: PCI bridge to [bus 01-ff] > > > > > > > [ 1.705814] pci 0000:00:00.0: bridge window [mem > > > > > > 0x18100000-0x181fffff] > > > > > > > [ 1.712972] pcieport 0000:00:00.0: PME: Signaling with IRQ > 216 > > > > > > > " > > > > > > > Regarding the log you pasted, it seems that the clock is not > > > > > > > feed to PHY > > > > > > properly. > > > > > > > > > > > > > > Anyway, let's waiting for the v4 series, then make a try. > > > > > > > Thanks for your > > > > > > great help to make the double tests. > > > > > > > > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that defined in > > > > > > pinmux and I found that if I add > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > PCIe > > > > > > works on my board but this isn't a solution just a work-around > > > > > > (I have boards that use the only two possible pins for CLKREQ > > > > > > as other > > > > features). > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you comment out > > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up > > > > > > hanging like my > > > > boards: > > > > > [Richard Zhu] Hi Tim: > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and > > > > > should be > > > > configured as an open drain, active low signal. > > > > > And this signal should be driven low by the PCIe M.2 device to > > > > > request the > > > > REF clock be available(active low). > > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM EVK > board. > > > > > > > > > > Anyway, I think the external OSC circuit should be always > > > > > running if there is > > > > no CLKREQ# on your HW board design. > > > > > > > > > > > > > The way I understand it is CLKREQ# allows the host to disable the > > > > REFCLK when not needed for power savings so it would seem optional > > > > to implement that and if not implemented should be left unconnected on > the card. > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is > mandatory required. > > > Especially for the L1ss usages. This signal would be OD(open drain), > > > bi-directional, and might be driven low/high by RC or EP automatically if > L1ss modes are enabled. > > > You can make reference to the > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. 4.0 > Version 1.0". > > > > > > > CLKREQ is only mandatory if you wish to support clock power > > management. Many boards with a PCI host controller do not support > > this. [Richard Zhu] Okay, understood. > > > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > @@ -448,7 +448,9 @@ > > > > > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > > > fsl,pins = < > > > > > > +/* > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > > > > +*/ > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > > > 0x41 > > > > > > >; > > > > > > }; > > > > > > > > > > > > I have PCIe working with a driver that I ported from NXP's > > > > > > kernel which differs from your driver in that the PCIe PHY is > > > > > > not abstracted to its own driver so I think this has something > > > > > > to do with the order in which the phy is reset or initialized? > > > > > > The configuration of > > > > gpr14 bits looks correct to me. > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked. > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to level > > > > > up the HW > > > > compatibility. > > > > > That's might the reason why the PCIe works on your HW board > > > > > although the > > > > CLKREQ# PIN is not defined. > > > > > This method is a little rude and violate the SPEC, and not > > > > > recommended > > > > although it levels up the HW compatibility. > > > > > So I drop this method in this series. > > > > > > > > > > > > > Sorry, I don't understand what you are saying here. Is there a > > > > change you are going to make to v4 that will make this work for > > > > the evk and my boards? What is that change exactly? > > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced to > > > be low in NXP local BSP kernel. I guess this might be the reason why your > board works. > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# to > be low. > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to > CLKREQ_OVERRIDE(bit11). > > > > > > > Ok, that makes sense. Those bits are not explained well in the > > IMX8MMRM. As my board's external REFCLK is always enabled that must > > gate the clock internally to the host controller block. > > > > I can confirm that asserting those GPR14 bits does resolve my issue: > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL BIT(11) > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN BIT(10) > > > > /* > > * for boards that do not connect CLKREQ#, > > * override CLKREQ# and drive it low internally > > */ > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); [Richard Zhu] regmap bits operations should manipulate according bits. The BIT(10) and BIT(11) should be touched actually. > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs to > > be set true to implement the above code? > > > > Richard, > > Sorry - spoke too soon. My test was flawed as I still was pinmuxing CLKREQ in > my dt to work around the issue and after removed the above did not resolve > my issue. The setting of OVERRIDE_EN was wrong above (should not be set to > '1' but BIT(10) instead) but this code already exists in > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch so this is > not the issue. > > What makes my board work is to clear GPR14 bit9 (like the NXP kernel > does) so I don't think this bit does what we think it does (select between > internal and ext clk). I think setting it enables clock gating via CLKREQ#. > > This also points out that perhaps the CLKREQ_OVERRIDE logic should be > moved to the new phy driver for IMX8MM. [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be low. I will think about that and add this in later v5 patch-set if nobody has different concerns. Thanks. BR Richard > > Best regards, > > Tim
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 <hongxing.zhu@nxp.com> wrote: > > Snipped... > > > > > > > > > My boards do not use CLKREQ# so I do not have that defined > > > > > > > > in pinmux and I found that if I add > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > > > PCIe > > > > > > > > works on my board but this isn't a solution just a > > > > > > > > work-around (I have boards that use the only two possible > > > > > > > > pins for CLKREQ as other > > > > > > features). > > > > > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you comment out > > > > > > > > the CLKREQ (which isn't required) the imx8mmevk will end up > > > > > > > > hanging like my > > > > > > boards: > > > > > > > [Richard Zhu] Hi Tim: > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and > > > > > > > should be > > > > > > configured as an open drain, active low signal. > > > > > > > And this signal should be driven low by the PCIe M.2 device to > > > > > > > request the > > > > > > REF clock be available(active low). > > > > > > > So, there is such kind of CLKREQ# pin definition on i.MX8MM > > > > > > > EVK > > > board. > > > > > > > > > > > > > > Anyway, I think the external OSC circuit should be always > > > > > > > running if there is > > > > > > no CLKREQ# on your HW board design. > > > > > > > > > > > > > > > > > > > The way I understand it is CLKREQ# allows the host to disable > > > > > > the REFCLK when not needed for power savings so it would seem > > > > > > optional to implement that and if not implemented should be left > > > > > > unconnected on > > > the card. > > > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this signal is > > > mandatory required. > > > > > Especially for the L1ss usages. This signal would be OD(open > > > > > drain), bi-directional, and might be driven low/high by RC or EP > > > > > automatically if > > > L1ss modes are enabled. > > > > > You can make reference to the > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or the > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. > > > 4.0 Version 1.0". > > > > > > > > > > > > > CLKREQ is only mandatory if you wish to support clock power > > > > management. Many boards with a PCI host controller do not support > > > > this. > > [Richard Zhu] Okay, understood. > > > > > > > > > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > @@ -448,7 +448,9 @@ > > > > > > > > > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > > > > > fsl,pins = < > > > > > > > > +/* > > > > > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > > > > > > +*/ > > > > > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > > > > > 0x41 > > > > > > > > >; > > > > > > > > }; > > > > > > > > > > > > > > > > I have PCIe working with a driver that I ported from NXP's > > > > > > > > kernel which differs from your driver in that the PCIe PHY > > > > > > > > is not abstracted to its own driver so I think this has > > > > > > > > something to do with the order in which the phy is reset or > > initialized? > > > > > > > > The configuration of > > > > > > gpr14 bits looks correct to me. > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked. > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to > > > > > > > level up the HW > > > > > > compatibility. > > > > > > > That's might the reason why the PCIe works on your HW board > > > > > > > although the > > > > > > CLKREQ# PIN is not defined. > > > > > > > This method is a little rude and violate the SPEC, and not > > > > > > > recommended > > > > > > although it levels up the HW compatibility. > > > > > > > So I drop this method in this series. > > > > > > > > > > > > > > > > > > > Sorry, I don't understand what you are saying here. Is there a > > > > > > change you are going to make to v4 that will make this work for > > > > > > the evk and my boards? What is that change exactly? > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is forced > > > > > to be low in NXP local BSP kernel. I guess this might be the > > > > > reason why your > > > board works. > > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the CLKREQ# > > > > > to > > > be low. > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to > > > CLKREQ_OVERRIDE(bit11). > > > > > > > > > > > > > Ok, that makes sense. Those bits are not explained well in the > > > > IMX8MMRM. As my board's external REFCLK is always enabled that must > > > > gate the clock internally to the host controller block. > > > > > > > > I can confirm that asserting those GPR14 bits does resolve my issue: > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL BIT(11) > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN BIT(10) > > > > > > > > /* > > > > * for boards that do not connect CLKREQ#, > > > > * override CLKREQ# and drive it low internally > > > > */ > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); > > [Richard Zhu] regmap bits operations should manipulate according bits. > > The BIT(10) and BIT(11) should be touched actually. > > > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that needs > > > > to be set true to implement the above code? > > > > > > > > > > Richard, > > > > > > Sorry - spoke too soon. My test was flawed as I still was pinmuxing > > > CLKREQ in my dt to work around the issue and after removed the above > > > did not resolve my issue. The setting of OVERRIDE_EN was wrong above > > > (should not be set to '1' but BIT(10) instead) but this code already > > > exists in imx6_pcie_enable_ref_clk and is used for IMX8MM per your > > > patch so this is not the issue. > > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP kernel > > > does) so I don't think this bit does what we think it does (select > > > between internal and ext clk). I think setting it enables clock gating via > > CLKREQ#. > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should be > > > moved to the new phy driver for IMX8MM. > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# to be > > low. > > I will think about that and add this in later v5 patch-set if nobody has different > > concerns. > > Thanks. > [Richard Zhu] Hi Tim: > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on your board, right? > " (I have boards that use the only two possible pins for CLKREQ as other features)" > > Did the override configuration of the clkreq# will bring unexpected results for other features on your board? > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4 and because I2C4_SCL and UART4_RXD are the only two pads that could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing it. Currently your driver only works on my imx8mm-venice-* boards if I add one of the following on boards that don't connect those pads (or if I clear IMX8MM_GPR_PCIE_REF_USE_PAD): MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this code already in the imx6_pcie_enable_ref_clk function to override REF_CLK and drive it low: offset = imx6_pcie_grp_offset(imx6_pcie); /* * Set the over ride low and enabled * make sure that REF_CLK is turned on. */ regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE, 0); regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN, IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN); So this is already being run and yet my boards still do not work unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP downstream driver does: regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, IMX8MM_GPR_PCIE_REF_USE_PAD, 0); This is why I'm not sure that bit does what you think it does... I feel like that bit enables 'Use CLKREQ# to enable CLK'. You tell me the descriptions for GPR14 are wrong in the reference manual. Please provide correct descriptions for us so we can sort this out. Best regards, Tim [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1634028078-2387-10-git-send-email-hongxing.zhu@nxp.com/
> -----Original Message----- > From: Tim Harvey <tharvey@gateworks.com> > Sent: Tuesday, October 26, 2021 1:15 AM > To: Richard Zhu <hongxing.zhu@nxp.com> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > linux-phy@lists.infradead.org; Device Tree Mailing List > <devicetree@vger.kernel.org>; Linux ARM Mailing List > <linux-arm-kernel@lists.infradead.org>; open list > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > support > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com> > wrote: > > > > Snipped... > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that > > > > > > > > > defined in pinmux and I found that if I add > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > > > > PCIe > > > > > > > > > works on my board but this isn't a solution just a > > > > > > > > > work-around (I have boards that use the only two > > > > > > > > > possible pins for CLKREQ as other > > > > > > > features). > > > > > > > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you comment > > > > > > > > > out the CLKREQ (which isn't required) the imx8mmevk will > > > > > > > > > end up hanging like my > > > > > > > boards: > > > > > > > > [Richard Zhu] Hi Tim: > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and > > > > > > > > should be > > > > > > > configured as an open drain, active low signal. > > > > > > > > And this signal should be driven low by the PCIe M.2 > > > > > > > > device to request the > > > > > > > REF clock be available(active low). > > > > > > > > So, there is such kind of CLKREQ# pin definition on > > > > > > > > i.MX8MM EVK > > > > board. > > > > > > > > > > > > > > > > Anyway, I think the external OSC circuit should be always > > > > > > > > running if there is > > > > > > > no CLKREQ# on your HW board design. > > > > > > > > > > > > > > > > > > > > > > The way I understand it is CLKREQ# allows the host to > > > > > > > disable the REFCLK when not needed for power savings so it > > > > > > > would seem optional to implement that and if not implemented > > > > > > > should be left unconnected on > > > > the card. > > > > > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this > > > > > > signal is > > > > mandatory required. > > > > > > Especially for the L1ss usages. This signal would be OD(open > > > > > > drain), bi-directional, and might be driven low/high by RC or > > > > > > EP automatically if > > > > L1ss modes are enabled. > > > > > > You can make reference to the > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or > the > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. > > > > 4.0 Version 1.0". > > > > > > > > > > > > > > > > CLKREQ is only mandatory if you wish to support clock power > > > > > management. Many boards with a PCI host controller do not > > > > > support this. > > > [Richard Zhu] Okay, understood. > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > @@ -448,7 +448,9 @@ > > > > > > > > > > > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > > > > > > fsl,pins = < > > > > > > > > > +/* > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > > > > > > > +*/ > > > > > > > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > > > > > > 0x41 > > > > > > > > > >; > > > > > > > > > }; > > > > > > > > > > > > > > > > > > I have PCIe working with a driver that I ported from > > > > > > > > > NXP's kernel which differs from your driver in that the > > > > > > > > > PCIe PHY is not abstracted to its own driver so I think > > > > > > > > > this has something to do with the order in which the phy > > > > > > > > > is reset or > > > initialized? > > > > > > > > > The configuration of > > > > > > > gpr14 bits looks correct to me. > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked. > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to > > > > > > > > level up the HW > > > > > > > compatibility. > > > > > > > > That's might the reason why the PCIe works on your HW > > > > > > > > board although the > > > > > > > CLKREQ# PIN is not defined. > > > > > > > > This method is a little rude and violate the SPEC, and not > > > > > > > > recommended > > > > > > > although it levels up the HW compatibility. > > > > > > > > So I drop this method in this series. > > > > > > > > > > > > > > > > > > > > > > Sorry, I don't understand what you are saying here. Is there > > > > > > > a change you are going to make to v4 that will make this > > > > > > > work for the evk and my boards? What is that change exactly? > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is > > > > > > forced to be low in NXP local BSP kernel. I guess this might > > > > > > be the reason why your > > > > board works. > > > > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the > > > > > > CLKREQ# to > > > > be low. > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to > > > > CLKREQ_OVERRIDE(bit11). > > > > > > > > > > > > > > > > Ok, that makes sense. Those bits are not explained well in the > > > > > IMX8MMRM. As my board's external REFCLK is always enabled that > > > > > must gate the clock internally to the host controller block. > > > > > > > > > > I can confirm that asserting those GPR14 bits does resolve my issue: > > > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL BIT(11) > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN BIT(10) > > > > > > > > > > /* > > > > > * for boards that do not connect CLKREQ#, > > > > > * override CLKREQ# and drive it low internally > > > > > */ > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); > > > [Richard Zhu] regmap bits operations should manipulate according bits. > > > The BIT(10) and BIT(11) should be touched actually. > > > > > > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that > > > > > needs to be set true to implement the above code? > > > > > > > > > > > > > Richard, > > > > > > > > Sorry - spoke too soon. My test was flawed as I still was > > > > pinmuxing CLKREQ in my dt to work around the issue and after > > > > removed the above did not resolve my issue. The setting of > > > > OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10) > > > > instead) but this code already exists in imx6_pcie_enable_ref_clk > > > > and is used for IMX8MM per your patch so this is not the issue. > > > > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP > > > > kernel > > > > does) so I don't think this bit does what we think it does (select > > > > between internal and ext clk). I think setting it enables clock > > > > gating via > > > CLKREQ#. > > > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should > > > > be moved to the new phy driver for IMX8MM. > > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# > > > to be low. > > > I will think about that and add this in later v5 patch-set if nobody > > > has different concerns. > > > Thanks. > > [Richard Zhu] Hi Tim: > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on > your board, right? > > " (I have boards that use the only two possible pins for CLKREQ as other > features)" > > > > Did the override configuration of the clkreq# will bring unexpected results > for other features on your board? > > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4 > and because I2C4_SCL and UART4_RXD are the only two pads that could be > pinmuxed for CLKREQ# I can't use the workaround of pin muxing it. > > Currently your driver only works on my imx8mm-venice-* boards if I add one > of the following on boards that don't connect those pads (or if I clear > IMX8MM_GPR_PCIE_REF_USE_PAD): > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this > code already in the imx6_pcie_enable_ref_clk function to override REF_CLK > and drive it low: > > offset = imx6_pcie_grp_offset(imx6_pcie); > /* > * Set the over ride low and enabled > * make sure that REF_CLK is turned on. > */ > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE, > 0); > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN, > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN); > > So this is already being run and yet my boards still do not work unless I clr > IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP > downstream driver does: > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > IMX8MM_GPR_PCIE_REF_USE_PAD, 0); > > This is why I'm not sure that bit does what you think it does... I feel like that > bit enables 'Use CLKREQ# to enable CLK'. > > You tell me the descriptions for GPR14 are wrong in the reference manual. > Please provide correct descriptions for us so we can sort this out. > [Richard Zhu] Hi Tim: The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN" and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM. I think the two bits descriptions are used to describe the BIT19 and BIT9 together refer to my guess. {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) } 2'b00: External Reference Clock I/O (for PLL) Disable 2'b01: External Reference Clock I/O (for PLL) Enable 2'b10: External Reference Clock I/O (for PLL) Disable 2'b11: External Reference Clock I/O (for PLL) output is controlled by CLKREQ# The option1&3 should be forbidden, since the external REF CLK I/O should be enabled on your board and EVK board. In the option2&4, the BIT19 should be set to be 1'b1. So, regarding my understand, if the CLKREQ# is not pinmuxed in your use case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0. BR Richard > Best regards, > > Tim > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > work.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F1634028078-23 > 87-10-git-send-email-hongxing.zhu%40nxp.com%2F&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 <marcel.ziswiler@toradex.com> BTW: I tested it on Verdin iMX8M Mini V1.1B without an external PCIe oscillator aka setting fsl,refclk-pad-mode to IMX8_PCIE_REFCLK_PAD_OUTPUT which worked like a charm. Thanks! > [1] https://patchwork.ozlabs.org/project/linux-pci/patch/20210510141509.929120-3-l.stach@pengutronix.de/ > [2] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210910202640.980366-1-l.stach@pengutronix.de/ > > Main changes v2 --> v3: > - Regarding Lucas' comments. >  - to have a whole view to review the patches, send out the i.MX8MM PCIe support too. >  - move the PHY related bits manipulations of the GPR/SRC to standalone PHY driver. >  - split the dts changes to SOC and board DT, and use the enum instead of raw value. >  - update the license of the dt-binding header file. > > Changes v1 --> v2: > - Update the license of the dt-binding header file to make the license >  compatible with dts files. > - Fix the dt_binding_check errors. > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml   |  6 +++ > Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml | 79 +++++++++++++++++++++++++++++ > arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi               | 53 ++++++++++++++++++++ > arch/arm64/boot/dts/freescale/imx8mm.dtsi                   | 46 ++++++++++++++++- > drivers/pci/controller/dwc/pci-imx6.c                       | 63 ++++++++++++++++++++++- > drivers/phy/freescale/Kconfig                               |  9 ++++ > drivers/phy/freescale/Makefile                              |  1 + > drivers/phy/freescale/phy-fsl-imx8m-pcie.c                  | 218 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > include/dt-bindings/phy/phy-imx8-pcie.h                     | 14 ++++++ > 9 files changed, 486 insertions(+), 3 deletions(-) > > [PATCH v3 1/9] dt-bindings: phy: phy-imx8-pcie: Add binding for the > [PATCH v3 2/9] dt-bindings: phy: add imx8 pcie phy driver support > [PATCH v3 3/9] arm64: dts: imx8mm: add the pcie phy support > [PATCH v3 4/9] arm64: dts: imx8mm-evk: add the pcie phy support > [PATCH v3 5/9] phy: freescale: pcie: initialize the imx8 pcie > [PATCH v3 6/9] dt-bindings: imx6q-pcie: Add PHY phandles and name > [PATCH v3 7/9] arm64: dts: imx8mm: add the pcie support > [PATCH v3 8/9] arm64: dts: imx8mm-evk: add the pcie support on imx8mm > [PATCH v3 9/9] PCI: imx: add the imx8mm pcie support
On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com> wrote: > > > -----Original Message----- > > From: Tim Harvey <tharvey@gateworks.com> > > Sent: Tuesday, October 26, 2021 1:15 AM > > To: Richard Zhu <hongxing.zhu@nxp.com> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > linux-phy@lists.infradead.org; Device Tree Mailing List > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > <linux-arm-kernel@lists.infradead.org>; open list > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > > dl-linux-imx <linux-imx@nxp.com> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > > support > > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com> > > wrote: > > > > > > Snipped... > > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that > > > > > > > > > > defined in pinmux and I found that if I add > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > > > > > PCIe > > > > > > > > > > works on my board but this isn't a solution just a > > > > > > > > > > work-around (I have boards that use the only two > > > > > > > > > > possible pins for CLKREQ as other > > > > > > > > features). > > > > > > > > > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you comment > > > > > > > > > > out the CLKREQ (which isn't required) the imx8mmevk will > > > > > > > > > > end up hanging like my > > > > > > > > boards: > > > > > > > > > [Richard Zhu] Hi Tim: > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, and > > > > > > > > > should be > > > > > > > > configured as an open drain, active low signal. > > > > > > > > > And this signal should be driven low by the PCIe M.2 > > > > > > > > > device to request the > > > > > > > > REF clock be available(active low). > > > > > > > > > So, there is such kind of CLKREQ# pin definition on > > > > > > > > > i.MX8MM EVK > > > > > board. > > > > > > > > > > > > > > > > > > Anyway, I think the external OSC circuit should be always > > > > > > > > > running if there is > > > > > > > > no CLKREQ# on your HW board design. > > > > > > > > > > > > > > > > > > > > > > > > > The way I understand it is CLKREQ# allows the host to > > > > > > > > disable the REFCLK when not needed for power savings so it > > > > > > > > would seem optional to implement that and if not implemented > > > > > > > > should be left unconnected on > > > > > the card. > > > > > > > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this > > > > > > > signal is > > > > > mandatory required. > > > > > > > Especially for the L1ss usages. This signal would be OD(open > > > > > > > drain), bi-directional, and might be driven low/high by RC or > > > > > > > EP automatically if > > > > > L1ss modes are enabled. > > > > > > > You can make reference to the > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", or > > the > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. > > > > > 4.0 Version 1.0". > > > > > > > > > > > > > > > > > > > CLKREQ is only mandatory if you wish to support clock power > > > > > > management. Many boards with a PCI host controller do not > > > > > > support this. > > > > [Richard Zhu] Okay, understood. > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > @@ -448,7 +448,9 @@ > > > > > > > > > > > > > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > > > > > > > fsl,pins = < > > > > > > > > > > +/* > > > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > > > > > > > > +*/ > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > > > > > > > 0x41 > > > > > > > > > > >; > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > I have PCIe working with a driver that I ported from > > > > > > > > > > NXP's kernel which differs from your driver in that the > > > > > > > > > > PCIe PHY is not abstracted to its own driver so I think > > > > > > > > > > this has something to do with the order in which the phy > > > > > > > > > > is reset or > > > > initialized? > > > > > > > > > > The configuration of > > > > > > > > gpr14 bits looks correct to me. > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be masked. > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# low to > > > > > > > > > level up the HW > > > > > > > > compatibility. > > > > > > > > > That's might the reason why the PCIe works on your HW > > > > > > > > > board although the > > > > > > > > CLKREQ# PIN is not defined. > > > > > > > > > This method is a little rude and violate the SPEC, and not > > > > > > > > > recommended > > > > > > > > although it levels up the HW compatibility. > > > > > > > > > So I drop this method in this series. > > > > > > > > > > > > > > > > > > > > > > > > > Sorry, I don't understand what you are saying here. Is there > > > > > > > > a change you are going to make to v4 that will make this > > > > > > > > work for the evk and my boards? What is that change exactly? > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is > > > > > > > forced to be low in NXP local BSP kernel. I guess this might > > > > > > > be the reason why your > > > > > board works. > > > > > > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the > > > > > > > CLKREQ# to > > > > > be low. > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to > > > > > CLKREQ_OVERRIDE(bit11). > > > > > > > > > > > > > > > > > > > Ok, that makes sense. Those bits are not explained well in the > > > > > > IMX8MMRM. As my board's external REFCLK is always enabled that > > > > > > must gate the clock internally to the host controller block. > > > > > > > > > > > > I can confirm that asserting those GPR14 bits does resolve my issue: > > > > > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL BIT(11) > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN BIT(10) > > > > > > > > > > > > /* > > > > > > * for boards that do not connect CLKREQ#, > > > > > > * override CLKREQ# and drive it low internally > > > > > > */ > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > > IOMUXC_GPR14, > > > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > > IOMUXC_GPR14, > > > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); > > > > [Richard Zhu] regmap bits operations should manipulate according bits. > > > > The BIT(10) and BIT(11) should be touched actually. > > > > > > > > > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that > > > > > > needs to be set true to implement the above code? > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Sorry - spoke too soon. My test was flawed as I still was > > > > > pinmuxing CLKREQ in my dt to work around the issue and after > > > > > removed the above did not resolve my issue. The setting of > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but BIT(10) > > > > > instead) but this code already exists in imx6_pcie_enable_ref_clk > > > > > and is used for IMX8MM per your patch so this is not the issue. > > > > > > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP > > > > > kernel > > > > > does) so I don't think this bit does what we think it does (select > > > > > between internal and ext clk). I think setting it enables clock > > > > > gating via > > > > CLKREQ#. > > > > > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic should > > > > > be moved to the new phy driver for IMX8MM. > > > > [Richard Zhu] It sounds reasonable to consider to force the CLKREQ# > > > > to be low. > > > > I will think about that and add this in later v5 patch-set if nobody > > > > has different concerns. > > > > Thanks. > > > [Richard Zhu] Hi Tim: > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe on > > your board, right? > > > " (I have boards that use the only two possible pins for CLKREQ as other > > features)" > > > > > > Did the override configuration of the clkreq# will bring unexpected results > > for other features on your board? > > > > > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and UART4 > > and because I2C4_SCL and UART4_RXD are the only two pads that could be > > pinmuxed for CLKREQ# I can't use the workaround of pin muxing it. > > > > Currently your driver only works on my imx8mm-venice-* boards if I add one > > of the following on boards that don't connect those pads (or if I clear > > IMX8MM_GPR_PCIE_REF_USE_PAD): > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B > > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does enable this > > code already in the imx6_pcie_enable_ref_clk function to override REF_CLK > > and drive it low: > > > > offset = imx6_pcie_grp_offset(imx6_pcie); > > /* > > * Set the over ride low and enabled > > * make sure that REF_CLK is turned on. > > */ > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE, > > 0); > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN, > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN); > > > > So this is already being run and yet my boards still do not work unless I clr > > IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the NXP > > downstream driver does: > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0); > > > > This is why I'm not sure that bit does what you think it does... I feel like that > > bit enables 'Use CLKREQ# to enable CLK'. > > > > You tell me the descriptions for GPR14 are wrong in the reference manual. > > Please provide correct descriptions for us so we can sort this out. > > > [Richard Zhu] Hi Tim: > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN" > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM. > I think the two bits descriptions are used to describe the BIT19 and BIT9 together refer to my guess. > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) } > 2'b00: External Reference Clock I/O (for PLL) Disable > 2'b01: External Reference Clock I/O (for PLL) Enable > 2'b10: External Reference Clock I/O (for PLL) Disable > 2'b11: External Reference Clock I/O (for PLL) output is controlled by CLKREQ# > > The option1&3 should be forbidden, since the external REF CLK I/O should be enabled on your board and EVK board. > In the option2&4, the BIT19 should be set to be 1'b1.' > > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0. > Richard, Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support' should have this on top and squashed: diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c index 7c89bd1a6441..458d54c8e385 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie) break; case IMX7D: break; - case IMX8MQ: case IMX8MM: + ret = clk_prepare_enable(imx6_pcie->pcie_aux); + if (ret) + dev_err(dev, "unable to enable pcie_aux clock\n"); + break; + case IMX8MQ: ret = clk_prepare_enable(imx6_pcie->pcie_aux); if (ret) { dev_err(dev, "unable to enable pcie_aux clock\n"); And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy driver' should have this on top and squashed: diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c index 317cf61bff37..27ca0b9f1d92 100644 --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c @@ -43,7 +43,7 @@ #define IMX8MM_GPR_PCIE_CMN_RST BIT(18) #define IMX8MM_GPR_PCIE_POWER_OFF BIT(17) #define IMX8MM_GPR_PCIE_SSC_EN BIT(16) -#define IMX8MM_GPR_PCIE_REF_USE_PAD BIT(9) +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE BIT(9) struct imx8_pcie_phy { u32 refclk_pad_mode; @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy) reset_control_assert(imx8_phy->reset); regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, - IMX8MM_GPR_PCIE_REF_USE_PAD, - imx8_phy->refclk_pad_mode == 1 ? - IMX8MM_GPR_PCIE_REF_USE_PAD : 0); + IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE, + 0); regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, IMX8MM_GPR_PCIE_AUX_EN, - IMX8MM_GPR_PCIE_AUX_EN); + imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ? + IMX8MM_GPR_PCIE_AUX_EN : 0); regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, IMX8MM_GPR_PCIE_POWER_OFF, 0); regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@ -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy) regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, IMX8MM_GPR_PCIE_REF_CLK_SEL, - imx8_phy->refclk_pad_mode == 1 ? + imx8_phy->refclk_pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ? IMX8MM_GPR_PCIE_REF_CLK_EXT : IMX8MM_GPR_PCIE_REF_CLK_PLL); usleep_range(100, 200); I tested this and it works both on imx8mm-evk and imx8mm-venice-* which both have external clkgen. However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE for the case where CLKREQ# is connected and thus should be used so I think we need to add a property for that to define if CLKREQ# is hooked up or not. I tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected that worked on the imx8mm-evk which hooks up CLKREQ# but not imx8mm-venice which does not hook up CLKREQ#. What do you think about adding a property for this? Best regards, Tim
> -----Original Message----- > From: Marcel Ziswiler <marcel.ziswiler@toradex.com> > Sent: Tuesday, October 26, 2021 11:57 PM > To: kishon@ti.com; vkoul@kernel.org; robh@kernel.org; > l.stach@pengutronix.de; shawnguo@kernel.org; tharvey@gateworks.com; > galak@kernel.crashing.org; Richard Zhu <hongxing.zhu@nxp.com> > Cc: linux-phy@lists.infradead.org; linux-arm-kernel@lists.infradead.org; > kernel@pengutronix.de; devicetree@vger.kernel.org; > linux-kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > support > > On Tue, 2021-10-12 at 16:41 +0800, Richard Zhu wrote: > > refer to the discussion [1] when try to enable i.MX8MM PCIe support, > > one standalone PCIe PHY driver should be seperated from i.MX PCIe > > driver when enable i.MX8MM PCIe support. > > > > This patch-set adds the standalone PCIe PHY driver suport[1-5], and > > i.MX8MM PCIe support[6-9] to have whole view to review this patch-set. > > > > The PCIe works on i.MX8MM EVK board based the the blkctrl power driver > > [2] and this PHY driver patch-set. > > Whole series: > > Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> > > BTW: I tested it on Verdin iMX8M Mini V1.1B without an external PCIe > oscillator aka setting fsl,refclk-pad-mode to > IMX8_PCIE_REFCLK_PAD_OUTPUT which worked like a charm. Thanks! > [Richard Zhu] Thanks for your tests. Best Regards Richard Zhu > > [1] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > > > hwork.ozlabs.org%2Fproject%2Flinux-pci%2Fpatch%2F20210510141509.929 > 120 > > > -3-l.stach%40pengutronix.de%2F&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 <tharvey@gateworks.com> > Sent: Wednesday, October 27, 2021 12:06 AM > To: Richard Zhu <hongxing.zhu@nxp.com> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > linux-phy@lists.infradead.org; Device Tree Mailing List > <devicetree@vger.kernel.org>; Linux ARM Mailing List > <linux-arm-kernel@lists.infradead.org>; open list > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > support > > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com> > wrote: > > > > > -----Original Message----- > > > From: Tim Harvey <tharvey@gateworks.com> > > > Sent: Tuesday, October 26, 2021 1:15 AM > > > To: Richard Zhu <hongxing.zhu@nxp.com> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > > linux-phy@lists.infradead.org; Device Tree Mailing List > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > > <linux-arm-kernel@lists.infradead.org>; open list > > > <linux-kernel@vger.kernel.org>; Sascha Hauer > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm > > > pcie support > > > > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com> > > > wrote: > > > > > > > > Snipped... > > > > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that > > > > > > > > > > > defined in pinmux and I found that if I add > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > > > > > > PCIe > > > > > > > > > > > works on my board but this isn't a solution just a > > > > > > > > > > > work-around (I have boards that use the only two > > > > > > > > > > > possible pins for CLKREQ as other > > > > > > > > > features). > > > > > > > > > > > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you > > > > > > > > > > > comment out the CLKREQ (which isn't required) the > > > > > > > > > > > imx8mmevk will end up hanging like my > > > > > > > > > boards: > > > > > > > > > > [Richard Zhu] Hi Tim: > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, > > > > > > > > > > and should be > > > > > > > > > configured as an open drain, active low signal. > > > > > > > > > > And this signal should be driven low by the PCIe M.2 > > > > > > > > > > device to request the > > > > > > > > > REF clock be available(active low). > > > > > > > > > > So, there is such kind of CLKREQ# pin definition on > > > > > > > > > > i.MX8MM EVK > > > > > > board. > > > > > > > > > > > > > > > > > > > > Anyway, I think the external OSC circuit should be > > > > > > > > > > always running if there is > > > > > > > > > no CLKREQ# on your HW board design. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The way I understand it is CLKREQ# allows the host to > > > > > > > > > disable the REFCLK when not needed for power savings so > > > > > > > > > it would seem optional to implement that and if not > > > > > > > > > implemented should be left unconnected on > > > > > > the card. > > > > > > > > > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this > > > > > > > > signal is > > > > > > mandatory required. > > > > > > > > Especially for the L1ss usages. This signal would be > > > > > > > > OD(open drain), bi-directional, and might be driven > > > > > > > > low/high by RC or EP automatically if > > > > > > L1ss modes are enabled. > > > > > > > > You can make reference to the > > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", > or > > > the > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. > > > > > > 4.0 Version 1.0". > > > > > > > > > > > > > > > > > > > > > > CLKREQ is only mandatory if you wish to support clock power > > > > > > > management. Many boards with a PCI host controller do not > > > > > > > support this. > > > > > [Richard Zhu] Okay, understood. > > > > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > @@ -448,7 +448,9 @@ > > > > > > > > > > > > > > > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > > > > > > > > fsl,pins = < > > > > > > > > > > > +/* > > > > > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > > > > > > > > > +*/ > > > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > > > > > > > > 0x41 > > > > > > > > > > > >; > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > I have PCIe working with a driver that I ported from > > > > > > > > > > > NXP's kernel which differs from your driver in that > > > > > > > > > > > the PCIe PHY is not abstracted to its own driver so > > > > > > > > > > > I think this has something to do with the order in > > > > > > > > > > > which the phy is reset or > > > > > initialized? > > > > > > > > > > > The configuration of > > > > > > > > > gpr14 bits looks correct to me. > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be > masked. > > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# > > > > > > > > > > low to level up the HW > > > > > > > > > compatibility. > > > > > > > > > > That's might the reason why the PCIe works on your HW > > > > > > > > > > board although the > > > > > > > > > CLKREQ# PIN is not defined. > > > > > > > > > > This method is a little rude and violate the SPEC, and > > > > > > > > > > not recommended > > > > > > > > > although it levels up the HW compatibility. > > > > > > > > > > So I drop this method in this series. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry, I don't understand what you are saying here. Is > > > > > > > > > there a change you are going to make to v4 that will > > > > > > > > > make this work for the evk and my boards? What is that change > exactly? > > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is > > > > > > > > forced to be low in NXP local BSP kernel. I guess this > > > > > > > > might be the reason why your > > > > > > board works. > > > > > > > > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the > > > > > > > > CLKREQ# to > > > > > > be low. > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to > > > > > > CLKREQ_OVERRIDE(bit11). > > > > > > > > > > > > > > > > > > > > > > Ok, that makes sense. Those bits are not explained well in > > > > > > > the IMX8MMRM. As my board's external REFCLK is always > > > > > > > enabled that must gate the clock internally to the host controller > block. > > > > > > > > > > > > > > I can confirm that asserting those GPR14 bits does resolve my > issue: > > > > > > > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL BIT(11) > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN > BIT(10) > > > > > > > > > > > > > > /* > > > > > > > * for boards that do not connect CLKREQ#, > > > > > > > * override CLKREQ# and drive it low internally > > > > > > > */ > > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > > > IOMUXC_GPR14, > > > > > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); > > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > > > IOMUXC_GPR14, > > > > > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); > > > > > [Richard Zhu] regmap bits operations should manipulate according > bits. > > > > > The BIT(10) and BIT(11) should be touched actually. > > > > > > > > > > > > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that > > > > > > > needs to be set true to implement the above code? > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > > > Sorry - spoke too soon. My test was flawed as I still was > > > > > > pinmuxing CLKREQ in my dt to work around the issue and after > > > > > > removed the above did not resolve my issue. The setting of > > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but > > > > > > BIT(10) > > > > > > instead) but this code already exists in > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch > so this is not the issue. > > > > > > > > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP > > > > > > kernel > > > > > > does) so I don't think this bit does what we think it does > > > > > > (select between internal and ext clk). I think setting it > > > > > > enables clock gating via > > > > > CLKREQ#. > > > > > > > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic > > > > > > should be moved to the new phy driver for IMX8MM. > > > > > [Richard Zhu] It sounds reasonable to consider to force the > > > > > CLKREQ# to be low. > > > > > I will think about that and add this in later v5 patch-set if > > > > > nobody has different concerns. > > > > > Thanks. > > > > [Richard Zhu] Hi Tim: > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe > > > > on > > > your board, right? > > > > " (I have boards that use the only two possible pins for CLKREQ as > > > > other > > > features)" > > > > > > > > Did the override configuration of the clkreq# will bring > > > > unexpected results > > > for other features on your board? > > > > > > > > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and > > > UART4 and because I2C4_SCL and UART4_RXD are the only two pads that > > > could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing > it. > > > > > > Currently your driver only works on my imx8mm-venice-* boards if I > > > add one of the following on boards that don't connect those pads (or > > > if I clear > > > IMX8MM_GPR_PCIE_REF_USE_PAD): > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B > > > > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does > > > enable this code already in the imx6_pcie_enable_ref_clk function to > > > override REF_CLK and drive it low: > > > > > > offset = imx6_pcie_grp_offset(imx6_pcie); > > > /* > > > * Set the over ride low and enabled > > > * make sure that REF_CLK is turned on. > > > */ > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE, > > > 0); > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN, > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN); > > > > > > So this is already being run and yet my boards still do not work > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the > > > NXP downstream driver does: > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0); > > > > > > This is why I'm not sure that bit does what you think it does... I > > > feel like that bit enables 'Use CLKREQ# to enable CLK'. > > > > > > You tell me the descriptions for GPR14 are wrong in the reference manual. > > > Please provide correct descriptions for us so we can sort this out. > > > > > [Richard Zhu] Hi Tim: > > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN" > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM. > > I think the two bits descriptions are used to describe the BIT19 and BIT9 > together refer to my guess. > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) } > > 2'b00: External Reference Clock I/O (for PLL) Disable > > 2'b01: External Reference Clock I/O (for PLL) Enable > > 2'b10: External Reference Clock I/O (for PLL) Disable > > 2'b11: External Reference Clock I/O (for PLL) output is controlled by > > CLKREQ# > > > > The option1&3 should be forbidden, since the external REF CLK I/O should > be enabled on your board and EVK board. > > In the option2&4, the BIT19 should be set to be 1'b1.' > > > > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0. > > > > Richard, > > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM > should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support' > should have this on top and squashed: > diff --git a/drivers/pci/controller/dwc/pci-imx6.c > b/drivers/pci/controller/dwc/pci-imx6.c > index 7c89bd1a6441..458d54c8e385 100644 > --- a/drivers/pci/controller/dwc/pci-imx6.c > +++ b/drivers/pci/controller/dwc/pci-imx6.c > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct > imx6_pcie *imx6_pcie) > break; > case IMX7D: > break; > - case IMX8MQ: > case IMX8MM: > + ret = clk_prepare_enable(imx6_pcie->pcie_aux); > + if (ret) > + dev_err(dev, "unable to enable pcie_aux > clock\n"); > + break; > + case IMX8MQ: > ret = clk_prepare_enable(imx6_pcie->pcie_aux); > if (ret) { > dev_err(dev, "unable to enable pcie_aux > clock\n"); > [Richard Zhu] Sorry, I might don't understand what's meaning of the changes. What're the differences between before and after the changes? > > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy > driver' should have this on top and squashed: > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > index 317cf61bff37..27ca0b9f1d92 100644 > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > @@ -43,7 +43,7 @@ > #define IMX8MM_GPR_PCIE_CMN_RST BIT(18) > #define IMX8MM_GPR_PCIE_POWER_OFF BIT(17) > #define IMX8MM_GPR_PCIE_SSC_EN BIT(16) > -#define IMX8MM_GPR_PCIE_REF_USE_PAD BIT(9) > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE BIT(9) > > struct imx8_pcie_phy { > u32 refclk_pad_mode; > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy) > reset_control_assert(imx8_phy->reset); > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > - IMX8MM_GPR_PCIE_REF_USE_PAD, > - imx8_phy->refclk_pad_mode == 1 ? > - IMX8MM_GPR_PCIE_REF_USE_PAD : 0); > + IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE, > + 0); > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > IMX8MM_GPR_PCIE_AUX_EN, > - IMX8MM_GPR_PCIE_AUX_EN); > + imx8_phy->refclk_pad_mode == > IMX8_PCIE_REFCLK_PAD_INPUT ? > + IMX8MM_GPR_PCIE_AUX_EN : 0); > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > IMX8MM_GPR_PCIE_POWER_OFF, 0); > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@ > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy) > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > IMX8MM_GPR_PCIE_REF_CLK_SEL, > - imx8_phy->refclk_pad_mode == 1 ? > + imx8_phy->refclk_pad_mode == > IMX8_PCIE_REFCLK_PAD_INPUT ? > IMX8MM_GPR_PCIE_REF_CLK_EXT : > IMX8MM_GPR_PCIE_REF_CLK_PLL); > usleep_range(100, 200); > > I tested this and it works both on imx8mm-evk and imx8mm-venice-* which > both have external clkgen. > > However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE > for the case where CLKREQ# is connected and thus should be used so I think > we need to add a property for that to define if CLKREQ# is hooked up or not. I > tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected > that worked on the imx8mm-evk which hooks up CLKREQ# but not > imx8mm-venice which does not hook up CLKREQ#. > > What do you think about adding a property for this? [Richard Zhu] First of all, thanks a lot for your help to figure out the details. Agree with your proposal. One optional property "fsl,clkreq-unsupported" would be added for the CLKREQ# not hooked case later. diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml index 097ba2a28fb4..2264452924cc 100644 --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml @@ -58,6 +58,11 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 default: 0 + fsl,clkreq-unsupported: + type: boolean + description: A boolean property whoes presence indicates the CLKREQ# + signal isn't supported in the HW board design (optional required). + diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c index 07eea39283ed..4b4402eaddcc 100644 --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c @@ -43,7 +43,7 @@ #define IMX8MM_GPR_PCIE_CMN_RST BIT(18) #define IMX8MM_GPR_PCIE_POWER_OFF BIT(17) #define IMX8MM_GPR_PCIE_SSC_EN BIT(16) -#define IMX8MM_GPR_PCIE_REF_USE_PAD BIT(9) +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE BIT(9) struct imx8_pcie_phy { void __iomem *base; @@ -54,6 +54,7 @@ struct imx8_pcie_phy { u32 refclk_pad_mode; u32 tx_deemph_gen1; u32 tx_deemph_gen2; + bool clkreq_unused; }; static int imx8_pcie_phy_init(struct phy *phy) @@ -65,13 +66,15 @@ static int imx8_pcie_phy_init(struct phy *phy) reset_control_assert(imx8_phy->reset); pad_mode = imx8_phy->refclk_pad_mode; + /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't hooked */ regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, - IMX8MM_GPR_PCIE_REF_USE_PAD, - pad_mode == IMX8MM_GPR_PCIE_REF_USE_PAD ? - IMX8MM_GPR_PCIE_REF_USE_PAD : 0); + IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE, + imx8_phy->clkreq_unused ? + 0 : IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE); regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, IMX8MM_GPR_PCIE_AUX_EN, - IMX8MM_GPR_PCIE_AUX_EN); + pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ? + IMX8MM_GPR_PCIE_AUX_EN : 0); regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, IMX8MM_GPR_PCIE_POWER_OFF, 0); regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@ -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct platform_device *pdev) &imx8_phy->tx_deemph_gen2)) imx8_phy->tx_deemph_gen2 = 0; + if (of_property_read_bool(np, "fsl,clkreq-unsupported")) + imx8_phy->clkreq_unused = true; + else + imx8_phy->clkreq_unused = false; + imx8_phy->clk = devm_clk_get(dev, "ref"); if (IS_ERR(imx8_phy->clk)) { dev_err(dev, "failed to get imx pcie phy clock\n"); Best Regards Richard Zhu > > Best regards, > > Tim
On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <hongxing.zhu@nxp.com> wrote: > > > -----Original Message----- > > From: Tim Harvey <tharvey@gateworks.com> > > Sent: Wednesday, October 27, 2021 12:06 AM > > To: Richard Zhu <hongxing.zhu@nxp.com> > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > linux-phy@lists.infradead.org; Device Tree Mailing List > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > <linux-arm-kernel@lists.infradead.org>; open list > > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > > dl-linux-imx <linux-imx@nxp.com> > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm pcie > > support > > > > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu <hongxing.zhu@nxp.com> > > wrote: > > > > > > > -----Original Message----- > > > > From: Tim Harvey <tharvey@gateworks.com> > > > > Sent: Tuesday, October 26, 2021 1:15 AM > > > > To: Richard Zhu <hongxing.zhu@nxp.com> > > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > > > linux-phy@lists.infradead.org; Device Tree Mailing List > > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > > > <linux-arm-kernel@lists.infradead.org>; open list > > > > <linux-kernel@vger.kernel.org>; Sascha Hauer > > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com> > > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm > > > > pcie support > > > > > > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu <hongxing.zhu@nxp.com> > > > > wrote: > > > > > > > > > > Snipped... > > > > > > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have that > > > > > > > > > > > > defined in pinmux and I found that if I add > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > > > > > > > PCIe > > > > > > > > > > > > works on my board but this isn't a solution just a > > > > > > > > > > > > work-around (I have boards that use the only two > > > > > > > > > > > > possible pins for CLKREQ as other > > > > > > > > > > features). > > > > > > > > > > > > > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you > > > > > > > > > > > > comment out the CLKREQ (which isn't required) the > > > > > > > > > > > > imx8mmevk will end up hanging like my > > > > > > > > > > boards: > > > > > > > > > > > [Richard Zhu] Hi Tim: > > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory required, > > > > > > > > > > > and should be > > > > > > > > > > configured as an open drain, active low signal. > > > > > > > > > > > And this signal should be driven low by the PCIe M.2 > > > > > > > > > > > device to request the > > > > > > > > > > REF clock be available(active low). > > > > > > > > > > > So, there is such kind of CLKREQ# pin definition on > > > > > > > > > > > i.MX8MM EVK > > > > > > > board. > > > > > > > > > > > > > > > > > > > > > > Anyway, I think the external OSC circuit should be > > > > > > > > > > > always running if there is > > > > > > > > > > no CLKREQ# on your HW board design. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The way I understand it is CLKREQ# allows the host to > > > > > > > > > > disable the REFCLK when not needed for power savings so > > > > > > > > > > it would seem optional to implement that and if not > > > > > > > > > > implemented should be left unconnected on > > > > > > > the card. > > > > > > > > > > > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, this > > > > > > > > > signal is > > > > > > > mandatory required. > > > > > > > > > Especially for the L1ss usages. This signal would be > > > > > > > > > OD(open drain), bi-directional, and might be driven > > > > > > > > > low/high by RC or EP automatically if > > > > > > > L1ss modes are enabled. > > > > > > > > > You can make reference to the > > > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", > > or > > > > the > > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base Specification, Rev. > > > > > > > 4.0 Version 1.0". > > > > > > > > > > > > > > > > > > > > > > > > > CLKREQ is only mandatory if you wish to support clock power > > > > > > > > management. Many boards with a PCI host controller do not > > > > > > > > support this. > > > > > > [Richard Zhu] Okay, understood. > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > > > > > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > > @@ -448,7 +448,9 @@ > > > > > > > > > > > > > > > > > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > > > > > > > > > fsl,pins = < > > > > > > > > > > > > +/* > > > > > > > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61 > > > > > > > > > > > > +*/ > > > > > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > > > > > > > > > 0x41 > > > > > > > > > > > > >; > > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > > > I have PCIe working with a driver that I ported from > > > > > > > > > > > > NXP's kernel which differs from your driver in that > > > > > > > > > > > > the PCIe PHY is not abstracted to its own driver so > > > > > > > > > > > > I think this has something to do with the order in > > > > > > > > > > > > which the phy is reset or > > > > > > initialized? > > > > > > > > > > > > The configuration of > > > > > > > > > > gpr14 bits looks correct to me. > > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't be > > masked. > > > > > > > > > > > In the NXP's local BSP kernel, I just force CLKREQ# > > > > > > > > > > > low to level up the HW > > > > > > > > > > compatibility. > > > > > > > > > > > That's might the reason why the PCIe works on your HW > > > > > > > > > > > board although the > > > > > > > > > > CLKREQ# PIN is not defined. > > > > > > > > > > > This method is a little rude and violate the SPEC, and > > > > > > > > > > > not recommended > > > > > > > > > > although it levels up the HW compatibility. > > > > > > > > > > > So I drop this method in this series. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry, I don't understand what you are saying here. Is > > > > > > > > > > there a change you are going to make to v4 that will > > > > > > > > > > make this work for the evk and my boards? What is that change > > exactly? > > > > > > > > > [Richard Zhu] No. What I said above is that the CLKREQ# is > > > > > > > > > forced to be low in NXP local BSP kernel. I guess this > > > > > > > > > might be the reason why your > > > > > > > board works. > > > > > > > > > > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force the > > > > > > > > > CLKREQ# to > > > > > > > be low. > > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one zero to > > > > > > > CLKREQ_OVERRIDE(bit11). > > > > > > > > > > > > > > > > > > > > > > > > > Ok, that makes sense. Those bits are not explained well in > > > > > > > > the IMX8MMRM. As my board's external REFCLK is always > > > > > > > > enabled that must gate the clock internally to the host controller > > block. > > > > > > > > > > > > > > > > I can confirm that asserting those GPR14 bits does resolve my > > issue: > > > > > > > > > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL BIT(11) > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN > > BIT(10) > > > > > > > > > > > > > > > > /* > > > > > > > > * for boards that do not connect CLKREQ#, > > > > > > > > * override CLKREQ# and drive it low internally > > > > > > > > */ > > > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > > > > IOMUXC_GPR14, > > > > > > > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); > > > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > > > > IOMUXC_GPR14, > > > > > > > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); > > > > > > [Richard Zhu] regmap bits operations should manipulate according > > bits. > > > > > > The BIT(10) and BIT(11) should be touched actually. > > > > > > > > > > > > > > > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag that > > > > > > > > needs to be set true to implement the above code? > > > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > > > > > Sorry - spoke too soon. My test was flawed as I still was > > > > > > > pinmuxing CLKREQ in my dt to work around the issue and after > > > > > > > removed the above did not resolve my issue. The setting of > > > > > > > OVERRIDE_EN was wrong above (should not be set to '1' but > > > > > > > BIT(10) > > > > > > > instead) but this code already exists in > > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your patch > > so this is not the issue. > > > > > > > > > > > > > > What makes my board work is to clear GPR14 bit9 (like the NXP > > > > > > > kernel > > > > > > > does) so I don't think this bit does what we think it does > > > > > > > (select between internal and ext clk). I think setting it > > > > > > > enables clock gating via > > > > > > CLKREQ#. > > > > > > > > > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE logic > > > > > > > should be moved to the new phy driver for IMX8MM. > > > > > > [Richard Zhu] It sounds reasonable to consider to force the > > > > > > CLKREQ# to be low. > > > > > > I will think about that and add this in later v5 patch-set if > > > > > > nobody has different concerns. > > > > > > Thanks. > > > > > [Richard Zhu] Hi Tim: > > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for PCIe > > > > > on > > > > your board, right? > > > > > " (I have boards that use the only two possible pins for CLKREQ as > > > > > other > > > > features)" > > > > > > > > > > Did the override configuration of the clkreq# will bring > > > > > unexpected results > > > > for other features on your board? > > > > > > > > > > > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 and > > > > UART4 and because I2C4_SCL and UART4_RXD are the only two pads that > > > > could be pinmuxed for CLKREQ# I can't use the workaround of pin muxing > > it. > > > > > > > > Currently your driver only works on my imx8mm-venice-* boards if I > > > > add one of the following on boards that don't connect those pads (or > > > > if I clear > > > > IMX8MM_GPR_PCIE_REF_USE_PAD): > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B > > > > > > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does > > > > enable this code already in the imx6_pcie_enable_ref_clk function to > > > > override REF_CLK and drive it low: > > > > > > > > offset = imx6_pcie_grp_offset(imx6_pcie); > > > > /* > > > > * Set the over ride low and enabled > > > > * make sure that REF_CLK is turned on. > > > > */ > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE, > > > > 0); > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN, > > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN); > > > > > > > > So this is already being run and yet my boards still do not work > > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is what the > > > > NXP downstream driver does: > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0); > > > > > > > > This is why I'm not sure that bit does what you think it does... I > > > > feel like that bit enables 'Use CLKREQ# to enable CLK'. > > > > > > > > You tell me the descriptions for GPR14 are wrong in the reference manual. > > > > Please provide correct descriptions for us so we can sort this out. > > > > > > > [Richard Zhu] Hi Tim: > > > The BIT9 of GPR14 is used as "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN" > > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on i.MX8MM. > > > I think the two bits descriptions are used to describe the BIT19 and BIT9 > > together refer to my guess. > > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), > > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) } > > > 2'b00: External Reference Clock I/O (for PLL) Disable > > > 2'b01: External Reference Clock I/O (for PLL) Enable > > > 2'b10: External Reference Clock I/O (for PLL) Disable > > > 2'b11: External Reference Clock I/O (for PLL) output is controlled by > > > CLKREQ# > > > > > > The option1&3 should be forbidden, since the external REF CLK I/O should > > be enabled on your board and EVK board. > > > In the option2&4, the BIT19 should be set to be 1'b1.' > > > > > > So, regarding my understand, if the CLKREQ# is not pinmuxed in your use > > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0. > > > > > > > Richard, > > > > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c for IMX8MM > > should not touch GPR14 and '[v3,9/9] PCI: imx: add the imx8mm pcie support' > > should have this on top and squashed: > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c > > b/drivers/pci/controller/dwc/pci-imx6.c > > index 7c89bd1a6441..458d54c8e385 100644 > > --- a/drivers/pci/controller/dwc/pci-imx6.c > > +++ b/drivers/pci/controller/dwc/pci-imx6.c > > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct > > imx6_pcie *imx6_pcie) > > break; > > case IMX7D: > > break; > > - case IMX8MQ: > > case IMX8MM: > > + ret = clk_prepare_enable(imx6_pcie->pcie_aux); > > + if (ret) > > + dev_err(dev, "unable to enable pcie_aux > > clock\n"); > > + break; > > + case IMX8MQ: > > ret = clk_prepare_enable(imx6_pcie->pcie_aux); > > if (ret) { > > dev_err(dev, "unable to enable pcie_aux > > clock\n"); > > > [Richard Zhu] Sorry, I might don't understand what's meaning of the changes. > What're the differences between before and after the changes? > The above change to your patch 'only' calls clk_prepare_enable for IMX8MM and does not touch GPR14 bits as the IMX8MQ case does (because as you point out the GPR14 bits differ between IMX8MM and IMX8MQ). > > > > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie standalone phy > > driver' should have this on top and squashed: > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > index 317cf61bff37..27ca0b9f1d92 100644 > > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > @@ -43,7 +43,7 @@ > > #define IMX8MM_GPR_PCIE_CMN_RST BIT(18) > > #define IMX8MM_GPR_PCIE_POWER_OFF BIT(17) > > #define IMX8MM_GPR_PCIE_SSC_EN BIT(16) > > -#define IMX8MM_GPR_PCIE_REF_USE_PAD BIT(9) > > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE BIT(9) > > > > struct imx8_pcie_phy { > > u32 refclk_pad_mode; > > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy) > > reset_control_assert(imx8_phy->reset); > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > - IMX8MM_GPR_PCIE_REF_USE_PAD, > > - imx8_phy->refclk_pad_mode == 1 ? > > - IMX8MM_GPR_PCIE_REF_USE_PAD : 0); > > + IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE, > > + 0); > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > IMX8MM_GPR_PCIE_AUX_EN, > > - IMX8MM_GPR_PCIE_AUX_EN); > > + imx8_phy->refclk_pad_mode == > > IMX8_PCIE_REFCLK_PAD_INPUT ? > > + IMX8MM_GPR_PCIE_AUX_EN : 0); > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > IMX8MM_GPR_PCIE_POWER_OFF, 0); > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, @@ > > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy) > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > IMX8MM_GPR_PCIE_REF_CLK_SEL, > > - imx8_phy->refclk_pad_mode == 1 ? > > + imx8_phy->refclk_pad_mode == > > IMX8_PCIE_REFCLK_PAD_INPUT ? > > IMX8MM_GPR_PCIE_REF_CLK_EXT : > > IMX8MM_GPR_PCIE_REF_CLK_PLL); > > usleep_range(100, 200); > > > > I tested this and it works both on imx8mm-evk and imx8mm-venice-* which > > both have external clkgen. > > > > However, the above does not set IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE > > for the case where CLKREQ# is connected and thus should be used so I think > > we need to add a property for that to define if CLKREQ# is hooked up or not. I > > tested enabling IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE and as expected > > that worked on the imx8mm-evk which hooks up CLKREQ# but not > > imx8mm-venice which does not hook up CLKREQ#. > > > > What do you think about adding a property for this? > [Richard Zhu] First of all, thanks a lot for your help to figure out the details. > Agree with your proposal. > One optional property "fsl,clkreq-unsupported" would be added for the CLKREQ# not hooked case later. > > diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml > index 097ba2a28fb4..2264452924cc 100644 > --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml > @@ -58,6 +58,11 @@ properties: > $ref: /schemas/types.yaml#/definitions/uint32 > default: 0 > > + fsl,clkreq-unsupported: > + type: boolean > + description: A boolean property whoes presence indicates the CLKREQ# > + signal isn't supported in the HW board design (optional required). > + A boolean property indicating the CLKREQ# signal is not supported in the board design (optional) > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > index 07eea39283ed..4b4402eaddcc 100644 > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > @@ -43,7 +43,7 @@ > #define IMX8MM_GPR_PCIE_CMN_RST BIT(18) > #define IMX8MM_GPR_PCIE_POWER_OFF BIT(17) > #define IMX8MM_GPR_PCIE_SSC_EN BIT(16) > -#define IMX8MM_GPR_PCIE_REF_USE_PAD BIT(9) > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE BIT(9) > > struct imx8_pcie_phy { > void __iomem *base; > @@ -54,6 +54,7 @@ struct imx8_pcie_phy { > u32 refclk_pad_mode; > u32 tx_deemph_gen1; > u32 tx_deemph_gen2; > + bool clkreq_unused; > }; > > static int imx8_pcie_phy_init(struct phy *phy) > @@ -65,13 +66,15 @@ static int imx8_pcie_phy_init(struct phy *phy) > reset_control_assert(imx8_phy->reset); > > pad_mode = imx8_phy->refclk_pad_mode; > + /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't hooked */ > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > - IMX8MM_GPR_PCIE_REF_USE_PAD, > - pad_mode == IMX8MM_GPR_PCIE_REF_USE_PAD ? > - IMX8MM_GPR_PCIE_REF_USE_PAD : 0); > + IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE, > + imx8_phy->clkreq_unused ? > + 0 : IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE); > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > IMX8MM_GPR_PCIE_AUX_EN, > - IMX8MM_GPR_PCIE_AUX_EN); > + pad_mode == IMX8_PCIE_REFCLK_PAD_INPUT ? > + IMX8MM_GPR_PCIE_AUX_EN : 0); > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > IMX8MM_GPR_PCIE_POWER_OFF, 0); > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > @@ -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct platform_device *pdev) > &imx8_phy->tx_deemph_gen2)) > imx8_phy->tx_deemph_gen2 = 0; > > + if (of_property_read_bool(np, "fsl,clkreq-unsupported")) > + imx8_phy->clkreq_unused = true; > + else > + imx8_phy->clkreq_unused = false; > + > imx8_phy->clk = devm_clk_get(dev, "ref"); > if (IS_ERR(imx8_phy->clk)) { > dev_err(dev, "failed to get imx pcie phy clock\n"); > Yes this looks good and works both on venice (with 'fsl,clkreq-unsupported' added) and on imx8mm-evk. Thanks for working through this with me and please cc me on your v4 submission. Best regards, Tim
> -----Original Message----- > From: Tim Harvey <tharvey@gateworks.com> > Sent: Wednesday, October 27, 2021 11:41 PM > To: Richard Zhu <hongxing.zhu@nxp.com> > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > linux-phy@lists.infradead.org; Device Tree Mailing List > <devicetree@vger.kernel.org>; Linux ARM Mailing List > <linux-arm-kernel@lists.infradead.org>; open list > <linux-kernel@vger.kernel.org>; Sascha Hauer <kernel@pengutronix.de>; > dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and imx8mm > pcie support > > On Tue, Oct 26, 2021 at 11:18 PM Richard Zhu <hongxing.zhu@nxp.com> > wrote: > > > > > -----Original Message----- > > > From: Tim Harvey <tharvey@gateworks.com> > > > Sent: Wednesday, October 27, 2021 12:06 AM > > > To: Richard Zhu <hongxing.zhu@nxp.com> > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring <robh@kernel.org>; > > > galak@kernel.crashing.org; Shawn Guo <shawnguo@kernel.org>; > > > linux-phy@lists.infradead.org; Device Tree Mailing List > > > <devicetree@vger.kernel.org>; Linux ARM Mailing List > > > <linux-arm-kernel@lists.infradead.org>; open list > > > <linux-kernel@vger.kernel.org>; Sascha Hauer > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com> > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and > imx8mm > > > pcie support > > > > > > On Mon, Oct 25, 2021 at 10:41 PM Richard Zhu > <hongxing.zhu@nxp.com> > > > wrote: > > > > > > > > > -----Original Message----- > > > > > From: Tim Harvey <tharvey@gateworks.com> > > > > > Sent: Tuesday, October 26, 2021 1:15 AM > > > > > To: Richard Zhu <hongxing.zhu@nxp.com> > > > > > Cc: Lucas Stach <l.stach@pengutronix.de>; Kishon Vijay Abraham I > > > > > <kishon@ti.com>; vkoul@kernel.org; Rob Herring > > > > > <robh@kernel.org>; galak@kernel.crashing.org; Shawn Guo > > > > > <shawnguo@kernel.org>; linux-phy@lists.infradead.org; Device > > > > > Tree Mailing List <devicetree@vger.kernel.org>; Linux ARM > > > > > Mailing List <linux-arm-kernel@lists.infradead.org>; open list > > > > > <linux-kernel@vger.kernel.org>; Sascha Hauer > > > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com> > > > > > Subject: Re: [PATCH v3 0/9] add the imx8m pcie phy driver and > > > > > imx8mm pcie support > > > > > > > > > > On Mon, Oct 25, 2021 at 12:23 AM Richard Zhu > > > > > <hongxing.zhu@nxp.com> > > > > > wrote: > > > > > > > > > > > > Snipped... > > > > > > > > > > > > > > > > > > > My boards do not use CLKREQ# so I do not have > > > > > > > > > > > > > that defined in pinmux and I found that if I add > > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > > > > > > > > PCIe > > > > > > > > > > > > > works on my board but this isn't a solution just > > > > > > > > > > > > > a work-around (I have boards that use the only > > > > > > > > > > > > > two possible pins for CLKREQ as other > > > > > > > > > > > features). > > > > > > > > > > > > > > > > > > > > > > > > > > Similarly you will find on the imx8mm-evk if you > > > > > > > > > > > > > comment out the CLKREQ (which isn't required) > > > > > > > > > > > > > the imx8mmevk will end up hanging like my > > > > > > > > > > > boards: > > > > > > > > > > > > [Richard Zhu] Hi Tim: > > > > > > > > > > > > Regarding the SPEC, the CLKREQ# is mandatory > > > > > > > > > > > > required, and should be > > > > > > > > > > > configured as an open drain, active low signal. > > > > > > > > > > > > And this signal should be driven low by the PCIe > > > > > > > > > > > > M.2 device to request the > > > > > > > > > > > REF clock be available(active low). > > > > > > > > > > > > So, there is such kind of CLKREQ# pin definition > > > > > > > > > > > > on i.MX8MM EVK > > > > > > > > board. > > > > > > > > > > > > > > > > > > > > > > > > Anyway, I think the external OSC circuit should be > > > > > > > > > > > > always running if there is > > > > > > > > > > > no CLKREQ# on your HW board design. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The way I understand it is CLKREQ# allows the host > > > > > > > > > > > to disable the REFCLK when not needed for power > > > > > > > > > > > savings so it would seem optional to implement that > > > > > > > > > > > and if not implemented should be left unconnected on > > > > > > > > the card. > > > > > > > > > > > > > > > > > > > > > [Richard Zhu] No, not that way. Regarding the SPEC, > > > > > > > > > > this signal is > > > > > > > > mandatory required. > > > > > > > > > > Especially for the L1ss usages. This signal would be > > > > > > > > > > OD(open drain), bi-directional, and might be driven > > > > > > > > > > low/high by RC or EP automatically if > > > > > > > > L1ss modes are enabled. > > > > > > > > > > You can make reference to the > > > > > > > > > > > "ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a", > > > or > > > > > the > > > > > > > > chapter 5.5 L1 PM Substates of "PCI Express Base > Specification, Rev. > > > > > > > > 4.0 Version 1.0". > > > > > > > > > > > > > > > > > > > > > > > > > > > > CLKREQ is only mandatory if you wish to support clock > > > > > > > > > power management. Many boards with a PCI host > controller > > > > > > > > > do not support this. > > > > > > > [Richard Zhu] Okay, understood. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > > > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > > > index 5ce43daa0c8b..f0023b48f475 100644 > > > > > > > > > > > > > --- > > > > > > > > > > > > > a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi > > > > > > > > > > > > > +++ > b/arch/arm64/boot/dts/freescale/imx8mm-evk.d > > > > > > > > > > > > > +++ tsi > > > > > > > > > > > > > @@ -448,7 +448,9 @@ > > > > > > > > > > > > > > > > > > > > > > > > > > pinctrl_pcie0: pcie0grp { > > > > > > > > > > > > > fsl,pins = < > > > > > > > > > > > > > +/* > > > > > > > > > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > 0x61 > > > > > > > > > > > > > +*/ > > > > > > > > > > > > > > > > > > > > > > > > MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 > > > > > > > > > > > > > 0x41 > > > > > > > > > > > > > >; > > > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > > > > > I have PCIe working with a driver that I ported > > > > > > > > > > > > > from NXP's kernel which differs from your driver > > > > > > > > > > > > > in that the PCIe PHY is not abstracted to its > > > > > > > > > > > > > own driver so I think this has something to do > > > > > > > > > > > > > with the order in which the phy is reset or > > > > > > > initialized? > > > > > > > > > > > > > The configuration of > > > > > > > > > > > gpr14 bits looks correct to me. > > > > > > > > > > > > [Richard Zhu] The CLKREQ# PIN definition shouldn't > > > > > > > > > > > > be > > > masked. > > > > > > > > > > > > In the NXP's local BSP kernel, I just force > > > > > > > > > > > > CLKREQ# low to level up the HW > > > > > > > > > > > compatibility. > > > > > > > > > > > > That's might the reason why the PCIe works on your > > > > > > > > > > > > HW board although the > > > > > > > > > > > CLKREQ# PIN is not defined. > > > > > > > > > > > > This method is a little rude and violate the SPEC, > > > > > > > > > > > > and not recommended > > > > > > > > > > > although it levels up the HW compatibility. > > > > > > > > > > > > So I drop this method in this series. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry, I don't understand what you are saying here. > > > > > > > > > > > Is there a change you are going to make to v4 that > > > > > > > > > > > will make this work for the evk and my boards? What > > > > > > > > > > > is that change > > > exactly? > > > > > > > > > > [Richard Zhu] No. What I said above is that the > > > > > > > > > > CLKREQ# is forced to be low in NXP local BSP kernel. I > > > > > > > > > > guess this might be the reason why your > > > > > > > > board works. > > > > > > > > > > > > > > > > > > > > BIT11 and BIT10 of IOMUXC_GPR14 can be used to force > > > > > > > > > > the CLKREQ# to > > > > > > > > be low. > > > > > > > > > > Set CLKREQ_OVERRIDE_EN(bit10) 1b1, then write one > zero > > > > > > > > > > to > > > > > > > > CLKREQ_OVERRIDE(bit11). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok, that makes sense. Those bits are not explained well > > > > > > > > > in the IMX8MMRM. As my board's external REFCLK is > always > > > > > > > > > enabled that must gate the clock internally to the host > > > > > > > > > controller > > > block. > > > > > > > > > > > > > > > > > > I can confirm that asserting those GPR14 bits does > > > > > > > > > resolve my > > > issue: > > > > > > > > > > > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL > BIT(11) > > > > > > > > > #define IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN > > > BIT(10) > > > > > > > > > > > > > > > > > > /* > > > > > > > > > * for boards that do not connect CLKREQ#, > > > > > > > > > * override CLKREQ# and drive it low internally > > > > > > > > > */ > > > > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > > > > > IOMUXC_GPR14, > > > > > > > > > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_VAL, 0); > > > > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > > > > > IOMUXC_GPR14, > > > > > > > > > > > > > > > > > IMX8MM_GPR_PCIE_CLKREQ_OVERRIDE_EN, 1); > > > > > > > [Richard Zhu] regmap bits operations should manipulate > > > > > > > according > > > bits. > > > > > > > The BIT(10) and BIT(11) should be touched actually. > > > > > > > > > > > > > > > > > > > > > > > > > Should this be added as a 'fsl,clkreq-unsupported' flag > > > > > > > > > that needs to be set true to implement the above code? > > > > > > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > > > > > > > Sorry - spoke too soon. My test was flawed as I still was > > > > > > > > pinmuxing CLKREQ in my dt to work around the issue and > > > > > > > > after removed the above did not resolve my issue. The > > > > > > > > setting of OVERRIDE_EN was wrong above (should not be set > > > > > > > > to '1' but > > > > > > > > BIT(10) > > > > > > > > instead) but this code already exists in > > > > > > > > imx6_pcie_enable_ref_clk and is used for IMX8MM per your > > > > > > > > patch > > > so this is not the issue. > > > > > > > > > > > > > > > > What makes my board work is to clear GPR14 bit9 (like the > > > > > > > > NXP kernel > > > > > > > > does) so I don't think this bit does what we think it does > > > > > > > > (select between internal and ext clk). I think setting it > > > > > > > > enables clock gating via > > > > > > > CLKREQ#. > > > > > > > > > > > > > > > > This also points out that perhaps the CLKREQ_OVERRIDE > > > > > > > > logic should be moved to the new phy driver for IMX8MM. > > > > > > > [Richard Zhu] It sounds reasonable to consider to force the > > > > > > > CLKREQ# to be low. > > > > > > > I will think about that and add this in later v5 patch-set > > > > > > > if nobody has different concerns. > > > > > > > Thanks. > > > > > > [Richard Zhu] Hi Tim: > > > > > > As you mentioned above, the CLKREQ# GPIO PIN is not used for > > > > > > PCIe on > > > > > your board, right? > > > > > > " (I have boards that use the only two possible pins for > > > > > > CLKREQ as other > > > > > features)" > > > > > > > > > > > > Did the override configuration of the clkreq# will bring > > > > > > unexpected results > > > > > for other features on your board? > > > > > > > > > > > > > > > > What I mean is that imx8mm-venice-gw7901.dts uses both I2C4 > and > > > > > UART4 and because I2C4_SCL and UART4_RXD are the only two > pads > > > > > that could be pinmuxed for CLKREQ# I can't use the workaround of > > > > > pin muxing > > > it. > > > > > > > > > > Currently your driver only works on my imx8mm-venice-* boards if > > > > > I add one of the following on boards that don't connect those > > > > > pads (or if I clear > > > > > IMX8MM_GPR_PCIE_REF_USE_PAD): > > > > > MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B > > > > > MX8MM_IOMUXC_UART4_RXD_PCIE1_CLKREQ_B > > > > > > > > > > Note your 'PCI: imx: add the imx8mm pcie support' patch [1] does > > > > > enable this code already in the imx6_pcie_enable_ref_clk > > > > > function to override REF_CLK and drive it low: > > > > > > > > > > offset = imx6_pcie_grp_offset(imx6_pcie); > > > > > /* > > > > > * Set the over ride low and enabled > > > > > * make sure that REF_CLK is turned on. > > > > > */ > > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > > > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE, > > > > > 0); > > > > > regmap_update_bits(imx6_pcie->iomuxc_gpr, offset, > > > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN, > > > > > IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN); > > > > > > > > > > So this is already being run and yet my boards still do not work > > > > > unless I clr IMX8MM_GPR_PCIE_REF_USE_PAD like this which is > what > > > > > the NXP downstream driver does: > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, > > > > > IMX8MM_GPR_PCIE_REF_USE_PAD, 0); > > > > > > > > > > This is why I'm not sure that bit does what you think it does... > > > > > I feel like that bit enables 'Use CLKREQ# to enable CLK'. > > > > > > > > > > You tell me the descriptions for GPR14 are wrong in the reference > manual. > > > > > Please provide correct descriptions for us so we can sort this out. > > > > > > > > > [Richard Zhu] Hi Tim: > > > > The BIT9 of GPR14 is used as > "GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN" > > > > and BIT19 is used as "GPR_PCIE1_PHY_FUNC_I_AUX_EN" on > i.MX8MM. > > > > I think the two bits descriptions are used to describe the BIT19 > > > > and BIT9 > > > together refer to my guess. > > > > {GPR_PCIE1_PHY_I_AUX_EN_OVERRIDE_EN(BIT9), > > > > GPR_PCIE1_PHY_FUNC_I_AUX_EN(BIT19) } > > > > 2'b00: External Reference Clock I/O (for PLL) Disable > > > > 2'b01: External Reference Clock I/O (for PLL) Enable > > > > 2'b10: External Reference Clock I/O (for PLL) Disable > > > > 2'b11: External Reference Clock I/O (for PLL) output is controlled > > > > by CLKREQ# > > > > > > > > The option1&3 should be forbidden, since the external REF CLK I/O > > > > should > > > be enabled on your board and EVK board. > > > > In the option2&4, the BIT19 should be set to be 1'b1.' > > > > > > > > So, regarding my understand, if the CLKREQ# is not pinmuxed in > > > > your use > > > case, the IMX8MM_GPR_PCIE_REF_USE_PAD (BIT9) should be 1'b0. > > > > > > > > > > Richard, > > > > > > Ok, if this is the case then drivers/pci/controller/dwc/pci-imx6.c > > > for IMX8MM should not touch GPR14 and '[v3,9/9] PCI: imx: add the > imx8mm pcie support' > > > should have this on top and squashed: > > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c > > > b/drivers/pci/controller/dwc/pci-imx6.c > > > index 7c89bd1a6441..458d54c8e385 100644 > > > --- a/drivers/pci/controller/dwc/pci-imx6.c > > > +++ b/drivers/pci/controller/dwc/pci-imx6.c > > > @@ -452,8 +452,12 @@ static int imx6_pcie_enable_ref_clk(struct > > > imx6_pcie *imx6_pcie) > > > break; > > > case IMX7D: > > > break; > > > - case IMX8MQ: > > > case IMX8MM: > > > + ret = clk_prepare_enable(imx6_pcie->pcie_aux); > > > + if (ret) > > > + dev_err(dev, "unable to enable > pcie_aux > > > clock\n"); > > > + break; > > > + case IMX8MQ: > > > ret = clk_prepare_enable(imx6_pcie->pcie_aux); > > > if (ret) { > > > dev_err(dev, "unable to enable > pcie_aux > > > clock\n"); > > > > > [Richard Zhu] Sorry, I might don't understand what's meaning of the > changes. > > What're the differences between before and after the changes? > > > > The above change to your patch 'only' calls clk_prepare_enable for > IMX8MM and does not touch GPR14 bits as the IMX8MQ case does > (because as you point out the GPR14 bits differ between IMX8MM and > IMX8MQ). [Richard Zhu] Got that, thanks a lot. > > > > > > > And your '[v3,5/9] phy: freescale: pcie: initialize the imx8 pcie > > > standalone phy driver' should have this on top and squashed: > > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > > index 317cf61bff37..27ca0b9f1d92 100644 > > > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > > @@ -43,7 +43,7 @@ > > > #define IMX8MM_GPR_PCIE_CMN_RST BIT(18) > > > #define IMX8MM_GPR_PCIE_POWER_OFF BIT(17) > > > #define IMX8MM_GPR_PCIE_SSC_EN BIT(16) > > > -#define IMX8MM_GPR_PCIE_REF_USE_PAD BIT(9) > > > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE BIT(9) > > > > > > struct imx8_pcie_phy { > > > u32 refclk_pad_mode; > > > @@ -63,12 +63,12 @@ static int imx8_pcie_phy_init(struct phy *phy) > > > reset_control_assert(imx8_phy->reset); > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > > - IMX8MM_GPR_PCIE_REF_USE_PAD, > > > - imx8_phy->refclk_pad_mode == 1 ? > > > - IMX8MM_GPR_PCIE_REF_USE_PAD : > 0); > > > + > IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE, > > > + 0); > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > > IMX8MM_GPR_PCIE_AUX_EN, > > > - IMX8MM_GPR_PCIE_AUX_EN); > > > + imx8_phy->refclk_pad_mode == > > > IMX8_PCIE_REFCLK_PAD_INPUT ? > > > + IMX8MM_GPR_PCIE_AUX_EN : 0); > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > > IMX8MM_GPR_PCIE_POWER_OFF, > 0); > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, @@ > > > -76,7 +76,7 @@ static int imx8_pcie_phy_init(struct phy *phy) > > > > > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > > > IMX8MM_GPR_PCIE_REF_CLK_SEL, > > > - imx8_phy->refclk_pad_mode == 1 ? > > > + imx8_phy->refclk_pad_mode == > > > IMX8_PCIE_REFCLK_PAD_INPUT ? > > > > IMX8MM_GPR_PCIE_REF_CLK_EXT : > > > > IMX8MM_GPR_PCIE_REF_CLK_PLL); > > > usleep_range(100, 200); > > > > > > I tested this and it works both on imx8mm-evk and imx8mm-venice-* > > > which both have external clkgen. > > > > > > However, the above does not set > IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE for > > > the case where CLKREQ# is connected and thus should be used so I > > > think we need to add a property for that to define if CLKREQ# is > > > hooked up or not. I tested enabling > IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE > > > and as expected that worked on the imx8mm-evk which hooks up > CLKREQ# > > > but not imx8mm-venice which does not hook up CLKREQ#. > > > > > > What do you think about adding a property for this? > > [Richard Zhu] First of all, thanks a lot for your help to figure out the > details. > > Agree with your proposal. > > One optional property "fsl,clkreq-unsupported" would be added for the > CLKREQ# not hooked case later. > > > > diff --git > > a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml > > b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml > > index 097ba2a28fb4..2264452924cc 100644 > > --- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml > > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml > > @@ -58,6 +58,11 @@ properties: > > $ref: /schemas/types.yaml#/definitions/uint32 > > default: 0 > > > > + fsl,clkreq-unsupported: > > + type: boolean > > + description: A boolean property whoes presence indicates the > CLKREQ# > > + signal isn't supported in the HW board design (optional > required). > > + > > A boolean property indicating the CLKREQ# signal is not supported in the > board design (optional) [Richard Zhu] Okay, would be updated later. > > > > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > index 07eea39283ed..4b4402eaddcc 100644 > > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c > > @@ -43,7 +43,7 @@ > > #define IMX8MM_GPR_PCIE_CMN_RST BIT(18) > > #define IMX8MM_GPR_PCIE_POWER_OFF BIT(17) > > #define IMX8MM_GPR_PCIE_SSC_EN BIT(16) > > -#define IMX8MM_GPR_PCIE_REF_USE_PAD BIT(9) > > +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE BIT(9) > > > > struct imx8_pcie_phy { > > void __iomem *base; > > @@ -54,6 +54,7 @@ struct imx8_pcie_phy { > > u32 refclk_pad_mode; > > u32 tx_deemph_gen1; > > u32 tx_deemph_gen2; > > + bool clkreq_unused; > > }; > > > > static int imx8_pcie_phy_init(struct phy *phy) @@ -65,13 +66,15 @@ > > static int imx8_pcie_phy_init(struct phy *phy) > > reset_control_assert(imx8_phy->reset); > > > > pad_mode = imx8_phy->refclk_pad_mode; > > + /* Set AUX_EN_OVERRIDE 1'b0, when the CLKREQ# isn't > hooked */ > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > - IMX8MM_GPR_PCIE_REF_USE_PAD, > > - pad_mode == > IMX8MM_GPR_PCIE_REF_USE_PAD ? > > - IMX8MM_GPR_PCIE_REF_USE_PAD : > 0); > > + > IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE, > > + imx8_phy->clkreq_unused ? > > + 0 : > IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE); > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > IMX8MM_GPR_PCIE_AUX_EN, > > - IMX8MM_GPR_PCIE_AUX_EN); > > + pad_mode == > IMX8_PCIE_REFCLK_PAD_INPUT ? > > + IMX8MM_GPR_PCIE_AUX_EN : 0); > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, > > IMX8MM_GPR_PCIE_POWER_OFF, > 0); > > regmap_update_bits(imx8_phy->iomuxc_gpr, > IOMUXC_GPR14, @@ > > -171,6 +174,11 @@ static int imx8_pcie_phy_probe(struct > platform_device *pdev) > > > &imx8_phy->tx_deemph_gen2)) > > imx8_phy->tx_deemph_gen2 = 0; > > > > + if (of_property_read_bool(np, "fsl,clkreq-unsupported")) > > + imx8_phy->clkreq_unused = true; > > + else > > + imx8_phy->clkreq_unused = false; > > + > > imx8_phy->clk = devm_clk_get(dev, "ref"); > > if (IS_ERR(imx8_phy->clk)) { > > dev_err(dev, "failed to get imx pcie phy clock\n"); > > > > Yes this looks good and works both on venice (with > 'fsl,clkreq-unsupported' added) and on imx8mm-evk. > > Thanks for working through this with me and please cc me on your v4 > submission. [Richard Zhu] Welcome. I'm glad to have your help. Thanks a lot. > > Best regards, > > Tim