From: Herve Codina <herve.codina@bootlin.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Hoan Tran <hoan@os.amperecomputing.com>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Magnus Damm <magnus.damm@gmail.com>,
Saravana Kannan <saravanak@google.com>,
Serge Semin <fancer.lancer@gmail.com>,
Phil Edworthy <phil.edworthy@renesas.com>,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Miquel Raynal <miquel.raynal@bootlin.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 0/6] gpio: renesas: Add support for GPIO and related interrupts in RZ/N1 SoC
Date: Wed, 30 Jul 2025 10:10:07 +0200 [thread overview]
Message-ID: <20250730101007.314d88ce@bootlin.com> (raw)
In-Reply-To: <aIYHD5SEAqQNfDjD@ninjato>
Hi Wolfram,
On Sun, 27 Jul 2025 13:01:35 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
> Hi Hervé,
>
> > This series adds support for GPIO and GPIO IRQ mux available in the
> > RZ/N1 SoCs.
>
> Yes, way cool! Very happy to see this upstreaming effort!
>
> > The first two patches of the series add support for GPIO (binding update
> > and device-tree description).
>
> So, I started simple and used the first two patches to enable LEDs on
> pins 92 and 93 on my board. I added this on top of patch 1+2:
>
> diff --git a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts
> index 3258b2e27434..4790ffad578f 100644
> --- a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts
> +++ b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts
> @@ -185,6 +185,12 @@ fixed-link {
> };
> };
>
> +&gpio1 {
> + pinctrl-0 = <&pins_gpio1>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> +
> &i2c2 {
> pinctrl-0 = <&pins_i2c2>;
> pinctrl-names = "default";
> @@ -256,6 +262,11 @@ pins_cpld: pins-cpld {
> <RZN1_PINMUX(122, RZN1_FUNC_USB)>;
> };
>
> + pins_gpio1: pins-gpio1 {
> + pinmux = <RZN1_PINMUX(92, RZN1_FUNC_GPIO)>, /* GPIO1B[23] */
> + <RZN1_PINMUX(93, RZN1_FUNC_GPIO)>; /* GPIO1B[24] */
> + };
> +
> pins_eth3: pins_eth3 {
> pinmux = <RZN1_PINMUX(36, RZN1_FUNC_CLK_ETH_MII_RGMII_RMII)>,
> <RZN1_PINMUX(37, RZN1_FUNC_CLK_ETH_MII_RGMII_RMII)>
>
> to my board dts. The controller gets probed but I can't control the
> LEDs. Neither with exported GPIOs (via sysfs) nor with a dedicated LED
> node. Am I missing something obvious? The LEDs are attached to PL_GPIO92
> and PL_GPIO93 which are mapped to GPIO1b[23] and GPIO1b[24]. That seems
> to be in accordance with the datasheet. I hope I just overlooked
> something simple. Some outputs, first /sys/kernel/debug/gpio:
>
> ...
> gpiochip1: GPIOs 552-583, parent: platform/5000c000.gpio, 5000c000.gpio:
>
> gpiochip2: GPIOs 584-615, parent: platform/5000c000.gpio, 5000c000.gpio:
> gpio-608 ( |sysfs ) out hi
>
> And /sys/kernel/debug/pinctrl/40067000.pinctrl/pinmux-pins:
>
> Pinmux settings per pin
> Format: pin (name): mux_owner gpio_owner hog?
> ...
> pin 92 (pl_gpio92): 5000c000.gpio (GPIO UNCLAIMED) function pins-gpio1 group pins-gpio1
> pin 93 (pl_gpio93): 5000c000.gpio (GPIO UNCLAIMED) function pins-gpio1 group pins-gpio1
>
> I wonder about the "(GPIO UNCLAIMED)" a little? How do you use it on
> your board?
>
Strange, I have a LED working on my side.
My LED is connected to gpio0b[9] (GPIO17).
I just used:
--- 8< ---
gpio_leds {
compatible = "gpio-leds";
led_1g: led-0 {
label = "led_1g";
gpios = <&gpio0b 9 GPIO_ACTIVE_HIGH>;
};
};
&gpio0 {
pinctrl-0 = <&pins_gpio0>;
pinctrl-names = "default";
status = "okay";
};
&pinctrl{
/*
* I have other pins used as GPIOs but my led is :
* RZN1_PINMUX(17, RZN1_FUNC_GPIO)
*/
pins_gpio0: pins_gpio0 {
pinmux = <
RZN1_PINMUX(13, RZN1_FUNC_GPIO) /* GPIO0B[7] */
RZN1_PINMUX(14, RZN1_FUNC_GPIO) /* GPIO0B[8] */
RZN1_PINMUX(15, RZN1_FUNC_GPIO) /* GPIO0A[6] */
RZN1_PINMUX(16, RZN1_FUNC_GPIO) /* GPIO0A[7] */
RZN1_PINMUX(17, RZN1_FUNC_GPIO) /* GPIO0B[9] */
RZN1_PINMUX(18, RZN1_FUNC_GPIO) /* GPIO0B[10] */
RZN1_PINMUX(22, RZN1_FUNC_GPIO) /* GPIO0A[9] */
RZN1_PINMUX(23, RZN1_FUNC_GPIO) /* GPIO0B[13] */
>;
drive-strength = <6>;
bias-disable;
pins_gpio0_pullup {
pinmux = <
RZN1_PINMUX(25, RZN1_FUNC_GPIO) /* GPIO0B[14] - A70CI_EN_N */
RZN1_PINMUX(26, RZN1_FUNC_GPIO) /* GPIO0B[15] - A71CH_EN_N */
RZN1_PINMUX(27, RZN1_FUNC_GPIO) /* GPIO0A[11] - TRUST_M_EN_N */
RZN1_PINMUX(28, RZN1_FUNC_GPIO) /* GPIO0A[12] - TRUST_X_EN_N */
RZN1_PINMUX(32, RZN1_FUNC_GPIO) /* GPIO0B[19] - STMA100_EN_N*/
>;
drive-strength = <6>;
bias-pull-up;
};
};
--- 8< ---
Of course with:
CONFIG_GPIO_DWAPB=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
My led is accessible from the user-space without any issue:
echo 255 > /sys/class/leds/led_1g/brightness
I have checked /sys/kernel/debug/pinctrl/40067000.pinctrl/pinmux-pins and
I have also the "(GPIO UNCLAIMED)":
...
pin 12 (pl_gpio12): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 13 (pl_gpio13): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0
pin 14 (pl_gpio14): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0
pin 15 (pl_gpio15): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0
pin 16 (pl_gpio16): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0
pin 17 (pl_gpio17): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0
pin 18 (pl_gpio18): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0
pin 19 (pl_gpio19): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 20 (pl_gpio20): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 21 (pl_gpio21): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 22 (pl_gpio22): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0
pin 23 (pl_gpio23): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0
pin 24 (pl_gpio24): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 25 (pl_gpio25): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0_pullup
pin 26 (pl_gpio26): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0_pullup
pin 27 (pl_gpio27): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0_pullup
pin 28 (pl_gpio28): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0_pullup
pin 29 (pl_gpio29): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 30 (pl_gpio30): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 31 (pl_gpio31): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 32 (pl_gpio32): 5000b000.gpio (GPIO UNCLAIMED) function pins_gpio0 group pins_gpio0_pullup
pin 33 (pl_gpio33): (MUX UNCLAIMED) (GPIO UNCLAIMED)
...
When you described the LED on your side, did you reference the GPIO using &gpio1b
for instance gpios = <&gpio1b 23 GPIO_ACTIVE_HIGH>;
For GPIO accesses from user space I used gpioget/gpioset tools from libgpiod
without any issues to read/write a GPIO.
Best regards,
Hervé
next prev parent reply other threads:[~2025-07-30 8:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 15:26 [PATCH 0/6] gpio: renesas: Add support for GPIO and related interrupts in RZ/N1 SoC Herve Codina
2025-07-25 15:26 ` [PATCH 1/6] dt-bindings: gpio: snps,dw-apb: Add support for Renesas RZ/N1 Herve Codina
2025-07-29 18:11 ` Rob Herring
2025-07-30 9:17 ` Herve Codina
2025-07-25 15:26 ` [PATCH 2/6] ARM: dts: r9a06g032: Add GPIO controllers Herve Codina
2025-07-25 15:26 ` [PATCH 3/6] dt-bindings: soc: renesas: Add the Renesas RZ/N1 GPIO Interrupt Multiplexer Herve Codina
2025-07-25 15:26 ` [PATCH 4/6] of/irq: Introduce of_irq_foreach_imap Herve Codina
2025-07-29 19:51 ` Rob Herring
2025-07-30 9:43 ` Herve Codina
2025-07-25 15:26 ` [PATCH 5/6] soc: renesas: Add support for Renesas RZ/N1 GPIO Interrupt Multiplexer Herve Codina
2025-07-29 19:51 ` Rob Herring
2025-07-30 9:54 ` Herve Codina
2025-07-30 20:47 ` Rob Herring
2025-08-01 9:17 ` Herve Codina
2025-07-25 15:26 ` [PATCH 6/6] ARM: dts: r9a06g032: Add support for GPIO interrupts Herve Codina
2025-07-25 20:17 ` [PATCH 0/6] gpio: renesas: Add support for GPIO and related interrupts in RZ/N1 SoC Rob Herring (Arm)
2025-07-27 11:01 ` Wolfram Sang
2025-07-30 8:10 ` Herve Codina [this message]
2025-08-06 18:51 ` Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250730101007.314d88ce@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=brgl@bgdev.pl \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fancer.lancer@gmail.com \
--cc=geert+renesas@glider.be \
--cc=hoan@os.amperecomputing.com \
--cc=krzk+dt@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=phil.edworthy@renesas.com \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).