- 09 Jul, 2022 5 commits
-
-
Amadeusz Sławiński authored
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. Signed-off-by:
Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by:
Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220706120230.427296-8-cezary.rojewski@intel.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Cezary Rojewski authored
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. Signed-off-by:
-
Cezary Rojewski authored
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. Signed-off-by:
-
Cezary Rojewski authored
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. Signed-off-by:
-
Cezary Rojewski authored
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(). Signed-off-by:
-
- 05 Jul, 2022 2 commits
-
-
Jan Schär authored
Fixes: 4b8ea38f ("ALSA: usb-audio: Support jack detection on Dell dock") Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/202207051932.qUilU0am-lkp@intel.comSigned-off-by:
Jan Schär <jan@jschaer.ch> Link: https://lore.kernel.org/r/20220705135746.13713-1-jan@jschaer.chSigned-off-by:
-
Tom Rix authored
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. Fixes: 9e7647b5 ("ALSA: hda/cs8409: Move arrays of configuration to a new file") Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220704142836.636204-1-trix@redhat.comSigned-off-by:
-
- 04 Jul, 2022 10 commits
-
-
Steven Rostedt (Google) authored
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. The output should be the same. Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20220703110605.07a86fb2@rorschach.local.homeSigned-off-by:
-
Colin Ian King authored
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 Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220629102744.139673-1-colin.i.king@gmail.comSigned-off-by:
-
Jan Schär authored
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. Fixes: 964af639 ("ALSA: usb-audio: Initialize Dell Dock playback volumes") Signed-off-by:
-
Jan Schär authored
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. Signed-off-by:
-
Takashi Iwai authored
Back-merge of 5.19-rc branch for the futher development, mainly about USB-audio and HD-audio Cirrus stuff. Signed-off-by: -
Takashi Iwai authored
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 authored
The patch applies the same quirks used for SC-01 at firmware v1.1.0 to the ones running v1.0.0, with respect to hard-coded sample rates. I got two more units and successfully tested the patch series with both firmwares. The support is now complete (not accounting ASIO). Signed-off-by:
Egor Vorontsov <sdoregor@sdore.me> Link: https://lore.kernel.org/r/20220627100041.2861494-2-sdoregor@sdore.meSigned-off-by:
-
Egor Vorontsov authored
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. Signed-off-by:
-
Tim Crawford authored
Fixes headset detection on Clevo L140PU. Signed-off-by:
Tim Crawford <tcrawford@system76.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220624144109.3957-1-tcrawford@system76.comSigned-off-by:
-
John Veness authored
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. Signed-off-by:
John Veness <john-linux@pelago.org.uk> Link: https://lore.kernel.org/r/20220624140757.28758-1-john-linux@pelago.org.ukSigned-off-by:
-
- 24 Jun, 2022 23 commits
-
-
Charles Keepax authored
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. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220623105120.1981154-5-ckeepax@opensource.cirrus.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
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. Signed-off-by:
-
Charles Keepax authored
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. Signed-off-by:
-
Charles Keepax authored
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. Signed-off-by:
-
Charles Keepax authored
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. Signed-off-by:
-
Shuming Fan authored
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. Signed-off-by:
Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20220621090719.30558-1-shumingf@realtek.comSigned-off-by:
-
Charles Keepax authored
Various boolean controls on cs35l41 are missing the required "Switch" in the name, add these. Signed-off-by:
-
Charles Keepax authored
The DRE controls on wm5110 should return a value of 1 if the DRE state is actually changed, update to fix this. Signed-off-by:
-
Charles Keepax authored
The preloader controls on ADSP should return a value of 1 if the preloader value was changed, update to correct this. Signed-off-by:
-
Srinivas Kandagatla authored
Update Banajit's email address from codeaurora.org to quicinc.com, as codeaurora.org is not in use anymore. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220617210230.7685-1-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Judy Hsiao authored
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. Signed-off-by:
Judy Hsiao <judyhsiao@chromium.org> Link: https://lore.kernel.org/r/20220615045643.3137287-1-judyhsiao@chromium.orgSigned-off-by:
-
Pierre-Louis Bossart authored
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. BugLink: https://github.com/thesofproject/sof/issues/5892 Fixes: 5fb5f511 ("ASoC: SOF: Intel: hda-loader: add IMR restore support") Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@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/20220616201818.130802-4-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Pierre-Louis Bossart authored
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. Signed-off-by:
-
Pierre-Louis Bossart authored
The existing code only deals with S0 and S3, let's start adding S1 and S2. No functional change. Signed-off-by:
-
Peter Ujfalusi authored
Commit 288fad2f ("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:
-
Dan Carpenter authored
This should return PTR_ERR() instead of IS_ERR(). Fixes: e0100bfd ("ASoC: SOF: mediatek: Add mt8186 ipc support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
Hans de Goede authored
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. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Pierre-Louis Bossart authored
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:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
-
Mark Brown authored
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. Signed-off-by:
-
Mark Brown authored
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. Signed-off-by:
-
Yassine Oudjana authored
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. Signed-off-by:
Yassine Oudjana <y.oudjana@protonmail.com> Link: https://lore.kernel.org/r/20220606152226.149164-1-y.oudjana@protonmail.comSigned-off-by:
-
Srinivas Kandagatla authored
prepare callback can be called multiple times, so unprepare the stream if its already prepared. Without this DSP is not happy to setting the params on a already prepared graph. Fixes: 9b4fe0f1 ("ASoC: qdsp6: audioreach: add q6apm-dai support") Reported-by:
Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Signed-off-by:
-
Amadeusz Sławiński authored
Commit 81da8a0b ("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. Fixes: 81da8a0b ("ASoC: remove codec hw_write/control_data") Signed-off-by:
-
