From: Qiang Yu <quic_qianyu@quicinc.com>
All PCIe PHYs on the X1E80100 SOC require the vdda-qref, which feeds QREF
clocks provided by the TCSR device.
Hence, restore the vdda-qref request for the 6th PCIe instance by reverting
commit 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100 qref
supplies"). For the 4th PCIe instance (Gen3 x2), add a new driver data
entry, namely x1e80100_qmp_gen3x2_pciephy_cfg, which is a copy of
sm8550_qmp_gen3x2_pciephy_cfg but uses sm8550_qmp_phy_vreg_l instead.
Fixes: 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100 qref supplies")
Fixes: 606060ce8fd0 ("phy: qcom-qmp-pcie: Add support for X1E80100 g3x2 and g4x2 PCIE")
Cc: Johan Hovold <johan+linaro@kernel.org>
Cc: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 37 ++++++++++++++++++++----
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index ab90aafb3..c3c725744 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -4142,6 +4142,33 @@ static const struct qmp_phy_cfg sa8775p_qmp_gen4x4_pciephy_cfg = {
.phy_status = PHYSTATUS_4_20,
};
+static const struct qmp_phy_cfg x1e80100_qmp_gen3x2_pciephy_cfg = {
+ .lanes = 2,
+
+ .offsets = &qmp_pcie_offsets_v5,
+
+ .tbls = {
+ .serdes = sm8550_qmp_gen3x2_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_serdes_tbl),
+ .tx = sm8550_qmp_gen3x2_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_tx_tbl),
+ .rx = sm8550_qmp_gen3x2_pcie_rx_tbl,
+ .rx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_rx_tbl),
+ .pcs = sm8550_qmp_gen3x2_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_tbl),
+ .pcs_misc = sm8550_qmp_gen3x2_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_misc_tbl),
+ },
+ .reset_list = sdm845_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .vreg_list = sm8550_qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
+ .regs = pciephy_v5_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS,
+};
+
static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
.lanes = 2,
@@ -4164,8 +4191,8 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
- .vreg_list = qmp_phy_vreg_l,
- .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .vreg_list = sm8550_qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
.pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
@@ -4197,8 +4224,8 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x4_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
- .vreg_list = qmp_phy_vreg_l,
- .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .vreg_list = sm8550_qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
.pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
@@ -5094,7 +5121,7 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
.data = &sm8650_qmp_gen4x2_pciephy_cfg,
}, {
.compatible = "qcom,x1e80100-qmp-gen3x2-pcie-phy",
- .data = &sm8550_qmp_gen3x2_pciephy_cfg,
+ .data = &x1e80100_qmp_gen3x2_pciephy_cfg,
}, {
.compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy",
.data = &x1e80100_qmp_gen4x2_pciephy_cfg,
--
2.34.1On Thu, May 08, 2025 at 04:15:14PM +0800, Wenbin Yao wrote:
> From: Qiang Yu <quic_qianyu@quicinc.com>
>
> All PCIe PHYs on the X1E80100 SOC require the vdda-qref, which feeds QREF
> clocks provided by the TCSR device.
This still looks wrong and you never replied to why these supplies
shouldn't be handled by the tcsr clock driver that supplies these
clocks:
https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/
> Hence, restore the vdda-qref request for the 6th PCIe instance by reverting
> commit 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100 qref
> supplies"). For the 4th PCIe instance (Gen3 x2), add a new driver data
> entry, namely x1e80100_qmp_gen3x2_pciephy_cfg, which is a copy of
> sm8550_qmp_gen3x2_pciephy_cfg but uses sm8550_qmp_phy_vreg_l instead.
>
> Fixes: 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100 qref supplies")
> Fixes: 606060ce8fd0 ("phy: qcom-qmp-pcie: Add support for X1E80100 g3x2 and g4x2 PCIE")
> Cc: Johan Hovold <johan+linaro@kernel.org>
> Cc: Abel Vesa <abel.vesa@linaro.org>
> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com>
Johan
On 5/8/2025 4:20 PM, Johan Hovold wrote:
> On Thu, May 08, 2025 at 04:15:14PM +0800, Wenbin Yao wrote:
>> From: Qiang Yu <quic_qianyu@quicinc.com>
>>
>> All PCIe PHYs on the X1E80100 SOC require the vdda-qref, which feeds QREF
>> clocks provided by the TCSR device.
> This still looks wrong and you never replied to why these supplies
> shouldn't be handled by the tcsr clock driver that supplies these
> clocks:
>
> https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/
Sorry, I thought Konrad had convinced you.
If the TCSR driver manages these supplies, would it be possible for tscr
driver to recognize when it needs to turn vdda-qref on or off for a
specific PCIe port?
>
>> Hence, restore the vdda-qref request for the 6th PCIe instance by reverting
>> commit 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100 qref
>> supplies"). For the 4th PCIe instance (Gen3 x2), add a new driver data
>> entry, namely x1e80100_qmp_gen3x2_pciephy_cfg, which is a copy of
>> sm8550_qmp_gen3x2_pciephy_cfg but uses sm8550_qmp_phy_vreg_l instead.
>>
>> Fixes: 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100 qref supplies")
>> Fixes: 606060ce8fd0 ("phy: qcom-qmp-pcie: Add support for X1E80100 g3x2 and g4x2 PCIE")
>> Cc: Johan Hovold <johan+linaro@kernel.org>
>> Cc: Abel Vesa <abel.vesa@linaro.org>
>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
>> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com>
> Johan
--
With best wishes
Qiang Yu
On Thu, May 08, 2025 at 04:50:30PM +0800, Qiang Yu wrote: > > On 5/8/2025 4:20 PM, Johan Hovold wrote: > > On Thu, May 08, 2025 at 04:15:14PM +0800, Wenbin Yao wrote: > >> From: Qiang Yu <quic_qianyu@quicinc.com> > >> > >> All PCIe PHYs on the X1E80100 SOC require the vdda-qref, which feeds QREF > >> clocks provided by the TCSR device. > > This still looks wrong and you never replied to why these supplies > > shouldn't be handled by the tcsr clock driver that supplies these > > clocks: > > > > https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/ > Sorry, I thought Konrad had convinced you. IIRC, he just said you guys were told to add the QREF supply to the PHY. That's not an argument. > If the TCSR driver manages these supplies, would it be possible for tscr > driver to recognize when it needs to turn vdda-qref on or off for a > specific PCIe port? Sure, just add a lookup table to the driver and enable the required supplies when a ref clock is enabled. As I mentioned in the other thread, the T14s has the following QREF supplies: VDD_A_QREFS_1P2_A VDD_A_QREFS_1P2_B VDD_A_QREFS_0P875_A VDD_A_QREFS_0P875_B VDD_A_QREFS_0P875_0 VDD_A_QREFS_0P875_2 VDD_A_QREFS_0P875_3 and it's not clear how these maps to the various consumer ref clocks, including the PCIe ones: #define TCSR_PCIE_2L_4_CLKREF_EN #define TCSR_PCIE_2L_5_CLKREF_EN #define TCSR_PCIE_8L_CLKREF_EN #define TCSR_PCIE_4L_CLKREF_EN That mapping can be done by the TCSR clock driver (which would also take care of the 1.2 V supplies). Johan
On 5/8/25 11:45 AM, Johan Hovold wrote: > On Thu, May 08, 2025 at 04:50:30PM +0800, Qiang Yu wrote: >> >> On 5/8/2025 4:20 PM, Johan Hovold wrote: >>> On Thu, May 08, 2025 at 04:15:14PM +0800, Wenbin Yao wrote: >>>> From: Qiang Yu <quic_qianyu@quicinc.com> >>>> >>>> All PCIe PHYs on the X1E80100 SOC require the vdda-qref, which feeds QREF >>>> clocks provided by the TCSR device. >>> This still looks wrong and you never replied to why these supplies >>> shouldn't be handled by the tcsr clock driver that supplies these >>> clocks: >>> >>> https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/ > >> Sorry, I thought Konrad had convinced you. > > IIRC, he just said you guys were told to add the QREF supply to the PHY. > That's not an argument. > >> If the TCSR driver manages these supplies, would it be possible for tscr >> driver to recognize when it needs to turn vdda-qref on or off for a >> specific PCIe port? > > Sure, just add a lookup table to the driver and enable the required > supplies when a ref clock is enabled. > > As I mentioned in the other thread, the T14s has the following QREF > supplies: > > > VDD_A_QREFS_1P2_A > VDD_A_QREFS_1P2_B > > VDD_A_QREFS_0P875_A > VDD_A_QREFS_0P875_B > VDD_A_QREFS_0P875_0 > VDD_A_QREFS_0P875_2 > VDD_A_QREFS_0P875_3 > > and it's not clear how these maps to the various consumer ref clocks, > including the PCIe ones: > > #define TCSR_PCIE_2L_4_CLKREF_EN > #define TCSR_PCIE_2L_5_CLKREF_EN > #define TCSR_PCIE_8L_CLKREF_EN > #define TCSR_PCIE_4L_CLKREF_EN > > That mapping can be done by the TCSR clock driver (which would also take > care of the 1.2 V supplies). So we had an internal discussion about this and while it may work, it would only do so for some SoCs, and maybe only on the surface, as the wiring behind it is rather peculiar.. Plus, not all QREF consumers have a clock expressed in TCSR as of right now. Konrad
On Thu, May 22, 2025 at 10:03:18PM +0200, Konrad Dybcio wrote: > On 5/8/25 11:45 AM, Johan Hovold wrote: > > On Thu, May 08, 2025 at 04:50:30PM +0800, Qiang Yu wrote: > >> On 5/8/2025 4:20 PM, Johan Hovold wrote: > >>> This still looks wrong and you never replied to why these supplies > >>> shouldn't be handled by the tcsr clock driver that supplies these > >>> clocks: > >>> > >>> https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/ > > > >> Sorry, I thought Konrad had convinced you. > > > > IIRC, he just said you guys were told to add the QREF supply to the PHY. > > That's not an argument. > > > >> If the TCSR driver manages these supplies, would it be possible for tscr > >> driver to recognize when it needs to turn vdda-qref on or off for a > >> specific PCIe port? > > > > Sure, just add a lookup table to the driver and enable the required > > supplies when a ref clock is enabled. > > > > As I mentioned in the other thread, the T14s has the following QREF > > supplies: > > > > > > VDD_A_QREFS_1P2_A > > VDD_A_QREFS_1P2_B > > > > VDD_A_QREFS_0P875_A > > VDD_A_QREFS_0P875_B > > VDD_A_QREFS_0P875_0 > > VDD_A_QREFS_0P875_2 > > VDD_A_QREFS_0P875_3 > > > > and it's not clear how these maps to the various consumer ref clocks, > > including the PCIe ones: > > > > #define TCSR_PCIE_2L_4_CLKREF_EN > > #define TCSR_PCIE_2L_5_CLKREF_EN > > #define TCSR_PCIE_8L_CLKREF_EN > > #define TCSR_PCIE_4L_CLKREF_EN > > > > That mapping can be done by the TCSR clock driver (which would also take > > care of the 1.2 V supplies). > > So we had an internal discussion about this and while it may work, it > would only do so for some SoCs, and maybe only on the surface, as the > wiring behind it is rather peculiar.. Care to expand on why it cannot be made to work generally? Also, what would the mapping of the above QREF supplies to PCIe PHYs even look like? > Plus, not all QREF consumers have a clock expressed in TCSR as of > right now. Is that because there is no corresponding bit in the TCSR or simply because it has not been described yet? Johan
On 5/26/25 3:47 PM, Johan Hovold wrote: > On Thu, May 22, 2025 at 10:03:18PM +0200, Konrad Dybcio wrote: >> On 5/8/25 11:45 AM, Johan Hovold wrote: >>> On Thu, May 08, 2025 at 04:50:30PM +0800, Qiang Yu wrote: >>>> On 5/8/2025 4:20 PM, Johan Hovold wrote: > >>>>> This still looks wrong and you never replied to why these supplies >>>>> shouldn't be handled by the tcsr clock driver that supplies these >>>>> clocks: >>>>> >>>>> https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/ >>> >>>> Sorry, I thought Konrad had convinced you. >>> >>> IIRC, he just said you guys were told to add the QREF supply to the PHY. >>> That's not an argument. >>> >>>> If the TCSR driver manages these supplies, would it be possible for tscr >>>> driver to recognize when it needs to turn vdda-qref on or off for a >>>> specific PCIe port? >>> >>> Sure, just add a lookup table to the driver and enable the required >>> supplies when a ref clock is enabled. >>> >>> As I mentioned in the other thread, the T14s has the following QREF >>> supplies: >>> >>> >>> VDD_A_QREFS_1P2_A >>> VDD_A_QREFS_1P2_B >>> >>> VDD_A_QREFS_0P875_A >>> VDD_A_QREFS_0P875_B >>> VDD_A_QREFS_0P875_0 >>> VDD_A_QREFS_0P875_2 >>> VDD_A_QREFS_0P875_3 >>> >>> and it's not clear how these maps to the various consumer ref clocks, >>> including the PCIe ones: >>> >>> #define TCSR_PCIE_2L_4_CLKREF_EN >>> #define TCSR_PCIE_2L_5_CLKREF_EN >>> #define TCSR_PCIE_8L_CLKREF_EN >>> #define TCSR_PCIE_4L_CLKREF_EN >>> >>> That mapping can be done by the TCSR clock driver (which would also take >>> care of the 1.2 V supplies). >> >> So we had an internal discussion about this and while it may work, it >> would only do so for some SoCs, and maybe only on the surface, as the >> wiring behind it is rather peculiar.. > > Care to expand on why it cannot be made to work generally? "-ENODATA".. many connections are difficult to unambiguously decipher > > Also, what would the mapping of the above QREF supplies to PCIe PHYs > even look like? I'm not sure I have a clear answer.. > >> Plus, not all QREF consumers have a clock expressed in TCSR as of >> right now. > > Is that because there is no corresponding bit in the TCSR or simply > because it has not been described yet? Unfortunately, the former.. Some IPs have a non-TCSR ref clock and some are presumably implicitly fed by BI_TCXO Konrad
On Tue, May 27, 2025 at 12:50:21PM +0200, Konrad Dybcio wrote: > On 5/26/25 3:47 PM, Johan Hovold wrote: > > On Thu, May 22, 2025 at 10:03:18PM +0200, Konrad Dybcio wrote: > >> On 5/8/25 11:45 AM, Johan Hovold wrote: > >>> On Thu, May 08, 2025 at 04:50:30PM +0800, Qiang Yu wrote: > >>>> On 5/8/2025 4:20 PM, Johan Hovold wrote: > > > >>>>> This still looks wrong and you never replied to why these supplies > >>>>> shouldn't be handled by the tcsr clock driver that supplies these > >>>>> clocks: > >>>>> > >>>>> https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/ > >>> > >>>> Sorry, I thought Konrad had convinced you. > >>> > >>> IIRC, he just said you guys were told to add the QREF supply to the PHY. > >>> That's not an argument. > >>> > >>>> If the TCSR driver manages these supplies, would it be possible for tscr > >>>> driver to recognize when it needs to turn vdda-qref on or off for a > >>>> specific PCIe port? > >>> > >>> Sure, just add a lookup table to the driver and enable the required > >>> supplies when a ref clock is enabled. > >>> > >>> As I mentioned in the other thread, the T14s has the following QREF > >>> supplies: > >>> > >>> > >>> VDD_A_QREFS_1P2_A > >>> VDD_A_QREFS_1P2_B > >>> > >>> VDD_A_QREFS_0P875_A > >>> VDD_A_QREFS_0P875_B > >>> VDD_A_QREFS_0P875_0 > >>> VDD_A_QREFS_0P875_2 > >>> VDD_A_QREFS_0P875_3 > >>> > >>> and it's not clear how these maps to the various consumer ref clocks, > >>> including the PCIe ones: > >>> > >>> #define TCSR_PCIE_2L_4_CLKREF_EN > >>> #define TCSR_PCIE_2L_5_CLKREF_EN > >>> #define TCSR_PCIE_8L_CLKREF_EN > >>> #define TCSR_PCIE_4L_CLKREF_EN > >>> > >>> That mapping can be done by the TCSR clock driver (which would also take > >>> care of the 1.2 V supplies). > >> > >> So we had an internal discussion about this and while it may work, it > >> would only do so for some SoCs, and maybe only on the surface, as the > >> wiring behind it is rather peculiar.. > > > > Care to expand on why it cannot be made to work generally? > > "-ENODATA".. many connections are difficult to unambiguously decipher > > > > > Also, what would the mapping of the above QREF supplies to PCIe PHYs > > even look like? > > I'm not sure I have a clear answer.. How would anyone know how to use a binding like this if you guys with access to internal docs can't even answer how the QREF supplies maps to the PHYs for a given SoC? > >> Plus, not all QREF consumers have a clock expressed in TCSR as of > >> right now. > > > > Is that because there is no corresponding bit in the TCSR or simply > > because it has not been described yet? > > Unfortunately, the former.. Some IPs have a non-TCSR ref clock and > some are presumably implicitly fed by BI_TCXO I think you need to provide a lot more detail here so we can determine how best best to proceed. We shouldn't accept made up PHY supplies without a proper motivation just because that's how it's done downstream. Johan
© 2016 - 2025 Red Hat, Inc.