I have been wondering why DPCM needs special flag (= dpcm_playback/capture)
to use it. Below is the history why it was added to ASoC.
(A) In beginning, there was no dpcm_xxx flag on ASoC.
It checks channels_min for DPCM, same as current non-DPCM.
Let's name it as "validation check" here.
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
if (cpu_dai->driver->playback.channels_min)
playback = 1;
if (cpu_dai->driver->capture.channels_min)
capture = 1;
(B) commit 1e9de42f43 ("ASoC: dpcm: Explicitly set BE DAI link supported
stream directions") force to use dpcm_xxx flag on DPCM. According to
this commit log, this is because "Some BE dummy DAI doesn't set
channels_min for playback/capture". But we don't know which DAI is it,
and not know why it can't/don't have channels_min. Let's name it as
"no_chan_DAI" here. According to the code and git-log, it is used as
DCPM-BE and is CPU DAI. I think the correct solution was set
channels_min on "no_chan_DAI" side, not update ASoC framework side. But
everything is under smoke today.
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
playback = rtd->dai_link->dpcm_playback;
capture = rtd->dai_link->dpcm_capture;
(C) commit 9b5db05936 ("ASoC: soc-pcm: dpcm: Only allow playback/capture
if supported") checks channels_min (= validation check) again. Because
DPCM availability was handled by dpcm_xxx flag at that time, but some
Sound Card set it even though it wasn't available. Clearly there's
a contradiction here. I think correct solution was update Sound Card
side instead of ASoC framework. Sound Card side will be updated to
handle this issue later (commit 25612477d2 ("ASoC: soc-dai: set
dai_link dpcm_ flags with a helper"))
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
...
playback = rtd->dai_link->dpcm_playback &&
snd_soc_dai_stream_valid(cpu_dai, ...);
capture = rtd->dai_link->dpcm_capture &&
snd_soc_dai_stream_valid(cpu_dai, ...);
This (C) patch should have broken "no_chan_DAI" which doesn't have
channels_min, but there was no such report during this 4 years.
Possibilities case are as follows
- No one is using "no_chan_DAI"
- "no_chan_DAI" is no longer exist : was removed ?
- "no_chan_DAI" is no longer exist : has channels_min ?
Because of these history, this dpcm_xxx is unneeded flag today. But because
we have been used it for 10 years since (B), it may have been used
differently. For example some DAI available both playback/capture, but it
set dpcm_playback flag only, in this case dpcm_xxx flag is used as
availability limitation. We can use playback_only flag instead in this
case, but it is very difficult to find such DAI today.
Let's add grace time to remove dpcm_playback/capture flag.
This patch don't use dpcm_xxx flag anymore, and indicates warning to use
xxx_only flag if both playback/capture were available but using only
one of dpcm_xxx flag, and not using xxx_only flag.
Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/87seuyaahn.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert binding doc tpa6130a2.txt to yaml format.
Additional change:
- add ref to dai-common.yaml
- add i2c node in example
Fix below warning:
arch/arm64/boot/dts/freescale/imx8mq-zii-ultra-rmb3.dtb: /soc@0/bus@30800000/i2c@30a20000/amp@60:
failed to match any schema with compatible: ['ti,tpa6130a2']
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20240820184604.499017-1-Frank.Li@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver does not access reset GPIO in atomic contexts so it is usable
with GPIOs that may sleep during access. Switch to using
gpiod_set_value_cansleep().
Also the reset GPIO is configured as output at the time it is acquired,
there is no need to use gpiod_direction_output() when executing reset
sequence.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/ZsPty8oNMQk4YTl1@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>:
Intel new platforms can have up to 5 SoundWire links.
This series does not apply to SoundWire tree due to recent changes in
machine driver. Can we go via ASoC tree with Vinod's Acked-by tag?
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
A spiritual successor to haswell/baytrail removal series [1].
The avs-driver found in sound/soc/intel/avs is a direct replacement to
the existing skylake-driver. It covers all features supported by it and
more and aligns with the recommended flows and requirements based on
Windows driver equivalent.
The skylake-driver related UAPI has been removed with "ASoC: Drop
soc-topology ABI v4 support" [2].
For the official kernel tree the deprecation begun with v6.0. Most
skylake-drivers users moved to avs- or SOF-driver when AudioDSP
capabilities are available on the platform or to snd-hda-intel
(sound/pci/hda) when such capabilities are not.
For the supported trees the deprecation begun with v5.4 with v5.15 being
the first where the skylake-driver is disabled entirely.
All machine board drivers that consume this DSP driver have their
replacements present within sound/soc/intel/avs/boards/ directory.
[1]: https://lore.kernel.org/alsa-devel/20201006064907.16277-1-cezary.rojewski@intel.com/
[2]: https://lore.kernel.org/alsa-devel/20240403091629.647267-1-cezary.rojewski@intel.com/
The avs-driver found in sound/soc/intel/avs is a direct replacement to
the existing skylake-driver. It covers all features supported by it and
more and aligns with the recommended flows and requirements based on
Windows driver equivalent.
For the official kernel tree the deprecation begun with v6.0. Most
skylake-drivers users moved to avs- or SOF-driver when AudioDSP
capabilities are available on the platform or to snd-hda-intel
(sound/pci/hda) when such capabilities are not.
For the supported trees the deprecation begun with v5.4 with v5.15 being
the first where the skylake-driver is disabled entirely.
All machine board drivers that consume the DSP driver have their
replacements present within sound/soc/intel/avs/boards/ directory.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-14-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert binding doc tlv320aic31xx.txt to yaml format.
Additional change:
- add i2c node in example.
- replace MICBIAS_OFF with MICBIAS_2_0v in example because MICBIAS_OFF have
been defined in header file.
- add ref to dai-common.yaml.
- add #sound-dai-cells.
Fix below warning:
arch/arm64/boot/dts/freescale/imx8mq-zii-ultra-rmb3.dtb: /soc@0/bus@30800000/i2c@30a30000/codec@18:
failed to match any schema with compatible: ['ti,tlv320dac3100']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20240814174422.4026100-1-Frank.Li@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When ACP is not powered on by default, acp power on sequence explicitly
invoked by programming pgfsm control mask. The existing implementation
checks the same PGFSM status mask and programs the same PGFSM control mask
in all ACP variants which breaks acp power on sequence for ACP6.0 and
ACP6.3 variants. So to fix this issue, update ACP pgfsm control mask and
status mask based on acp descriptor rev field, which will vary based on
acp variant.
Fixes: 846aef1d7c ("ASoC: SOF: amd: Add Renoir ACP HW support")
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/20240816070328.610360-1-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add AFE Control Register 0 to the volatile_register.
AFE_DAC_CON0 can be modified by both the SOF and ALSA drivers.
If this register is read and written in cache mode, the cached value
might not reflect the actual value when the register is modified by
another driver. It can cause playback or capture failures. Therefore,
it is necessary to add AFE_DAC_CON0 to the list of volatile registers.
Signed-off-by: YR Yang <yr.yang@mediatek.com>
Reviewed-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Trevor Wu <trevor.wu@mediatek.com>
Link: https://patch.msgid.link/20240801084326.1472-1-yr.yang@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace SET_RUNTIME_PM_OPS()/SET SYSTEM_SLEEP_PM_OPS() with their modern
RUNTIME_PM_OPS() and SYSTEM_SLEEP_PM_OPS() alternatives.
The combined usage of pm_ptr() and RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the CONFIG_PM ifdefery from the runtime
suspend/resume() functions.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://patch.msgid.link/20240808184944.267686-7-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace SET_SYSTEM_SLEEP_PM_OPS() with its modern SYSTEM_SLEEP_PM_OPS()
alternative.
The combined usage of pm_sleep_ptr() and SYSTEM_SLEEP_PM_OPS() allows
the compiler to evaluate if the suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the CONFIG_PM_SLEEP ifdefery from the
suspend/resume() functions.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://patch.msgid.link/20240808184944.267686-6-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace SET_SYSTEM_SLEEP_PM_OPS() with its modern SYSTEM_SLEEP_PM_OPS()
alternative.
The combined usage of pm_sleep_ptr() and SYSTEM_SLEEP_PM_OPS() allows
the compiler to evaluate if the suspend/resume() functions are used at
build time or are simply dead code.
This allows removing the CONFIG_PM_SLEEP ifdefery from the
suspend/resume() functions.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://patch.msgid.link/20240808184944.267686-5-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace SET_RUNTIME_PM_OPS()/SET SYSTEM_SLEEP_PM_OPS() with their modern
RUNTIME_PM_OPS() and SYSTEM_SLEEP_PM_OPS() alternatives.
The combined usage of pm_ptr() and RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the CONFIG_PM ifdefery from the runtime
suspend/resume() functions.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://patch.msgid.link/20240808184944.267686-4-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace SET_RUNTIME_PM_OPS() with its modern RUNTIME_PM_OPS()
alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS() allows the
compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the CONFIG_PM ifdefery from the runtime
suspend/resume() functions.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://patch.msgid.link/20240808184944.267686-3-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace SET_RUNTIME_PM_OPS()/SET SYSTEM_SLEEP_PM_OPS() with their modern
RUNTIME_PM_OPS() and SYSTEM_SLEEP_PM_OPS() alternatives.
The combined usage of pm_ptr() and RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the CONFIG_PM ifdefery from the runtime
suspend/resume() functions.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://patch.msgid.link/20240808184944.267686-2-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
