summaryrefslogtreecommitdiff
path: root/sound/soc/sof/pcm.c
diff options
context:
space:
mode:
authorMark Brown <broonie@kernel.org>2021-11-24 20:33:54 +0300
committerMark Brown <broonie@kernel.org>2021-11-24 20:33:54 +0300
commitcd2f33e93d578e9e1c47ef8981ec69298da9cb38 (patch)
tree4d971b7745f89cd0b9dab97750bdce811f954de1 /sound/soc/sof/pcm.c
parent96da174024b9c63bd5d3358668d0bc12677be877 (diff)
parent6c26b5054ce2b822856e32f1840d13f777c6f295 (diff)
downloadlinux-cd2f33e93d578e9e1c47ef8981ec69298da9cb38.tar.xz
ASoC: SOF: Intel: power optimizations with HDaudio SPIB register
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: The use of the SPIB register helps reduce power consumption - though to a smaller degree than DMI_L1. This hardware capability is however incompatible with userspace-initiated rewinds typically used by PulseAudio. In the past (2015..2017) Intel suggested an API extension to let applications disable rewinds. At the time the feedback was that such a capability was too Intel-specific and SPIB remained unused except for loading DSP code. We now see devices with smaller batteries being released, and it's time to revisit Linux support for SPIB to extend battery life. In this update the rewinds are disabled via an opt-in kernel parameter. In the previous reviews, there was consensus that a Kconfig option was too complicated for distributions to set, and we are missing a TBD API to expose such capabilities to user-space. The debate on whether or not to use rewinds, and the impact of disabling rewinds, will likely be closed when Intel releases the 'deep-buffer' support, currently under development [2][3]. With this solution, rewinds will not be needed, ever. When an application deals with content that is not latency-sensitive (e.g. music playback), it will be able to reduce power consumption by selecting a different PCM device with increased buffering capabilities. Low-latency streams will be handled by the 'regular' path. In other words, the impossible compromise between power and latency will be handled with different PCM devices/profiles for the same endpoint, and we can push the design of capability negotiation to a later time when all the building blocks (firmware topology, kernel, userspace) are ready - we still have firmware xruns, DPCM race conditions to solve, and a need to describe these alternate PCM devices with UCM using 'modifiers'.
Diffstat (limited to 'sound/soc/sof/pcm.c')
-rw-r--r--sound/soc/sof/pcm.c9
1 files changed, 9 insertions, 0 deletions
diff --git a/sound/soc/sof/pcm.c b/sound/soc/sof/pcm.c
index 0ceb1a9cbf73..1bf7e60be772 100644
--- a/sound/soc/sof/pcm.c
+++ b/sound/soc/sof/pcm.c
@@ -916,6 +916,14 @@ static void sof_pcm_remove(struct snd_soc_component *component)
snd_soc_tplg_component_remove(component);
}
+static int sof_pcm_ack(struct snd_soc_component *component,
+ struct snd_pcm_substream *substream)
+{
+ struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(component);
+
+ return snd_sof_pcm_platform_ack(sdev, substream);
+}
+
void snd_sof_new_platform_drv(struct snd_sof_dev *sdev)
{
struct snd_soc_component_driver *pd = &sdev->plat_drv;
@@ -934,6 +942,7 @@ void snd_sof_new_platform_drv(struct snd_sof_dev *sdev)
pd->hw_free = sof_pcm_hw_free;
pd->trigger = sof_pcm_trigger;
pd->pointer = sof_pcm_pointer;
+ pd->ack = sof_pcm_ack;
#if IS_ENABLED(CONFIG_SND_SOC_SOF_DEBUG_PROBES)
pd->compress_ops = &sof_probe_compressed_ops;