[tmleman]

Total of 391 commits.

Changes include:

44464c4d4fc drivers: dai: intel: ssp: Introduce DMA control set API
5084decbc46 drivers: dai: intel: ssp: Refactor TLV parsing into a separate function
230709e4ae6 include: dai: Introduce runtime DAI configuration update API
1497f77cc89 intel: adsp: make SRAM power-off configurable
293fa118df9 intel: adsp: fix firmware image in IMR overwriting

[marc-hb]

Nice try, thanks @tmleman. Unfortunately, we have a new, unrelated regression and crash:
https://sof-ci.01.org/sofpr/PR9338/build6778/devicetest/index.html

• sof_sdw: init platform error / mc_probe failure - no audio device (dmic_num issue) linux#5124

UPDATE: it's a complex issue but there is a way to avoid the failure in the BIOS configuration.

[marc-hb]

EDIT: off-topic and moved to new issue #9343

---

The fuzzing crash is also worrying, @andyross could you help?
https://github.com/thesofproject/sof/actions/runs/10144692547/job/28048711573?pr=9338

==5054==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000 (pc 0x081aecfa bp 0xdbffadb8 sp 0xdbffacd0 T7)
==5054==The signal is caused by a WRITE memory access.
==5054==Hint: address points to the zero page.
    #0 0x81aecfa in k_sys_fatal_error_handler /home/runner/work/sof/sof/workspace/sof/zephyr/wrapper.c:352:19
    #1 0x815e3c9 in assert_post_action /home/runner/work/sof/sof/workspace/zephyr/lib/os/assert.c:43:2
    #2 0x8188b30 in comp_buffer_connect /home/runner/work/sof/sof/workspace/sof/src/ipc/ipc-helper.c:188:3
    #3 0x81819b6 in ipc_buffer_to_comp_connect /home/runner/work/sof/sof/workspace/sof/src/ipc/ipc3/helper.c:594:9
    #4 0x8181404 in ipc_comp_connect /home/runner/work/sof/sof/workspace/sof/src/ipc/ipc3/helper.c:[622](https://github.com/thesofproject/sof/actions/runs/10144692547/job/28048711573?pr=9338#step:7:623):10
    #5 0x8176f3e in ipc_glb_tplg_comp_connect /home/runner/work/sof/sof/workspace/sof/src/ipc/ipc3/handler.c:1375:9
    #6 0x8175bd4 in ipc_cmd /home/runner/work/sof/sof/workspace/sof/src/ipc/ipc3/handler.c:1654:9
    #7 0x818e639 in ipc_platform_do_cmd /home/runner/work/sof/sof/workspace/sof/src/platform/posix/ipc.c:160:2
    #8 0x818750c in ipc_do_cmd /home/runner/work/sof/sof/workspace/sof/src/ipc/ipc-common.c:326:9
    #9 0x81af56b in task_run /home/runner/work/sof/sof/workspace/sof/zephyr/include/rtos/task.h:94:9
    #10 0x81af0de in edf_work_handler /home/runner/work/sof/sof/workspace/sof/zephyr/edf_schedule.c:32:16

EDIT: somehow this was run again and is passing now: https://github.com/thesofproject/sof/actions/runs/10144692547/job/28093942074?pr=9338

Fuzzing is typically non-deterministic.

[marc-hb]

SOFCI TEST

[tmleman]

EDIT: somehow this was run again and is passing now: https://github.com/thesofproject/sof/actions/runs/10144692547/job/28093942074?pr=9338

Fuzzing is typically non-deterministic.

I have another PR with the same update and there was no failure there. Locally, I initially couldn't hit it either. That's why I did a rerun of fuzzing for this PR.
After some longer runs, I now have the same failure and I must admit that I don't quite understand the point of this assert. The assumption seems to be that when creating components we know they will be on separate cores and that they will be connected. That's why we set the buffer as shared, but I don't know how to verify this at an earlier stage so that here we can be sure that the buffer is shared.
I will also add that the same case reproduces for me on the current main.

[marc-hb]

I will also add that the same case reproduces for me on the current main.

Thanks for all the off-topic testing and investigation! I just filed new #9343 to move this (yet other...) distraction away from this PR.

Well known LNL failures in https://sof-ci.01.org/sofpr/PR9338/build6792/devicetest/index.html