-----Original Message----- From: Adam Ford aford173@gmail.com Sent: 2024年11月2日 3:53 To: Hongxing Zhu hongxing.zhu@nxp.com Cc: Frank Li frank.li@nxp.com; vkoul@kernel.org; festevam@gmail.com; imx@lists.linux.dev; kernel@pengutronix.de; kishon@kernel.org; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; Marcel Ziswiler marcel.ziswiler@toradex.com; s.hauer@pengutronix.de; shawnguo@kernel.org; stable@vger.kernel.org Subject: Re: [PATCH v2 1/1] phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check
On Mon, Oct 21, 2024 at 11:06 PM Hongxing Zhu hongxing.zhu@nxp.com wrote:
-----Original Message----- From: Frank Li frank.li@nxp.com Sent: 2024年10月21日 23:53 To: vkoul@kernel.org Cc: Frank Li frank.li@nxp.com; festevam@gmail.com; Hongxing Zhu hongxing.zhu@nxp.com; imx@lists.linux.dev; kernel@pengutronix.de; kishon@kernel.org; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; Marcel Ziswiler marcel.ziswiler@toradex.com; s.hauer@pengutronix.de; shawnguo@kernel.org; stable@vger.kernel.org Subject: [PATCH v2 1/1] phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check
From: Richard Zhu hongxing.zhu@nxp.com
When enable initcall_debug together with higher debug level below. CONFIG_CONSOLE_LOGLEVEL_DEFAULT=9 CONFIG_CONSOLE_LOGLEVEL_QUIET=9 CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7
The initialization of i.MX8MP PCIe PHY might be timeout failed randomly. To fix this issue, adjust the sequence of the resets refer to the power up sequence listed below.
i.MX8MP PCIe PHY power up sequence: /--------------------------------------------- 1.8v supply ---------/ /--------------------------------------------------- 0.8v supply ---/
---\ /-------------------------------------------------- X REFCLK ValidReference Clock ---/ --------------------------------------------------
|i_init_restn --------------
|i_cmn_rstn ---------------------
| o_pll_lock_done
Logs: imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges: imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000 imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000 probe of clk_imx8mp_audiomix.reset.0 returned 0 after 1052 usecs probe of 30e20000.clock-controller returned 0 after 32971 usecs phy phy-32f00000.pcie-phy.4: phy poweron failed --> -110 probe of 30e10000.dma-controller returned 0 after 10235 usecs imx6q-pcie 33800000.pcie: waiting for PHY ready timeout! dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2) imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
Fixes: dce9edff16ee ("phy: freescale: imx8m-pcie: Add i.MX8MP PCIe PHY support") Cc: stable@vger.kernel.org Signed-off-by: Richard Zhu hongxing.zhu@nxp.com Signed-off-by: Frank Li Frank.Li@nxp.com
v2 changes:
- Rebase to latest fixes branch of linux-phy git repo.
- Richard's environment have problem and can't sent out patch. So I
help post this fix patch.
Even with this patch, I am still seeing an occasional timeout on 8MP. I looked at some logs on a similarly functioning 8MM and I can't get this error to appear on Mini that I see on Plus.
The TRM doesn't document the timing of the startup sequence, like this e-mail patch did nor does it state how long a reasonable timeout should take. So, I started looking through the code and I noticed that the Mini asserts the reset at the beginning, then makes all the changes, and de-asserts the resets toward the end. Is there any reason we should not assert one or both of the resets on 8MP before setting up the reset of the registers like the way Mini does it?
Yes, I had the similar confusions when I try to bring up i.MX8MP PCIe. i.MX8MP PCIe resets have the different designs but I don't know the reason and the details. These resets shouldn't be asserted/de-asserted as Mini does during the initialization.
On i.MX8MP, these resets should be configured one-shot. I used to toggle them in my own experiments. Unfortunately, the PCIe PHY wouldn't be functional.
Best Regards Richard Zhu
adam
Hi Frank: Thanks a lot for your kindly help. Since my server is down, I can't send out this v2 in the past days.
Hi Vinod: Sorry for the late reply, and bring you inconvenience.
Best Regards Richard Zhu
drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c index 11fcb1867118c..e98361dcdeadf 100644 --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c @@ -141,11 +141,6 @@ static int imx8_pcie_phy_power_on(struct phy *phy) IMX8MM_GPR_PCIE_REF_CLK_PLL); usleep_range(100, 200);
/* Do the PHY common block reset */regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,IMX8MM_GPR_PCIE_CMN_RST,IMX8MM_GPR_PCIE_CMN_RST);switch (imx8_phy->drvdata->variant) { case IMX8MP: reset_control_deassert(imx8_phy->perst);@@ -156,6 +151,11 @@ static int imx8_pcie_phy_power_on(struct phy *phy) break; }
/* Do the PHY common block reset */regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,IMX8MM_GPR_PCIE_CMN_RST,IMX8MM_GPR_PCIE_CMN_RST);/* Polling to check the phy is ready or not. */ ret = readl_poll_timeout(imx8_phy->base +IMX8MM_PCIE_PHY_CMN_REG075, val, val == ANA_PLL_DONE, 10,
20000);
-- 2.34.1
-- linux-phy mailing list linux-phy@lists.infradead.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
s.infradead.org%2Fmailman%2Flistinfo%2Flinux-phy&data=05%7C02%7Chongxi
ng.zhu%40nxp.com%7C666c8968b3094147ed4408dcfaaec631%7C686ea1d3bc 2b4c6f
a92cd99c5c301635%7C0%7C0%7C638660875771545687%7CUnknown%7CTWF pbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% 7C0
%7C%7C%7C&sdata=3Mg4SqcaA%2FlbScveriGBBMOq1YOTt3okydgHmjmdLps
%3D&reser
ved=0