The CM9825 is a High Definition Audio Codec.
There are 2 independent stereo outputs, one of the stereo
outputs is cap-less with HP AMP, and the other is line out to
connect the active speaker. The inputs can be Line-in and MIC-in.
Signed-off-by: Leo Tsai <antivirus621@gmail.com>
Link: https://patch.msgid.link/20240910065542.6534-1-antivirus621@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The definition of struct snd_malloc_ops was moved out to
memalloc_local.h since there was another code for S/G buffer
allocation referring to the struct. But since the code change to use
non-contiguous allocators, it's solely referred in memalloc.c, hence
it makes little sense to have a separate header file.
Let's move it back to memalloc.c.
Link: https://patch.msgid.link/20240910113141.32618-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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-2323411911
Signed-off-by: Joshua Grisham <josh@joshuagrisham.com>
Link: https://patch.msgid.link/20240909193000.838815-1-josh@joshuagrisham.com
Signed-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.com
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
37137ec26c ("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 9c27301342
("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.de
Signed-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.com
Signed-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.de
Signed-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
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.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbaKqkACgkQJNaLcl1U
h9B6FAf/QlcNrFWx2m0SLhRqeeNRX3pwp7cjNLSo1TlIaBJy5NZJ1QjE7epl1/vx
4nzWi+3p1oql3h64RLIGUZ3dIUlFBoRBjmfF/aunxQ9VT7F8cqvLol+4sl+TcpTc
JWL5vuoCYcCsJDRwydUxcCyEClsC51PNn+WomqDP829yvgErob6VBXHhdRyZYd35
ffPBhAUOW0C+SOu7zGCAVqbtki2WMKc8gYweUhsuqEFQebOMkrO/sqJJsLbWje4D
LPGFfVDQaLQ+0h7pKR0m9Fwh17VTbsHGKEqt0qWK4GUfs61odsEs+C6BWfpM+S5k
comuzgnjtxgCV3K9URmYZx0435i+PQ==
=kMAy
-----END PGP SIGNATURE-----
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.org
Signed-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.com
Signed-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.com
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.net
Signed-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.net
Signed-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.com
Signed-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 cd7eb8f83f ("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.de
Signed-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: 378918d591 ("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.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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.org
Signed-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.com
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: dd657eae81 ("ASoC: sun4i-i2s: Fix the LRCK polarity")
Fixes: 73adf87b7a ("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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
MSI Bravo 17 (D7VEK), like other laptops from the family,
has broken ACPI tables and needs a quirk for internal mic
to work.
Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
Link: https://patch.msgid.link/20240829130313.338508-1-markuss.broks@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to get the correct keys when using the ES8326.We will associate
SND_JACK_BTN_1 to KEY_VOLUMEUP and SND_JACK_BTN_2 to KEY_VOLUMEDOWN
when the ES8326 flag is recognized.
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20240816114921.48913-1-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SOF topology loading function sets the device name for the platform
component link. This should be unset when unloading the topology,
otherwise a machine driver unbind/bind or reprobe would complain about
an invalid component as having both its component name and of_node set:
mt8186_mt6366 sound: ASoC: Both Component name/of_node are set for AFE_SOF_DL1
mt8186_mt6366 sound: error -EINVAL: Cannot register card
mt8186_mt6366 sound: probe with driver mt8186_mt6366 failed with error -22
This happens with machine drivers that set the of_node separately.
Clear the SOF link platform name in the topology unload callback.
Fixes: 311ce4fe76 ("ASoC: SOF: Add support for loading topologies")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240821041006.2618855-1-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The Sirius notebooks have two sets of speakers 0x17 (sides) and
0x1d (top center). The side speakers are active by default but
the top speakers aren't.
This patch provides a pincfg quirk to activate the top speakers.
Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20240827102540.9480-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As the last-standing user of PCM vmalloc buffer helper API took its
own buffer management, we can finally drop those API functions, which
were leftover after reorganization of ALSA memalloc code.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240807152725.18948-3-tiwai@suse.de
The dw-hdmi drm bridge driver is the only one who still uses the ALSA
vmalloc helper API functions. A previous attempt to change the way of
buffer management wasn't taken for this legacy stuff, as we had little
chance for test and some risk of major breaking.
Instead, this patch moves the vmalloc buffer stuff into the dw-hdmi
driver code itself, so that we can drop them from ALSA core code
afterwards.
There should be no functional changes.
Link: https://lore.kernel.org/20191210154536.29819-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240807152725.18948-2-tiwai@suse.de
Merge series from Liao Chen <liaochen4@huawei.com>:
This patchset aims to enable autoloading of some use modules.
By registering MDT, the kernel is allowed to automatically bind
modules to devices that match the specified compatible strings.
Normally, the type of enums is "unsigned int" or "int". GCC has
the "-fshort-enums" option, which instructs the compiler to
use the smallest data type that can hold all the values in
the enum (i.e: char, short, int or their unsigned variants).
According to the GCC documentation, "-fshort-enums" may be
default on some targets. This seems to be the case for SOF
when built for a certain 32-bit ARM platform.
On Linux, this is not the case (tested with "aarch64-linux-gnu-gcc")
which means enums such as "enum sof_comp_type" will end up having
different sizes on Linux and SOF. Since "enum sof_comp_type" is used in
IPC-related structures such as "struct sof_ipc_comp", this means
the fields of the structures will end up being placed at different
offsets. This, in turn, leads to SOF not being able to properly
interpret data passed from Linux.
With this in mind, replace "enum sof_comp_type" from
"struct sof_ipc_comp" with "uint32_t".
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://patch.msgid.link/20240826182442.6191-1-laurentiumihalcea111@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
