linux.git/sound/soc/sof/pcm.c, branch v6.7

ASoC: sof: convert not to use asoc_xxx()

2023-09-26T15:18:42+00:00

ASoC is now unified asoc_xxx() into snd_soc_xxx().
This patch convert asoc_xxx() to snd_soc_xxx().

Signed-off-by: Kuninori Morimoto 
Link: https://lore.kernel.org/r/87sf71fo32.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown

ES8316 audio codec fixes on Rock5B

2023-05-30T19:41:29+00:00

Merge series from Cristian Ciocaltea :

This patch series handles a few issues related to the ES8316 audio
codec, discovered while doing some testing on the Rock 5B board.

ASoC: SOF: Simplify the calculation of variables

2023-05-15T11:14:34+00:00

./sound/soc/sof/pcm.c:372:27-29: WARNING !A || A && B is equivalent to !A || B.

Reported-by: Abaci Robot

ASoC: SOF: pcm: fix pm_runtime imbalance in error handling

2023-05-15T01:20:58+00:00

When an error occurs, we need to make sure the device can pm_runtime
suspend instead of keeping it active.

Signed-off-by: Pierre-Louis Bossart

ASoC: SOF: pcm: Add an option to skip platform trigger during stop

2023-04-20T11:51:59+00:00

In the case of IPC4, a pipeline is only paused during STOP/PAUSE/SUSPEND
triggers and the FW keeps the host DMA running when a pipeline is
paused. The start/stop tests iterate through STOP/START triggers without
involving a hw_free. This means that the pipeline state will only toggle
between PAUSED (during the STOP trigger) and RUNNING (during the START
trigger). So this test should be treated in the same way as a
PAUSE_PUSH/PAUSE_RELEASE test and the DMA should be kept running when
toggling the pipeline states between PAUSED and RUNNING.

Since there is no way to tell if a STOP trigger will be followed by hw_free
or not, this patch proposes to always skip DMA stop during the STOP trigger
and handle it later during hw_free. Introduce a new flag in struct
sof_ipc_pcm_ops, delayed_platform_trigger, that will be used to ensure that
the host DMA will not be stopped during the STOP/PAUSE/RELEASE triggers
and set it for IPC4. The platform_trigger call to stop the DMA will be
invoked during PCM hw_free instead when the pipeline is reset.

Signed-off-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Péter Ujfalusi 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20230420114137.27613-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Add support for DSPless mode

2023-04-04T11:42:34+00:00

Via the SOF_DBG_DSPLESS_MODE sof_debug flag the SOF stack can be asked to
not use the DSP for audio.

The core's support for DSPless mode is only going to be enabled if the
platform reports that it can be used without DSP.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Rander Wang 
Link: https://lore.kernel.org/r/20230404092115.27949-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: pcm: Improve the pcm trigger sequence

2023-03-22T13:17:31+00:00

The recommended sequence for triggering the host DMA is to first program
the DMA in the FW before setting the RUN bit to start the stream in the
host. With IPC3, this sequence is honored because the FW programs the
DMA when the HW_PARAMS IPC is sent during PCM hw_params and then the host
sets the RUN bit during sof_pcm_trigger(). But with IPC4,
sof_pcm_trigger() sends the SET_PIPELINE_STATE IPC to program the DMA in
the FW after the DMA RUN bit is set.

In order to minimize the impact for IPC3, introduce a new flag as part
of struct sof_ipc_pcm_ops, ipc_first_on_start, which will be set for IPC4
only. With this flag set, the SET_PIPELINE_STATE IPC will be sent before
the DMA RUN bit is set by the host during the START/PAUSE_RELEASE
triggers.

Signed-off-by: Ranjani Sridharan 
Reviewed-by: Péter Ujfalusi 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20230322094346.6019-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: pcm: Make hw_params reset conditional for IPC3

2023-03-22T13:17:31+00:00

In the case of IPC4, since there is no PCM_PARAMS IPC to send the new
stream tag when restarting a stream without a hw_free, the original
stream tag needs to be preserved. So, add new a flag as part of struct
sof_ipc_pcm_ops, reset_hw_params_during_stop and set it only for IPC3.
This will ensure that the host DMA stream tag will not be given up during
the STOP trigger for IPC4.

Signed-off-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Reviewed-by: Bard Liao 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20230322094346.6019-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: add delay function support in sof framework

2023-02-03T12:03:52+00:00

Sof framework will call specific delay function for
different IPC version.

Signed-off-by: Rander Wang 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Bard Liao 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20230202132954.26773-7-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: pcm: do not free widgets during suspend trigger

2023-01-27T12:14:02+00:00

IPC3 and IPC4 have different requirements for the order in which the FE
CPU and BE CPU DAI trigger callbacks must be invoked. With a regular PCM
start/stop, pipeline widgets are set up during hw_params and freed
during hw_free.

But when the system is suspended when a PCM is running,
pipeline widgets are freed during the SUSPEND trigger callback for the
FE CPU DAI. In order to avoid freeing the pipeline widgets before the BE
CPU DAI trigger is executed, the trigger order was modified in previous
contributions in the PCM dai_link_fixup callback to make sure that the BE
CPU DAI trigger stop/suspend is always invoked before the FE CPU DAI
trigger. But this contradicts the firmware requirement for IPC4 w.r.t.
ordering of pipeline triggers.

So, remove the freeing of pipeline widgets during FE CPU DAI suspend
trigger and handle it during system suspend when the
tear_down_all_pipelines() IPC op is invoked. This will be followed up
with a patch to fix the trigger order for IPC4.

Signed-off-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Péter Ujfalusi 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20230127120031.10709-6-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown