[PATCH v3 0/4] clk: qcom: Add common clkref support and migrate Glymur

[PATCH v3 0/4] clk: qcom: Add common clkref support and migrate Glymur

[Qiang Yu]

This series adds a common clkref_en implementation and converts glymur to
use it, along with the related binding and DTS updates.

The PCIe clkref clocks on Glymur gate the QREF block which provides
reference clocks to the PCIe PHYs. QREF requires LDO supplies and a
reference voltage from the refgen block to operate. The refgen block
itself requires vdda-refgen_0p9 and vdda-refgen_1p2 LDOs to function.

Previously, these QREF votes were done in PHY drivers. In earlier
discussion [1], the feedback was that this is the wrong ownership point:
those supplies are for the QREF controlled by clkref registers, not for
PHY directly. Based on that feedback, this series keeps the regulator
handling with the clkref control path.

Another reason for this series is reuse. clkref_en registers may live in
different blocks across platforms (for example TCSR on Glymur, TLMM on
SM8750 [2]), while the behavior is the same. The common helper lets each
driver provide simple descriptors (name, offset, optional supplies) and
reuse shared registration and runtime logic.

[1] https://lore.kernel.org/lkml/aEBfV2M-ZqDF7aRz@hovoldconsulting.com/
[2] https://lore.kernel.org/linux-arm-msm/20260202-topic-8750_tcsr-v1-0-cd7e6648c64f@oss.qualcomm.com/

Changes in v3:
- Fix dtb check error: allOf:0: 'then' is a dependency of 'if'.
- Link to v2: https://lore.kernel.org/all/20260420-vote_qref_in_tcsrcc-v2-0-589a23ae640a@oss.qualcomm.com/

Changes in v2:
- RFC tag dropped
- Changed back to additionalProperties: false
- Moved all Glymur supply properties into top-level properties so they are explicitly defined.
- Link to v1: https://lore.kernel.org/all/20260331-qref_vote-v1-0-3fd7fbf87864@oss.qualcomm.com/

Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
Qiang Yu (4):
      dt-bindings: clock: qcom: Add QREF regulator supplies for glymur
      clk: qcom: Add generic clkref_en support
      clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper
      arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR

 .../bindings/clock/qcom,sm8550-tcsr.yaml           |  57 ++++
 arch/arm64/boot/dts/qcom/glymur-crd.dts            |  19 ++
 drivers/clk/qcom/Makefile                          |   1 +
 drivers/clk/qcom/clk-ref.c                         | 202 ++++++++++++
 drivers/clk/qcom/tcsrcc-glymur.c                   | 340 ++++++---------------
 include/linux/clk/qcom.h                           |  69 +++++
 6 files changed, 441 insertions(+), 247 deletions(-)
---
base-commit: 4cd074ae20bbcc293bbbce9163abe99d68ae6ae0
change-id: 20260505-qref_vote_0506-fb14bfb08cd9

Best regards,
--  
Qiang Yu <qiang.yu@oss.qualcomm.com>

[PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Qiang Yu]

Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
required by clkref clocks.

The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
QREF TX/RPT/RX components, while SoC-specific topology and instance count
differ. Document them here for qcom,glymur-tcsr.

Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
 .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
index 1ccdf4b0f5dd..57921cb63230 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
@@ -51,6 +51,63 @@ properties:
   '#reset-cells':
     const: 1
 
+  vdda-refgen-0p9-supply: true
+  vdda-refgen-1p2-supply: true
+  vdda-qrefrx0-0p9-supply: true
+  vdda-qrefrx1-0p9-supply: true
+  vdda-qrefrx2-0p9-supply: true
+  vdda-qrefrx4-0p9-supply: true
+  vdda-qrefrx5-0p9-supply: true
+  vdda-qreftx0-0p9-supply: true
+  vdda-qreftx0-1p2-supply: true
+  vdda-qreftx1-0p9-supply: true
+  vdda-qrefrpt0-0p9-supply: true
+  vdda-qrefrpt1-0p9-supply: true
+  vdda-qrefrpt2-0p9-supply: true
+  vdda-qrefrpt3-0p9-supply: true
+  vdda-qrefrpt4-0p9-supply: true
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: qcom,glymur-tcsr
+    then:
+      required:
+        - vdda-refgen-0p9-supply
+        - vdda-refgen-1p2-supply
+        - vdda-qrefrx0-0p9-supply
+        - vdda-qrefrx1-0p9-supply
+        - vdda-qrefrx2-0p9-supply
+        - vdda-qrefrx4-0p9-supply
+        - vdda-qrefrx5-0p9-supply
+        - vdda-qreftx0-0p9-supply
+        - vdda-qreftx0-1p2-supply
+        - vdda-qreftx1-0p9-supply
+        - vdda-qrefrpt0-0p9-supply
+        - vdda-qrefrpt1-0p9-supply
+        - vdda-qrefrpt2-0p9-supply
+        - vdda-qrefrpt3-0p9-supply
+        - vdda-qrefrpt4-0p9-supply
+    else:
+      properties:
+        vdda-refgen-0p9-supply: false
+        vdda-refgen-1p2-supply: false
+        vdda-qrefrx0-0p9-supply: false
+        vdda-qrefrx1-0p9-supply: false
+        vdda-qrefrx2-0p9-supply: false
+        vdda-qrefrx4-0p9-supply: false
+        vdda-qrefrx5-0p9-supply: false
+        vdda-qreftx0-0p9-supply: false
+        vdda-qreftx0-1p2-supply: false
+        vdda-qreftx1-0p9-supply: false
+        vdda-qrefrpt0-0p9-supply: false
+        vdda-qrefrpt1-0p9-supply: false
+        vdda-qrefrpt2-0p9-supply: false
+        vdda-qrefrpt3-0p9-supply: false
+        vdda-qrefrpt4-0p9-supply: false
+
 required:
   - compatible
   - clocks

-- 
2.34.1

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Krzysztof Kozlowski]

On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
> required by clkref clocks.
> 
> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
> QREF TX/RPT/RX components, while SoC-specific topology and instance count
> differ. Document them here for qcom,glymur-tcsr.
> 
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> index 1ccdf4b0f5dd..57921cb63230 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> @@ -51,6 +51,63 @@ properties:
>    '#reset-cells':
>      const: 1
>  
> +  vdda-refgen-0p9-supply: true
> +  vdda-refgen-1p2-supply: true
> +  vdda-qrefrx0-0p9-supply: true
> +  vdda-qrefrx1-0p9-supply: true
> +  vdda-qrefrx2-0p9-supply: true
> +  vdda-qrefrx4-0p9-supply: true
> +  vdda-qrefrx5-0p9-supply: true
> +  vdda-qreftx0-0p9-supply: true
> +  vdda-qreftx0-1p2-supply: true
> +  vdda-qreftx1-0p9-supply: true
> +  vdda-qrefrpt0-0p9-supply: true
> +  vdda-qrefrpt1-0p9-supply: true
> +  vdda-qrefrpt2-0p9-supply: true
> +  vdda-qrefrpt3-0p9-supply: true
> +  vdda-qrefrpt4-0p9-supply: true

Either I do not understand your previous explanation:
CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY

or this is still wrong. There is no TCSR here, so this proves nothing.
If TCSR is TX0, then you do not have five of them...

My previous comment stay - you are not describing the actual hardware
here.

Best regards,
Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Krzysztof Kozlowski]

On 14/05/2026 12:22, Krzysztof Kozlowski wrote:
> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
>> required by clkref clocks.
>>
>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
>> differ. Document them here for qcom,glymur-tcsr.
>>
>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>> ---
>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
>>  1 file changed, 57 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>> index 1ccdf4b0f5dd..57921cb63230 100644
>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>> @@ -51,6 +51,63 @@ properties:
>>    '#reset-cells':
>>      const: 1
>>  
>> +  vdda-refgen-0p9-supply: true
>> +  vdda-refgen-1p2-supply: true
>> +  vdda-qrefrx0-0p9-supply: true
>> +  vdda-qrefrx1-0p9-supply: true
>> +  vdda-qrefrx2-0p9-supply: true
>> +  vdda-qrefrx4-0p9-supply: true
>> +  vdda-qrefrx5-0p9-supply: true
>> +  vdda-qreftx0-0p9-supply: true
>> +  vdda-qreftx0-1p2-supply: true
>> +  vdda-qreftx1-0p9-supply: true
>> +  vdda-qrefrpt0-0p9-supply: true
>> +  vdda-qrefrpt1-0p9-supply: true
>> +  vdda-qrefrpt2-0p9-supply: true
>> +  vdda-qrefrpt3-0p9-supply: true
>> +  vdda-qrefrpt4-0p9-supply: true
> 
> Either I do not understand your previous explanation:
> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
> 
> or this is still wrong. There is no TCSR here, so this proves nothing.
> If TCSR is TX0, then you do not have five of them...
> 
> My previous comment stay - you are not describing the actual hardware
> here.

And it should not be my task BUT YOURS to verify this in hardware
programming guide or manual, but nevertheless I did verify and the
manual DOES NOT mention these supplies. For Glymur, it mentions 8 reset
ports and 5 clock ports.

No supplies at all.

Then I went to QREF and it does mention few supplies but completely
different, like mx, cx, px 0.88 and px1.2, so none of this matches QREF
either.

Best regards,
Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Qiang Yu]

On Thu, May 14, 2026 at 12:35:19PM +0200, Krzysztof Kozlowski wrote:
> On 14/05/2026 12:22, Krzysztof Kozlowski wrote:
> > On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
> >> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
> >> required by clkref clocks.
> >>
> >> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
> >> QREF TX/RPT/RX components, while SoC-specific topology and instance count
> >> differ. Document them here for qcom,glymur-tcsr.
> >>
> >> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> >> ---
> >>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
> >>  1 file changed, 57 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >> index 1ccdf4b0f5dd..57921cb63230 100644
> >> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >> @@ -51,6 +51,63 @@ properties:
> >>    '#reset-cells':
> >>      const: 1
> >>  
> >> +  vdda-refgen-0p9-supply: true
> >> +  vdda-refgen-1p2-supply: true
> >> +  vdda-qrefrx0-0p9-supply: true
> >> +  vdda-qrefrx1-0p9-supply: true
> >> +  vdda-qrefrx2-0p9-supply: true
> >> +  vdda-qrefrx4-0p9-supply: true
> >> +  vdda-qrefrx5-0p9-supply: true
> >> +  vdda-qreftx0-0p9-supply: true
> >> +  vdda-qreftx0-1p2-supply: true
> >> +  vdda-qreftx1-0p9-supply: true
> >> +  vdda-qrefrpt0-0p9-supply: true
> >> +  vdda-qrefrpt1-0p9-supply: true
> >> +  vdda-qrefrpt2-0p9-supply: true
> >> +  vdda-qrefrpt3-0p9-supply: true
> >> +  vdda-qrefrpt4-0p9-supply: true
> > 
> > Either I do not understand your previous explanation:
> > CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
> > 
> > or this is still wrong. There is no TCSR here, so this proves nothing.
> > If TCSR is TX0, then you do not have five of them...
> > 
> > My previous comment stay - you are not describing the actual hardware
> > here.
> 
> And it should not be my task BUT YOURS to verify this in hardware
> programming guide or manual, but nevertheless I did verify and the
> manual DOES NOT mention these supplies. For Glymur, it mentions 8 reset
> ports and 5 clock ports.
> 
> No supplies at all.
> 
> Then I went to QREF and it does mention few supplies but completely
> different, like mx, cx, px 0.88 and px1.2, so none of this matches QREF
> either.
>

Honestly, I couldn't find QREF LDO-related information in HPG either.
However, you can find it on IPCAT. For example, in the glymur power grid,
these LDOs are clearly documented under the LDOs required by each PHY,
even though they are not directly supplied to the PHY. In the QREF
diagram ,you can see the complete QREF network.

Of course, on some platforms — such as monaco — although the QREF LDOs are
also documented in the power grid, there is no indication of which
specific QREF LDO each PHY requires, and no QREF diagram is provided. In
such cases, we can only verify this information with the SVE team.

- Qiang Yu
> Best regards,
> Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Krzysztof Kozlowski]

On 17/05/2026 07:58, Qiang Yu wrote:
> On Thu, May 14, 2026 at 12:35:19PM +0200, Krzysztof Kozlowski wrote:
>> On 14/05/2026 12:22, Krzysztof Kozlowski wrote:
>>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
>>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
>>>> required by clkref clocks.
>>>>
>>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
>>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
>>>> differ. Document them here for qcom,glymur-tcsr.
>>>>
>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>>> ---
>>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
>>>>  1 file changed, 57 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>> index 1ccdf4b0f5dd..57921cb63230 100644
>>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>> @@ -51,6 +51,63 @@ properties:
>>>>    '#reset-cells':
>>>>      const: 1
>>>>  
>>>> +  vdda-refgen-0p9-supply: true
>>>> +  vdda-refgen-1p2-supply: true
>>>> +  vdda-qrefrx0-0p9-supply: true
>>>> +  vdda-qrefrx1-0p9-supply: true
>>>> +  vdda-qrefrx2-0p9-supply: true
>>>> +  vdda-qrefrx4-0p9-supply: true
>>>> +  vdda-qrefrx5-0p9-supply: true
>>>> +  vdda-qreftx0-0p9-supply: true
>>>> +  vdda-qreftx0-1p2-supply: true
>>>> +  vdda-qreftx1-0p9-supply: true
>>>> +  vdda-qrefrpt0-0p9-supply: true
>>>> +  vdda-qrefrpt1-0p9-supply: true
>>>> +  vdda-qrefrpt2-0p9-supply: true
>>>> +  vdda-qrefrpt3-0p9-supply: true
>>>> +  vdda-qrefrpt4-0p9-supply: true
>>>
>>> Either I do not understand your previous explanation:
>>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
>>>
>>> or this is still wrong. There is no TCSR here, so this proves nothing.
>>> If TCSR is TX0, then you do not have five of them...
>>>
>>> My previous comment stay - you are not describing the actual hardware
>>> here.
>>
>> And it should not be my task BUT YOURS to verify this in hardware
>> programming guide or manual, but nevertheless I did verify and the
>> manual DOES NOT mention these supplies. For Glymur, it mentions 8 reset
>> ports and 5 clock ports.
>>
>> No supplies at all.
>>
>> Then I went to QREF and it does mention few supplies but completely
>> different, like mx, cx, px 0.88 and px1.2, so none of this matches QREF
>> either.
>>
> 
> Honestly, I couldn't find QREF LDO-related information in HPG either.
> However, you can find it on IPCAT. For example, in the glymur power grid,
> these LDOs are clearly documented under the LDOs required by each PHY,

How is that relevant here? This is not PHY here. You are adding supplies
to TCSR. Do you understand what a supply is?


Best regards,
Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Qiang Yu]

On Sun, May 17, 2026 at 10:28:48AM +0200, Krzysztof Kozlowski wrote:
> On 17/05/2026 07:58, Qiang Yu wrote:
> > On Thu, May 14, 2026 at 12:35:19PM +0200, Krzysztof Kozlowski wrote:
> >> On 14/05/2026 12:22, Krzysztof Kozlowski wrote:
> >>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
> >>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
> >>>> required by clkref clocks.
> >>>>
> >>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
> >>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
> >>>> differ. Document them here for qcom,glymur-tcsr.
> >>>>
> >>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> >>>> ---
> >>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
> >>>>  1 file changed, 57 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>> index 1ccdf4b0f5dd..57921cb63230 100644
> >>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>> @@ -51,6 +51,63 @@ properties:
> >>>>    '#reset-cells':
> >>>>      const: 1
> >>>>  
> >>>> +  vdda-refgen-0p9-supply: true
> >>>> +  vdda-refgen-1p2-supply: true
> >>>> +  vdda-qrefrx0-0p9-supply: true
> >>>> +  vdda-qrefrx1-0p9-supply: true
> >>>> +  vdda-qrefrx2-0p9-supply: true
> >>>> +  vdda-qrefrx4-0p9-supply: true
> >>>> +  vdda-qrefrx5-0p9-supply: true
> >>>> +  vdda-qreftx0-0p9-supply: true
> >>>> +  vdda-qreftx0-1p2-supply: true
> >>>> +  vdda-qreftx1-0p9-supply: true
> >>>> +  vdda-qrefrpt0-0p9-supply: true
> >>>> +  vdda-qrefrpt1-0p9-supply: true
> >>>> +  vdda-qrefrpt2-0p9-supply: true
> >>>> +  vdda-qrefrpt3-0p9-supply: true
> >>>> +  vdda-qrefrpt4-0p9-supply: true
> >>>
> >>> Either I do not understand your previous explanation:
> >>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
> >>>
> >>> or this is still wrong. There is no TCSR here, so this proves nothing.
> >>> If TCSR is TX0, then you do not have five of them...
> >>>
> >>> My previous comment stay - you are not describing the actual hardware
> >>> here.
> >>
> >> And it should not be my task BUT YOURS to verify this in hardware
> >> programming guide or manual, but nevertheless I did verify and the
> >> manual DOES NOT mention these supplies. For Glymur, it mentions 8 reset
> >> ports and 5 clock ports.
> >>
> >> No supplies at all.
> >>
> >> Then I went to QREF and it does mention few supplies but completely
> >> different, like mx, cx, px 0.88 and px1.2, so none of this matches QREF
> >> either.
> >>
> > 
> > Honestly, I couldn't find QREF LDO-related information in HPG either.
> > However, you can find it on IPCAT. For example, in the glymur power grid,
> > these LDOs are clearly documented under the LDOs required by each PHY,
> 
> How is that relevant here? This is not PHY here. You are adding supplies
> to TCSR. Do you understand what a supply is?
>

I'm telling you the fact that I see from power grid table.

- Qiang Yu

> 
> Best regards,
> Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Krzysztof Kozlowski]

On 18/05/2026 05:35, Qiang Yu wrote:
> On Sun, May 17, 2026 at 10:28:48AM +0200, Krzysztof Kozlowski wrote:
>> On 17/05/2026 07:58, Qiang Yu wrote:
>>> On Thu, May 14, 2026 at 12:35:19PM +0200, Krzysztof Kozlowski wrote:
>>>> On 14/05/2026 12:22, Krzysztof Kozlowski wrote:
>>>>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
>>>>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
>>>>>> required by clkref clocks.
>>>>>>
>>>>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
>>>>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
>>>>>> differ. Document them here for qcom,glymur-tcsr.
>>>>>>
>>>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>>>>> ---
>>>>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
>>>>>>  1 file changed, 57 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>> index 1ccdf4b0f5dd..57921cb63230 100644
>>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>> @@ -51,6 +51,63 @@ properties:
>>>>>>    '#reset-cells':
>>>>>>      const: 1
>>>>>>  
>>>>>> +  vdda-refgen-0p9-supply: true
>>>>>> +  vdda-refgen-1p2-supply: true
>>>>>> +  vdda-qrefrx0-0p9-supply: true
>>>>>> +  vdda-qrefrx1-0p9-supply: true
>>>>>> +  vdda-qrefrx2-0p9-supply: true
>>>>>> +  vdda-qrefrx4-0p9-supply: true
>>>>>> +  vdda-qrefrx5-0p9-supply: true
>>>>>> +  vdda-qreftx0-0p9-supply: true
>>>>>> +  vdda-qreftx0-1p2-supply: true
>>>>>> +  vdda-qreftx1-0p9-supply: true
>>>>>> +  vdda-qrefrpt0-0p9-supply: true
>>>>>> +  vdda-qrefrpt1-0p9-supply: true
>>>>>> +  vdda-qrefrpt2-0p9-supply: true
>>>>>> +  vdda-qrefrpt3-0p9-supply: true
>>>>>> +  vdda-qrefrpt4-0p9-supply: true
>>>>>
>>>>> Either I do not understand your previous explanation:
>>>>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
>>>>>
>>>>> or this is still wrong. There is no TCSR here, so this proves nothing.
>>>>> If TCSR is TX0, then you do not have five of them...
>>>>>
>>>>> My previous comment stay - you are not describing the actual hardware
>>>>> here.
>>>>
>>>> And it should not be my task BUT YOURS to verify this in hardware
>>>> programming guide or manual, but nevertheless I did verify and the
>>>> manual DOES NOT mention these supplies. For Glymur, it mentions 8 reset
>>>> ports and 5 clock ports.
>>>>
>>>> No supplies at all.
>>>>
>>>> Then I went to QREF and it does mention few supplies but completely
>>>> different, like mx, cx, px 0.88 and px1.2, so none of this matches QREF
>>>> either.
>>>>
>>>
>>> Honestly, I couldn't find QREF LDO-related information in HPG either.
>>> However, you can find it on IPCAT. For example, in the glymur power grid,
>>> these LDOs are clearly documented under the LDOs required by each PHY,
>>
>> How is that relevant here? This is not PHY here. You are adding supplies
>> to TCSR. Do you understand what a supply is?
>>
> 
> I'm telling you the fact that I see from power grid table.

So you see supplies in phy, then add them to the phy.

Best regards,
Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Qiang Yu]

On Mon, May 18, 2026 at 08:59:14AM +0200, Krzysztof Kozlowski wrote:
> On 18/05/2026 05:35, Qiang Yu wrote:
> > On Sun, May 17, 2026 at 10:28:48AM +0200, Krzysztof Kozlowski wrote:
> >> On 17/05/2026 07:58, Qiang Yu wrote:
> >>> On Thu, May 14, 2026 at 12:35:19PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 14/05/2026 12:22, Krzysztof Kozlowski wrote:
> >>>>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
> >>>>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
> >>>>>> required by clkref clocks.
> >>>>>>
> >>>>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
> >>>>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
> >>>>>> differ. Document them here for qcom,glymur-tcsr.
> >>>>>>
> >>>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> >>>>>> ---
> >>>>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
> >>>>>>  1 file changed, 57 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>>>> index 1ccdf4b0f5dd..57921cb63230 100644
> >>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>>>> @@ -51,6 +51,63 @@ properties:
> >>>>>>    '#reset-cells':
> >>>>>>      const: 1
> >>>>>>  
> >>>>>> +  vdda-refgen-0p9-supply: true
> >>>>>> +  vdda-refgen-1p2-supply: true
> >>>>>> +  vdda-qrefrx0-0p9-supply: true
> >>>>>> +  vdda-qrefrx1-0p9-supply: true
> >>>>>> +  vdda-qrefrx2-0p9-supply: true
> >>>>>> +  vdda-qrefrx4-0p9-supply: true
> >>>>>> +  vdda-qrefrx5-0p9-supply: true
> >>>>>> +  vdda-qreftx0-0p9-supply: true
> >>>>>> +  vdda-qreftx0-1p2-supply: true
> >>>>>> +  vdda-qreftx1-0p9-supply: true
> >>>>>> +  vdda-qrefrpt0-0p9-supply: true
> >>>>>> +  vdda-qrefrpt1-0p9-supply: true
> >>>>>> +  vdda-qrefrpt2-0p9-supply: true
> >>>>>> +  vdda-qrefrpt3-0p9-supply: true
> >>>>>> +  vdda-qrefrpt4-0p9-supply: true
> >>>>>
> >>>>> Either I do not understand your previous explanation:
> >>>>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
> >>>>>
> >>>>> or this is still wrong. There is no TCSR here, so this proves nothing.
> >>>>> If TCSR is TX0, then you do not have five of them...
> >>>>>
> >>>>> My previous comment stay - you are not describing the actual hardware
> >>>>> here.
> >>>>
> >>>> And it should not be my task BUT YOURS to verify this in hardware
> >>>> programming guide or manual, but nevertheless I did verify and the
> >>>> manual DOES NOT mention these supplies. For Glymur, it mentions 8 reset
> >>>> ports and 5 clock ports.
> >>>>
> >>>> No supplies at all.
> >>>>
> >>>> Then I went to QREF and it does mention few supplies but completely
> >>>> different, like mx, cx, px 0.88 and px1.2, so none of this matches QREF
> >>>> either.
> >>>>
> >>>
> >>> Honestly, I couldn't find QREF LDO-related information in HPG either.
> >>> However, you can find it on IPCAT. For example, in the glymur power grid,
> >>> these LDOs are clearly documented under the LDOs required by each PHY,
> >>
> >> How is that relevant here? This is not PHY here. You are adding supplies
> >> to TCSR. Do you understand what a supply is?
> >>
> > 
> > I'm telling you the fact that I see from power grid table.
> 
> So you see supplies in phy, then add them to the phy.

These LDOs don't supply to PHY directly and this is why I was taught to
add them in TCSR.

- Qiang Yu

> 
> Best regards,
> Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Qiang Yu]

On Thu, May 14, 2026 at 12:22:17PM +0200, Krzysztof Kozlowski wrote:
> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
> > Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
> > required by clkref clocks.
> > 
> > The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
> > QREF TX/RPT/RX components, while SoC-specific topology and instance count
> > differ. Document them here for qcom,glymur-tcsr.
> > 
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> >  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
> >  1 file changed, 57 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > index 1ccdf4b0f5dd..57921cb63230 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > @@ -51,6 +51,63 @@ properties:
> >    '#reset-cells':
> >      const: 1
> >  
> > +  vdda-refgen-0p9-supply: true
> > +  vdda-refgen-1p2-supply: true
> > +  vdda-qrefrx0-0p9-supply: true
> > +  vdda-qrefrx1-0p9-supply: true
> > +  vdda-qrefrx2-0p9-supply: true
> > +  vdda-qrefrx4-0p9-supply: true
> > +  vdda-qrefrx5-0p9-supply: true
> > +  vdda-qreftx0-0p9-supply: true
> > +  vdda-qreftx0-1p2-supply: true
> > +  vdda-qreftx1-0p9-supply: true
> > +  vdda-qrefrpt0-0p9-supply: true
> > +  vdda-qrefrpt1-0p9-supply: true
> > +  vdda-qrefrpt2-0p9-supply: true
> > +  vdda-qrefrpt3-0p9-supply: true
> > +  vdda-qrefrpt4-0p9-supply: true
> 
> Either I do not understand your previous explanation:
> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
>
> or this is still wrong. There is no TCSR here, so this proves nothing.
> If TCSR is TX0, then you do not have five of them...
> 
> My previous comment stay - you are not describing the actual hardware
> here.
> 
The CXO network "-> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 ->" is referred to
as the QREF block, and each component is controlled by the tcsr_clkref_en
registers.

If a PHY receives its reference clock from QREF, it will have a clkref_en
register. However, this register may be located in different regions
depending on the target. On glymur it resides in TCSR, so I added these
LDOs QREF required in tcsr yaml.

- Qiang Yu

> Best regards,
> Krzysztof
> 

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Krzysztof Kozlowski]

On 17/05/2026 07:39, Qiang Yu wrote:
> On Thu, May 14, 2026 at 12:22:17PM +0200, Krzysztof Kozlowski wrote:
>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
>>> required by clkref clocks.
>>>
>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
>>> differ. Document them here for qcom,glymur-tcsr.
>>>
>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>> ---
>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
>>>  1 file changed, 57 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>> index 1ccdf4b0f5dd..57921cb63230 100644
>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>> @@ -51,6 +51,63 @@ properties:
>>>    '#reset-cells':
>>>      const: 1
>>>  
>>> +  vdda-refgen-0p9-supply: true
>>> +  vdda-refgen-1p2-supply: true
>>> +  vdda-qrefrx0-0p9-supply: true
>>> +  vdda-qrefrx1-0p9-supply: true
>>> +  vdda-qrefrx2-0p9-supply: true
>>> +  vdda-qrefrx4-0p9-supply: true
>>> +  vdda-qrefrx5-0p9-supply: true
>>> +  vdda-qreftx0-0p9-supply: true
>>> +  vdda-qreftx0-1p2-supply: true
>>> +  vdda-qreftx1-0p9-supply: true
>>> +  vdda-qrefrpt0-0p9-supply: true
>>> +  vdda-qrefrpt1-0p9-supply: true
>>> +  vdda-qrefrpt2-0p9-supply: true
>>> +  vdda-qrefrpt3-0p9-supply: true
>>> +  vdda-qrefrpt4-0p9-supply: true
>>
>> Either I do not understand your previous explanation:
>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
>>
>> or this is still wrong. There is no TCSR here, so this proves nothing.
>> If TCSR is TX0, then you do not have five of them...
>>
>> My previous comment stay - you are not describing the actual hardware
>> here.
>>
> The CXO network "-> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 ->" is referred to
> as the QREF block, and each component is controlled by the tcsr_clkref_en
> registers.

Still no clue what this -> relation is. Again, describe the hardware.

> 
> If a PHY receives its reference clock from QREF, it will have a clkref_en
> register. However, this register may be located in different regions
> depending on the target. On glymur it resides in TCSR, so I added these
> LDOs QREF required in tcsr yaml.
Registers are not described as supplies.

Best regards,
Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Qiang Yu]

On Sun, May 17, 2026 at 10:27:39AM +0200, Krzysztof Kozlowski wrote:
> On 17/05/2026 07:39, Qiang Yu wrote:
> > On Thu, May 14, 2026 at 12:22:17PM +0200, Krzysztof Kozlowski wrote:
> >> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
> >>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
> >>> required by clkref clocks.
> >>>
> >>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
> >>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
> >>> differ. Document them here for qcom,glymur-tcsr.
> >>>
> >>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> >>> ---
> >>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
> >>>  1 file changed, 57 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>> index 1ccdf4b0f5dd..57921cb63230 100644
> >>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>> @@ -51,6 +51,63 @@ properties:
> >>>    '#reset-cells':
> >>>      const: 1
> >>>  
> >>> +  vdda-refgen-0p9-supply: true
> >>> +  vdda-refgen-1p2-supply: true
> >>> +  vdda-qrefrx0-0p9-supply: true
> >>> +  vdda-qrefrx1-0p9-supply: true
> >>> +  vdda-qrefrx2-0p9-supply: true
> >>> +  vdda-qrefrx4-0p9-supply: true
> >>> +  vdda-qrefrx5-0p9-supply: true
> >>> +  vdda-qreftx0-0p9-supply: true
> >>> +  vdda-qreftx0-1p2-supply: true
> >>> +  vdda-qreftx1-0p9-supply: true
> >>> +  vdda-qrefrpt0-0p9-supply: true
> >>> +  vdda-qrefrpt1-0p9-supply: true
> >>> +  vdda-qrefrpt2-0p9-supply: true
> >>> +  vdda-qrefrpt3-0p9-supply: true
> >>> +  vdda-qrefrpt4-0p9-supply: true
> >>
> >> Either I do not understand your previous explanation:
> >> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
> >>
> >> or this is still wrong. There is no TCSR here, so this proves nothing.
> >> If TCSR is TX0, then you do not have five of them...
> >>
> >> My previous comment stay - you are not describing the actual hardware
> >> here.
> >>
> > The CXO network "-> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 ->" is referred to
> > as the QREF block, and each component is controlled by the tcsr_clkref_en
> > registers.
> 
> Still no clue what this -> relation is. Again, describe the hardware.
> 
> > 
> > If a PHY receives its reference clock from QREF, it will have a clkref_en
> > register. However, this register may be located in different regions
> > depending on the target. On glymur it resides in TCSR, so I added these
> > LDOs QREF required in tcsr yaml.
> Registers are not described as supplies.

I'm not descirbing register as supply.

    tx0-0p9/1p2  rpt0-0p9   rpt1-0p9    rpt2-0p9    rx2-0p9
       |             |           |        |           |
       |             |           |        |           |
CXO -> TX0 -------> RPT0 ------> RPT1 -> RPT2 -----> RX2 -> PCIe4_PHY
       |             |           |        |           |
       |             |           |        |           |
       ---------------------------------------------------tcsr_clkref_en

These components(TX/RTP/RX) can be disabled/enabled by tcsr_clkref_en
register, and they require power supplies.

- Qiang Yu

> 
> Best regards,
> Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Krzysztof Kozlowski]

On 18/05/2026 05:50, Qiang Yu wrote:
> On Sun, May 17, 2026 at 10:27:39AM +0200, Krzysztof Kozlowski wrote:
>> On 17/05/2026 07:39, Qiang Yu wrote:
>>> On Thu, May 14, 2026 at 12:22:17PM +0200, Krzysztof Kozlowski wrote:
>>>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
>>>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
>>>>> required by clkref clocks.
>>>>>
>>>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
>>>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
>>>>> differ. Document them here for qcom,glymur-tcsr.
>>>>>
>>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>>>> ---
>>>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
>>>>>  1 file changed, 57 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>> index 1ccdf4b0f5dd..57921cb63230 100644
>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>> @@ -51,6 +51,63 @@ properties:
>>>>>    '#reset-cells':
>>>>>      const: 1
>>>>>  
>>>>> +  vdda-refgen-0p9-supply: true
>>>>> +  vdda-refgen-1p2-supply: true
>>>>> +  vdda-qrefrx0-0p9-supply: true
>>>>> +  vdda-qrefrx1-0p9-supply: true
>>>>> +  vdda-qrefrx2-0p9-supply: true
>>>>> +  vdda-qrefrx4-0p9-supply: true
>>>>> +  vdda-qrefrx5-0p9-supply: true
>>>>> +  vdda-qreftx0-0p9-supply: true
>>>>> +  vdda-qreftx0-1p2-supply: true
>>>>> +  vdda-qreftx1-0p9-supply: true
>>>>> +  vdda-qrefrpt0-0p9-supply: true
>>>>> +  vdda-qrefrpt1-0p9-supply: true
>>>>> +  vdda-qrefrpt2-0p9-supply: true
>>>>> +  vdda-qrefrpt3-0p9-supply: true
>>>>> +  vdda-qrefrpt4-0p9-supply: true
>>>>
>>>> Either I do not understand your previous explanation:
>>>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
>>>>
>>>> or this is still wrong. There is no TCSR here, so this proves nothing.
>>>> If TCSR is TX0, then you do not have five of them...
>>>>
>>>> My previous comment stay - you are not describing the actual hardware
>>>> here.
>>>>
>>> The CXO network "-> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 ->" is referred to
>>> as the QREF block, and each component is controlled by the tcsr_clkref_en
>>> registers.
>>
>> Still no clue what this -> relation is. Again, describe the hardware.
>>
>>>
>>> If a PHY receives its reference clock from QREF, it will have a clkref_en
>>> register. However, this register may be located in different regions
>>> depending on the target. On glymur it resides in TCSR, so I added these
>>> LDOs QREF required in tcsr yaml.
>> Registers are not described as supplies.
> 
> I'm not descirbing register as supply.
> 
>     tx0-0p9/1p2  rpt0-0p9   rpt1-0p9    rpt2-0p9    rx2-0p9
>        |             |           |        |           |
>        |             |           |        |           |
> CXO -> TX0 -------> RPT0 ------> RPT1 -> RPT2 -----> RX2 -> PCIe4_PHY
>        |             |           |        |           |
>        |             |           |        |           |
>        ---------------------------------------------------tcsr_clkref_en
> 
> These components(TX/RTP/RX) can be disabled/enabled by tcsr_clkref_en
> register, and they require power supplies.

So I told you more than once - none of these are supplies to the TCSR.
You clearly misunderstand what a supply is.


Best regards,
Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Qiang Yu]

On Mon, May 18, 2026 at 09:00:33AM +0200, Krzysztof Kozlowski wrote:
> On 18/05/2026 05:50, Qiang Yu wrote:
> > On Sun, May 17, 2026 at 10:27:39AM +0200, Krzysztof Kozlowski wrote:
> >> On 17/05/2026 07:39, Qiang Yu wrote:
> >>> On Thu, May 14, 2026 at 12:22:17PM +0200, Krzysztof Kozlowski wrote:
> >>>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
> >>>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
> >>>>> required by clkref clocks.
> >>>>>
> >>>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
> >>>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
> >>>>> differ. Document them here for qcom,glymur-tcsr.
> >>>>>
> >>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> >>>>> ---
> >>>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
> >>>>>  1 file changed, 57 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>>> index 1ccdf4b0f5dd..57921cb63230 100644
> >>>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> >>>>> @@ -51,6 +51,63 @@ properties:
> >>>>>    '#reset-cells':
> >>>>>      const: 1
> >>>>>  
> >>>>> +  vdda-refgen-0p9-supply: true
> >>>>> +  vdda-refgen-1p2-supply: true
> >>>>> +  vdda-qrefrx0-0p9-supply: true
> >>>>> +  vdda-qrefrx1-0p9-supply: true
> >>>>> +  vdda-qrefrx2-0p9-supply: true
> >>>>> +  vdda-qrefrx4-0p9-supply: true
> >>>>> +  vdda-qrefrx5-0p9-supply: true
> >>>>> +  vdda-qreftx0-0p9-supply: true
> >>>>> +  vdda-qreftx0-1p2-supply: true
> >>>>> +  vdda-qreftx1-0p9-supply: true
> >>>>> +  vdda-qrefrpt0-0p9-supply: true
> >>>>> +  vdda-qrefrpt1-0p9-supply: true
> >>>>> +  vdda-qrefrpt2-0p9-supply: true
> >>>>> +  vdda-qrefrpt3-0p9-supply: true
> >>>>> +  vdda-qrefrpt4-0p9-supply: true
> >>>>
> >>>> Either I do not understand your previous explanation:
> >>>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
> >>>>
> >>>> or this is still wrong. There is no TCSR here, so this proves nothing.
> >>>> If TCSR is TX0, then you do not have five of them...
> >>>>
> >>>> My previous comment stay - you are not describing the actual hardware
> >>>> here.
> >>>>
> >>> The CXO network "-> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 ->" is referred to
> >>> as the QREF block, and each component is controlled by the tcsr_clkref_en
> >>> registers.
> >>
> >> Still no clue what this -> relation is. Again, describe the hardware.
> >>
> >>>
> >>> If a PHY receives its reference clock from QREF, it will have a clkref_en
> >>> register. However, this register may be located in different regions
> >>> depending on the target. On glymur it resides in TCSR, so I added these
> >>> LDOs QREF required in tcsr yaml.
> >> Registers are not described as supplies.
> > 
> > I'm not descirbing register as supply.
> > 
> >     tx0-0p9/1p2  rpt0-0p9   rpt1-0p9    rpt2-0p9    rx2-0p9
> >        |             |           |        |           |
> >        |             |           |        |           |
> > CXO -> TX0 -------> RPT0 ------> RPT1 -> RPT2 -----> RX2 -> PCIe4_PHY
> >        |             |           |        |           |
> >        |             |           |        |           |
> >        ---------------------------------------------------tcsr_clkref_en
> > 
> > These components(TX/RTP/RX) can be disabled/enabled by tcsr_clkref_en
> > register, and they require power supplies.
> 
> So I told you more than once - none of these are supplies to the TCSR.
> You clearly misunderstand what a supply is.
>

The TCSR binding here describes the tcsr_clkref_en clock gate, not the
TCSR register block itself. The clock gate controls whether the reference
clock is forwarded through the QREF chain to the PHY.

The QREF components (TX/RPT/RX) sit between the clock gate and the PHY.
They require LDO supplies to operate, and those supplies must be enabled
before the clock gate is asserted and disabled after it is deasserted.
This enable/disable sequencing is the responsibility of the clock gate
driver, not the PHY driver.

Since the supplies are managed as part of the clock gate operation, they
are modeled as properties of the clock gate node. The node happens to live
in TCSR on glymur, but the supplies describe what the clock gate needs to
do its job, not what TCSR itself needs.

- Qiang Yu

> 
> Best regards,
> Krzysztof

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Manivannan Sadhasivam]

On Mon, May 18, 2026 at 12:26:22AM -0700, Qiang Yu wrote:
> On Mon, May 18, 2026 at 09:00:33AM +0200, Krzysztof Kozlowski wrote:
> > On 18/05/2026 05:50, Qiang Yu wrote:
> > > On Sun, May 17, 2026 at 10:27:39AM +0200, Krzysztof Kozlowski wrote:
> > >> On 17/05/2026 07:39, Qiang Yu wrote:
> > >>> On Thu, May 14, 2026 at 12:22:17PM +0200, Krzysztof Kozlowski wrote:
> > >>>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
> > >>>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
> > >>>>> required by clkref clocks.
> > >>>>>
> > >>>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
> > >>>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
> > >>>>> differ. Document them here for qcom,glymur-tcsr.
> > >>>>>
> > >>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > >>>>> ---
> > >>>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
> > >>>>>  1 file changed, 57 insertions(+)
> > >>>>>
> > >>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > >>>>> index 1ccdf4b0f5dd..57921cb63230 100644
> > >>>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > >>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > >>>>> @@ -51,6 +51,63 @@ properties:
> > >>>>>    '#reset-cells':
> > >>>>>      const: 1
> > >>>>>  
> > >>>>> +  vdda-refgen-0p9-supply: true
> > >>>>> +  vdda-refgen-1p2-supply: true
> > >>>>> +  vdda-qrefrx0-0p9-supply: true
> > >>>>> +  vdda-qrefrx1-0p9-supply: true
> > >>>>> +  vdda-qrefrx2-0p9-supply: true
> > >>>>> +  vdda-qrefrx4-0p9-supply: true
> > >>>>> +  vdda-qrefrx5-0p9-supply: true
> > >>>>> +  vdda-qreftx0-0p9-supply: true
> > >>>>> +  vdda-qreftx0-1p2-supply: true
> > >>>>> +  vdda-qreftx1-0p9-supply: true
> > >>>>> +  vdda-qrefrpt0-0p9-supply: true
> > >>>>> +  vdda-qrefrpt1-0p9-supply: true
> > >>>>> +  vdda-qrefrpt2-0p9-supply: true
> > >>>>> +  vdda-qrefrpt3-0p9-supply: true
> > >>>>> +  vdda-qrefrpt4-0p9-supply: true
> > >>>>
> > >>>> Either I do not understand your previous explanation:
> > >>>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
> > >>>>
> > >>>> or this is still wrong. There is no TCSR here, so this proves nothing.
> > >>>> If TCSR is TX0, then you do not have five of them...
> > >>>>
> > >>>> My previous comment stay - you are not describing the actual hardware
> > >>>> here.
> > >>>>
> > >>> The CXO network "-> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 ->" is referred to
> > >>> as the QREF block, and each component is controlled by the tcsr_clkref_en
> > >>> registers.
> > >>
> > >> Still no clue what this -> relation is. Again, describe the hardware.
> > >>
> > >>>
> > >>> If a PHY receives its reference clock from QREF, it will have a clkref_en
> > >>> register. However, this register may be located in different regions
> > >>> depending on the target. On glymur it resides in TCSR, so I added these
> > >>> LDOs QREF required in tcsr yaml.
> > >> Registers are not described as supplies.
> > > 
> > > I'm not descirbing register as supply.
> > > 
> > >     tx0-0p9/1p2  rpt0-0p9   rpt1-0p9    rpt2-0p9    rx2-0p9
> > >        |             |           |        |           |
> > >        |             |           |        |           |
> > > CXO -> TX0 -------> RPT0 ------> RPT1 -> RPT2 -----> RX2 -> PCIe4_PHY
> > >        |             |           |        |           |
> > >        |             |           |        |           |
> > >        ---------------------------------------------------tcsr_clkref_en
> > > 
> > > These components(TX/RTP/RX) can be disabled/enabled by tcsr_clkref_en
> > > register, and they require power supplies.
> > 
> > So I told you more than once - none of these are supplies to the TCSR.
> > You clearly misunderstand what a supply is.
> >
> 
> The TCSR binding here describes the tcsr_clkref_en clock gate, not the
> TCSR register block itself. The clock gate controls whether the reference
> clock is forwarded through the QREF chain to the PHY.
> 
> The QREF components (TX/RPT/RX) sit between the clock gate and the PHY.
> They require LDO supplies to operate, and those supplies must be enabled
> before the clock gate is asserted and disabled after it is deasserted.
> This enable/disable sequencing is the responsibility of the clock gate
> driver, not the PHY driver.
> 
> Since the supplies are managed as part of the clock gate operation, they
> are modeled as properties of the clock gate node. The node happens to live
> in TCSR on glymur, but the supplies describe what the clock gate needs to
> do its job, not what TCSR itself needs.
> 

Just to add a bit more context:

The QREF block supplies the reference clock to the PHY IPs. But the digital
logic (register interface) to control this QREF block lives inside TCSR in some
SoCs like Glymur. But AFAIK, the analog QREF circuitry is not inside TCSR, but
somewhere near to PHYs.

Also, QREF needs its own LDOs to operate and supply reference clocks to PHYs.
Initially, we tried to add these QREF supplies to PHY node itself. But that was
pushed back by Johan [1]. His argument was that since these LDOs power QREFs,
not the PHY IPs, these supplies should not be added to the PHY nodes. And since
we do not have a dedicated QREF DT node due to the fact that the QREF registers
gets moved between various IPs based on the available space in the RTL. (It used
to live in GCC, but now it is in TCSR and in the future it could be in some
other IPs. Unfortunately, we cannot control this design)

So he suggested to add these supplies to TCSR node which acts as a control
interface to QREF, even though it is not an accurate hw representation either.

And this patchset is based on that feedback only.

But your argument is also valid that these supplies are not supplying the TCSR
block in hw, but just the QREF analog circuitry living close to PHY.

We are open to suggestions here as we do not know what is the accurate hardware
description for these supplies/QREF.

- Mani

[1] https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur

[Krzysztof Kozlowski]

On 19/05/2026 13:25, Manivannan Sadhasivam wrote:
> On Mon, May 18, 2026 at 12:26:22AM -0700, Qiang Yu wrote:
>> On Mon, May 18, 2026 at 09:00:33AM +0200, Krzysztof Kozlowski wrote:
>>> On 18/05/2026 05:50, Qiang Yu wrote:
>>>> On Sun, May 17, 2026 at 10:27:39AM +0200, Krzysztof Kozlowski wrote:
>>>>> On 17/05/2026 07:39, Qiang Yu wrote:
>>>>>> On Thu, May 14, 2026 at 12:22:17PM +0200, Krzysztof Kozlowski wrote:
>>>>>>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
>>>>>>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
>>>>>>>> required by clkref clocks.
>>>>>>>>
>>>>>>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
>>>>>>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
>>>>>>>> differ. Document them here for qcom,glymur-tcsr.
>>>>>>>>
>>>>>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>>  .../bindings/clock/qcom,sm8550-tcsr.yaml           | 57 ++++++++++++++++++++++
>>>>>>>>  1 file changed, 57 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>>>> index 1ccdf4b0f5dd..57921cb63230 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>>>> @@ -51,6 +51,63 @@ properties:
>>>>>>>>    '#reset-cells':
>>>>>>>>      const: 1
>>>>>>>>  
>>>>>>>> +  vdda-refgen-0p9-supply: true
>>>>>>>> +  vdda-refgen-1p2-supply: true
>>>>>>>> +  vdda-qrefrx0-0p9-supply: true
>>>>>>>> +  vdda-qrefrx1-0p9-supply: true
>>>>>>>> +  vdda-qrefrx2-0p9-supply: true
>>>>>>>> +  vdda-qrefrx4-0p9-supply: true
>>>>>>>> +  vdda-qrefrx5-0p9-supply: true
>>>>>>>> +  vdda-qreftx0-0p9-supply: true
>>>>>>>> +  vdda-qreftx0-1p2-supply: true
>>>>>>>> +  vdda-qreftx1-0p9-supply: true
>>>>>>>> +  vdda-qrefrpt0-0p9-supply: true
>>>>>>>> +  vdda-qrefrpt1-0p9-supply: true
>>>>>>>> +  vdda-qrefrpt2-0p9-supply: true
>>>>>>>> +  vdda-qrefrpt3-0p9-supply: true
>>>>>>>> +  vdda-qrefrpt4-0p9-supply: true
>>>>>>>
>>>>>>> Either I do not understand your previous explanation:
>>>>>>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
>>>>>>>
>>>>>>> or this is still wrong. There is no TCSR here, so this proves nothing.
>>>>>>> If TCSR is TX0, then you do not have five of them...
>>>>>>>
>>>>>>> My previous comment stay - you are not describing the actual hardware
>>>>>>> here.
>>>>>>>
>>>>>> The CXO network "-> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 ->" is referred to
>>>>>> as the QREF block, and each component is controlled by the tcsr_clkref_en
>>>>>> registers.
>>>>>
>>>>> Still no clue what this -> relation is. Again, describe the hardware.
>>>>>
>>>>>>
>>>>>> If a PHY receives its reference clock from QREF, it will have a clkref_en
>>>>>> register. However, this register may be located in different regions
>>>>>> depending on the target. On glymur it resides in TCSR, so I added these
>>>>>> LDOs QREF required in tcsr yaml.
>>>>> Registers are not described as supplies.
>>>>
>>>> I'm not descirbing register as supply.
>>>>
>>>>     tx0-0p9/1p2  rpt0-0p9   rpt1-0p9    rpt2-0p9    rx2-0p9
>>>>        |             |           |        |           |
>>>>        |             |           |        |           |
>>>> CXO -> TX0 -------> RPT0 ------> RPT1 -> RPT2 -----> RX2 -> PCIe4_PHY
>>>>        |             |           |        |           |
>>>>        |             |           |        |           |
>>>>        ---------------------------------------------------tcsr_clkref_en
>>>>
>>>> These components(TX/RTP/RX) can be disabled/enabled by tcsr_clkref_en
>>>> register, and they require power supplies.
>>>
>>> So I told you more than once - none of these are supplies to the TCSR.
>>> You clearly misunderstand what a supply is.
>>>
>>
>> The TCSR binding here describes the tcsr_clkref_en clock gate, not the
>> TCSR register block itself. The clock gate controls whether the reference
>> clock is forwarded through the QREF chain to the PHY.
>>
>> The QREF components (TX/RPT/RX) sit between the clock gate and the PHY.
>> They require LDO supplies to operate, and those supplies must be enabled
>> before the clock gate is asserted and disabled after it is deasserted.
>> This enable/disable sequencing is the responsibility of the clock gate
>> driver, not the PHY driver.
>>
>> Since the supplies are managed as part of the clock gate operation, they
>> are modeled as properties of the clock gate node. The node happens to live
>> in TCSR on glymur, but the supplies describe what the clock gate needs to
>> do its job, not what TCSR itself needs.
>>
> 
> Just to add a bit more context:
> 
> The QREF block supplies the reference clock to the PHY IPs. But the digital
> logic (register interface) to control this QREF block lives inside TCSR in some
> SoCs like Glymur. But AFAIK, the analog QREF circuitry is not inside TCSR, but
> somewhere near to PHYs.
> 
> Also, QREF needs its own LDOs to operate and supply reference clocks to PHYs.
> Initially, we tried to add these QREF supplies to PHY node itself. But that was
> pushed back by Johan [1]. His argument was that since these LDOs power QREFs,
> not the PHY IPs, these supplies should not be added to the PHY nodes. And since
> we do not have a dedicated QREF DT node due to the fact that the QREF registers
> gets moved between various IPs based on the available space in the RTL. (It used
> to live in GCC, but now it is in TCSR and in the future it could be in some
> other IPs. Unfortunately, we cannot control this design)
> 
> So he suggested to add these supplies to TCSR node which acts as a control
> interface to QREF, even though it is not an accurate hw representation either.
> 
> And this patchset is based on that feedback only.
> 
> But your argument is also valid that these supplies are not supplying the TCSR
> block in hw, but just the QREF analog circuitry living close to PHY.
> 
> We are open to suggestions here as we do not know what is the accurate hardware
> description for these supplies/QREF.

As I understood these are real supplies to QREF which on these SoCs is
part of TCSR, so in general it is fine. Should be in its own binding
file, though.

Best regards,
Krzysztof

[PATCH v3 2/4] clk: qcom: Add generic clkref_en support

[Qiang Yu]

Before XO refclk is distributed to PCIe/USB/eDP PHYs, it passes through
a QREF block. QREF is powered by dedicated LDO rails, and the clkref_en
register controls whether refclk is gated through to the PHY side.

These clkref controls are different from typical GCC branch clocks:
- only a single enable bit is present, without branch-style config bits
- regulators must be voted before enable and unvoted after disable

Model this as a dedicated clk_ref clock type with custom clk_ops instead
of reusing struct clk_branch semantics.

Also provide a common registration/probe API so the same clkref model
can be reused regardless of where clkref_en registers are placed, e.g.
TCSR on glymur and TLMM on SM8750.

Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
 drivers/clk/qcom/Makefile  |   1 +
 drivers/clk/qcom/clk-ref.c | 202 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/qcom.h   |  69 ++++++++++++++++
 3 files changed, 272 insertions(+)

diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 89d07c35e4d9..1659e9d9afa9 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -8,6 +8,7 @@ clk-qcom-y += clk-pll.o
 clk-qcom-y += clk-rcg.o
 clk-qcom-y += clk-rcg2.o
 clk-qcom-y += clk-branch.o
+clk-qcom-y += clk-ref.o
 clk-qcom-y += clk-regmap-divider.o
 clk-qcom-y += clk-regmap-mux.o
 clk-qcom-y += clk-regmap-mux-div.o
diff --git a/drivers/clk/qcom/clk-ref.c b/drivers/clk/qcom/clk-ref.c
new file mode 100644
index 000000000000..ea2ed03460f2
--- /dev/null
+++ b/drivers/clk/qcom/clk-ref.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2026, Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clk/qcom.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+#define QCOM_CLK_REF_EN_MASK BIT(0)
+
+struct qcom_clk_ref_provider {
+	struct qcom_clk_ref *refs;
+	size_t num_refs;
+};
+
+static inline struct qcom_clk_ref *to_qcom_clk_ref(struct clk_hw *hw)
+{
+	return container_of(hw, struct qcom_clk_ref, hw);
+}
+
+static const struct clk_parent_data qcom_clk_ref_parent_data = {
+	.index = 0,
+};
+
+static int qcom_clk_ref_prepare(struct clk_hw *hw)
+{
+	struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+	int ret;
+
+	if (!rclk->desc.num_regulators)
+		return 0;
+
+	ret = regulator_bulk_enable(rclk->desc.num_regulators, rclk->regulators);
+	if (ret)
+		pr_err("Failed to enable regulators for %s: %d\n",
+		       clk_hw_get_name(hw), ret);
+
+	return ret;
+}
+
+static void qcom_clk_ref_unprepare(struct clk_hw *hw)
+{
+	struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+
+	if (rclk->desc.num_regulators)
+		regulator_bulk_disable(rclk->desc.num_regulators, rclk->regulators);
+}
+
+static int qcom_clk_ref_enable(struct clk_hw *hw)
+{
+	struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+	int ret;
+
+	ret = regmap_update_bits(rclk->regmap, rclk->desc.offset, QCOM_CLK_REF_EN_MASK,
+				 QCOM_CLK_REF_EN_MASK);
+	if (ret)
+		return ret;
+
+	udelay(10);
+
+	return 0;
+}
+
+static void qcom_clk_ref_disable(struct clk_hw *hw)
+{
+	struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+
+	regmap_update_bits(rclk->regmap, rclk->desc.offset, QCOM_CLK_REF_EN_MASK, 0);
+	udelay(10);
+}
+
+static int qcom_clk_ref_is_enabled(struct clk_hw *hw)
+{
+	struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+	u32 val;
+	int ret;
+
+	ret = regmap_read(rclk->regmap, rclk->desc.offset, &val);
+	if (ret)
+		return ret;
+
+	return !!(val & QCOM_CLK_REF_EN_MASK);
+}
+
+static const struct clk_ops qcom_clk_ref_ops = {
+	.prepare = qcom_clk_ref_prepare,
+	.unprepare = qcom_clk_ref_unprepare,
+	.enable = qcom_clk_ref_enable,
+	.disable = qcom_clk_ref_disable,
+	.is_enabled = qcom_clk_ref_is_enabled,
+};
+
+static int qcom_clk_ref_register(struct device *dev, struct regmap *regmap,
+				 struct qcom_clk_ref *clk_refs,
+				 const struct qcom_clk_ref_desc *descs,
+				 size_t num_clk_refs)
+{
+	const struct qcom_clk_ref_desc *desc;
+	struct qcom_clk_ref *clk_ref;
+	size_t clk_idx;
+	unsigned int i;
+	int ret;
+
+	for (clk_idx = 0; clk_idx < num_clk_refs; clk_idx++) {
+		clk_ref = &clk_refs[clk_idx];
+		desc = &descs[clk_idx];
+
+		if (!desc->name)
+			return -EINVAL;
+
+		clk_ref->regmap = regmap;
+		clk_ref->desc = *desc;
+
+		if (clk_ref->desc.num_regulators) {
+			clk_ref->regulators = devm_kcalloc(dev, clk_ref->desc.num_regulators,
+							   sizeof(*clk_ref->regulators),
+							   GFP_KERNEL);
+			if (!clk_ref->regulators)
+				return -ENOMEM;
+
+			for (i = 0; i < clk_ref->desc.num_regulators; i++)
+				clk_ref->regulators[i].supply =
+					clk_ref->desc.regulator_names[i];
+
+			ret = devm_regulator_bulk_get(dev, clk_ref->desc.num_regulators,
+						      clk_ref->regulators);
+			if (ret)
+				return dev_err_probe(dev, ret,
+						     "Failed to get regulators for %s\n",
+						     clk_ref->desc.name);
+		}
+
+		clk_ref->init_data.name = clk_ref->desc.name;
+		clk_ref->init_data.parent_data = &qcom_clk_ref_parent_data;
+		clk_ref->init_data.num_parents = 1;
+		clk_ref->init_data.ops = &qcom_clk_ref_ops;
+		clk_ref->hw.init = &clk_ref->init_data;
+
+		ret = devm_clk_hw_register(dev, &clk_ref->hw);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static struct clk_hw *qcom_clk_ref_provider_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct qcom_clk_ref_provider *provider = data;
+	unsigned int idx = clkspec->args[0];
+
+	if (idx >= provider->num_refs)
+		return ERR_PTR(-EINVAL);
+
+	return &provider->refs[idx].hw;
+}
+
+int qcom_clk_ref_probe(struct platform_device *pdev,
+		       const struct regmap_config *config,
+		       const struct qcom_clk_ref_desc *descs,
+		       size_t num_clk_refs)
+{
+	struct qcom_clk_ref_provider *provider;
+	struct device *dev = &pdev->dev;
+	struct regmap *regmap;
+	void __iomem *base;
+	int ret;
+
+	base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	regmap = devm_regmap_init_mmio(dev, base, config);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
+	if (!provider)
+		return -ENOMEM;
+
+	provider->refs = devm_kcalloc(dev, num_clk_refs, sizeof(*provider->refs),
+				      GFP_KERNEL);
+	if (!provider->refs)
+		return -ENOMEM;
+
+	provider->num_refs = num_clk_refs;
+
+	ret = qcom_clk_ref_register(dev, regmap, provider->refs, descs,
+				    provider->num_refs);
+	if (ret)
+		return ret;
+
+	return devm_of_clk_add_hw_provider(dev, qcom_clk_ref_provider_get, provider);
+}
+EXPORT_SYMBOL_GPL(qcom_clk_ref_probe);
diff --git a/include/linux/clk/qcom.h b/include/linux/clk/qcom.h
new file mode 100644
index 000000000000..09e2e3178cfb
--- /dev/null
+++ b/include/linux/clk/qcom.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026, Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef __LINUX_CLK_QCOM_H
+#define __LINUX_CLK_QCOM_H
+
+#include <linux/clk-provider.h>
+#include <linux/errno.h>
+#include <linux/kconfig.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+struct device;
+struct platform_device;
+struct regulator_bulk_data;
+
+/**
+ * struct qcom_clk_ref_desc - descriptor for a clkref_en gate clock
+ * @name: clock name exposed to the common clock framework
+ * @offset: clkref_en register offset from the block base
+ * @regulator_names: optional supply names enabled while preparing the clock
+ * @num_regulators: number of entries in @regulator_names
+ */
+struct qcom_clk_ref_desc {
+	const char *name;
+	u32 offset;
+	const char * const *regulator_names;
+	unsigned int num_regulators;
+};
+
+/**
+ * struct qcom_clk_ref - per-clock data for a clkref_en gate clock
+ * @hw: common clock framework hardware clock handle
+ * @init_data: common clock framework registration data
+ * @regmap: register map backing the clkref_en register
+ * @desc: clock descriptor copied at registration time
+ * @regulators: optional bulk regulator handles for @desc.regulator_names
+ */
+struct qcom_clk_ref {
+	struct clk_hw hw;
+	struct clk_init_data init_data;
+	struct regmap *regmap;
+	struct qcom_clk_ref_desc desc;
+	struct regulator_bulk_data *regulators;
+};
+
+#if IS_ENABLED(CONFIG_COMMON_CLK_QCOM)
+
+int qcom_clk_ref_probe(struct platform_device *pdev,
+		       const struct regmap_config *config,
+		       const struct qcom_clk_ref_desc *descs,
+		       size_t num_clk_refs);
+
+#else
+
+static inline int
+qcom_clk_ref_probe(struct platform_device *pdev,
+		   const struct regmap_config *config,
+		   const struct qcom_clk_ref_desc *descs,
+		   size_t num_clk_refs)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif
+
+#endif

-- 
2.34.1

[PATCH v3 3/4] clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper

[Qiang Yu]

Replace local clk_branch-based clkref definitions with descriptor-based
registration via qcom_clk_ref_probe().

This keeps the glymur driver focused on clock metadata and reuses common
runtime logic for regulator handling, enable/disable sequencing, and OF
provider wiring.

Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
 drivers/clk/qcom/tcsrcc-glymur.c | 340 +++++++++++----------------------------
 1 file changed, 93 insertions(+), 247 deletions(-)

diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
index 9c0edebcdbb1..585f87b23af2 100644
--- a/drivers/clk/qcom/tcsrcc-glymur.c
+++ b/drivers/clk/qcom/tcsrcc-glymur.c
@@ -4,265 +4,115 @@
  */
 
 #include <linux/clk-provider.h>
+#include <linux/clk/qcom.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
 
 #include <dt-bindings/clock/qcom,glymur-tcsr.h>
 
-#include "clk-alpha-pll.h"
-#include "clk-branch.h"
-#include "clk-pll.h"
-#include "clk-rcg.h"
-#include "clk-regmap.h"
-#include "clk-regmap-divider.h"
-#include "clk-regmap-mux.h"
-#include "common.h"
-#include "gdsc.h"
-#include "reset.h"
-
-enum {
-	DT_BI_TCXO_PAD,
-};
-
-static struct clk_branch tcsr_edp_clkref_en = {
-	.halt_reg = 0x60,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x60,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_edp_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+static const char * const tcsr_pcie_1_regulators[] = {
+	"vdda-refgen-0p9",
+	"vdda-refgen-1p2",
+	"vdda-qrefrx5-0p9",
+	"vdda-qreftx0-0p9",
+	"vdda-qreftx0-1p2",
+};
+
+static const char * const tcsr_pcie_2_regulators[] = {
+	"vdda-refgen-0p9",
+	"vdda-refgen-1p2",
+	"vdda-qreftx1-0p9",
+	"vdda-qrefrpt0-0p9",
+	"vdda-qrefrpt1-0p9",
+	"vdda-qrefrpt2-0p9",
+	"vdda-qrefrx2-0p9",
+};
+
+static const char * const tcsr_pcie_3_regulators[] = {
+	"vdda-refgen-0p9",
+	"vdda-refgen-1p2",
+	"vdda-qreftx1-0p9",
+	"vdda-qrefrpt0-0p9",
+	"vdda-qrefrpt1-0p9",
+	"vdda-qrefrx1-0p9",
+};
+
+static const char * const tcsr_pcie_4_regulators[] = {
+	"vdda-refgen-0p9",
+	"vdda-refgen-1p2",
+	"vdda-qreftx1-0p9",
+	"vdda-qrefrpt0-0p9",
+	"vdda-qrefrpt1-0p9",
+	"vdda-qrefrpt2-0p9",
+	"vdda-qrefrx2-0p9",
+};
+
+static const struct qcom_clk_ref_desc tcsr_cc_glymur_clk_descs[] = {
+	[TCSR_EDP_CLKREF_EN] = {
+		.name = "tcsr_edp_clkref_en",
+		.offset = 0x60,
 	},
-};
-
-static struct clk_branch tcsr_pcie_1_clkref_en = {
-	.halt_reg = 0x48,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x48,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_pcie_1_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_PCIE_1_CLKREF_EN] = {
+		.name = "tcsr_pcie_1_clkref_en",
+		.offset = 0x48,
+		.regulator_names = tcsr_pcie_1_regulators,
+		.num_regulators = ARRAY_SIZE(tcsr_pcie_1_regulators),
 	},
-};
-
-static struct clk_branch tcsr_pcie_2_clkref_en = {
-	.halt_reg = 0x4c,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x4c,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_pcie_2_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_PCIE_2_CLKREF_EN] = {
+		.name = "tcsr_pcie_2_clkref_en",
+		.offset = 0x4c,
+		.regulator_names = tcsr_pcie_2_regulators,
+		.num_regulators = ARRAY_SIZE(tcsr_pcie_2_regulators),
 	},
-};
-
-static struct clk_branch tcsr_pcie_3_clkref_en = {
-	.halt_reg = 0x54,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x54,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_pcie_3_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_PCIE_3_CLKREF_EN] = {
+		.name = "tcsr_pcie_3_clkref_en",
+		.offset = 0x54,
+		.regulator_names = tcsr_pcie_3_regulators,
+		.num_regulators = ARRAY_SIZE(tcsr_pcie_3_regulators),
 	},
-};
-
-static struct clk_branch tcsr_pcie_4_clkref_en = {
-	.halt_reg = 0x58,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x58,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_pcie_4_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_PCIE_4_CLKREF_EN] = {
+		.name = "tcsr_pcie_4_clkref_en",
+		.offset = 0x58,
+		.regulator_names = tcsr_pcie_4_regulators,
+		.num_regulators = ARRAY_SIZE(tcsr_pcie_4_regulators),
 	},
-};
-
-static struct clk_branch tcsr_usb2_1_clkref_en = {
-	.halt_reg = 0x6c,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x6c,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_usb2_1_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_USB2_1_CLKREF_EN] = {
+		.name = "tcsr_usb2_1_clkref_en",
+		.offset = 0x6c,
 	},
-};
-
-static struct clk_branch tcsr_usb2_2_clkref_en = {
-	.halt_reg = 0x70,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x70,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_usb2_2_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_USB2_2_CLKREF_EN] = {
+		.name = "tcsr_usb2_2_clkref_en",
+		.offset = 0x70,
 	},
-};
-
-static struct clk_branch tcsr_usb2_3_clkref_en = {
-	.halt_reg = 0x74,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x74,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_usb2_3_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_USB2_3_CLKREF_EN] = {
+		.name = "tcsr_usb2_3_clkref_en",
+		.offset = 0x74,
 	},
-};
-
-static struct clk_branch tcsr_usb2_4_clkref_en = {
-	.halt_reg = 0x88,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x88,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_usb2_4_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_USB2_4_CLKREF_EN] = {
+		.name = "tcsr_usb2_4_clkref_en",
+		.offset = 0x88,
 	},
-};
-
-static struct clk_branch tcsr_usb3_0_clkref_en = {
-	.halt_reg = 0x64,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x64,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_usb3_0_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_USB3_0_CLKREF_EN] = {
+		.name = "tcsr_usb3_0_clkref_en",
+		.offset = 0x64,
 	},
-};
-
-static struct clk_branch tcsr_usb3_1_clkref_en = {
-	.halt_reg = 0x68,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x68,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_usb3_1_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_USB3_1_CLKREF_EN] = {
+		.name = "tcsr_usb3_1_clkref_en",
+		.offset = 0x68,
 	},
-};
-
-static struct clk_branch tcsr_usb4_1_clkref_en = {
-	.halt_reg = 0x44,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x44,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_usb4_1_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_USB4_1_CLKREF_EN] = {
+		.name = "tcsr_usb4_1_clkref_en",
+		.offset = 0x44,
 	},
-};
-
-static struct clk_branch tcsr_usb4_2_clkref_en = {
-	.halt_reg = 0x5c,
-	.halt_check = BRANCH_HALT_DELAY,
-	.clkr = {
-		.enable_reg = 0x5c,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "tcsr_usb4_2_clkref_en",
-			.parent_data = &(const struct clk_parent_data){
-				.index = DT_BI_TCXO_PAD,
-			},
-			.num_parents = 1,
-			.ops = &clk_branch2_ops,
-		},
+	[TCSR_USB4_2_CLKREF_EN] = {
+		.name = "tcsr_usb4_2_clkref_en",
+		.offset = 0x5c,
 	},
 };
 
-static struct clk_regmap *tcsr_cc_glymur_clocks[] = {
-	[TCSR_EDP_CLKREF_EN] = &tcsr_edp_clkref_en.clkr,
-	[TCSR_PCIE_1_CLKREF_EN] = &tcsr_pcie_1_clkref_en.clkr,
-	[TCSR_PCIE_2_CLKREF_EN] = &tcsr_pcie_2_clkref_en.clkr,
-	[TCSR_PCIE_3_CLKREF_EN] = &tcsr_pcie_3_clkref_en.clkr,
-	[TCSR_PCIE_4_CLKREF_EN] = &tcsr_pcie_4_clkref_en.clkr,
-	[TCSR_USB2_1_CLKREF_EN] = &tcsr_usb2_1_clkref_en.clkr,
-	[TCSR_USB2_2_CLKREF_EN] = &tcsr_usb2_2_clkref_en.clkr,
-	[TCSR_USB2_3_CLKREF_EN] = &tcsr_usb2_3_clkref_en.clkr,
-	[TCSR_USB2_4_CLKREF_EN] = &tcsr_usb2_4_clkref_en.clkr,
-	[TCSR_USB3_0_CLKREF_EN] = &tcsr_usb3_0_clkref_en.clkr,
-	[TCSR_USB3_1_CLKREF_EN] = &tcsr_usb3_1_clkref_en.clkr,
-	[TCSR_USB4_1_CLKREF_EN] = &tcsr_usb4_1_clkref_en.clkr,
-	[TCSR_USB4_2_CLKREF_EN] = &tcsr_usb4_2_clkref_en.clkr,
-};
-
 static const struct regmap_config tcsr_cc_glymur_regmap_config = {
 	.reg_bits = 32,
 	.reg_stride = 4,
@@ -271,11 +121,12 @@ static const struct regmap_config tcsr_cc_glymur_regmap_config = {
 	.fast_io = true,
 };
 
-static const struct qcom_cc_desc tcsr_cc_glymur_desc = {
-	.config = &tcsr_cc_glymur_regmap_config,
-	.clks = tcsr_cc_glymur_clocks,
-	.num_clks = ARRAY_SIZE(tcsr_cc_glymur_clocks),
-};
+static int tcsr_cc_glymur_probe(struct platform_device *pdev)
+{
+	return qcom_clk_ref_probe(pdev, &tcsr_cc_glymur_regmap_config,
+				  tcsr_cc_glymur_clk_descs,
+				  ARRAY_SIZE(tcsr_cc_glymur_clk_descs));
+}
 
 static const struct of_device_id tcsr_cc_glymur_match_table[] = {
 	{ .compatible = "qcom,glymur-tcsr" },
@@ -283,11 +134,6 @@ static const struct of_device_id tcsr_cc_glymur_match_table[] = {
 };
 MODULE_DEVICE_TABLE(of, tcsr_cc_glymur_match_table);
 
-static int tcsr_cc_glymur_probe(struct platform_device *pdev)
-{
-	return qcom_cc_probe(pdev, &tcsr_cc_glymur_desc);
-}
-
 static struct platform_driver tcsr_cc_glymur_driver = {
 	.probe = tcsr_cc_glymur_probe,
 	.driver = {

-- 
2.34.1

[PATCH v3 4/4] arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR

[Qiang Yu]

The TCSR clkref clocks gate the QREF block which provides reference
clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF
and refgen blocks on the CRD board:

- vdda-refgen_0p9/1p2: LDOs for the refgen block that generates the
  reference voltage for QREF
- vdda-qrefrx/tx/rpt: LDOs for the QREF receiver, transmitter
  and repeater circuits

Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur-crd.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
index 35aaf09e4e2b..382398e44296 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
@@ -358,6 +358,25 @@ &usb_1 {
 	status = "okay";
 };
 
+&tcsr {
+	vdda-refgen-0p9-supply = <&vreg_l1f_e1_0p82>;
+	vdda-refgen-1p2-supply = <&vreg_l4f_e1_1p08>;
+
+	vdda-qrefrx5-0p9-supply = <&vreg_l3f_e0_0p72>;
+	vdda-qreftx0-0p9-supply = <&vreg_l3f_e0_0p72>;
+	vdda-qreftx0-1p2-supply = <&vreg_l4h_e0_1p2>;
+	vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
+	vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
+	vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
+	vdda-qrefrpt3-0p9-supply = <&vreg_l2h_e0_0p72>;
+	vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
+	vdda-qrefrx0-0p9-supply = <&vreg_l2f_e1_0p83>;
+	vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
+	vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
+	vdda-qrefrx4-0p9-supply = <&vreg_l2h_e0_0p72>;
+	vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
+};
+
 &usb_1_dwc3_hs {
 	remote-endpoint = <&pmic_glink_hs_in1>;
 };

-- 
2.34.1