west.yml: update Zephyr to b92e749c3e5f

[kv2019i]

Contains 2211 commits, including following directly affecting SOF targets:

ab0ed577111b mm: intel_adsp_tlb: Handle address space conversion warnings
823e6b70d240 arch: xtensa: Implement arch_float_enable&disable
be779f2a6195 intel_adsp: hda: fix usage of FIFORDY bit
498f294b2720 west: update sof ref in manifest
42ca64d60cd2 tests: dma_sg: intel_adsp_ace15 specific config
0e373019d65e dma: intel_adsp_gpdma: Unmask interrupt on ACE
6e66efa08871 soc: intel_adsp_ace15: Include stdint.h
250748bfe671 intel_adsp: Add option about switch off hpsram
b4293ec026c4 dts: xtensa: nxp: add nodes for IPC
1295283a8a72 soc: xtensa: nxp: add resource_table section in linker script
e6d89268572d xtensa: set no optimization for arch_cpu_idle() with xt-clang
a458d0443a91 xtensa: allow arch-specific arch_spin_relax() with more NOPs
f60306193844 soc: xtensa: intel_adsp: cavs: fix PM hooks guards
385ad46a39ca boards/xtensa: Skip cleaning intermediate binaries up
1c0c2a095b48 drivers: intel_adsp_gpdma: Fix release ownership
e55fb88bcbe7 soc: intel_adsp/ace: update clock rate
35e8e6fa03fa soc/xtensa/nxp_adsp/CMakeLists.txt: use new WEST_SIGN_OPTS variable
c35d97534fd1 include: util_internal: add Z_SPARSE_LIST_{ODD|EVEN}_NUMBERS
25c6553edde5 soc: intel_adsp/ace: use functions to do CPU power control
3764814831a7 intel_adsp: boot: d3: hp sram reinit

[lgirdwood]

@kv2019i do we also need an rimage update too ?

[kv2019i]

Hmm, still sparse fails :( I will track these down and file new bugs, we need to get this in control:

/zep_workspace/zephyr/soc/xtensa/intel_adsp/cavs/power.c:97:53: warning: incorrect type in argument 1 (different address spaces)
/zep_workspace/zephyr/soc/xtensa/intel_adsp/cavs/power.c:106:63: warning: incorrect type in argument 2 (different address spaces)
/zep_workspace/sof/src/ipc/ipc4/helper.c:389:49: warning: incorrect type in argument 1 (different address spaces)
/zep_workspace/sof/src/ipc/ipc4/helper.c:390:45: warning: incorrect type in argument 1 (different address spaces)

#7759 not seen anymore, so fix seems to hold up! There's one runtime-PM fail still in https://sof-ci.01.org/sofpr/PR8085/build11979/devicetest/index.html , but that has been seen in baseline as well.

[kv2019i]

@lgirdwood wrote:

@kv2019i do we also need an rimage update too ?

That ideally should be done by authors of rimage patches. I'm ok to do the occasional Zephyr update as these can be complex w.r.t. validation sometimes, but for rimage, there's really no reason why the PR authors do not do the rimage update.

But alas, I'll do at least one update before SOF2.7 branch just so we don't miss any updates. There seems to be 4-5 updates (from Seppo and Curtis).

[marc-hb]

Hmm, still sparse fails :( I will track these down and file new bugs,

zephyrproject-rtos/zephyr#61630 fixed some warnings but not all of them? Or, new ones popped up.

we need to get this in control

The only way is to somehow run sparse in Zephyr CI.

Either for every Zephyr PR but that's unlikely to fly because SOF is just one Zephyr projects among very many others.

Or in a smarter, on-demand way using some sort of "cross-CI" technique/button.

[plbossart]

FWIW, we only run sparse and other static analysis on parts of the code we control, usually limited to sound/, sometimes sound/soc. You can't force a diverse community to all align and see the light all at once.

[marc-hb]

You can't force a diverse community to all align and see the light all at once.

Agreed and that's not what I had in mind.

I mentioned the idea of "sparsing" only SOF in Zephyr CI but that obviously does not scale and does not work either: you can't have each separate area adding its own, favorite analyzers. That's why some smarter "cross-CI" is needed.

[plbossart]

Ah yes I see your point now @marc-hb, things work for us at the kernel level because we are not the mainline tree, and we can add as many filters as we see fit. For an organization where all the merges are handled without a notion of subsystem integration indeed the CI will have to default to the largest common factor. Turning CI rules on depending on which part of the code they touch is also not really feasible.

[marc-hb]

Turning CI rules on depending on which part of the code they touch is also not really feasible.

Actually Zephyr CI does or at least has been doing some of that as a "CI cost" optimization. For instance: don't rebuild the docs when the docs don't change. However I think these were just "optimizations" and not domain-specific AFAIK. The maintenance of Zephyr CI code has a scalability element too.

The first step for such optimizations is to get the list of changed files which can be surprisingly difficult in the general case:

• https://stackoverflow.com/questions/25071579/list-all-files-changed-in-a-pull-request-in-git-github
• thesofproject/sof-test@8a4b9919f1e27923
• Shallow cloning can create pull requests with one million commits linux#2556 (about merge bases)