- Dec 20, 2021
-
-
Ricard Wanderlof authored
New codec driver for Texas Instruments TLV320ADC3001 and TLV320ADC3101 audio ADCs. Signed-off-by:
Ricard Wanderlof <ricardw@axis.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2112151801370.27889@lap5cg0092dnk.se.axis.com Signed-off-by:
Mark Brown <broonie@kernel.org>
-
- Dec 17, 2021
-
-
Heiner Kallweit authored
The return value of pm_runtime_resume_and_get() needs to be checked to avoid a usage count imbalance in the error case. This fix is basically the same as 92c959ba ("reset: renesas: Fix Runtime PM usage"), and the last step before pm_runtime_resume_and_get() can be annotated as __must_check. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/9fed506d-b780-55cd-45a4-9bd2407c910f@gmail.com Signed-off-by:
-
Cezary Rojewski authored
Group all the catpt_xxx structs together in PCM related functions so they look more cohesive. Signed-off-by:
Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20211216115743.2130622-4-cezary.rojewski@intel.com Signed-off-by:
-
Cezary Rojewski authored
With some improved if-logy, function's size can be reduced slightly. Signed-off-by:
-
Cezary Rojewski authored
After calling dmaengine_submit(), the submitted transfer descriptor belongs to the DMA engine. Pointer to that descriptor may no longer be valid after the call and should be tested before awaiting transfer completion. Reported-by:
Kevin Tian <kevin.tian@intel.com> Suggested-by:
Dave Jiang <dave.jiang@intel.com> Fixes: 4fac9b31 ("ASoC: Intel: Add catpt base members") Signed-off-by:
-
Dmitry Osipenko authored
Support new nvidia,fixed-parent-rate device-tree property which instructs I2S that board wants parent clock rate to stay at a fixed rate. This allows to play audio over S/PDIF and I2S simultaneously. The root of the problem is that audio components on Tegra share the same audio PLL, and thus, only a subset of rates can be supported if we want to play audio simultaneously. Filter out audio rates that don't match parent clock rate if device-tree has the nvidia,fixed-parent-rate property. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20211204143725.31646-14-digetx@gmail.com Signed-off-by:
-
Dmitry Osipenko authored
SPDIF and other SoC components share audio PLL on Tegra, thus only one component may set the desired base clock rate. This creates problem for HDMI audio because it uses SPDIF and audio may not work if SPDIF's clock doesn't exactly match standard audio rate since some receivers may reject audio in that case. Filter out audio rates which SPDIF output can't support, assuming that other components won't change rate at runtime. Signed-off-by:
-
Dmitry Osipenko authored
Support system suspend by enforcing runtime PM suspend/resume. Now there is no doubt that h/w is indeed stopped during suspend and that h/w state will be properly restored after resume. Signed-off-by:
-
Dmitry Osipenko authored
Reset S/PDIF controller on runtime PM suspend/resume to ensure that we always have a consistent hardware state. Signed-off-by:
-
Dmitry Osipenko authored
Use resource-managed helpers to make code cleaner. Driver's remove callback isn't needed anymore since driver is completely resource-managed now. Signed-off-by:
-
Dmitry Osipenko authored
- Clean up whitespaces, defines and variables. - Remove obsolete code. - Adhere to upstream coding style. - Don't override returned error code. - Replace pr_err with dev_err. No functional changes are made by this patch. This is a minor code's refactoring that will ease further maintenance of the driver. Signed-off-by:
-
Dmitry Osipenko authored
Tegra20 S/PDIF driver was added in a pre-DT era and was never used since that time. Revive driver by adding device-tree support. Signed-off-by:
-
Dmitry Osipenko authored
FIFO trigger level must be not less than the size of DMA burst, otherwise audio will be played x4 faster that it should be because part of the DMA data will be dropped on FIFO input buffer overflow. Signed-off-by:
-
Peter Ujfalusi authored
SND_SOC_SOF_DEVELOPER_SUPPORT contains options affecting how the built SOF driver stack will behave, enables debug options and other features. These options have no meaning if the SND_SOC_SOF is not even enabled. If we have SOF client options under developer_support and debug they can be selected to be built even without the core, but they do need symbols from the core (the sof-client API) which can result build failure. In Kconfig we can have SND_SOC_SOF_TOPLEVEL=y SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST=y for example, which will make the flood client to be built, but the SOF core is not as SND_SOC_SOF is not selected. Reviewed-by:
Paul Olaru <paul.olaru@oss.nxp.com> Reviewed-by:
Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@intel.com> 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/20211216230350.343857-1-pierre-louis.bossart@linux.intel.com Signed-off-by:
-
Ajit Kumar Pandey authored
When pcm stream is stopped "substream->runtime" pointer will be set to NULL by ALSA core. In case host received an ipc msg from firmware of type IPC_STREAM_POSITION after pcm stream is stopped, there will be kernel NULL pointer exception in ipc_period_elapsed(). This patch fixes it by adding NULL pointer check for "substream->runtime". Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Signed-off-by:
-
Guennadi Liakhovetski authored
Casting "const" attribute away is dangerous, obtain a writable pointer instead to avoid that. Signed-off-by:
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by:
-
Ranjani Sridharan authored
The SOF driver removed the support for INFO_RESUME in the commit "ASoC: SOF: pcm: do not add SNDRV_PCM_INFO_RESUME to runtime hw info". And resuming is handled by the ALSA core with the .prepare and .trigger_start stages. So, remove handling of RESUME trigger in the component driver trigger op. So, remove handling the RESUME trigger in the platform trigger op for HDA platforms. Reviewed-by:
Kai Vehmanen <kai.vehmanen@intel.com> Reviewed-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by:
-
Ranjani Sridharan authored
The SOF driver removed the support for INFO_RESUME in the commit "ASoC: SOF: pcm: do not add SNDRV_PCM_INFO_RESUME to runtime hw info". And resuming is handled by the ALSA core with the .prepare and .trigger_start stages. So, remove handling of RESUME trigger in the HDA DAI BE trigger op. Reviewed-by:
-
Ranjani Sridharan authored
The SOF driver removed the support for INFO_RESUME in the commit "ASoC: SOF: pcm: do not add SNDRV_PCM_INFO_RESUME to runtime hw info". And resuming is handled by the ALSA core with the .prepare and .trigger_start stages. So, remove handling of RESUME trigger in the component driver trigger op. Reviewed-by:
-
Arnd Bergmann authored
This field is no longer set from any driver now, so remove the last references as well. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Vinod Koul <vkoul@kernel.org>
-
Arnd Bergmann authored
The DMA resource is never set up anywhere, and passing this as slave_id has not been the proper procedure in a long time. As a preparation for removing all slave_id references from the ALSA code, remove this one. According to Dmitry Osipenko, this driver has never been used and the mechanism for configuring DMA would not work as it is implemented, so this part will get rewritten when the driver gets put into use again in the future. Signed-off-by:
-
- Dec 15, 2021
-
-
Pierre-Louis Bossart authored
on i386 or x86_64: when # CONFIG_ACPI is not set, so SND_SOC_ACPI is not set: WARNING: unmet direct dependencies detected for SND_AMD_ACP_CONFIG Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_ACPI [=n] Selected by [y]: - SND_SOC_AMD_ACP_COMMON [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && X86 [=y] && PCI [=y] This problem is due to the unconditional selection of SND_AMD_ACP_CONFIG in other options. Using 'depends on' solved an initial problem but exposed another, let's use select instead. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Fixes: d9b994cd ('ASoC: AMD: acp-config: fix missing dependency on SND_SOC_ACPI') Signed-off-by:
-
Ranjani Sridharan authored
Read back the control data from the DSP to initialize the control data size to match that of the data in the DSP. This is particularly useful for volatile read-only kcontrols in static pipelines. Signed-off-by:
-
Peter Ujfalusi authored
The SOF_CTRL_TYPE_VALUE_COMP_* type is not used by the firmware nor in the kernel side. It is also not clear what action should be taken for such type. With this in mind: The correct ipc_cmd can be selected based on the `ctrl_cmd` and the `set` parameters: if the ctrl_cmd is SOF_CTRL_CMD_BINARY then SOF_CTRL_TYPE_DATA_* otherwise SOF_CTRL_TYPE_VALUE_CHAN_*. The SET or GET direction can be selected with the use of `set` parameter. Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Peter Ujfalusi authored
The component type is not used in firmware nor in the kernel currently and it is not even clear how it should be handled. Do not even try to handle it to avoid errors. Signed-off-by:
-
Peter Ujfalusi authored
There is no need to use two variables to store and check the same information, the scontrol->cmd is the same as scontrol->control_data->cmd. Drop the former one and when it is needed, access the cmd from the control_data. Signed-off-by:
-
Peter Ujfalusi authored
The scontrol->control_data->cmd has been configured during initialization to the correct sof_ipc_ctrl_cmd. No need to pass duplicated information, let's use the already available one via scontrol. Signed-off-by:
-
Peter Ujfalusi authored
Set the scontrol->control_data->cmd early to the same as scontrol->cmd. This is a preparatory patch to remove the ctrl_cmd parameter for the snd_sof_ipc_set_get_comp_data() function. Signed-off-by:
-
Peter Ujfalusi authored
The correct ipc_cmd can be selected based on the `ctrl_cmd` and the `set` parameters: if the ctrl_cmd is SOF_CTRL_CMD_BINARY then SOF_IPC_COMP_*_DATA otherwise SOF_IPC_COMP_*_VALUE. The SET or GET direction can be selected with the use of `set` parameter. Signed-off-by:
-
Peter Ujfalusi authored
Rename the send parameter to set in snd_sof_ipc_set_get_comp_data() and sof_set_get_large_ctrl_data() to be more aligned with the function name. No functional change. Signed-off-by:
-
Jiasheng Jiang authored
The return value of device_property_read_u32_array() is not always 0. To catch the exception in case that devm_kzalloc failed and the rt5663->imp_table was NULL, which caused the failure of device_property_read_u32_array. Fixes: 450f0f6a ("ASoC: rt5663: Add the manual offset field to compensate the DC offset") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20211215031550.70702-1-jiasheng@iscas.ac.cn Signed-off-by:
-
Daniel Baluta authored
Similar with commit 8a49cd11 ("ASoC: SOF: ACPI: avoid reverse module dependency") we will be having hardware specific drivers that link against a common "helper" framework. sof-of-dev.c becomes a library with the interface defined in the newly created file sof-of-dev.h. This is the final step started with Kconfig simplification in commit 7548a391 ("ASoC: SOF: i.MX: simplify Kconfig") Signed-off-by:
-
- Dec 14, 2021
-
-
Miaoqian Lin authored
The function gpr_alloc_port return ERR_PTR on errors, it doesn't return null. Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20211211065840.1221-1-linmq006@gmail.com Signed-off-by:
-
Judy Hsiao authored
Distinguish which headset codec is on the board by codec_dai->name instead of card->name. It fixes the crash of being unable to handle kernel paging requests at virtual address ADDR by initializing the correct audio codec on the board. Call stack of the crash: ``` Unable to handle kernel paging request at virtual address ... ... Call trace: rt5682_set_component_pll+0xcc/0xb78 [snd_soc_rt5682] snd_soc_component_set_pll+0x90/0x154 snd_soc_dai_set_pll+0xf4/0x1ac sc7180_snd_startup+0x268/0x3c0 [snd_soc_sc7180] snd_soc_link_startup+0xa4/0x180 soc_pcm_open+0x35c/0x15c8 snd_pcm_open_substream+0xa90/0x13b0 snd_pcm_open+0x1a4/0x55c snd_pcm_capture_open+0x7c/0xe8 snd_open+0x2b8/0x2e4 chrdev_open+0x364/0x3d4 do_dentry_open+0x66c/0xc58 vfs_open+0x7c/0x8c path_openat+0x108c/0x2bbc do_filp_open+0x15c/0x258 do_sys_open+0x278/0x62c __arm64_compat_sys_openat+0x9c/0xb0 ... ``` Fixes: 425c5fce ("ASoC: qcom: Add support for ALC5682I-VS codec") Signed-off-by:
Judy Hsiao <judyhsiao@chromium.org> Link: https://lore.kernel.org/r/20211214022509.1288245-1-judyhsiao@chromium.org Signed-off-by:
-
Pierre-Louis Bossart authored
A BE connected to more than one FE, e.g. in a mixer case, can go through the following transitions. play FE1 -> BE state is START pause FE1 -> BE state is PAUSED play FE2 -> BE state is START stop FE2 -> BE state is STOP (see note [1] below) release FE1 -> BE state is START stop FE1 -> BE state is STOP play FE1 -> BE state is START pause FE1 -> BE state is PAUSED play FE2 -> BE state is START release FE1 -> BE state is START stop FE2 -> BE state is START stop FE1 -> BE state is STOP play FE1 -> BE state is START play FE2 -> BE state is START (no change) pause FE1 -> BE state is START (no change) pause FE2 -> BE state is PAUSED release FE1 -> BE state is START release FE2 -> BE state is START (no change) stop FE1 -> BE state is START (no change) stop FE2 -> BE state is STOP The existing code for PAUSE_RELEASE only allows for the case where the BE is paused, which clearly would not work in the sequences above. Extend the allowed states to restart the BE when PAUSE_RELEASE is received, and increase the refcount if the BE is already in START. [1] the existing logic does not move the BE state back to PAUSED when the FE2 is stopped. This patch does not change the logic; it would be painful to keep a history of changes on the FE side, the state machine is already rather complicated with transitions based on the last BE state and the trigger type. Reported-by:
Bard Liao <bard.liao@intel.com> Signed-off-by:
-
Pierre-Louis Bossart authored
On start/pause_release/resume, when more than one FE is connected to the same BE, it's possible that the trigger is sent more than once. This is not desirable, we only want to trigger a BE once, which is straightforward to implement with a refcount. For stop/pause/suspend, the problem is more complicated: the check implemented in snd_soc_dpcm_can_be_free_stop() may fail due to a conceptual deadlock when we trigger the BE before the FE. In this case, the FE states have not yet changed, so there are corner cases where the TRIGGER_STOP is never sent - the dual case of start where multiple triggers might be sent. This patch suggests an unconditional trigger in all cases, without checking the FE states, using a refcount protected by the BE PCM stream lock. Signed-off-by:
-
Takashi Iwai authored
When more than one FE is connected to a BE, e.g. in a mixing use case, the BE can be triggered multiple times when the FE are opened/started concurrently. This race condition is problematic in the case of SoundWire BE dailinks, and this is not desirable in a general case. This patch relies on the existing BE PCM lock, which takes atomicity into account. The locking model assumes that all interactions start with the FE, so that there is no deadlock between FE and BE locks. Signed-off-by:
Takashi Iwai <tiwai@suse.de> [test, checkpatch fix and clarification of commit message by plbossart] Signed-off-by:
-
Takashi Iwai authored
The existing locking for DPCM has several issues a) a confusing mix of card->mutex and card->pcm_mutex. b) a dpcm_lock spinlock added inconsistently and on paths that could be recursively taken. The use of irqsave/irqrestore was also overkill. The suggested model is: 1) The pcm_mutex is the top-most protection of BE links in the FE. The pcm_mutex is applied always on either the top PCM callbacks or the external call from DAPM, not taken in the internal functions. 2) the FE stream lock is taken in higher levels before invoking dpcm_be_dai_trigger() 3) when adding and deleting a BE, both the pcm_mutex and FE stream lock are taken. Signed-off-by:
-
Pierre-Louis Bossart authored
Since the flow for DPCM is based on taking a lock for the FE first, we need to make sure during the connection between a BE and an FE that they both use the same 'atomicity', otherwise we may sleep in atomic context. If the FE is nonatomic, this patch forces the BE to be nonatomic as well. That should have no negative impact since the BE 'inherits' the FE properties. However, if the FE is atomic and the BE is not, then the configuration is flagged as invalid. Signed-off-by:
-
Pierre-Louis Bossart authored
We allocate a structure in dpcm_be_connect(), which may be called in atomic context. Using GFP_KERNEL is not quite right, we have to use GFP_ATOMIC to prevent the allocator from sleeping. Suggested-by:
-
