[FEATURE] Explicit clock control

Some codecs need external clock (mclk or bclk) to be ready in prepare stage or some function may broken.

To support those codec, we need to implement explicit clock control so machine driver could enable/disable the clock via DAPM supply widget or set_bias_level callback.

This feature has been implemented on SST FW running on Chrome KBL platforms. Following are the mailthread:
https://mailman.alsa-project.org/pipermail/alsa-devel/2017-November/127833.html
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-October/156161.html

same request in linux
thesofproject/linux#2907

This was a feature we've put on the back burner since November 2018. #629

If you just want the blk and MCLK, it's rather easy to enable since it's just a change in the clock settings. But if you want the FSYNC to be enabled on demand, then it requires firmware to enable pretend DMA transfers with zero-based values, a lot more work.

@cujomalainey

If I am not mistaken this also causes a 400ms delay on GLK, if the clock is not enabled the codec will play audio with a delay.
I just can't find the issue any longer. @cujomalainey @bzhg can you help track this?

@cujomalainey

If I am not mistaken this also causes a 400ms delay on GLK, if the clock is not enabled the codec will play audio with a delay.
I just can't find the issue any longer. @cujomalainey @bzhg can you help track this?

is this one @plbossart ?
#2124

@sathya-nujella

Yes @sathya-nujella that was issue #2124 I was looking for, but it does make a reference to the WCLK aka FrameSync, so it's not trivial to fix.

@plbossart

@plbossart At least we need to support BCLK for cs42l42. It would be better if MCLK could be supported as well since some codecs like rt5514 needs MCLK.

~~This would also help solve the long pcm open call for da7219 correct?~~

Got lazy didn't read whole bug, yes, i think your mean #2124

This would also help solve the long pcm open call for da7219 correct?

depends what you want for cs42l42. If it's bclk and mclk, it's easier, but that isn't enough for DA7219 which needs FSYNC to be active

@plbossart

@plbossart This is Karl Sun from Cirrus . For cs42l42 ,the the PLL lock will be dependent from bclk input. Then we have all the correct setting ready for Dout and DIn.

Can anyone give some feedback on the expected clock preamble duration prior to audio data being sent ? This would help with the design.

@brentlu

Can anyone give some feedback on the expected clock preamble duration prior to audio data being sent ? This would help with the design.

yes, I don't get what is needed. @brentlu added a 10ms delay initially in the topology but it doesn't seem to fix the issue.

@hhyshw

10ms delay is for another TX noise issue. The delay is between bclk on and dma enable to avoid noise.

my understanding of PLL issue is that: this codec requires bclk ready in prepare stage

@hhyshw would you confirm if my understanding is correct and describe the clock requirement of the codec with more detail? thanks.

At the stage, the sclk is sent out at the SNDRV_PCM_TRIGGER_START signal of trigger(). But we can't do any register access in a trigger() function that will cause kernel warnings about blocking in an atomic context (and if you don't have that warning enabled, it can cause silent bugs. ). We have tried to have a workaround patch at trigger https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2874751 but it seemed that we met with one potential issue https://partnerissuetracker.corp.google.com/u/1/issues/187911216 to read/write registers at trigger().
The main line branch that we are using is that the code in cs42l42_mute_stream() to switch back to internal oscillator, and implement the PLL Lock request. Here we met with PLL unlock issue without the sclk signal that is always later than we request PLL lock.
Ideally to support CS42L42 clocking mechanism we would hope clocks start / stop in Enable sclk in hw_prepare() / Disable SCLK in hw_free() callbacks. In this case we can guarantee that internal clock and external sclk clock source switch smoothly for audio playback.
I have read the https://mailman.alsa-project.org/pipermail/alsa-devel/2019-October/156161.html that sclk is enabled early enough and disabled after the headphone audio track stops. It looks fine to me .

@snake0x65

@snake0x65 I don't fully understand the request. At what point do you switch from PLL to internal clock?

My worry is that if we keep the SCLK active until the hw_free, the SOF hw_free will be executed before the codec hw_free, and we still have a deadlock.

@plbossart

@plbossart , sorry, my explanation might be a bit confusing. CS42l42 HW required clocks to be present at the moment of switch from internal clocks to external SCLK and back. The transition takes ~150us. Currently, we are using mute_stream() callback to switch to/from PLL. UNMUTE event -> we switch to PLL, MUTE -> we switch to internal clocks. The problem is that (observed in 4.14 kernel) when mute_stream() is called to unmute SCLK still not available, and when mute_stream() callback is called to mute, SCLK has already stopped. So, we need 2 points where SCLK is stable to make a safe switch to/from PLL. When we use SCLK as a reference for PLL and suddenly SCLK is removed then the I2C bus will be dead and all transitions will fail. We cannot recover from this condition until HW reset.
For transition to PLL we can use PLL_LOCK interrupt, we start PLL, and then when PLL_LOCK happened we can switch from internal clocks to PLL safely, But, the problem is still in switching back from PLL to internal clocks in unmute_stream() as at this point SCLK already stopped and I2C is dead.

@snake0x65

@snake0x65 I am not familiar with this mute_stream thing, we only deal with trigger_stop, hw_free and release. Where would you want us to stop the clock?

@plbossart

@plbossart hw_free() would be ideal for stop

@snake0x65

Thanks @snake0x65, we will assume the direction is to turn on the BCLK and FSYNC during .prepare() (or maybe .hw_params(), tbd) and turn them off during .hw_free(). I don't think we have a limitation at the hardware level, but there are currently missing steps in the firmware if you see #4189

Hi,

I implement a virtual clock driver for mclk/bclk on Linux side and add a new IPC command on FW side to support explicit clock control. Tested on my TGL chromebook.

Kernel: Chrome v5.4 kernel
FW: main head of sof github

thesofproject/linux#2932
#4213

Regards,
Brent

@plbossart

This feature is a duplicate of #629. Close it. @plbossart @bardliao @brentlu Let's track #629. Thanks

Navigation Menu

Repository navigation

[FEATURE] Explicit clock control #4156

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE] Explicit clock control #4156

Description

Activity

brentlu commented on May 10, 2021

plbossart commented on May 10, 2021

plbossart commented on May 10, 2021

sathya-nujella commented on May 10, 2021

plbossart commented on May 10, 2021

brentlu commented on May 10, 2021

cujomalainey commented on May 10, 2021

plbossart commented on May 10, 2021

hhyshw commented on May 12, 2021

lgirdwood commented on May 12, 2021

plbossart commented on May 12, 2021

brentlu commented on May 12, 2021

hhyshw commented on May 12, 2021

6 remaining items

plbossart commented on May 13, 2021

snake0x65 commented on May 14, 2021

plbossart commented on May 14, 2021

snake0x65 commented on May 14, 2021

plbossart commented on May 14, 2021

brentlu commented on May 19, 2021

mengdonglin commented on Feb 16, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions