There's no need to make this variable visible at a higher level.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20240827123215.258859-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Let the kmemdup_array() take care about multiplication
and possible overflows.
Using kmemdup_array() is more appropriate and makes the code
easier to audit.
Signed-off-by: Shen Lichuan <shenlichuan@vivo.com>
Link: https://patch.msgid.link/20240826054402.58396-1-shenlichuan@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add SOF support for ACP7.0 version based platform.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://patch.msgid.link/20240823053739.465187-3-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add acpi machine id for ACP7.0 version based platform and configure
driver data to enable SOF sound card support on newer boards.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://patch.msgid.link/20240823053739.465187-2-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it
turns out that the 2G version has a DMI product name of
"CHERRYVIEW D1 PLATFORM" where as the 4G version has
"CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are
unique enough that the product-name check is not necessary.
Drop the product-name check so that the existing DMI match for the 4G
RAM version also matches the 2G RAM version.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://patch.msgid.link/20240823074305.16873-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 13f58267cd ("ASoC: soc.h: don't create dummy Component
via COMP_DUMMY()") dummy codecs declared like this:
SND_SOC_DAILINK_DEF(dummy,
DAILINK_COMP_ARRAY(COMP_DUMMY()));
expand to:
static struct snd_soc_dai_link_component dummy[] = {
};
Which means that dummy is a zero sized array and thus dais[i].codecs should
not be dereferenced *at all* since it points to the address of the next
variable stored in the data section as the "dummy" variable has an address
but no size, so even dereferencing dais[0] is already an out of bounds
array reference.
Which means that the if (dais[i].codecs->name) check added in
commit 7d99a70b65 ("ASoC: Intel: Boards: Fix NULL pointer deref
in BYT/CHT boards") relies on that the part of the next variable which
the name member maps to just happens to be NULL.
Which apparently so far it usually is, except when it isn't
and then it results in crashes like this one:
[ 28.795659] BUG: unable to handle page fault for address: 0000000000030011
...
[ 28.795780] Call Trace:
[ 28.795787] <TASK>
...
[ 28.795862] ? strcmp+0x18/0x40
[ 28.795872] 0xffffffffc150c605
[ 28.795887] platform_probe+0x40/0xa0
...
[ 28.795979] ? __pfx_init_module+0x10/0x10 [snd_soc_sst_bytcr_wm5102]
Really fix things this time around by checking dais.num_codecs != 0.
Fixes: 7d99a70b65 ("ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://patch.msgid.link/20240823074217.14653-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the timestamp of a calibration entry is 0 it is an unused entry and
must be ignored.
Some end-products reserve EFI space for calibration entries by shipping
with a zero-filled EFI file. When searching the file for calibration
data the driver must skip the empty entries. The timestamp of a valid
entry is always non-zero.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 1cad8725f2 ("ASoC: cs-amp-lib: Add helpers for factory calibration data")
Link: https://patch.msgid.link/20240822133544.304421-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For a normal calibration blob the calTarget values must be non-zero and
unique, and the calTime values must be non-zero. Don't rely on
get_random_bytes() to be random enough to guarantee this. Force the
calTarget and calTime values to be valid while retaining randomness
in the values.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 177862317a ("ASoC: cs-amp-lib: Add KUnit test for calibration helpers")
Link: https://patch.msgid.link/20240822115725.259568-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for removal of dpcm_playback and dpcm_capture flags in
dailinks.
[Kuninori adjusted Pierre-Louis's patch]
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87o75maah5.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dpcm_xxx flags are no longer needed.
We need to use xxx_only flags instead if needed, but
snd_soc_dai_link_set_capabilities() user adds dpcm_xxx if playback/capture
were available. Thus converting dpcm_xxx to xxx_only is not needed.
Just remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/87r0aiaahh.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Add MODULE_DEVICE_TABLE(), so modules could be properly
autoloaded based on the alias from platform_device_id table.
Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
Link: https://patch.msgid.link/20240821061955.2273782-3-lihongbo22@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add MODULE_DEVICE_TABLE(), so modules could be properly
autoloaded based on the alias from platform_device_id table.
Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
Link: https://patch.msgid.link/20240821061955.2273782-2-lihongbo22@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc-pcm.c has snd_soc_dpcm_stream_lock_irqsave_nested() /
snd_soc_dpcm_stream_unlock_irqrestore() helper function,
but it is almost nothing help. It just makes a code complex.
Let's remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87msl6aa2c.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove unnecessary line feed for tasdevice_codec_remove.
Add comma at the end the last member of the array.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
Link: https://patch.msgid.link/20240821072527.1294-1-baojun.xu@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't populate the read-only array minCode_param on the stack at
run time, instead make it static const.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://patch.msgid.link/20240821114927.520193-1-colin.i.king@gmail.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 skylake-driver is deprecated in favour of the avs-driver. As the
latter supports all configurations of its predecessor and more, update
the existing selection mechanism to acknowledge the SST flag.
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-15-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
The driver has no users.
Succeeded by:
- avs_nau8825 (./intel/avs/boards/nau8825.c)
- avs_max98357a (./intel/avs/boards/max98357a.c)
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-13-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_nau8825 (./intel/avs/boards/nau8825.c)
- avs_ssm4567 (./intel/avs/boards/ssm4567.c)
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-12-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt286 (./intel/avs/boards/rt286.c)
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-11-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_da7219 (./intel/avs/boards/da7219.c)
- avs_max98357a (./intel/avs/boards/max98357a.c)
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-10-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_da7219 (./intel/avs/boards/da7219.c)
- avs_max98927 (./intel/avs/boards/max98927.c)
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-9-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt5660 (./intel/avs/boards/rt5660.c)
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-8-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt5663 (./intel/avs/boards/rt5663.c)
- avs_max98927 (./intel/avs/boards/max98927.c)
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-7-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt5514 (./intel/avs/boards/rt5514.c)
- avs_rt5663 (./intel/avs/boards/rt5663.c)
- avs_max98927 (./intel/avs/boards/max98927.c)
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-6-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_da7219 (./intel/avs/boards/da7219.c)
- avs_max98357a (./intel/avs/boards/max98357a.c)
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-5-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt298 (./intel/avs/boards/rt298.c)
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-4-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Preparation step in the skylake-driver removal process.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-3-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The definitions are currently duplicated in intel-sdw-acpi.c and
sof_sdw.c. Move the definition to the sdw_intel.h header, and change
the prefix to make it Intel-specific.
No functionality change in this patch.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240819005548.5867-2-yung-chuan.liao@linux.intel.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>
Remove unnecessary line feed for tasdevice_dsp_create_ctrls,
and remove two unnecessary spaces in tas2563_digital_gain_get
and tas2563_digital_gain_put.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://patch.msgid.link/20240815042138.1997-1-shenghao-ding@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
based on the alias from platform_device_id table.
Fixes: 9d8a7be88b ("ASoC: amd: acp: Add legacy sound card support for Chrome audio")
Signed-off-by: Yuntao Liu <liuyuntao12@huawei.com>
Link: https://patch.msgid.link/20240815084923.756476-1-liuyuntao12@huawei.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>
soc-pcm.c has snd_soc_dpcm_stream_{lock/unlock}_irq() helper function,
but it is almost nothing help. It just makes a code complex.
Let's remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/875xsnll85.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
