[PATCH 0/3] Move to gated-fixed-clock for Theobroma/Cherry boards

[PATCH 0/3] Move to gated-fixed-clock for Theobroma/Cherry boards

[Heiko Stuebner]

Both Tiger and Jaguar currently use a fixed-clock and gpio-gate-clock
to model the PCIe clock generator they have.

Ever since I wrote the gated-fixed-clock binding + driver, I carry
around conversion patches for those boards to use the new binding
and describe actual hardware.

I submitted different versions in the initial submission of the
then still named "clock-generator" binding, but have reworked
them now to use the gated-fixed-clock binding that actually landed.

Heiko Stuebner (3):
  arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on
    rk3588-jaguar
  arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on
    rk3588-tiger
  arm64: dts: rockchip: add pinctrl for clk-generator GPIO on
    rk3588-tiger

 .../arm64/boot/dts/rockchip/rk3588-jaguar.dts | 13 ++++--------
 .../arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 21 +++++++++++--------
 2 files changed, 16 insertions(+), 18 deletions(-)

-- 
2.47.2

[PATCH 1/3] arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-jaguar

[Heiko Stuebner]

From: Heiko Stuebner <heiko.stuebner@cherry.de>

Using a combination of fixed clock and gpio-gate clock works but does
not describe the actual hardware. Use the gated-fixed-clock binding
to describe this in a nicer way.

Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
 arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts b/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts
index 952affaf455c..6eea4e0b6ca4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts
@@ -90,21 +90,16 @@ led-1 {
 	 * 100MHz reference clock for PCIe peripherals from PI6C557-05BLE
 	 * clock generator.
 	 * The clock output is gated via the OE pin on the clock generator.
-	 * This is modeled as a fixed-clock plus a gpio-gate-clock.
 	 */
-	pcie_refclk_gen: pcie-refclk-gen-clock {
-		compatible = "fixed-clock";
+	pcie_refclk: pcie-clock-generator {
+		compatible = "gated-fixed-clock";
 		#clock-cells = <0>;
 		clock-frequency = <100000000>;
-	};
-
-	pcie_refclk: pcie-refclk-clock {
-		compatible = "gpio-gate-clock";
-		clocks = <&pcie_refclk_gen>;
-		#clock-cells = <0>;
+		clock-output-names = "pcie3_refclk";
 		enable-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_LOW>; /* PCIE30X4_CLKREQN_M0 */
 		pinctrl-names = "default";
 		pinctrl-0 = <&pcie30x4_clkreqn_m0>;
+		vdd-supply = <&vcca_3v3_s0>;
 	};
 
 	pps {
-- 
2.47.2

Re: [PATCH 1/3] arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-jaguar

[Quentin Schulz]

Hi Heiko,

On 2/5/26 11:21 AM, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner@cherry.de>
> 
> Using a combination of fixed clock and gpio-gate clock works but does
> not describe the actual hardware. Use the gated-fixed-clock binding
> to describe this in a nicer way.
> 

You also add a regulator as supply :)

> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> ---
>   arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 13 ++++---------
>   1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts b/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts
> index 952affaf455c..6eea4e0b6ca4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts
> @@ -90,21 +90,16 @@ led-1 {
>   	 * 100MHz reference clock for PCIe peripherals from PI6C557-05BLE
>   	 * clock generator.
>   	 * The clock output is gated via the OE pin on the clock generator.
> -	 * This is modeled as a fixed-clock plus a gpio-gate-clock.
>   	 */

I'm assuming the whole comment can be removed as it was just the 
reasoning behind two clocks and now we only have one which is pretty 
self explanatory?

> -	pcie_refclk_gen: pcie-refclk-gen-clock {
> -		compatible = "fixed-clock";
> +	pcie_refclk: pcie-clock-generator {
> +		compatible = "gated-fixed-clock";
>   		#clock-cells = <0>;
>   		clock-frequency = <100000000>;
> -	};
> -
> -	pcie_refclk: pcie-refclk-clock {
> -		compatible = "gpio-gate-clock";
> -		clocks = <&pcie_refclk_gen>;
> -		#clock-cells = <0>;
> +		clock-output-names = "pcie3_refclk";

Why change the name? I'm also wondering if we cannot have free backward 
compatibility by setting this to pcie-refclk-clock to match the old name?

Same remarks for Tiger (patch 2).

Change looks fine though.

Cheers,
Quentin

[PATCH 2/3] arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-tiger

[Heiko Stuebner]

From: Heiko Stuebner <heiko.stuebner@cherry.de>

Using a combination of fixed clock and gpio-gate clock works but does
not describe the actual hardware. Use the gated-fixed-clock binding
to describe this in a nicer way.

Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
 arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
index 27269b7b08aa..259fb125e13f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
@@ -51,19 +51,14 @@ led-1 {
 	 * 100MHz reference clock for PCIe peripherals from PI6C557-05BLE
 	 * clock generator.
 	 * The clock output is gated via the OE pin on the clock generator.
-	 * This is modeled as a fixed-clock plus a gpio-gate-clock.
 	 */
-	pcie_refclk_gen: pcie-refclk-gen-clock {
-		compatible = "fixed-clock";
+	pcie_refclk: pcie-clock-generator {
+		compatible = "gated-fixed-clock";
 		#clock-cells = <0>;
 		clock-frequency = <100000000>;
-	};
-
-	pcie_refclk: pcie-refclk-clock {
-		compatible = "gpio-gate-clock";
-		clocks = <&pcie_refclk_gen>;
-		#clock-cells = <0>;
+		clock-output-names = "pcie3_refclk";
 		enable-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; /* PCIE30X4_CLKREQN_M1_L */
+		vdd-supply = <&vcca_3v3_s0>;
 	};
 
 	vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
-- 
2.47.2

[PATCH 3/3] arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tiger

[Heiko Stuebner]

From: Heiko Stuebner <heiko.stuebner@cherry.de>

While specific driver in the Linux-Kernel handles GPIOs gracefully without
matching pinctrl entries, this might not be true for other operating
systems. So having pinctrl entries makes the hardware-description
more complete.

The somewhat similar rk3588-jaguar board has a pinctrl entry already,
so also add one for rk3588-tiger.

Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
 arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
index 259fb125e13f..91057b166690 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
@@ -58,6 +58,8 @@ pcie_refclk: pcie-clock-generator {
 		clock-frequency = <100000000>;
 		clock-output-names = "pcie3_refclk";
 		enable-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; /* PCIE30X4_CLKREQN_M1_L */
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie30x4_clkreqn_m1_l>;
 		vdd-supply = <&vcca_3v3_s0>;
 	};
 
@@ -357,6 +359,12 @@ module_led_pin: module-led-pin {
 		};
 	};
 
+	pcie30x4 {
+		pcie30x4_clkreqn_m1_l: pcie30x4-clkreqn-m1-l {
+			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
 	usb3 {
 		usb3_id: usb3-id {
 			rockchip,pins =
-- 
2.47.2

Re: [PATCH 3/3] arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tiger

[Quentin Schulz]

Hi Heiko,

On 2/5/26 11:21 AM, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner@cherry.de>
> 
> While specific driver in the Linux-Kernel handles GPIOs gracefully without
> matching pinctrl entries, this might not be true for other operating
> systems. So having pinctrl entries makes the hardware-description
> more complete.
> 
> The somewhat similar rk3588-jaguar board has a pinctrl entry already,
> so also add one for rk3588-tiger.
> 
> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> ---
>   arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> index 259fb125e13f..91057b166690 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> @@ -58,6 +58,8 @@ pcie_refclk: pcie-clock-generator {
>   		clock-frequency = <100000000>;
>   		clock-output-names = "pcie3_refclk";
>   		enable-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; /* PCIE30X4_CLKREQN_M1_L */
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pcie30x4_clkreqn_m1_l>;
>   		vdd-supply = <&vcca_3v3_s0>;
>   	};
>   
> @@ -357,6 +359,12 @@ module_led_pin: module-led-pin {
>   		};
>   	};
>   
> +	pcie30x4 {
> +		pcie30x4_clkreqn_m1_l: pcie30x4-clkreqn-m1-l {
> +			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;

So this is interesting because it made me double-check the schematics 
and I think we did a mistake on Jaguar.

This one here is fine as this SoC pin is connected to the PDn pin of the 
IC which has an internal Pull-Up, so the state is defined.

However, on Jaguar this signal controls a transistor and there's no 
external Pull-Up or Pull-Down between the SoC and the transistor gate so 
we probably should not have pull_none for the pinconf. The default reset 
state of this pin in Pull-Up so maybe we should go with that such that 
there's no difference between the reset default and the time between 
application of the pinconf by the core and asserting of the pin by the 
driver. What do you think?

As for Tiger, this is fine, so:

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [PATCH 3/3] arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tiger

[Heiko Stübner]

Am Donnerstag, 5. Februar 2026, 17:49:15 Mitteleuropäische Normalzeit schrieb Quentin Schulz:
> Hi Heiko,
> 
> On 2/5/26 11:21 AM, Heiko Stuebner wrote:
> > From: Heiko Stuebner <heiko.stuebner@cherry.de>
> > 
> > While specific driver in the Linux-Kernel handles GPIOs gracefully without
> > matching pinctrl entries, this might not be true for other operating
> > systems. So having pinctrl entries makes the hardware-description
> > more complete.
> > 
> > The somewhat similar rk3588-jaguar board has a pinctrl entry already,
> > so also add one for rk3588-tiger.
> > 
> > Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> > ---
> >   arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 8 ++++++++
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> > index 259fb125e13f..91057b166690 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> > @@ -58,6 +58,8 @@ pcie_refclk: pcie-clock-generator {
> >   		clock-frequency = <100000000>;
> >   		clock-output-names = "pcie3_refclk";
> >   		enable-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; /* PCIE30X4_CLKREQN_M1_L */
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pcie30x4_clkreqn_m1_l>;
> >   		vdd-supply = <&vcca_3v3_s0>;
> >   	};
> >   
> > @@ -357,6 +359,12 @@ module_led_pin: module-led-pin {
> >   		};
> >   	};
> >   
> > +	pcie30x4 {
> > +		pcie30x4_clkreqn_m1_l: pcie30x4-clkreqn-m1-l {
> > +			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
> 
> So this is interesting because it made me double-check the schematics 
> and I think we did a mistake on Jaguar.
> 
> This one here is fine as this SoC pin is connected to the PDn pin of the 
> IC which has an internal Pull-Up, so the state is defined.
> 
> However, on Jaguar this signal controls a transistor and there's no 
> external Pull-Up or Pull-Down between the SoC and the transistor gate so 
> we probably should not have pull_none for the pinconf. The default reset 
> state of this pin in Pull-Up so maybe we should go with that such that 
> there's no difference between the reset default and the time between 
> application of the pinconf by the core and asserting of the pin by the 
> driver. What do you think?

Looking at the datasheet for the PI6C557-05B, both nPD and OE are
described as having an "internal pull up resistor", so the pinconf side
should not matter?


> As for Tiger, this is fine, so:
> 
> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Heiko

Re: [PATCH 3/3] arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tiger

[Quentin Schulz]

Hi Heiko,

On 2/9/26 5:27 PM, Heiko Stübner wrote:
> Am Donnerstag, 5. Februar 2026, 17:49:15 Mitteleuropäische Normalzeit schrieb Quentin Schulz:
>> Hi Heiko,
>>
>> On 2/5/26 11:21 AM, Heiko Stuebner wrote:
>>> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>>>
>>> While specific driver in the Linux-Kernel handles GPIOs gracefully without
>>> matching pinctrl entries, this might not be true for other operating
>>> systems. So having pinctrl entries makes the hardware-description
>>> more complete.
>>>
>>> The somewhat similar rk3588-jaguar board has a pinctrl entry already,
>>> so also add one for rk3588-tiger.
>>>
>>> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
>>> ---
>>>    arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 8 ++++++++
>>>    1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
>>> index 259fb125e13f..91057b166690 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
>>> @@ -58,6 +58,8 @@ pcie_refclk: pcie-clock-generator {
>>>    		clock-frequency = <100000000>;
>>>    		clock-output-names = "pcie3_refclk";
>>>    		enable-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; /* PCIE30X4_CLKREQN_M1_L */
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&pcie30x4_clkreqn_m1_l>;
>>>    		vdd-supply = <&vcca_3v3_s0>;
>>>    	};
>>>    
>>> @@ -357,6 +359,12 @@ module_led_pin: module-led-pin {
>>>    		};
>>>    	};
>>>    
>>> +	pcie30x4 {
>>> +		pcie30x4_clkreqn_m1_l: pcie30x4-clkreqn-m1-l {
>>> +			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
>>
>> So this is interesting because it made me double-check the schematics
>> and I think we did a mistake on Jaguar.
>>
>> This one here is fine as this SoC pin is connected to the PDn pin of the
>> IC which has an internal Pull-Up, so the state is defined.
>>
>> However, on Jaguar this signal controls a transistor and there's no
>> external Pull-Up or Pull-Down between the SoC and the transistor gate so
>> we probably should not have pull_none for the pinconf. The default reset
>> state of this pin in Pull-Up so maybe we should go with that such that
>> there's no difference between the reset default and the time between
>> application of the pinconf by the core and asserting of the pin by the
>> driver. What do you think?
> 
> Looking at the datasheet for the PI6C557-05B, both nPD and OE are
> described as having an "internal pull up resistor", so the pinconf side
> should not matter?
> 

I believe it does because it's an undefined state for the gate of the 
transistor. Look at Q21 on the schematics of v1.4.0, it's directly 
routed to the SoC pin. There's no HW pull-up or pull-down on the gate 
side of the transistor so we rely on the SoC internal pull-up/pull-down 
to have a stable state at the gate. This means the transistor gate may 
be either high or low based on who knows what since the line is left 
floating the moment the pinconf is applied (by the core, thus before the 
driver is even attempted to be probed) until the driver probes and 
drives the enable-gpios low, meaning we either conduct between drain and 
source (meaning we pull the PDn and OE pins of the PI6C557-05B to 
ground) or not (left floating, no external HW pull-up or pull-down, 
internal pull-up of PDn and OE should be enough to guarantee a stable 
state) but we cannot say for sure which. Of course we exit this state 
once we drive the enable-gpios line from the driver.

This was discussed with the HW department, you can double-check with 
them, maybe we overlooked something or I got something wrong, my 
transistor-fu is not even beginner-level ;)

Cheers,
Quentin