| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <AS8PR04MB86767FA0C6A323B2205D704E8CFD9@AS8PR04MB8676.eurprd04.prod.outlook.com>
Date: Thu, 28 Apr 2022 01:29:56 +0000
From: Hongxing Zhu <hongxing.zhu@....com>
To: Lucas Stach <l.stach@...gutronix.de>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
"robh@...nel.org" <robh@...nel.org>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"vkoul@...nel.org" <vkoul@...nel.org>,
"alexander.stein@...tq-group.com" <alexander.stein@...tq-group.com>
CC: "linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH v2 3/7] phy: freescale: imx8m-pcie: Add iMX8MP PCIe PHY
support
> -----Original Message-----
> From: Lucas Stach <l.stach@...gutronix.de>
> Sent: 2022年4月27日 23:19
> To: Hongxing Zhu <hongxing.zhu@....com>; p.zabel@...gutronix.de;
> bhelgaas@...gle.com; lorenzo.pieralisi@....com; robh@...nel.org;
> shawnguo@...nel.org; vkoul@...nel.org; alexander.stein@...tq-group.com
> Cc: linux-phy@...ts.infradead.org; devicetree@...r.kernel.org;
> linux-pci@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> linux-kernel@...r.kernel.org; kernel@...gutronix.de; dl-linux-imx
> <linux-imx@....com>
> Subject: Re: [PATCH v2 3/7] phy: freescale: imx8m-pcie: Add iMX8MP PCIe PHY
> support
>
> Hi Richard,
>
> Am Montag, dem 18.04.2022 um 04:55 +0000 schrieb Hongxing Zhu:
> > > -----Original Message-----
> > > From: Lucas Stach <l.stach@...gutronix.de>
> > > Sent: 2022年4月15日 4:59
> > > To: Hongxing Zhu <hongxing.zhu@....com>; p.zabel@...gutronix.de;
> > > bhelgaas@...gle.com; lorenzo.pieralisi@....com; robh@...nel.org;
> > > shawnguo@...nel.org; vkoul@...nel.org;
> > > alexander.stein@...tq-group.com
> > > Cc: linux-phy@...ts.infradead.org; devicetree@...r.kernel.org;
> > > linux-pci@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> > > linux-kernel@...r.kernel.org; kernel@...gutronix.de; dl-linux-imx
> > > <linux-imx@....com>
> > > Subject: Re: [PATCH v2 3/7] phy: freescale: imx8m-pcie: Add iMX8MP
> > > PCIe PHY support
> > >
> > > Am Montag, dem 07.03.2022 um 17:07 +0800 schrieb Richard Zhu:
> > > > Add the i.MX8MP PCIe PHY support
> > > >
> > > > Signed-off-by: Richard Zhu <hongxing.zhu@....com>
> > > > ---
> > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 205
> > > > ++++++++++++++++-----
> > > > 1 file changed, 163 insertions(+), 42 deletions(-)
> > > >
> > > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > > index 04b1aafb29f4..3d01da4323a6 100644
> > > > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > > @@ -11,6 +11,8 @@
> > > > #include <linux/mfd/syscon.h>
> > > > #include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
> > > > #include <linux/module.h>
> > > > +#include <linux/of_address.h>
> > > > +#include <linux/of_device.h>
> > > > #include <linux/phy/phy.h>
> > > > #include <linux/platform_device.h>
> > > > #include <linux/regmap.h>
> > > > @@ -30,12 +32,10 @@
> > > > #define IMX8MM_PCIE_PHY_CMN_REG065 0x194
> > > > #define ANA_AUX_RX_TERM (BIT(7) | BIT(4))
> > > > #define ANA_AUX_TX_LVL GENMASK(3, 0)
> > > > -#define IMX8MM_PCIE_PHY_CMN_REG75 0x1D4
> > > > -#define PCIE_PHY_CMN_REG75_PLL_DONE 0x3
> > > > +#define IMX8MM_PCIE_PHY_CMN_REG075 0x1D4
> > > > +#define ANA_PLL_DONE 0x3
> > >
> > > Why do you drop the register prefix from the name here?
> > To prevent the codes from exceeding the 80 columns and align with the
> > other
> > bit definitions, drop the prefix and keep the bit definitions as
> > short as
> > possible.
> >
> > >
> > > > #define PCIE_PHY_TRSV_REG5 0x414
> > > > -#define PCIE_PHY_TRSV_REG5_GEN1_DEEMP 0x2D
> > > > #define PCIE_PHY_TRSV_REG6 0x418
> > > > -#define PCIE_PHY_TRSV_REG6_GEN2_DEEMP 0xF
> > > >
> > > > #define IMX8MM_GPR_PCIE_REF_CLK_SEL GENMASK(25, 24)
> > > > #define IMX8MM_GPR_PCIE_REF_CLK_PLL
> > > FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> > > > @@ -46,16 +46,43 @@
> > > > #define IMX8MM_GPR_PCIE_SSC_EN BIT(16)
> > > > #define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDE BIT(9)
> > > >
> > > > +#define IMX8MP_GPR_REG0 0x0
> > > > +#define IMX8MP_GPR_CLK_MOD_EN BIT(0)
> > > > +#define IMX8MP_GPR_PHY_APB_RST BIT(4)
> > > > +#define IMX8MP_GPR_PHY_INIT_RST BIT(5)
> > > > +#define IMX8MP_GPR_REG1 0x4
> > > > +#define IMX8MP_GPR_PM_EN_CORE_CLK BIT(0)
> > > > +#define IMX8MP_GPR_PLL_LOCK BIT(13)
> > > > +#define IMX8MP_GPR_REG2 0x8
> > > > +#define IMX8MP_GPR_P_PLL_MASK GENMASK(5, 0)
> > > > +#define IMX8MP_GPR_M_PLL_MASK GENMASK(15, 6)
> > > > +#define IMX8MP_GPR_S_PLL_MASK GENMASK(18, 16)
> > > > +#define IMX8MP_GPR_P_PLL (0xc << 0)
> > > > +#define IMX8MP_GPR_M_PLL (0x320 << 6)
> > > > +#define IMX8MP_GPR_S_PLL (0x4 << 16)
> > > > +#define IMX8MP_GPR_REG3 0xc
> > > > +#define IMX8MP_GPR_PLL_CKE BIT(17)
> > > > +#define IMX8MP_GPR_PLL_RST BIT(31)
> > > > +
> > > > +enum imx8_pcie_phy_type {
> > > > + IMX8MM,
> > > > + IMX8MP,
> > > > +};
> > > > +
> > > > struct imx8_pcie_phy {
> > > > void __iomem *base;
> > > > + struct device *dev;
> > > > struct clk *clk;
> > > > struct phy *phy;
> > > > + struct regmap *hsio_blk_ctrl;
> > > > struct regmap *iomuxc_gpr;
> > > > struct reset_control *reset;
> > > > + struct reset_control *perst;
> > > > u32 refclk_pad_mode;
> > > > u32 tx_deemph_gen1;
> > > > u32 tx_deemph_gen2;
> > > > bool clkreq_unused;
> > > > + enum imx8_pcie_phy_type variant;
> > > > };
> > > >
> > > > static int imx8_pcie_phy_init(struct phy *phy) @@ -67,6 +94,87 @@
> > > > static int imx8_pcie_phy_init(struct phy *phy)
> > > > reset_control_assert(imx8_phy->reset);
> > > >
> > > > pad_mode = imx8_phy->refclk_pad_mode;
> > > > + switch (imx8_phy->variant) {
> > > > + case IMX8MM:
> > > > + /* Tune PHY de-emphasis setting to pass PCIe compliance. */
> > > > + if (imx8_phy->tx_deemph_gen1)
> > > > + writel(imx8_phy->tx_deemph_gen1,
> > > > + imx8_phy->base + PCIE_PHY_TRSV_REG5);
> > > > + if (imx8_phy->tx_deemph_gen2)
> > > > + writel(imx8_phy->tx_deemph_gen2,
> > > > + imx8_phy->base + PCIE_PHY_TRSV_REG6);
> > > > + break;
> > > > + case IMX8MP:
> > > > + reset_control_assert(imx8_phy->perst);
> > >
> > > Could you tell us something more about this reset. What exactly is it
> resetting.
> > > Do we really need to assert it before starting the HSIO PLL?
> > Yes, this reset should be asserted, otherwise, the PCIe wouldn't work.
> > I'm asking more details of this reset bit from design team, and would
> > update
> > later after I get the response.
> >
> > > AFAICS the PLL should be pretty much independent of the PHY.
> > Agree.
> >
> > >
> > > Do we need to enable this PLL when the PHY gets an external
> > > refclock? I couldn't test it yet, but I suspect that the HSIO PLL is
> > > only needed as an internal reference, when the i.MX8MP is the
> > > refclock source, either through the PHY pads or via a clkout from the PLL.
> > >
> > Refer to my experience, the HSIO PLL should be enabled firstly.
> >
> > > > + /* Set P=12,M=800,S=4 and must set ICP=2'b01. */
> > > > + regmap_update_bits(imx8_phy->hsio_blk_ctrl,
> IMX8MP_GPR_REG2,
> > > > + IMX8MP_GPR_P_PLL_MASK |
> > > > + IMX8MP_GPR_M_PLL_MASK |
> > > > + IMX8MP_GPR_S_PLL_MASK,
> > > > + IMX8MP_GPR_P_PLL |
> > > > + IMX8MP_GPR_M_PLL |
> > > > + IMX8MP_GPR_S_PLL);
> > > > + /* wait greater than 1/F_FREF =1/2MHZ=0.5us */
> > > > + udelay(1);
> > > > +
> > > > + regmap_update_bits(imx8_phy->hsio_blk_ctrl,
> IMX8MP_GPR_REG3,
> > > > + IMX8MP_GPR_PLL_RST,
> > > > + IMX8MP_GPR_PLL_RST);
> > > > + udelay(10);
> > > > +
> > > > + /* Set 1 to pll_cke of GPR_REG3 */
> > > > + regmap_update_bits(imx8_phy->hsio_blk_ctrl,
> IMX8MP_GPR_REG3,
> > > > + IMX8MP_GPR_PLL_CKE,
> > > > + IMX8MP_GPR_PLL_CKE);
> > > > +
> > > > + /* Lock time should be greater than 300cycle=300*0.5us=150us
> */
> > > > + ret = regmap_read_poll_timeout(imx8_phy->hsio_blk_ctrl,
> > > > + IMX8MP_GPR_REG1, val,
> > > > + val & IMX8MP_GPR_PLL_LOCK,
> > > > + 10, 1000);
> > > > + if (ret) {
> > > > + dev_err(imx8_phy->dev, "PCIe PLL lock timeout\n");
> > > > + return ret;
> > > > + }
> > > > +
> > > > + /* pcie_clock_module_en */
> > > > + regmap_update_bits(imx8_phy->hsio_blk_ctrl,
> IMX8MP_GPR_REG0,
> > > > + IMX8MP_GPR_CLK_MOD_EN,
> > > > + IMX8MP_GPR_CLK_MOD_EN);
> > >
> > > You shouldn't need to touch this bit. The HSIO blk-ctrl already
> > > enables this bit when the PCIe power-domain is powered up.
> > Okay, got that.
> >
> > >
> > > > + udelay(10);
> > > > +
> > > > + reset_control_deassert(imx8_phy->reset);
> > > > + reset_control_deassert(imx8_phy->perst);
> > > > +
> > > > + /* release pcie_phy_apb_reset and pcie_phy_init_resetn */
> > > > + regmap_update_bits(imx8_phy->hsio_blk_ctrl,
> IMX8MP_GPR_REG0,
> > > > + IMX8MP_GPR_PHY_APB_RST |
> > > > + IMX8MP_GPR_PHY_INIT_RST,
> > > > + IMX8MP_GPR_PHY_APB_RST |
> > > > + IMX8MP_GPR_PHY_INIT_RST);
> > >
> > > Not sure about those yet. We might want to toggle them via a virtual
> > > PD in the HSIO blk-ctrl.
> > Refer to my understand, these reset should be a part of power-up
> > sequence of
> > the PHY. It's reasonable to toggle them via a PD.
>
> So I had a chance to look into why this series isn't working for me some more.
>
> It seems the full PHY initialization fails, as the complete PHY MMIO region
> reads back as 0xff. This hints at either a missing clock, or (more likely) the
> register interface of the PHY being held in reset.
> Note that I'm running upstream TF-A and the Barebox bootloader, so this
> might be a missing initialization somewhere, that is done by downstream TF-A
> or U-Boot.
>
> Sadly the above bits are also not documented in the RM, but are marked as
> reserved. By chance, do you know about any other secondary clocks/resets
> that may have an impact on PCIe?
>
Hi Lucas:
Thanks for your help to look at this series.
Refer to your descriptions, it seems that one initial version i.MX865 chip
is used at your side.
There is a design bug in the initial version of i.MX865 PCIe. All the PHY MMIO
region reads back as 0xff.
It is fixed by the later chips. Find another newer board is a quick method to
fix it. Or, apply one SW workaround to let it work only in Gen1/Gen2 modes.
Best Regards
Richard Zhu
> Regards,
> Lucas
Powered by blists - more mailing lists