-
Notifications
You must be signed in to change notification settings - Fork 349
[RFC] app: boards: add common board family definitions for Intel ADSPs #10182
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
[RFC] app: boards: add common board family definitions for Intel ADSPs #10182
Conversation
Kconfig default is 'n' by default. Remove redundant definition. This also allows later use of board/family specific Kconfig.defconfig files that provide additional rules to set defaults. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
SOF builds currently use the board Kconfig file to set any target specific build options. This includes modifying Zephyr build options (if different from Zephyr defaults for the SoC) and setting SOF specific options. There is currently no way to share definitions. For Intel ADSP boards, there starts to be a lot of boards and a lot of duplication of settings. Add a new mechanism to include common Kconfig.defconfig for a family of boards. Start with addition of boards/intel_adsp/Kconfig.defconfig and move defaults for CONFIG_COMP_ARIA and CONFIG_IPC4_BASE_FW_INTEL to the common file. These are options that are not related to hardware features, but we want to set them in the same way for all Intel ADSP targets. Follow-up patches will move more options to the common Kconfig.defconfig and other vendors can add their own board family defconfig files. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
|
@thesofproject/nxp @thesofproject/mediatek @thesofproject/amd please check whether this would be aligned with your needs to set common options for your product lines. |
| config IPC4_BASE_FW_INTEL | ||
| def_bool y | ||
|
|
||
| config COMP_ARIA |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks unorthodox with config COMP_ARIA present in src/audio/aria/Kconfig also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ujfalusi this is used in Zephyr to set board defaults: e.g. https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/nxp/imx943_evk/Kconfig.defconfig , https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/ruuvi/ruuvitag/Kconfig.defconfig and others.
This does build on the convention to not set redundant "default n" in the main Kconfig definition.
lgirdwood
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kv2019i I assume you are proposing a platform/family config with an optional sku config to differentiate from the platform/family ? How would you add OS differentiation ?
Long term we also have the minimal RTOS baseFW and the llext application and modules, so any solution need to work here too.
|
@lgirdwood wrote:
We currently have three level of settings:
I'm proposing to add a layer above board settings to have common settings defined in a single place. Then orthogonal to all this, we have overlays that can be applied to all SOF targets. We have one for debug, one for performance tracing and most recently, "Host OS Linux" variant that selects features used by the Linux SOF driver. I'm not proposing any changes to the overlays.
I don't see any immediate conflict with this. |
|
|
||
| config COMP_ARIA | ||
| def_tristate m if LIBRARY_DEFAULT_MODULAR | ||
| def_tristate y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks like a very modest beginning, but a good start
tmleman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, I like the concept of default values for a family of platforms to avoid duplicating them in platform-specific Kconfigs. I think it's a good direction.
|
Thank you all for reviews. Seem no showstoppers to go ahead with this. Let me work on a PR that moves more of the common options. I'll keep this draft until I have replacement ready in case there is more feedback. |
|
Replaced by #10209 |
We've had multiple issues minor config differences between different Intel boards, that it's time to remove some of the duplication and make adding new boards easier.
Other options considered: