TDA4VE-Q1: How to enable SPI and Slave Mode on spi7?

Dear customer, 

     Here is a patch, you can enable SPI DMA mode.

      /cfs-file/__key/communityserver-discussions-components-files/791/0361.0001_2D00_Test_5F00_spi_5F00_DMA.patch

   About SPI7, and slave mode,you can change accordingly. Any further issue,please feedback. Thanks.

Linjun

Hi,Linjun:

Our main application runs on the A72 side. If we enable SPI on the R5 core, we would additionally need IPC communication to forward the data, which is even more impractical. Therefore, we need to enable SPI on the A72 side to communicate with the external MCU for processing the relevant data.

Best regards!

hawayi

Hello Keerthy,

    Can we support slave SPI DMA mode on A72 of Linux Os?  Thanks. Keerthy J 

Best regards,

Linjun

3.2.2.17. SPI — Processor SDK Linux for J721s2 Documentation

here is one example from Linux user guide, but please help customer to provide the right dtso configure for one main SPI as slave mode for TDA4VE and Processor SDK Linux 9.2 which is a mass production baseline at present. especially we're unable to find the correct udma tx and rx psil-ID for SPI under current ti document when required to align with sysfw as well. 

thanks.  

Here is the pins config of SPI7

Hi Hawayi,

Please reference this FAQ for J722S for MCU SPI0 and Main SPI2:  [FAQ] J722SXH01EVM: How to enable McSPI on the 40 pin user expansion header for the J722SXH01EVM? 

FAQ also has a link for an application note that explains in detail for J721E. 

Please reference above to add to device tree for SPI7 to TDA4VE.

Regards,

Tali,a

Hi Tali,a:

How to verify if the configured DMA is functioning properly? What changes occur in the device nodes? When testing the spidev_test application in SPI7 slave mode without external devices connected, the application fails to exit and consumes over 95% CPU usage.

Best regards!

Hawayi

Hi Hawayi,

Currently traveling for work. Let me get back to you tomorrow on this.

Regards,

Takuma

Hi Hawayi,

My understanding is that PSIL threads were needed for enabling DMA for McSPI. J721S2/TDA4VE does not have PSIL threads for McSPI, so I do not think DMA is possible: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721s2/psil_cfg.html

However, let me double check with the author of this app note just in case I am wrong: https://www.ti.com/lit/an/sprad26/sprad26.pdf?ts=1758666511555&ref_url=https%253A%252F%252Fwww.google.com%252F

Regards,

Takuma

Waiting for your verification results, Thanks.

Hi Tali,a:

Here are my modifications, please help review if there are any errors. Thanks!

Index: arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts
===================================================================
--- arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts (revision 10713)
+++ arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts (working copy)
@@ -382,13 +383,19 @@
};

&main_spi7 {
+ status="okay";
pinctrl-names = "default";
pinctrl-0 = <&myspi1_pins_default>;
- status="okay";
- spidev@0 {
+ spi-slave;
+ //ti,pindir-d0-out-d1-in;
+ dmas = <&main_udmap 0xc600>, <&main_udmap 0x4600>;
+ dma-names = "tx0", "rx0";
+ slave@0 {
spi-max-frequency = <24000000>;
reg = <0>;
- compatible = "cisco,spi-petra";
+ compatible = "rohm,dh2228fv";
};
};

Index: drivers/dma/ti/k3-psil-j721s2.c
===================================================================
--- drivers/dma/ti/k3-psil-j721s2.c (revision 10713)
+++ drivers/dma/ti/k3-psil-j721s2.c (working copy)
@@ -248,6 +248,9 @@
/* SA2UL */
PSIL_SA2UL(0xf500, 1),
PSIL_SA2UL(0xf501, 1),
+
+ /* PDMA8 (PDMA_MISC_G0) - SPI0-1 */
+ PSIL_PDMA_XY_PKT(0xc600),
};

struct psil_ep_map j721s2_ep_map = {

Hi Tali,a:

    Is there any progress?

Best Regards!

hawayi

Hi Hawayi,

Checked with author of app note. Without PSIL, it is not possible to use DMA. So no support for DMA mode McSPI on J721S2.

Regards,

Takuma

Hi Takuma,

    Since the SPI slave mode depends on DMA, and the J721S2 cannot support DMA due to the absence of PSIL, SPI slave mode is also no longer supported?

Regards,

Hawayi

Hi Hawayi,

That is my understanding... but it does sound strange to me that this would be the case. J721E architecture is similar to J721S2/TDA4VE architecture, and I see that k3-psil-j721e.c uses the "MISC" PSIL threads for SPI for both RX and TX DMA.

J721S2 does not define these PSIL threads within k3-psil-j721s2.c for TX (although, RX PSIL are defined).

And further looking into our TISCI documentations (https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721s2/psil_cfg.html), it looks like the MISC TX threads that are in k3-psil-j721e.c should exist for J721S2 device as well

So what you have done should be correct...

Regards,

Takuma

Otherwise, perhaps the large CPU load is caused by this blocking call to spi_sync and DMA is already set up?

Below is description of spi_sync which is described as "blocking/synchronous SPI data transfers"

In spidev.c, I see that the file operation for .write is spidev_write which then calls into ->spidev_sync_write->spidev_sync->spi_sync.

Regards,

Takuma

Hi Takuma,

Does the TDA4VE's SPI actually support slave mode?

Regards,

Hawayi

Hi Liu,

Should support. I was looking into this a couple days back from your query and there have been engineers that have enabled SPI slave on Linux on AM68, which is the industrial variant of TDA4VE:  RE: SK-AM68: Enabling SPI Slave Mode and spidev 

Regards,

Takuma

Hi Takuma,

I tested the spidev_test application according to the documentation（ https://www.ti.com/lit/an/sprad26/sprad26.pdf?ts=1758666511555&ref_url=https%253A%252F%252Fwww.google.com%252F） and found that it hangs when sending data exceeding 159 bytes regardless of whether -p or -i parameters are used. Attached are the operation logs for your reference - please help verify what's causing this issue. Thank you!

Regards,

Hawayi

root@j721s2-evm:/data/cache# ls -l
total 144
drwxr-xr-x 3 root root  4096 Sep 19  2025 boot
-rw-r--r-- 1 root root   158 Apr 28 17:45 debug_txt
drwx------ 2 root root 16384 Aug 30  2022 lost+found
-rwxr-xr-x 1 root root 27280 Sep 19  2025 spidev_fdx
-rwxr-xr-x 1 root root 45072 Sep 23  2025 spidev_test
-rwxr-xr-x 1 root root 44176 Sep 19  2025 spidev_test_01
root@j721s2-evm:/data/cache# ./spidev_test -v -D /dev/spidev0.0 -i debug_txt
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)
[transfer] Line:150.
[transfer] Line:152.
TX | 74 68 65 72 77 69 73 65 2C 20 70 65 72 68 61 70 73 20 74 68 65 20 6C 61 72 67 65 20 43 50 55 20  |therwise, perhaps the large CPU |
TX | 6C 6F 61 64 20 69 73 20 63 61 75 73 65 64 20 62 79 20 74 68 69 73 20 62 6C 6F 63 6B 69 6E 67 20  |load is caused by this blocking |
TX | 63 61 6C 6C 20 74 6F C2 A0 73 70 69 5F 73 79 6E 63 20 61 6E 64 20 44 4D 41 20 69 73 20 61 6C 72  |call to..spi_sync and DMA is alr|
TX | 65 61 64 79 20 73 65 74 20 75 70 3F 0A 77 68 69 63 68 20 69 73 20 74 68 65 20 69 6E 64 75 73 74  |eady set up?.which is the indust|
TX | 72 69 61 6C 20 76 61 72 69 61 6E 74 20 6F 66 20 54 44 41 34 56 45 2E 68 61 77 61 79 69 0A __ __  |rial variant of TDA4VE.hawayi.|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF __ __  |..............................|
root@j721s2-evm:/data/cache# vi debug_txt 
root@j721s2-evm:/data/cache# ./spidev_test -v -D /dev/spidev0.0 -i debug_txt
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)
[transfer] Line:150.
[transfer] Line:152.
TX | 74 68 65 72 77 69 73 65 2C 20 70 65 72 68 61 70 73 20 74 68 65 20 6C 61 72 67 65 20 43 50 55 20  |therwise, perhaps the large CPU |
TX | 6C 6F 61 64 20 69 73 20 63 61 75 73 65 64 20 62 79 20 74 68 69 73 20 62 6C 6F 63 6B 69 6E 67 20  |load is caused by this blocking |
TX | 63 61 6C 6C 20 74 6F C2 A0 73 70 69 5F 73 79 6E 63 20 61 6E 64 20 44 4D 41 20 69 73 20 61 6C 72  |call to..spi_sync and DMA is alr|
TX | 65 61 64 79 20 73 65 74 20 75 70 3F 0A 77 68 69 63 68 20 69 73 20 74 68 65 20 69 6E 64 75 73 74  |eady set up?.which is the indust|
TX | 72 69 61 6C 20 76 61 72 69 61 6E 74 20 6F 66 20 54 44 41 34 56 45 2E 2E 68 61 77 61 79 69 0A __  |rial variant of TDA4VE..hawayi.|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF __  |...............................|
root@j721s2-evm:/data/cache# ls -l
total 144
drwxr-xr-x 3 root root  4096 Sep 19  2025 boot
-rw-r--r-- 1 root root   159 Apr 28 17:46 debug_txt
drwx------ 2 root root 16384 Aug 30  2022 lost+found
-rwxr-xr-x 1 root root 27280 Sep 19  2025 spidev_fdx
-rwxr-xr-x 1 root root 45072 Sep 23  2025 spidev_test
-rwxr-xr-x 1 root root 44176 Sep 19  2025 spidev_test_01
root@j721s2-evm:/data/cache# vi debug_txt 
root@j721s2-evm:/data/cache# ./spidev_test -v -D /dev/spidev0.0 -i debug_txt
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)
[transfer] Line:150.

root@j721s2-evm:/data/cache# ./spidev_test -v -D /dev/spidev0.0 -p "therwise, perhaps the large CPU load is caused by this blocking call spi_sync and DMA is already set up? which is the industrial variant of TDA4VE. hawayi....."
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)
[main] Line:483.
[transfer_escaped_string] Line:329.
[transfer] Line:150.
[transfer] Line:152.
TX | 74 68 65 72 77 69 73 65 2C 20 70 65 72 68 61 70 73 20 74 68 65 20 6C 61 72 67 65 20 43 50 55 20  |therwise, perhaps the large CPU |
TX | 6C 6F 61 64 20 69 73 20 63 61 75 73 65 64 20 62 79 20 74 68 69 73 20 62 6C 6F 63 6B 69 6E 67 20  |load is caused by this blocking |
TX | 63 61 6C 6C 20 73 70 69 5F 73 79 6E 63 20 61 6E 64 20 44 4D 41 20 69 73 20 61 6C 72 65 61 64 79  |call spi_sync and DMA is already|
TX | 20 73 65 74 20 75 70 3F 20 77 68 69 63 68 20 69 73 20 74 68 65 20 69 6E 64 75 73 74 72 69 61 6C  | set up? which is the industrial|
TX | 20 76 61 72 69 61 6E 74 20 6F 66 20 54 44 41 34 56 45 2E 20 68 61 77 61 79 69 2E 2E 2E 2E 2E __  | variant of TDA4VE. hawayi.....|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF __  |...............................|
[transfer_escaped_string] Line:331.
[main] Line:485.
root@j721s2-evm:/data/cache# ./spidev_test -v -D /dev/spidev0.0 -p "therwise, perhaps the large CPU load is caused by this blocking call spi_sync and DMA is already set up? which is the industrial variant of TDA4VE. hawayi......"
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)
[main] Line:483.
[transfer_escaped_string] Line:329.
[transfer] Line:150.

Hi Hawayi,

If some sort of loopback test is being done, looks like RX did not receive.

Can you check where in the kernel driver it is hanging? I suspect it is hanging in spidev.c spidev_write function, since it does a spidev_sync_write which eventually calls into __spi_sync function in spi.c, whch has a blocking call to wait_for_completion.

You can also confirm by taking a look at the source code:

• https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/spi/spi.c?h=ti-linux-6.1.y
• https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/spi/spidev.c?h=ti-linux-6.1.y

In the past on a different device that uses the same driver and same McSPI hardware as TDA4VE, I did not see hang issue when TX and RX were connected:  RE: PROCESSOR-SDK-J722S: mcspi slave mode hang?  

Regards,

Takuma

Hi Takuma

The issue might be similar to the one mentioned in this link（e2echina.ti.com/.../omap2-mcspi-dma）—could it be that DMA isn't working?

The macro defines DMA_MIN_BYTES = 160, meaning that when transmitting fewer than 160 bytes, using omap2_mcspi_txrx_pio(spi, t) works fine.

However, when exceeding 160 bytes, issues arise with omap2_mcspi_txrx_dma(spi, t)

Regards,

Hawayi

Hi Hawayi,

You bring up a good point. That does match the threshold for the number of bytes you were sending.

If you increase DMA_MIN_BYTES, do you see that the number of bytes you can transmit successfully also increase?

Regards,

Takuma

Yes, it is.

The issue is fixed, thank you very much!

Hi Liu,

Great to hear issue is fixed. If you do not mind, could I get details for how it was fixed for future reference?

Regards,

Takuma

hi Takuma,

I changed the dma id to 0xc610(tx)/0x4610(rx), but there still something wrong with the kernel show as below, what's matter?

[ 0.118136] ti-udma 31150000.dma-controller: Channels: 60 (tchan: 30, rchan: 30, gp-rflow: 16)
[ 1.550984] ti-udma 31150000.dma-controller: PSI-L pairing failed: 0x4610 -> 0x9005
[ 1.623617] ti-udma 31150000.dma-controller: get channel fail in udma_of_xlate.

Regards,

Hawayi