| Age | Commit message (Collapse) | Author |
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.4
A moderately large collection of fixes and quirks that have come in
during the merge window, everything here is driver specific and none of
it unusually severe.
|
|
After the codec has been removed, its runtime PM status is
RPM_SUSPENDED while hdac_hda_codec_probe() powers the codec up via
snd_hda_codec_device_new(). The pm_runtime_put()/snd_hda_power_down()
calls on probe and registration then see an already suspended device,
the codec suspend callback is not called and the codec, its HDA link and
the codec_powered bit stay set, preventing the controller from runtime
suspending.
The remove has a similar problem with the codec link accounting:
hdac_hda_codec_remove() drops the link reference taken in probe without
looking at the runtime PM state of the codec. If the codec was already
runtime suspended, the link reference has been dropped by the codec
suspend callback and the remove drops it a second time.
Resume the codec in hdac_hda_codec_remove() before disabling runtime PM
so that the link reference and the codec_powered bit are always in the
same state as after the probe, and mark the device active on probe once
the codec has been powered up.
Finally mark the codec device suspended at the end of the remove. Its
runtime PM is disabled at this point and if only the ASoC card is
unbound (e.g. by unbinding the machine driver), a following system
suspend would otherwise call the runtime suspend callback on the already
cleaned up codec via pm_runtime_force_suspend().
This is a followup patch to address Sashiko reports.
Link: https://lore.kernel.org/linux-sound/20261027083840.28813-4-peter.ujfalusi@linux.intel.com/
Fixes: c3ec8ac82105 ("ASoC: hdac_hda: fix memleak on module unload")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261027144655.31988-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Egor Poderiagin reported runtime resume failures caused by rejected
writes during regcache_sync().
Remove the PDE23 REQ_POWER_STATE default and the defaults for the
volatile MBQ registers 0x2000046 and 0x6100006. Also remove 0x2000046
from the MBQ readable and volatile register lists.
This allows cache sync to complete without suppressing sync errors.
Thanks to Egor Poderiagin for the detailed report and testing of the
default removals.
Closes:
https://lore.kernel.org/linux-sound/8a12a2d9-1b56-4e00-8ccc-cf31325f8366@crazyrussian.pro/
Fixes: 7a0886826308 ("ASoC: codecs: rt721-sdca-sdw: Propagate regcache_sync() errors")
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://patch.msgid.link/20261027-rt721fix-v1-1-42cd4b1711d2@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
hdac_hda_codec_remove() disables runtime PM of the codec device before
releasing the HDA link and calling the codec driver's remove callback,
so that no runtime resume can race with the teardown and access the
link or the already freed codec driver data.
snd_hda_codec_cleanup_for_unbind() then disables runtime PM again.
On the next probe snd_hda_codec_register() enables runtime PM only once,
leaving it disabled after the ASoC card or the codec driver has been
unbound and bound again: the codec stays powered and runtime_status
reads 'unsupported'.
Re-enable runtime PM at the end of hdac_hda_codec_remove() to balance
its own disable. The codec remains disabled until it is registered again.
Fixes: c3ec8ac82105 ("ASoC: hdac_hda: fix memleak on module unload")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261027083840.28813-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
hdac_hda_codec_probe() changes the type of the codec device to
HDA_DEV_ASOC to prevent snd_hda_codec_unregister() from unregistering
the device when the card is freed.
The type is never restored, and hda_bus_match() requires the device and
driver types to be equal. After unbinding the codec driver via sysfs the
HDA_DEV_LEGACY codec drivers no longer match the device and bind fails
with -ENODEV.
Restore HDA_DEV_LEGACY with a device managed action registered before
the component, so it runs after the component and the card are gone.
Fixes: b60ee2e281b6 ("ASoC: hdac_hda: overwrite hdev type to HDA_DEV_ASOC")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261027083840.28813-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The SOF HDA code allocates struct hdac_hda_priv and stores it as drvdata
of the codec device before the codec driver is bound. The driver core
clears drvdata on unbind, so after unbinding the codec driver via sysfs
a subsequent bind dereferences a NULL pointer in hdac_hda_dev_probe().
All information in the private data can be derived from the codec
device itself, so allocate and set it up in hdac_hda_dev_probe() as a
device managed resource, which is released on unbind.
Remove the allocation from SOF, keeping the check for iDisp codecs
without display audio component.
Fixes: 3fd63658caed ("ASoC: Intel: Drop hdac_ext usage for codec device creation")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261027083840.28813-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Zhang Yi <zhangyi@everest-semi.com> says:
Both the Kcontrols for the ES8326 and ES8375 have an issue where they write to other bits.
This patch will fix that issue.
Link: https://patch.msgid.link/20261026054837.13618-1-zhangyi@everest-semi.com
|
|
The Kcontrol related to DMIC_GAIN affects bits[3:2].
However, the old code sets ES8375_DMIC_GAIN_MAX to 4, which causes the Kcontrol to
affect bits [4:2],this is incorrect. Therefore, change ES8375_DMIC_GAIN_MAX to 3.
Fixes: de2b3119f9f7 ("ASoC: codecs: add support for ES8375")
Reviewed-by: HyeongJun An <sammiee5311@gmail.com>
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20261026054837.13618-3-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The register related to "ALC Capture Recovery Level" is ES8326_ALC_RECOVERY,
not ES8326_ALC_LEVEL.
Fixes: 5c439937775d ("ASoC: codecs: add support for ES8326")
Reviewed-by: HyeongJun An <sammiee5311@gmail.com>
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20261026054837.13618-2-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On Qualcomm RB5 both WSA8815 speaker amplifiers share a single powerdown
GPIO (TLMM 130), which is handled by the shared GPIO proxy. Since commit
b30973e8c392 ("gpio: shared: make the voting mechanism adaptable") the
proxy treats the value set by the first user on request as the default
and lets any single user vote for the opposite value.
The driver requests the GPIO de-asserted (GPIOD_OUT_LOW), so powering the
amplifier up became the default and asserting powerdown became the
winning vote. Once both amplifiers are runtime suspended, resuming them
deadlocks: the first one releases its powerdown vote and waits for
SoundWire enumeration, but the line stays asserted, because the second
amplifier is still suspended and votes for powerdown. The wait times out
and playback fails:
wsa881x-codec sdw:1:0:0217:2110:00:3: Initialization not complete
wsa881x-codec sdw:1:0:0217:2110:00:3: ASoC error (-110): at snd_soc_pcm_component_pm_runtime_get() on sdw:1:0:0217:2110:00:3
Request the GPIO asserted, so that powerdown is the default state and
the line is de-asserted as long as any amplifier needs to be powered,
then de-assert it to power up the amplifier as before.
Also use gpiod_set_value_cansleep() instead of gpiod_direction_output()
in the runtime PM callbacks. The line is already configured as an output
and the proxy resets its default value when the direction is set while
it has only a single user, which can happen if the other amplifiers have
not been probed yet.
Fixes: bfa336cee332 ("ASoC: wsa881x: Move custom workaround to gpiolib-of")
Fixes: b30973e8c392 ("gpio: shared: make the voting mechanism adaptable")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20261022090923.769464-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Zhang Yi <zhangyi@everest-semi.com> says:
To support different versions of the ES9356, the code reads the chip version
and performs different initialization configurations based on the version number.
To improve button performance, we've adjusted the timing and settings related to the headphones.
Link: https://patch.msgid.link/20261026064251.15017-1-zhangyi@everest-semi.com
|
|
Read the chip version number and modify the initialization configuration
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20261026064251.15017-4-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Set ES9356_VERSION and the HID-related registers to read-only.
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20261026064251.15017-3-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Change the time it takes to create a workqueue from 280 ms to 50 ms to
ensure faster response to button presses.
Modify the settings related to buttons after plugging in the headset
to ensure more accurate button type recognition.
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20261026064251.15017-2-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> says:
Fixes found while bringing up speaker protection on the Lenovo ThinkPad
T14s Gen 7 (Snapdragon X2 Elite) with WSA8845 speakers.
- AudioReach: the module cfg blob size was used as an element count,
so the allocation and copy were four times too large.
- WSA88xx: speaker temperatures above 45 degC were rejected, runtime
PM was left enabled on unbind (NULL dereference on wsa884x), and
the VI sense port carried only half of the V/I pair.
Tool use: an LLM coding assistant (Claude Code with Claude Opus) was
used for some of the patches in this series, to debug the issues during
bring-up and to draft the code and commit messages.
Link: https://patch.msgid.link/20261023171316.819857-1-srinivas.kandagatla@oss.qualcomm.com
|
|
The VI sense port carries both the voltage and the current sense data
of the speaker, but it is described with max_ch = 1 and, since commit
ed3b274abc40 ("ASoC: codecs: wsa883x: Correct VI sense channel mask"),
a channel mask of 0x1, so only half of the V/I pair is transferred.
Describe the port as two channels and set the channel mask back to 0x3.
Fixes: ed3b274abc40 ("ASoC: codecs: wsa883x: Correct VI sense channel mask")
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261023171316.819857-8-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The VI sense port carries both the voltage and the current sense data
of the speaker, but it is described with max_ch = 1 and, since commit
060fac202eb8 ("ASoC: codecs: wsa884x: Correct VI sense channel mask"),
a channel mask of 0x1, so only half of the V/I pair is transferred.
Describe the port as two channels and set the channel mask back to 0x3.
Fixes: 060fac202eb8 ("ASoC: codecs: wsa884x: Correct VI sense channel mask")
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261023171316.819857-7-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Probe enables runtime PM but nothing disables it on unbind, or when
registering the component fails. A pending autosuspend can then run
wsa883x_runtime_suspend() after the devm-managed regmap is freed, and
dereference NULL, as seen on wsa884x.
Use devm_pm_runtime_enable() so runtime PM is disabled before the regmap
is freed.
Fixes: 43b8c7dc85a1 ("ASoC: codecs: add wsa883x amplifier support")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261023171316.819857-6-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Probe enables runtime PM but nothing disables it on unbind. The pending
autosuspend then runs wsa884x_runtime_suspend() after the devm-managed
regmap is freed, and dereferences NULL:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
pc : regcache_cache_only+0x18/0x80
lr : wsa884x_runtime_suspend+0x24/0x40 [snd_soc_wsa884x]
Use devm_pm_runtime_enable() so runtime PM is disabled before the regmap
is freed.
Fixes: aa21a7d4f68a ("ASoC: codecs: wsa884x: Add WSA884x family of speakers")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261023171316.819857-5-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
wsa883x_get_temp() rejects any reading outside 5..45 degC with -EAGAIN,
so a speaker that has been playing, or sits in a warm chassis, becomes
unreadable above 45 degC.
Bound the check by the -10..150 degC two-point trim range instead, and
use inclusive comparisons, as in_range() excludes the upper bound.
Fixes: a02c42d41af7 ("ASoC: codecs: wsa883x: Implement temperature reading and hwmon")
Cc: stable@vger.kernel.org
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261023171316.819857-4-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
wsa884x_get_temp() rejects any reading outside 5..45 degC with -EAGAIN.
A speaker that has been playing, or sits in a warm laptop, easily runs
above 45 degC, so its temperature becomes unreadable when it matters.
The check only needs to drop bogus conversions, such as the all-zero
reading before the PA is first enabled. Bound it by the -10..150 degC
two-point trim range instead.
Fixes: 6b99dc62d940 ("ASoC: codecs: wsa884x: Implement temperature reading and hwmon")
Cc: stable@vger.kernel.org
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261023171316.819857-3-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Modify the Initialization Configuration and Clock Table
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20261022025309.24028-1-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
A zero rate requested through clk_set_rate() or clk_round_rate() reaches
clk_aic32x4_div_determine_rate() when the minimum rate is zero. Clamping
the requested rate to the allowed range leaves it unchanged, causing
division by zero when calculating the divisor.
A zero parent rate can also cause division by zero in determine_rate().
For example, if reading a parent divider's register fails,
clk_aic32x4_div_recalc_rate() returns zero, which the clock framework
caches as the parent's rate. A subsequent rate request for a child
divider receives this value in best_parent_rate. With a nonzero requested
rate, the calculated divisor is zero. It passes the existing upper-bound
check and causes division by zero in the resulting rate calculation.
The set_rate callback can receive a zero rate when an ancestor's rate
changes. clk_calc_subtree() calculates descendant rates through
recalc_rate() without calling their determine_rate callbacks. If reading
a descendant divider's register fails, clk_aic32x4_div_recalc_rate()
returns zero. This becomes the descendant's new_rate, which
clk_change_rate() passes to clk_aic32x4_div_set_rate(), causing division
by zero.
Reject zero rates in both callbacks and reject a zero divisor in
clk_aic32x4_div_determine_rate().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: a51b50062091 ("ASoC: tlv320aic32x4: Model DAC/ADC dividers in CCF")
Cc: stable@vger.kernel.org
Signed-off-by: Alex Kazinsky <a.kazinsky@ideco.ru>
Link: https://patch.msgid.link/20261023130854.93639-1-a.kazinsky@ideco.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Dell SKU 0EBA uses only the left audio channel and a single speaker.
Add the corresponding settings to support this configuration.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20261021090929.2135891-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The AIF clock source can be changed by configure_aif_clock() while the
AIF clock is running, for example the Midas machine driver switches
AIF1 between MCLK2 and FLL1 while AIF1CLK is kept enabled for jack
detection. aif_mclk_set() only enables the MCLK selected at the time
the AIF clock is turned on, so an MCLK selected later this way is never
enabled, and the codec may run from a stopped clock.
Track whether the AIF clock is running and, if so, enable the newly
selected MCLK in configure_aif_clock() before switching to it, then
release the previously enabled one.
Fixes: 001b83d395ab ("ASoC: wm8994: Add support for MCLKn clock gating")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20261022101531.775891-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
wm8994_set_dai_sysclk() passes the AIF index (dai->id - 1) to
wm8994_set_mclk_rate(), which uses it to index the MCLK clocks and
their cached rates. As a result, selecting MCLK2 as the AIF1 clock
source sets and reads back the rate of MCLK1 instead, and the rate
of MCLK1 is then stored as the MCLK2 rate.
On the Exynos4412 Trats2 board, where MCLK1 is a fixed 24MHz clock and
MCLK2 a 32768Hz clock used when the codec is idle, this gives:
wm8994-codec wm8994-codec: AIF1 using MCLK2 at 24000000Hz
so the driver assumes a 12MHz SYSCLK while it actually runs at 32kHz.
This skips the 128fs AIF clock ratio setup for low SYSCLK rates and
makes the mic detection rate configuration use the wrong clock rate.
Pass the MCLK index matching the selected clock source instead.
Fixes: 419e2f508336 ("ASoC: wm8994: Add support for setting MCLK clock rate")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Link: https://patch.msgid.link/20261021101750.3297770-4-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When SYSCLK drops below 50kHz, the AIFnCLK rate ratio is saved and
temporarily lowered to 128fs for accessory detection, then restored
once SYSCLK gets fast enough again. The ratio is however saved again
on each clock reconfiguration done while SYSCLK is still slow, which
overwrites the original ratio with the 128fs one.
This happens on the Exynos4412 Trats2 board, which set MCLK2 as SYSCLK
twice during the card probe and then configure FLL1 while still running
from MCLK2. Once SYSCLK is switched to FLL1, the 128fs ratio is
"restored", so AIF1 is left configured for 48kHz at 128fs while being
clocked at 256fs. If any digital path is powered up before a stream
reconfigures the AIF, the codec raises FIFO error interrupts every
10ms, flooding the kernel log:
wm8994-codec wm8994-codec: FIFO error
Save the original ratio only when entering the low SYSCLK mode. While
at it, move the code duplicated in _wm8994_set_fll() and
wm8994_set_dai_sysclk() to a common helper.
Fixes: 6730049a4763 ("ASoC: wm8994: Lower AIFnCLK divisor when dropping to 32kHz")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Link: https://patch.msgid.link/20261021101750.3297770-3-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
aif_mclk_set() masks the AIFnCLK_SRC field of the AIFn clocking
register, but compares the result with unshifted field values. The
MCLK2 source (0x08) therefore never matches, so MCLK2 is never enabled
for an AIF clocked from it, and the AIF relies on other users of that
clock to keep it running.
On the Exynos4412 Trats2 board, AIF1 and SYSCLK run from MCLK2, the
32768Hz PMIC clock, while the codec is idle. That clock is shared with
the WLAN and Bluetooth chips, which enable it only once their drivers
are loaded. Until then the codec runs from a stopped clock: FLL1 fails
to lock when configured from that state, and the codec floods the
kernel log with FIFO error interrupts once a digital path is powered
up:
wm8994-codec wm8994-codec: Timed out waiting for FLL lock
wm8994-codec wm8994-codec: FIFO error
Booting with clk_ignore_unused, which keeps that clock running from
the bootloader, makes both issues disappear.
Fixing just the comparison is not enough. The AIF clock source can
be changed while the AIF clock is running, for example the Midas
machine driver switches AIF1 between MCLK2 and FLL1 while AIF1CLK is
kept enabled for jack detection. Looking up the clock again on disable
can then release a different MCLK than the one enabled, leaking the
enable count of one clock and underflowing the other.
Shift the field value before decoding it, and remember which MCLK has
been enabled for each AIF, so that the same clock is released on
disable. While at it, report the MCLK number 1-based in the error
message.
Fixes: 001b83d395ab ("ASoC: wm8994: Add support for MCLKn clock gating")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Link: https://patch.msgid.link/20261021101750.3297770-2-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On CS35L5x firmware older than 3.13.7 (B0 silicon) and 4.7.16 (B2 silicon)
a SoundWire bus reset is not allowed within 250ms of the last firmware
timer start.
This is already avoided during runtime suspend by the various idle
timeouts. System suspend can happen at any time so needs special
protection. The driver cannot cancel the firmware timer, so it must wait
long enough for the timer to expire.
The delay is placed in the suspend stage because typically this has less
impact on end users than delays in resuming. The amp is in PS3 power
state when suspending and no new timers will be started in this state.
An extra 10ms is added to the delay to avoid a race on the exact instant
the firmware timer expires.
There is no need to have the delay for every driver instance. The timers
on each amp will expire in parallel, so the delay is only needed once.
A global flag is used so that the first instance to reach its suspend()
callback will delay and then clear the flag. The cs35l56_fw_idle_wait_lock
mutex is to ensure this is still safe if async_suspend was ever enabled
for SoundWire devices.
Fixes: e496112529006 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
Reported-by: Ferenc Lengyel <leferi99@gmail.com>
Closes: https://github.com/thesofproject/linux/issues/5898
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20261020135706.3573260-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ADC Mute Switch control writes bits 2 and 3 of the Misc ADC Control
register. These are the ADCA Invert and ADCB Invert bits, which have
their own controls. The ADC mute bits are bits 0 and 1, and the DAI mute
callback already sets them.
So the control has never muted the ADCs, and nobody can be relying on
it. Remove it rather than point it at the mute bits, so the ADCs are
muted in one place only.
Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC")
Suggested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/all/atXh3Br+fuH83S0q@opensource.cirrus.com/
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20261019124022.3410793-1-sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Pass the ACF firmware filename as an argument to
aw88399_request_firmware_file() instead of hardcoding AW88399_ACF_FILE.
Both existing callers (ASoC and HDA) pass AW88399_ACF_FILE to preserve
current behavior. Also add missing newlines to the log messages of the
modified lines.
This allows the HDA side codec driver to request per-model firmware files
in the next patch.
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/SN6PR19MB2303DB0BF41797A38EB04CBFFC992@SN6PR19MB2303.namprd19.prod.outlook.com
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v7.4
There's an awful lot of cleanup work in this pull request, lots from Bui
Duc Phuc, Pengpeng Hou, HyeongJun An and Chancel Liu cleaning up detail
issues in drivers in addition to Mormoto-san's ongoing framework work.
This time Morimoto-san's work included enabling auto_selectable_formats
so there's less manual configuration required for DAI links.
There's also been a huge amount of upstreaming activity from Qualcomm,
some pain there but hopefully enough has now landed for things to be
smoother in future.
- Use auto_selectable_formats in most drivers to reduce the amount of
manual configuration required for DAI links.
- Support for compressed audio on SOF IPC4 systems.
- Support for AMD ACP 7.B and 7.F, AmLogic A9 and T7, Airoha AN7581,
ESS Technology ES9039Q2M, Intel Cherry Trail with RT5688, Nuvoton
NAU83G60, nVidia systems with WM8994, Qualcomm QAIF, Senary I2S, WCD9378
and various platforms, Realtek RT766 and RT767, Senary SN624x
I also mistakenly merged some SPI changes in here then applied more
patches on top before I noticed (it looks like this was b4's base
selection logic picking a bad base for some ASoC work), highlights there
are:
- Improvements for spidev_test to cover additional use cases, plus be a
bit easier to use.
- Push more Tegra210 QSPI handling into interrupt context for
performance improvements.
- Support for Qualcomm QPIC SNAND v2 and RealTek RTD1625 NOR.
- Documentation clarifications.
- Fixes for some runtime PM and error handling issues.
- Support for R-Car Gen5.
(this should also be going in via my SPI pull request)
|
|
Pull 7.4 merge-window stuff.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
HyeongJun An <sammiee5311@gmail.com> says:
These are the last fixes found by the overlap scan from the first
series [1]. In sta32x and sta350 a 4-bit field has a maximum of 16, so
the control also writes the bit above it. In tlv320aic32x4 a TAS2505
control uses the wrong register.
[1] https://lore.kernel.org/all/20261008130953.2446692-1-sammiee5311@gmail.com/
Link: https://patch.msgid.link/cover.1792135145.git.sammiee5311@gmail.com
|
|
The TAS2505 HP volume is bits 6:0 of page 1 register 22, not of
register 16, which holds the HP driver mute (bit 6) and gain
(bits 5:0).
Fixes: 2169d6a0f072 ("ASoC: tlv320aic32x4: Fix TAS2505 volume controls")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/e50b88689e8efd353ee597a6692ab4db30aa63e7.1792135145.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The limiter attack and release thresholds are the two 4-bit halves of
one register, so their maximum is 15, not 16. With 16 the controls on
bits 3:0 also write bit 4, which belongs to the other threshold.
Fixes: 2439ea1f0f8f ("ASoC: sta350: Add codec driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/d65a21665a1e0d63dec174dd3691bd97764b8ae0.1792135145.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The limiter attack and release thresholds are the two 4-bit halves of
one register, so their maximum is 15, not 16. With 16 the controls on
bits 3:0 also write bit 4, which belongs to the other threshold.
Fixes: c034abf6e503 ("ASoC: add STA32X codec driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/179118fc7680b2b872d1f917b7fd21f54a73a6d8.1792135145.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> says:
This series adds audio support for the Qualcomm Nord Ride and
RRD boards and includes the required machine driver, device tree
binding updates, and codec improvements needed for the board's
external audio codec configuration.
Nord Ride uses a PCM1681 DAC for playback and an ADAU1979 ADC for capture.
Compared to other SC8280XP based platforms, Nord Ride requires
board-specific DAI format and codec clock configuration to support
the external PCM1681 DAC and ADAU1979 ADC.
Link: https://patch.msgid.link/20261009-nord-asoc-driver-support-v3-v3-0-0c1897f21ccf@oss.qualcomm.com
|
|
The driver assumes that the analog and digital supplies of the DAC are
already up by the time it probes. That only holds when the rails are
hardwired or left on by the bootloader. Boards which gate them, like
the Qualcomm Nord RRD and Ride, have no way to get them enabled, and
the first register access then fails.
Enable the VCC1, VCC2 and VDD supplies before touching the clock or the
regmap, so that the DAC is powered whenever the driver is bound. The
supplies are optional as far as the regulator core is concerned, so
boards which do not describe them keep working through the dummy
regulator.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Link: https://patch.msgid.link/20261009-nord-asoc-driver-support-v3-v3-5-0c1897f21ccf@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The PCM1681 selects the audio interface format using FMT[3:0] in the
format register. The driver currently supports only I2S, left-justified,
and right-justified formats, preventing a machine driver from selecting
TDM mode.
Add support for SND_SOC_DAIFMT_DSP_A and program the PCM1681 I2S TDM
format when it is selected. Also advertise DSP_A in the selectable DAI
formats.
While adding TDM support, correct the reset default for the format
register from 0x06 to 0x05. The current default does not match the
hardware reset value. Although this has no effect while regmap caching
is disabled, it could cause the TDM format write to be skipped if
regmap caching is enabled in the future.
The existing I2S, left-justified, and right-justified formats remain
unchanged.
Assisted-by: LLM
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Link: https://patch.msgid.link/20261009-nord-asoc-driver-support-v3-v3-3-0c1897f21ccf@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The PCM1681 requires its SCK system clock to be running before register
access. On platforms where SCK is provided by a gateable clock, register
access may fail when the clock is disabled.
Add support for an optional "sck" clock and enable it before accessing the
device. After enabling SCK, wait for the required 65536 system clock cycles
to allow the device to complete its internal reset sequence.
Use runtime PM to manage SCK instead of keeping it enabled for the lifetime
of the device. Disable the clock during runtime suspend and restore it on
runtime resume. Use autosuspend to avoid unnecessary clock toggling between
closely spaced accesses.
Since the device register state may be lost when SCK is disabled, enable
the regmap cache. Switch regmap to cache-only mode and mark the cache
dirty on runtime suspend, then synchronize the cached register state after
SCK is restored on runtime resume. Mark the zero-detect status register
volatile since it is updated by hardware.
Drop idle_bias_on so that the component can reach SND_SOC_BIAS_OFF and
runtime suspend can gate SCK.
Assisted-by: LLM
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Link: https://patch.msgid.link/20261009-nord-asoc-driver-support-v3-v3-2-0c1897f21ccf@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
HyeongJun An <sammiee5311@gmail.com> says:
These are more fixes found by the overlap scan from the first series
[1]. In each driver a control writes the register of another control.
[1] https://lore.kernel.org/all/20261008130953.2446692-1-sammiee5311@gmail.com/
Link: https://patch.msgid.link/cover.1792135144.git.sammiee5311@gmail.com
|
|
Each channel's master volume bypass (CxVBP) is in its own
configuration register, C2CFG and C3CFG, not in C1CFG, which holds the
channel 1 bit.
Fixes: 2439ea1f0f8f ("ASoC: sta350: Add codec driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/1107a42a563459b26038bdff4d8f6e2423816d0a.1792135144.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Each channel's master volume bypass (CxVBP) is in its own
configuration register, C2CFG and C3CFG, not in C1CFG, which holds the
channel 1 bit.
Fixes: c034abf6e503 ("ASoC: add STA32X codec driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/8576f091aa0fe172ce43f28dacd6a1bf638258c6.1792135144.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The right channel AGC target level is in RIGHT_CHN_AGC_1, as on the
left, not in RIGHT_CHN_AGC_2, which holds the right noise threshold
and hysteresis.
Fixes: e9a3b57efd28 ("ASoC: codec: tlv320adc3xxx: New codec driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/09cad9ec9bb382e44cad079a680bdf0f6163567e.1792135144.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ADC2 EQ overall volume is in DA732X_REG_ADC2_EQ5 (0x9F), not in
DA732X_REG_ADC1_EQ5 (0x97), which holds the ADC1 one.
Fixes: 48e278746070 ("ASoC: codecs: Add DA732x codec driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/35bae3f84cdc3ceb6ca412153f44dee3647fdbd6.1792135144.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
bui duc phuc <phucduc.bui@gmail.com> says:
Since v1 has already been applied, this series provides incremental
changes to address the remaining items from v2:
- Add comments explaining why .open() and .startup() must return 0
on success to prevent the issue from being reintroduced.
- Add Reviewed-by tags from Vijendar Mukunda and Chancel Liu,
and Acked-by tags from Morimoto-san and Cezary.
- Remove redundant integer constraints already applied
by snd_dmaengine_pcm_open().
Link v1:
https://lore.kernel.org/all/20261008103831.542533-1-phucduc.bui@gmail.com/
Link v2:
https://lore.kernel.org/all/20261015014324.5569-1-phucduc.bui@gmail.com/
Compile-tested only.
Link: https://patch.msgid.link/20261016040946.521195-1-phucduc.bui@gmail.com
|
|
Add comments explaining why the .startup() callbacks must return
0 on success to ensure the DAI is correctly marked as started
and prevent future changes from reintroducing the issue.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20261016040946.521195-5-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Smatch warns about inconsistent indenting in
rt721_sdca_jack_detect_handler(): the rt_sdca_index_read() call that
samples the JD pin state, and the following mask of real_JD, are
indented one level deeper than the surrounding statements, so they
look like part of the preceding block although they are not.
Re-indent them to match the rest of the block. No functional change.
Fixes: e2eb4873b901 ("ASoC: rt721-sdca: Adjust blindwrite flow to fix type detection issue")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202610080041.JAcitVQd-lkp@intel.com/
Signed-off-by: Jack Yu <jack.yu@realtek.com>
Link: https://patch.msgid.link/20261016082243.1352940-1-jack.yu@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
jack_detect_work can rearm btn_check_timer, and the timer callback can
queue jack_detect_work. Deleting the timer before cancelling the work
does not break this cycle: an already running worker can rearm the timer
after timer_delete_sync() returns. The timer can then outlive removal.
Use timer_shutdown_sync() before cancelling the delayed work so that
subsequent attempts to rearm the timer are ignored. The IRQ producer has
already been removed at this point. Keep the restartable timer deletion
in the suspend path.
This issue was identified as part of our ongoing research while
reviewing kernel code.
Fixes: 7ff6319e7da5 ("ASoC: rt5645: use polling to support HS button")
Assisted-by: LLM
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Link: https://patch.msgid.link/179203261324.2681924.5002100194676410503.rt5645-button-timer@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|