Skip to content

[BUG] make CONFIG_SOF_ZEPHYR_STRICT_HEADERS the default #9015

Closed

Description

@kv2019i

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

Activity

  1. added
    bugSomething isn't working as expected
    ZephyrIssues only observed with Zephyr integrated
    on Apr 9, 2024
  2. added this to the v2.10 milestone on Apr 16, 2024
  3. self-assigned this
    on May 28, 2024
  4. kv2019i commented on May 28, 2024

    @kv2019i
    CollaboratorAuthor

    Not sure I can tackle this in time for v2.10, but assigning for myself, as nobody else is assigned.

  5. kv2019i commented on Jun 5, 2024

    @kv2019i
    CollaboratorAuthor

    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).

  6. modified the milestones: v2.10, v2.11 on Jun 5, 2024
  7. added
    enhancementNew feature or request
    and removed
    bugSomething isn't working as expected
    on Sep 10, 2024
  8. kv2019i commented on Sep 10, 2024

    @kv2019i
    CollaboratorAuthor

    Work breakdown added to the issue description with already done worked marked as done.

  9. added a commit that references this issue on Sep 11, 2024
  10. 22 remaining items

  11. kv2019i commented on Oct 31, 2024

    @kv2019i
    CollaboratorAuthor

    With #9627 all work for this done, marking this as closed.

  12. kv2019i commented on Nov 29, 2024

    @kv2019i
    CollaboratorAuthor

    @LaurentiuM1234 wrote:

    @kv2019i wrote:

    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

    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 mmu_regions.c. I'm thinking that, ideally, this shouldn't be required. Instead, we

    I filed now a proper enhancement ticket for this #9697
    Rest of platform layer starts to be simplified now -- a few tough nuts to crack left, mailbox.h is one of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

ZephyrIssues only observed with Zephyr integratedenhancementNew feature or request

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions