kernel.git/include/sound/emu10k1.h, branch linux-rolling-stable

ALSA: emu10k1: Use guard() for emu1010 FPGA locking

2025-09-01T11:52:40Z

The snd_emu1010_fpga_lock() and _unlock() call pairs can be simplified gracefully with the introduction of guard(). Only code refactoring, and no functional changes. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250829144342.4290-28-tiwai@suse.de

Merge branch 'topic/emu10k1-fix' into for-next

2024-04-28T10:00:57Z

Pull emu10k1 fixes from Oswald Buddenhagen Signed-off-by: Takashi Iwai

ALSA: emu10k1: move code for entering E-MU card FPGA programming mode

2024-04-28T10:00:36Z

... into snd_emu1010_load_firmware_entry(). This makes it clearer that these steps belong together tightly, as implied by prior commits. Signed-off-by: Oswald Buddenhagen Signed-off-by: Takashi Iwai Message-ID: <20240428093717.3198716-5-oswald.buddenhagen@gmx.de>

ALSA: emu10k1: move snd_emu1010_load_firmware_entry() to io.c

2024-04-28T10:00:36Z

It is a low-level I/O access function, so io.c is the natural place for it. While we're moving the code, reduce the scope of some variables, use compound assignment operators, and add/adjust some comments. Signed-off-by: Oswald Buddenhagen Signed-off-by: Takashi Iwai Message-ID: <20240428093717.3198716-4-oswald.buddenhagen@gmx.de>

ALSA: emu10k1: use mutex for E-MU FPGA access locking

2024-04-28T09:58:12Z

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: Oswald Buddenhagen Signed-off-by: Takashi Iwai Message-ID: <20240428093716.3198666-5-oswald.buddenhagen@gmx.de>

ALSA: emu10k1: move the whole GPIO event handling to the workqueue

2024-04-28T09:58:12Z

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: fbb64eedf5a3 ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen Signed-off-by: Takashi Iwai Message-ID: <20240428093716.3198666-4-oswald.buddenhagen@gmx.de>

ALSA: emu10k1: improve cache behavior documentation

2024-04-07T06:35:51Z

Resulting from more reverse engineering in the course of debugging. Signed-off-by: Oswald Buddenhagen Message-ID: <20240406064830.1029573-15-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai

ALSA: emu10k1: fix sample signedness issues in wavetable loader

2024-04-07T06:35:49Z

The hardware supports S16LE and U8 samples, while U16LE and S8 (which the driver implicitly claims to support) require sign flipping. Note that this matters only for the GUS patch loader, as the implemented SoundFont v2.01 spec is limited to S16LE. Signed-off-by: Oswald Buddenhagen Message-ID: <20240406064830.1029573-10-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai

ALSA: emu10k1: set the "no filtering" bits on PCM voices on Audigy

2023-07-17T07:29:07Z

Given that the filter is already set to neutral for PCM voices, the only observable effect is that the Z1/Z2/FXBUS registers don't have a stray bit set for negative numbers anymore. The bit is below the ones significant for output, but it would mess with 32-bit sample recombination, which we intend to add. kX-project does that, but I had to figure out myself why. Signed-off-by: Oswald Buddenhagen Link: https://lore.kernel.org/r/20230715160802.326872-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai

ALSA: emu10k1: track loss of external clock on E-MU cards

2023-07-17T07:21:21Z

85;95;0c This uses IRQs to track spontaneous changes to the word clock source register. FWIW, that this can happen in the first place is the reason why it is futile to lock the clock source mixer setting while the device is open - we can't consistently control the rate anyway. Though arguably, we should reset any open streams when that happens, as they become corrupted anyway. Signed-off-by: Oswald Buddenhagen Link: https://lore.kernel.org/r/20230715160738.326832-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai