I have done a lot of analysis for these type of devices and collaborated
quite a bit with Nick Weihs (author of the first patch submitted for this
including adding samsung_helper.c). More information can be found in the
issue on Github [1] including additional rationale and testing.

The existing implementation includes a large number of equalizer coef
values that are not necessary to actually init and enable the speaker
amps, as well as create a somewhat worse sound profile. Users have
reported "muffled" or "muddy" sound; more information about this including
my analysis of the differences can be found in the linked Github issue.

This patch refactors the "v2" version of ALC298_FIXUP_SAMSUNG_AMP to a much
simpler implementation which removes the new samsung_helper.c, reuses more
of the existing patch_realtek.c, and sends significantly fewer unnecessary
coef values (including removing all of these EQ-specific coef values).

A pcm_playback_hook is used to dynamically enable and disable the speaker
amps only when there will be audio playback; this is to match the behavior
of how the driver for these devices is working in Windows, and is
suspected but not yet tested or confirmed to help with power consumption.

Support for models with 2 speaker amps vs 4 speaker amps is controlled by
a specific quirk name for both types. A new int num_speaker_amps has been
added to alc_spec so that the hooks can know how many speaker amps to
enable or disable. This design was chosen to limit the number of places
that subsystem ids will need to be maintained: like this, they can be
maintained only once in the quirk table and there will not be another
separate list of subsystem ids to maintain elsewhere in the code.

Also updated the quirk name from ALC298_FIXUP_SAMSUNG_AMP2 to
ALC298_FIXUP_SAMSUNG_AMP_V2_.. as this is not a quirk for "Amp #2" on
ALC298 but is instead a different version of how to handle it.

More devices have been added (see Github issue for testing confirmation),
as well as a small cleanup to existing names.

[1]: https://github.com/thesofproject/linux/issues/4055#issuecomment-2323411911Signed-off-by: Joshua Grisham <josh@joshuagrisham.com>
Link: https://patch.msgid.link/20240909193000.838815-1-josh@joshuagrisham.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Vaio VJFH52 is equipped with ACL256, and needs a
fix to make the internal mic and headphone mic to work.
Also must to limits the internal microphone boost.
Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Link: https://patch.msgid.link/20240909162751.4790-1-edson.drosdeck@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Signed-off-by: Takashi Iwai <tiwai@suse.de>

The azx_bus->dma_type is referred only for allocating the
communication buffers like CORB/RIRB, and the allocation size is
small.  Hence it doesn't have to be S/G buffer allocation, which is an
obvious overkill.  Use the standard SNDRV_DMA_TYPE_DEV_WC instead.

This was changed to SNDRV_DMA_TYPE_DEV_WC_SG in the commit
37137ec2 ("ALSA: hda: Once again fix regression of page
allocations with IOMMU") as a workaround for IOMMU-backed
allocations.  But this is no longer needed since the allocation with
SNDRV_DMA_TYPE_DEV_WC itself was fixed in the commit 9c273013
("ALSA: memalloc: Use DMA API for x86 WC page allocations, too").

So this patch reverts the previous workaround in this piece of code.

Link: https://patch.msgid.link/20240909134744.25426-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Parameter xindex is not used in macro HDSPM_TCO_LTC_FRAMES and
HDSPM_TCO_VIDEO_INPUT_FORMAT,so just remove it to simplify the code.
Signed-off-by: He Lugang <helugang@uniontech.com>
Link: https://patch.msgid.link/F53E9F10DA24705D+20240907142854.17627-1-helugang@uniontech.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Add 128kHz, 352.4kHz, 384kHz and 705.6kHz.
These definitions have been found working on eARC using a Murideo
Seven Generator.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20240906093422.2976550-1-jbrunet@baylibre.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Since there are a few corner cases where the S/G buffer allocation
isn't performed (e.g. depending on IOMMU implementations), it'd be
better to allow the default buffer preallocation size for x86, too.

The default for x86 is still kept to 0, as it should work in most
cases.

Link: https://patch.msgid.link/20240907084129.28802-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

IEC958-3 defines sampling rate up to 768 kHz.
Such rates maybe used with high bandwidth IEC958 links, such as eARC.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-13-8371948d3921@baylibre.com

The cs35l34 adds a useless rate constraint on startup.
It does not set SNDRV_PCM_RATE_KNOT and the rates set are already a subset
of the ones provided in the constraint list, so it is a no-op.

>From the rest of the code, it is likely HW supports more than the 32, 44.1
and 48kHz listed in CS35L34_RATES but there is no way to know for sure
without proper documentation.

Keep the driver as it is for now and just drop the useless constraint.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-12-8371948d3921@baylibre.com

The custom rate constraint lists was necessary to support 12kHz and 24kHz.
These rates are now available through SNDRV_PCM_RATE_12000 and
SNDRV_PCM_RATE_24000.

Use them and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-11-8371948d3921@baylibre.com

The custom rate constraint list was necessary to support 12kHz and 24kHz.
These rates are now available through SNDRV_PCM_RATE_12000 and
SNDRV_PCM_RATE_24000.

Use them and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-10-8371948d3921@baylibre.com

The custom rate constraint list was necessary to support 12kHz, 24kHz and
128kHz. These rates are now available through SNDRV_PCM_RATE_12000,
SNDRV_PCM_RATE_24000 and SNDRV_PCM_RATE_128000.

Use them and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-9-8371948d3921@baylibre.com

The custom rate constraint list was necessary to support 12kHz and 24kHz.
These rates are now available through SNDRV_PCM_RATE_12000 and
SNDRV_PCM_RATE_24000.

Use them and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-8-8371948d3921@baylibre.com

The custom rate constraint list was necessary to support 12kHz and 24kHz.
These rates are now available through SNDRV_PCM_RATE_12000 and
SNDRV_PCM_RATE_24000.

Use them and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-7-8371948d3921@baylibre.com

The custom rate constraint list was necessary to support 12kHz and 24kHz.
These rates are now available through SNDRV_PCM_RATE_12000 and
SNDRV_PCM_RATE_24000.

Use them and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-6-8371948d3921@baylibre.com

The custom rate constraint list was necessary to support 128kHz.
This rate is now available through SNDRV_PCM_RATE_128000.

Use it and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-5-8371948d3921@baylibre.com

The custom rate constraint list was necessary to support 128kHz.
This rate is now available through SNDRV_PCM_RATE_128000.

Use it and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-4-8371948d3921@baylibre.com

The custom rate constraint lists were necessary to support 12kHz and 24kHz.
These rates are now available through SNDRV_PCM_RATE_12000 and
SNDRV_PCM_RATE_24000.

Use them and drop the custom rate constraint rules.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-3-8371948d3921@baylibre.com

The custom rate constraint list was necessary to support 128kHz.
This rate is now available through SNDRV_PCM_RATE_128000.

Use it and drop the custom rate constraint rule.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-2-8371948d3921@baylibre.com

This adds a sample rate definition for 12kHz, 24kHz and 128kHz.

Admittedly, just a few drivers are currently using these sample
rates but there is enough of a recurrence to justify adding a definition
for them and remove some custom rate constraint code while at it.

The new definitions are not added to the interval definitions, such as
SNDRV_PCM_RATE_8000_44100, because it would silently add new supported
rates to drivers that may or may not support them. For sure the drivers
have not been tested for these new rates so it is better to leave them out
of interval definitions.

That being said, the added rates are multiples of well know rates families,
it is very likely that a lot of devices out there actually supports them.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-1-8371948d3921@baylibre.com

Merge tag 'asoc-fix-v6.11-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v6.11

A larger set of fixes than I'd like at this point, but mainly due to
people working on fixing module autoloading by adding missing exports of
ID tables rather than anything particularly concerning.  There are some
other runtime fixes and quirks, and a tweak to the ABI definition for
SOF which ensures that a struct layout doesn't vary depending on the
architecture of the host.

When the headset is connected, there is no automatic switching of the
capture source - you can only manually select the headset microphone
in pavucontrol.

This patch fixes/activates the inactive microphone of the headset.
Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240905140211.937385-1-kovalev@altlinux.orgSigned-off-by: Takashi Iwai <tiwai@suse.de>

The mute LED on this HP laptop uses ALC236 and requires a quirk to function. This patch enables the existing quirk for the device.
Signed-off-by: Maximilien Perreault <maximilienperreault@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240904031013.21220-1-maximilienperreault@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

The mute led is controlled by ALC245. This patch enables the already
existing quirk for this device.
Signed-off-by: Adam Queler <queler+k@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240903202419.31433-1-queler+k@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Pull 6.11 devel branch.  The conflicts in HD-audio Realtek codec driver
got resolved.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Implement sync, output format, and input status mixer controls, to allow
the interface to be used as a straight ADAT/SPDIF (+ Headphones) I/O
interface.

This does not implement the matrix mixer, output gain controls, or input
level meter feedback. The full mixer interface is only really usable
using a dedicated userspace control app (there are too many mixer nodes
for alsamixer to be usable), so for now we leave it up to userspace to
directly control these features using raw USB control messages. This is
similar to how it's done with some FireWire interfaces (ffado-mixer).
Signed-off-by: Asahi Lina <lina@asahilina.net>
Link: https://patch.msgid.link/20240903-rme-digiface-v2-2-71b06c912e97@asahilina.netSigned-off-by: Takashi Iwai <tiwai@suse.de>

Add trivial support for audio streaming on the RME Digiface USB. Binds
only to the first interface to allow userspace to directly drive the
complex I/O and matrix mixer controls.
Signed-off-by: Cyan Nyan <cyan.vtb@gmail.com>
[Lina: Added 2x/4x sample rate support & boot/format quirks]
Co-developed-by: Asahi Lina <lina@asahilina.net>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Link: https://patch.msgid.link/20240903-rme-digiface-v2-1-71b06c912e97@asahilina.netSigned-off-by: Takashi Iwai <tiwai@suse.de>

The mic in those laptops suffers too high gain resulting in mostly (fan
or else) noise being recorded. In addition to the existing fixup about
mic detection, apply also limiting its boost. While at it, extend the
quirk to also V5[46]0TNE models, which have the same issue.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240903124939.6213-1-marmarek@invisiblethingslab.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

We used to wrap with no_free_ptr() for the return value from
memdup_user() with errors where the auto cleanup is applied.  This was
a workaround because the initial implementation of kfree auto-cleanup
checked only NULL pointers.

Since recently, though, the kfree auto-cleanup checks with
IS_ERR_OR_NULL() (by the commit cd7eb8f8 ("mm/slab: make
__free(kfree) accept error pointers")), hence those workarounds became
superfluous.  Let's drop them now.

Link: https://patch.msgid.link/20240902075246.3743-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

1000000000L is number of ns per second, use NSEC_PER_SEC macro to replace
it to make it more readable
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://patch.msgid.link/20240902071622.3519787-1-ruanjinjie@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

The previous fix brought yet another compile warning at pr_debug()
call with the changed size.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/20240902132904.5ee173f3@canb.auug.org.au
Fixes: 43b42ed4 ("ALSA: pcm: Fix the previous conversion to kstrtoul()")
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://patch.msgid.link/20240902062217.9777-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

There is a extraneous space after a newline in a dev_dbg message.
Remove it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://patch.msgid.link/20240901162125.144069-1-colin.i.king@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

The previous replacement from simple_strtoul() to kstrtoul() forgot
that the passed pointer must be an unsigned long int pointer, while
the value used there is a sized_t pointer.  Fix it.

Fixes: 61bc4def ("ALSA: pcm: replace simple_strtoul to kstrtoul")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202409010425.YPS7cWeJ-lkp@intel.com/
Link: https://patch.msgid.link/20240901134524.27107-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

As mentioned in [1], "...simple_strtol(), simple_strtoll(),
simple_strtoul(), and simple_strtoull() functions explicitly
ignore overflows, which may lead to unexpected results in callers."
Hence, the use of those functions is discouraged.

This patch replace the use of the simple_strtoul with the safer
alternatives kstrtoul.

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoullSigned-off-by: Hongbo Li <lihongbo22@huawei.com>
Link: https://patch.msgid.link/20240831080639.3985143-1-lihongbo22@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

sm8250 and sc7280 have lpass codec version 1.0, as these are very old
platforms, they do not have a reliable way to get the codec version
from core_id registers.

On codec versions below 2.0, even though the core_id registers are
available to read, the values of these registers are not unique to be
able to determine the version of the codec dynamically.

Add the version info into of_data, so that driver does not need to use
core_id registers to get version number for such situations.

Fixes: 378918d5 ("ASoC: codecs: lpass-macro: add helpers to get codec version")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Amit Pundir <amit.pundir@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://patch.msgid.link/20240816091210.50172-1-srinivas.kandagatla@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Add HDMI codec ID for Intel Panther Lake platform.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20240830072458.110831-1-yung-chuan.liao@linux.intel.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Lenovo V145 is having phase inverted dmic but simply applying inverted
dmic fixups does not work. Chaining up verb fixes for ALC283 enables
inverting dmic fixup to work properly.
Signed-off-by: Terry Cheong <htcheong@chromium.org>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240830-lenovo-v145-fixes-v3-1-f7b7265068fa@chromium.orgSigned-off-by: Takashi Iwai <tiwai@suse.de>

We do not need model specific HDA quirks to construct the component
binding details of Cirrus Logic companion amplifiers as this information
is already present in the ACPI.

Quirks are then only required for special workarounds not described in
the ACPI such as internal configuration of the Realtek codecs.

The codec pointer is now initialized in hda_component_manager_init() so
that we can detect when companion amplifiers are found in the ACPI but
the SSID invokes a quirk that also attempts to create the component
binding.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Link: https://patch.msgid.link/20240829161114.140938-1-simont@opensource.cirrus.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Pull 6.11 devel branch for applying further updates for Cirrus codecs
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This fixes the LRCLK polarity for sun8i-h3 and sun50i-h6 in i2s mode
which was wrongly inverted.

The LRCLK was being set in reversed logic compared to the DAI format:
inverted LRCLK for SND_SOC_DAIFMT_IB_NF and SND_SOC_DAIFMT_NB_NF; normal
LRCLK for SND_SOC_DAIFMT_IB_IF and SND_SOC_DAIFMT_NB_IF. Such reversed
logic applies properly for DSP_A, DSP_B, LEFT_J and RIGHT_J modes but
not for I2S mode, for which the LRCLK signal results reversed to what
expected on the bus. The issue is due to a misinterpretation of the
LRCLK polarity bit of the H3 and H6 i2s controllers. Such bit in this
case does not mean "0 => normal" or "1 => inverted" according to the
expected bus operation, but it means "0 => frame starts on low edge" and
"1 => frame starts on high edge" (from the User Manuals).

This commit fixes the LRCLK polarity by setting the LRCLK polarity bit
according to the selected bus mode and renames the LRCLK polarity bit
definition to avoid further confusion.

Fixes: dd657eae ("ASoC: sun4i-i2s: Fix the LRCK polarity")
Fixes: 73adf87b ("ASoC: sun4i-i2s: Add support for H6 I2S")
Signed-off-by: Matteo Martelli <matteomartelli3@gmail.com>
Link: https://patch.msgid.link/20240801-asoc-fix-sun4i-i2s-v2-1-a8e4e9daa363@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>