diff mbox series

[v2,4/4] arm64: dts: qcom: x1e80100-qcp: Add qref supply for PCIe PHYs

Message ID 20250425092955.4099677-5-quic_wenbyao@quicinc.com
State Superseded
Headers show
Series arm64: qcom: x1e80100-qcp: Add power supply and sideband signals for PCIe RC | expand

Commit Message

Wenbin Yao April 25, 2025, 9:29 a.m. UTC
From: Qiang Yu <quic_qianyu@quicinc.com>

All PCIe PHYs on X1E80100 require vdda-qref power supplies, but this is
missing in the current PHY device tree node. The PCIe port can still
function because the regulator L3J, which vdda-qref consumes, is voted by
other components.

Since the device tree should accurately describe the hardware, add the
vdda-qref power supply explicitly in all PCIe PHY device nodes.

Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com>
---
 arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 3 +++
 1 file changed, 3 insertions(+)

Comments

Johan Hovold April 25, 2025, 12:02 p.m. UTC | #1
On Fri, Apr 25, 2025 at 12:03:06PM +0200, Konrad Dybcio wrote:
> On 4/25/25 11:51 AM, Johan Hovold wrote:
> > On Fri, Apr 25, 2025 at 05:29:55PM +0800, Wenbin Yao wrote:
> >> From: Qiang Yu <quic_qianyu@quicinc.com>
> >>
> >> All PCIe PHYs on X1E80100 require vdda-qref power supplies, but this is
> >> missing in the current PHY device tree node. The PCIe port can still
> >> function because the regulator L3J, which vdda-qref consumes, is voted by
> >> other components.
> >>
> >> Since the device tree should accurately describe the hardware, add the
> >> vdda-qref power supply explicitly in all PCIe PHY device nodes.
> > 
> > AFAIU the PHYs do not use this qref supply directly so it does not
> > belong in the PHY node (but possibly in the tcsr node that provides the
> > refclk).
> > 
> > Since commit 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100
> > qref supplies") it also won't have any effect for pcie4 and pcie6.
> 
> QREF is a separate hw block distributing the reference clocks across
> certain on-SoC peripherals
> 
> If its power goes out, I don't think much of the platform would be
> functional anyway, so it's redundant here..
> 
> It doesn't have its own single register region and it's frankly
> one-shot-configured way before Linux starts up, so there should be
> no need of describing it at all.

Then it sounds like the qref supplies should be marked as always-on. Can
they be disabled at all?

Johan
Konrad Dybcio April 26, 2025, 10:48 a.m. UTC | #2
On 4/25/25 2:02 PM, Johan Hovold wrote:
> On Fri, Apr 25, 2025 at 12:03:06PM +0200, Konrad Dybcio wrote:
>> On 4/25/25 11:51 AM, Johan Hovold wrote:
>>> On Fri, Apr 25, 2025 at 05:29:55PM +0800, Wenbin Yao wrote:
>>>> From: Qiang Yu <quic_qianyu@quicinc.com>
>>>>
>>>> All PCIe PHYs on X1E80100 require vdda-qref power supplies, but this is
>>>> missing in the current PHY device tree node. The PCIe port can still
>>>> function because the regulator L3J, which vdda-qref consumes, is voted by
>>>> other components.
>>>>
>>>> Since the device tree should accurately describe the hardware, add the
>>>> vdda-qref power supply explicitly in all PCIe PHY device nodes.
>>>
>>> AFAIU the PHYs do not use this qref supply directly so it does not
>>> belong in the PHY node (but possibly in the tcsr node that provides the
>>> refclk).
>>>
>>> Since commit 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100
>>> qref supplies") it also won't have any effect for pcie4 and pcie6.
>>
>> QREF is a separate hw block distributing the reference clocks across
>> certain on-SoC peripherals
>>
>> If its power goes out, I don't think much of the platform would be
>> functional anyway, so it's redundant here..
>>
>> It doesn't have its own single register region and it's frankly
>> one-shot-configured way before Linux starts up, so there should be
>> no need of describing it at all.
> 
> Then it sounds like the qref supplies should be marked as always-on. Can
> they be disabled at all?

The best answer I can say is "maybe". I would (without knowing any better)
assume RPMh wouldn't let you turn them off. QREF predictably takes VDD_CX/MX
and some additional lines

Konrad
Qiang Yu April 30, 2025, 4:15 a.m. UTC | #3
On 4/26/2025 6:48 PM, Konrad Dybcio wrote:
> On 4/25/25 2:02 PM, Johan Hovold wrote:
>> On Fri, Apr 25, 2025 at 12:03:06PM +0200, Konrad Dybcio wrote:
>>> On 4/25/25 11:51 AM, Johan Hovold wrote:
>>>> On Fri, Apr 25, 2025 at 05:29:55PM +0800, Wenbin Yao wrote:
>>>>> From: Qiang Yu <quic_qianyu@quicinc.com>
>>>>>
>>>>> All PCIe PHYs on X1E80100 require vdda-qref power supplies, but this is
>>>>> missing in the current PHY device tree node. The PCIe port can still
>>>>> function because the regulator L3J, which vdda-qref consumes, is voted by
>>>>> other components.
>>>>>
>>>>> Since the device tree should accurately describe the hardware, add the
>>>>> vdda-qref power supply explicitly in all PCIe PHY device nodes.
>>>> AFAIU the PHYs do not use this qref supply directly so it does not
>>>> belong in the PHY node (but possibly in the tcsr node that provides the
>>>> refclk).
>>>>
>>>> Since commit 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100
>>>> qref supplies") it also won't have any effect for pcie4 and pcie6.
>>> QREF is a separate hw block distributing the reference clocks across
>>> certain on-SoC peripherals
>>>
>>> If its power goes out, I don't think much of the platform would be
>>> functional anyway, so it's redundant here..
>>>
>>> It doesn't have its own single register region and it's frankly
>>> one-shot-configured way before Linux starts up, so there should be
>>> no need of describing it at all.
>> Then it sounds like the qref supplies should be marked as always-on. Can
>> they be disabled at all?
> The best answer I can say is "maybe". I would (without knowing any better)
> assume RPMh wouldn't let you turn them off. QREF predictably takes VDD_CX/MX
> and some additional lines
>
> Konrad
The vdda-qref power supply feeds the QREF clocks, which are consumed by 
PCIe, UFS, USB and display on X1e80100.
For PCIe, QREF clks are provided by the TCSR device with the following 
bindings on X1E80100:
#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

These QREF clocks are not enabled all the time and are disabled during 
PHY deinit. Hence, vdda-qref should not be an always-on power supply. It 
should be turned off when the QREF clocks are disabled.

Describing vdda-qref in the PHY device tree node is reasonable, as it 
allows the vdda-qref power supply to be enabled or disabled along with 
the QREF clocks during PHY init/deinit.
Konrad Dybcio April 30, 2025, 7:42 a.m. UTC | #4
On 4/30/25 6:15 AM, Qiang Yu wrote:
> 
> On 4/26/2025 6:48 PM, Konrad Dybcio wrote:
>> On 4/25/25 2:02 PM, Johan Hovold wrote:
>>> On Fri, Apr 25, 2025 at 12:03:06PM +0200, Konrad Dybcio wrote:
>>>> On 4/25/25 11:51 AM, Johan Hovold wrote:
>>>>> On Fri, Apr 25, 2025 at 05:29:55PM +0800, Wenbin Yao wrote:
>>>>>> From: Qiang Yu <quic_qianyu@quicinc.com>
>>>>>>
>>>>>> All PCIe PHYs on X1E80100 require vdda-qref power supplies, but this is
>>>>>> missing in the current PHY device tree node. The PCIe port can still
>>>>>> function because the regulator L3J, which vdda-qref consumes, is voted by
>>>>>> other components.
>>>>>>
>>>>>> Since the device tree should accurately describe the hardware, add the
>>>>>> vdda-qref power supply explicitly in all PCIe PHY device nodes.
>>>>> AFAIU the PHYs do not use this qref supply directly so it does not
>>>>> belong in the PHY node (but possibly in the tcsr node that provides the
>>>>> refclk).
>>>>>
>>>>> Since commit 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100
>>>>> qref supplies") it also won't have any effect for pcie4 and pcie6.
>>>> QREF is a separate hw block distributing the reference clocks across
>>>> certain on-SoC peripherals
>>>>
>>>> If its power goes out, I don't think much of the platform would be
>>>> functional anyway, so it's redundant here..
>>>>
>>>> It doesn't have its own single register region and it's frankly
>>>> one-shot-configured way before Linux starts up, so there should be
>>>> no need of describing it at all.
>>> Then it sounds like the qref supplies should be marked as always-on. Can
>>> they be disabled at all?
>> The best answer I can say is "maybe". I would (without knowing any better)
>> assume RPMh wouldn't let you turn them off. QREF predictably takes VDD_CX/MX
>> and some additional lines
>>
>> Konrad
> The vdda-qref power supply feeds the QREF clocks, which are consumed by PCIe, UFS, USB and display on X1e80100.
> For PCIe, QREF clks are provided by the TCSR device with the following bindings on X1E80100:
> #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
> 
> These QREF clocks are not enabled all the time and are disabled during PHY deinit. Hence, vdda-qref should not be an always-on power supply. It should be turned off when the QREF clocks are disabled.
> 
> Describing vdda-qref in the PHY device tree node is reasonable, as it allows the vdda-qref power supply to be enabled or disabled along with the QREF clocks during PHY init/deinit.

We were advised to repeat this for all QREF consumers as what I said
before may not hold true for all platforms and nobody's gonna play
whack-a-mole with this

Konrad
Johan Hovold April 30, 2025, 7:43 a.m. UTC | #5
[ Qiang, it seems you mail client is removing newlines from your quoted
  replies which makes it hard to read the context. I've tried to add
  them back below, but please try to fix that up. ]

On Wed, Apr 30, 2025 at 12:15:56PM +0800, Qiang Yu wrote:
> On 4/26/2025 6:48 PM, Konrad Dybcio wrote:
> > On 4/25/25 2:02 PM, Johan Hovold wrote:
> >> On Fri, Apr 25, 2025 at 12:03:06PM +0200, Konrad Dybcio wrote:
> >>> On 4/25/25 11:51 AM, Johan Hovold wrote:

> >>>> AFAIU the PHYs do not use this qref supply directly so it does not
> >>>> belong in the PHY node (but possibly in the tcsr node that provides the
> >>>> refclk).
> >>>>
> >>>> Since commit 031b46b4729b ("phy: qcom: qmp-pcie: drop bogus x1e80100
> >>>> qref supplies") it also won't have any effect for pcie4 and pcie6.

> >>> QREF is a separate hw block distributing the reference clocks across
> >>> certain on-SoC peripherals
> >>>
> >>> If its power goes out, I don't think much of the platform would be
> >>> functional anyway, so it's redundant here..
> >>>
> >>> It doesn't have its own single register region and it's frankly
> >>> one-shot-configured way before Linux starts up, so there should be
> >>> no need of describing it at all.

> >> Then it sounds like the qref supplies should be marked as always-on. Can
> >> they be disabled at all?

> > The best answer I can say is "maybe". I would (without knowing any better)
> > assume RPMh wouldn't let you turn them off. QREF predictably takes VDD_CX/MX
> > and some additional lines

> The vdda-qref power supply feeds the QREF clocks, which are consumed by 
> PCIe, UFS, USB and display on X1e80100.
> For PCIe, QREF clks are provided by the TCSR device with the following 
> bindings on X1E80100:
> #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
> 
> These QREF clocks are not enabled all the time and are disabled during 
> PHY deinit. Hence, vdda-qref should not be an always-on power supply. It 
> should be turned off when the QREF clocks are disabled.
> 
> Describing vdda-qref in the PHY device tree node is reasonable, as it 
> allows the vdda-qref power supply to be enabled or disabled along with 
> the QREF clocks during PHY init/deinit.

It may work, but it seems more reasonable to have the TCSR clock
controller manage them even if that isn't necessarily an entirely
accurate description of the hw either.

On the T14s (X1E), we have 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

which does not seem to map directly to the three PCIe PHYs (and other
consumers).

Johan
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
index 88dfd2199..10f2ac70e 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
@@ -994,6 +994,7 @@  &pcie3 {
 &pcie3_phy {
 	vdda-phy-supply = <&vreg_l3c_0p8>;
 	vdda-pll-supply = <&vreg_l3e_1p2>;
+	vdda-qref-supply = <&vreg_l3j_0p8>;
 
 	status = "okay";
 };
@@ -1017,6 +1018,7 @@  &pcie4 {
 &pcie4_phy {
 	vdda-phy-supply = <&vreg_l3i_0p8>;
 	vdda-pll-supply = <&vreg_l3e_1p2>;
+	vdda-qref-supply = <&vreg_l3j_0p8>;
 
 	status = "okay";
 };
@@ -1053,6 +1055,7 @@  &pcie6a {
 &pcie6a_phy {
 	vdda-phy-supply = <&vreg_l1d_0p8>;
 	vdda-pll-supply = <&vreg_l2j_1p2>;
+	vdda-qref-supply = <&vreg_l3j_0p8>;
 
 	status = "okay";
 };