SSP: need to support MCLK/BCLK/LRCLK on-demand on/off capabilities

[plbossart]

Some codecs need the MCLK/BCLK/LRCLK to be on before streaming starts (typically 10s of ms to avoid clicks/pops), see e.g. https://elixir.bootlin.com/linux/latest/source/sound/soc/intel/boards/kbl_rt5663_max98927.c#L86 for RT5663

The SSP IPC supports keeping the clock on a boot via the clks_control field, but it's not currently implemented. We would also miss IPC support for on/off requests on-demand (new IPC required?)

Adding @lgirdwood and @mmaka1 as assignees mainly to get comments on what IPC changes would be needed, the implementation can be done later.

[lgirdwood]

This could be done with another optional IPC sent during prepare() and before trigger.

[dbaluta]

@plbossart @lgirdwood
So the clocks handling is done on the host side and DSP sends requests for various operations on the clocks, right?

[plbossart]

On 2/22/19 1:26 AM, Daniel Baluta wrote: One question: so the clock handling is done on the host side and DSP sends request for various operations on the clocks, right?

No, it's the other way around. The machine driver may request the I2S/MCLK clocks to be turned-on (either at boot e.g. for an automotive platform) or on-demand with DAPM events (e.g. for mobile devices). the machine driver uses the clk API to make that request, and the clk is actually exposed by the SOF driver which in turn tells the firmware to activate the clocks. On intel platforms if the bclk or frame_sync are requested, we have to enable a dummy transfer with zero samples to avoid underflow interrupts/status. On older devices (Baytrail/Cherrytrail) the MCLK is already exposed with the clock API, but it's enabled with PMC registers and not the audio DSP ones.

[dbaluta]

@plbossart Thanks, I understand! On i.MX clock handling would be really fun to implement :). That's because the clock handling is taken care by a separate firmware (running on an M4) and now is handled with commands from the host (Linux) side. So for this reason I've asked about the direction.

[lgirdwood]

@dbaluta looks like your i.MX SOF driver will need to program M4 ? There are PCM callbacks in the SOF HW abstraction layer so you could add your M4 programming to the hw_params() or prepare() callback ? Btw, if you need other callbacks, then feel free to send a PR.

[mengdonglin]

Comments from Pierre "These features will be enabled with IPC4, in fact I am working on them at the moment since the way to control them is via a gateway configuration in addition to the binary blobs coming from NHLT.

The activation of clocks is handled with a 'gateway configuration', which is made of the 'SSP blob' along with additional commands to configure clocks early.

This capability is handled by the cAVS firmware... I am thinking this is part of the plan for the converged firmware."

@mwasko @lgirdwood Can you please confirm this capability will be supported by the converged firmware?

[lgirdwood]

@mmaka1 @marcinszkudlinski pls confirm ?

[mwasko]

Comments from Pierre "These features will be enabled with IPC4, in fact I am working on them at the moment since the way to control them is via a gateway configuration in addition to the binary blobs coming from NHLT.

The activation of clocks is handled with a 'gateway configuration', which is made of the 'SSP blob' along with additional commands to configure clocks early.

This capability is handled by the cAVS firmware... I am thinking this is part of the plan for the converged firmware."

@mwasko @lgirdwood Can you please confirm this capability will be supported by the converged firmware?

yes