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

Quentin Schulz
2026-02-09T17:12:48Z

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