summaryrefslogtreecommitdiffstats
path: root/sound/pci/emu10k1
Commit message (Collapse)AuthorAgeFilesLines
...
* ALSA: emu10k1: simplify interrupt handler, part 1Oswald Buddenhagen2023-05-181-2/+1
| | | | | | | | | | | IPR_CHANNELNUMBERMASK cannot be non-zero when IPR_CHANNELLOOP is unset, so join marking them as handled. This logically reverts part of commit f453e20d8a0 ("ALSA update 0.9.3a"), which made the inverse change with no explanation. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518093047.3697887-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix PCM playback buffer size constraintsOswald Buddenhagen2023-05-181-12/+26
| | | | | | | | | | | | | | | | | | | The period_bytes_min parameter and the buffer_bytes minimum constraint made no sense at all, as they didn't reflect any hardware limitation. Instead, apply a frame-based period_size minimum constraint, which is derived from the cache size (it would be actually possible to go below that, but it would require special handling, and it would be practically impossible to keep up with the IRQ rate anyway). Sync up the constraints of the EFX playback with those of the regular playback, as there is no reason for them to diverge. N.b., the maximum buffer size is actually arbitrary - the hardware could go waay beyond 128 KiB. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518092224.3696958-9-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: refactor PCM playback address handlingOswald Buddenhagen2023-05-181-29/+52
| | | | | | | | | | Pull the special handling of extra voices out of snd_emu10k1_pcm_init_voice(), simplify snd_emu10k1_playback_pointer(), and make the logic overall clearer. Also, add verbose comments. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-9-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: refactor PCM playback cache fillingOswald Buddenhagen2023-05-181-12/+21
| | | | | | | | | | | Rename snd_emu10k1_playback_invalidate_cache() to the more apt snd_emu10k1_playback_fill_cache(), and factor out snd_emu10k1_playback_prepare_voices(), which calls the former for all channels. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-8-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: improve API of low-level voice manipulation functionsOswald Buddenhagen2023-05-181-28/+22
| | | | | | | | | | | | | | | | | | Originally, there was a 1:1 relationship between the PCM streams' and the low-level voices' parameters. The addition of multi-channel playback partially invalidated that, but didn't introduce proper layering, so things kept working only by virtue of the multi-channel device never having two channels (yet). The upcoming addition of 32-bit playback would complete upending the relationships. So this patch detaches the low-level parameters from the high-level ones: we pass pre-calculated bit width and stereo flags to the low-level manipulation functions instead of calculating them in-place from the stream parameters. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix PCM playback cache and interrupt handlingOswald Buddenhagen2023-05-181-44/+23
| | | | | | | | | | | | | The cache causes a fixed delay regardless of stream parameters. Consequently, all that "cache invalidate size" calculation stuff was garbage (which can be traced right back to Creative's OSS driver). This also removes the definitions of registers CD1..CDF, because they are accessed only relative to CD0 anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: skip pointless cache setup for extra voicesOswald Buddenhagen2023-05-181-6/+5
| | | | | | | | | | Given that the data is going to be ignored anyway, and that the cache does not influence interrupt timing (which is the purpose of the extra voices), it's pointless to pre-fill the cache. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove pointless displacement of the extra voicesOswald Buddenhagen2023-05-181-4/+0
| | | | | | | | | | | The idea is to make the extra voice lag behind the "real" voices, but moving the buffer address around doesn't contribute to that, as the CCCA write below uses the same address. The exact address is unimportant, as the data is discarded anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Revert "ALSA: emu10k1 - delay the PCM interrupts (add pcm_irq_delay parameter)"Oswald Buddenhagen2023-05-183-30/+3
| | | | | | | | | | | This workaround fails to address the underlying problem, which is actually wholly self-made. Subsequent patches will fix it. This reverts commit 56385a12d9bb9e173751f74b6c430742018cafc0. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: pass frame instead of byte addressesOswald Buddenhagen2023-05-181-22/+9
| | | | | | | | | ... to snd_emu10k1_pcm_init_voice(). This makes the code arguably less convoluted. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove runtime 64-bit divisionsOswald Buddenhagen2023-05-171-6/+12
| | | | | | | | | | | | | | | | | | 32-bit platforms don't like these. As we're actually dealing with constants, factor out the calculations and pass them in as additional arguments. To keep the call sites clean, wrap the actual functions in macros which generate the arguments. Fixes: bb5ceb43b7bf ("ALSA: emu10k1: fix non-zero mixer control defaults in highres mode") Fixes: 1298bc978afb ("ALSA: emu10k1: enable bit-exact playback, part 1: DSP attenuation") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202305171622.jKTovBvy-lkp@intel.com/ Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu> Closes: https://lore.kernel.org/r/CA+G9fYsShNP=LALHdMd-Btx3PBtO_CjyBNgpStr9fPGXNbRvdg@mail.gmail.com Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517164800.3650699-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make struct snd_emu1010 less wastefulOswald Buddenhagen2023-05-171-0/+5
| | | | | | | | | | | Shrink the {in,out}put_source arrays and their data type to what is actually necessary. To be still on the safe side, add some static asserts. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-11-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: add explicit support for E-MU 0404Oswald Buddenhagen2023-05-173-29/+121
| | | | | | | | | | | | Unlike the other models, this is actually a distinct card, rather than an E-MU 1010 with different "dongles". It is stereo only, and supports no ADAT (there is no trace of ADAT in the manual, switching the output mode to ADAT has no effect, and switching the input mode to ADAT just breaks input (presumably ... my only ADAT source is the card's output)). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-10-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: improve mixer controls for E-MU 1010 rev2 cardOswald Buddenhagen2023-05-171-6/+100
| | | | | | | | | This card has rather different inputs/outputs due to switching from the AudioDock to the MicroDock. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-9-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make E-MU mixer control creation more data-drivenOswald Buddenhagen2023-05-171-51/+49
| | | | | | | | | | | | The more card models are handled separately, the more code duplication this saves. add_emu1010_source_mixers() is factored out the save duplication in a later commit. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-8-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make E-MU I/O routing init data-drivenOswald Buddenhagen2023-05-172-246/+99
| | | | | | | | | | | | | | | | | | | | | | | ... and move it to the mixer init, as it's logically part of it. As a side effect, this fixes the initial values of the input destination mixer controls, which would have previously remained at "Silent" despite different defaults. This didn't really matter, though, as ALSA state restoration would hide that bug beyond first use. Note that this completely does away with clearing the output routing registers, as it was rather pointless - we just programmed the FPGA (resetting it first if necessary), so everything is zeroed anyway (that's documented by Xilinx, and as further evidence, some of the loops terminated too early, and we didn't bother clearing the high channels of the input routes at all, all with no observed adverse effects). As a drive-by, this also fixes some capture channel defaults - any EMU_SRC_*2 isn't a sensible value in 1x clock mode. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix return value of snd_emu1010_dac_pads_put()Oswald Buddenhagen2023-05-171-2/+5
| | | | | | | | It returned zero even if the value had changed. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-6-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: un-hardcode E-MU mixer control callbacks somewhatOswald Buddenhagen2023-05-171-54/+101
| | | | | | | | | | | | | | | Instead of hard-coding the card-specific arrays and their sizes in each function, use a more data-driven approach. As a drive-by, also hide the unavailable I2S input destinations on the 1616 cardbus card. Also as a drive-by, use more assignments at variable declaration for brevity. This also removes the pointless masking of kctl.private_value. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make mixer control mass creation less wastefulOswald Buddenhagen2023-05-171-247/+202
| | | | | | | | | | | | | | | | | | | | | Define arrays of strings instead of snd_kcontrol_new. While at it, move the E-MU source & destination enum defs next to their hardware defs, which is a lot more logical and will come in handy in a followup commit. And add some static asserts to verify that the array sizes match. This also applies the compactization from the previous commit to the destination registers. While reshuffling the arrays anyway, switch the order of the HAMOA_DAC & HANA_SPDIF output destinations for the 1010 card, so they follow a more regular pattern. This should have no functional impact. The code is somewhat de-duplicated by the extraction of add_ctls(). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: compactize E-MU routing source arraysOswald Buddenhagen2023-05-171-212/+103
| | | | | | | | | | | | | | | | | Use macros to avoid duplication. Arguably, this is somewhat less legible, but future additions would grow this part of the file to completely unmanageable dimensions. The EMU*_COMMON_TEXTS macros will save duplication in a future commit; I pulled them ahead to reduce churn. While rewriting the tables anyway, rearrange them such that each card's strings and registers are adjacent. Also, add some static asserts to verify that the array sizes match. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make some initializer arrays less wastefulOswald Buddenhagen2023-05-171-5/+5
| | | | | | | | | - Use bit fields in struct snd_emu_chip_details - Use shorts in the E-MU routing register arrays Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536508-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: factor out snd_emu10k1_compose_audigy_sendamounts()Oswald Buddenhagen2023-05-172-9/+3
| | | | | | | | Saves a bit of code duplication. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: skip needless setting of some voice registersOswald Buddenhagen2023-05-171-41/+48
| | | | | | | | | | | | | | | | | | | | | | Many registers are meaningless for stereo slaves and the extra voices. This patch cleans up these unnecessary register writes. snd_emu10k1_playback_{trigger,stop}_voice() is not called for stereo slaves any more. snd_emu10k1_playback_prepare_voice() is renamed to snd_emu10k1_playback_unmute_voice(), as this better reflects its remaining function. It's not called for the extra voices any more. Accordingly, snd_emu10k1_playback_mute_voice() is factored out from snd_emu10k1_playback_stop_voice(), and is called selectively as well. This doesn't add conditionals which would avoid initializing sub-registers, as that wouldn't pull its weight. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-6-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: rewire {en,dis}abling interrupts for PCM playbackOswald Buddenhagen2023-05-171-16/+29
| | | | | | | | | | | | | | | | | | | We now enable ints even before triggering, and disable them only after stopping - otherwise there is a race condition we may plausibly run into when we pause/resume near the end of the buffer. Updating the epcm->running flag is moved the same way, as it affects the *_pointer() functions, which are called by the interrupt handler. Also, factor these out to own functions, for clarity. For multi-channel, the extra voice is now triggered after all regular voices - we wouldn't want to receive an int before all channels have passed the period boundary. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove useless resets of stop-on-loop-end bitsOswald Buddenhagen2023-05-172-1/+2
| | | | | | | | | We initialize them at card init and don't touch them later, so there is no need to reset them again at voice start. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: cleanup envelope register initOswald Buddenhagen2023-05-173-99/+14
| | | | | | | | | | | | | We (rightfully) don't enable the envelope engine for PCM voices, so any related setup is entirely pointless - the EMU8K documentation makes that very clear, and the fact that the various open drivers all use different values to no observable detriment pretty much confirms it. The remaining initializations are regrouped for clarity. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: straighten out FX send initOswald Buddenhagen2023-05-173-52/+8
| | | | | | | | | | | | | | | | | | | | | | | | | The mixer structures were filled in two places: on driver init, and when the devices are opened. The latter made the former pointless, so we remove the former. This implies that mixer dumps may now return all zeroes, which is OK, as restoring them is meaningless as well. Things were even weirder for the (generally unused) secondary sends: Some of the initialization loops were forgotten when support for Audigy was added, thus creating the technically illegal state of multiple sends being routed to the same FX accumulator (though it apparently doesn't matter when the amount is zero). The global multi-channel init used some rather bizarre values for the secondary sends, and the init on open actually forgot to re-initialize them. We now use a not really more useful, but simpler formula. The direct register init was also bogus. This doesn't really matter, as the value is overwritten when a voice comes into use, but still. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: enable bit-exact playback, part 2: voice attenuationOswald Buddenhagen2023-05-163-20/+29
| | | | | | | | | | | | | | | | | | | | The voice volume is a raw fractional multiplier that can't actually represent 1.0. To still enable real pass-through, we now set the volume to 0.5 (which results in no loss of precision, as the FX bus provides fractional values) and scale up the samples in DSP code. To maintain backwards compatibility with existing configuration files, we rescale the values in the mixer controls. The range is extended upwards from 0xffff to 0x1fffd, which actually introduces the possibility of specifying an amplification. There is still a minor incompatibility with user space, namely if someone loaded custom DSP code. They'll just get half the volume, so this doesn't seem like a big deal. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408834-8-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: enable bit-exact playback, part 1: DSP attenuationOswald Buddenhagen2023-05-151-63/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fractional multiplication with the maximal value 2^31-1 causes some tiny distortion. Instead, we want to multiply with the full 2^31. The catch is of course that this cannot be represented in the DSP's signed 32 bit registers. One way to deal with this is to encode 1.0 as a negative number and special-case it. As a matter of fact, the SbLive! code path already contained such code, though the controls never actually exercised it. A more efficient approach is to use negative values, which actually extend to -2^31. Accordingly, for all the volume adjustments we now use the MAC1 instruction which negates the X operand. The range of the controls in highres mode is extended downwards, so -1 is the new zero/mute. At maximal excursion, real zero is not mute any more, but I don't think anyone will notice this behavior change. ;-) That also required making the min/max/values in the control structs signed. This technically changes the user space interface, but it seems implausible that someone would notice - the numbers were actually treated as if they were signed anyway (and in the actual mixer iface they _are_). And without this change, the min value didn't even make sense in the first place (and no-one noticed, because it was always 0). Tested-by: Jonathan Dowland <jon@dow.land> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408834-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: skip mic capture PCM for cards without AC97 codecOswald Buddenhagen2023-05-152-16/+20
| | | | | | | | | The microphone capture device is a feature of the AC97 codec, so its availability should be coupled to the presence of that codec. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408834-6-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: omit non-applicable mixer controls for E-MU cardsOswald Buddenhagen2023-05-151-117/+116
| | | | | | | | | | | The E-MU cards don't try very hard to be Sound Blasters. All sound I/O goes through the Hana FPGA, thus making the regular extin/out controls useless. Still showing them just serves to clutter up the interface and confuse the user. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408834-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: validate min/max values of translated controlsOswald Buddenhagen2023-05-151-0/+26
| | | | | | | | | | | | | | | User space could pass arbitrary ranges, which were uncritically accepted. This could lead to table lookups out of range. I don't think that this is a security issue, as it only allowed someone with CAP_SYS_ADMIN to crash the kernel, but still. Setting an invalid translation mode will also be rejected now. That did no harm, but it's still better to detect errors. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408834-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix non-zero mixer control defaults in highres modeOswald Buddenhagen2023-05-151-3/+5
| | | | | | | | The default value needs to be scaled. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408834-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: polish audigy GPR allocationOswald Buddenhagen2023-05-151-32/+37
| | | | | | | | | | | | - Pull ahead all fixed allocations, so we don't rely on the semi- dynamic ones not crossing the arbitrarily determined limit - Use an enum for the fixed allocations - Stop arbitrarily wasting registers on unexplained "reservations" - Don't reserve two regs for the master volume control - it's mono Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408834-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: optimize mask calculation in snd_emu10k1_ptr_read()Oswald Buddenhagen2023-05-151-2/+2
| | | | | | | | | Unlike in snd_emu10k1_ptr_write(), we don't need to keep the value's bits in place, so we can save one shift. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408798-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: merge common paths in snd_emu10k1_ptr_{read,write}()Oswald Buddenhagen2023-05-151-13/+7
| | | | | | | | Avoids some code duplication. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408798-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: validate parameters of snd_emu10k1_ptr_{read,write}()Oswald Buddenhagen2023-05-151-7/+22
| | | | | | | | | Rather than applying masks to the provided values, make assertions about them being valid - otherwise we'd just try to paper over bugs. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408798-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: simplify tone control switch DSP codeOswald Buddenhagen2023-05-121-73/+50
| | | | | | | | | | | Instead of using lots of instructions to mix wet and dry signals, simply skip over the whole code block if tone control is disabled. This also allows us doing away with the "shadow" playback channels. Tested-by: Jonathan Dowland <jon@dow.land> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230510173917.3073107-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: apply channel delay hack to all E-MU cardsOswald Buddenhagen2023-05-121-5/+18
| | | | | | | | | | | | | Evidently, the channel delay bug exists in all E-MU cards; it's in the Hana FPGA program, and was never fixed. Note that the implementation is somewhat lazy - to localize the code paths, we actually waste a GPR and a DSP instruction by keeping two delay registers for the same physical source. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230510173917.3073107-6-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: simplify snd_emu10k1_audigy_dsp_convert_32_to_2x16()Oswald Buddenhagen2023-05-121-13/+13
| | | | | | | | | | | | | | Instead of spending lots of instructions on masking and transplanting the sign bit, sidestep the issue by replacing the last bit shift with a wrapping addition to self. Solution stolen from kX-project, after I pondered other ideas first. Also, the function really doesn't need to return a constant int value. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230510173917.3073107-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix+optimize E-MU stereo capture DSP codeOswald Buddenhagen2023-05-121-5/+3
| | | | | | | | | | | | | | Presumably, JDC added the seemingly superfluous indirection over the temporary register because without it he'd get only zero readings. However, switching the X and Y operands (or using EMU32 as the A operand in the temporary load) works just fine. Presumably a DSP bug? The original code was also actually buggy, though: both channels used the left volume control. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230510173917.3073107-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: roll up loops in DSP setup code for AudigyOswald Buddenhagen2023-05-121-103/+9
| | | | | | | | There is no apparent reason for the massive code duplication. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230510173917.3073107-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make tone control switch monoOswald Buddenhagen2023-05-121-8/+8
| | | | | | | | | It controls the whole surround set, so stereo can't work. As a consequence, only the left channel was paid attention to. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230510173917.3073107-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: don't create regular S/PDIF controls for E-MU cardsOswald Buddenhagen2023-05-121-1/+1
| | | | | | | | These ports are unused on these cards. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230510173722.3072439-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: minor E-MU naming fixupsOswald Buddenhagen2023-05-082-26/+26
| | | | | | | | | | | | | | | | | - Fix mixer source port names. These will require some users to re-adjust their mixer settings, which seems acceptable: - The S/PDIF port is on the main 1010 card, not the 0202 daughter card - The 1616m CardBus card has all inputs on the dock, so there is no point in specifying it - Conversely, the 1010 card has "dispersed" inputs, so say where the ADAT port is, consistently with the S/PDIF port - The 1616m CardBus card is actually named E-MU 02 (due to the headphone output jack it has) - Fix capitalization of "E-MU" Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230428095941.1706335-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove now superfluous mixer lockingOswald Buddenhagen2023-05-083-37/+0
| | | | | | | | | | | | | | | | | Since commit 5bbb1ab5bd ("control: use counting semaphore as write lock for ELEM_WRITE operation"), mixer values have been fully read-write locked. This means that it is now unnecessary to apply any additional locks to values that are accessed solely by mixer callbacks. Values that are read outside mixer callbacks still need write locking. There are no cases of mixer values being written outside mixer callbacks, so no read locks remain in mixer callbacks. Note that the removed locks refer only to the emu data structure, not the card's registers as the lock's name suggests. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230428095941.1706278-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix locking in snd_emu1010_fpga_link_dst_src_write()Oswald Buddenhagen2023-05-081-8/+17
| | | | | | | | | This is a multi-register operation, which must be locked in its entirety. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230428095941.1706278-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: use the right lock in snd_emu10k1_shared_spdif_put()Oswald Buddenhagen2023-05-081-2/+2
| | | | | | | | | | | | The function does read-modify-write cycles on the card's registers, and doesn't access mutable members of the emu data structure. I suppose this might have been a mixup due to the lock names being logically swapped. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230428095941.1706278-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove pointless locks from /proc codeOswald Buddenhagen2023-05-081-6/+0
| | | | | | | | | emu_lock locks the card's registers, but that's necessary only for multi-register access, incl. read-modify-write cycles. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230428095941.1706278-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove pointless locks from timer codeOswald Buddenhagen2023-05-081-6/+0
| | | | | | | | | | | | | | | | | | Contrary to its name, reg_lock locks the emu data structure, not the registers. As the functions access only data which is set once at card initialization, there is no point in locking it. Actually locking the registers would be pointless as well, as snd_emu10k1_intr_{en,dis}able() does its own locking, and TIMER is accessed only in this one place. Locking snd_emu10k1_timer_{start,stop}() against each other also wouldn't buy us anything; the functions interleaving their I/O accesses wouldn't introduce new problems. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230428095941.1706278-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-14 11:17:57 +0000