[PATCH 3/3] arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tiger
Heiko Stübner
heiko at sntech.de
Mon Feb 9 08:27:51 PST 2026
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 at 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 at 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 at cherry.de>
Heiko
More information about the linux-arm-kernel
mailing list