- Dec 17, 2021
-
-
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 <digetx@gmail.com> Acked-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20211204143725.31646-8-digetx@gmail.com Signed-off-by:
Mark Brown <broonie@kernel.org>
-
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:
-
Dmitry Osipenko authored
Document new nvidia,fixed-parent-rate property which instructs that this board wants parent clock to stay at a fixed rate. It allows to prevent conflicts between audio components that share same parent PLL. For instance, this property allows to have HDMI audio, speaker and headphones in the system playing audio simultaneously, which is a common pattern for consumer devices. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Dmitry Osipenko authored
Convert NVIDIA Tegra20 I2S binding to schema. Reviewed-by:
-
Dmitry Osipenko authored
Add device-tree binding for Tegra20 S/PDIF controller. Reviewed-by:
-
Mark Brown authored
Merge tag 'dmaengine_topic_slave_id_removal_5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine into v4_20211204_digetx_support_hdmi_audio_on_nvidia_tegra20 dmaengine_topic_slave_id_removal_5.17 Tag for dmaengine slave_id removal topic branch which should be merged into v5.17
-
Arnd Bergmann authored
All references to the slave_id field have been removed, so remove the field as well to prevent new references from creeping in again. Originally this allowed slave DMA drivers to configure which device is accessed with the dmaengine_slave_config() call, but this was inconsistent, as the same information is also passed while requesting a channel, and never changes in practice. In modern kernels, the device is always selected when requesting the channel, so the .slave_id field is no longer useful. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Vinod Koul <vkoul@kernel.org>
-
Arnd Bergmann authored
The display driver wants to pass a custom flag to the DMA engine driver, which it started doing by using the slave_id field that was traditionally used for a different purpose. As there is no longer a correct use for the slave_id field, it should really be removed, and the remaining users changed over to something different. The new mechanism for passing nonstandard settings is using the .peripheral_config field, so use that to pass a newly defined structure here, making it clear that this will not work in portable drivers. Reviewed-by:
-
Arnd Bergmann authored
The slave_id was previously used to pick one DMA slave instead of another, but this is now done through the DMA descriptors in device tree. For the qcom_adm driver, the configuration is documented in the DT binding to contain a tuple of device identifier and a "crci" field, but the implementation ends up using only a single cell for identifying the slave, with the crci getting passed in nonstandard properties of the device, and passed through the dma driver using the old slave_id field. Part of the problem apparently is that the nand driver ends up using only a single DMA request ID, but requires distinct values for "crci" depending on the type of transfer. Change both the dmaengine driver and the two slave drivers to allow the documented binding to work in addition to the ad-hoc passing of crci values. In order to no longer abuse the slave_id field, pass the data using the "peripheral_config" mechanism instead. Signed-off-by:
-
Arnd Bergmann authored
It appears that the code that reads the slave_id from the channel config was copied incorrectly from other drivers. Nothing ever sets this field on platforms that use this driver, so remove the reference. Reviewed-by:
Baolin Wang <baolin.wang7@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
The last driver referencing the slave_id on Marvell PXA and MMP platforms was the SPI driver, but this stopped doing so a long time ago, so the TODO from the earlier patch can no be removed. Fixes: b729bf34 ("spi/pxa2xx: Don't use slave_id of dma_slave_config") Fixes: 13b3006b ("dma: mmp_pdma: add filter function") Signed-off-by:
-
Arnd Bergmann authored
The slave device is picked through either devicetree or a filter function, and any remaining out-of-tree drivers would have warned about this usage since 2015. Stop interpreting the field finally so it can be removed from the interface. Reviewed-by:
-
Arnd Bergmann authored
The field is not interpreted by the DMA engine driver, as all the data is passed from devicetree instead. Remove the assignment so the field can eventually be deleted. Reviewed-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Acked-by:
-
Arnd Bergmann authored
Setting slave_id makes no sense with DT based probing, and should eventually get removed entirely. Address this driver by no longer setting the field here. I could not find which DMA driver is used on PIC32, if it's in the tree at all, but none of the obvious ones even care about slave_id any more. Acked-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 authored
Nothing sets the slave_id field any more, so stop accessing it to allow the removal of this field. Signed-off-by:
-
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 16, 2021
-
-
Mark Brown authored
Merge series from Ranjani Sridharan <ranjani.sridharan@linux.intel.com>: This set of patches deals with modifications to the signature of kcontrol get/set data functions to make them more intuitive. The last patch deals with initializing the binary control data size after boot up.
-
- 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:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Reviewed-by:
Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@intel.com> Reviewed-by:
Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Link: https://lore.kernel.org/r/20211215163511.151286-1-pierre-louis.bossart@linux.intel.com Signed-off-by:
-
David Heidelberg authored
Convert Tegra audio complex with the * ALC5632 * MAX98090 * RT5640 * RT5677 * SGTL5000 * TrimSlice * WM8753 * WM8903 * WM9712 codec to the YAML format. Additional changes: - added missing HPOUTL to the WM9712 codec. - extended rt5677 codec with multiple pins Reviewed-by:
David Heidelberg <david@ixit.cz> Reviewed-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:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20211215180404.53254-9-ranjani.sridharan@linux.intel.com 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:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-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:
Paul Olaru <paul.olaru@oss.nxp.com> Reviewed-by:
-
Mark Brown authored
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: We've been adding a 'deep buffer' PCM device to several SOF topologies in order to reduce power consumption. The typical use-case would be music playback over a headset: this additional PCM device provides more buffering and longer latencies, leaving the rest of the system sleep for longer periods. Notifications and 'regular' low-latency audio playback would still use the 'normal' PCM device and be mixed with the 'deep buffer' before rendering on the headphone endpoint. The tentative direction would be to expose this alternate device to PulseAudio/PipeWire/CRAS via the UCM SectionModifier definitions. That seemed a straightforward topology change until our automated validation stress tests started reporting issues on SoundWire platforms, when e.g. two START triggers might be send and conversely the STOP trigger is never sent. The SoundWire stream state management flagged inconsistent states when the two 'normal' and 'deep buffer' devices are used concurrently with rapid play/stop/pause monkey testing. Looking at the soc-pcm.c code, it seems that the BE state management needs a lot of love. a) there is no consistent protection for the BE state. In some parts of the code, the state updates are protected by a spinlock but in the trigger they are not. When we open/play/close the two PCM devices in stress tests, we end-up testing a state that is being modified. That can't be good. b) there is a conceptual deadlock: on stop we check the FE states to see if a shared BE can be stopped, but since we trigger the BE first the FE states have not been modified yet, so the TRIGGER_STOP is never sent. This patchset suggests the removal of the dedicated 'dpcm_lock' and follows the design suggested by Takashi Iwai. By default the protection relies on the 'pcm_mutex', except for the FE and BE triggers where the mutex cannot be used. In this case, the FE PCM lock is used instead. In the cases where a BE is added/removed, the pcm_mutex and FE PCM lock are both taken. In addition, the BE PCM lock is used to serialize access to a shared BE. With these patches I am able to run our entire validation suite without any issues with this new 'deep buffer' topology, and no regressions on existing solutions [1]. The tests were reproduced by Bard Liao for SoundWire devices. One might ask 'how come we didn't see this earlier'? The answer is probably that the .trigger callbacks in most implementations seems to perform DAPM operations, and sending the triggers multiple times is not an issue. In the case of SoundWire, we do use the .trigger callback to reconfigure the bus using the 'bank switch' mechanism. It could be acceptable to tolerate a trigger multiple times, but the deadlock on stop cannot be fixed at the SoundWire level alone. Opens: 1) The issues reported by Nvidia on the RFCv3 may or may not be present. We'd need test results to make sure the locking update does not introduce a regression on Tegra. 2) There are other reports of kernel oopses [2] that seem related to the lack of protection. I'd be good to confirm if this patchset solve these problems as well. [1] https://github.com/thesofproject/linux/pull/3146 [2] https://lore.kernel.org/alsa-devel/002f01d7b4f5$c030f4a0$4092dde0$@samsung.com/ changes since RFCv3: Used two patches from Takashi. We now use the pcm_mutex, the FE stream lock when adding and deleting a BE, and the BE stream lock to handle concurrency between streams using the same BE. Added a patch to use GFP_ATOMIC for the DPCM structure. Fixed PAUSE_RELEASE transition (GitHub comment from Kai Vehmanen) changes since RFCv2: Removal of dpcm_lock to use FE PCM locks (credits to Takashi Iwai for the suggestion). The FE PCM lock is now used before each use of for_each_dpcm_be() - with the exception of the trigger where the lock is already taken. This change is also applied in drivers which make use of this loop (compress, SH, FSL). Addition of BE PCM lock to deal with mutual exclusion between triggers for the same BE. Alignment of the BE atomicity on the FE on connections, this is required to avoid sleeping in atomic context. Additional cleanups (indentation, static functions) changes since RFC v1: Removed unused function Removed exported symbols only used in soc-pcm.c, used static instead Use a mutex instead of a spinlock Protect all for_each_dpcm_be() loops Fix bugs introduced in the refcount Pierre-Louis Bossart (4): ASoC: soc-pcm: use GFP_ATOMIC for dpcm structure ASoC: soc-pcm: align BE 'atomicity' with that of the FE ASoC: soc-pcm: test refcount before triggering ASoC: soc-pcm: fix BE handling of PAUSE_RELEASE Takashi Iwai (2): ASoC: soc-pcm: Fix and cleanup DPCM locking ASoC: soc-pcm: serialize BE triggers include/sound/soc-dpcm.h | 2 + include/sound/soc.h | 2 - sound/soc/soc-core.c | 1 - sound/soc/soc-pcm.c | 351 +++++++++++++++++++++++++++------------ 4 files changed, 246 insertions(+), 110 deletions(-) -- 2.25.1
-
- 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:
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by:
-
Mark Brown authored
Merge series from Stephan Gerhold <stephan@gerhold.net>: This series makes it possible to route audio through the combined audio/modem DSP on MSM8916/APQ8016 devices instead of bypassing it using the LPASS drivers. This is necessary to support certain functionality such as voice call audio. See PATCH 4/5 for details. Also, qcom,apq8016-sbc.txt is converted to DT schema by adding it to the existing qcom,sm8250.yaml. The bindings are similar enough that it is easier to share a single schema instead of duplicating everything into multiple ones.
-
