[PATCH 0/2] ARM: dts: renesas: r9a06g032-rzn1d400: enable USB

[PATCH 0/2] ARM: dts: renesas: r9a06g032-rzn1d400: enable USB

[Wolfram Sang]

This mini series enables USB on the RZ/N1D development board. Noteworthy
is only that the device port is on the module board. And the host port
is on the extension board. Otherwise, it is basic enablement. Depends on
the patches enabling GMAC1 and UART2. Not on the Debug-LED patches as
those still need discussion. A branch is here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/n1d/enablement

Happy hacking!


Wolfram Sang (2):
  ARM: dts: renesas: r9a06g032-rzn1d400-db: enable USB device port
  ARM: dts: renesas: r9a06g032-rzn1d400-eb: enable USB host port

 arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts |  4 ++++
 arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts | 13 +++++++++++++
 2 files changed, 17 insertions(+)

-- 
2.47.2

[PATCH 1/2] ARM: dts: renesas: r9a06g032-rzn1d400-db: enable USB device port

[Wolfram Sang]

Can be used via the microUSB connector CN9.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

The 'g_serial' gadget could be detected on the host.

 arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts
index 322e4c95ad3d..328cb35547d7 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts
+++ b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts
@@ -282,6 +282,10 @@ &uart0 {
 	status = "okay";
 };
 
+&udc {
+	status = "okay";
+};
+
 &wdt0 {
 	timeout-sec = <60>;
 	status = "okay";
-- 
2.47.2

Re: [PATCH 1/2] ARM: dts: renesas: r9a06g032-rzn1d400-db: enable USB device port

[Geert Uytterhoeven]

On Fri, 25 Apr 2025 at 12:01, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> Can be used via the microUSB connector CN9.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.16.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 2/2] ARM: dts: renesas: r9a06g032-rzn1d400-eb: enable USB host port

[Wolfram Sang]

Can be used via the USB connector J20.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

A rockbox based media player was successfully found.

 arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
index a3ef9d407a95..0806a1ea836a 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
+++ b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
@@ -153,6 +153,13 @@ pins_uart2: pins-uart2 {
 			 <RZN1_PINMUX(108, RZN1_FUNC_UART2)>;
 		bias-disable;
 	};
+
+	pins_usb: pins-usb {
+		pinmux = <RZN1_PINMUX(119, RZN1_FUNC_USB)>,
+			 <RZN1_PINMUX(120, RZN1_FUNC_USB)>,
+			 <RZN1_PINMUX(121, RZN1_FUNC_USB)>,
+			 <RZN1_PINMUX(122, RZN1_FUNC_USB)>;
+	};
 };
 
 &sdio1 {
@@ -236,3 +243,9 @@ &uart2 {
 	status = "okay";
 	uart-has-rtscts;
 };
+
+&pci_usb {
+	pinctrl-0 = <&pins_usb>;
+	pinctrl-names = "default";
+	status = "okay";
+};
-- 
2.47.2

Re: [PATCH 2/2] ARM: dts: renesas: r9a06g032-rzn1d400-eb: enable USB host port

[Geert Uytterhoeven]

Hi Wolfram,

CC Hervé

On Fri, 25 Apr 2025 at 12:01, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> Can be used via the USB connector J20.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Thanks for your patch!

> --- a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
> +++ b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
> @@ -153,6 +153,13 @@ pins_uart2: pins-uart2 {
>                          <RZN1_PINMUX(108, RZN1_FUNC_UART2)>;
>                 bias-disable;
>         };
> +
> +       pins_usb: pins-usb {
> +               pinmux = <RZN1_PINMUX(119, RZN1_FUNC_USB)>,
> +                        <RZN1_PINMUX(120, RZN1_FUNC_USB)>,

These two are USB_PPON1 and USB_OC1...

> +                        <RZN1_PINMUX(121, RZN1_FUNC_USB)>,
> +                        <RZN1_PINMUX(122, RZN1_FUNC_USB)>;

... and these two are USB_PPON2 and USB_OC2.

> +       };
>  };
>
>  &sdio1 {
> @@ -236,3 +243,9 @@ &uart2 {
>         status = "okay";
>         uart-has-rtscts;
>  };
> +
> +&pci_usb {
> +       pinctrl-0 = <&pins_usb>;
> +       pinctrl-names = "default";
> +       status = "okay";
> +};

This corresponds to USB port 2, which is a USB host port.
Port 1 was added in the previous patch as a USB function port.

According to Sections 10.6.5.1 (1) ("Meanings of USB_OCI and USB_PPON
Signals") and Table 10.131 ("OCI and PPON") of the RZ/N1D System Control
and Peripheral Manual, USB_PPON2 and USB_OC2 are only used when both
ports are configured for host mode.  When port 1 is configured for
function mode, port 2 uses USB_PPON1 and USB_OC1 instead, so you
shouldn't need pin control for USB_PPON2 and USB_OC2.
However, that does not match the schematics, which show that USB_PPON2
and USB_OC2 are wired to port 2's power switch.
Can you enlighten me?
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] ARM: dts: renesas: r9a06g032-rzn1d400-eb: enable USB host port

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]


> According to Sections 10.6.5.1 (1) ("Meanings of USB_OCI and USB_PPON
> Signals") and Table 10.131 ("OCI and PPON") of the RZ/N1D System Control
> and Peripheral Manual, USB_PPON2 and USB_OC2 are only used when both
> ports are configured for host mode.  When port 1 is configured for
> function mode, port 2 uses USB_PPON1 and USB_OC1 instead, so you
> shouldn't need pin control for USB_PPON2 and USB_OC2.
> However, that does not match the schematics, which show that USB_PPON2
> and USB_OC2 are wired to port 2's power switch.
> Can you enlighten me?

Both pins I enabled here are routed to the Config CPLD (check the DB
datasheet, page 9). This handles the configuration and routes whatever
is selected to the EB then. The pins on the EB are always named PPON2
and OC2. Because these pins are always routed to the CPLD, I think it
makes sense to have them described like this always. I didn't see
another way to use them anyhow. It could be argued, though, that these
pinmux properties belong to the DB, then. Maybe this makes more sense?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] ARM: dts: renesas: r9a06g032-rzn1d400-eb: enable USB host port

[Geert Uytterhoeven]

Hi Wolfram,

On Mon, 5 May 2025 at 22:27, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > According to Sections 10.6.5.1 (1) ("Meanings of USB_OCI and USB_PPON
> > Signals") and Table 10.131 ("OCI and PPON") of the RZ/N1D System Control
> > and Peripheral Manual, USB_PPON2 and USB_OC2 are only used when both
> > ports are configured for host mode.  When port 1 is configured for
> > function mode, port 2 uses USB_PPON1 and USB_OC1 instead, so you
> > shouldn't need pin control for USB_PPON2 and USB_OC2.
> > However, that does not match the schematics, which show that USB_PPON2
> > and USB_OC2 are wired to port 2's power switch.
> > Can you enlighten me?
>
> Both pins I enabled here are routed to the Config CPLD (check the DB
> datasheet, page 9). This handles the configuration and routes whatever
> is selected to the EB then. The pins on the EB are always named PPON2
> and OC2. Because these pins are always routed to the CPLD, I think it
> makes sense to have them described like this always. I didn't see
> another way to use them anyhow. It could be argued, though, that these
> pinmux properties belong to the DB, then. Maybe this makes more sense?

Oh, I totally missed that the markings "USB_{OC,PPON}[01]" next to
the "RZ_N1D_GPIO_1{19-22}" lines connected to the CPLD are merely
comments, and thus these lines are not physically connected to the
"USB_{OC,PPON}[01]" lines also connected to the CPLD.

So the CPLD takes care of the routing, based on the SETUP_SW<4>
setting. And I guess that setting should match the presence or absence
of a jumper on CN2, which controls OTG vs. Peri for USB1?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds