- 10 Jan, 2020 11 commits
-
-
Kuninori Morimoto authored
dpcm_fe_dai_shutdown() / soc_compr_free_fe() didn't care pmdown_time. We already have snd_soc_dapm_stream_stop() for it. Let's use common method. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87zhewrq9j.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
When we stop stream, if it was Playback, we might need to care about power down time. In such case, we need to use delayed work. We have same implementation for it at soc-pcm.c and soc-compress.c, but we don't want to have duplicate code. This patch adds snd_soc_dapm_stream_stop(), and share same code. Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/871rs8t4uw.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
We need to setup rtd->close_delayed_work_func. It will be set at snd_soc_dai_compress_new() or soc_new_pcm(). But these setups close_delayed_work() which is same name / same implemantaion, but different local code. To reduce duplicate code, this patch moves it as snd_soc_close_delayed_work() and share same code. Signed-off-by:
-
Kuninori Morimoto authored
ALSA SoC need to care pinctrl_pm_select_xxx(). It is called at soc-core and soc-pcm. soc-pcm is controlling it for activate DAI. soc-core is controlling it for whole system (= suspend/resume/probe/poweroff). If we focus to soc-core side, it need to care about BIAS level. Then, snd_soc_suspend() only is controlling it by Component base (a). Other functions are DAI base (b). (a) pinctrl_pm_select_xxx(component->dev, xxx); (b) pinctrl_pm_select_xxx(dai->dev, xxx); Because of these unbalance, the code is confusable. Here, dai->dev and component->dev are same pointer. Thus, we can replace it component base. One note here is that it cared DAI (= CPU/Codec) pin before this patch, after this patch, it cares Component (= CPU/Codec/Platform) pin. Signed-off-by:
-
Kuninori Morimoto authored
snd_soc_suspend() are doing below for pinctrl_pm_select_sleep_state() int snd_soc_suspend(struct device *dev) { ... for_each_card_components(card, component) { ... (1) pinctrl_pm_select_sleep_state(component->dev); } for_each_card_rtds(card, rtd) { ... (2) pinctrl_pm_select_sleep_state(cpu_dai->dev); } } (1) is called for all component (CPU/Codec/Platform), and (2) is called for CPU DAIs. Here, component->dev is same as dai->dev. This means, it is called in duplicate on CPU case. This patch removes (2). Signed-off-by: -
Kuninori Morimoto authored
Card dai_link has .ignore_suspend, and ALSA SoC cares it when suspend. For example, like this for_each_card_rtds(card, rtd) { if (rtd->dai_link->ignore_suspend) continue; ... } But in snd_soc_suspend(), it doesn't care about it when suspending Component. This patch cares it. Signed-off-by: -
Kuninori Morimoto authored
We don't have snd_soc_rtdcom_list anymore. Let's rename snd_soc_rtdcom_add() to more understandable snd_soc_rtd_add_component() Reported-by:
Sridharan, Ranjani <ranjani.sridharan@intel.com> Signed-off-by:
-
Shuming Fan authored
This is the initial codec driver for rt700. Signed-off-by:
Shuming Fan <shumingf@realtek.com> Tested-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110014552.17252-1-shumingf@realtek.comSigned-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is using struct snd_soc_rtdcom_list to connecting component to rtd by using list_head. struct snd_soc_rtdcom_list { struct snd_soc_component *component; struct list_head list; /* rtd::component_list */ }; struct snd_soc_pcm_runtime { ... struct list_head component_list; /* list of connected components */ ... }; The CPU/Codec/Platform component which will be connected to rtd (a) is indicated via dai_link at snd_soc_add_pcm_runtime() int snd_soc_add_pcm_runtime(...) { ... /* Find CPU from registered CPUs */ rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus); ... (a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component); ... /* Find CODEC from registered CODECs */ (b) for_each_link_codecs(dai_link, i, codec) { rtd->codec_dais[i] = snd_soc_find_dai(codec); ... (a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component); } ... /* Find PLATFORM from registered PLATFORMs */ (b) for_each_link_platforms(dai_link, i, platform) { for_each_component(component) { ... (a) snd_soc_rtdcom_add(rtd, component); } } } It shows, it is possible to know how many components will be connected to rtd by using dai_link->num_cpus dai_link->num_codecs dai_link->num_platforms If so, we can use component pointer array instead of list_head, in such case, code can be more simple. This patch removes struct snd_soc_rtdcom_list that is only of temporary value, and convert to pointer array. Signed-off-by: -
Mark Brown authored
This reverts commit 4e93c129 (ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double()) which was misapplied. Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Mark Brown authored
Merge branch 'for-5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-5.6
-
- 09 Jan, 2020 9 commits
-
-
Shuming Fan authored
This is the initial codec driver for rt711. Signed-off-by:
-
Mark Brown authored
Merge tag 'sdw_interfaces_5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire into asoc-5.6 SoundWire tag for ASoC This contains the recently merged soundwire interface changes for ASoC subsystem.
-
Srinivas Kandagatla authored
This patch adds support to WSA8810/WSA8815 Class-D Smart Speaker Amplifier. This Amplifier is primarily interfaced with SoundWire. One WSA is used for mono speaker configuration and second one would give stereo setup. This patch is tested on SDM845 based DragonBoard DB845c and Lenovo YOGA C630 Laptop based on SDM850 with WSA8815 speaker amplifiers. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by:
-
Srinivas Kandagatla authored
This patch adds bindings for WSA8810/WSA8815 Class-D Smart Speaker Amplifier. This Amplifier also has a simple thermal sensor for over temperature and speaker protection. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200107135929.3267-2-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Olivier Moysan authored
In current driver, locks can be taken as follows: - Register access: take a lock on regmap config and then on clock. - Master clock provider: take a lock on clock and then on regmap config. This can lead to the circular locking summarized below. Remove peripheral clock management through regmap framework, and manage peripheral clock in driver instead. On register access, lock on clock is taken first, which allows to avoid possible locking issue. [ 6696.561513] ====================================================== [ 6696.567670] WARNING: possible circular locking dependency detected [ 6696.573842] 4.19.49 #866 Not tainted [ 6696.577397] ------------------------------------------------------ [ 6696.583566] pulseaudio/6439 is trying to acquire lock: [ 6696.588697] 87b0a25b (enable_lock){..-.}, at: clk_enable_lock+0x64/0x128 [ 6696.595377] [ 6696.595377] but task is already holding lock: [ 6696.601197] d858f825 (stm32_sai_sub:1342:(sai->regmap_config)->lock){....} ... [ 6696.812513] Possible unsafe locking scenario: [ 6696.812513] [ 6696.818418] CPU0 CPU1 [ 6696.822935] ---- ---- [ 6696.827451] lock(stm32_sai_sub:1342:(sai->regmap_config)->lock); [ 6696.833618] lock(enable_lock); [ 6696.839350] lock(stm32_sai_sub:1342: (sai->regmap_config)->lock); [ 6696.848035] lock(enable_lock); Fixes: 03e78a24 ("ASoC: stm32: sai: add h7 support") Signed-off-by:Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20200109083254.478-1-olivier.moysan@st.comSigned-off-by:
-
Marek Szyprowski authored
Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling many controls by adding a custom put function to them. That new custom put function properly handles relations between codec's hardware registers. However they used card->dapm_mutex to properly serialize those operations. This in turn triggers a lockdep warning about possible circular dependency. Fix this by introducing a separate mutex only for serializing the SHDN hardware register related operations. This fixes the following lockdep warning observed on Exynos4412-based Odroid U3 board: ====================================================== WARNING: possible circular locking dependency detected 5.5.0-rc5-next-20200107 #166 Not tainted ------------------------------------------------------ alsactl/1104 is trying to acquire lock: ed0d50f4 (&card->dapm_mutex){+.+.}, at: max98090_shdn_save+0x1c/0x28 but task is already holding lock: edb4b49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&card->controls_rwsem){++++}: snd_ctl_add_replace+0x3c/0x84 dapm_create_or_share_kcontrol+0x24c/0x2e0 snd_soc_dapm_new_widgets+0x308/0x594 snd_soc_bind_card+0x80c/0xad4 devm_snd_soc_register_card+0x34/0x6c odroid_audio_probe+0x288/0x34c platform_drv_probe+0x6c/0xa4 really_probe+0x200/0x490 driver_probe_device+0x78/0x1f8 bus_for_each_drv+0x74/0xb8 __device_attach+0xd4/0x16c bus_probe_device+0x88/0x90 deferred_probe_work_func+0x3c/0xd0 process_one_work+0x22c/0x7c4 worker_thread+0x44/0x524 kthread+0x130/0x164 ret_from_fork+0x14/0x20 0x0 -> #0 (&card->dapm_mutex){+.+.}: lock_acquire+0xe8/0x270 __mutex_lock+0x9c/0xb18 mutex_lock_nested+0x1c/0x24 max98090_shdn_save+0x1c/0x28 max98090_put_enum_double+0x20/0x40 snd_ctl_ioctl+0x190/0xbb8 ksys_ioctl+0x470/0xaf8 ret_fast_syscall+0x0/0x28 0xbefaa564 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&card->controls_rwsem); lock(&card->dapm_mutex); lock(&card->controls_rwsem); lock(&card->dapm_mutex); *** DEADLOCK *** 1 lock held by alsactl/1104: #0: edb4b49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8 stack backtrace: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (unwind_backtrace) from [<c010e180>] (show_stack+0x10/0x14) (show_stack) from [<c0b2a09c>] (dump_stack+0xb4/0xe0) (dump_stack) from [<c018a1c0>] (check_noncircular+0x1ec/0x208) (check_noncircular) from [<c018c5dc>] (__lock_acquire+0x1210/0x25ec) (__lock_acquire) from [<c018e2d8>] (lock_acquire+0xe8/0x270) (lock_acquire) from [<c0b49678>] (__mutex_lock+0x9c/0xb18) (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) (max98090_shdn_save) from [<c083a5b8>] (max98090_put_enum_double+0x20/0x40) (max98090_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... Fixes: 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by:
-
Marek Szyprowski authored
Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling "LTENL Mux", "LTENR Mux", "LBENL Mux" and "LBENR Mux" controls by adding a custom max98090_dapm_put_enum_double() function to them. However that function used incorrect helper to get its component object. Fix this by using the proper snd_soc_dapm_* helper. This fixes the following NULL pointer exception observed on Exynos4412-based Odroid U3 board: 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 000000b0 pgd = (ptrval) [000000b0] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) PC is at __mutex_lock+0x54/0xb18 LR is at ___might_sleep+0x3c/0x2e0 ... Process alsactl (pid: 1104, stack limit = 0x(ptrval)) ... [<c0b49630>] (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) [<c0b4a110>] (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) [<c0839b3c>] (max98090_shdn_save) from [<c083a4f8>] (max98090_dapm_put_enum_double+0x20/0x40) [<c083a4f8>] (max98090_dapm_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) [<c080d0e8>] (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) [<c02cafec>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... ---[ end trace 0e93f0580f4b9241 ]--- Fixes: 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by:
Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20200108115007.31095-1-m.szyprowski@samsung.comSigned-off-by:
-
Marek Szyprowski authored
Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling "LTENL Mux", "LTENR Mux", "LBENL Mux" and "LBENR Mux" controls by adding a custom max98090_dapm_put_enum_double() function to them. However that function used incorrect helper to get its component object. Fix this by using the proper snd_soc_dapm_* helper. This fixes the following NULL pointer exception observed on Exynos4412-based Odroid U3 board: 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 000000b0 pgd = (ptrval) [000000b0] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) PC is at __mutex_lock+0x54/0xb18 LR is at ___might_sleep+0x3c/0x2e0 ... Process alsactl (pid: 1104, stack limit = 0x(ptrval)) ... [<c0b49630>] (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) [<c0b4a110>] (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) [<c0839b3c>] (max98090_shdn_save) from [<c083a4f8>] (max98090_dapm_put_enum_double+0x20/0x40) [<c083a4f8>] (max98090_dapm_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) [<c080d0e8>] (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) [<c02cafec>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... ---[ end trace 0e93f0580f4b9241 ]--- Fixes: 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by:
-
Wei Yongjun authored
In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: c9fe7db6 ("ASoC: amd: Refactoring of DAI from DMA driver") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200108035954.51317-1-weiyongjun1@huawei.comSigned-off-by:
-
- 07 Jan, 2020 4 commits
-
-
Arnd Bergmann authored
The driver produces warnings without CONFIG_OF, and makes no sense without it either: sound/soc/codecs/gtm601.c:50:34: error: 'bm818_dai' defined but not used [-Werror=unused-variable] static struct snd_soc_dai_driver bm818_dai = { ^~~~~~~~~ sound/soc/codecs/gtm601.c:32:34: error: 'gtm601_dai' defined but not used [-Werror=unused-variable] static struct snd_soc_dai_driver gtm601_dai = { ^~~~~~~~~~ Remove the #ifdef check to avoid the warning. Fixes: 057a317a ("ASoC: gtm601: add Broadmobi bm818 sound profile") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200107214846.1284981-1-arnd@arndb.deSigned-off-by:
-
Pierre-Louis Bossart authored
We currently have no trace referring to the firmware path, add a trace to help debug cases where the wrong file might be used. Signed-off-by:
-
Pierre-Louis Bossart authored
Since ApolloLake, Intel platforms require signed firmware. On all Windows platforms the default is to require the Intel production key be used. But some platforms allow for a community key to be used, which allows developers to compile/build their own firmware. In the linux-firmware tree, the default intel/sof path is used for firmwares signed for the production key, and files signed with the community key are located in intel/sof/community. Since we don't have an API to query which key is used on what platforms, we have to rely on DMI-based quirks. Developers can bypass this mechanism by setting a kernel 'fw_path' module parameter. Additional dynamic debug traces are provided to help debug cases where the wrong file might be used. Signed-off-by:
-
Takashi Iwai authored
When an ASoC driver with pcm_destruct component ops is freed before the PCM object instantiation (e.g. deferring the probe), it hits an Oops at snd_soc_pcm_component_free() that calls the pcm_destruct ops unconditionally. Fix it by adding a NULL-check of rtd->pcm before calling callbacks. Fixes: c64bfc90 ("ASoC: soc-core: add new pcm_construct/pcm_destruct") Reported-by:
Matthias Brugger <matthias.bgg@gmail.com> Tested-by:
Ben Ho <ben.ho@mediatek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200107070956.15807-1-tiwai@suse.deSigned-off-by:
-
- 06 Jan, 2020 3 commits
-
-
Sam McNally authored
Some members of the Google_Hatch family include a rt5682 jack codec, but no speaker amplifier. This uses the same driver (sof_rt5682) as a combination of rt5682 jack codec and max98357a speaker amplifier. Within the sof_rt5682 driver, these cases are not currently distinguishable, relying on a DMI quirk to decide the configuration. This causes an incorrect configuration when only the rt5682 is present on a Google_Hatch device. For CML, the jack codec is used as the primary key when matching, with a possible speaker amplifier described in quirk_data. The two cases of interest are the second and third 10EC5682 entries in snd_soc_acpi_intel_cml_machines[]. The second entry matches the combination of rt5682 and max98357a, resulting in the quirk_data field in the snd_soc_acpi_mach being non-null, pointing at max98357a_spk_codecs, the snd_soc_acpi_codecs for the matched speaker amplifier. The third entry matches just the rt5682, resulting in a null quirk_data. The sof_rt5682 driver's DMI data matching identifies that a speaker amplifier is present for all Google_Hatch family devices. Detect cases where there is no speaker amplifier by checking for a null quirk_data in the snd_soc_acpi_mach and remove the speaker amplifier bit in that case. Signed-off-by:
Sam McNally <sammc@chromium.org> Acked-by:
-
Hans de Goede authored
When a quirk for the Irbis NB41 netbook was added, to override the defaults for this device, I forgot to add/keep the BYT_CHT_ES8316_SSP0 part of the defaults, completely breaking audio on this netbook. This commit adds the BYT_CHT_ES8316_SSP0 flag to the Irbis NB41 netbook quirk, making audio work again. Cc: stable@vger.kernel.org Cc: russianneuromancer@ya.ru Fixes: aa2ba991 ("ASoC: Intel: bytcht_es8316: Add quirk for Irbis NB41 netbook") Reported-and-tested-by: russianneuromancer@ya.ru Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Dmitry Osipenko authored
The rt5640->jack is NULL if jack is already disabled at the time of driver's module unloading. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20200106014707.11378-1-digetx@gmail.comSigned-off-by:
-
- 03 Jan, 2020 3 commits
-
-
Pierre-Louis Bossart authored
Sparse complains about a series of easy warnings, fix. Signed-off-by:
-
Pierre-Louis Bossart authored
Fix Sparse warning: hda_dsp_common.c:66:37: warning: Using plain integer as NULL pointer Signed-off-by:
-
Arnd Bergmann authored
On non-x86, the new driver results in a build failure: sound/soc/intel/boards/cml_rt1011_rt5682.c:14:10: fatal error: asm/cpu_device_id.h: No such file or directory The asm/cpu_device_id.h header is not actually needed here, so don't include it. Signed-off-by:
-
- 01 Jan, 2020 2 commits
-
-
Julia Lawall authored
Use resource_size rather than a verbose computation on the end and start fields. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) <smpl> @@ struct resource ptr; @@ - (ptr.end - ptr.start + 1) + resource_size(&ptr) </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/1577900990-8588-7-git-send-email-Julia.Lawall@inria.frSigned-off-by:
-
Julia Lawall authored
The q6asm_dai_hardware_capture structure is only copied into another structure, so make it const. The opportunity for this change was found using Coccinelle. Signed-off-by:
-
- 31 Dec, 2019 8 commits
-
-
Ravulapati Vishnu vardhan rao authored
ACP-I2S device support MMAP_INTERLEAVED. Added support for the same. Signed-off-by:
Ravulapati Vishnu vardhan rao <Vishnuvardhanrao.Ravulapati@amd.com> Link: https://lore.kernel.org/r/1577540460-21438-7-git-send-email-Vishnuvardhanrao.Ravulapati@amd.comSigned-off-by:
-
Ravulapati Vishnu vardhan rao authored
When system wide suspend happens, ACP will be powered off and when system resumes,for audio usecase to continue,all the runtime configuration data needs to be programmed again. Added resume pm call back to ACP pm ops and also added runtime PM operations for ACP3x PCM platform device. Device will enter into D3 state when there is no activity on audio I2S lines. Signed-off-by:
-
Ravulapati Vishnu vardhan rao authored
Enabled support for I2S-SP interrupt handling. Previous to this implementation, driver supports only interrupts on BT instance. Signed-off-by:
-
Ravulapati Vishnu vardhan rao authored
ACP3x I2S (CPU DAI) can act in normal I2S and TDM modes. Added support for TDM mode. Desired mode can be selected from ASoC machine driver. Signed-off-by:
-
Ravulapati Vishnu vardhan rao authored
This patch adds I2S SP support in ACP PCM DMA and DAI. Added I2S support in DMA and DAI probe,its hw_params handling its open and close functionalities. This enables to open and close on the SP instance for playback and capture. Signed-off-by:
-
Ravulapati Vishnu vardhan rao authored
ASoC: PCM DMA driver should only have dma ops. So Removed all DAI related functionality.Refactoring the PCM DMA diver code.Added new file containing only DAI ops Signed-off-by:
-
Charles Keepax authored
When one of the MCLK pins is used to supply the FLL enable that clock source. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20191230143517.21005-2-ckeepax@opensource.cirrus.comSigned-off-by:
-
Charles Keepax authored
When one of the MCLK pins is used to supply an internal clock directly enable the source clock for that pin. Signed-off-by:
-
