Repository navigation
[BUG][mtl-004] nocodec playback can't work on MTL #7176
Description
Test step: speaker-test -c 2 -t sine -Dhw:0,0 // SSP was used
Kernel: sof-dev
FW: mtl-004-drop-stable commit 09213dc
Topology: sof-main, binary mtl-nocodec.tplg
FW error log:
[00:00:00.163,918] dai_intel_ssp: dai_ssp_get_properties: dai_ssp_get_properties dai_index 2
[00:00:00.163,965] dai_intel_ssp: dai_ssp_get_properties: dai_ssp_get_properties fifo 172048
[00:00:00.164,016] dai_intel_ssp: dai_ssp_get_properties: dai_ssp_get_properties handshake 6
[00:00:00.164,066] dai_intel_ssp: dai_ssp_get_properties: dai_ssp_get_properties init delay 0
[00:00:00.164,186] dai_comp: dai_playback_params: comp:1 0x40001 dai_playback_params() dest_dev = 6 stream_id = 0 src_width = 4 dest_width = 4
[00:00:00.164,245] dai_intel_ssp: dai_ssp_get_properties: dai_ssp_get_properties dai_index 2
[00:00:00.164,293] dai_intel_ssp: dai_ssp_get_properties: dai_ssp_get_properties fifo 172048
[00:00:00.164,343] dai_intel_ssp: dai_ssp_get_properties: dai_ssp_get_properties handshake 6
[00:00:00.164,393] dai_intel_ssp: dai_ssp_get_properties: dai_ssp_get_properties init delay 0
[00:00:00.165,100] dai_comp: comp:1 0x40001 dai_config_prepare(): dma_request_channel() failed
[00:00:00.165,190] pipe: pipe:1 0x0 pipeline_prepare(): ret = -5, dev->comp.id = 196608
[00:00:00.165,255] ipc: ipc: pipe 1 comp 0 prepare failed -5
[00:00:00.165,971] component: comp_set_state: comp:1 0x40001 comp_set_state(), state already set to 1
Activity
[-][BUG] mtl-004-drop-stable: nocodec playback can't work[/-][+][BUG] mtl-004-drop-stable: nocodec playback can't work on MTL[/+]RanderWang commentedon Feb 27, 2023
@mengdonglin @keqiaozhang
RanderWang commentedon Feb 27, 2023
DMIC can work with 004 branch
abonislawski commentedon Feb 28, 2023
Should be fixed now on mtl-004
keqiaozhang commentedon Mar 1, 2023
I tried latest mtl-004 branch(d769820), but the result is bad. playback failed at the first round with
ipc timed out 0x13000004|0x1 GLB_SET_PIPELINE_STATE.https://sof-ci.ostc.intel.com/#/result/planresultdetail/21514
@abonislawski , please help to double confirm it on your device.
mengdonglin commentedon Mar 1, 2023
Here are the dmesg and mtrace when failure happened in case check-playback-all-formats.sh
On MTL with SDW:
dmesg:
mtrace:
On MTL in SSP nocodec mode:
dmesg:
mtrace:
abonislawski commentedon Mar 3, 2023
@mengdonglin @keqiaozhang can we rerun and double confirm? It works fine on my linux platform and Dhara also reported echo ref is working fine on 004
keqiaozhang commentedon Mar 7, 2023
This issue is related to the debug build, if we enable the debug option
-dwhen building FW, we will run to this error on all MTL platforms.kv2019i commentedon Mar 7, 2023
@abonislawski I suspect this an assert. This branch has "app: zephyr: enable CONFIG_ASSERT in debug overlay" commit, but I suspect either SOF or the Zephyr branch used here, is missing some assert fix, and now you hit an assert when you build with "-d" (which enables asserts now).
abonislawski commentedon Mar 7, 2023
@keqiaozhang @kv2019i I assume debug build works fine on main branch?
keqiaozhang commentedon Mar 8, 2023
@abonislawski debug build works fine on main branch.
[-][BUG] mtl-004-drop-stable: nocodec playback can't work on MTL[/-][+][BUG][mtl-004] nocodec playback can't work on MTL[/+]abonislawski commentedon Mar 9, 2023
I found root cause for crashing with -d option, normal FW (without -d) is affected too but still handle this.
@keqiaozhang I need assistance from kernel team to check why FW receives 0 CPC for gain module, all other modules are fine.
#7228
RanderWang commentedon Mar 10, 2023
@abonislawski It is missed in gain setting in topology. Let me add it.
abonislawski commentedon Mar 10, 2023
@RanderWang thanks!
So looks like manifest data is ignored anyway, for example for MIXIN in topology I can see CPC 910 but measured minimum is 2572 (added to rimage manifest here thesofproject/rimage@0bcef6f )
Why this works like that?
RanderWang commentedon Mar 10, 2023
@abonislawski First I wanted to talk about windows driver. The cpc value is zero in extended module config and windows driver calculates it based on CPS, then sends to FW. So Linux driver should do it like this, but now we get cpc from topology, not from extended module config. I don't think we need to set cpc value in rimage for above reason
RanderWang commentedon Mar 10, 2023
topology change: #7242
abonislawski commentedon Mar 10, 2023
@RanderWang its not really a big difference cps/cpc, it can be calculated from one to another. At the end we need to get CPC in FW, its fine if you calculate it from cps (but from manifest as in current windows solution).
However please note that windows solution have limitations (for example lets think about copier types but cps/cpc is based only on format) and it is already outdated and we could think about something better where we could differentiate normal copier from i2s copier, etc. so after all topology solution is not that bad but at least needs to be extended
RanderWang commentedon Mar 10, 2023
@abonislawski Thanks for your info. We need to figure out a general method to make cSOF compatible with both windows and Linux.
RanderWang commentedon Mar 20, 2023
fixed