Repository navigation
[BUG] [JSL]: Fail to enter S0ix while WoV pipeline is running #3144
Description
Describe the bug
On Jasper Lake with WoV running, system is not able to enter S0ix.
To Reproduce
Step 1:
arecord -Dhw:0,6 -M -N -c 2 -f S16_LE -r 16000 --buffer-size=68000 tmp.wav -d 10 -vvv
Step 2: Run powerd_dbus_suspend from another console.
Step 3: Wake up the DUT and check residency counter at
cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
Reproduction Rate
100%
Expected behavior
System should enter into S0IX with WoV running and should wake up upon detecting the keyworrd(tap/loud noise near the DMIC).
Impact
Lose S0ix when WoV is used.
Environment
Stack
OS - R85-13290.0.0
Coreboot - Google_Waddledoo.13297.0.2020_06_19_1121
EC -
RO version: waddledoo_1.1.9999-3cfaa4c
RW version: waddledoo_1.1.9999-3cfaa4c
Kernel – with commit 0dc2876505851c2a448030fe88fbb351906f5f31 + cherry-pick thesofproject/linux@f731ca0
Updated to waddledoo – version - 5.4.50
JSL with SOF V0.3 release.
localhost ~ # md5sum /lib/firmware/intel/sof/community/sof-jsl.ri
106d6716067ebc767e396e84753af8b8 /lib/firmware/intel/sof/community/sof-jsl.ri
localhost ~ # md5sum /lib/firmware/intel/sof-tplg/sof-jsl-da7219-mx98360a.tplg
d4ff4af9ce461c7508e9bb9a82fdf1d5 /lib/firmware/intel/sof-tplg/sof-jsl-da7219-mx98360a.tplg
Activity
yongzhi1 commentedon Jul 7, 2020
Thanks @udaymb for providing the dumps for working (w/o KWD) and non-working cases:
s0ix-not-working-wov.txt
s0ix-working-wo-kwd.txt
I suspect the assertion of this clock PARCAVSHUB/hda_pgda1/audiofbr_clk blocks the S0ix entry as we have to set CPPMVRIC2 ADSPROSCOFFQDIS bit in order enter S0ix.
keyonjie commentedon Jul 8, 2020
Hi @yongzhi1 chan you try if the PR#3130 helps?
#3130
yongzhi1 commentedon Jul 8, 2020
Thanks @keyonjie , just tried, with KWD running, s0ix not entered with #3130 , @udaymb can you double check as well?
[-][BUG] JSL: Fail to enter S0ix while WoV pipeline is running[/-][+][BUG] [JSL]: Fail to enter S0ix while WoV pipeline is running[/+]yongzhi1 commentedon Jul 16, 2020
With releases/tgl/v7.0-rc9 based sof-jsl.ri and the following config:
CONFIG_CAVS_LPS=n
CONFIG_CAVS_USE_LPRO_IN_WAITI=y
CONFIG_HAVE_AGENT=n
And PGA removed sof-jsl-da7219.tplg now, KWD/S0ix is working without the ROSC bypass( (I.e. CPPMVRIC2 ADSPROSCOFFQDIS bit set)
There was an error with --buffer-size=67200:
[11875910610.677084] ( 8.229167) c0 kpb 8.42 src/audio/kpb.c:1552 ERROR kpb: host_buffer_size (537600) must be at least 588800
[11875910617.760418] ( 7.083333) c0 pipe 8.47 src/audio/pipeline.c:597 ERROR pipeline_prepare(): ret = 22, dev>comp.id = 40
[11875910624.427084] ( 6.666667) c0 ipc src/ipc/handler.c:312 ERROR ipc: pipe 8 comp 40 prepare failed -22
So I tested with --buffer-size=80000:
localhost /sys/kernel/debug/pmc_core # cat slp_s0_debug_status |grep AU
DSLP_S0_DBG: AUDIO_D3 State: Yes
SLP_S0_DBG: AUDIO_PLL_OFF State: No
SLP_S0_DBG: AUDIO_ROSC_OFF State: Yes
In other word, S0ix could be entered successfully now without any disqualifier bit.
keyonjie commentedon Jul 16, 2020
keyonjie commentedon Jul 17, 2020
@yongzhi1 can you try with https://github.com/thesofproject/sof/tree/releases/tgl/v7.0-rc10 (need set --buffer-size=96000) which will be used for the drop? if it is fixed, please help to close it, thanks.
yongzhi1 commentedon Jul 21, 2020
With releases/tgl/v7.0-rc10, there are two issues:
localhost ~ # arecord -Dhw:0,6 -M -N -c 2 -f S24_LE -r 16000 --buffer-size=96000 /tmp/tmp.wav -vvv
[491705032.604167] ( 400.989594) c0 ipc src/ipc/handler.c:631 ipc: pm -> restore
[491706180.781250] ( 1148.177124) c0 pipe 8.47 src/audio/pipeline.c:459 pipe params dir 1 frame_fmt 1 buffer_fmt 0 rate 16000
[491706190.208333] ( 9.427083) c0 pipe 8.47 src/audio/pipeline.c:463 pipe params stream_tag 2 channels 2 sample_valid_bytes 3 sample_container_bytes 4
[491706277.812500] ( 87.604164) c0 hda-dma ..../intel/hda/hda-dma.c:409 hda-dmac: 4 channel 1 -> get
[491706288.906250] ( 11.093750) c0 hda-dma ..../intel/hda/hda-dma.c:594 hda-dmac: 4 channel 1 -> config
[491706374.479167] ( 85.572914) c0 dai 8.46 src/audio/dai.c:356 dai_capture_params() src_dev = 1 stream_id = 0 src_width = 4 dest_width = 4
[491706383.020833] ( 8.541667) c0 dai 8.46 src/audio/dai.c:362 dai_capture_params() fifo 10108
[491706398.802083] ( 15.781250) c0 pipe 8.47 src/audio/pipeline.c:590 pipe prepare
[491706489.166667] ( 90.364586) c0 kpb 8.42 src/audio/kpb.c:434 kpb_prepare()
[491706498.020833] ( 8.854167) c0 kpb src/audio/kpb.c:218 kpb_allocate_history_buffer()
[491709973.541667] ( 3475.520752) c0 memory src/lib/alloc.c:283 ERROR 171 blocks needed for allocation but only 170 blocks are remaining
[491710082.864583] ( 109.322914) c0 kpb src/audio/kpb.c:245 kpb new memory block: 65024
[491710411.145833] ( 328.281250) c0 memory src/lib/alloc.c:283 ERROR 1247 blocks needed for allocation but only 946 blocks are remaining
[491710756.145833] ( 345.000000) c0 memory src/lib/alloc.c:283 ERROR 1246 blocks needed for allocation but only 946 blocks are remaining
[491711079.531250] ( 323.385406) c0 memory src/lib/alloc.c:283 ERROR 1245 blocks needed for allocation but only 946 blocks are remaining
[491711402.552083] ( 323.020844) c0 memory src/lib/alloc.c:283 ERROR 1244 blocks needed for allocation but only 946 blocks are remaining
...
[491813529.947917] ( 10.312500) c0 memory src/lib/alloc.c:283 ERROR 2 blocks needed for allocation but only 0 blocks are remaining
[491813539.270833] ( 9.322917) c0 kpb src/audio/kpb.c:294 kpb_allocate_history_buffer(): allocated 306944 bytes
[491813546.562500] ( 7.291667) c0 kpb src/audio/kpb.c:476 ERROR kpb_prepare(): failed to allocate space for KPB buffer
[491813552.916667] ( 6.354167) c0 kpb src/audio/kpb.c:310 kpb_free_history_buffer()
[491813977.447917] ( 424.531250) c0 pipe 8.47 src/audio/pipeline.c:597 ERROR pipeline_prepare(): ret = -22, dev->comp.id = 40
[491813984.583333] ( 7.135417) c0 ipc src/ipc/handler.c:312 ERROR ipc: pipe 8 comp 40 prepare failed -22
[491813991.250000] ( 6.666667) c0 pipe 8.47 src/audio/pipeline.c:864 pipe reset
With "-f S16_LE", when I wake up the system, another interesting observation is that although slp_s0_residency_usec increases, the latched debug status shows:
localhost /sys/kernel/debug/pmc_core # cat slp_s0_debug_status |grep AU
SLP_S0_DBG: AUDIO_D3 State: No
SLP_S0_DBG: AUDIO_PLL_OFF State: No
SLP_S0_DBG: AUDIO_ROSC_OFF State: No
Just noticed, the KWD pipelines period in topology also needs to change from 20 to 5, so the host capture issue was resolved.
jajanusz commentedon Jul 30, 2020
@yongzhi1 please retest with https://github.com/thesofproject/sof/tree/releases/jsl/v4.0-rc1
yongzhi1 commentedon Jul 31, 2020
Hi @jajanusz ,
Correction, I found the topology has to rebuild based on the same tag because of the detect_test_coef.m4 change, so to confirm S0ix can be entered with v4.0-rc1/v4.0-rc2.
Somehow slp_s0_debug_status does not reflect the real state of ROSC:
localhost /sys/kernel/debug/pmc_core # cat slp_s0_debug_status |grep AU
SLP_S0_DBG: AUDIO_D3 State: No
SLP_S0_DBG: AUDIO_PLL_OFF State: No
SLP_S0_DBG: AUDIO_ROSC_OFF State: No
udaymb commentedon Aug 3, 2020
Hello @yongzhi1, @jajanusz
Waddledoo setup
SOF: https://github.com/thesofproject/sof/tree/releases/jsl/v4.0-rc1(21c8900f)
Kernel: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-5.4
commit 651969cf77a14349b5d500b070298cf102380ff8 + thesofproject/linux#2276
KWD cmd - arecord -Dhw:0,6 -M -N -c 2 -f S24_LE -r 16000 --buffer-size=67200 /tmp/tmp.wav -vvv
WoV s0ix has passed.
localhost /sys/kernel/debug/pmc_core # cat slp_s0_debug_status |grep AU
SLP_S0_DBG: AUDIO_D3 State: No
SLP_S0_DBG: AUDIO_PLL_OFF State: No
SLP_S0_DBG: AUDIO_ROSC_OFF State: Yes
No workarounds
mengdonglin commentedon Aug 4, 2020
Thank you for double check @udaymb Closed this issue as resolved.