| Message ID | 20240415182052.374494-7-mr.nuke.me@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | ipq9574: Enable PCI-Express support | expand |
On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> wrote: > > Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream > 5.4 kernel. Only the serdes and pcs_misc tables are new, the others > being reused from IPQ8074 and IPQ6018 PHYs. > > Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> > --- > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- > .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ > 2 files changed, 149 insertions(+), 1 deletion(-) > [skipped] > @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val) > > /* list of clocks required by phy */ > static const char * const qmp_pciephy_clk_l[] = { > - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", "anoc", "snoc" Are the NoC clocks really necessary to drive the PHY? I think they are usually connected to the controllers, not the PHYs. > }; > > /* list of regulators */ > @@ -2499,6 +2593,16 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x1 = { > .rx = 0x0400, > }; > > +static const struct qmp_pcie_offsets qmp_pcie_offsets_ipq9574 = { > + .serdes = 0, > + .pcs = 0x1000, > + .pcs_misc = 0x1400, > + .tx = 0x0200, > + .rx = 0x0400, > + .tx2 = 0x0600, > + .rx2 = 0x0800, > +}; > + > static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x2 = { > .serdes = 0, > .pcs = 0x0a00, > @@ -2728,6 +2832,33 @@ static const struct qmp_phy_cfg sm8250_qmp_gen3x1_pciephy_cfg = { > .phy_status = PHYSTATUS, > }; > > +static const struct qmp_phy_cfg ipq9574_pciephy_gen3x2_cfg = { > + .lanes = 2, > + > + .offsets = &qmp_pcie_offsets_ipq9574, > + > + .tbls = { > + .serdes = ipq9574_gen3x2_pcie_serdes_tbl, > + .serdes_num = ARRAY_SIZE(ipq9574_gen3x2_pcie_serdes_tbl), > + .tx = ipq8074_pcie_gen3_tx_tbl, > + .tx_num = ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl), > + .rx = ipq6018_pcie_rx_tbl, > + .rx_num = ARRAY_SIZE(ipq6018_pcie_rx_tbl), > + .pcs = ipq6018_pcie_pcs_tbl, > + .pcs_num = ARRAY_SIZE(ipq6018_pcie_pcs_tbl), > + .pcs_misc = ipq9574_gen3x2_pcie_pcs_misc_tbl, > + .pcs_misc_num = ARRAY_SIZE(ipq9574_gen3x2_pcie_pcs_misc_tbl), > + }, > + .reset_list = ipq8074_pciephy_reset_l, > + .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l), > + .vreg_list = NULL, > + .num_vregs = 0, > + .regs = pciephy_v4_regs_layout, So, is it v4 or v5? > + > + .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, > + .phy_status = PHYSTATUS, > +}; > + > static const struct qmp_phy_cfg sm8250_qmp_gen3x2_pciephy_cfg = { > .lanes = 2, > -- With best wishes Dmitry
On 4/15/24 15:10, Dmitry Baryshkov wrote: > On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> wrote: >> >> Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream >> 5.4 kernel. Only the serdes and pcs_misc tables are new, the others >> being reused from IPQ8074 and IPQ6018 PHYs. >> >> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> >> --- >> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- >> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ >> 2 files changed, 149 insertions(+), 1 deletion(-) >> > > [skipped] > >> @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val) >> >> /* list of clocks required by phy */ >> static const char * const qmp_pciephy_clk_l[] = { >> - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", >> + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", "anoc", "snoc" > > Are the NoC clocks really necessary to drive the PHY? I think they are > usually connected to the controllers, not the PHYs. The system will hang if these clocks are not enabled. They are also attached to the PHY in the QCA 5.4 downstream kernel. >> }; >> >> /* list of regulators */ >> @@ -2499,6 +2593,16 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x1 = { >> .rx = 0x0400, >> }; >> >> +static const struct qmp_pcie_offsets qmp_pcie_offsets_ipq9574 = { >> + .serdes = 0, >> + .pcs = 0x1000, >> + .pcs_misc = 0x1400, >> + .tx = 0x0200, >> + .rx = 0x0400, >> + .tx2 = 0x0600, >> + .rx2 = 0x0800, >> +}; >> + >> static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x2 = { >> .serdes = 0, >> .pcs = 0x0a00, >> @@ -2728,6 +2832,33 @@ static const struct qmp_phy_cfg sm8250_qmp_gen3x1_pciephy_cfg = { >> .phy_status = PHYSTATUS, >> }; >> >> +static const struct qmp_phy_cfg ipq9574_pciephy_gen3x2_cfg = { >> + .lanes = 2, >> + >> + .offsets = &qmp_pcie_offsets_ipq9574, >> + >> + .tbls = { >> + .serdes = ipq9574_gen3x2_pcie_serdes_tbl, >> + .serdes_num = ARRAY_SIZE(ipq9574_gen3x2_pcie_serdes_tbl), >> + .tx = ipq8074_pcie_gen3_tx_tbl, >> + .tx_num = ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl), >> + .rx = ipq6018_pcie_rx_tbl, >> + .rx_num = ARRAY_SIZE(ipq6018_pcie_rx_tbl), >> + .pcs = ipq6018_pcie_pcs_tbl, >> + .pcs_num = ARRAY_SIZE(ipq6018_pcie_pcs_tbl), >> + .pcs_misc = ipq9574_gen3x2_pcie_pcs_misc_tbl, >> + .pcs_misc_num = ARRAY_SIZE(ipq9574_gen3x2_pcie_pcs_misc_tbl), >> + }, >> + .reset_list = ipq8074_pciephy_reset_l, >> + .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l), >> + .vreg_list = NULL, >> + .num_vregs = 0, >> + .regs = pciephy_v4_regs_layout, > > So, is it v4 or v5? Please give me a day or so to go over my notes and give you a more coherent explanation of why this versioning was chosen. I am only working from the QCA 5.4 downstream sources. I don't have any documentation for the silicon Alex > >> + >> + .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, >> + .phy_status = PHYSTATUS, >> +}; >> + >> static const struct qmp_phy_cfg sm8250_qmp_gen3x2_pciephy_cfg = { >> .lanes = 2, >> > > > > -- > With best wishes > Dmitry
Hi Dmitry, On 4/15/24 16:25, mr.nuke.me@gmail.com wrote: > > > On 4/15/24 15:10, Dmitry Baryshkov wrote: >> On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> >> wrote: >>> >>> Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream >>> 5.4 kernel. Only the serdes and pcs_misc tables are new, the others >>> being reused from IPQ8074 and IPQ6018 PHYs. >>> >>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> >>> --- >>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- >>> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ >>> 2 files changed, 149 insertions(+), 1 deletion(-) >>> >> >> [skipped] >> >>> @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem >>> *base, u32 offset, u32 val) >>> >>> /* list of clocks required by phy */ >>> static const char * const qmp_pciephy_clk_l[] = { >>> - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", >>> + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", >>> "anoc", "snoc" >> >> Are the NoC clocks really necessary to drive the PHY? I think they are >> usually connected to the controllers, not the PHYs. > > The system will hang if these clocks are not enabled. They are also > attached to the PHY in the QCA 5.4 downstream kernel. > They are named "anoc_lane", and "snoc_lane" in the downstream kernel. Would you like me to use these names instead? e>>> }; >>> >>> /* list of regulators */ >>> @@ -2499,6 +2593,16 @@ static const struct qmp_pcie_offsets >>> qmp_pcie_offsets_v4x1 = { >>> .rx = 0x0400, >>> }; >>> >>> +static const struct qmp_pcie_offsets qmp_pcie_offsets_ipq9574 = { >>> + .serdes = 0, >>> + .pcs = 0x1000, >>> + .pcs_misc = 0x1400, >>> + .tx = 0x0200, >>> + .rx = 0x0400, >>> + .tx2 = 0x0600, >>> + .rx2 = 0x0800, >>> +}; >>> + >>> static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x2 = { >>> .serdes = 0, >>> .pcs = 0x0a00, >>> @@ -2728,6 +2832,33 @@ static const struct qmp_phy_cfg >>> sm8250_qmp_gen3x1_pciephy_cfg = { >>> .phy_status = PHYSTATUS, >>> }; >>> >>> +static const struct qmp_phy_cfg ipq9574_pciephy_gen3x2_cfg = { >>> + .lanes = 2, >>> + >>> + .offsets = &qmp_pcie_offsets_ipq9574, >>> + >>> + .tbls = { >>> + .serdes = ipq9574_gen3x2_pcie_serdes_tbl, >>> + .serdes_num = >>> ARRAY_SIZE(ipq9574_gen3x2_pcie_serdes_tbl), >>> + .tx = ipq8074_pcie_gen3_tx_tbl, >>> + .tx_num = ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl), >>> + .rx = ipq6018_pcie_rx_tbl, >>> + .rx_num = ARRAY_SIZE(ipq6018_pcie_rx_tbl), >>> + .pcs = ipq6018_pcie_pcs_tbl, >>> + .pcs_num = ARRAY_SIZE(ipq6018_pcie_pcs_tbl), >>> + .pcs_misc = ipq9574_gen3x2_pcie_pcs_misc_tbl, >>> + .pcs_misc_num = >>> ARRAY_SIZE(ipq9574_gen3x2_pcie_pcs_misc_tbl), >>> + }, >>> + .reset_list = ipq8074_pciephy_reset_l, >>> + .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l), >>> + .vreg_list = NULL, >>> + .num_vregs = 0, >>> + .regs = pciephy_v4_regs_layout, >> >> So, is it v4 or v5? > > Please give me a day or so to go over my notes and give you a more > coherent explanation of why this versioning was chosen. I am only > working from the QCA 5.4 downstream sources. I don't have any > documentation for the silicon The downstream QCA kernel uses the same table for ipq6018, ipq8074-gen3, and ipq9574. It is named "ipq_pciephy_gen3_regs_layout". Thus, it made sense to use the same upstream table for ipq9574, "pciephy_v4_regs_layout". As far as the register tables go, the pcs/pcs_misc are squashed into the same table in the downstream 5.4 kernel. I was able to separate the two tables because the pcs_misc registers were defined with an offset of 0x400. For example: /* QMP V2 PHY for PCIE gen3 2 Lane ports - PCS Misc registers */ #define PCS_PCIE_X2_POWER_STATE_CONFIG2 0x40c #define PCS_PCIE_X2_POWER_STATE_CONFIG4 0x414 #define PCS_PCIE_X2_ENDPOINT_REFCLK_DRIVE 0x420 #define PCS_PCIE_X2_L1P1_WAKEUP_DLY_TIME_AUXCLK_L 0x444 #define PCS_PCIE_X2_L1P1_WAKEUP_DLY_TIME_AUXCLK_H 0x448 #define PCS_PCIE_X2_L1P2_WAKEUP_DLY_TIME_AUXCLK_L 0x44c #define PCS_PCIE_X2_L1P2_WAKEUP_DLY_TIME_AUXCLK_H 0x450 ... Here, QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG2 = 0xc would be correct, assuming a pcs_misc offset of 0x400. However, starting with ENDPOINT_REFCLK_DRIVE, the register would be QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_DRIVE = 0x1c. Our offsets are off-by 0x4. The existing V5 offsets, on the other hand, were all correct. For this reason, I considered that V5 is the most likely place to add the missing PCS misc definitions. Is this explanation sufficiently convincing? Where does the v4/v5 scheme in upstream kernel originate? Alex
On Wed, 17 Apr 2024 at 00:25, Alex G. <mr.nuke.me@gmail.com> wrote: > > Hi Dmitry, > > On 4/15/24 16:25, mr.nuke.me@gmail.com wrote: > > > > > > On 4/15/24 15:10, Dmitry Baryshkov wrote: > >> On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> > >> wrote: > >>> > >>> Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream > >>> 5.4 kernel. Only the serdes and pcs_misc tables are new, the others > >>> being reused from IPQ8074 and IPQ6018 PHYs. > >>> > >>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> > >>> --- > >>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- > >>> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ > >>> 2 files changed, 149 insertions(+), 1 deletion(-) > >>> > >> > >> [skipped] > >> > >>> @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem > >>> *base, u32 offset, u32 val) > >>> > >>> /* list of clocks required by phy */ > >>> static const char * const qmp_pciephy_clk_l[] = { > >>> - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > >>> + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > >>> "anoc", "snoc" > >> > >> Are the NoC clocks really necessary to drive the PHY? I think they are > >> usually connected to the controllers, not the PHYs. > > > > The system will hang if these clocks are not enabled. They are also > > attached to the PHY in the QCA 5.4 downstream kernel. Interesting. I see that Varadarajan is converting these clocks into interconnects. Maybe it's better to wait for those patches to land and use interconnects instead. I think it would better suit the infrastructure. Varadarajan, could you please comment, are these interconnects connected to the PHY too or just to the PCIe controller? > > > They are named "anoc_lane", and "snoc_lane" in the downstream kernel. > Would you like me to use these names instead? I'm fine either way. > e>>> }; > >>> > >>> /* list of regulators */ > >>> @@ -2499,6 +2593,16 @@ static const struct qmp_pcie_offsets > >>> qmp_pcie_offsets_v4x1 = { > >>> .rx = 0x0400, > >>> }; > >>> > >>> +static const struct qmp_pcie_offsets qmp_pcie_offsets_ipq9574 = { > >>> + .serdes = 0, > >>> + .pcs = 0x1000, > >>> + .pcs_misc = 0x1400, > >>> + .tx = 0x0200, > >>> + .rx = 0x0400, > >>> + .tx2 = 0x0600, > >>> + .rx2 = 0x0800, > >>> +}; > >>> + > >>> static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x2 = { > >>> .serdes = 0, > >>> .pcs = 0x0a00, > >>> @@ -2728,6 +2832,33 @@ static const struct qmp_phy_cfg > >>> sm8250_qmp_gen3x1_pciephy_cfg = { > >>> .phy_status = PHYSTATUS, > >>> }; > >>> > >>> +static const struct qmp_phy_cfg ipq9574_pciephy_gen3x2_cfg = { > >>> + .lanes = 2, > >>> + > >>> + .offsets = &qmp_pcie_offsets_ipq9574, > >>> + > >>> + .tbls = { > >>> + .serdes = ipq9574_gen3x2_pcie_serdes_tbl, > >>> + .serdes_num = > >>> ARRAY_SIZE(ipq9574_gen3x2_pcie_serdes_tbl), > >>> + .tx = ipq8074_pcie_gen3_tx_tbl, > >>> + .tx_num = ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl), > >>> + .rx = ipq6018_pcie_rx_tbl, > >>> + .rx_num = ARRAY_SIZE(ipq6018_pcie_rx_tbl), > >>> + .pcs = ipq6018_pcie_pcs_tbl, > >>> + .pcs_num = ARRAY_SIZE(ipq6018_pcie_pcs_tbl), > >>> + .pcs_misc = ipq9574_gen3x2_pcie_pcs_misc_tbl, > >>> + .pcs_misc_num = > >>> ARRAY_SIZE(ipq9574_gen3x2_pcie_pcs_misc_tbl), > >>> + }, > >>> + .reset_list = ipq8074_pciephy_reset_l, > >>> + .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l), > >>> + .vreg_list = NULL, > >>> + .num_vregs = 0, > >>> + .regs = pciephy_v4_regs_layout, > >> > >> So, is it v4 or v5? > > > > Please give me a day or so to go over my notes and give you a more > > coherent explanation of why this versioning was chosen. I am only > > working from the QCA 5.4 downstream sources. I don't have any > > documentation for the silicon > > The downstream QCA kernel uses the same table for ipq6018, ipq8074-gen3, > and ipq9574. It is named "ipq_pciephy_gen3_regs_layout". Thus, it made > sense to use the same upstream table for ipq9574, "pciephy_v4_regs_layout". > > As far as the register tables go, the pcs/pcs_misc are squashed into the > same table in the downstream 5.4 kernel. I was able to separate the two > tables because the pcs_misc registers were defined with an offset of > 0x400. For example: > > /* QMP V2 PHY for PCIE gen3 2 Lane ports - PCS Misc registers */ > #define PCS_PCIE_X2_POWER_STATE_CONFIG2 0x40c > #define PCS_PCIE_X2_POWER_STATE_CONFIG4 0x414 > #define PCS_PCIE_X2_ENDPOINT_REFCLK_DRIVE 0x420 > #define PCS_PCIE_X2_L1P1_WAKEUP_DLY_TIME_AUXCLK_L 0x444 > #define PCS_PCIE_X2_L1P1_WAKEUP_DLY_TIME_AUXCLK_H 0x448 > #define PCS_PCIE_X2_L1P2_WAKEUP_DLY_TIME_AUXCLK_L 0x44c > #define PCS_PCIE_X2_L1P2_WAKEUP_DLY_TIME_AUXCLK_H 0x450 > ... > > Here, QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG2 = 0xc would be correct, > assuming a pcs_misc offset of 0x400. However, starting with > ENDPOINT_REFCLK_DRIVE, the register would be > QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_DRIVE = 0x1c. Our offsets are off-by 0x4. > > The existing V5 offsets, on the other hand, were all correct. For this > reason, I considered that V5 is the most likely place to add the missing > PCS misc definitions. Ok, sounds sane. Please use _v5 for the regs layout. > > Is this explanation sufficiently convincing? Where does the v4/v5 scheme > in upstream kernel originate? Sometimes it's vendor kernels, sometimes it's a feedback from devs that have access to actual specs. -- With best wishes Dmitry
On Wed, Apr 17, 2024 at 12:50:49AM +0300, Dmitry Baryshkov wrote: > On Wed, 17 Apr 2024 at 00:25, Alex G. <mr.nuke.me@gmail.com> wrote: > > > > Hi Dmitry, > > > > On 4/15/24 16:25, mr.nuke.me@gmail.com wrote: > > > > > > > > > On 4/15/24 15:10, Dmitry Baryshkov wrote: > > >> On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> > > >> wrote: > > >>> > > >>> Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream > > >>> 5.4 kernel. Only the serdes and pcs_misc tables are new, the others > > >>> being reused from IPQ8074 and IPQ6018 PHYs. > > >>> > > >>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> > > >>> --- > > >>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- > > >>> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ > > >>> 2 files changed, 149 insertions(+), 1 deletion(-) > > >>> > > >> > > >> [skipped] > > >> > > >>> @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem > > >>> *base, u32 offset, u32 val) > > >>> > > >>> /* list of clocks required by phy */ > > >>> static const char * const qmp_pciephy_clk_l[] = { > > >>> - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > > >>> + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > > >>> "anoc", "snoc" > > >> > > >> Are the NoC clocks really necessary to drive the PHY? I think they are > > >> usually connected to the controllers, not the PHYs. > > > > > > The system will hang if these clocks are not enabled. They are also > > > attached to the PHY in the QCA 5.4 downstream kernel. > > Interesting. > I see that Varadarajan is converting these clocks into interconnects. > Maybe it's better to wait for those patches to land and use > interconnects instead. I think it would better suit the > infrastructure. > > Varadarajan, could you please comment, are these interconnects > connected to the PHY too or just to the PCIe controller? Sorry for the late response. Missed this e-mail. These 2 clks are related to AXI port clk on Aggnoc/SNOC, not directly connected to PCIE wrapper, but it should be enabled to generate pcie traffic. Thanks Varada > > They are named "anoc_lane", and "snoc_lane" in the downstream kernel. > > Would you like me to use these names instead? > > I'm fine either way. > > > e>>> }; > > >>> > > >>> /* list of regulators */ > > >>> @@ -2499,6 +2593,16 @@ static const struct qmp_pcie_offsets > > >>> qmp_pcie_offsets_v4x1 = { > > >>> .rx = 0x0400, > > >>> }; > > >>> > > >>> +static const struct qmp_pcie_offsets qmp_pcie_offsets_ipq9574 = { > > >>> + .serdes = 0, > > >>> + .pcs = 0x1000, > > >>> + .pcs_misc = 0x1400, > > >>> + .tx = 0x0200, > > >>> + .rx = 0x0400, > > >>> + .tx2 = 0x0600, > > >>> + .rx2 = 0x0800, > > >>> +}; > > >>> + > > >>> static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x2 = { > > >>> .serdes = 0, > > >>> .pcs = 0x0a00, > > >>> @@ -2728,6 +2832,33 @@ static const struct qmp_phy_cfg > > >>> sm8250_qmp_gen3x1_pciephy_cfg = { > > >>> .phy_status = PHYSTATUS, > > >>> }; > > >>> > > >>> +static const struct qmp_phy_cfg ipq9574_pciephy_gen3x2_cfg = { > > >>> + .lanes = 2, > > >>> + > > >>> + .offsets = &qmp_pcie_offsets_ipq9574, > > >>> + > > >>> + .tbls = { > > >>> + .serdes = ipq9574_gen3x2_pcie_serdes_tbl, > > >>> + .serdes_num = > > >>> ARRAY_SIZE(ipq9574_gen3x2_pcie_serdes_tbl), > > >>> + .tx = ipq8074_pcie_gen3_tx_tbl, > > >>> + .tx_num = ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl), > > >>> + .rx = ipq6018_pcie_rx_tbl, > > >>> + .rx_num = ARRAY_SIZE(ipq6018_pcie_rx_tbl), > > >>> + .pcs = ipq6018_pcie_pcs_tbl, > > >>> + .pcs_num = ARRAY_SIZE(ipq6018_pcie_pcs_tbl), > > >>> + .pcs_misc = ipq9574_gen3x2_pcie_pcs_misc_tbl, > > >>> + .pcs_misc_num = > > >>> ARRAY_SIZE(ipq9574_gen3x2_pcie_pcs_misc_tbl), > > >>> + }, > > >>> + .reset_list = ipq8074_pciephy_reset_l, > > >>> + .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l), > > >>> + .vreg_list = NULL, > > >>> + .num_vregs = 0, > > >>> + .regs = pciephy_v4_regs_layout, > > >> > > >> So, is it v4 or v5? > > > > > > Please give me a day or so to go over my notes and give you a more > > > coherent explanation of why this versioning was chosen. I am only > > > working from the QCA 5.4 downstream sources. I don't have any > > > documentation for the silicon > > > > The downstream QCA kernel uses the same table for ipq6018, ipq8074-gen3, > > and ipq9574. It is named "ipq_pciephy_gen3_regs_layout". Thus, it made > > sense to use the same upstream table for ipq9574, "pciephy_v4_regs_layout". > > > > As far as the register tables go, the pcs/pcs_misc are squashed into the > > same table in the downstream 5.4 kernel. I was able to separate the two > > tables because the pcs_misc registers were defined with an offset of > > 0x400. For example: > > > > /* QMP V2 PHY for PCIE gen3 2 Lane ports - PCS Misc registers */ > > #define PCS_PCIE_X2_POWER_STATE_CONFIG2 0x40c > > #define PCS_PCIE_X2_POWER_STATE_CONFIG4 0x414 > > #define PCS_PCIE_X2_ENDPOINT_REFCLK_DRIVE 0x420 > > #define PCS_PCIE_X2_L1P1_WAKEUP_DLY_TIME_AUXCLK_L 0x444 > > #define PCS_PCIE_X2_L1P1_WAKEUP_DLY_TIME_AUXCLK_H 0x448 > > #define PCS_PCIE_X2_L1P2_WAKEUP_DLY_TIME_AUXCLK_L 0x44c > > #define PCS_PCIE_X2_L1P2_WAKEUP_DLY_TIME_AUXCLK_H 0x450 > > ... > > > > Here, QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG2 = 0xc would be correct, > > assuming a pcs_misc offset of 0x400. However, starting with > > ENDPOINT_REFCLK_DRIVE, the register would be > > QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_DRIVE = 0x1c. Our offsets are off-by 0x4. > > > > The existing V5 offsets, on the other hand, were all correct. For this > > reason, I considered that V5 is the most likely place to add the missing > > PCS misc definitions. > > Ok, sounds sane. Please use _v5 for the regs layout. > > > > > Is this explanation sufficiently convincing? Where does the v4/v5 scheme > > in upstream kernel originate? > > Sometimes it's vendor kernels, sometimes it's a feedback from devs > that have access to actual specs. > > > -- > With best wishes > Dmitry
On Mon, 29 Apr 2024 at 09:20, Varadarajan Narayanan <quic_varada@quicinc.com> wrote: > > On Wed, Apr 17, 2024 at 12:50:49AM +0300, Dmitry Baryshkov wrote: > > On Wed, 17 Apr 2024 at 00:25, Alex G. <mr.nuke.me@gmail.com> wrote: > > > > > > Hi Dmitry, > > > > > > On 4/15/24 16:25, mr.nuke.me@gmail.com wrote: > > > > > > > > > > > > On 4/15/24 15:10, Dmitry Baryshkov wrote: > > > >> On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> > > > >> wrote: > > > >>> > > > >>> Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream > > > >>> 5.4 kernel. Only the serdes and pcs_misc tables are new, the others > > > >>> being reused from IPQ8074 and IPQ6018 PHYs. > > > >>> > > > >>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> > > > >>> --- > > > >>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- > > > >>> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ > > > >>> 2 files changed, 149 insertions(+), 1 deletion(-) > > > >>> > > > >> > > > >> [skipped] > > > >> > > > >>> @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem > > > >>> *base, u32 offset, u32 val) > > > >>> > > > >>> /* list of clocks required by phy */ > > > >>> static const char * const qmp_pciephy_clk_l[] = { > > > >>> - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > > > >>> + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > > > >>> "anoc", "snoc" > > > >> > > > >> Are the NoC clocks really necessary to drive the PHY? I think they are > > > >> usually connected to the controllers, not the PHYs. > > > > > > > > The system will hang if these clocks are not enabled. They are also > > > > attached to the PHY in the QCA 5.4 downstream kernel. > > > > Interesting. > > I see that Varadarajan is converting these clocks into interconnects. > > Maybe it's better to wait for those patches to land and use > > interconnects instead. I think it would better suit the > > infrastructure. > > > > Varadarajan, could you please comment, are these interconnects > > connected to the PHY too or just to the PCIe controller? > > Sorry for the late response. Missed this e-mail. > > These 2 clks are related to AXI port clk on Aggnoc/SNOC, not > directly connected to PCIE wrapper, but it should be enabled to > generate pcie traffic. So, are they required for the PHY or are they required for the PCIe controller only? > > Thanks > Varada > > > > They are named "anoc_lane", and "snoc_lane" in the downstream kernel. > > > Would you like me to use these names instead? > > > > I'm fine either way. > >
On Mon, Apr 29, 2024 at 01:55:32PM +0300, Dmitry Baryshkov wrote: > On Mon, 29 Apr 2024 at 09:20, Varadarajan Narayanan > <quic_varada@quicinc.com> wrote: > > > > On Wed, Apr 17, 2024 at 12:50:49AM +0300, Dmitry Baryshkov wrote: > > > On Wed, 17 Apr 2024 at 00:25, Alex G. <mr.nuke.me@gmail.com> wrote: > > > > > > > > Hi Dmitry, > > > > > > > > On 4/15/24 16:25, mr.nuke.me@gmail.com wrote: > > > > > > > > > > > > > > > On 4/15/24 15:10, Dmitry Baryshkov wrote: > > > > >> On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> > > > > >> wrote: > > > > >>> > > > > >>> Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream > > > > >>> 5.4 kernel. Only the serdes and pcs_misc tables are new, the others > > > > >>> being reused from IPQ8074 and IPQ6018 PHYs. > > > > >>> > > > > >>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> > > > > >>> --- > > > > >>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- > > > > >>> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ > > > > >>> 2 files changed, 149 insertions(+), 1 deletion(-) > > > > >>> > > > > >> > > > > >> [skipped] > > > > >> > > > > >>> @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem > > > > >>> *base, u32 offset, u32 val) > > > > >>> > > > > >>> /* list of clocks required by phy */ > > > > >>> static const char * const qmp_pciephy_clk_l[] = { > > > > >>> - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > > > > >>> + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > > > > >>> "anoc", "snoc" > > > > >> > > > > >> Are the NoC clocks really necessary to drive the PHY? I think they are > > > > >> usually connected to the controllers, not the PHYs. > > > > > > > > > > The system will hang if these clocks are not enabled. They are also > > > > > attached to the PHY in the QCA 5.4 downstream kernel. > > > > > > Interesting. > > > I see that Varadarajan is converting these clocks into interconnects. > > > Maybe it's better to wait for those patches to land and use > > > interconnects instead. I think it would better suit the > > > infrastructure. > > > > > > Varadarajan, could you please comment, are these interconnects > > > connected to the PHY too or just to the PCIe controller? > > > > Sorry for the late response. Missed this e-mail. > > > > These 2 clks are related to AXI port clk on Aggnoc/SNOC, not > > directly connected to PCIE wrapper, but it should be enabled to > > generate pcie traffic. > > So, are they required for the PHY or are they required for the PCIe > controller only? These 2 clks are required for PCIe controller only. PCIE controller need these clks to send/receive axi pkts. Thanks Varada > > > > They are named "anoc_lane", and "snoc_lane" in the downstream kernel. > > > > Would you like me to use these names instead? > > > > > > I'm fine either way. > > > > > > > -- > With best wishes > Dmitry
On 4/30/24 1:31 AM, Varadarajan Narayanan wrote: > On Mon, Apr 29, 2024 at 01:55:32PM +0300, Dmitry Baryshkov wrote: >> On Mon, 29 Apr 2024 at 09:20, Varadarajan Narayanan >> <quic_varada@quicinc.com> wrote: >>> >>> On Wed, Apr 17, 2024 at 12:50:49AM +0300, Dmitry Baryshkov wrote: >>>> On Wed, 17 Apr 2024 at 00:25, Alex G. <mr.nuke.me@gmail.com> wrote: >>>>> >>>>> Hi Dmitry, >>>>> >>>>> On 4/15/24 16:25, mr.nuke.me@gmail.com wrote: >>>>>> >>>>>> >>>>>> On 4/15/24 15:10, Dmitry Baryshkov wrote: >>>>>>> On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream >>>>>>>> 5.4 kernel. Only the serdes and pcs_misc tables are new, the others >>>>>>>> being reused from IPQ8074 and IPQ6018 PHYs. >>>>>>>> >>>>>>>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> >>>>>>>> --- >>>>>>>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- >>>>>>>> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ >>>>>>>> 2 files changed, 149 insertions(+), 1 deletion(-) >>>>>>>> >>>>>>> >>>>>>> [skipped] >>>>>>> >>>>>>>> @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem >>>>>>>> *base, u32 offset, u32 val) >>>>>>>> >>>>>>>> /* list of clocks required by phy */ >>>>>>>> static const char * const qmp_pciephy_clk_l[] = { >>>>>>>> - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", >>>>>>>> + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", >>>>>>>> "anoc", "snoc" >>>>>>> >>>>>>> Are the NoC clocks really necessary to drive the PHY? I think they are >>>>>>> usually connected to the controllers, not the PHYs. >>>>>> >>>>>> The system will hang if these clocks are not enabled. They are also >>>>>> attached to the PHY in the QCA 5.4 downstream kernel. >>>> >>>> Interesting. >>>> I see that Varadarajan is converting these clocks into interconnects. >>>> Maybe it's better to wait for those patches to land and use >>>> interconnects instead. I think it would better suit the >>>> infrastructure. >>>> >>>> Varadarajan, could you please comment, are these interconnects >>>> connected to the PHY too or just to the PCIe controller? >>> >>> Sorry for the late response. Missed this e-mail. >>> >>> These 2 clks are related to AXI port clk on Aggnoc/SNOC, not >>> directly connected to PCIE wrapper, but it should be enabled to >>> generate pcie traffic. >> >> So, are they required for the PHY or are they required for the PCIe >> controller only? > > These 2 clks are required for PCIe controller only. > PCIE controller need these clks to send/receive axi pkts. Very interesting information, thank you! Dmitry, In light of this information do you want me to move these clocks out of the PHY and into the PCIe controller? Alex > Thanks > Varada > >>>>> They are named "anoc_lane", and "snoc_lane" in the downstream kernel. >>>>> Would you like me to use these names instead? >>>> >>>> I'm fine either way. >>>> >> >> >> >> -- >> With best wishes >> Dmitry
On Wed, 1 May 2024 at 00:51, <mr.nuke.me@gmail.com> wrote: > > On 4/30/24 1:31 AM, Varadarajan Narayanan wrote: > > On Mon, Apr 29, 2024 at 01:55:32PM +0300, Dmitry Baryshkov wrote: > >> On Mon, 29 Apr 2024 at 09:20, Varadarajan Narayanan > >> <quic_varada@quicinc.com> wrote: > >>> > >>> On Wed, Apr 17, 2024 at 12:50:49AM +0300, Dmitry Baryshkov wrote: > >>>> On Wed, 17 Apr 2024 at 00:25, Alex G. <mr.nuke.me@gmail.com> wrote: > >>>>> > >>>>> Hi Dmitry, > >>>>> > >>>>> On 4/15/24 16:25, mr.nuke.me@gmail.com wrote: > >>>>>> > >>>>>> > >>>>>> On 4/15/24 15:10, Dmitry Baryshkov wrote: > >>>>>>> On Mon, 15 Apr 2024 at 21:23, Alexandru Gagniuc <mr.nuke.me@gmail.com> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream > >>>>>>>> 5.4 kernel. Only the serdes and pcs_misc tables are new, the others > >>>>>>>> being reused from IPQ8074 and IPQ6018 PHYs. > >>>>>>>> > >>>>>>>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> > >>>>>>>> --- > >>>>>>>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- > >>>>>>>> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ > >>>>>>>> 2 files changed, 149 insertions(+), 1 deletion(-) > >>>>>>>> > >>>>>>> > >>>>>>> [skipped] > >>>>>>> > >>>>>>>> @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem > >>>>>>>> *base, u32 offset, u32 val) > >>>>>>>> > >>>>>>>> /* list of clocks required by phy */ > >>>>>>>> static const char * const qmp_pciephy_clk_l[] = { > >>>>>>>> - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > >>>>>>>> + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", > >>>>>>>> "anoc", "snoc" > >>>>>>> > >>>>>>> Are the NoC clocks really necessary to drive the PHY? I think they are > >>>>>>> usually connected to the controllers, not the PHYs. > >>>>>> > >>>>>> The system will hang if these clocks are not enabled. They are also > >>>>>> attached to the PHY in the QCA 5.4 downstream kernel. > >>>> > >>>> Interesting. > >>>> I see that Varadarajan is converting these clocks into interconnects. > >>>> Maybe it's better to wait for those patches to land and use > >>>> interconnects instead. I think it would better suit the > >>>> infrastructure. > >>>> > >>>> Varadarajan, could you please comment, are these interconnects > >>>> connected to the PHY too or just to the PCIe controller? > >>> > >>> Sorry for the late response. Missed this e-mail. > >>> > >>> These 2 clks are related to AXI port clk on Aggnoc/SNOC, not > >>> directly connected to PCIE wrapper, but it should be enabled to > >>> generate pcie traffic. > >> > >> So, are they required for the PHY or are they required for the PCIe > >> controller only? > > > > These 2 clks are required for PCIe controller only. > > PCIE controller need these clks to send/receive axi pkts. > > Very interesting information, thank you! > > Dmitry, In light of this information do you want me to move these clocks > out of the PHY and into the PCIe controller? That's what I was thinking about. > > Alex > > > Thanks > > Varada > > > >>>>> They are named "anoc_lane", and "snoc_lane" in the downstream kernel. > >>>>> Would you like me to use these names instead? > >>>> > >>>> I'm fine either way. > >>>> > >> > >> > >> > >> -- > >> With best wishes > >> Dmitry
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c index 8836bb1ff0cc..a4a79ddf50a5 100644 --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c @@ -487,6 +487,100 @@ static const struct qmp_phy_init_tbl ipq8074_pcie_gen3_pcs_misc_tbl[] = { QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_DRIVE, 0xc1), }; +static const struct qmp_phy_init_tbl ipq9574_gen3x2_pcie_serdes_tbl[] = { + QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CLKBUFLR_EN, 0x18), + QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CTRL_BY_PSM, 0x01), + QMP_PHY_INIT_CFG(QSERDES_PLL_CLK_SELECT, 0x31), + QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_IVCO, 0x0f), + QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TRIM, 0x0f), + QMP_PHY_INIT_CFG(QSERDES_PLL_CMN_CONFIG, 0x06), + QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP_EN, 0x42), + QMP_PHY_INIT_CFG(QSERDES_PLL_RESETSM_CNTRL, 0x20), + QMP_PHY_INIT_CFG(QSERDES_PLL_SVS_MODE_CLK_SEL, 0x01), + QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE_MAP, 0x04), + QMP_PHY_INIT_CFG(QSERDES_PLL_SVS_MODE_CLK_SEL, 0x05), + QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE_TIMER1, 0xff), + QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE_TIMER2, 0x3f), + QMP_PHY_INIT_CFG(QSERDES_PLL_CORE_CLK_EN, 0x30), + QMP_PHY_INIT_CFG(QSERDES_PLL_HSCLK_SEL, 0x21), + QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE0, 0x68), + QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START3_MODE0, 0x02), + QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START2_MODE0, 0xaa), + QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START1_MODE0, 0xab), + QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE0, 0x14), + QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE0, 0xd4), + QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE0, 0x09), + QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE0, 0x16), + QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE0, 0x28), + QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN1_MODE0, 0x00), + QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE0, 0xa0), + QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE0, 0x02), + QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE0, 0x24), + QMP_PHY_INIT_CFG(QSERDES_PLL_SVS_MODE_CLK_SEL, 0x05), + QMP_PHY_INIT_CFG(QSERDES_PLL_CORE_CLK_EN, 0x00), + QMP_PHY_INIT_CFG(QSERDES_PLL_CORECLK_DIV, 0x0a), + QMP_PHY_INIT_CFG(QSERDES_PLL_CLK_SELECT, 0x32), + QMP_PHY_INIT_CFG(QSERDES_PLL_SYS_CLK_CTRL, 0x02), + QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_BUF_ENABLE, 0x07), + QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_EN_SEL, 0x08), + QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TIMER, 0x0a), + QMP_PHY_INIT_CFG(QSERDES_PLL_HSCLK_SEL, 0x01), + QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE1, 0x53), + QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START3_MODE1, 0x05), + QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START2_MODE1, 0x55), + QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START1_MODE1, 0x55), + QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE1, 0x29), + QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE1, 0xaa), + QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE1, 0x09), + QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE1, 0x16), + QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE1, 0x28), + QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN1_MODE1, 0x00), + QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE1, 0xa0), + QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE1, 0x03), + QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE1, 0xb4), + QMP_PHY_INIT_CFG(QSERDES_PLL_SVS_MODE_CLK_SEL, 0x05), + QMP_PHY_INIT_CFG(QSERDES_PLL_CORE_CLK_EN, 0x00), + QMP_PHY_INIT_CFG(QSERDES_PLL_CORECLK_DIV_MODE1, 0x08), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_EN_CENTER, 0x01), + QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_PER1, 0x7d), + QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_PER2, 0x01), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_ADJ_PER1, 0x00), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_ADJ_PER2, 0x00), + QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_STEP_SIZE1_MODE0, 0x0a), + QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_STEP_SIZE2_MODE0, 0x05), + QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_STEP_SIZE1_MODE1, 0x08), + QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_STEP_SIZE2_MODE1, 0x04), + QMP_PHY_INIT_CFG(QSERDES_PLL_CLK_EP_DIV_MODE0, 0x19), + QMP_PHY_INIT_CFG(QSERDES_PLL_CLK_EP_DIV_MODE1, 0x28), + QMP_PHY_INIT_CFG(QSERDES_PLL_CLK_ENABLE1, 0x90), + QMP_PHY_INIT_CFG(QSERDES_PLL_HSCLK_SEL, 0x89), + QMP_PHY_INIT_CFG(QSERDES_PLL_CLK_ENABLE1, 0x10), +}; + +static const struct qmp_phy_init_tbl ipq9574_gen3x2_pcie_pcs_misc_tbl[] = { + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_OSC_DTCT_ACTIONS, 0x00), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_POWER_STATE_CONFIG2, 0x1d), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_H, 0x00), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_L, 0x01), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_H, 0x00), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_L, 0x01), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_EQ_CONFIG1, 0x14), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_EQ_CONFIG1, 0x10), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_EQ_CONFIG2, 0x0b), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_PRESET_P10_PRE, 0x00), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_PRESET_P10_POST, 0x58), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_POWER_STATE_CONFIG4, 0x07), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_OSC_DTCT_CONFIG1, 0x00), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_OSC_DTCT_CONFIG2, 0x52), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_OSC_DTCT_CONFIG4, 0x19), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_INT_AUX_CLK_CONFIG1, 0x00), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_OSC_DTCT_MODE2_CONFIG2, 0x49), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_OSC_DTCT_MODE2_CONFIG4, 0x2a), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_OSC_DTCT_MODE2_CONFIG5, 0x02), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_OSC_DTCT_MODE2_CONFIG6, 0x03), + QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_ENDPOINT_REFCLK_DRIVE, 0xc1), +}; + static const struct qmp_phy_init_tbl sdm845_qmp_pcie_serdes_tbl[] = { QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x14), QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30), @@ -2448,7 +2542,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val) /* list of clocks required by phy */ static const char * const qmp_pciephy_clk_l[] = { - "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", + "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", "anoc", "snoc" }; /* list of regulators */ @@ -2499,6 +2593,16 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x1 = { .rx = 0x0400, }; +static const struct qmp_pcie_offsets qmp_pcie_offsets_ipq9574 = { + .serdes = 0, + .pcs = 0x1000, + .pcs_misc = 0x1400, + .tx = 0x0200, + .rx = 0x0400, + .tx2 = 0x0600, + .rx2 = 0x0800, +}; + static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x2 = { .serdes = 0, .pcs = 0x0a00, @@ -2728,6 +2832,33 @@ static const struct qmp_phy_cfg sm8250_qmp_gen3x1_pciephy_cfg = { .phy_status = PHYSTATUS, }; +static const struct qmp_phy_cfg ipq9574_pciephy_gen3x2_cfg = { + .lanes = 2, + + .offsets = &qmp_pcie_offsets_ipq9574, + + .tbls = { + .serdes = ipq9574_gen3x2_pcie_serdes_tbl, + .serdes_num = ARRAY_SIZE(ipq9574_gen3x2_pcie_serdes_tbl), + .tx = ipq8074_pcie_gen3_tx_tbl, + .tx_num = ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl), + .rx = ipq6018_pcie_rx_tbl, + .rx_num = ARRAY_SIZE(ipq6018_pcie_rx_tbl), + .pcs = ipq6018_pcie_pcs_tbl, + .pcs_num = ARRAY_SIZE(ipq6018_pcie_pcs_tbl), + .pcs_misc = ipq9574_gen3x2_pcie_pcs_misc_tbl, + .pcs_misc_num = ARRAY_SIZE(ipq9574_gen3x2_pcie_pcs_misc_tbl), + }, + .reset_list = ipq8074_pciephy_reset_l, + .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l), + .vreg_list = NULL, + .num_vregs = 0, + .regs = pciephy_v4_regs_layout, + + .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, + .phy_status = PHYSTATUS, +}; + static const struct qmp_phy_cfg sm8250_qmp_gen3x2_pciephy_cfg = { .lanes = 2, @@ -3935,6 +4066,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = { }, { .compatible = "qcom,ipq8074-qmp-pcie-phy", .data = &ipq8074_pciephy_cfg, + }, { + .compatible = "qcom,ipq9574-qmp-gen3x2-pcie-phy", + .data = &ipq9574_pciephy_gen3x2_cfg, }, { .compatible = "qcom,msm8998-qmp-pcie-phy", .data = &msm8998_pciephy_cfg, diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h index a469ae2a10a1..fa15a03055de 100644 --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h @@ -11,8 +11,22 @@ #define QPHY_V5_PCS_PCIE_POWER_STATE_CONFIG2 0x0c #define QPHY_V5_PCS_PCIE_POWER_STATE_CONFIG4 0x14 #define QPHY_V5_PCS_PCIE_ENDPOINT_REFCLK_DRIVE 0x20 +#define QPHY_V5_PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_L 0x44 +#define QPHY_V5_PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_H 0x48 +#define QPHY_V5_PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_L 0x4c +#define QPHY_V5_PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_H 0x50 #define QPHY_V5_PCS_PCIE_INT_AUX_CLK_CONFIG1 0x54 +#define QPHY_V5_PCS_PCIE_OSC_DTCT_CONFIG1 0x5c +#define QPHY_V5_PCS_PCIE_OSC_DTCT_CONFIG2 0x60 +#define QPHY_V5_PCS_PCIE_OSC_DTCT_CONFIG4 0x68 +#define QPHY_V5_PCS_PCIE_OSC_DTCT_MODE2_CONFIG2 0x7c +#define QPHY_V5_PCS_PCIE_OSC_DTCT_MODE2_CONFIG4 0x84 +#define QPHY_V5_PCS_PCIE_OSC_DTCT_MODE2_CONFIG5 0x88 +#define QPHY_V5_PCS_PCIE_OSC_DTCT_MODE2_CONFIG6 0x8c #define QPHY_V5_PCS_PCIE_OSC_DTCT_ACTIONS 0x94 +#define QPHY_V5_PCS_PCIE_EQ_CONFIG1 0xa4 #define QPHY_V5_PCS_PCIE_EQ_CONFIG2 0xa8 +#define QPHY_V5_PCS_PCIE_PRESET_P10_PRE 0xc0 +#define QPHY_V5_PCS_PCIE_PRESET_P10_POST 0xe4 #endif
Add support for the gen3x2 PCIe PHY on IPQ9574, ported form downstream 5.4 kernel. Only the serdes and pcs_misc tables are new, the others being reused from IPQ8074 and IPQ6018 PHYs. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> --- drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 136 +++++++++++++++++- .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 14 ++ 2 files changed, 149 insertions(+), 1 deletion(-)