- 23 Mar, 2021 5 commits
-
-
Libin Yang authored
According to hardware spec and PMC FW requirement, the DSP must be in D3 state before entering S5. Set shutdown call to hda_dsp_shutdown. Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
Libin Yang <libin.yang@intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-6-pierre-louis.bossart@linux.intel.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Libin Yang authored
According to hardware spec and PMC FW requirement, the DSP must be in D3 state before entering S5. Define the shutdown function to use snd_sof_suspend as shutdown callback to make sure DSP is in D3 state. Fixes: 44a4cfad ("ASoC: SOF: Intel: tgl: do thorough remove at .shutdown() callback") Reviewed-by:
Pan Xiuli <xiuli.pan@linux.intel.com> Signed-off-by:
-
Libin Yang authored
EHL is derived from TGL, not CNL, so we shall use the TGL ops. Fixes: 8d4ba1be ("ASoC: SOF: pci: split PCI into different drivers") Reviewed-by:
-
Pierre-Louis Bossart authored
When the probe is handled in a workqueue, we must use cancel_work_sync() in the shutdown helper to avoid possible race conditions. We must also take care of possible errors happening in a probe workqueue or during pm_runtime resume (called e.g. before shutdown for PCI devices). We should really only try to access hardware registers and initiate IPCs if the DSP is fully booted. Fixes: daff7f14 ("ASoC: SOF: add snd_sof_device_shutdown() helper for shutdown") Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
-
Guennadi Liakhovetski authored
When checking for enabled cores it isn't enough to check that some of the requested cores are running, we have to check that all of them are. Fixes: 747503b1 ("ASoC: SOF: Intel: Add Intel specific HDA DSP HW operations") Reviewed-by:
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by:
-
- 16 Mar, 2021 5 commits
-
-
Mark Brown authored
Merge series "Do not handle MCLK device clock in simple-card-utils" from Sameer Pujar <spujar@nvidia.com>: With commit 1e30f642 ("ASoC: simple-card-utils: Fix device module clock") simple-card-utils can control MCLK clock for rate updates or enable/disable. But this is breaking some platforms where it is expected that codec drivers would actually handle the MCLK clock. One such example is following platform. - "arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts" In above case codec, wm8904, is using internal PLL and configures sysclk based on fixed MCLK input. In such cases it is expected that, required PLL output or sysclk, is just passed via set_sysclk() callback and card driver need not actually update MCLK rate. Instead, codec can take ownership of this clock and do the necessary configuration. So the original commit is reverted and codec driver for rt5659 is updated to fix my board which has this codec. Sameer Pujar (2): ASoC: simple-card-utils: Do not handle device clock ASoC: rt5659: Update MCLK rate in set_sysclk() sound/soc/codecs/rt5659.c | 5 +++++ sound/soc/generic/simple-card-utils.c | 13 +++++++------ 2 files changed, 12 insertions(+), 6 deletions(-) -- 2.7.4
-
Shengjiu Wang authored
Add compatible string for new added platforms which support spdif module. They are i.MX8QXP, i.MX8MM, i.MX8MN, i.MX8MQ. Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1615884053-4264-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by:
-
Bard Liao authored
We do some IO operations in the snd_soc_component_set_jack callback function and snd_soc_component_set_jack() will be called when soc component is removed. However, we should not access SoundWire registers when the bus is suspended. So set regcache_cache_only(regmap, true) to avoid accessing in the soc component removal process. Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20210316005254.29699-1-yung-chuan.liao@linux.intel.comSigned-off-by:
-
Sameer Pujar authored
Simple-card/audio-graph-card drivers do not handle MCLK clock when it is specified in the codec device node. The expectation here is that, the codec should actually own up the MCLK clock and do necessary setup in the driver. Suggested-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1615829492-8972-3-git-send-email-spujar@nvidia.comSigned-off-by:
-
Sameer Pujar authored
This reverts commit 1e30f642 ("ASoC: simple-card-utils: Fix device module clock"). The original patch ended up breaking following platform, which depends on set_sysclk() to configure internal PLL on wm8904 codec and expects simple-card-utils to not update the MCLK rate. - "arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts" It would be best if codec takes care of setting MCLK clock via DAI set_sysclk() callback. Reported-by:
-
- 12 Mar, 2021 1 commit
-
-
Jiaxin Yu authored
This patch correct tdm out bck inverse register to AUDIO_TOP_CON3[3]. Signed-off-by:
Jiaxin Yu <jiaxin.yu@mediatek.com> Link: https://lore.kernel.org/r/1615516005-781-1-git-send-email-jiaxin.yu@mediatek.comSigned-off-by:
-
- 11 Mar, 2021 2 commits
-
-
Srinivasa Rao Mandadapu authored
The max boundary check while parsing dai ids makes sound card registration fail after common up dai ids. Fixes: cd3484f7 ("ASoC: qcom: Fix broken support to MI2S TERTIARY and QUATERNARY") Signed-off-by:
Srinivasa Rao Mandadapu <srivasam@codeaurora.org> Link: https://lore.kernel.org/r/20210311154557.24978-1-srivasam@codeaurora.orgSigned-off-by:
-
Meng Li authored
When initialize cadence qspi controller, it is need to set cqspi to the driver_data field of struct device, because it will be used in function cqspi_remove/suspend/resume(). Otherwise, there will be a crash trace as below when invoking these finctions. Fixes: 31fb632b ("spi: Move cadence-quadspi driver to drivers/spi/") Cc: stable@vger.kernel.org Signed-off-by:
Meng Li <Meng.Li@windriver.com> Link: https://lore.kernel.org/r/20210311091220.3615-1-Meng.Li@windriver.comSigned-off-by:
-
- 10 Mar, 2021 27 commits
-
-
Mark Brown authored
Merge series "ASoC: sdm845: array out of bound issues" from Srinivas Kandagatla <srinivas.kandagatla@linaro.org>: During testing John Stultz and Amit reported few array our bound issues after enabling bound sanitizer This patch series attempts to fix those! changes since v1: - make sure the wcd is not de-referenced without intialization Srinivas Kandagatla (3): ASoC: qcom: sdm845: Fix array out of bounds access ASoC: qcom: sdm845: Fix array out of range on rx slim channels ASoC: codecs: wcd934x: add a sanity check in set channel map sound/soc/codecs/wcd934x.c | 6 ++++++ sound/soc/qcom/sdm845.c | 6 +++--- 2 files changed, 9 insertions(+), 3 deletions(-) -- 2.21.0
-
Pan Xiuli authored
The ADSPCS_SPA is Set Power Active bit. To check if DSP is powered down, we need to check ADSPCS_CPA, the Current Power Active bit. Fixes: 747503b1 ("ASoC: SOF: Intel: Add Intel specific HDA DSP HW operations") Reviewed-by:
-
Srinivas Kandagatla authored
set channel map can be passed with a channel maps, however if the number of channels that are passed are more than the actual supported channels then we would be accessing array out of bounds. So add a sanity check to validate these numbers! Fixes: a61f3b4f ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec") Reported-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210309142129.14182-4-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Srinivas Kandagatla authored
WCD934x has only 13 RX SLIM ports however we are setting it as 16 in set_channel_map, this will lead to array out of bounds error! Orignally caught by enabling USBAN array out of bounds check: Fixes: 5caf64c6 ("ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga") Reported-by:
-
Srinivas Kandagatla authored
Static analysis Coverity had detected a potential array out-of-bounds write issue due to the fact that MAX AFE port Id was set to 16 instead of using AFE_PORT_MAX macro. Fix this by properly using AFE_PORT_MAX macro. Fixes: 1b93a884 ("ASoC: qcom: sdm845: handle soundwire stream") Reported-by:
-
Mark Brown authored
Merge series "Report jack and button detection + Capture Support" from Lucas Tanure <tanureal@opensource.cirrus.com>: Hi All, Here is a patch series for reporting to user space jack and button events and add the support for Capture. With some cleanups and fixes along the way. Regards, Lucas Tanure Lucas Tanure (12): ASoC: cs42l42: Fix Bitclock polarity inversion ASoC: cs42l42: Fix channel width support ASoC: cs42l42: Fix mixer volume control ASoC: cs42l42: Don't enable/disable regulator at Bias Level ASoC: cs42l42: Always wait at least 3ms after reset ASoC: cs42l42: Remove power if the driver is being removed ASoC: cs42l42: Disable regulators if probe fails ASoC: cs42l42: Provide finer control on playback path ASoC: cs42l42: Set clock source for both ways of stream ASoC: cs42l42: Add Capture Support ASoC: cs42l42: Report jack and button detection ASoC: cs42l42: Use bclk from hw_params if set_sysclk was not called Richard Fitzgerald (3): ASoC: cs42l42: Wait at least 150us after writing SCLK_PRESENT ASoC: cs42l42: Only start PLL if it is needed ASoC: cs42l42: Wait for PLL to lock before switching to it sound/soc/codecs/cs42l42.c | 437 +++++++++++++++++++++---------------- sound/soc/codecs/cs42l42.h | 41 +++- 2 files changed, 282 insertions(+), 196 deletions(-) -- 2.30.1
-
Peter Robinson authored
In 61fbeb5d the sirf prima/atlas drivers were removed. This cleans up a stray header and some Kconfig entries for the codec that were missed in the process. Fixes: 61fbeb5d (ASoC: remove sirf prima/atlas drivers) Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mark Brown <broonie@kernel.org> Acked-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210307162338.1160604-1-pbrobinson@gmail.comSigned-off-by:
-
Jonathan Marek authored
Attempting to use the RX MIX path at 48kHz plays at 96kHz, because these controls are incorrectly toggling the first bit of the register, which is part of the FS_RATE field. Fix the problem by using the same method used by the "WSA RX_MIX EC0_MUX" control, which is to use SND_SOC_NOPM as the register and use an enum in the shift field instead. Fixes: 2c4066e5 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Signed-off-by:
Jonathan Marek <jonathan@marek.ca> Reviewed-by:
-
Jonathan Marek authored
An interface can have multiple decimators enabled, so loop over all active decimators. Otherwise only one channel will be unmuted, and other channels will be zero. This fixes recording from dual DMIC as a single two channel stream. Also remove the now unused "active_decimator" field. Fixes: 908e6b1d ("ASoC: codecs: lpass-va-macro: Add support to VA Macro") Signed-off-by:
-
Lucas Tanure authored
This delay is part of the power-up sequence defined in the datasheet. A runtime_resume is a power-up so must also include the delay. Signed-off-by:
Lucas Tanure <tanureal@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210305173442.195740-6-tanureal@opensource.cirrus.comSigned-off-by:
-
Lucas Tanure authored
dev_pm_ops already enable/disable the codec if not in use Signed-off-by:
-
Lucas Tanure authored
The minimum value is 0x3f (-63dB), which also is mute Signed-off-by:
-
Lucas Tanure authored
Remove the hard coded 32 bits width and replace with the correct width calculated by params_width. Signed-off-by:
-
Lucas Tanure authored
The driver was setting bit clock polarity opposite to intended polarity. Also simplify the code by grouping ADC and DAC clock configurations into a single field. Signed-off-by:
-
Jon Hunter authored
Many systems do not use ACPI and hence do not provide a DMI table. On non-ACPI systems a warning, such as the following, is printed on boot. WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name! The variable 'dmi_available' is not exported and so currently cannot be used by kernel modules without adding an accessor. However, it is possible to use the function is_acpi_device_node() to determine if the sound card is an ACPI device and hence indicate if we expect a DMI table to be present. Therefore, call is_acpi_device_node() to see if we are using ACPI and only parse the DMI table if we are booting with ACPI. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20210303115526.419458-1-jonathanh@nvidia.comSigned-off-by:
-
Pierre-Louis Bossart authored
We only unregister the platform device during the .remove operation, but if the probe fails we will never reach this sequence. Suggested-by:
-
Mark Brown authored
Hi All, Here is a series of rt5640/rt5651 volume-control fixes which I wrote while working on a bytcr-rt5640 UCM profile patch-series adding hardware-volume control to devices using this UCM profile. The UCM series will also work on older kernels, but it works best on kernels with this series applied, giving e.g. finer grained volume control and support for hardware muting the outputs. Regards, Hans Hans de Goede (5): ASoC: rt5640: Fix dac- and adc- vol-tlv values being off by a factor of 10 ASoC: rt5651: Fix dac- and adc- vol-tlv values being off by a factor of 10 ASoC: rt5640: Add emulated 'DAC1 Playback Switch' control ASoC: rt5640: Rename 'Mono DAC Playback Volume' to 'DAC2 Playback Volume' ASoC: Intel: bytcr_rt5640: Add used AIF to the components string sound/soc/codecs/rt5640.c | 106 +++++++++++++++++++++++--- sound/soc/codecs/rt5640.h | 4 + sound/soc/codecs/rt5651.c | 4 +- sound/soc/intel/boards/bytcr_rt5640.c | 11 ++- 4 files changed, 111 insertions(+), 14 deletions(-) -- 2.30.1 -
Hans de Goede authored
Most steps in this table are steps of 3dB (300 centi-dB), so we can simplify the table. This not only reduces the amount of space it takes inside the kernel, this also makes alsa-lib's mixer code actually accept the table, where as before this change alsa-lib saw the "ADC PGA Gain" control as a control without a dB scale. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210228160441.241110-1-hdegoede@redhat.comSigned-off-by:
-
Benjamin Rood authored
According to the SGTL5000 datasheet [1], the DAP_AVC_CTRL register has the following bit field definitions: | BITS | FIELD | RW | RESET | DEFINITION | | 15 | RSVD | RO | 0x0 | Reserved | | 14 | RSVD | RW | 0x1 | Reserved | | 13:12 | MAX_GAIN | RW | 0x1 | Max Gain of AVC in expander mode | | 11:10 | RSVD | RO | 0x0 | Reserved | | 9:8 | LBI_RESP | RW | 0x1 | Integrator Response | | 7:6 | RSVD | RO | 0x0 | Reserved | | 5 | HARD_LMT_EN | RW | 0x0 | Enable hard limiter mode | | 4:1 | RSVD | RO | 0x0 | Reserved | | 0 | EN | RW | 0x0 | Enable/Disable AVC | The original default value written to the DAP_AVC_CTRL register during sgtl5000_i2c_probe() was 0x0510. This would incorrectly write values to bits 4 and 10, which are defined as RESERVED. It would also not set bits 12 and 14 to their correct RESET values of 0x1, and instead set them to 0x0. While the DAP_AVC module is effectively disabled because the EN bit is 0, this default value is still writing invalid values to registers that are marked as read-only and RESERVED as well as not setting bits 12 and 14 to their correct default values as defined by the datasheet. The correct value that should be written to the DAP_AVC_CTRL register is 0x5100, which configures the register bits to the default values defined by the datasheet, and prevents any writes to bits defined as 'read-only'. Generally speaking, it is best practice to NOT attempt to write values to registers/bits defined as RESERVED, as it generally produces unwanted/undefined behavior, or errors. Also, all credit for this patch should go to my colleague Dan MacDonald <dmacdonald@curbellmedical.com> for finding this error in the first place. [1] https://www.nxp.com/docs/en/data-sheet/SGTL5000.pdfSigned-off-by:
Benjamin Rood <benjaminjrood@gmail.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20210219183308.GA2117@ubuntu-devSigned-off-by:
-
Hans de Goede authored
The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale. E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer. Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize. Note this mirrors commit 3f31f7d9 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver. Signed-off-by:
-
Hans de Goede authored
The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale. E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer. Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize. Note this mirrors commit 3f31f7d9 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver. Signed-off-by:
-
Hans de Goede authored
When I added the quirk for the "HP Pavilion x2 10-p0XX" I copied the byt_rt5640_quirk_table[] entry for the HP Pavilion x2 10-k0XX / 10-n0XX models since these use almost the same settings. While doing this I accidentally also copied and kept the non-standard OVCD_TH_1500UA setting used on those models. This too low threshold is causing headsets to often be seen as headphones (without a headset-mic) and when correctly identified it is causing ghost play/pause button-presses to get detected. Correct the HP Pavilion x2 10-p0XX quirk to use the default OVCD_TH_2000UA setting, fixing these problems. Fixes: fbdae7d6 ("ASoC: Intel: bytcr_rt5640: Fix HP Pavilion x2 Detachable quirks") Signed-off-by:
-
Mark Brown authored
Hi All, While working on adding hardware-volume control support to the UCM profile for the rt5672 and on adding LED trigger support to the rt5670 codec driver. I hit / noticed a couple of issues this series fixes these issues. Regards, Hans Hans de Goede (4): ASoC: rt5670: Remove 'OUT Channel Switch' control ASoC: rt5670: Remove 'HP Playback Switch' control ASoC: rt5670: Remove ADC vol-ctrl mute bits poking from Sto1 ADC mixer settings ASoC: rt5670: Add emulated 'DAC1 Playback Switch' control sound/soc/codecs/rt5670.c | 110 +++++++++++++++++++++++++++++++++----- sound/soc/codecs/rt5670.h | 9 ++-- 2 files changed, 101 insertions(+), 18 deletions(-) -- 2.30.1 -
Shengjiu Wang authored
Add missed MODULE_DEVICE_TABLE for the driver can be loaded automatically at boot. Fixes: 92088477 ("ASoC: ak5558: Add support for AK5558 ADC driver") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Shengjiu Wang authored
Add missed MODULE_DEVICE_TABLE for the driver can be loaded automatically at boot. Fixes: 08660086 ("ASoC: ak4458: Add support for AK4458 DAC driver") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hans de Goede authored
For reliable output-mute LED control we need a "DAC1 Playback Switch" control. The "DAC Playback volume" control is the only control in the path from the DAC1 data input to the speaker output, so the UCM profile for the speaker output will have its PlaybackMixerElem set to "DAC1". But userspace (pulseaudio) will set the "DAC1 Playback Volume" control to its softest setting (which is not fully muted) while still showing the speaker as being enabled at a low volume in the UI. If we were to set the SNDRV_CTL_ELEM_ACCESS_SPK_LED on the "DAC1 Playback Volume" control, this would mean then what pressing KEY_VOLUMEDOWN the speaker-mute LED (embedded in the volume-mute toggle key) would light while the UI is still showing the speaker as being enabled at a low volume, meaning that the UI and the LED are out of sync. Only after an _extra_ KEY_VOLUMEDOWN press would the UI show the speaker as being muted. The path from DAC1 data input to the speaker output does have a digital mixer with DAC1's data as one of its inputs direclty after the "DAC1 Playback Volume" control. This commit adds an emulated "DAC1 Playback Switch" control by: 1. Declaring the enable flag for that mixers DAC1 input as well as the "DAC1 Playback Switch" control both as SND_SOC_NOPM controls. 2. Storing the settings of both controls as driver-private data 3. Only clearing the mute flag for the DAC1 input of that mixer if the stored values indicate both controls are enabled. This is a preparation patch for adding "audio-mute" LED trigger support. Signed-off-by:
-
Hans de Goede authored
The SND_SOC_DAPM_MIXER declaration for "Sto1 ADC MIXL" and "Sto1 ADC MIXR" was using the mute bits from the RT5670_STO1_ADC_DIG_VOL control as mixer master mute bits. But these bits are already exposed to userspace as controls as part of the "ADC Capture Volume" / "ADC Capture Switch" control pair: SOC_DOUBLE("ADC Capture Switch", RT5670_STO1_ADC_DIG_VOL, RT5670_L_MUTE_SFT, RT5670_R_MUTE_SFT, 1, 1), SOC_DOUBLE_TLV("ADC Capture Volume", RT5670_STO1_ADC_DIG_VOL, RT5670_L_VOL_SFT, RT5670_R_VOL_SFT, 127, 0, adc_vol_tlv), Both the fact that the mute bits belong to the same reg as the vol-ctrl and the "Digital Mixer Path" diagram in the datasheet clearly shows that these mute bits are not part of the mixer and having 2 separate controls poking at the same bits is a bad idea. Remove the master-mute bits settings from the "Sto1 ADC MIXL" and "Sto1 ADC MIXR" DAPM widget declarations, avoiding these bits getting poked from 2 different places. This should not cause any issues for userspace. AFAICT the rt567x codecs are only used on x86/ACPI devices and the UCM profiles used there already set the "ADC Capture Switch" as needed. Signed-off-by:
-
