>From the RK3588 Technical Reference Manual, Part1,
section 6.19 PCIe3PHY_GRF Register Description: "ref_use_pad"

"Select reference clock connected to ref_pad_clk_p/ref_pad_clk_m.
Selects the external ref_pad_clk_p and ref_pad_clk_m inputs as the
reference clock source when asserted. When de-asserted, ref_alt_clk_p
and ref_alt_clk_m are the sources of the reference clock."

The hardware reset value for this field is 0x1 (enabled).
Note that this register field is only available on RK3588, not on RK3568.

Add support for the device tree property rockchip,phy-ref-use-pad,
such that the PCIe PHY can be used on boards where there is no PCIe
reference clock generated or connected to the external pad, by setting
this property to 0 so that the internal clock is used.

DT bindings for internal clocks are CLK_PHY0_REF_ALT_P/M and
CLK_PHY1_REF_ALT_P/M and clock rate should be set to 100MHz in
the RK3588 cru clock controller (PLL_PPLL).

Example DT overlay where PHY0 uses internal clock (the first clock of
the cru (PLL_PPLL) must be set to 100MHz, other values are copied from
rk3588-base.dtsi) and PHY1 uses the external pad (the default):

---
&cru {
        assigned-clock-rates =
                <100000000>, <786432000>,
                <850000000>, <1188000000>,
                <702000000>,
                <400000000>, <500000000>,
                <800000000>, <100000000>,
                <400000000>, <100000000>,
                <200000000>, <500000000>,
                <375000000>, <150000000>,
                <200000000>;
};

&pcie30phy {
        rockchip,rx-common-refclk-mode = <0 0 1 1>;
        rockchip,phy-ref-use-pad = <0 1>;
        clocks = <&cru PCLK_PCIE_COMBO_PIPE_PHY>, <&cru CLK_PHY0_REF_ALT_P>,
                         <&cru CLK_PHY0_REF_ALT_M>, <&cru CLK_PHY1_REF_ALT_P>,
                         <&cru CLK_PHY1_REF_ALT_M>;
        clock-names = "pclk", "phy0_ref_alt_p",
                              "phy0_ref_alt_m", "phy1_ref_alt_p",
                              "phy1_ref_alt_m";
};
---

Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com>
---
 .../devicetree/bindings/phy/rockchip,pcie3-phy.yaml    | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml
index b747930b18f1..d9b9d7eabb81 100644
--- a/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml
@@ -67,6 +67,16 @@ properties:
       minimum: 0
       maximum: 1
 
+  rockchip,phy-ref-use-pad:
+    description: which PHY should use the external pad as PCIe reference clock.
+      1 means use pad (default), 0 means use internal clock (PLL_PPLL).
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 2
+    maxItems: 2
+    items:
+      minimum: 0
+      maximum: 1
+
 required:
   - compatible
   - reg
-- 
2.25.1

On Wed, Aug 06, 2025 at 03:38:23PM +0200, Rick Wertenbroek wrote:
> >From the RK3588 Technical Reference Manual, Part1,
> section 6.19 PCIe3PHY_GRF Register Description: "ref_use_pad"
> 
> "Select reference clock connected to ref_pad_clk_p/ref_pad_clk_m.
> Selects the external ref_pad_clk_p and ref_pad_clk_m inputs as the
> reference clock source when asserted. When de-asserted, ref_alt_clk_p
> and ref_alt_clk_m are the sources of the reference clock."
> 
> The hardware reset value for this field is 0x1 (enabled).
> Note that this register field is only available on RK3588, not on RK3568.

Then you miss restricting it (:false) in one of if:then: blocks.

Also, binding cannot be after the user. You need to reorder patches.

...

>  
> +  rockchip,phy-ref-use-pad:
> +    description: which PHY should use the external pad as PCIe reference clock.
> +      1 means use pad (default), 0 means use internal clock (PLL_PPLL).

Can't you deduce it from the presence of clock inputs? IOW, if the
clocks are physically connected, is it even reasonable or possible to
use internal clock?

> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 2
> +    maxItems: 2
> +    items:
> +      minimum: 0
> +      maximum: 1

More precise:

items:
  - description: PHY0 reference clock config
  - description: PHY1 reference clock config
  enum: [ 0, 1 ]
default: [ 1, 1 ]

Anyway, default 1, 1 is pretty non-obvious, so this should be just
non-unique-string-array (and property should be like
rockchip,phy-ref-clk-source/sel).


Best regards,
Krzysztof

On 07/08/2025 09:54, Krzysztof Kozlowski wrote:
> On Wed, Aug 06, 2025 at 03:38:23PM +0200, Rick Wertenbroek wrote:
>> >From the RK3588 Technical Reference Manual, Part1,
>> section 6.19 PCIe3PHY_GRF Register Description: "ref_use_pad"
>>
>> "Select reference clock connected to ref_pad_clk_p/ref_pad_clk_m.
>> Selects the external ref_pad_clk_p and ref_pad_clk_m inputs as the
>> reference clock source when asserted. When de-asserted, ref_alt_clk_p
>> and ref_alt_clk_m are the sources of the reference clock."
>>
>> The hardware reset value for this field is 0x1 (enabled).
>> Note that this register field is only available on RK3588, not on RK3568.
> 
> Then you miss restricting it (:false) in one of if:then: blocks.
> 
> Also, binding cannot be after the user. You need to reorder patches.
> 
> ...
> 
>>  
>> +  rockchip,phy-ref-use-pad:
>> +    description: which PHY should use the external pad as PCIe reference clock.
>> +      1 means use pad (default), 0 means use internal clock (PLL_PPLL).
> 
> Can't you deduce it from the presence of clock inputs? IOW, if the
> clocks are physically connected, is it even reasonable or possible to
> use internal clock?
> 
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    minItems: 2
>> +    maxItems: 2
>> +    items:
>> +      minimum: 0
>> +      maximum: 1
> 
> More precise:
> 
> items:
>   - description: PHY0 reference clock config
>   - description: PHY1 reference clock config
>   enum: [ 0, 1 ]

Eh, no, rather if this stays as int:

    items:
      - description: PHY0 reference clock config
        enum: [ 0, 1 ]
      - description: PHY1 reference clock config
        enum: [ 0, 1 ]
    default: [ 1, 1 ]


> default: [ 1, 1 ]
> 
> Anyway, default 1, 1 is pretty non-obvious, so this should be just
> non-unique-string-array (and property should be like
> rockchip,phy-ref-clk-source/sel).
> 
> 
> Best regards,
> Krzysztof
> 


Best regards,
Krzysztof

On Thu, Aug 7, 2025 at 9:55 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 07/08/2025 09:54, Krzysztof Kozlowski wrote:
> > On Wed, Aug 06, 2025 at 03:38:23PM +0200, Rick Wertenbroek wrote:
> >> >From the RK3588 Technical Reference Manual, Part1,
> >> section 6.19 PCIe3PHY_GRF Register Description: "ref_use_pad"
> >>
> >> "Select reference clock connected to ref_pad_clk_p/ref_pad_clk_m.
> >> Selects the external ref_pad_clk_p and ref_pad_clk_m inputs as the
> >> reference clock source when asserted. When de-asserted, ref_alt_clk_p
> >> and ref_alt_clk_m are the sources of the reference clock."
> >>
> >> The hardware reset value for this field is 0x1 (enabled).
> >> Note that this register field is only available on RK3588, not on RK3568.
> >
> > Then you miss restricting it (:false) in one of if:then: blocks.
> >
> > Also, binding cannot be after the user. You need to reorder patches.
> >
> > ...
> >
> >>
> >> +  rockchip,phy-ref-use-pad:
> >> +    description: which PHY should use the external pad as PCIe reference clock.
> >> +      1 means use pad (default), 0 means use internal clock (PLL_PPLL).
> >
> > Can't you deduce it from the presence of clock inputs? IOW, if the
> > clocks are physically connected, is it even reasonable or possible to
> > use internal clock?

Thank you Krzysztof,
But no, if there is no clock, the driver deadlocks, it needs a clock
to probe correctly.

When there is a clock physically connected on the pad, you can still
choose to use it or use the internal clock, this is no problem.
The problem is when you have no clock on the pad (as it defaults to
using the pad) and the loading the driver deadlocks the system...

> >
> >> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +    minItems: 2
> >> +    maxItems: 2
> >> +    items:
> >> +      minimum: 0
> >> +      maximum: 1
> >
> > More precise:
> >
> > items:
> >   - description: PHY0 reference clock config
> >   - description: PHY1 reference clock config
> >   enum: [ 0, 1 ]
>
> Eh, no, rather if this stays as int:
>
>     items:
>       - description: PHY0 reference clock config
>         enum: [ 0, 1 ]
>       - description: PHY1 reference clock config
>         enum: [ 0, 1 ]
>     default: [ 1, 1 ]
>
>
> > default: [ 1, 1 ]
> >
> > Anyway, default 1, 1 is pretty non-obvious, so this should be just
> > non-unique-string-array (and property should be like
> > rockchip,phy-ref-clk-source/sel).
> >
> >
> > Best regards,
> > Krzysztof
> >
>
>
> Best regards,
> Krzysztof

I based my patch on patch :
46492d10067660785a09db4ce9244545126a17b8
dt-bindings: phy: rockchip,pcie3-phy: add rockchip,rx-common-refclk-mode

As the option I add is extremely similar, it sets a feature in one of
the PHY registers and only applies to RK3588.
That is why I used the same style as rockchip,rx-common-refclk-mode.

Wouldn't it be confusing or at least incoherent to use enum for
rockchip,phy-ref-use-pad but not for rx-common-refclk-mode ?

As for the name, I used phy-ref-use-pad as it is the name used in the
RK3588 technical reference manual.
(Similarly done on rx-common-refclk-mode).

Best regards,
Rick

On Thu, Aug 07, 2025 at 10:47:18AM +0200, Rick Wertenbroek wrote:
> On Thu, Aug 7, 2025 at 9:55 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On 07/08/2025 09:54, Krzysztof Kozlowski wrote:
> > > On Wed, Aug 06, 2025 at 03:38:23PM +0200, Rick Wertenbroek wrote:
> > >> >From the RK3588 Technical Reference Manual, Part1,
> > >> section 6.19 PCIe3PHY_GRF Register Description: "ref_use_pad"
> > >>
> > >> "Select reference clock connected to ref_pad_clk_p/ref_pad_clk_m.
> > >> Selects the external ref_pad_clk_p and ref_pad_clk_m inputs as the
> > >> reference clock source when asserted. When de-asserted, ref_alt_clk_p
> > >> and ref_alt_clk_m are the sources of the reference clock."
> > >>
> > >> The hardware reset value for this field is 0x1 (enabled).
> > >> Note that this register field is only available on RK3588, not on RK3568.
> > >
> > > Then you miss restricting it (:false) in one of if:then: blocks.
> > >
> > > Also, binding cannot be after the user. You need to reorder patches.
> > >
> > > ...
> > >
> > >>
> > >> +  rockchip,phy-ref-use-pad:
> > >> +    description: which PHY should use the external pad as PCIe reference clock.
> > >> +      1 means use pad (default), 0 means use internal clock (PLL_PPLL).
> > >
> > > Can't you deduce it from the presence of clock inputs? IOW, if the
> > > clocks are physically connected, is it even reasonable or possible to
> > > use internal clock?
> 
> Thank you Krzysztof,
> But no, if there is no clock, the driver deadlocks, it needs a clock
> to probe correctly.
> 
> When there is a clock physically connected on the pad, you can still
> choose to use it or use the internal clock, this is no problem.

Why would use internal clock for such case? In few other cases this
appeared we usualyl were using the presence of the clock as determining
factor.

> The problem is when you have no clock on the pad (as it defaults to
> using the pad) and the loading the driver deadlocks the system...

This sounds like a driver, not a binding, problem.

> 
> > >
> > >> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > >> +    minItems: 2
> > >> +    maxItems: 2
> > >> +    items:
> > >> +      minimum: 0
> > >> +      maximum: 1
> > >
> > > More precise:
> > >
> > > items:
> > >   - description: PHY0 reference clock config
> > >   - description: PHY1 reference clock config
> > >   enum: [ 0, 1 ]
> >
> > Eh, no, rather if this stays as int:
> >
> >     items:
> >       - description: PHY0 reference clock config
> >         enum: [ 0, 1 ]
> >       - description: PHY1 reference clock config
> >         enum: [ 0, 1 ]
> >     default: [ 1, 1 ]
> >
> >
> > > default: [ 1, 1 ]
> > >
> > > Anyway, default 1, 1 is pretty non-obvious, so this should be just
> > > non-unique-string-array (and property should be like
> > > rockchip,phy-ref-clk-source/sel).
> > >
> > >
> > > Best regards,
> > > Krzysztof
> > >
> >
> >
> > Best regards,
> > Krzysztof
> 
> I based my patch on patch :
> 46492d10067660785a09db4ce9244545126a17b8
> dt-bindings: phy: rockchip,pcie3-phy: add rockchip,rx-common-refclk-mode
> 
> As the option I add is extremely similar, it sets a feature in one of
> the PHY registers and only applies to RK3588.
> That is why I used the same style as rockchip,rx-common-refclk-mode.

So you should have used for example same property.

> 
> Wouldn't it be confusing or at least incoherent to use enum for
> rockchip,phy-ref-use-pad but not for rx-common-refclk-mode ?

Same hardware properties should have same properties - type, name and
meaning - but you did not re-use existing one. Maybe it is too specific?

We do not write properties for registers, but for hardware (like SoC or
board) characteristics.

Best regards,
Krzysztof