On FRDM-i.MX8MP (Linux 6.12.34-lts-next), ALSA capture on wm8962 works fine until the Cortex-M7 is started via remoteproc. After any M7 firmware starts, arecord triggers a kernel panic.Summary:- Without M7: arecord OK- After starting M7: panic in fsl_sai_runtime_resume
→ regmap_write (SError 0xbf000002)- Reproduced with BSP stock firmwares:- imx8mp_m7_DDR_hello_world.elf- imx8mp_m7_DDR_rpmsg_lite_str_echo_rtos.elfSo this does not look specific to our custom M7 app.Reproduce:1) Boot Linux, keep M7 stopped2) arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t.wav → OK3) echo stop > /sys/class/remoteproc/remoteproc0/stateecho imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmwareecho start > /sys/class/remoteproc/remoteproc0/state4) same arecord → Kernel panic (SError)Panic path (abbreviated):snd_pcm_capture_open → ... → fsl_sai_runtime_resume → regmap_write → SError 0xbf000002Tried:- Remove optional "audio" (AUDPLL) clock from imx8mp-cm7 DT node → still fails- Disable AudioMIX ownership / Audio PLL init in our M7 clock_config → still fails with stock hello_world anywayQuestions:1) Is concurrent use of Linux SAI/wm8962 and M7 remoteproc supported on i.MX8MP?2) Does SDK BOARD_BootClockRUN() mapping AudioMIX to M7 conflict with A53 audio power domain?3) Any known 6.12 fixes for AudioMIX / fsl_sai runtime resume SError?4) Recommended clock_config for M7 when audio must remain owned by Linux (UART/RPMsg only on M7)?Thanks.------------------------- imx8mp-cm7 dts node --------------------------
imx8mp-cm7 {compatible = "fsl,imx8mn-cm7";rsc-da = <0x55000000>;clocks = <&clk IMX8MP_CLK_M7_DIV>;//<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;clock-names = "core", "uart4";mbox-names = "tx", "rx", "rxdb";mboxes = <&mu 0 1&mu 1 1&mu 3 1>;memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>,<&m4_reserved>;status = "okay";fsl,startup-delay-ms = <500>;};------------------ Panic log ------------------root@FRDM-test:/lib/firmware# echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware
root@FRDM-test:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state
root@FRDM-test:/lib/firmware#
root@FRDM-test:/lib/firmware#
root@FRDM-test:/lib/firmware#
root@FRDM-test:/lib/firmware# arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t_ex.wav
[ 58.448085] SError Interrupt on CPU0, code 0x00000000bf000002 -- SError
[ 58.448101] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: G C O 6.12.34-lts-next #1
[ 58.448109] Tainted: [C]=CRAP, [O]=OOT_MODULE
[ 58.448111] Hardware name: NXP FRDM-IMX8MPLUS (DT)
[ 58.448113] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 58.448118] pc : _raw_spin_unlock_irqrestore+0x10/0x50
[ 58.448130] lr : regmap_unlock_spinlock+0x14/0x20
[ 58.448136] sp : ffff8000854e3670
[ 58.448138] x29: ffff8000854e3670 x28: ffff8000854e3c30 x27: 0000000000000001
[ 58.448147] x26: ffff0000d06da088 x25: 0000000000000000 x24: ffff0000d06da390
[ 58.448153] x23: ffff0000d1c18f60 x22: ffff0000d0363c10 x21: 0000000001000000
[ 58.448160] x20: 0000000000000000 x19: ffff0000d14a3000 x18: 0000000000000002
[ 58.448168] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 58.448174] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 58.448180] x11: 0000000000000000 x10: ffff0000dccabb90 x9 : 0000000000000390
[ 58.448188] x8 : ffff0000dccabbac x7 : ffff8000854e3940 x6 : ffff0000dccabba0
[ 58.448194] x5 : ffff8000808ed440 x4 : 0000000000000008 x3 : ffff8000808ece60
[ 58.448200] x2 : 0000000001000000 x1 : ffff0000dcca5280 x0 : 0000000100000001
[ 58.448208] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 58.448211] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: G C O 6.12.34-lts-next #1
[ 58.448217] Tainted: [C]=CRAP, [O]=OOT_MODULE
[ 58.448221] Hardware name: NXP FRDM-IMX8MPLUS (DT)
[ 58.448223] Call trace:
[ 58.448225] dump_backtrace.part.0+0xd4/0xe0
[ 58.448234] show_stack+0x18/0x30
[ 58.448240] dump_stack_lvl+0x60/0x80
[ 58.448246] dump_stack+0x18/0x24
[ 58.448251] panic+0x168/0x360
[ 58.448258] add_taint+0x0/0xbc
[ 58.448264] arm64_serror_panic+0x64/0x70
[ 58.448269] do_serror+0x3c/0x70
[ 58.448273] el1h_64_error_handler+0x30/0x54
[ 58.448279] el1h_64_error+0x64/0x68
[ 58.448283] _raw_spin_unlock_irqrestore+0x10/0x50
[ 58.448289] regmap_write+0x58/0x80
[ 58.448294] fsl_sai_runtime_resume+0xc4/0x280 [snd_soc_fsl_sai]
[ 58.448304] pm_generic_runtime_resume+0x2c/0x44
[ 58.448312] __genpd_runtime_resume+0x30/0x80
[ 58.448318] genpd_runtime_resume+0x130/0x2c4
[ 58.448325] __rpm_callback+0x48/0x1e0
[ 58.448330] rpm_callback+0x68/0x80
[ 58.448334] rpm_resume+0x3bc/0x6a0
[ 58.448340] __pm_runtime_resume+0x50/0x9c
[ 58.448344] snd_soc_pcm_component_pm_runtime_get+0x3c/0x138
[ 58.448350] __soc_pcm_open+0x60/0x488
[ 58.448355] soc_pcm_open+0x30/0x58
[ 58.448359] snd_pcm_open_substream+0x594/0x850
[ 58.448364] snd_pcm_open+0x118/0x24c
[ 58.448368] snd_pcm_capture_open+0x4c/0x7c
[ 58.448372] snd_open+0xa0/0x19c
[ 58.448379] chrdev_open+0xb0/0x21c
[ 58.448386] do_dentry_open+0x138/0x4c4
[ 58.448392] vfs_open+0x2c/0xf0
[ 58.448397] path_openat+0x6fc/0x1074
[ 58.448403] do_filp_open+0xa0/0x15c
[ 58.448407] do_sys_openat2+0xc8/0x100
[ 58.448413] __arm64_sys_openat+0x64/0xc0
[ 58.448420] invoke_syscall+0x48/0x104
[ 58.448427] el0_svc_common.constprop.0+0xc0/0xe0
[ 58.448433] do_el0_svc+0x1c/0x28
[ 58.448438] el0_svc+0x30/0x100
[ 58.448444] el0t_64_sync_handler+0x120/0x12c
[ 58.448450] el0t_64_sync+0x190/0x194
[ 58.448458] SMP: stopping secondary CPUs
[ 58.448464] Kernel Offset: disabled
[ 58.448466] CPU features: 0x00,00000080,00200000,4200420b
[ 58.448469] Memory Limit: none
[ 58.762124] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
Hi @humm
Q1. Yes, but only if the two cannot compete for the same audio resources.
Q2. Yes, there will be conflicts. In scenarios where Linux controls the audio, the M7 side must remove the AUDIOMIX mapping and the code related to power-on and SAI PLL initialization, leaving AUDIOMIX entirely to the A53/Linux's audiomix_pd management.
Q3. No—because this isn't a bug in the fsl_sai driver, but rather a resource ownership configuration issue.
Q4.M7 SDK BOARD_RdcInit() — The most crucial step: Removes the M7 (DID1) allocation for SAI3/SDMA3/I2C3. Remove the allocations of RDC_PDAP_SAI3, RDC_MDA_SDMA3*, RDC_PDAP_SDMA3, and RDC_PDAP_I2C3 to DID1, keeping these resources accessible to A53.
B.R
Thank you very much for your guidance.
Following your advice, I updated the RDC configurations to assign SDMA3 to Domain 0 (A53/Linux) and shared SAI3, I2C3, and SDMA3 permissions between Domain 0 and Domain 1.
Here is the diff of the RDC changes I applied:
-RDC_MDA RDC_MDA_SDMA3p DID1 0x0 0x0
+RDC_MDA RDC_MDA_SDMA3p DID0 0x0 0x0-RDC_MDA RDC_MDA_SDMA3b DID1 0x0 0x0
+RDC_MDA RDC_MDA_SDMA3b DID0 0x0 0x0-RDC_MDA RDC_MDA_SDMA3_SPBA2 DID1 0x0 0x0
+RDC_MDA RDC_MDA_SDMA3_SPBA2 DID0 0x0 0x0-RDC_PDAP RDC_PDAP_SAI3 PDAP_D1_ACCESS 0x0 0x0
+RDC_PDAP RDC_PDAP_SAI3 PDAP_D0D1_ACCESS 0x0 0x0-RDC_PDAP RDC_PDAP_SDMA3 PDAP_D1_ACCESS 0x0 0x0
+RDC_PDAP RDC_PDAP_SDMA3 PDAP_D0D1_ACCESS 0x0 0x0-RDC_PDAP RDC_PDAP_I2C3 PDAP_D1_ACCESS 0x0 0x0
+RDC_PDAP RDC_PDAP_I2C3 PDAP_D0D1_ACCESS 0x0 0x0
After applying these changes, arecord works on Linux without triggering any SError, even while the M7 core is running its RTOS firmware.
Thanks again for your help!