[PATCH v3 0/2] Reserve eDMA channels 0-1 for V2X

[PATCH v3 0/2] Reserve eDMA channels 0-1 for V2X

[Joy Zou]

---
Changes in v3:
- extract the imx95-19x19-evk-sof.dts changes into a separate patch.
- Link to v2: https://lore.kernel.org/r/20260123-b4-imx95-v2x-v2-1-0497a9814668@nxp.com

Changes in v2:
- modify imx95-19x19-evk-sof.dts dma-channel-mask property.
- add comments for mask channel.
- add Reviewed-by and Tested-by tag, tested on MX95-15x15-FRDM, MX95-19x19-EVK.
- Link to v1: https://lore.kernel.org/r/20260120-b4-imx95-v2x-v1-1-52b2025b27a0@nxp.com

---
Joy Zou (2):
      arm64: dts: imx95: Reserve eDMA channels 0-1 for V2X
      arm64: dts: imx95-evk: update the dma-channel-mask property

 arch/arm64/boot/dts/freescale/imx95-19x19-evk-sof.dts | 7 +++++--
 arch/arm64/boot/dts/freescale/imx95.dtsi              | 2 ++
 2 files changed, 7 insertions(+), 2 deletions(-)
---
base-commit: d08c85ac8894995d4b0d8fb48d2f6a3e53cd79ab
change-id: 20260120-b4-imx95-v2x-3e01c7bc6881

Best regards,
-- 
Joy Zou <joy.zou@nxp.com>

[PATCH v3 1/2] arm64: dts: imx95: Reserve eDMA channels 0-1 for V2X

[Joy Zou]

Reserve eDMA channels 0 and 1 on the AXI eDMA controller for exclusive
use by V2X (Vehicle-to-Everything) fast hash operations.

Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Tested-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx95.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 55e2da094c889fc7c1096d0e36f31ae118d2a982..9ac82da2ff440e08ae8378d7ff830a568d50a354 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -631,6 +631,8 @@ edma2: dma-controller@42000000 {
 				reg = <0x42000000 0x210000>;
 				#dma-cells = <3>;
 				dma-channels = <64>;
+				/* channels 0 and 1 reserved for V2X fast hash */
+				dma-channel-mask = <0x3>;
 				interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
 					     <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
 					     <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,

-- 
2.37.1

[PATCH v3 2/2] arm64: dts: imx95-evk: update the dma-channel-mask property

[Joy Zou]

Have reserved eDMA2 channels 0 and 1 for V2X fast hash in imx95.dtsi.
So update the dma-channel-mask from 0xc0000000 to 0xc0000003 to mark
channels 0, 1, 30, and 31 as reserved.

Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx95-19x19-evk-sof.dts | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk-sof.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk-sof.dts
index 808a9fe3ebb2b9557be9e428583e76c32517de08..264703f6eef64813d64fe07713cf92fd02fa0778 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk-sof.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk-sof.dts
@@ -55,8 +55,11 @@ sound-wm8962 {
 };
 
 &edma2 {
-	/* channels 30 and 31 reserved for FW usage */
-	dma-channel-mask = <0xc0000000>, <0x0>;
+	/*
+	 * channels 0 and 1 reserved for V2X fast hash,
+	 * channels 30 and 31 reserved for FW usage
+	 */
+	dma-channel-mask = <0xc0000003>, <0x0>;
 };
 
 &sai3 {

-- 
2.37.1

Re: [PATCH v3 1/2] arm64: dts: imx95: Reserve eDMA channels 0-1 for V2X

[Peng Fan]

Hi Joy,

Sorry to jump in at V3.

On Fri, Jan 30, 2026 at 05:36:27PM +0800, Joy Zou wrote:
>Reserve eDMA channels 0 and 1 on the AXI eDMA controller for exclusive
>use by V2X (Vehicle-to-Everything) fast hash operations.
>
>Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>Tested-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>Signed-off-by: Joy Zou <joy.zou@nxp.com>
>---
> arch/arm64/boot/dts/freescale/imx95.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
>index 55e2da094c889fc7c1096d0e36f31ae118d2a982..9ac82da2ff440e08ae8378d7ff830a568d50a354 100644
>--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
>+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
>@@ -631,6 +631,8 @@ edma2: dma-controller@42000000 {
> 				reg = <0x42000000 0x210000>;
> 				#dma-cells = <3>;
> 				dma-channels = <64>;
>+				/* channels 0 and 1 reserved for V2X fast hash */
>+				dma-channel-mask = <0x3>;

This is wrong. Per dt-binding,
dma-channel-mask means Bitmask of available DMA channels in ascending order,
The usage in this patch does not match the dt-binding.

Regards
Peng

Re: [PATCH v3 1/2] arm64: dts: imx95: Reserve eDMA channels 0-1 for V2X

[Laurentiu Mihalcea]

On 2/1/2026 7:22 PM, Peng Fan wrote:
> Hi Joy,
>
> Sorry to jump in at V3.
>
> On Fri, Jan 30, 2026 at 05:36:27PM +0800, Joy Zou wrote:
>> Reserve eDMA channels 0 and 1 on the AXI eDMA controller for exclusive
>> use by V2X (Vehicle-to-Everything) fast hash operations.
>>
>> Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>> Tested-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>> Signed-off-by: Joy Zou <joy.zou@nxp.com>
>> ---
>> arch/arm64/boot/dts/freescale/imx95.dtsi | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
>> index 55e2da094c889fc7c1096d0e36f31ae118d2a982..9ac82da2ff440e08ae8378d7ff830a568d50a354 100644
>> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
>> @@ -631,6 +631,8 @@ edma2: dma-controller@42000000 {
>> 				reg = <0x42000000 0x210000>;
>> 				#dma-cells = <3>;
>> 				dma-channels = <64>;
>> +				/* channels 0 and 1 reserved for V2X fast hash */
>> +				dma-channel-mask = <0x3>;
> This is wrong. Per dt-binding,
> dma-channel-mask means Bitmask of available DMA channels in ascending order,
> The usage in this patch does not match the dt-binding.


Ah, good catch. It would seem like our EDMA driver reverses the meaning of the "dma-channel-mask"

bits (i.e. bit x set means channel x reserved instead of channel x available).


Now, I wonder how we should be proceeding with this. According to the DT binding, our devicetree

configurations are wrong. Since there seem to be only 8 upstream instances in which this property is

being used I guess it wouldn't be so difficult to correct the driver's behavior and then correct the

devicetrees?