[lbetlej]

As the number of FW configuration options is extending there is a need to clearly specify presets that reflect features options. This is an alternative to #2599 that is closer to linux concept of incremental update of kernel parameters.

The approach is based on keeping generic configuration in configs directory while the override directory contains only incremental delta information. The compilation flow assumes using make overrideconfig command. In example:
make cannonlake_defconfig
cp ../src/arch/xtensa/configs/override/cannonlake_chrome_override.config
override.config
make overrideconfig
make bin

Specifically the change separate presets for:

1. Chrome based platforms by enabling option to enable Low Power Sequencer (LPS) and LP Ring Oscillator clock together for low power Keyphrase Detection use cases (CNL/JSL) or LPS and HP RO for more complex use cases (TGL)
2. Generic profile that enables HP Ring Oscillator for workloads that exceed compute capacity with LP RO clock enabled.

Future enhancement would include in example _debug_defconfig presets with all debug options enabled.

[lgirdwood]

GH is showing this warning.

[lgirdwood]

This is fine for short term, but can we set this clock via IPC yet ?
Thinking here is that we need a single singed binary we can use both HP/LP clocks (selected via topology).

[lbetlej]

It's always a trade-off (on image size/FW complexity) between images that have all features and logic to switch between them in run-time compiled in and images with features selected at a compilation time. I agree that we need to discuss about long term approach.

[ranj063]

1. Chrome based platforms by enabling option to enable Low Power Sequencer (LPS) and LP Ring Oscillator clock together for low power Keyphrase Detection use cases (CNL/JSL) or LPS and HP RO for more complex use cases (TGL)

@lbetlej the patch looks good but for my education. What happens on the chrome platforms when workload exceeds compute capacity with LPRO set as default?

[jajanusz]

This is fine for short term, but can we set this clock via IPC yet ?
Thinking here is that we need a single singed binary we can use both HP/LP clocks (selected via topology).

Maybe it'd be better if topology would declare required MIPS and IRT that FW will choose clock.

[jajanusz]

I think that override in file name is not needed, cos it's already in override folder.
@lbetlej To make things easier I can add automatic generation of targets for overrides, just like for defconfigs.
So instead of something like:

make cannonlake_defconfig
cp ../src/arch/xtensa/configs/override/cannonlake_chrome.config .override
make overrideconfig

There will be

make cannonlake_defconfig
make cannonlake_chrome_override_config

[jajanusz]

BTW I'm not sure if these files should have .config suffixes. I know defconfigs don't have extension in kernel, but not sure about non-defconfigs.
@lgirdwood Can you tell us, what's the best practice here?

[lbetlej]

@jajanusz I like the idea , Could be multiple stages supported ? Like:

make cannonlake_defconfig
make cannonlake_chrome_override_config
make cannonlake_debug_override_config

[jajanusz]

Yes you can stack them.

[lgirdwood]

@kv2019i any comment on stacking the kconfigs ?

[jajanusz]

BTW I'm not sure if these files should have .config suffixes. I know defconfigs don't have extension in kernel, but not sure about non-defconfigs.
@lgirdwood Can you tell us, what's the best practice here?

@kv2019i Can you share the best practice?

[kv2019i]

@jajanusz @lgirdwood Stacking is very common. Typically you merge the stacked configs to a single .config file, before running the actual build make target. E.g. for SOF kernel we have following instructions:
https://github.com/thesofproject/kconfig/blob/master/README.md

The filename conventions vary but e.g. in kernel non-defconfig files still have the ".config" suffix (e.g. arch/x86/Kconfig.debug). But e.g. in SOF kconfig repo, all config files have a "defconfig" suffix, so this is not universally followed (upstream kernel has exceptions as well).

[jajanusz]

ok thanks for info, we will go for .config then for non-defconfig files

[lgirdwood]

This is fine for short term, but can we set this clock via IPC yet ?
Thinking here is that we need a single singed binary we can use both HP/LP clocks (selected via topology).

Maybe it'd be better if topology would declare required MIPS and IRT that FW will choose clock.

I'd go with this. I think @tlauda has some data for MCPS for each component, and this could be included in topology so we can configure the clock after load (and then eventually dynamically).

[lbetlej]

@lgirdwood @jajanusz This is fine by me regarding clocks long term, that's what we planned. Of course there has to be a procedure to measure components in worst case condition (latency to memory access), for components like SRC probably we are talking about a mapping sampling ratio->MCPS etc. The PR is to address current implementation.

[lbetlej]

@ranj063 Symptoms may be observed as FW xruns and/or IPC timeouts.

[jajanusz]

@lbetlej override in file names is redundant

[lbetlej]

@jajanusz ACK for filenames length reduction

[jajanusz]

SOFCI TEST

[jajanusz]

@lgirdwood @xiulipan SOFCI TEST didn't help for travis, it's stuck, can you look at it?

[xiulipan]

@jajanusz The Travis is not configured to response to that magic word. It seems to be some network issue for Travis, I can find the build history https://travis-ci.org/github/thesofproject/sof/builds/669242119 but the status is not updated here. I re-run the whole build hope it can work. Please check later.

[lgirdwood]

@jajanusz @xiulipan I think we have had network issues with GH as I've seen all the CIs pend recently. It looks like the issue is clear now though.

[lgirdwood]

CI known issue

[xiulipan]

@lgirdwood Yep, I think so. The Internet must be on heavy load as most of us are WFH :)