From: "Heiko Stübner" <heiko@sntech.de>
To: FUKAUMI Naoki <naoki@radxa.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
Ed W <lists@wildgooses.com>
Subject: Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO3
Date: Thu, 18 Sep 2025 18:18:22 +0200 [thread overview]
Message-ID: <2325560.3ZeAukHxDK@diego> (raw)
In-Reply-To: <adbc2396-d5f0-4dd6-a65e-0dd78a58b9a4@wildgooses.com>
Am Donnerstag, 18. September 2025, 17:23:04 Mitteleuropäische Sommerzeit schrieb Ed W:
> On 18/09/2025 05:53, FUKAUMI Naoki wrote:
> > Hi Ed,
> >
> > Thank you very much for your work.
> >
> > On 9/17/25 20:49, Ed Wildgoose wrote:
> >> The rk3566 has multiplexed pins and the uarts can be moved to a choice
> >> of 2 pin groups. The default rk356x-base.dtsi appears to default to mux0
> >> for all uarts, however, specific hardware might choose to implement
> >> alternatives
> >>
> >> The Radxa zero 3 shows that is uses M1 for uarts:
> >> - uart4
> >> - uart5
> >> - uart9
> >>
> >> These aren't normally enabled, but we should at least correct the
> >> default pinctrl definitions. Without these changes there will be
> >> conflicts with mmc0/mmc1, leading to the SD or eMMC going missing.
> >
> > Sorry, but why do we need these definitions for disabled nodes?
> >
> > Or why don't we do similar definitions for nodes other than uart?
> > For example, PWM12, I2S3, and SPI3 also use M1. Are they not related to SD/eMMC and therefore
> > don't need to be defined?
> >
> > If users want to use UARTs on pin headers, they will refer to the correct documentation[1] to
> > determine which pins are UARTs and will of course write the correct pinctrl definition.
> >
> > [1] https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface#gpio-interface
> >
> > Best regards,
> >
>
>
> Personally, and I'm saying this as a user who is technical enough to fix the definitions, it took me
> quite a few days to figure out what was wrong with the definitions and understand the intricate tree
> of dtsi includes, to finally figure out why I couldn't just do a "status = "okay";" to enable the
> UARTs... (which is roughly what is shown in several radxa supplied overlays to enable uarts on
> various boards)
>
> So my vote would be to correctly define all the hardware for a given board. Then users can simply do
> a status="okay" to enable and off they go.
And I'd agree with that argument. Setting up the needed pinctrl settings
for the peripherals described in the device documentation
( https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface#gpio-interface )
is the sensible thing to do. While keeping the peripherals itself disabled
and for the user to decide which peripheral to enable.
Heiko
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: FUKAUMI Naoki <naoki@radxa.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
Ed W <lists@wildgooses.com>
Subject: Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO3
Date: Thu, 18 Sep 2025 18:18:22 +0200 [thread overview]
Message-ID: <2325560.3ZeAukHxDK@diego> (raw)
In-Reply-To: <adbc2396-d5f0-4dd6-a65e-0dd78a58b9a4@wildgooses.com>
Am Donnerstag, 18. September 2025, 17:23:04 Mitteleuropäische Sommerzeit schrieb Ed W:
> On 18/09/2025 05:53, FUKAUMI Naoki wrote:
> > Hi Ed,
> >
> > Thank you very much for your work.
> >
> > On 9/17/25 20:49, Ed Wildgoose wrote:
> >> The rk3566 has multiplexed pins and the uarts can be moved to a choice
> >> of 2 pin groups. The default rk356x-base.dtsi appears to default to mux0
> >> for all uarts, however, specific hardware might choose to implement
> >> alternatives
> >>
> >> The Radxa zero 3 shows that is uses M1 for uarts:
> >> - uart4
> >> - uart5
> >> - uart9
> >>
> >> These aren't normally enabled, but we should at least correct the
> >> default pinctrl definitions. Without these changes there will be
> >> conflicts with mmc0/mmc1, leading to the SD or eMMC going missing.
> >
> > Sorry, but why do we need these definitions for disabled nodes?
> >
> > Or why don't we do similar definitions for nodes other than uart?
> > For example, PWM12, I2S3, and SPI3 also use M1. Are they not related to SD/eMMC and therefore
> > don't need to be defined?
> >
> > If users want to use UARTs on pin headers, they will refer to the correct documentation[1] to
> > determine which pins are UARTs and will of course write the correct pinctrl definition.
> >
> > [1] https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface#gpio-interface
> >
> > Best regards,
> >
>
>
> Personally, and I'm saying this as a user who is technical enough to fix the definitions, it took me
> quite a few days to figure out what was wrong with the definitions and understand the intricate tree
> of dtsi includes, to finally figure out why I couldn't just do a "status = "okay";" to enable the
> UARTs... (which is roughly what is shown in several radxa supplied overlays to enable uarts on
> various boards)
>
> So my vote would be to correctly define all the hardware for a given board. Then users can simply do
> a status="okay" to enable and off they go.
And I'd agree with that argument. Setting up the needed pinctrl settings
for the peripherals described in the device documentation
( https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface#gpio-interface )
is the sensible thing to do. While keeping the peripherals itself disabled
and for the user to decide which peripheral to enable.
Heiko
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-09-18 16:18 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 11:49 [PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs Ed Wildgoose
2025-09-17 11:49 ` Ed Wildgoose
2025-09-17 11:49 ` [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3 Ed Wildgoose
2025-09-17 11:49 ` Ed Wildgoose
2025-09-18 4:53 ` FUKAUMI Naoki
2025-09-18 4:53 ` FUKAUMI Naoki
2025-09-18 15:23 ` Ed W
2025-09-18 15:23 ` Ed W
2025-09-18 16:18 ` Heiko Stübner [this message]
2025-09-18 16:18 ` [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO3 Heiko Stübner
2025-09-18 23:57 ` FUKAUMI Naoki
2025-09-18 23:57 ` FUKAUMI Naoki
2025-09-19 9:28 ` Ed W
2025-09-19 9:28 ` Ed W
2025-09-19 10:17 ` Heiko Stübner
2025-09-19 10:17 ` Heiko Stübner
2025-09-19 10:21 ` FUKAUMI Naoki
2025-09-19 10:21 ` FUKAUMI Naoki
2025-09-19 0:13 ` [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3 FUKAUMI Naoki
2025-09-19 0:13 ` FUKAUMI Naoki
2025-09-20 8:14 ` Jonas Karlman
2025-09-20 8:14 ` Jonas Karlman
2025-09-17 11:49 ` [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property Ed Wildgoose
2025-09-17 11:49 ` Ed Wildgoose
2025-09-17 12:22 ` Dragan Simic
2025-09-17 12:22 ` Dragan Simic
2025-09-17 14:25 ` Heiko Stübner
2025-09-17 14:25 ` Heiko Stübner
2025-09-18 9:32 ` [PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs v2 Ed Wildgoose
2025-09-18 9:32 ` Ed Wildgoose
2025-09-18 9:32 ` [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3 Ed Wildgoose
2025-09-18 9:32 ` Ed Wildgoose
2025-09-18 9:32 ` [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property Ed Wildgoose
2025-09-18 9:32 ` Ed Wildgoose
2025-09-18 16:22 ` Heiko Stübner
2025-09-18 16:22 ` Heiko Stübner
2025-09-18 16:20 ` [PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs v2 Heiko Stübner
2025-09-18 16:20 ` Heiko Stübner
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=2325560.3ZeAukHxDK@diego \
--to=heiko@sntech.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lists@wildgooses.com \
--cc=naoki@radxa.com \
--cc=robh@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.