IMX8M Mini Kernal SPI Driver Issue

[Dhevan]

Hi,

     BSP Version - imx-yocto-L5.4.24_2.1.0

     I have enabled ecspi2 on kernel device tree file.

     I had faced another issue firmware error (https://community.nxp.com/t5/i-MX-Processors/Yocto-build-external-firmware-error/m-p/1232438/emcs_t/...) then sdma made as loadable module.

    If am see boot log spi devier printing some trace errors.

Welcome to NXP i.MX Release Distro 5.4-zeus (zeus)!

[    3.939435] systemd[1]: Set hostname to <pteth3>.
[    4.058371] systemd[1]: /lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket ��→ /run/dbus/system_bus_socket; p.
[    4.113413] systemd[1]: /lib/systemd/system/rngd.service:21: Unknown key name 'ProtectKernelLogs' in section 'Service', ignoring.
[    4.149987] random: systemd: uninitialized urandom read (16 bytes read)
[    4.156770] systemd[1]: system-getty.slice: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling.
[    4.169144] systemd[1]: (This warning is only shown for the first unit using IP firewalling.)
[    4.179375] systemd[1]: Created slice system-getty.slice.
[  OK  ] Created slice system-getty.slice.
[    4.203118] random: systemd: uninitialized urandom read (16 bytes read)
[    4.210919] systemd[1]: Created slice system-serial\x2dgetty.slice.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[    4.235263] random: systemd: uninitialized urandom read (16 bytes read)
[    4.243012] systemd[1]: Created slice User and Session Slice.
[  OK  ] Created slice User and Session Slice.
[  OK  ] Started Dispatch Password ��…ts to Console Directory Watch.
[  OK  ] Started Forward Password R��…uests to Wall Directory Watch.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Remote File Systems.
[  OK  ] Reached target Slices.
[  OK  ] Reached target Swap.
[  OK  ] Listening on Syslog Socket.
[  OK  ] Listening on initctl Compatibility Named Pipe.
[  OK  ] Listening on Journal Audit Socket.
[  OK  ] Listening on Journal Socket (/dev/log).
[  OK  ] Listening on Journal Socket.
[  OK  ] Listening on Network Service Netlink Socket.
[  OK  ] Listening on udev Control Socket.
[  OK  ] Listening on udev Kernel Socket.
         Mounting Huge Pages File System...
         Mounting POSIX Message Queue File System...
         Mounting Kernel Debug File System...
         Mounting Temporary Directory (/tmp)...
         Starting Create list of st��…odes for the current kernel...
         Starting Journal Service...
         Mounting Kernel Configuration File System...
         Starting Remount Root and Kernel File Systems...
[    4.606232] EXT4-fs (mmcblk2p2): re-mounted. Opts: (null)
         Starting Apply Kernel Variables...
         Starting udev Coldplug all Devices...
[  OK  ] Started Journal Service.
[  OK  ] Mounted Huge Pages File System.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Mounted Kernel Debug File System.
[  OK  ] Mounted Temporary Directory (/tmp).
[  OK  ] Started Create list of sta��… nodes for the current kernel.
[  OK  ] Mounted Kernel Configuration File System.
[  OK  ] Started Remount Root and Kernel File Systems.
[  OK  ] Started Apply Kernel Variables.
         Starting Flush Journal to Persistent Storage...
[    4.815026] systemd-journald[377]: Received client request to flush runtime journal.
         Starting Create Static Device Nodes in /dev...
[  OK  ] Started Flush Journal to Persistent Storage.
[  OK  ] Started Create Static Device Nodes in /dev.
[  OK  ] Reached target Local File Systems (Pre).
         Mounting /var/volatile...
         Starting udev Kernel Device Manager...
[  OK  ] Started udev Coldplug all Devices.
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Mounted /var/volatile.
         Starting Network Service...
         Starting Load/Save Random Seed...
[  OK  ] Reached target Local File Systems.
         Starting Create Volatile Files and Directories...
[  OK  ] Started Network Service.
[  OK  ] Started Create Volatile Files and Directories.
[  OK  ] Started Hardware RNG Entropy Gatherer Daemon.
         Starting Network Name Resolution...
         Starting Network Time Synchronization...
         Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Started Update UTMP about System Boot/Shutdown.
[    5.183424] random: crng init done
[    5.187120] random: 7 urandom warning(s) missed due to ratelimiting
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Network Name Resolution.
[  OK  ] Reached target Network.
[  OK  ] Reached target Host and Network Name Lookups.
[  OK  ] Started Network Time Synchronization.
[  OK  ] Reached target System Initialization.
[  OK  ] Started Daily Cleanup of Temporary Directories.
[    5.331899] imx-sdma 302c0000.dma-controller: loaded firmware 4.5
[  OK  ] Reached target System Time Set.
[    5.349409] fsl-spdif-dai 30090000.spdif: Unbalanced pm_runtime_enable!
[  OK  ] Reached target System Time Synchronized.
[    5.372821] imx-spdif sound-spdif: snd-soc-dummy-dai <-> 30090000.spdif mapping ok
[    5.380497] imx-spdif sound-spdif: ASoC: no DMI vendor name!
[  OK  ] Reached target Timers.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[    5.415618] ------------[ cut here ]------------
[    5.420287] /soc@0/bus@30800000/spi@30820000/spidev@0x00: buggy DT: spidev listed directly in DT
[    5.435161] WARNING: CPU: 2 PID: 21 at drivers/spi/spidev.c:726 spidev_probe+0x104/0x220
[    5.443259] Modules linked in: imx_sdma
[    5.447110] CPU: 2 PID: 21 Comm: kworker/2:0 Not tainted 5.4.24-2.1.0+gbabac008e5cf #1
[    5.455035] Hardware name: FSL i.MX8MM EVK board (DT)
[    5.460106] Workqueue: events deferred_probe_work_func
[    5.465272] pstate: 40000005 (nZcv daif -PAN -UAO)
[    5.465282] pc : spidev_probe+0x104/0x220
[    5.465285] lr : spidev_probe+0x104/0x220
[    5.465287] sp : ffff800011ccb7c0
[    5.465289] x29: ffff800011ccb7c0 x28: ffff8000119c6000 
[    5.465292] x27: ffff00007be1c000 x26: ffff800011a36558 
         [    5.465295] x25: 0000000000000000 x24: 000000000000002b 
[    5.465298] x23: ffff800011a46148 x22: 0000000000000000 
Starting sshd.socket[    5.465301] x21: ffff800011a46128 x20: ffff00007be1c800 
.
[    5.465303] x19: 0000000000000000 x18: 0000000000000000 
[    5.465306] x17: 0000000000000000 x16: 0000000000000000 
[    5.465309] x15: 0000000000000000 x14: 0000000000000000 
[    5.465311] x13: 00002e1922ea5295 x12: 0000000000000001 
[    5.465314] x11: 0000000000000000 x10: 00000000000009c0 
[    5.465317] x9 : ffff800011ccb4f0 x8 : ffff00007a0fd020 
[    5.465320] x7 : ffff00007a0fc780 x6 : ffff00007fba54c0 
[    5.465323] x5 : 0000000000000000 x4 : ffff00007fb9a188 
[    5.465325] x3 : ffff00007fba0f20 x2 : ffff00007fb9a188 
[    5.465328] x1 : 734649f3bd8b2900 x0 : 0000000000000000 
[    5.465331] Call trace:
[    5.465336]  spidev_probe+0x104/0x220
[    5.465340]  spi_drv_probe+0x7c/0xd8
[    5.465343]  really_probe+0xd4/0x318
[    5.465347]  driver_probe_device+0x54/0xe8
[    5.465350]  __device_attach_driver+0x80/0xb8
[    5.465353]  bus_for_each_drv+0x74/0xc0
[    5.465356]  __device_attach+0xdc/0x138
[    5.465358]  device_initial_probe+0x10/0x18
[    5.465361]  bus_probe_device+0x90/0x98
[    5.465364]  device_add+0x378/0x648
[    5.465366]  spi_add_device+0xe4/0x1c8
[    5.465370]  of_register_spi_device+0x204/0x3c8
[    5.465372]  spi_register_controller+0x3dc/0x790
[    5.465376]  spi_bitbang_start+0x34/0x80
[    5.465379]  spi_imx_probe+0x448/0x688
[    5.465381]  platform_drv_probe+0x50/0xa0
[    5.465384]  really_probe+0xd4/0x318
[    5.465387]  driver_probe_device+0x54/0xe8
[    5.465390]  __device_attach_driver+0x80/0xb8
[    5.465392]  bus_for_each_drv+0x74/0xc0
[    5.465395]  __device_attach+0xdc/0x138
[    5.465398]  device_initial_probe+0x10/0x18
[    5.465401]  bus_probe_device+0x90/0x98
[    5.465403]  deferred_probe_work_func+0x64/0x98
[    5.465408]  process_one_work+0x198/0x320
[    5.465411]  worker_thread+0x48/0x420
[    5.465416]  kthread+0xf0/0x120
[    5.465420]  ret_from_fork+0x10/0x18
[    5.465423] ---[ end trace d8a5b0d0624ff12f ]---
[    5.475254] spi_imx 30820000.spi: probed
[  OK  ] Listening on sshd.socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Basic System.
[    5.755311] ------------[ cut here ]------------
[    5.759996] /soc@0/bus@30800000/spi@30830000/spidev@0x00: buggy DT: spidev listed directly in DT
[  OK  ] Reached target Sound Card.
[    5.775993] WARNING: CPU: 2 PID: 21 at drivers/spi/spidev.c:726 spidev_probe+0x104/0x220
[    5.780859] Atheros 8031 ethernet 30be0000.ethernet-1:00: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)
[    5.785045] Modules linked in: crct10dif_ce(+) imx_sdma
[    5.785056] CPU: 2 PID: 21 Comm: kworker/2:0 Tainted: G        W         5.4.24-2.1.0+gbabac008e5cf #1
[    5.785057] Hardware name: FSL i.MX8MM EVK board (DT)
[    5.785068] Workqueue: events deferred_probe_work_func
[    5.823523] pstate: 40000005 (nZcv daif -PAN -UAO)
[    5.828340] pc : spidev_probe+0x104/0x220
[    5.828344] lr : spidev_probe+0x104/0x220
[    5.828346] sp : ffff800011ccb7c0
[    5.828347] x29: ffff800011ccb7c0 x28: ffff8000119c6000 
[    5.828351] x27: ffff00007be1d000 x26: ffff800011a36558 
[    5.828354] x25: 0000000000000000 x24: 000000000000002d 
[    5.828356] x23: ffff800011a46148 x22: 0000000000000000 
[  OK  [    5.828359] x21: ffff800011a46128 x20: ffff00007be1d800 
[    5.828362] x19: 0000000000000000 x18: 0000000000000000 
[    5.828365] x17: 0000000000000000 x16: 0000000000000000 
[    5.828367] x15: 0000000000000000 x14: 0000000000000000 
[    5.828370] x13: 00008ef6db7464aa x12: 0000000000000001 
] [    5.828373] x11: 0000000000000000 x10: 00000000000009c0 
[    5.828376] x9 : ffff800011ccb4f0 x8 : 0000000000000001 
[    5.828378] x7 : 0000000000000000 x6 : 0000000000000002 
Started Kernel Logging S[    5.828381] x5 : 0000000000000000 x4 : ffff00007fb9a188 
ervice.[    5.828384] x3 : ffff00007fba0f20 x2 : ffff00007fb9a188 
[    5.828386] x1 : 734649f3bd8b2900 x0 : 0000000000000000 
[    5.828390] Call trace:
[    5.828394]  spidev_probe+0x104/0x220
[    5.828397]  spi_drv_probe+0x7c/0xd8
[    5.828402]  really_probe+0xd4/0x318

[    5.828406]  driver_probe_device+0x54/0xe8
[    5.828409]  __device_attach_driver+0x80/0xb8
[    5.828412]  bus_for_each_drv+0x74/0xc0
[    5.828414]  __device_attach+0xdc/0x138
[    5.828417]  device_initial_probe+0x10/0x18
[    5.828420]  bus_probe_device+0x90/0x98
[    5.828422]  device_add+0x378/0x648
[    5.828425]  spi_add_device+0xe4/0x1c8
[    5.828428]  of_register_spi_device+0x204/0x3c8
[    5.828431]  spi_register_controller+0x3dc/0x790
[    5.828434]  spi_bitbang_start+0x34/0x80
[    5.828438]  spi_imx_probe+0x448/0x688
[    5.828440]  platform_drv_probe+0x50/0xa0
[    5.828443]  really_probe+0xd4/0x318
[    5.828446]  driver_probe_device+0x54/0xe8
[    5.828449]  __device_attach_driver+0x80/0xb8
[    5.828451]  bus_for_each_drv+0x74/0xc0
[    5.828454]  __device_attach+0xdc/0x138
[    5.828457]  device_initial_probe+0x10/0x18
[    5.828460]  bus_probe_device+0x90/0x98
[    5.828463]  deferred_probe_work_func+0x64/0x98
[    5.828468]  process_one_work+0x198/0x320
[    5.828471]  worker_thread+0x48/0x420
[    5.828477]  kthread+0xf0/0x120
[    5.828481]  ret_from_fork+0x10/0x18
[    5.828484] ---[ end trace d8a5b0d0624ff130 ]---
[    5.875303] spi_imx 30830000.spi: probed
[  OK  ] Started System Logging Service.
[  OK  ] Started D-Bus System Message Bus.
         Starting Login Service...
         Starting Permit User Sessions...
[  OK  ] Started Target Communication Framework agent.
[  OK  ] Started TEE Supplicant.
[  OK  ] Started Permit User Sessions.
[  OK  ] Started Login Service.
[  OK  ] Started Getty on tty1.
[  OK  ] Started Serial Getty on ttymxc1.
[  OK  ] Reached target Login Prompts.
[  OK  ] Reached target Multi-User System.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.

    Why kernel having issue on spi driver ?

    Please help us to solve above issue.

Thanks & Regards,

       Vasu

[weidong_sun]

yes, right.

I just prepared code for you, for you reference:

for example, use ecspi2 to do a loopback test, MOSI and MISO should be conneted together.
....
pinctrl_ecspi2: ecspi2grp {
fsl,pins = <
MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK 0x82
MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI 0x82
MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO 0x82
>;
};

pinctrl_ecspi2_cs: ecspi2cs {
fsl,pins = <
MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 0x40000
>;
};
....

&ecspi2 {
#address-cells = <1>;
#size-cells = <0>;
fsl,spi-num-chipselects = <1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>;
cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
status = "okay";

spidev0: spi@0 {
reg = <0>;
compatible = "rohm,dh2228fv";
spi-max-frequency = <500000>;
};
};

Have a nice day!

weidong

[ceggers1]

Hi Vasu,

the problem is not in the SPI driver but in your device tree. Can you please post the spi sections of your tree?

regards
Christian

[Dhevan]

Hi @ceggers1,

      Please look into attached spi device tree configuration.

        pinctrl_ecspi2: ecspi2grp {
                 fsl,pins = <
                        MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO 0x00000116
                        MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI 0x00000116
                        MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK 0x00001916
                        MX8MM_IOMUXC_ECSPI2_SS0_ECSPI2_SS0 0x00000116
                >;
        };

&ecspi2 {
        fsl,spi-num-chipselects = <1>;
        cs-gpios = <0>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ecspi2>;
        status = "okay";
        spidev@0x00 {
            compatible = "spidev";
            spi-max-frequency = <10000000>;
        spi-cs-high;
        reg = <0>;
        };
};

 Thanks & Regards,

         Vasu

[ceggers]

Hi Vasu,

instead of setting "compatible" to "spidev", you should extend the table in drivers/spi/spidev.c:

#ifdef CONFIG_OF
static const struct of_device_id spidev_dt_ids[] = {
	{ .compatible = "rohm,dh2228fv" },
	{ .compatible = "lineartechnology,ltc2488" },
	{ .compatible = "ge,achc" },
	{ .compatible = "semtech,sx1301" },
	{ .compatible = "lwn,bk4" },
	{ .compatible = "dh,dhcom-board" },
	{ .compatible = "menlo,m53cpld" },
	{ .compatible = "<company>,<device>" },
	{},
};
MODULE_DEVICE_TABLE(of, spidev_dt_ids);
#endif

After that, you should set compatible to "<company>,<device>" in your device tree.

May I ask what kind of SPI device you want to interface? Maybe there is an existing kernel driver.

regards
Christian

[Dhevan]

Hi @ceggers ,

       Thanks for your reply.

       We are using ad7940 and knx134 sensors.

       User space device driver already done.

       Which one is generic kernal driver(spidev_dt_ids) ?

Thanks & Regards,

     Vasu

[ceggers]

You can choose the compatible string in spidev_dt_ids freely, but it must match the compatible string in your device tree. You should avoid re-using already existing compatible strings, as an existing kernel driver may hijack your hardware.

[Dhevan]

Hi @ceggers ,

     Two sensors in our user space code we are reading parallel. 

     Are you telling two spi peripheral(ECSPI1, ECSPI3) should not same compatible names ?

Thanks & Regards,

         Vasu

[ceggers1]

The SPI masters (ecspiN) must use the original compatible strings. But the compatible strings for the two sensors (SPI devices) should be chosen in a way that not builtin kernel driver binds to these peripherals. Otherwise you will probably not be able to control them from user space.

regards
Christian

[Dhevan]

Hi @ceggers1,

     We have configured two different spi interface.

     In our user space code we are reading two spi parallel (one spi 14k data another spi 1024 data per second) but we are facing issue for data loss.

     User space code we have tried mutex and thread sync but no use we unable to achieve 14k data read per second.

      Now we are thinking like one spi for linux and another spi for m4 core reads the data.

      M4 code read data has to transfer linux user space code.

      Do you have any suggestion to solve two spi parallel read data loss issue ?

Thanks & Regards,

      Vasu

[ceggers1]

Hi Vasu,

> In our user space code we are reading two spi parallel 
from you description I assume that you use spidev for this. Is this correct?

> but we are facing issue for data loss.
In case of spidev this might be related to this:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa9e862d7d5bcecd4dca9f...

> we unable to achieve 14k data read per second.
Please provide some more details how you exactly transfer data via SPI. Doing (S)DMA transfers with small amounts of data is usually very inefficient. Transferring more bytes within a single transfer may improve performance.

> Now we are thinking like one spi for linux and another spi for m4 core reads the data.
I don't think that you can share a SDMA instance between both processor cores. So you'll have to work without SDMA on the M4 core. Also note that the bottleneck may be at internal bus where the SPI masters are connected.

regards
Christian

[Dhevan]

We are taking sensor stored data file from imx8mm custom board calculating FFT then we got to know frequency does not matching with our poc imxrt sensor tested data.

Only one spi reading data that time matching with our poc sensor data.

[Dhevan]

Hi @ceggers1 

      Thanks for your response.

      > In our user space code we are reading two spi parallel

           yeah, two spi configured in device tree file.

        pinctrl_ecspi2: ecspi2grp { 
                fsl,pins = <
                        MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK 0x82
                        MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI 0x82
                        MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO 0x82
                >;
        };

        pinctrl_ecspi2_cs: ecspi2cs {
                fsl,pins = <
                        MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 0x40000
                >;
        };

        pinctrl_ecspi1: ecspi1grp { 
                fsl,pins = <
                       MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x82
                       MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x82
                       MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x82
                >;
        };

        pinctrl_ecspi1_cs: ecspi1cs {
                fsl,pins = <
                       MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x40000
                >;
        };
		
		&ecspi2 {
        #address-cells = <1>;
        #size-cells = <0>;
        fsl,spi-num-chipselects = <1>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>;    
        cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
        status = "okay";

        spidev0: spi@0 {
          reg = <0>;
          compatible = "rohm,dh2228fv";
          spi-max-frequency = <5000000>;
        };
};

&ecspi1 {
        #address-cells = <1>;
        #size-cells = <0>;
        fsl,spi-num-chipselects = <1>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>;    
        cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
        status = "okay";

        spidev1: spi@0 {
          reg = <0>;
          compatible = "dh,dhcom-board";
          spi-max-frequency = <5000000>;
        };
};

    > but we are facing issue for data loss

          In while loop we unable to get proper count data one second timer was running to monitor while look it's not fixed count varies to (13k to 23k data per second)

          If we comment another spi thread we are getting 14k data per second.

          If two spi thread runs we facing issue for data loss.

          We have tried first line one spi read with 3.5MHZ and next line read another spi 1MHZ but we unable to achieve 14k data only we getting 8k data per second.

    > we unable to achieve 14k data read per second.

         one spi we are reading 6bytes and another spi 2bytes of data

         Where need to change sdma transfer size ?

   > Now we are thinking like one spi for linux and another spi for m4 core reads the data.

        In M4 spi code keep on reads spi data and send via some ipc mechanism to linux user space code. Is this possible.

 Thanks & Regards,

        Vasu

[ceggers]

Hi Vasu,

I assume that you are still using the ad7940 and knx134 sensors and not rohm,dh2228fv / dhcom-board... As the AD7940 is an ADC and you mentioned "FFT" a few months ago, I assume that you need to get samples from the ADC in a fixed time interval.

When using internal ADCs (on other micro controllers), you can usually control the sample rate of the ADC. Depending on the conversion settings (number of bits, sample time, number of samples to integrate, ...) the ADC needs a particular number of clock cycles for each conversion. So you can at least control the conversion rate by modifying the ADC's clock frequency. On some µC you can additionally connect a general purpose timer as a trigger in order to get accurate control over the interval between each conversion.

When using an external ADC (as in your case), the controller (= the software) is responsible for "triggering" each individual conversion of the ADC. As the software is running under an operating systems scheduler, I doubt the resulting values will be adequate for further signal processing. The timing jitter of the converted data should become better, when using a more precise "clock" for starting the conversion.

Instead of using SPI (where each conversion/transfer has to be started manually), you may check whether the i.MX SAI can be used for this. The SAI should provide some kind of "frame" signal which can be used to start the conversion (CS signal). Compared to SPI, the SAI will perform "cyclic" transfers itself. Software (SDMA) only has to processes the acquired data.

regards
Christian

[Dhevan]

Hi @ceggers,

        Thanks for your reply.

        Already hardware designed now can't use SAI interface.

        If we wrote kernel driver for both sensor this issue will resolve instant of calling from user space ?

        Now am trying to implement one spi for linux user space another spi for m4 core to solve the issue.

Thanks & Regards,

        Vasu

[ceggers]

Hi Vasu,

if you can't use the SAI peripheral, I would try to implement the ADC driver on the M4 or the SDMA. In both cases I would use a timer (EPIT or GPT) for generating a cyclic interrupt (period of the ADC measurement). From the timer handler, you can trigger a single SPI transfer then.

Unfortunately I cannot provide examples for M4 to Cortex-A communication. I work with i.MX6 ULL which only has a SDMA but no M4. In every case you should avoid passing every single ADC value to the Cortex-A individually (as this is quite inefficient). Instead you should aggregate as much data as possible on the M4 / SDMA and pass it as a bigger chunk to the Cortex-A.

regards
Christian