app: ptl: set IMR context save enabled for DAX overlay

[johnylin76]

This is a fix for regression on Chrome caused from 5599cff (boards: ace30: disable IMR context save). Empirical evidence showed that disabling IMR context save is fine on common Chrome builds but not on DAX-integrated builds. @abonislawski

Although 5599cff is only on ptl-007-drop-main rather than main, I feel this fix can land on both anyway.

[johnylin76]

@checkupup

[checkupup]

It is fine to me. I verfied it on ptl-007-drop-stable and it work well. It seems that the cold start of SOF with DAX has encountered some performance issues, right?

[lyakh]

uhm, this shouldn't be needed... I know it's difficult to debug these failures. Is DAX built as an LLEXT when this failure is happening?

[abonislawski]

This looks quite strange and seems like it's masking the real problem rather than fixing the root cause. IMR context restore has been disabled on every Chrome branch, e.g., the previous ptl-006.

@johnylin76 can you describe the problem in more detail?

@lgirdwood @kv2019i as far as I know, nothing has changed on the kernel side and context save is still not being actively utilized. Can you confirm?

[lgirdwood]

This looks quite strange and seems like it's masking the real problem rather than fixing the root cause. IMR context restore has been disabled on every Chrome branch, e.g., the previous ptl-006.

@johnylin76 can you describe the problem in more detail?

@lgirdwood @kv2019i as far as I know, nothing has changed on the kernel side and context save is still not being actively utilized. Can you confirm?

Adding @ujfalusi and @bardliao re kernel question.

[bardliao]

The IMR boot is enabled by default unless the SOF_DBG_IGNORE_D3_PERSISTENT flag is set by the module parameter. IOW, the IMR boot is only disabled when the SOF_DBG_IGNORE_D3_PERSISTENT flag is set. @ujfalusi please correct me if I was wrong.

[johnylin76]

This looks quite strange and seems like it's masking the real problem rather than fixing the root cause. IMR context restore has been disabled on every Chrome branch, e.g., the previous ptl-006.

Yes. That's also what I am concerned about

@johnylin76 can you describe the problem in more detail?

In my previous test, the broken issue behaved when we attempt to playback (via Speaker) after reboot. The system message shows as follows:

[  341.530547] sof-audio-pci-intel-ptl 0000:00:1f.3: ------------[ DSP dump start ]------------
[  341.532206] sof-audio-pci-intel-ptl 0000:00:1f.3: Firmware boot failure due to timeout
[  341.533710] sof-audio-pci-intel-ptl 0000:00:1f.3: fw_state: SOF_FW_BOOT_IN_PROGRESS (3)
[  341.535445] sof-audio-pci-intel-ptl 0000:00:1f.3: 0x50000005: module: ROM_EXT, state: FW_ENTERED, running
[  341.537052] sof-audio-pci-intel-ptl 0000:00:1f.3: ------------[ DSP dump end ]------------
[  341.537887] sof-audio-pci-intel-ptl 0000:00:1f.3: error: failed to boot DSP firmware after resume -5
[  341.559607] cs42l43-codec cs42l43-codec: Failed to resume for shutters: -16
[  341.568392] soundwire_intel soundwire_intel.link.3: ASoC error (-16): at snd_soc_pcm_component_pm_runtime_get() on soundwire_intel.link.3 
[  341.569252] SDW3-Playback-SmartAmp: ASoC error (-16): at __soc_pcm_open() on SDW3-Playback-SmartAmp
[  341.569875] Speaker: ASoC error (-16): at dpcm_be_dai_startup() on Speaker

Upon ptl-007-drop-stable, I have checked the combination about sof-ptl.ri (common or DAX-integrated)[1] and sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg (common or DAX-integrated)[2], and the result is as follows:

.ri    | .tplg  | result
------ + ------ + --------------
common | common | GOOD
common | DAX    | n/a
DAX    | common | issue occurred
DAX    | DAX    | issue occurred

which implies the issue is not triggered by DAX module use in runtime, instead something unexpected as firmware built with DAX

[1] The build command of sof-ptl.ri

common: sof/scripts/xtensa-build-zephyr.py ptl -p
DAX: sof/scripts/xtensa-build-zephyr.py ptl -p -o sof/app/overlays/ptl/dax_overlay.conf

[2] The topology comes from

common: sof/tools/build_tools/topology/topology2/production/sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg
DAX: sof/tools/build_tools/topology/topology2/production/sof-ptl-cs42l43-agg-l3-cs35l56-l2-dax.tplg

Is DAX built as an LLEXT when this failure is happening?

Yes. DAX is built as an LLEXT.

[lyakh]

.ri    | .tplg  | result
------ + ------ + --------------
common | common | GOOD
common | DAX    | n/a
DAX    | common | issue occurred
DAX    | DAX    | issue occurred

which implies the issue is not triggered by DAX module use in runtime, instead something unexpected as firmware built with DAX

@johnylin76 Interesting. So I suppose it is caused not by the DAX module, but by other options in the DAX overlay. I actually only see one option there, different from the standard .config: CONFIG_LLEXT_HEAP_SIZE=32. So if you remove that one, you don't get the problem? And no errors in mtrace?

[ujfalusi]

@johnylin76, can you share a complete kernel log and enable dyndbg for the drivers?
Rename sof-dyndbg.conf.txt to sof-dyndbg.conf and put it in the /etc/modprobe.d/

From the error it looks like that the firmware did booted up, so, either it has not been powered off prior or something really strange is going on.