-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DNM] Zephyr update + ZPR68101 + SOF fixes in review #8796
Conversation
…ads" When a stream is triggered to start, host kernel first sendis trigger start ipc message to fw and then start host dma for this stream. Ipc_wait_for_compound_msg is used to wait for all pipelines in the stream to be complete and need to be done fast since it blocks host to start hda dma. The reverted commit adds a 10 ms delay and results to host copier xrun warning for it can't get data from host dma. And this commit also makes a negative effect for stream_start_offset calculation which is for the difference between dai gateway and host gateway. We calculate it in host start function but host dma is started 10ms later, so there will be at least 10ms data error. This reverts commit 909a327. Signed-off-by: Rander Wang <[email protected]>
Fix handling of input_pins free. Module reset can be called multiple times, so move the resource release to module_adapter_free(). Fixes: 7046004 ("module_adapter_ipc4: Save and pre-parse base_cfg_ext data") Signed-off-by: Kai Vehmanen <[email protected]>
A race exists between submitting a new IDC message and completion of a previous message. The p4wq interface mandates k_p4wq_wait() must be called to claim back ownership of the work object. The SOF IDC code does not do this, but relies on the caller not to send multiple IDC messages to the same destination core. Add appropriate calls to k_p4wq_wait() to handle this issue. If caller wants to send an IDC in blocking mode, also call k_p4wq_wait() in blocking mode. If non-blocking, return -EBUSY immediately. The check for CPU status is moved earlier in the function. No pointing in waiting for p4wq semaphore if the target core is already powered down, so do the power state check as the first step. Signed-off-by: Kai Vehmanen <[email protected]> (cherry picked from commit 342553c)
This changes the secondary core power up routine to use the newly introduced k_smp_cpu_start() and k_smp_cpu_resume(). This removes the need to mirror part of the SMP start up code from Zephyr, and no longer need to call into Zephyr private kernel code. West update includes : eefaeee061c8 kernel: smp: introduce k_smp_cpu_resume 042cb6ac4e00 soc: intel_adsp: enable DfTTS-based time stamping on ACE platforms 6a0b1da158a4 soc: intel_adsp: call framework callback function for restore e7217925c93e ace: use a 'switch' statement in pm_state_set() c99a604bbf2c ace: remove superfluous variable initialisation a0ac2faf9bde intel_adsp: ace: enable power domain 4204ca9bcb3f ace: fix DSP panic during startup (fixes c3a6274bf5e4) d4b0273ab0c4 cmake: sparse.template: add COMMAND_ERROR_IS_FATAL ca12fd13c6d3 xtensa: intel_adsp: fix a cache handling error 0ee1e28a2f5f xtensa: polish doxygen and add to missing doc 035c8d8ceb4b xtensa: remove sys_define_gpr_with_alias() a64eec6aaeec xtensa: remove XTENSA_ERR_NORET Signed-off-by: Daniel Leung <[email protected]> Signed-off-by: Rander Wang <[email protected]>
Loving it! Now the cavs25 XCC build is broken in Zephyr, fix in zephyrproject-rtos/zephyr#68108 |
446156d
to
7ae54cc
Compare
Combo of 3 PRs in Zephyr.
7ae54cc
to
3542311
Compare
One more: zephyrproject-rtos/zephyr#68118 |
Results are pretty horrible: The chain-dma fix is not holding up, and have a new category of asserts firing up like
|
A collection of SOF and Zephyr fixes to attempt to a) update Zephyr and bring in the new SMP interface, and b) still pass SOF tests.