Repository navigation
[BUG] GLK Chromebooks with da7219 have 400ms delay waiting for SRM lock #2124
Description
Describe the bug
There is a 400ms delay when calling snd_pcm_prepare on glk chromebooks using the da7219 since the code to wait for the SRM lock times out after 400ms. I spoke with the author of the codec driver at Dialog, and their response was:
"I'm almost certain this is because the platforms in question are not enabling the WCLK before the codec's PLL is being enabled. [...] So on the Apollo lake and Kaby lake platforms (and probably other Intel ones using DA7219) what would happen is that the codec's PLL would be enabled before WCLK, you see the timeout in the kernel logs after the large delay, and then subsequently (at some point) the Intel I2S related code would then enable the WCLK and the PLL would then lock with SRM."
To Reproduce
Just starting a stream using "aplay /dev/zero" is sufficient to trigger this bug. There will be a noticeable delay of about 700ms before audio starts.
The message "da7219 i2c-DLGS7219:00: SRM failed to lock" will also appear in dmesg.
Reproduction Rate
Every time a stream is started with the codec powered down.
Expected behavior
The SRM lock bit should be flipped before the 400ms is elapsed and we should not see the delay/warning message in dmesg.
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Name of the topology file
- Topology: presumably sof-glk-da7219.m4
- Name of the platform(s) on which the bug is observed.
- Platform: GLK Chromebooks
Activity
plbossart commentedon Nov 21, 2019
Humm... All machine drivers based on da7219 pretty much do the same thing, so not sure why this would be specific to GLK?
besides, the MCLK is provided, so not sure why the codec would lock on the WCLK? The PLL reference should the be the MCLK, not WCLK.
cujomalainey commentedon Nov 22, 2019
This is not specific to GLK, we are just logging this here as a GLK bug since this is the only SOF based board that we have the da7219 on that we are seeing this issue with currently and figured since SOF is under active development we should report it here first.
lgirdwood commentedon Nov 22, 2019
@sathyap-chrome fyi
plbossart commentedon Nov 22, 2019
ok, thanks for the precision.
I think at some point we discussed turning on the bclock earlier, if it was needed, but if we'd need to turn the fsync/WCLK earlier that's a completely different story, we need need to start dummy transfers.
@lbetlej please correct me if I am saying something silly here.
cujomalainey commentedon Nov 22, 2019
Jimmy pointed out there appears to be something similarly done for rt5663 on kbl. Maybe something similar needs to be done for all da7219 boards? https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/764232/
plbossart commentedon Nov 22, 2019
one of the difference with KBL is that the SOF firmware does not provide (yet) the ability to start BCLK/FSYNC on demand from the machine driver.
It's something we know we'll need but it's not there just yet.
lgirdwood commentedon Nov 23, 2019
@plbossart thinking aloud here would could have a tuple flag for this in DAI topology (to enable certain clocks immediately after hw_params are known) e.g.
plbossart commentedon Nov 25, 2019
Yes, and I remember discussing this with @lbetlej. We can enable MCLK and BCLK as soon as the config is known, and we can use the existing SSP quirk mask to indicate the desire behavior.
The issue is for the WCLK/FSYNC, you have to enable it with dummy transfers so it's a completely different solution that would be needed.
lgirdwood commentedon Nov 25, 2019
@plbossart ouch, I can see why codec vendor has done this but from a system integration perspective it's undesirable (pretty much for every serial DAI IP from any vendor). Gah.
plbossart commentedon Nov 25, 2019
@lgirdwood see https://github.com/thesofproject/linux/blob/58ed327217ba03698a14191fe17c540551bb956e/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c#L102 for examples of what was done in the past to toggle the clocks on/off from the machine driver.
tlauda commentedon Mar 19, 2020
@lgirdwood @plbossart Keeping this here or maybe turning into feature?
lgirdwood commentedon Mar 19, 2020
@plbossart machine driver infrastructure in ASoC ? or something similar ? My only other though is putting this 400ms delay in codec trigger() (not used atm IIRC)
plbossart commentedon Mar 19, 2020
we really need to expose MCLK, BCLK, FSYNC with the clock framework and let the machine driver turn them on/off at will (either on startup/shutdown or on DAPM event).
it's been done before by the Skylake driver. The main issue for us is the FSYNC which can only work if we start dummy DMA transfers with zero-ed data. MCLK and BCLK can be turned on without audio transfers.
lgirdwood commentedon Mar 20, 2020
@plbossart we could hook this into hw_params IPC. i.e. have a topology flag that just says "keep playing silence until trigger(start)". This way FW can play silence, we schedule pipeline normally but we manually disconnect the DAI source component from the DAI buffer (until we get trigger(start) where we can then reconnect the DAI buffer source component and process the full pipeline).
@tlauda any take on this ?
6 remaining items
lgirdwood commentedon Apr 10, 2020
@plbossart fine by me, the FW change is the same either way.
plbossart commentedon Apr 10, 2020
right, but the clock framework is a bit of a pain to implement.
lgirdwood commentedon Apr 10, 2020
The path of least resistance is maybe DAPM then ?
plbossart commentedon Apr 10, 2020
No I am thinking that maybe the right thing to do is have the SOF core create a clock client - but only when an I2S-based machine driver is used and not for HDaudio. Then the client sends IPCs as required. Since we can play with pm_runtime in the prepare_enable/disable_deprepare, the DSP would remain on as long as the clock is needed.
We could even prototype this with a small change to @ranj063 's PC test client, instead of flooding the DSP we'd only send specific clock-related IPCs.
bardliao commentedon Aug 11, 2020
@lgirdwood @plbossart Won't MCLK be turned on in or right after snd_sof_rintime_resume()?
@macchian Could you measure the delay in each process?
For example DSP boot: 20ms, waiting for MCLK ready: 100ms, codec power up: 150ms...
So we can focus on the critical part to shorten the delay time.
lgirdwood commentedon Aug 11, 2020
@macchian is this still an issue or has it been solved hence the lack of discussion ?
cujomalainey commentedon Aug 11, 2020
I am still seeing activity on internal bug
brentlu commentedon Aug 12, 2020
Turning on mclk does not help because da7219 tries to lock the fsync in prepare stage. Another possible fix is using it's "PLL bypass mode" but it requires 11.288/24.576/49.152MHz mclk. This frequency could be achieved by using cardinal clock but KBL does not support it.
brentlu commentedon Aug 18, 2020
Another issue is there is 220ms delay which is caused by codec driver itself (30ms x 2 in da7219_mixout_event(), 40ms x 4 in da7219_mixout_event()). Google is about to check the 220ms delay with DA.
plbossart commentedon Jul 14, 2021
@brentlu @cujomalainey @fletcherw @bzhg does the recent work with the early BCLK enabling solve this SRM lock delay? I vaguely recall seeing such a statement, but the explanations above only talk about FSYNC which is still enabled in the trigger phase when data transfers start (the actual data come with a delay due to SOF pipelining).
Also adding @lgirdwood and @sathya-nujella on the Intel side.
cujomalainey commentedon Jul 15, 2021
I haven't tested, I am working remote till aug ~10 (currently at the mercy of westjet and they are doing their best to mess with me) so I can't pull ToT and test. I didn't see any work land in the machine driver for the da7219, we would need to enable the clock early there wouldn't we?
plbossart commentedon Jul 15, 2021
we use the same topology as for the CS42L42 and the changes in the kernel are related to the SSP in general, not the machine driver.
github-actions commentedon Jun 20, 2025
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.