sof
sof copied to clipboard
thesofproject
zephyr: macros: Avoid macros redefinition
Some macros defined in SoF are also being defined in Zephyr. Just avoiding redefinition un-defining these macros.
Signed-off-by: Flavio Ceolin [email protected]
Can one of the admins verify this patch?
reply test this please to run this test once
v2: - Include Zephyr's header where macros are defined. It ensures that Zephyr will not redefine SoF macros.
v4:
- GET_BITS is not going to be exported by Zephyr at moment.https://github.com/zephyrproject-rtos/zephyr/pull/48963#issuecomment-1217148881
@ceolin I really like the way you add history of updates with v1, v2, ... v4. @lgirdwood we should keep in mind and use that for SOF more often.
The long term direction for SOF on Zephyr platforms is that IP drivers will migrate to Zephyr i.e. the need for bit setting macros will be reduced. We will still need an aligned bit setting macro for xtos users though.
The long term direction for SOF on Zephyr platforms is that IP drivers will migrate to Zephyr i.e. the need for bit setting macros will be reduced. We will still need an aligned bit setting macro for xtos users though.
I have avoided to duplicate these macros on Zephyr in every driver but I hit a road blocker. These macros need a proper namespace, moving them a common place started to conflict with other subsystems / hals.
Regarding CI failing, that is the thing, this change requires the changes on Zephyr as well, it is the chicken and egg problem, Zephyr is also failing because SoF. One thing we can do to avoid break the code base is come back with that initial version that un-define the macros (to avoid re-definition), merge Zephyr changes, then we it again to this latest commit.
@ceolin fwiw - I'm looking at a more strict partitioning of RTOS headers and logic. See https://github.com/thesofproject/sof/pull/6161 The intent is to make sure we have no contamination in the future between xtos code and zephyr code. Today this is quite tricky to rule out.
