arm64: dts: rockchip: fix dma and pinctrl defs

[PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3

Posted by Ed Wildgoose 2 weeks, 1 day ago

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.

Signed-off-by: Ed Wildgoose <lists@wildgooses.com>
---
 .../boot/dts/rockchip/rk3566-radxa-zero-3.dtsi    | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
index 1ee5d96a4..41b3c4403 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
@@ -492,6 +492,21 @@ &uart2 {
 	status = "okay";
 };
 
+&uart4{
+    pinctrl-names = "default";
+    pinctrl-0 = <&uart4m1_xfer>;
+};
+
+&uart5 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&uart5m1_xfer>;
+};
+
+&uart9 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&uart9m1_xfer>;
+};
+
 &usb_host0_xhci {
 	status = "okay";
 };
-- 
2.49.0

Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3

Posted by FUKAUMI Naoki 2 weeks ago

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,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> 
> Signed-off-by: Ed Wildgoose <lists@wildgooses.com>
> ---
>   .../boot/dts/rockchip/rk3566-radxa-zero-3.dtsi    | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
> index 1ee5d96a4..41b3c4403 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
> @@ -492,6 +492,21 @@ &uart2 {
>   	status = "okay";
>   };
>   
> +&uart4{
> +    pinctrl-names = "default";
> +    pinctrl-0 = <&uart4m1_xfer>;
> +};
> +
> +&uart5 {
> +    pinctrl-names = "default";
> +    pinctrl-0 = <&uart5m1_xfer>;
> +};
> +
> +&uart9 {
> +    pinctrl-names = "default";
> +    pinctrl-0 = <&uart9m1_xfer>;
> +};
> +
>   &usb_host0_xhci {
>   	status = "okay";
>   };

Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3

Posted by Ed W 1 week, 6 days ago

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,
>
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.

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. Phrased another way, I can't see a disadvantage in doing
this, rather than leaving broken definitions in place which don't work correctly. Ideally I think
you should add at least the I2C defs as well, as that is something I would like to use for another
reason and haven't even got to the point of discovering that was broken?

I might also (gently) add that it was not easy to find all the documentation to fix this. I located
the datasheet for the Zero 3 via google (it's not obviously available on the wiki?), then there is
the reading through and I must admit I missed the multiplex difference the first few reads through.
Eventually I fed the docs into a LLM and it pointed out what I missed and we got there

So in summary, I'm hoping you will adjust the (really very well structured! thanks!) dtsi include
tree to correctly define all hardware on each board so that we don't have a situation that every
user in the world needs to be a really decent level kernel tech just to use the board! Pretty please!

Thanks for listening

Ed W

Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3

Posted by FUKAUMI Naoki 1 week, 6 days ago

Hi Ed,

On 9/19/25 00:23, Ed W wrote:
> 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,
>>
>> -- 
>> FUKAUMI Naoki
>> Radxa Computer (Shenzhen) Co., Ltd.
> 
> 
> 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. Phrased another way, I can't see a disadvantage in doing
> this, rather than leaving broken definitions in place which don't work correctly. Ideally I think
> you should add at least the I2C defs as well, as that is something I would like to use for another
> reason and haven't even got to the point of discovering that was broken?
> 
> I might also (gently) add that it was not easy to find all the documentation to fix this. I located
> the datasheet for the Zero 3 via google (it's not obviously available on the wiki?), then there is
> the reading through and I must admit I missed the multiplex difference the first few reads through.
> Eventually I fed the docs into a LLM and it pointed out what I missed and we got there

In addition to docs.radxa.com, we also distribute some PDFs on the 
following pages:

  https://radxa.com/products/zeros/zero3e#downloads
  https://radxa.com/products/zeros/zero3w#downloads

All information should be linked from the product pages (e.g. 
https://radxa.com/products/zeros/zero3e), but if something is missing, 
please report the issue by clicking "Report issue" at the bottom of each 
page on docs.radxa.com.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> So in summary, I'm hoping you will adjust the (really very well structured! thanks!) dtsi include
> tree to correctly define all hardware on each board so that we don't have a situation that every
> user in the world needs to be a really decent level kernel tech just to use the board! Pretty please!
> 
> Thanks for listening
> 
> Ed W
> 
> 
>