Vitaly Rodionov [Thu, 30 Jun 2022 00:23:25 +0000 (01:23 +0100)]
ALSA: hda: cs35l41: Add initial DSP support and firmware loading
This patch adds support for the CS35L41 DSP.
The DSP allows for extra features, such as running
speaker protection algorithms and hibernations.
To utilize these features, the driver must load
firmware into the DSP, as well as various tuning
files which allow for customization for specific
models.
Stefan Binding [Thu, 30 Jun 2022 00:23:23 +0000 (01:23 +0100)]
ALSA: hda: hda_cs_dsp_ctl: Add apis to write the controls directly
DSP controls are exposed as ALSA controls, however,
some of these controls are required to be accessed by
the driver. Add apis which allow read/write of these
controls. The write api will also notify the ALSA control
on value change.
Stefan Binding [Thu, 30 Jun 2022 00:23:22 +0000 (01:23 +0100)]
ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls
The cs35l41 part contains a DSP which is able to run firmware.
The cs_dsp library can be used to control the DSP.
These controls can be exposed to userspace using ALSA controls.
This library adds apis to be able to interface between
cs_dsp and hda drivers and expose the relevant controls as
ALSA controls.
[ Note: the dependency of CONFIG_SND_HDA_CS_DSP_CONTROLS Kconfig is
corrected. Also, this Kconfig isn't enabled now but will be
actually enabled in a later patch -- tiwai ]
ALSA: usb-audio: Use atomic_try_cmpxchg in ep_state_update
Use atomic_try_cmpxchg instead of atomic_cmpxchg (*ptr, old, new) == old in
ep_state_update. x86 CMPXCHG instruction returns success in ZF flag,
so this change saves a compare after cmpxchg (and related move instruction
in front of cmpxchg).
ALSA: core: Fix missing return value comments for kernel docs
Each kernel doc comment expects the definition of the return value in
a proper format. This patch adds or fixes the missing entries for the
remaining ALSA core API functions.
ALSA: memalloc: Fix missing return value comments for kernel docs
Each kernel doc comment expects the definition of the return value in
a proper format. This patch adds or fixes the missing entries for
memory allocation helpers.
Each kernel doc comment expects the definition of the return value and
the summary for each struct / enum in a proper format. This patch
adds or fixes the missing entries for compress-offload API.
ALSA: dmaengine: Fix missing return value comments for kernel docs
Each kernel doc comment expects the definition of the return value in
a proper format. This patch adds or fixes the missing entries for PCM
dmaengine API.
ALSA: compress: Enable kernel doc markers for some functions
The exported functions snd_compress_new() and snd_compr_stop_error()
had already kernel-doc-style comments but they were not processed as
they weren't marked properly. Let's enable them.
This patch also fixes the missing argument id for snd_compress_new
comments, too.
The comments are inconsistent and point to the wrong driver name.
The initially named i2c-multi-instantiate it was renamed to the
serial-multi-instantiate exactly due to support of the platforms
with multiple CS35L41 codecs.
Old code resets SIE for up to 8 streams using byte accessor, but
register is laid out in following way:
31 GIE
30 CIE
29:x Reserved
x-1:0 SIE
If there is more than 8 streams, some of them may and up with enabled
interrupts. To fix this just clear whole INTCTL register when disabling
interrupts.
ALSA: hda: Fix page fault in snd_hda_codec_shutdown()
If early probe of HDAudio bus driver fails e.g.: due to missing
firmware file, snd_hda_codec_shutdown() ends in manipulating
uninitialized codec->pcm_list_head causing page fault.
Iinitialization of HDAudio codec in ASoC is split in two:
- snd_hda_codec_device_init()
- snd_hda_codec_device_new()
snd_hda_codec_device_init() is called during probe_codecs() by HDAudio
bus driver while snd_hda_codec_device_new() is called by
codec-component's ->probe(). The second call will not happen until all
components required by related sound card are present within the ASoC
framework. With firmware failing to load during the PCI's deferred
initialization i.e.: probe_work(), no platform components are ever
registered. HDAudio codec enumeration is done at that point though, so
the codec components became registered to ASoC framework, calling
snd_hda_codec_device_init() in the process.
Now, during platform reboot snd_hda_codec_shutdown() is called for every
codec found on the HDAudio bus causing oops if any of them has not
completed both of their initialization steps. Relocating field
initialization fixes the issue.
ALSA: hda: Fix put_device() inconsistency in error path
AVS HDAudio bus driver does not tie with codec drivers tighly. Codec
device and its respective driver cleanup procedures are split and may
not occur one after the other. Device cleanup is performed only on
snd_hdac_ext_bus_device_remove() i.e. it's the bus driver's
responsibility. If codec component probing fails, put_device() found in
snd_hda_codec_device_new() may lead to page fault. Relocate it to
snd_hda_codec_new() to address the problem on ASoC side while keeping
status quo for snd_hda_intel.
ALSA: hda: Make device usage_count consistent across subsequent probing
AVS HDAudio bus driver does not tie with codec drivers tighly and
snd_hda_codec_device_new() can be called after codec's module reload. In
such case, rpm is forbidden and invoking pm_runtime_forbid()
unconditionally causes device's usage_count to become unbalanced. This
is later caught by WARN_ON() found in sound/soc/hda.c. Detect such
circumstance and bump the usage_count instead.
ALSA: hda: Fix null-ptr-deref when i915 fails and hdmi is denylisted
If snd_hda_hdmi_codec module is denylisted and any event causes i915
enumeration to fail, is_likely_hdmi_codec() ends in null-ptr-deref.
As snd_soc_hda is an ASoC-based driver, its initialization is delayed
until all the necessary components appear in the system - allowing
actual sound card to enumerate. snd_hda_codec_configure() gets called by
the avs-driver core during probe_codecs() but the
snd_hda_codec_device_new(), necessary to complete codecs initialization,
happens only when codec-component of hda sound card is being probed.
Denylisting snd_hda_codec_hdmi module causes snd_hda_codec_configure()
to reach: codec_bind_generic() -> is_likely_hdmi_codec() which makes use
of ->wcaps and at this point the it isn't initialized yet - again,
requires completion of snd_hda_codec_device_new().
Tom Rix [Mon, 4 Jul 2022 14:28:36 +0000 (10:28 -0400)]
ALSA: hda/cs8409: change cs8409_fixups v.pins initializers to static
sparse reports
sound/pci/hda/patch_cs8409-tables.c:79:25: warning: symbol 'cs8409_cs42l42_pincfgs_no_dmic' was not declared. Should it be static?
cs8409_cs42l42_pincfgs_no_dmic is only used by cs8409_fixups table as an
initializer for the hda_fixup element v.pins. Both are defined in the
patch_cs8408-table.c file but only cs8409_fixups is used externally in
patch_cs8409.c. So cs8409_cs42l42_pincfgs_no_dmic should have a static
storage class specifier.
The other v.pins initializers in cs8409_fixups table, though declared
extern in patch_cs8409.h are also only used in patch_cs8409-tables.c.
So change all the v.pins initializers to static.
tracing: ALSA: hda: Remove string manipulation out of the fast path
The TRACE_EVENT() macro is broken up into various parts to be efficient.
The TP_fast_assign() is just to record the event into the ring buffer, and
is to be done as fast as possible as this occurs during the actual running
of the code. The slower this is, the slower the code that is being traced
becomes.
The TP_printk() is processed when reading the tracing buffer. This is
considered the slow path. Any processing that can be moved from the
TP_fast_assign() to the TP_printk() should do so.
For some reason, the entire string processing of the trace events
hda_send_cmd, hda_get_response, and hda_unsol_event was moved from the
TP_printk() into the TP_fast_assign(). On top of that, the
__dynamic_array() was used with a fixed size of HDAC_MSG_MAX, which is
useless as a dynamic_array as it will always allocate HDAC_MSG_MAX bytes
on the ring buffer and even save that amount into the event (as it expects
the size to be dynamic, which using a fixed size defeats that purpose).
Instead, just save the necessary elements in the TP_fast_assign() and do
the string manipulation in the slow path.
Colin Ian King [Wed, 29 Jun 2022 10:27:43 +0000 (11:27 +0100)]
ALSA: wavefront: remove redundant assignment to pointer end
Pointer end is being re-assigned the same value as it was initialized
with in the previous statement. The re-assignment is redundant and
can be removed.
Cleans up clang scan-build warning:
sound/isa/wavefront/wavefront_synth.c:582:17: warning: Value stored
to 'end' during its initialization is never read
Jan Schär [Mon, 27 Jun 2022 17:18:55 +0000 (19:18 +0200)]
ALSA: usb-audio: Turn off 'manual mode' on Dell dock
This removes the need to power cycle the Dell WD15 dock if it has been
attached to a Windows machine.
The Windows driver puts the ALC4020 USB audio controller into
'manual mode', and then does all the power management and other
configuration itself, by sending HD audio commands directly to the
ALC3263 audio codec via vendor-type USB messages. If manual mode is off,
this is all handled by the firmware, and works well enough.
If manual mode is turned on, the latency of the SET INTERFACE command
goes from several hundred ms to less than 1 ms
(see https://bugzilla.suse.com/show_bug.cgi?id=1089467), but I'm not
sure if the additional code that would be required is worth it.
Funnily enough, the Windows driver tries to turn off manual mode when
the dock is disconnected, which doesn't work for obvious reasons.
Additionally, fix a bug in dell_dock_init_vol, which didn't work because
the Control Selector was missing.
Now, it properly resets the volume to 0dB.
Jan Schär [Mon, 27 Jun 2022 17:18:54 +0000 (19:18 +0200)]
ALSA: usb-audio: Support jack detection on Dell dock
The Dell WD15 dock has a headset and a line out port. Add support for
detecting if a jack is inserted into one of these ports.
For the headset jack, additionally determine if a mic is present.
The WD15 contains an ALC4020 USB audio controller and ALC3263 audio codec
from Realtek. It is a UAC 1 device, and UAC 1 does not support jack
detection. Instead, jack detection works by sending HD Audio commands over
vendor-type USB messages.
I found out how it works by looking at USB captures on Windows.
The audio codec is very similar to the one supported by
sound/soc/codecs/rt298.c / rt298.h, some constant names and the mic
detection are adapted from there. The realtek_add_jack function is adapted
from build_connector_control in sound/usb/mixer.c.
I tested this on a WD15 dock with the latest firmware.
Merge tag 'asoc-fix-v5.19-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.19
A collection of fixes for v5.19, quite large but nothing major - a good
chunk of it is more stuff that was identified by mixer-test regarding
event generation.
Egor Vorontsov [Mon, 27 Jun 2022 10:00:34 +0000 (13:00 +0300)]
ALSA: usb-audio: Add quirk for Fiero SC-01
Fiero SC-01 is a USB sound card with two mono inputs and a single
stereo output. The inputs are composed into a single stereo stream.
The device uses a vendor-provided driver on Windows and does not work
at all without it. The driver mostly provides ASIO functionality, but
also alters the way the sound card is queried for sample rates and
clocks.
ALSA queries those failing with an EPIPE (same as Windows 10 does).
Presumably, the vendor-provided driver does not query it at all, simply
matching by VID:PID. Thus, I consider this a buggy firmware and adhere
to a set of fixed endpoint quirks instead.
The soundcard has an internal clock. Implicit feedback mode is required
for the playback.
I have updated my device to v1.1.0 from a Windows 10 VM using a vendor-
provided binary prior to the development, hoping for it to just begin
working. The device provides no obvious way to downgrade the firmware,
and regardless, there's no binary available for v1.0.0 anyway.
Thus, I will be getting another unit to extend the patch with support
for that. Expected to be a simple copy-paste of the existing one,
though.
There were no previous reports of that device in context of Linux
anywhere. Other issues have been reported though, but that's out of the
scope.
John Veness [Fri, 24 Jun 2022 14:07:57 +0000 (15:07 +0100)]
ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices
Treat the claimed 96kHz 1ch in the descriptors as 48kHz 2ch, so that
the audio stream doesn't sound mono. Also fix initial stream
alignment, so that left and right channels are in the correct order.
Charles Keepax [Thu, 23 Jun 2022 10:51:19 +0000 (11:51 +0100)]
ASoC: madera: Fix event generation for rate controls
madera_adsp_rate_put always returns zero regardless of if the control
value was updated. This results in missing notifications to user-space
of the control change. Update the handling to return 1 when the
value is changed.
Charles Keepax [Thu, 23 Jun 2022 10:51:18 +0000 (11:51 +0100)]
ASoC: madera: Fix event generation for OUT1 demux
madera_out1_demux_put returns the value of
snd_soc_dapm_mux_update_power, which returns a 1 if a path was found for
the kcontrol. This is obviously different to the expected return a 1 if
the control was updated value. This results in spurious notifications to
user-space. Update the handling to only return a 1 when the value is
changed.
Charles Keepax [Thu, 23 Jun 2022 10:51:17 +0000 (11:51 +0100)]
ASoC: cs47l15: Fix event generation for low power mux control
cs47l15_in1_adc_put always returns zero regardless of if the control
value was updated. This results in missing notifications to user-space
of the control change. Update the handling to return 1 when the value is
changed.
Charles Keepax [Thu, 23 Jun 2022 10:51:16 +0000 (11:51 +0100)]
ASoC: cs35l41: Add ASP TX3/4 source to register patch
The mixer controls for ASP TX3/4 are set to values that are not included
in their enumeration control. This will cause spurious event
notifications when the controls are first changed, as the register value
changes whilst the actual visible enumeration value does not. Use the
register patch to set them to a known value, zero, which equates to zero
fill, thereby avoiding the spurious notifications.
Charles Keepax [Thu, 23 Jun 2022 10:51:15 +0000 (11:51 +0100)]
ASoC: dapm: Initialise kcontrol data for mux/demux controls
DAPM keeps a copy of the current value of mux/demux controls,
however this value is only initialised in the case of autodisable
controls. This leads to false notification events when first
modifying a DAPM kcontrol that has a non-zero default.
Autodisable controls are left as they are, since they already
initialise the value, and there would be more work required to
support autodisable muxes where the first option isn't disabled
and/or that isn't the default.
Technically this issue could affect mixer/switch elements as well,
although not on any of the devices I am currently running. There
is also a little more work to do to address the issue there due to
that side supporting stereo controls, so that has not been tackled
in this patch.
Shuming Fan [Tue, 21 Jun 2022 09:07:19 +0000 (17:07 +0800)]
ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error
The initial settings will be written before the codec probe function.
But, the rt711->component doesn't be assigned yet.
If IO error happened during initial settings operations, it will cause the kernel panic.
This patch changed component->dev to slave->dev to fix this issue.
Judy Hsiao [Wed, 15 Jun 2022 04:56:43 +0000 (04:56 +0000)]
ASoC: rockchip: i2s: switch BCLK to GPIO
We discoverd that the state of BCLK on, LRCLK off and SD_MODE on
may cause the speaker melting issue. Removing LRCLK while BCLK
is present can cause unexpected output behavior including a large
DC output voltage as described in the Max98357a datasheet.
In order to:
1. prevent BCLK from turning on by other component.
2. keep BCLK and LRCLK being present at the same time
This patch switches BCLK to GPIO func before LRCLK output, and
configures BCLK func back during LRCLK is output.
Without this fix, BCLK is turned on 11 ms earlier than LRCK by the
da7219.
With this fix, BCLK is turned on only 0.4 ms earlier than LRCK by
the rockchip codec.
ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states
The IMR was assumed to be preserved when suspending to S4 and S5
states, but community reports invalidate that assumption, the hardware
seems to be powered off and the IMR memory content cleared.
Make sure regular boot with firmware download is used for S4 and S5.
ASoC: SOF: pm: add definitions for S4 and S5 states
We currently don't have a means to differentiate between S3, S4 and
S5. Add definitions so that we have select different code paths
depending on the target state in follow-up patches.
Peter Ujfalusi [Thu, 16 Jun 2022 20:19:53 +0000 (15:19 -0500)]
ASoC: SOF: Intel: hda: Fix compressed stream position tracking
Commit f27850a417a9 ("ASoC: SOF: Intel: hda: add quirks for HDAudio DMA position information")
modified the PCM path only, but left the compressed data patch using an
obsolete option.
Move the functionality in a helper that can be called for both PCM and
compressed data.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Fixes: f27850a417a9 ("ASoC: SOF: Intel: hda: add quirks for HDAudio DMA position information") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220616201953.130876-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Hans de Goede [Sun, 12 Jun 2022 15:56:52 +0000 (17:56 +0200)]
ASoC: Intel: bytcr_wm5102: Fix GPIO related probe-ordering problem
The "wlf,spkvdd-ena" GPIO needed by the bytcr_wm5102 driver
is made available through a gpio-lookup table.
This gpio-lookup table is registered by drivers/mfd/arizona-spi.c, which
may get probed after the bytcr_wm5102 driver.
If the gpio-lookup table has not registered yet then the gpiod_get()
will return -ENOENT. Treat -ENOENT as -EPROBE_DEFER to still keep
things working in this case.
Keyon Jie was a key contributor to the Intel ASoC and SOF Intel
drivers, but he's moved on to a different role within Intel. We wish
him all the best in his new endeavors.
Bard Liao, Kai Vehmanen, Ranjani Sridharan and Peter Ujfalusi have
been involved in the Intel multi-maintainer team, it's time to update
the MAINTAINERS entry to reflect their contributions and clarify their
role.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220610214313.42903-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Fri, 3 Jun 2022 12:25:26 +0000 (14:25 +0200)]
ASoC: wcd938x: Fix event generation for some controls
Currently wcd938x_*_put() unconditionally report that the value of the
control changed, resulting in spurious events being generated. Return 0 in
that case instead as we should. There is still an issue in the compander
control which is a bit more complex.
Mark Brown [Fri, 3 Jun 2022 12:46:09 +0000 (14:46 +0200)]
ASoC: wcd9335: Fix spurious event generation
The slimbus mux put operation unconditionally reports a change in value
which means that spurious events are generated. Fix this by exiting early
in that case.
Yassine Oudjana [Mon, 6 Jun 2022 15:22:26 +0000 (19:22 +0400)]
ASoC: wcd9335: Remove RX channel from old list before adding it to a new one
Currently in slim_rx_mux_put, an RX channel gets added to a new list
even if it is already in one. This can mess up links and make either
it, the new list head, or both, get linked to the wrong entries.
This can cause an entry to link to itself which in turn ends up
making list_for_each_entry in other functions loop infinitely.
To avoid issues, always remove the RX channel from any list it's in
before adding it to a new list.
Commit a299af034fc6 ("ASoC: remove codec hw_write/control_data") removed
use of hw_write_t in struct snd_soc_codec, but it left type definition.
Fully clean it up.
Peter Ujfalusi [Fri, 10 Jun 2022 08:47:35 +0000 (11:47 +0300)]
ASoC: SOF: ipc3-topology: Move and correct size checks in sof_ipc3_control_load_bytes()
Move the size checks prior to allocating memory as these checks do not need
the data to be allocated and in case of an error we would not need to free
the allocation.
The max size must not be less than the size of
struct sof_ipc_ctrl_data + struct sof_abi_hdr as the ABI header needs to
be present under all circumstances.
The check was incorrectly used or between the two size checks.
Fixes: 806f4f0b3d81 ("ASoC: SOF: topology: Make control parsing IPC agnostic") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220610084735.19397-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Thu, 9 Jun 2022 08:59:49 +0000 (11:59 +0300)]
ASoC: SOF: Intel: hda-loader: Clarify the cl_dsp_init() flow
Update the comment for the cl_dsp_init() to clarify what is done by the
function and use the chip->init_core_mask instead of BIT(0) when
unstalling/running the init core.
Peter Ujfalusi [Thu, 9 Jun 2022 08:59:48 +0000 (11:59 +0300)]
ASoC: SOF: Intel: hda-loader: Make sure that the fw load sequence is followed
The hda_dsp_enable_core() is powering up _and_ unstall the core in one
call while the first step of the firmware loading must not unstall the
core.
The core can be unstalled only after the set cpb_cfp and the configuration
of the IPC register for the ROM_CONTROL message.
The hda_dsp_core_power_up() needs to be exposed so that it can be used in
hda-loader.c to correct the boot flow.
The first step must not unstall the core, it should only power up the
core(s).
Add sanity check for the core_mask while exposing it to be safe.
ASoC: ak4613: cares Simple-Audio-Card case for TDM
Renesas is the only user of ak4613 on upstream for now, and
commit 1a0c74e5e05745 ("ASoC: ak4613: add TDM256 support")
added TDM256 support. Renesas tested part of it, because of
board connection.
It was assuming ak4613 is probed via Audio-Graph-Card, but it
might be probed via Simple-Audio-Card either.
It will indicates WARNING in such case. This patch fixup it.
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/87h74v29f7.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: codecs: rt700/rt711/rt711-sdca: resume bus/codec in .set_jack_detect
The .set_jack_detect() codec component callback is invoked during card
registration, which happens when the machine driver is probed.
The issue is that this callback can race with the bus suspend/resume,
and IO timeouts can happen. This can be reproduced very easily if the
machine driver is 'blacklisted' and manually probed after the bus
suspends. The bus and codec need to be re-initialized using pm_runtime
helpers.
Previous contributions tried to make sure accesses to the bus during
the .set_jack_detect() component callback only happen when the bus is
active. This was done by changing the regcache status on a component
remove. This is however a layering violation, the regcache status
should only be modified on device probe, suspend and resume. The
component probe/remove should not modify how the device regcache is
handled. This solution also didn't handle all the possible race
conditions, and the RT700 headset codec was not handled.
This patch tries to resume the codec device before handling the jack
initializations. In case the codec has not yet been initialized,
pm_runtime may not be enabled yet, so we don't squelch the -EACCES
error code and only stop the jack information. When the codec reports
as attached, the jack initialization will proceed as usual.
ASoC: codecs: rt700/rt711/rt711-sdca: initialize workqueues in probe
The workqueues are initialized in the io_init functions, which isn't
quite right. In some tests, this leads to warnings throw from
__queue_delayed_work()
Realtek headset codec drivers typically check if the card is
instantiated before proceeding with the jack detection.
The rt700, rt711 and rt711-sdca are however missing a check on the
card pointer, which can lead to NULL dereferences encountered in
driver bind/unbind tests.
ASoC: Intel: sof_sdw: handle errors on card registration
If the card registration fails, typically because of deferred probes,
the device properties added for headset codecs are not removed, which
leads to kernel oopses in driver bind/unbind tests.
We already clean-up the device properties when the card is removed,
this code can be moved as a helper and called upon card registration
errors.
A quick check in the code shows that the 'calibrate_mutex' used by
this driver are not initialized at probe time. Moving the
initialization to the probe removes the issue.
Takashi Iwai [Fri, 24 Jun 2022 10:11:32 +0000 (12:11 +0200)]
ALSA: usb-audio: Workarounds for Behringer UMC 204/404 HD
Both Behringer UMC 202 HD and 404 HD need explicit quirks to enable
the implicit feedback mode and start the playback stream primarily.
The former seems fixing the stuttering and the latter is required for
a playback-only case.
Note that the "clock source 41 is not valid" error message still
appears even after this fix, but it should be only once at probe.
The reason of the error is still unknown, but this seems to be mostly
harmless as it's a one-off error and the driver retires the clock
setup and it succeeds afterwards.
Takashi Iwai [Tue, 21 Jun 2022 12:00:44 +0000 (14:00 +0200)]
ALSA: hda: Fix discovery of i915 graphics PCI device
It's been reported that the recent fix for skipping the
component-binding with D-GPU caused a regression on some systems; it
resulted in the completely missing component binding with i915 GPU.
The problem was the use of pci_get_class() function. It matches with
the full PCI class bits, while we want to match only partially the PCI
base class bits. So, when a system has an i915 graphics device with
the PCI class 0380, it won't hit because we're looking for only the
PCI class 0300.
This patch fixes i915_gfx_present() to look up each PCI device and
match with PCI base class explicitly instead of pci_get_class().
Takashi Iwai [Mon, 20 Jun 2022 10:40:08 +0000 (12:40 +0200)]
ALSA: hda/via: Fix missing beep setup
Like the previous fix for Conexant codec, the beep_nid has to be set
up before calling snd_hda_gen_parse_auto_config(); otherwise it'd miss
the path setup.
Fix the call order for addressing the missing beep setup.
Takashi Iwai [Mon, 20 Jun 2022 10:40:07 +0000 (12:40 +0200)]
ALSA: hda/conexant: Fix missing beep setup
Currently the Conexant codec driver sets up the beep NID after calling
snd_hda_gen_parse_auto_config(). It turned out that this results in
the insufficient setup for the beep control, as the generic parser
handles the fake path in snd_hda_gen_parse_auto_config() only if the
beep_nid is set up beforehand.
For dealing with the beep widget properly, call cx_auto_parse_beep()
before snd_hda_gen_parse_auto_config() call.
Takashi Iwai [Fri, 17 Jun 2022 14:40:51 +0000 (16:40 +0200)]
ALSA: rawmidi: Take buffer refcount while draining output
Although snd_rawmidi_drain_output() may take some long time, it has no
protection and intrusive operations like the buffer resize may happen
meanwhile. For making the operation a bit more robust, this patch
takes the buffer refcount for blocking the buffer resize.
Also, as this function is exported, in theory, it might be called
asynchronously from the stream open/close state. For avoiding the
missing refcount, now the close call checks the buffer refcount, too.
Takashi Iwai [Fri, 17 Jun 2022 14:40:50 +0000 (16:40 +0200)]
ALSA: rawmidi: Check stream state at exported functions
The rawmidi interface provides some exported functions to be called
from outside, and currently there is no state check for those calls
whether the stream is properly opened and running. Although such an
invalid call shouldn't happen, but who knows.
This patch adds the proper rawmidi stream state checks with spinlocks
for avoiding unexpected accesses when such exported functions are
called in an invalid state. After this patch, with the
substream->opened and substream->runtime are always tied and
guaranteed to be set under substream->lock.
Takashi Iwai [Fri, 17 Jun 2022 14:40:49 +0000 (16:40 +0200)]
ALSA: rawmidi: Take open_mutex around parameter changes
The input/output parameter changes are pretty intrusive, possibly
involving with the buffer resizing operation. Hence those should be
performed exclusively; otherwise some ugly race could happen.
This patch puts the existing open_mutex for snd_rawmidi_input_params()
and *_output_params() for protecting the concurrent calls. Since
those are exported, it's also meant for hardening from the external
calls, too.
Takashi Iwai [Fri, 17 Jun 2022 14:40:48 +0000 (16:40 +0200)]
ALSA: rawmidi: Move lock to snd_rawmidi_substream
Having a lock in snd_rawmidi_runtime can be a problem especially when
a substream is accessed from the outside, as the runtime creation
might be racy with the external calls. As a first step for hardening,
move the spinlock from snd_rawmidi_runtime to snd_rawmidi_substream.
This patch just replaces the lock calls, no real functional change is
put yet.
Takashi Iwai [Mon, 20 Jun 2022 07:34:40 +0000 (09:34 +0200)]
ALSA: memalloc: Drop x86-specific hack for WC allocations
The recent report for a crash on Haswell machines implied that the
x86-specific (rather hackish) implementation for write-cache memory
buffer allocation in ALSA core is buggy with the recent kernel in some
corner cases. This patch drops the x86-specific implementation and
uses the standard dma_alloc_wc() & co generically for avoiding the bug
and also for simplification.
ALSA: x86: intel_hdmi_audio: enable pm_runtime and set autosuspend delay
The existing code uses pm_runtime_get_sync/put_autosuspend, but
pm_runtime was not explicitly enabled. The autosuspend delay was not
set either, the value is set to 5s since HDMI is rather painful to
resume.
ALSA: hda: intel-dspcfg: use SOF for UpExtreme and UpExtreme11 boards
The UpExtreme BIOS reports microphones that are not physically
present, so this module ends-up selecting SOF, while the UpExtreme11
BIOS does not report microphones so the snd-hda-intel driver is
selected.
For consistency use SOF unconditionally in autodetection mode. The use
of the snd-hda-intel driver can still be enabled with
'options snd-intel-dspcfg dsp_driver=1'
Takashi Iwai [Thu, 9 Jun 2022 12:02:19 +0000 (14:02 +0200)]
ALSA: control: Add input validation
This patch adds a new feature to enable the validation of input data
to control elements in the ALSA core side. When
CONFIG_SND_CTL_INPUT_VALIDATION is set, ALSA core verifies whether the
each input value via control API is in the defined ranges, also checks
whether it's aligned to the defined steps. If an invalid value is
detected, ALSA core returns -EINVAL error immediately without passing
further to the driver's callback. So this is a kind of hardening for
(badly written) drivers that have no proper error checks, at the cost
of a slight performance overhead.
Technically seen, this reuses a part of the existing validation code
for CONFIG_SND_CTL_DEBUG case with a slight modification to suppress
error prints for the input validation.
Takashi Iwai [Thu, 9 Jun 2022 12:02:17 +0000 (14:02 +0200)]
ALSA: control: Rename CONFIG_SND_CTL_VALIDATION to CONFIG_SND_CTL_DEBUG
The purpose of CONFIG_SND_CTL_VALIDATION is rather to enable the
debugging feature for the control API. The validation is only a part
of it. Let's rename it to be more explicit and intuitive.
While we're at it, let's advertise, give more comment to recommend
this feature for development in the kconfig help text.
Takashi Iwai [Fri, 10 Jun 2022 06:45:37 +0000 (08:45 +0200)]
ALSA: control: Use xarray for faster lookups
The control elements are managed in a single linked list and we
traverse the whole list for matching each numid or ctl id per every
inquiry of a control element. This is OK-ish for a small number of
elements but obviously it doesn't scale. Especially the matching with
the ctl id takes time because it checks each field of the snd_ctl_id
element, e.g. the name string is matched with strcmp().
This patch adds the hash tables with Xarray for improving the lookup
speed of a control element. There are two xarray tables added to the
card; one for numid and another for ctl id. For the numid, we use the
numid as the index, while for the ctl id, we calculate a hash key.
The lookup is done via a single xa_load() execution. As long as the
given control element is found on the Xarray table, that's fine, we
can give back a quick lookup result. The problem is when no entry
hits on the table, and for this case, we have a slight optimization.
Namely, the driver checks whether we had a collision on Xarray table,
and do a fallback search (linear lookup of the full entries) only if a
hash key collision happened beforehand.
So, in theory, the inquiry for a non-existing element might take still
time even with this patch in a worst case, but this must be pretty
rare.
The feature is enabled via CONFIG_SND_CTL_FAST_LOOKUP, which is turned
on as default. For simplicity, the option can be turned off only when
CONFIG_EXPERT is set ("You are expert? Then you manage 1000 knobs").
Takashi Iwai [Tue, 14 Jun 2022 05:48:31 +0000 (07:48 +0200)]
ALSA: hda/realtek: Apply fixup for Lenovo Yoga Duet 7 properly
It turned out that Lenovo shipped two completely different products
with the very same PCI SSID, where both require different quirks;
namely, Lenovo C940 has already the fixup for its speaker
(ALC298_FIXUP_LENOVO_SPK_VOLUME) with the PCI SSID 17aa:3818, while
Yoga Duet 7 has also the very same PCI SSID but requires a different
quirk, ALC287_FIXUP_YOGA7_14TIL_SPEAKERS.
Fortunately, both are with different codecs (C940 with ALC298 and Duet
7 with ALC287), hence we can apply different fixes by checking the
codec ID. This patch implements that special fixup function.
For easier handling, the internal function for applying a specific
fixup entry is exported as __snd_hda_apply_fixup(), so that it can be
called from the codec driver. The rest is simply calling it with a
different fixup ID depending on the codec ID.
Kailang Yang [Mon, 13 Jun 2022 06:57:19 +0000 (14:57 +0800)]
ALSA: hda/realtek - ALC897 headset MIC no sound
There is not have Headset Mic verb table in BIOS default.
So, it will have recording issue from headset MIC.
Add the verb table value without jack detect. It will turn on Headset Mic.
projects / kernel.git / log