-
Notifications
You must be signed in to change notification settings - Fork 311
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
[BUG] make CONFIG_SOF_ZEPHYR_STRICT_HEADERS the default #9015
Comments
Not sure I can tackle this in time for v2.10, but assigning for myself, as nobody else is assigned. |
Update for v2.10: spent some time on this trying to make one Intel target build in strict headers mode, but could not complete the task. There is still quite a lot of use of e..g sof/lib/mailbox.h and sof/lib/memory.h in surprising places in audio code that needs to be cleaned up first. Also we have some SOF side functions list SOF list.h and perf_cnt -- for these, move to some common header might be easier. For now moving to v2.11 -- might be able to complete some of this work in June, but won't backport to 2.10 release (as no functional benefit for the release). |
Work breakdown added to the issue description with already done worked marked as done. |
Implement sof/lib/dai.h for Zephyr build and do not rely o the xtos version for Zephyr builds. Add a warning to catch invalid build configurations. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Implement sof/lib/dai.h for Zephyr build and do not rely o the xtos version for Zephyr builds. Add a warning to catch invalid build configurations. Link: #9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Implement sof/lib/dai.h for Zephyr build and do not rely o the xtos version for Zephyr builds. Add a warning to catch invalid build configurations. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Remove the shim.h interface from RTOS layer as there is no use of this interface anymore in SOF codebase. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
sof/list.h is a software interface used by the audio pipeline framework and should not be in the RTOS abstraction layer. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
2.11 cutoff day. Some progress with this. Work breakdown has been done and shared as a task list in bug description. At end of 2.11 cycle, we have 23 out of 35 identified tasks completed. Pushing the remaining work to v2.12. |
sof/list.h is a software interface used by the audio pipeline framework and should not be in the RTOS abstraction layer. Link: #9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Remove the shim.h interface from RTOS layer as there is no use of this interface anymore in SOF codebase. Link: #9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Introduce a separate file for Zephyr compiler_attributes.h and move all Zephyr-specific definitions to this file. This is a prerequisite to build with CONFIG_SOF_ZEPHYR_STRICT_HEADERS=y. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Introduce a separate file for Zephyr compiler_attributes.h and move all Zephyr-specific definitions to this file. This is a prerequisite to build with CONFIG_SOF_ZEPHYR_STRICT_HEADERS=y. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The SOF agent.h interface is a system agent that is implemented on top of SOF audio task scheduling interface. An agent task is added to the low-latency scheduler to monitor health of the system. The current implementation is actually RTOS agnostic and can run on top of both Zephyr and XTOS. Some RTOSes offer a lower level watchdog interface to implement system monitoring. Previously agent.h was considered as the abstraction point, onto which RTOS specific implementations can be hooked in. This patch moves agent.h back to application interface. In the future, a more low-level agent hooking into a watchdog system (either hardware watchdog directly, or software abstraction like Zephyr's task_wdt) can be added on the side, and enabled on a per target basis. The audio scheduler level SOF agent will continue to be available as an option, and can be used with all RTOS'es. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The SOF perf_cnt.h provides a simple performance counter interface that is used in SOF to track performance at audio module and pipeline level. Majority of the implementation is RTOS agnostic, relying on sof_cycle_get_64() to sample platform clock, and timer_get_system() for CPU clock, both defined in rtos/timer.h. There is however some conditional rules for Zephyr to use timing_counter_get() if SOF is built with CONFIG_TIMING_FUNCTIONS=y. The amount of RTOS variation does not seem to warrant branching the whole perf_cnt.h to RTOS layer. Move perf_cnt.h back to application interface, so the single implementation can be shared. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Introduce a separate file for Zephyr compiler_attributes.h and move all Zephyr-specific definitions to this file. This is a prerequisite to build with CONFIG_SOF_ZEPHYR_STRICT_HEADERS=y. Link: #9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The SOF agent.h interface is a system agent that is implemented on top of SOF audio task scheduling interface. An agent task is added to the low-latency scheduler to monitor health of the system. The current implementation is actually RTOS agnostic and can run on top of both Zephyr and XTOS. Some RTOSes offer a lower level watchdog interface to implement system monitoring. Previously agent.h was considered as the abstraction point, onto which RTOS specific implementations can be hooked in. This patch moves agent.h back to application interface. In the future, a more low-level agent hooking into a watchdog system (either hardware watchdog directly, or software abstraction like Zephyr's task_wdt) can be added on the side, and enabled on a per target basis. The audio scheduler level SOF agent will continue to be available as an option, and can be used with all RTOS'es. Link: #9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Just thinking out loud here regarding i.e: something like:
The new mailbox header would look something like:
One obvious problem that I see with this is that the messages from the failed Also, I'm not sure how well this would play out on Intel platforms. I've been messing around with this idea on nxp platforms and I think it might work out. Also, not sure how good of an idea is to add application-specific chosen nodes.... This would also get rid of having to add the platform-specific |
Thanks @LaurentiuM1234 . mailbox.h is one of the more complex cases. With many platform interfaces, once you move to use native Zephyr drivers, most of the platform interface usage gets removed automatically (makes sense, talking to hw should go via drivers). But with mailbox we actually have quite a bit of use remaining in generic SOF code. I think the DT overlay would work. In fact for Intel platforms, the mailbox addresses are actually already defined via DT entries in soc/src/platform/meteorlake/include/platform/lib/memory.h: That's a good question whether mandating a SOF side DT overlay adds value anymore or do we get same result by leaving a minimal platform layer for mailbox.h. And for e.g. Intel this turns into simple mapping to a DT entry already defined in Zephyr that is same for all Intel platforms. Another approach might be to improve and scale up the "adsp_host_ipc" DT interface used by zephyr/soc/intel/intel_adsp/common/ipc.c . This is essentially the driver interface to talk to host and I think for longterm it would be better to move all current mailbox use to this interface (or maybe have two, one for IPC send/receiv and one to write to shared debug area). Majority of mailbox.h use is stll just to implement IPC to host, with a smaller set of use for debug (and some could clearly be replaced with other Zephyr mechanisms). This would also make it easier to use SOF on platforms that don't have a similar mapped memory between host and the DSP. E.g. you send IPC via ipc_send_message() Zephyr call, but implementation details are driver specific. |
I like the idea of using a driver for the IPC stuff. One aparent flaw I've noticed with our current mailbox implementation is that it's not really MMU friendly. On imx93 (ARM64 architecture, MMU enabled) we had to deal with this by adding some static phys-virt mappings inside If we are to add such a driver in Zephyr (or extend the one used by Intel) assuming we're going to be using Zephyr's mbox API, we also need to switch our mailbox unit driver (talking about the imx one) to Zephyr (we already have 2 of them, but not sure how "complete" they are - @iuliana-prodan may be able to comment on this). Nevertheless, it's some extra work, but it must be done at some point. |
The SOF perf_cnt.h provides a simple performance counter interface that is used in SOF to track performance at audio module and pipeline level. Majority of the implementation is RTOS agnostic, relying on sof_cycle_get_64() to sample platform clock, and timer_get_system() for CPU clock, both defined in rtos/timer.h. There is however some conditional rules for Zephyr to use timing_counter_get() if SOF is built with CONFIG_TIMING_FUNCTIONS=y. The amount of RTOS variation does not seem to warrant branching the whole perf_cnt.h to RTOS layer. Move perf_cnt.h back to application interface, so the single implementation can be shared. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The SOF perf_cnt.h provides a simple performance counter interface that is used in SOF to track performance at audio module and pipeline level. Majority of the implementation is RTOS agnostic, relying on sof_cycle_get_64() to sample platform clock, and timer_get_system() for CPU clock, both defined in rtos/timer.h. There is however some conditional rules for Zephyr to use timing_counter_get() if SOF is built with CONFIG_TIMING_FUNCTIONS=y. The amount of RTOS variation does not seem to warrant branching the whole perf_cnt.h to RTOS layer. Move perf_cnt.h back to application interface, so the single implementation can be shared. Link: #9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Implement sof/lib/memory.h for Zephyr build and do not rely on the xtos version for Zephyr builds. Link: thesofproject#9015 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Describe the bug/enhancement
When rtos include layer was added in #6161 , CONFIG_SOF_ZEPHYR_STRICT_HEADERS was added as a transitory tool.
This is still in place and can cause confusing issues as both XTOS and Zephyr headers are added to the include path by default.
To Reproduce
Build target, check .config
Reproduction Rate
100%
Expected behavior
OS include paths not mixed in build.
Impact
Slows down development of new features.
Environment
SOF main as of 2024-04-09
Work breakdown
Following subtasks identified (breakdown started in v2.11 cycle):
Screenshots or console output
The text was updated successfully, but these errors were encountered: