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'.
This patch prepares the introduction of the compress API with SOF.
After each fragment is accepted by the DSP we need to inform
the userspace applications that they can send the next fragment.
This is done via snd_compr_fragment_elapsed.
Similar with the PCM case, in order to avoid sending an IPC before
the previous IPC is handled we need to schedule a delayed work to
call snd_compr_fragment_elapsed().
See snd_sof_pcm_period_elapsed.
To sum up this patch offers the following API to SOF code:
* snd_sof_compr_init_elapsed_work
* snd_sof_compr_fragment_elapsed
Note that implementation for compressed function is in a new file
selected via CONFIG_SND_SOC_SOF_COMPRESS invisible config option.
This option is automatically selected for platforms that support
the compress interface. For now only i.MX8 platforms support this.
For symmetry we introduce snd_sof_pcm_init_elapsed_work to setup
the work struct for PCM case.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Bud Liviu-Alexandru <budliviu@gmail.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20211004152147.1268978-5-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for dynamic pipelines by modifying the PCM
hw_params ioctl implementation to determine the widgets
required for a PCM stream by querying the list of
connected DAPM widgets. This list is saved as part of
snd_sof_pcm_stream struct and will be used to setup the widgets.
The sof_widget_list_setup/free routines setup and free connected
DAPM widgets when a PCM is opened/closed. These routines accept
a list of connected DAPM widgets as input and determine the SOF
widgets, their corresponding pipeline widgets and connections
between them that need to be setup before the PCM is triggered.
Please note that the dynamic pipeline feature will only be enabled
for those pipelines whose dynamic_pipeline_widget flag is set in
topologies. Add a new token called SOF_TKN_SCHED_DYNAMIC_PIPELINE
that when set in topology will be applied to the
dynamic_pipeline_widget flag of the pipeline widget.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20210927120517.20505-12-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current SOF implementation limits period and buffer sizes to multiples
of period_min. Period_min is defined in topology, but is in practise set
to align with the SOF DSP timer tick (typically 1ms).
While this approach helps user-space to avoid period sizes, which are
not aligned to the DSP timer tick, it causes problems to applications
which want to align data processing size to that of ALSA period size.
One example is JACK audio server, which limits period sizes to power of
two values.
Other ALSA drivers where audio data transfer is driven by a timer tick,
like USB, do not constraint period and buffer sizes to exact multiple of
the timer tick.
To align SOF to follow the same behaviour, drop the additional alignment
constraints. As a side-effect, this patch can cause irregularity to
period wakeup timing. This happens when application chooses settings
which were previously forbidden. For example, if application configures
period size to 2^14 bytes and audio config of S32_LE/2ch/48000Hz, one
period represents 42.667ms of audio. Without this patch, this
configuration is not allowed by SOF. With the patch applied,
configuration is allowed but the wakeups are paced by the DSP timer
tick, which is typically 1ms. Application will see period wakeups with a
42/43/42/43ms repeating pattern.
Both approaches are valid within ALSA context, but relaxing the
constraints is better aligned with existing applications and other ALSA
drivers like USB audio.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20201118140545.2138895-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As discussion in ALSA https://patchwork.kernel.org/patch/11336023/, it
is suggested to skip DMA buffer pre-allocation with passing size=0 when
calling snd_pcm_set_managed_buffer(), to make the full buffer_bytes
range configured in topology file selectable from user space, here do
the corresponding change in SOF PCM driver to implement it.
This change doesn't have dependency to the change that Takashi will do
in the ALSA core by adding total_pcm_alloc_bytes limitation to the
struct snd_card, it passes tests both with or without Takashi's coming
change on SOF CML platform.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Link: https://lore.kernel.org/r/20200228231850.9226-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Any app using ALSA OSS emulation on top of SOF will fail
to error from OSS SNDCTL_DSP_SETFMT ioctl. Reported initially
as an issue with xournalpp (application using PortAudio with
an OSS backend), but applies more generally to other apps
using OSS as well.
Problem is caused by SOF PCM not supporting repeated calls
to hw_params(), without matching calls to pcm_free(). This
is however exactly what the ALSA OSS PCM code is doing when
it is handling the OSS ioctls.
The problem will lead to leaking of DSP resources and eventual
failure of DSP PCM_PARAMS IPC.
BugLink: https://github.com/thesofproject/linux/issues/1510
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200110235751.3404-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move all the audio-specific code in the core,
audio-specific logic in the top-level PM callbacks
and the core header files into a separate file
(sof-audio.*) in preparation for adding an
audio client device.
In the process of moving all structure definitions
for widget, routes, pcm's etc, the snd_sof_dev
member in all these structs is replaced with
the snd_soc_component member. Also, use the component
device instead of the snd_sof_dev device wherever
possible in the PCM component driver,
control IO functions and the topology parser as the
component device will be moved over to the client
device later on.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191204211556.12671-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_pcm_sgbuf_ops_page is no longer needed to be set explicitly to PCM
page ops since the recent change in the PCM core (*). Leaving it NULL
should work as long as the preallocation has been done properly.
This patch drops the redundant lines.
(*) 7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20191108094641.20086-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
During system suspend, the PM framework will freeze all applications and
the ALSA/ASoC core will suspend all RUNNING PCM streams.
However, D0ix-compatible PCM streams should keep the related pipelines
active in the DSP when the system is entering S0ix. The TRIGGER_SUSPEND
event is trapped in such cases to prevent the pipelines from being
stopped. Likewise, the TRIGGER_RESUME/START events should not affect the
pipeline state.
The SOF driver also triggers some DSP Firmware pipelines based on the
DAPM widgets power events. In such cases, we also ignore PRE_PMU and
POST_PMD events to keep the pipelines active.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191025224122.7718-23-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
