A BE connected to more than one FE, e.g. in a mixer case, can go
through the following transitions.
play FE1 -> BE state is START
pause FE1 -> BE state is PAUSED
play FE2 -> BE state is START
stop FE2 -> BE state is STOP (see note [1] below)
release FE1 -> BE state is START
stop FE1 -> BE state is STOP
play FE1 -> BE state is START
pause FE1 -> BE state is PAUSED
play FE2 -> BE state is START
release FE1 -> BE state is START
stop FE2 -> BE state is START
stop FE1 -> BE state is STOP
play FE1 -> BE state is START
play FE2 -> BE state is START (no change)
pause FE1 -> BE state is START (no change)
pause FE2 -> BE state is PAUSED
release FE1 -> BE state is START
release FE2 -> BE state is START (no change)
stop FE1 -> BE state is START (no change)
stop FE2 -> BE state is STOP
The existing code for PAUSE_RELEASE only allows for the case where the
BE is paused, which clearly would not work in the sequences above.
Extend the allowed states to restart the BE when PAUSE_RELEASE is
received, and increase the refcount if the BE is already in START.
[1] the existing logic does not move the BE state back to PAUSED when
the FE2 is stopped. This patch does not change the logic; it would be
painful to keep a history of changes on the FE side, the state machine
is already rather complicated with transitions based on the last BE
state and the trigger type.
Reported-by: Bard Liao <bard.liao@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20211207173745.15850-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On start/pause_release/resume, when more than one FE is connected to
the same BE, it's possible that the trigger is sent more than
once. This is not desirable, we only want to trigger a BE once, which
is straightforward to implement with a refcount.
For stop/pause/suspend, the problem is more complicated: the check
implemented in snd_soc_dpcm_can_be_free_stop() may fail due to a
conceptual deadlock when we trigger the BE before the FE. In this
case, the FE states have not yet changed, so there are corner cases
where the TRIGGER_STOP is never sent - the dual case of start where
multiple triggers might be sent.
This patch suggests an unconditional trigger in all cases, without
checking the FE states, using a refcount protected by the BE PCM
stream lock.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20211207173745.15850-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When more than one FE is connected to a BE, e.g. in a mixing use case,
the BE can be triggered multiple times when the FE are opened/started
concurrently. This race condition is problematic in the case of
SoundWire BE dailinks, and this is not desirable in a general
case.
This patch relies on the existing BE PCM lock, which takes atomicity into
account. The locking model assumes that all interactions start with
the FE, so that there is no deadlock between FE and BE locks.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[test, checkpatch fix and clarification of commit message by plbossart]
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20211207173745.15850-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The existing locking for DPCM has several issues
a) a confusing mix of card->mutex and card->pcm_mutex.
b) a dpcm_lock spinlock added inconsistently and on paths that could
be recursively taken. The use of irqsave/irqrestore was also overkill.
The suggested model is:
1) The pcm_mutex is the top-most protection of BE links in the FE. The
pcm_mutex is applied always on either the top PCM callbacks or the
external call from DAPM, not taken in the internal functions.
2) the FE stream lock is taken in higher levels before invoking
dpcm_be_dai_trigger()
3) when adding and deleting a BE, both the pcm_mutex and FE stream
lock are taken.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[clarification of commit message by plbossart]
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20211207173745.15850-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Stephan Gerhold <stephan@gerhold.net>:
This series makes it possible to route audio through the combined
audio/modem DSP on MSM8916/APQ8016 devices instead of bypassing it using
the LPASS drivers. This is necessary to support certain functionality such
as voice call audio. See PATCH 4/5 for details.
Also, qcom,apq8016-sbc.txt is converted to DT schema by adding it to the
existing qcom,sm8250.yaml. The bindings are similar enough that it is easier
to share a single schema instead of duplicating everything into multiple ones.
Fix the following sparse warning: (new ones prefixed by >>)
>> sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c:370:33:
sparse: sparse: incorrect type in argument 3 (different base types)
sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c:370:33: sparse:
expected unsigned int to
sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c:370:33: sparse:
got restricted snd_pcm_format_t [usertype]
Correct discription of format, use S32_LE and S24_LE to distinguish the
different 32bit.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20211209073224.21793-1-jiaxin.yu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The apq8016-sbc-sndcard is designed to be used with the LPASS drivers
(bypassing the combined audio/modem DSP in MSM8916/APQ8016).
Make it possible to use QDSP6 audio instead for the msm8916-qdsp6-sndcard.
This only requires adding some additional hooks that set up the DPCM
backends correctly. Similar code is already used in drivers for newer
SoCs such as apq8096.c, sdm845.c and sm8250.c.
A slightly different initialization sequence is used for the apq8016-sbc
and msm8916-qdsp6 sound card by defining the apq8016_sbc_add_ops()
function as device match data.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20211202145505.58852-6-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
There are two possible audio setups on MSM8916/APQ8016: Normally the audio
is routed through the audio/modem DSP (covered by the qdsp6 driver). During
upstreaming for the DragonBoard 410c it was decided to bypass it and
instead talk directly to the audio controller using the "lpass" driver.
Bypassing the DSP gives more control about the audio configuration but limits
the functionality: For example, routing audio through the audio/modem DSP is
strictly required for voice call audio. Also, without the special changes in
the DB410c firmware other MSM8916 devices can only use the bypass as long as
the modem DSP is not started. Otherwise, the firmware will assume control of
the LPASS hardware block and audio is no longer functional.
Add support for using the DSP audio setup instead using a new
"qcom,msm8916-qdsp6-sndcard" compatible. It is basically a mixture of
the apq8016-sbc-sndcard and the newer sm8250-sndcard, which uses
indirect QDSP6 DAI links instead of the direct LPASS DAI links.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211202145505.58852-5-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
All the Qualcomm sound card drivers use the same common device tree
parsing code, so the allowed device tree nodes are almost the same
for all of them. Convert the qcom,apq8016-sbc-sndcard documentation
to a DT schema by adding it to the existing qcom,sm8250 schema.
The only speciality of qcom,apq8016-sbc-sndcard is that it has memory
resources for setting up an I/O mux. This can be handled using
a conditional if statement that only requires it for the apq8016-sbc
compatible.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211202145505.58852-4-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
The sm8250 audio driver uses the common Qualcomm device tree parser and
therefore already supports the "aux-devs" property that allows adding
additional auxiliary devices to the sound card (e.g. analog speaker
amplifiers that can be connected using "audio-routing").
Document the property in the DT schema for sm8250 as well. The description
is taken from simple-card.yaml which has a very similar property.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211202145505.58852-3-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
The MultiMedia audio routes can be deduced from other parts of the
device tree (e.g. the definitions of the MultiMedia DAIs) and therefore
specifying them again in "audio-routing" is redundant and prone to
mistakes. This is no longer necessary since commit 6fd8d2d275
("ASoC: qcom: qdsp6: Move frontend AIFs to q6asm-dai").
Let's drop them from the example in the DT schema as well
to avoid confusion.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211202145505.58852-2-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
The code inherited from the Skylake driver does not seem to follow any
known hardware recommendations.
The only two recommended options are
a) use DPIB registers if VC1 traffic is not allowed
b) use DPIB DDR update if VC1 traffic is used
In all of SOF-based updated, VC1 is not supported so we can 'safely'
move to using DPIB registers only.
This patch keeps the legacy code, in case there was an undocumented
issue lost to history, and adds the DPIB DDR update for additional
debug.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20211207193947.71080-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Smatch complains that we might hit the continue path on every iteration
through the loop.
sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c:831
mt8195_mt6359_rt1019_rt5682_card_late_probe()
error: uninitialized symbol 'sof_comp'.
Initialize "sof_comp" to NULL to silence this warning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211208151145.GA29257@kili
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Ariel D'Alessandro <ariel.dalessandro@collabora.com>:
This is a follow up of patchsets:
[RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
[PATCH 0/4] fsl-asoc-card: Add optional dt property for setting mclk-id
Patch "ASoC: fsl-asoc-card: Support fsl,imx-audio-tlv320aic31xx codec"
in "[RFC patch 0/5] Support BCLK input clock in tlv320aic31xx" missed a
Kconfig option. Sending incremental patch fix.
Regards,
Ariel
Ariel D'Alessandro (1):
ASoC: fsl-asoc-card: Add missing Kconfig option for tlv320aic31xx
sound/soc/fsl/Kconfig | 1 +
1 file changed, 1 insertion(+)
--
2.30.2
Merge series from Trevor Wu <trevor.wu@mediatek.com>:
This series of patches adds support for memory-region assignment, so the
access region of DMA engine could be restricted.
Patches are based on broonie tree "for-next" branch.
Trevor Wu (2):
ASoC: mediatek: mt8195: support reserved memory assignment
dt-bindings: mediatek: mt8195: add memory-region property
.../devicetree/bindings/sound/mt8195-afe-pcm.yaml | 8 ++++++++
sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 7 +++++++
2 files changed, 15 insertions(+)
--
2.18.0
Merge series from Trevor Wu <trevor.wu@mediatek.com>:
This series of patches adds support for RT5682s headset codec in mt8195
machine drivers, and SOF support on card mt8195-mt6359-rt1019-rt5682 is
also included.
Patches are based on broonie tree "for-next" branch.
Changes since v1:
- remove patch3 and patch4 in v1
- add SOF support on card mt8195-mt6359-rt1012-rt5682
- add new propertes to dt-bindings for mt8195-mt6359-rt1019-rt5682
Trevor Wu (4):
ASoC: mediatek: mt8195: add headset codec rt5682s support
dt-bindings: mediatek: mt8195: add model property
ASoC: mediatek: mt8195: add sof support on mt8195-mt6359-rt1019-rt5682
dt-bindings: mediatek: mt8195: add adsp and dai-link property
.../sound/mt8195-mt6359-rt1011-rt5682.yaml | 4 +
.../sound/mt8195-mt6359-rt1019-rt5682.yaml | 14 +
sound/soc/mediatek/Kconfig | 2 +
.../mt8195/mt8195-mt6359-rt1011-rt5682.c | 29 +-
.../mt8195/mt8195-mt6359-rt1019-rt5682.c | 347 +++++++++++++++++-
5 files changed, 370 insertions(+), 26 deletions(-)
--
2.18.0
In the patch, widgets, routes and dai-link requrird by SOF are included,
and late_probe is introduced for SOF route connection.
Only when adsp phandle could be retrieved from DTS, the SOF related part
of machine driver is executed.
Additionally, supported dai-links could be specified from DTS, so that
we can disable AP side hardware controls when DSP SOF controls the same
audio FE.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Signed-off-by: YC Hung <yc.hung@mediatek.com>
Link: https://lore.kernel.org/r/20211129141057.12422-4-trevor.wu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
