- 18 Apr, 2024 26 commits
-
-
Stefan Binding authored
These laptops do not have _DSD and must be added by configuration table, however, the initial entries for them are incorrect: Neither laptop contains a Speaker ID GPIO. This issue would not affect audio playback, but may affect which files are loaded when loading firmware. Fixes: b67a7dc4 ("ALSA: hda/realtek: Add sound quirks for Lenovo Legion slim 7 16ARHA7 models") Signed-off-by:
Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Message-ID: <20240411110813.330483-8-sbinding@opensource.cirrus.com>
-
Richard Fitzgerald authored
In every case the 'dir' argument to cs35l41_request_firmware_file() is passed the string "cirrus/", so this is a redundant argument and can be removed. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by:
-
Stefan Binding authored
The original mechanism for applying calibration assumed that the calibration data would be ordered the same as the amp instances. However, for some 4 amp laptops, this is not the case. To ensure that the correct calibration is applied to the correct amp, the calibration data contains a unique id, which matches a unique id inside the CS35L41. This can be used to match to the correct data entry. This mechanism is available inside the shared module cs-amp-lib. Signed-off-by:
-
Stefan Binding authored
Currently, all PC systems are set to use VBSTMON for DSP1RX5_SRC, however, this is required only for external boost systems. Internal boost systems require VPMON instead of VBSTMON to be the input to DSP1RX5_SRC. All systems require DSP1RX6_SRC to be set to VBSTMON. Also fix incorrect comment for DACPCM1_SRC to use DSP1TX1. Signed-off-by:
-
Stefan Binding authored
Add 4 laptops using CS35L41 HDA. None of these laptops have _DSD, so require entries in property configuration table for cs35l41_hda driver. Signed-off-by:
-
Stefan Binding authored
Add support for 2 new HP Omen models without _DSD into configuration table. These laptops use the PCM Gain setting for the tuning setting file. Signed-off-by:
-
Stefan Binding authored
Some systems requires different max PCM Gains settings than the default. The current default value, when running firmware is 17.5 dB, which is used for all systems. Some systems require lower values. Value when running without firmware is 4.5 dB and remains unchanged. Since the gain value is dependent on Tuning and Firmware, it can change, so it cannot be saved in _DSD. Instead we can store it inside a configuration binary file alongside the Firmware and Tuning files. The gain value increments in steps of 1 dB, with value 0 representing 0.5 dB. The max value is 20, which corresponds to 20.5 dB. Signed-off-by:
-
Peter Ujfalusi authored
It is recommended that on Lunar Lake the PIO (immediate command response) is used instead of CORB/RIRB for commands/verbs. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Liam Girdwood <liam.r.girdwood@intel.com> Acked-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
It is recommended that on Lunar Lake the PIO (immediate command response) is used instead of CORB/RIRB for commands/verbs. Signed-off-by:
-
Peter Ujfalusi authored
Set the use_pio_for_commands flag in case AZX_DCAPS_PIO_COMMANDS quirk is enabled. When the PIO command mode is used we can re-use the existing azx_single_send_cmd() / azx_single_get_response() functions safely as the CORB DMA is not going to be enabled in snd_hdac_bus_init_cmd_io(). Signed-off-by:
-
Peter Ujfalusi authored
In case the use_pio_for_commands flag is set we must not enable the CORB DMA to make sure that it is not interfering with the immediate command mode. Convert the snd_hdac_bus_send_cmd/snd_hdac_bus_get_response as wrappers to call either the PIO or CORB based command handling depending on the use_pio_for_commands flag. Signed-off-by:
-
Peter Ujfalusi authored
Add AZX_DCAPS_PIO_COMMANDS quirk (bit 31) and use_pio_for_commands flag to be able to select PIO mode as alternative for CORB based command sending while retaining the RIRB functionality to receive unsolicited responses. This mode differs from the azx single_cmd mode when RIRB is disabled. The mixed mode is needed on Lunar Lake family because it is recommended to use Immediate Command Response (PIO mode) instead of CORB for HDA commands. Signed-off-by:
-
Geoffrey D. Bennett authored
The Vocaster Two has a Bluetooth module with a volume control. Add a corresponding ALSA mixer control. Signed-off-by:
Geoffrey D. Bennett <g@b4.vu> Signed-off-by:
-
Geoffrey D. Bennett authored
The Scarlett 4th Gen and Vocaster interfaces allow the autogain target dBFS value(s) to be configured. Add Mean and Peak Target controls for 4th Gen, and a Hot Target control for Vocaster. Signed-off-by:
-
Geoffrey D. Bennett authored
Add Focusrite Vocaster One and Two USB IDs, notification arrays, config sets, and device info data. Signed-off-by:
-
Geoffrey D. Bennett authored
Add filter and compressor DSP controls for the Vocaster interfaces. Mark scarlett2_notify_input_dsp() as __always_unused until it gets used when the Vocaster callback function array is added. Signed-off-by:
-
Geoffrey D. Bennett authored
Add controls for the input mute switches that the Vocaster interfaces have. Mark scarlett2_notify_input_mute() as __always_unused until it gets used when the Vocaster callback function array is added. Signed-off-by:
-
Geoffrey D. Bennett authored
The autogain status texts are different for Vocaster vs. Scarlett 4th Gen, so make them configurable per-config-set. Signed-off-by:
-
Geoffrey D. Bennett authored
Remove the #define SCARLETT2_MAX_GAIN_DB and replace with a per-config-set TLV as the Vocaster has a maximum gain of 70dB vs the 4th Gen 69dB. Signed-off-by:
-
Geoffrey D. Bennett authored
The 4th Gen Scarlett interfaces added software-controllable input gain along with channel select, channel link, auto-gain, and "safe" mode. Vocaster has software-controllable input gain and auto-gain but not channel select, channel link, or safe mode. Add a device info field safe_input_count to indicate how many channels have a safe mode control, and use the presence of the input select and input link switch configuration parameters to determine if those controls should be created. Signed-off-by:
-
Geoffrey D. Bennett authored
Update scarlett2_usb_get_config() to support 32-bit values which are needed by the upcoming Vocaster support. Signed-off-by:
-
Geoffrey D. Bennett authored
scarlett2_usb_set_config() was using size = 0 as a signal to use the parameter buffer. Replace that with an explicit indication (pbuf = 1), as the upcoming Vocaster support has a config item written via the parameter buffer with size = 1 rather than the implicit size of 8. Signed-off-by:
-
Geoffrey D. Bennett authored
The location pointed to by gen4_write_addr and gen4_write_addr + 1 is officially known as the parameter buffer. Update the code to match. Signed-off-by:
-
Geoffrey D. Bennett authored
Add hwdep read op so flash segments can be read. Signed-off-by:
-
Geoffrey D. Bennett authored
After scarlett2_usb() sends a command, it seems that we should wait for an ACK before attempting to read the response. Not doing that didn't seem necessary previously but seems to be causing occasional issues with 4th Gen devices. Signed-off-by:
-
Geoffrey D. Bennett authored
So that more forward declarations won't be required when we add handling of the ACK notification, move the initialisation functions to after the notification functions. Signed-off-by:
-
- 07 Apr, 2024 14 commits
-
-
Takashi Iwai authored
Pull emu10k1 fix patch series Signed-off-by: -
Oswald Buddenhagen authored
Both drivers provide both sample_new and sample_free, and it makes no sense to pretend that they could not. In fact, load_data() would already crash if sample_new was null. So remove the remaining null checks. Contrary to that, the emu10k1 driver actually has a null sample_reset, though I'm not convinced that this inconsistency is justified. Signed-off-by:
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-18-oswald.buddenhagen@gmx.de> Signed-off-by:
-
Oswald Buddenhagen authored
There is no need for it to be 32 samples - 3 will do just fine (which is the interpolator's epsilon). The old size was presumably meant to compensate for the cache's presence, but we're now handling that properly. Signed-off-by:
-
Oswald Buddenhagen authored
Compensate for the cache lag of 64 frames, and actually populate the cache. Without these, the playback would start with garbage (which would be (mostly?) masqueraded by the note's attack phase). Note that we set the starting address only 61 frames ahead, to compensate for the interpolator's epsilon. Unlike for PCM playback, we don't even need to manually silence-fill the first frames in the cache, because we insert some silence in front of each sample anyway. A challenge are extremely short samples with a loop end below the cache size, because a) we'd have to wrap the current address to be within the loop and b) automatic pre-filling of the cache with the right data does not work in this case. We could pre-fill the cache manually, but that's slow, requires additional code for each sample width, and is made even more complex by the driver's virtual address space having no contiguous mapping for the CPU. We could have the engine fill the cache piece-wise (which is really what happens when playback is running), but that would also be complex, and we'd need to wait for the engine to handle each piece, so it wouldn't be that much faster than the manual fill. For the case of requiring only one loop iteration prior to reaching the cache size, we could leverage the engine's looping mechanism around CCR_CACHELOOPFLAG, but this special case doesn't seem worth the complexity. So we just unroll the loop as far as necessary to be able to play back the sample without any fiddling. Pedantically, this would be incorrect for loop-until-release samples with a low loop end which are released very quickly, but that would be relatively harmless, is not a plausible use case in the first place, and SoundFont sample mode 3 isn't actually implemented anyway (it's conflated with mode 1, infinite looping). Signed-off-by:
-
Oswald Buddenhagen authored
Resulting from more reverse engineering in the course of debugging. Signed-off-by:
-
Oswald Buddenhagen authored
Instead of repeatedly checking the sample width, assign a size shift centrally. Signed-off-by:
-
Oswald Buddenhagen authored
The offsets are counted in samples, not in bytes. While the code block is being rewritten, also move it up a bit, to avoid churn in a subsequent patch. Signed-off-by:
-
Oswald Buddenhagen authored
This de-duplicates the code slightly. But the real reason is that it moves the code up, which the next patch will depend on. Signed-off-by:
-
Oswald Buddenhagen authored
Samples are byte-sized in this mode, and thus the offset calculation needs no shifting. Signed-off-by:
-
Oswald Buddenhagen authored
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 authored
Convert some checks in snd_emu10k1_sample_new() back into assertions (as they were prior to da3cec35 (ALSA: Kill snd_assert() in sound/pci/*, 2008-08-08)), and move them into the low-level memory access functions they protect. Signed-off-by:
-
Oswald Buddenhagen authored
In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did. Signed-off-by:
-
Oswald Buddenhagen authored
This does several closely related things: - Move the code from the drivers into the SoundFont loader, which de-duplicates it. - Sort of explain the weird "recalculate address offset" feature. Note that I don't think it actually makes any sense - the calling user space code should do that. The background is certainly that the source data (the SoundFont format) uses pointers into a single wave block (and the API allows doing the same for on-board ROM), but the API expects the wave data from user space to be pre-chopped into individual patches anyway. - Make sure that the specified offsets actually lie within the supplied wave data. Note that we don't validate ROM offsets, so one can play back anything within the sound card's address space. - In load_guspatch(), don't call the sample_new callback anymore when the patch size is zero, as was already the case in load_data(). The callbacks would instantly return in that case anyway; these checks are now removed. Signed-off-by:
-
Oswald Buddenhagen authored
This is required only to implement WAVE_BIDIR_LOOP and WAVE_LOOP_BACK in the GUS patch loader. It has not worked on emu10k1 since before ALSA hit mainline, yet nobody appears to have complained. And as it isn't super easy to implement, just admit defeat and clean up the code. If somebody wanted to resurrect the feature, the emu8k driver could serve as a template, but the code would be quite different. But arguably, this should be done in user space in the first place, as this doesn't represent a hardware feature (somewhat ironically, the actual GUS driver has no synth support, and therefore no GUS patch loader). Note that instead of properly rejecting affected samples, we continue to just pretend that the feature wasn't requested. This is extremely questionable behavior, but avoids that possibly unused instruments suddenly prevent loading the entire file, which would break backwards compatibility. But at least we log a warning now. Signed-off-by:
-
