[PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs

[PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs

[Ed Wildgoose]

The default pinctrl definitions for the Radxa Zero 3W don't match the
datasheet. Possibly few people enable extra UARTs and hence it wasn't
noticed? I needed all 5 UARTs for a project and the first patch corrects
the pinctrl defs. Without this patch, enabling the extra UARTs causes
issues such as the MMC devices disappearing, due to collisions.

Second patch adds a dma-names property, which appears to be a
pre-requisite for enabling DMA on the UARTs. I've applied this to the
base rk356x-base.dtsi as it seems like a change that should apply to all
SOMs? However, I confess ignorance in this area, so could I ask for a
second opinion before anyone applies this?  It's tested on my Zero 3W
board and appears to function correctly and DMA is reported as enabled.


Ed Wildgoose (2):
  arm64: dts: rockchip: correct uart mux for Radxa ZERO 3
  rockchip: dts: Enable UART DMA by adding default dma-names property

 .../boot/dts/rockchip/rk3566-radxa-zero-3.dtsi    | 15 +++++++++++++++
 arch/arm64/boot/dts/rockchip/rk356x-base.dtsi     |  9 +++++++++
 2 files changed, 24 insertions(+)

-- 
2.49.0

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

[Ed Wildgoose]

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

[FUKAUMI Naoki]

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

[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,
>
> -- 
> 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 ZERO3

[Heiko Stübner]

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

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

[FUKAUMI Naoki]

Hi Heiko, Ed,

On 9/19/25 01:18, Heiko Stübner wrote:
> 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.

I'm not strongly opposed to this policy, but I thought if you're going 
to do this, you should do it for everything, not just UARTs.

Best regards,

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

> Heiko
> 
> 
> 

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

[Ed W]

On 19/09/2025 00:57, FUKAUMI Naoki wrote:
> Hi Heiko, Ed,
>
> On 9/19/25 01:18, Heiko Stübner wrote:
>> Am Donnerstag, 18. September 2025, 17:23:04 Mitteleuropäische Sommerzeit schrieb Ed W:
>>> 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.
>
> I'm not strongly opposed to this policy, but I thought if you're going to do this, you should do
> it for everything, not just UARTs.
>
> Best regards,
>
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.


I would most definitely be in favour of doing this for all peripherals! Yes please!

I have a selection of Zero 3W and E devices here. We are going to potentially use them in an OEM
capacity, and I might have some I2C devices to plug into them in the future, and for example would
like to get the I2C working on the pins (is it 2 and 4?). It will be at least some weeks before I
can work on that, but if you want to offer some support to fixup at least that device I won't decline!

Thanks for making these boards

Ed W

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

[Heiko Stübner]

Am Freitag, 19. September 2025, 01:57:57 Mitteleuropäische Sommerzeit schrieb FUKAUMI Naoki:
> Hi Heiko, Ed,
> 
> On 9/19/25 01:18, Heiko Stübner wrote:
> > 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.
> 
> I'm not strongly opposed to this policy, but I thought if you're going 
> to do this, you should do it for everything, not just UARTs.

yes, exactly
So patches for the other header peripherals welcome :-) .

But still it's nice to do it in steps like this one, as it makes reviewing easier.


Heiko

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

[FUKAUMI Naoki]

On 9/19/25 19:17, Heiko Stübner wrote:
> Am Freitag, 19. September 2025, 01:57:57 Mitteleuropäische Sommerzeit schrieb FUKAUMI Naoki:
>> Hi Heiko, Ed,
>>
>> On 9/19/25 01:18, Heiko Stübner wrote:
>>> 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.
>>
>> I'm not strongly opposed to this policy, but I thought if you're going
>> to do this, you should do it for everything, not just UARTs.
> 
> yes, exactly
> So patches for the other header peripherals welcome :-) .
> 
> But still it's nice to do it in steps like this one, as it makes reviewing easier.

I agree.

Best regards,

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

> 
> 
> Heiko
> 
> 
> 

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

[FUKAUMI Naoki]

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
> 
> 
> 

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

[Jonas Karlman]

Hi Ed,

On 9/17/2025 1:49 PM, 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.

Please rephrase the commit subject and message, currently it seem to
imply that there is something broken that needs fixing, however this
mainly make it easier to apply an overlay that does not include
description of any changed behavior for pins on the 40-pin header.

Current expected behavior of the hw, using pins on 40-pin header as gpio
pins should already be correctly described in this board device tree.

My original intent when submitting board device trees, such as this one, 
is that a device tree overlay will fully describe any required changes.
Also I do not expect that using an overlay intended for an old vendor
kernel device tree will work as-is on mainline kernel device tree.

> 
> 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{

nit: missing space

> +    pinctrl-names = "default";
> +    pinctrl-0 = <&uart4m1_xfer>;

nit: seem to use space instead of tab, same for rest.

Regards,
Jonas

> +};
> +
> +&uart5 {
> +    pinctrl-names = "default";
> +    pinctrl-0 = <&uart5m1_xfer>;
> +};
> +
> +&uart9 {
> +    pinctrl-names = "default";
> +    pinctrl-0 = <&uart9m1_xfer>;
> +};
> +
>  &usb_host0_xhci {
>  	status = "okay";
>  };

[PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property

[Ed Wildgoose]

Kernel appears to need a dma-names set for DMA to actually enable. Set a
default dma-names property for all UARTs defined in the base rk356x-base
dtsi

This is tested on a Radxa Zero 3W (which has 5x UARTs) and removes the
warnings and enables DMA on this platform

Signed-off-by: Ed Wildgoose <lists@wildgooses.com>
---
 arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
index fd2214b6f..55240f76d 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
@@ -1334,6 +1334,7 @@ uart1: serial@fe650000 {
 		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 2>, <&dmac0 3>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart1m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
@@ -1348,6 +1349,7 @@ uart2: serial@fe660000 {
 		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 4>, <&dmac0 5>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart2m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
@@ -1362,6 +1364,7 @@ uart3: serial@fe670000 {
 		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 6>, <&dmac0 7>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart3m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
@@ -1376,6 +1379,7 @@ uart4: serial@fe680000 {
 		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 8>, <&dmac0 9>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart4m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
@@ -1390,6 +1394,7 @@ uart5: serial@fe690000 {
 		clocks = <&cru SCLK_UART5>, <&cru PCLK_UART5>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 10>, <&dmac0 11>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart5m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
@@ -1404,6 +1409,7 @@ uart6: serial@fe6a0000 {
 		clocks = <&cru SCLK_UART6>, <&cru PCLK_UART6>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 12>, <&dmac0 13>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart6m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
@@ -1418,6 +1424,7 @@ uart7: serial@fe6b0000 {
 		clocks = <&cru SCLK_UART7>, <&cru PCLK_UART7>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 14>, <&dmac0 15>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart7m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
@@ -1432,6 +1439,7 @@ uart8: serial@fe6c0000 {
 		clocks = <&cru SCLK_UART8>, <&cru PCLK_UART8>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 16>, <&dmac0 17>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart8m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
@@ -1446,6 +1454,7 @@ uart9: serial@fe6d0000 {
 		clocks = <&cru SCLK_UART9>, <&cru PCLK_UART9>;
 		clock-names = "baudclk", "apb_pclk";
 		dmas = <&dmac0 18>, <&dmac0 19>;
+		dma-names = "tx", "rx";
 		pinctrl-0 = <&uart9m0_xfer>;
 		pinctrl-names = "default";
 		reg-io-width = <4>;
-- 
2.49.0

Re: [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property

[Dragan Simic]

Hello Ed,

On 2025-09-17 13:49, Ed Wildgoose wrote:
> Kernel appears to need a dma-names set for DMA to actually enable. Set 
> a
> default dma-names property for all UARTs defined in the base 
> rk356x-base
> dtsi
> 
> This is tested on a Radxa Zero 3W (which has 5x UARTs) and removes the
> warnings and enables DMA on this platform

Thanks for the patches.

We should (still) stay away from defining the "dma-names" property
at the SoC level, because doing that causes serious issues in certain
cases.  Thus, I'd suggest that this patch is dropped, and that the
"dma-names" property is defined instead at the board level, where
it's needed and tested to work as expected.

Please see commit bf6f26deb0e8 (arm64: dts: rockchip: Add dma-names
to uart1 on quartz64-b, 2024-06-28) for further explanation.

If/when the underlying issues are debugged and resolved, we can get
back to defining the "dma-names" property at the SoC level.

Re: [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property

[Heiko Stübner]

Am Mittwoch, 17. September 2025, 14:22:52 Mitteleuropäische Sommerzeit schrieb Dragan Simic:
> Hello Ed,
> 
> On 2025-09-17 13:49, Ed Wildgoose wrote:
> > Kernel appears to need a dma-names set for DMA to actually enable. Set 
> > a
> > default dma-names property for all UARTs defined in the base 
> > rk356x-base
> > dtsi
> > 
> > This is tested on a Radxa Zero 3W (which has 5x UARTs) and removes the
> > warnings and enables DMA on this platform
> 
> Thanks for the patches.
> 
> We should (still) stay away from defining the "dma-names" property
> at the SoC level, because doing that causes serious issues in certain
> cases.  Thus, I'd suggest that this patch is dropped, and that the
> "dma-names" property is defined instead at the board level, where
> it's needed and tested to work as expected.
> 
> Please see commit bf6f26deb0e8 (arm64: dts: rockchip: Add dma-names
> to uart1 on quartz64-b, 2024-06-28) for further explanation.
> 
> If/when the underlying issues are debugged and resolved, we can get
> back to defining the "dma-names" property at the SoC level.

And apart from the whole stability thing, on a number of socs the pl330
dma controller has more possible sources for dma operations than it
has available channels ... and right now the driver does not support
handling this.

So you can (and if I remember correctly we did) end up with some uart
requesting dma channels (and not needing them) and then sound not
getting any.


Heiko

[PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs v2

[Ed Wildgoose]

Based on feedback, I reworked these patches. I've re-presented both as
I realise that one had invalid formatting (spaces vs tabs) and I've
moved the dma-names definition into the same board level dtsi. At this
point it seems reasonable to also squash the two patches, but feedback
appreciated?

The default pinctrl definitions for the Radxa Zero 3W don't match the
datasheet. Possibly few people enable extra UARTs and hence it wasn't
noticed? I needed all 5 UARTs for a project and the first patch corrects
the pinctrl defs. Without this patch, enabling the extra UARTs causes
issues such as the MMC devices disappearing, due to collisions.

Second patch adds a dma-names property, which appears to be a
pre-requisite for enabling DMA on the UARTs. I've applied this to the
board level dts as feedback suggested there could be unintended problems
if enabled across the complete rockchip dtsi.

It's tested on my Zero 3W board and appears to function correctly and
DMA is reported as enabled.

Ed Wildgoose (2):
  arm64: dts: rockchip: correct uart mux for Radxa ZERO 3
  rockchip: dts: Enable UART DMA by adding default dma-names property

 .../dts/rockchip/rk3566-radxa-zero-3.dtsi     | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)

-- 
2.49.0

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

[Ed Wildgoose]

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..e644bfc9c 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

[PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property

[Ed Wildgoose]

Kernel appears to need a dma-names set for DMA to actually enable. Set a
default dma-names property for all UARTs defined in the board
definition: rk3566-radxa-zero-3.dtsi

This is tested on a Radxa Zero 3W (which has 5x UARTs) and removes the
warnings and enables DMA on this platform

Signed-off-by: Ed Wildgoose <lists@wildgooses.com>
---
 arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi | 8 ++++++++
 1 file changed, 8 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 e644bfc9c..fc26a4a52 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
@@ -488,21 +488,29 @@ &tsadc {
 	status = "okay";
 };
 
+&uart1 {
+	dma-names = "tx", "rx";
+};
+
 &uart2 {
+	dma-names = "tx", "rx";
 	status = "okay";
 };
 
 &uart4{
+	dma-names = "tx", "rx";
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart4m1_xfer>;
 };
 
 &uart5 {
+	dma-names = "tx", "rx";
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart5m1_xfer>;
 };
 
 &uart9 {
+	dma-names = "tx", "rx";
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart9m1_xfer>;
 };
-- 
2.49.0

Re: [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property

[Heiko Stübner]

Hi,

Am Donnerstag, 18. September 2025, 11:32:46 Mitteleuropäische Sommerzeit schrieb Ed Wildgoose:
> Kernel appears to need a dma-names set for DMA to actually enable. Set a
> default dma-names property for all UARTs defined in the board
> definition: rk3566-radxa-zero-3.dtsi
> 
> This is tested on a Radxa Zero 3W (which has 5x UARTs) and removes the
> warnings and enables DMA on this platform

the kernel does not _need_ the dmas and the uart will work just fine
without.

And as was pointed out in the previous version, the uarts have possible
stability issues, when connected to specific peripherals

So I'd prefer to not enable uart dmas "just for fun".

Heiko


> Signed-off-by: Ed Wildgoose <lists@wildgooses.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi | 8 ++++++++
>  1 file changed, 8 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 e644bfc9c..fc26a4a52 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi
> @@ -488,21 +488,29 @@ &tsadc {
>  	status = "okay";
>  };
>  
> +&uart1 {
> +	dma-names = "tx", "rx";
> +};
> +
>  &uart2 {
> +	dma-names = "tx", "rx";
>  	status = "okay";
>  };
>  
>  &uart4{
> +	dma-names = "tx", "rx";
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&uart4m1_xfer>;
>  };
>  
>  &uart5 {
> +	dma-names = "tx", "rx";
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&uart5m1_xfer>;
>  };
>  
>  &uart9 {
> +	dma-names = "tx", "rx";
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&uart9m1_xfer>;
>  };
> 

Re: [PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs v2

[Heiko Stübner]

Hi Ed,

Am Donnerstag, 18. September 2025, 11:32:44 Mitteleuropäische Sommerzeit schrieb Ed Wildgoose:
> Based on feedback, I reworked these patches. I've re-presented both as
> I realise that one had invalid formatting (spaces vs tabs) and I've
> moved the dma-names definition into the same board level dtsi. At this
> point it seems reasonable to also squash the two patches, but feedback
> appreciated?
> 
> The default pinctrl definitions for the Radxa Zero 3W don't match the
> datasheet. Possibly few people enable extra UARTs and hence it wasn't
> noticed? I needed all 5 UARTs for a project and the first patch corrects
> the pinctrl defs. Without this patch, enabling the extra UARTs causes
> issues such as the MMC devices disappearing, due to collisions.
> 
> Second patch adds a dma-names property, which appears to be a
> pre-requisite for enabling DMA on the UARTs. I've applied this to the
> board level dts as feedback suggested there could be unintended problems
> if enabled across the complete rockchip dtsi.
> 
> It's tested on my Zero 3W board and appears to function correctly and
> DMA is reported as enabled.

housekeeping requests:
- please don't attach new versions to an old thread, but instead
  start a new thread
- this is supposed to be v2, so patches should be named
"[PATCH v2 0/2] ..." etc.

At least the cover-letter should contain a changelog what changed
between versions.


Heiko