Skip to content

L
linux
Switch branch/tag
  1. 28 Apr, 2024 8 commits
    • Oswald Buddenhagen's avatar
      ALSA: emu10k1: make snd_emu1010_load_firmware_entry() void · b83587ea
      Oswald Buddenhagen authored 
      There is only one call site, and there we already know that we actually
have a firmware.
Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Message-ID: <20240428093717.3198716-3-oswald.buddenhagen@gmx.de>
      b83587ea
    • Oswald Buddenhagen's avatar
      ALSA: emu10k1: simplify E-MU card FPGA reset sequence · 7868e4c1
      Oswald Buddenhagen authored 
      Firstly, it is pointless to explicitly disable the power to the dock
prior to resetting the FPGA, as the latter will do the former anyway.

Secondly, it doesn't make much sense to check whether the FPGA is
already programmed. It's much simpler to just presume it is, and issue
the self-reset command. If it isn't, the effect isn't worse than the
checks themselves. As a side effect, we lose the info if the reset
fails, but there is no plausible way how that could happen unless the
card burns out while operating, and in that case we'll detect a firmware
upload failure a bit later anyway.
Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Message-ID: <20240428093717.3198716-2-oswald.buddenhagen@gmx.de>
      7868e4c1
    • 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
  3. 19 Apr, 2024 2 commits
  5. 18 Apr, 2024 4 commits
  7. 07 Apr, 2024 2 commits
  9. 05 Apr, 2024 1 commit
  11. 04 Apr, 2024 2 commits
  13. 03 Apr, 2024 2 commits
  15. 02 Apr, 2024 11 commits
  17. 01 Apr, 2024 1 commit
  19. 30 Mar, 2024 1 commit
  21. 29 Mar, 2024 3 commits
  23. 28 Mar, 2024 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7