Skip to content

L
linux
Switch branch/tag
  1. 08 May, 2024 11 commits
  3. 02 May, 2024 1 commit
  5. 01 May, 2024 1 commit
    • Takashi Iwai's avatar
      Merge tag 'asoc-fix-v6.9-rc6' of... · a30a7a29
      Takashi Iwai authored 
      Merge tag 'asoc-fix-v6.9-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v6.9

This is much larger than is ideal, partly due to your holiday but also
due to several vendors having come in with relatively large fixes at
similar times.  It's all driver specific stuff.

The meson fixes from Jerome fix some rare timing issues with blocking
operations happening in triggers, plus the continuous clock support
which fixes clocking for some platforms.  The SOF series from Peter
builds to the fix to avoid spurious resets of ChainDMA which triggered
errors in cleanup paths with both PulseAudio and PipeWire, and there's
also some simple new debugfs files from Pierre which make support a lot
eaiser.
      a30a7a29
  7. 30 Apr, 2024 3 commits
    • Takashi Iwai's avatar
      ALSA: hda/realtek: Fix conflicting PCI SSID 17aa:386f for Lenovo Legion models · 39815cdf
      Takashi Iwai authored 
      Unfortunately both Lenovo Legion Pro 7 16ARX8H and Legion 7i 16IAX7
got the very same PCI SSID while the hardware implementations are
completely different (the former is with TI TAS2781 codec while the
latter is with Cirrus CS35L41 codec).  The former model got broken by
the recent fix for the latter model.

For addressing the regression, check the codec SSID and apply the
proper quirk for each model now.

Fixes: 24b6332c ("ALSA: hda: Add Lenovo Legion 7i gen7 sound quirk")
Cc: <stable@vger.kernel.org>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1223462
Message-ID: <20240430163206.5200-1-tiwai@suse.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      39815cdf
    • Kailang Yang's avatar
      ALSA: hda/realtek - Set GPIO3 to default at S4 state for Thinkpad with ALC1318 · 1e707769
      Kailang Yang authored 
      There is a chance of damaging the IC when S4 resume.
Add safe mode for no stream to disable GPIO3.
Thinkpad with ALC1318 platform need to add this workaround.
Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
Link: https://lore.kernel.org/r/a853dc4f0a4e412381d5f60565181247@realtek.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1e707769
    • Mark Brown's avatar
      ASoC: meson: tdm fixes · c5782bb5
      Mark Brown authored 
      Merge series from Jerome Brunet <jbrunet@baylibre.com>:

This patchset fixes 2 problems on TDM which both find a solution
by properly implementing the .trigger() callback for the TDM backend.

ATM, enabling the TDM formatters is done by the .prepare() callback
because handling the formatter is slow due to necessary calls to CCF.

The first problem affects the TDMIN. Because .prepare() is called on DPCM
backend first, the formatter are started before the FIFOs and this may
cause a random channel shifts if the TDMIN use multiple lanes with more
than 2 slots per lanes. Using trigger() allows to set the FE/BE order,
solving the problem.

There has already been an attempt to fix this 3y ago [1] and reverted [2]
It triggered a 'sleep in irq' error on the period IRQ. The solution is
to just use the bottom half of threaded IRQ. This is patch #1. Patch #2
and #3 remain mostly the same as 3y ago.

For TDMOUT, the problem is on pause. ATM pause only stops the FIFO and
the TDMOUT just starves. When it does, it will actually repeat the last
sample continuously. Depending on the platform, if there is no high-pass
filter on the analog path, this may translate to a constant position of
the speaker membrane. There is no audible glitch but it may damage the
speaker coil.

Properly stopping the TDMOUT in pause solves the problem. There is
behaviour change associated with that fix. Clocks used to be continuous
on pause because of the problem above. They will now be gated on pause by
default, as they should. The last change introduce the proper support for
continuous clocks, if needed.

[1]: https://lore.kernel.org/linux-amlogic/20211020114217.133153-1-jbrunet@baylibre.com
[2]: https://lore.kernel.org/linux-amlogic/20220421155725.2589089-1-narmstrong@baylibre.com
      c5782bb5
  9. 29 Apr, 2024 10 commits
  11. 28 Apr, 2024 6 commits
    • Oswald Buddenhagen's avatar
      ALSA: emu10k1: make E-MU FPGA writes potentially more reliable · 15c7e87a
      Oswald Buddenhagen authored 
      We did not delay after the second strobe signal, so another immediately
following access could potentially corrupt the written value.

This is a purely speculative fix with no supporting evidence, but after
taking out the spinlocks around the writes, it seems plausible that a
modern processor could be actually too fast. Also, it's just cleaner to
be consistent.
Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Message-ID: <20240428093716.3198666-7-oswald.buddenhagen@gmx.de>
      15c7e87a
    • Oswald Buddenhagen's avatar
      ALSA: emu10k1: fix E-MU dock initialization · e8289fd3
      Oswald Buddenhagen authored 
      A side effect of making the dock monitoring interrupt-driven was that
we'd be very quick to program a freshly connected dock. However, for
unclear reasons, the dock does not work when we do that - despite the
FPGA netlist upload going just fine. We work around this by adding a
delay before programming the dock; for safety, the value is several
times as much as was determined empirically.

Note that a badly timed dock hot-plug would have triggered the problem
even before the referenced commit - but now it would happen 100% instead
of about 3% of the time, thus making it impossible to work around by
re-plugging.

Fixes: fbb64eed ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Message-ID: <20240428093716.3198666-6-oswald.buddenhagen@gmx.de>
      e8289fd3
    • Oswald Buddenhagen's avatar
      ALSA: emu10k1: use mutex for E-MU FPGA access locking · 2d3f4810
      Oswald Buddenhagen authored 
      The FPGA access through the GPIO port does not interfere with other
sound processor register access, so there is no need to subject it to
emu_lock. And after moving all FPGA access out of the interrupt handler,
it does not need to be IRQ-safe, either.

What's more, attaching the dock causes a firmware upload, which takes
several seconds. We really don't want to disable IRQs for this long, and
even less also have someone else spin with IRQs disabled waiting for us.

Therefore, use a mutex for FPGA access locking.

This makes the code somewhat more noisy, as we need to wrap bigger
sections into the mutex, as it needs to enclose the spinlocks.

The latter has the "side effect" of fixing dock FPGA programming in a
corner case: a really badly timed mixer access right between entering
FPGA programming mode and uploading the netlist would mess up the
protocol.
Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Message-ID: <20240428093716.3198666-5-oswald.buddenhagen@gmx.de>
      2d3f4810
    • Oswald Buddenhagen's avatar
      ALSA: emu10k1: move the whole GPIO event handling to the workqueue · f848337c
      Oswald Buddenhagen authored 
      The actual event processing was already done by workqueue items. We can
move the event dispatching there as well, rather than doing it already
in the interrupt handler callback.

This change has a rather profound "side effect" on the reliability of
the FPGA programming: once we enter programming mode, we must not issue
any snd_emu1010_fpga_{read,write}() calls until we're done, as these
would badly mess up the programming protocol. But exactly that would
happen when trying to program the dock, as that triggers GPIO interrupts
as a side effect. This is mitigated by deferring the actual interrupt
handling, as workqueue items are not re-entrant.

To avoid scheduling the dispatcher on non-events, we now explicitly
ignore GPIO IRQs triggered by "uninteresting" pins, which happens a lot
as a side effect of calling snd_emu1010_fpga_{read,write}().

Fixes: fbb64eed ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Message-ID: <20240428093716.3198666-4-oswald.buddenhagen@gmx.de>
      f848337c
    • Oswald Buddenhagen's avatar
      ALSA: emu10k1: factor out snd_emu1010_load_dock_firmware() · 28deafd0
      Oswald Buddenhagen authored 
      Pulled out of the next patch to improve its legibility.

As the function is now available, call it directly from
snd_emu10k1_emu1010_init(), thus making the MicroDock firmware loading
synchronous - there isn't really a reason not to. Note that this does
not affect the AudioDocks of rev1 cards, as these have no independent
power supplies, and thus come up only a while after the main card is
initialized.

As a drive-by, adjust the priorities of two messages to better reflect
their impact.
Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Message-ID: <20240428093716.3198666-3-oswald.buddenhagen@gmx.de>
      28deafd0
    • Oswald Buddenhagen's avatar
      ALSA: emu10k1: fix E-MU card dock presence monitoring · 398321d7
      Oswald Buddenhagen authored 
      While there are two separate IRQ status bits for dock attach and detach,
the hardware appears to mix them up more or less randomly, making them
useless for tracking what actually happened. It is much safer to check
the dock status separately and proceed based on that, as the old polling
code did.

Note that the code assumes that only the dock can be hot-plugged - if
other option card bits changed, the logic would break.

Fixes: fbb64eed ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Message-ID: <20240428093716.3198666-2-oswald.buddenhagen@gmx.de>
      398321d7
  13. 23 Apr, 2024 2 commits
  15. 20 Apr, 2024 1 commit
  17. 19 Apr, 2024 4 commits
  19. 18 Apr, 2024 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7