- 24 Jun, 2022 38 commits
-
-
Javier Martinez Canillas authored
Before adding support to define bulk read/write callbacks in regmap_config by the commit d77e7456 ("regmap: Add bulk read/write callbacks into regmap_config"), the regmap_noinc_read() function returned an errno early a map->bus->read callback wasn't set. But that commit dropped the check and now a call to _regmap_raw_read() is attempted even when bulk read operations are not supported. That function checks for map->read anyways but there's no point to continue if the read can't succeed. Also is a fragile assumption to make so is better to make it fail earlier. Fixes: d77e7456 ("regmap: Add bulk read/write callbacks into regmap_config") Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20220616073435.1988219-3-javierm@redhat.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Javier Martinez Canillas authored
Support for drivers to define bulk read/write callbacks in regmap_config was introduced by the commit d77e7456 ("regmap: Add bulk read/write callbacks into regmap_config"), but this commit wrongly dropped a check in regmap_bulk_read() to determine whether bulk reads can be done or not. Before that commit, it was checked if map->bus was set. Now has to check if a map->read callback has been set. Fixes: d77e7456 ("regmap: Add bulk read/write callbacks into regmap_config") Signed-off-by:
-
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:
-
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:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20220603122526.3914942-1-broonie@kernel.orgSigned-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:
Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by:
Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220610124420.4160986-1-amadeuszx.slawinski@linux.intel.comSigned-off-by:
-
Amadeusz Sławiński authored
Use correct type for parsing UUIDs, this eliminates warning present, when compiling with W=1. Fixes: 34ae2cd5 ("ASoC: Intel: avs: Add topology parsing infrastructure") Reported-by:
-
Peter Ujfalusi authored
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: b5cee8fe ("ASoC: SOF: topology: Make control parsing IPC agnostic") Signed-off-by:
-
Peter Ujfalusi authored
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. Complements: 2a68ff84 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by:
-
Peter Ujfalusi authored
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. Complements: 2a68ff84 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by:
-
Peter Ujfalusi authored
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. Complements: 2a68ff84 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by:
-
Kuninori Morimoto authored
Renesas is the only user of ak4613 on upstream for now, and commit f28dbaa9 ("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:
-
Pierre-Louis Bossart authored
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. BugLink: https://github.com/thesofproject/linux/issues/3643 Fixes: 7ad4d237 ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver') Fixes: 899b1254 ('ASoC: rt711: add snd_soc_component remove callback') Signed-off-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
-
Pierre-Louis Bossart authored
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() WARN_ON_FUNCTION_MISMATCH(timer->function, delayed_work_timer_fn); Move all the initializations to the probe functions. Signed-off-by:
-
Pierre-Louis Bossart authored
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. Signed-off-by:
-
Pierre-Louis Bossart authored
Follow the same flow as rt711-sdca and initialize all mutexes at probe time. Signed-off-by:
-
Pierre-Louis Bossart authored
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. Signed-off-by:
-
Pierre-Louis Bossart authored
In codec driver bind/unbind test, the following warning is thrown: DEBUG_LOCKS_WARN_ON(lock->magic != lock) ... [ 699.182495] rt711_sdca_jack_init+0x1b/0x1d0 [snd_soc_rt711_sdca] [ 699.182498] rt711_sdca_set_jack_detect+0x3b/0x90 [snd_soc_rt711_sdca] [ 699.182500] snd_soc_component_set_jack+0x24/0x50 [snd_soc_core] 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. BugLink: https://github.com/thesofproject/linux/issues/3644Signed-off-by:
-
Pierre-Louis Bossart authored
When binding/unbinding codec drivers, the following warnings are thrown: [ 107.266879] rt715-sdca sdw:3:025d:0714:01: Unbalanced pm_runtime_enable! [ 306.879700] rt711-sdca sdw:0:025d:0711:01: Unbalanced pm_runtime_enable! Add a remove callback for all Realtek/Maxim SoundWire codecs and remove this warning. Signed-off-by:
-
- 07 Jun, 2022 2 commits
-
-
Mark Brown authored
We currently report that range controls accept a range of 0..(max-min) but accept writes in the range 0..(max-min+1). Remove that extra +1. Signed-off-by:
-
Mark Brown authored
Linux 5.19-rc1
-
