summaryrefslogtreecommitdiff
path: root/include
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 /include
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 'include')
-rw-r--r--include/uapi/sound/asound.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 5fbb79e30819..ff7e638221c5 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -300,7 +300,7 @@ typedef int __bitwise snd_pcm_subformat_t;
#define SNDRV_PCM_INFO_HAS_LINK_ESTIMATED_ATIME 0x04000000 /* report estimated link audio time */
#define SNDRV_PCM_INFO_HAS_LINK_SYNCHRONIZED_ATIME 0x08000000 /* report synchronized audio/system time */
#define SNDRV_PCM_INFO_EXPLICIT_SYNC 0x10000000 /* needs explicit sync of pointers and data */
-
+#define SNDRV_PCM_INFO_NO_REWINDS 0x20000000 /* hardware can only support monotonic changes of appl_ptr */
#define SNDRV_PCM_INFO_DRAIN_TRIGGER 0x40000000 /* internal kernel flag - trigger in drain */
#define SNDRV_PCM_INFO_FIFO_IN_FRAMES 0x80000000 /* internal kernel flag - FIFO size is in frames */