- 05 Nov, 2019 13 commits
-
-
Kuninori Morimoto authored
soc-core has snd_soc_add_component(), snd_soc_component_add(), snd_soc_del_component(), snd_soc_component_del(). These are very confusing naming. snd_soc_component_xxx() are called from snd_soc_xxx_component(), and these are very small. Let's merge these into snd_soc_xxx_component(), and remove snd_soc_component_xxx(). Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/871rum3jmy.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
It is easy to read code if it is cleanly using paired function/naming, like start <-> stop, register <-> unregister, etc, etc. But, current ALSA SoC code is very random, unbalance, not paired, etc. It is easy to create bug at the such code, and is difficult to debug. Now ALSA SoC has snd_soc_add_component(), but there is no paired snd_soc_del_component(). Thus, snd_soc_unregister_component() is calling cleanup function randomly. it is difficult to read. This patch adds missing snd_soc_del_component_unlocked() and balance up code. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/8736f23jn4.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
snd_soc_lookup_component() is using mix of continue and break in the same loop. It is odd. This patch cleanup it. Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/874kzi3jn8.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
This patch moves snd_soc_lookup_component() to upper side. This is prepare for snd_soc_unregister_component() Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/875zjy3jnd.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
It is easy to read code if it is cleanly using paired function/naming, like start <-> stop, register <-> unregister, etc, etc. But, current ALSA SoC code is very random, unbalance, not paired, etc. It is easy to create bug at the such code, and it will be difficult to debug. ALSA SoC has soc_bind_dai_link(), but its paired soc_unbind_dai_link() is not implemented. More confusable is that soc_remove_pcm_runtimes() which should be soc_unbind_dai_link() is implemented without synchronised to soc_bind_dai_link(). This patch cleanup this unbalance. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/877e4e3jni.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
If we focus to soc_bind_dai_link() at snd_soc_instantiate_card(), we will notice very complex operation. static int snd_soc_instantiate_card(...) { ... /* * (1) Bind dai_link via card pre-linked dai_link * * Bind dai_link via card pre-linked. * 1 dai_link will be 1 rtd, and connected to card. * for_each_card_prelinks() is for card pre-linked dai_link. * * Image * * card * - rtd(A) * - rtd(A) */ for_each_card_prelinks(card, i, dai_link) { ret = soc_bind_dai_link(card, dai_link); ... } ... /* * (2) Connect card pre-linked dai_link to card list * * Connect all card pre-linked dai_link to *card list*. * Here, (A) means from card pre-linked. * * Image * * card card list * - rtd(A) - dai_link(A) * - rtd(A) - dai_link(A) * - ... - ... */ for_each_card_prelinks(card, i, dai_link) { ret = snd_soc_add_dai_link(card, dai_link); ... } ... /* * (3) Probe binded component * * Each rtd has many components. * Here probes each rtd connected components. * rtd(A) in Image is the probe target. * * During this component probe, topology may add new dai_link to * *card list* by using snd_soc_add_dai_link() which is * used at (2). * Here, (B) means from topology * * Image * * card card list * - rtd(A) - dai_link(A) * - rtd(A) - dai_link(A) * - ... - ... * - dai_link(B) * - dai_link(B) */ ret = soc_probe_link_components(card); ... /* * (4) Bind dai_link again * * Bind dai_link again for topology. * Note, (1) used for_each_card_prelinks(), * here is using for_each_card_links() * * This means from card list. * As Image indicating, it has dai_link(A) (from card pre-link) * and dai_link(B) (from topology). * main target here is dai_link(B). * soc_bind_dai_link() ignores already used * dai_link (= dai_link(A)) * * Image * * card card list * - rtd(A) - dai_link(A) * - rtd(A) - dai_link(A) * - ... - ... * - rtd(B) - dai_link(B) * - rtd(B) - dai_link(B) */ for_each_card_links(card, dai_link) { ret = soc_bind_dai_link(card, dai_link); ... } ... } As you see above, it is doing very complex method. The problem is binding dai_link via "card pre-linked" (= (1)) and "topology added dai_link" (= (3)) are separated. The code can be simple if we can bind dai_link when dai_link is connected to *card list*. This patch do it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/878sou3jnn.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
soc_is_dai_link_bound() check will be called both *before* soc_bind_dai_link() (A), and *under* soc_bind_dai_link() (B). These are very verbose code. Let's remove one of them. * static int soc_bind_dai_link(...) { ... (B) if (soc_is_dai_link_bound(...)) { ... return 0; } ... } static int snd_soc_instantiate_card(...) { ... for_each_card_links(...) { (A) if (soc_is_dai_link_bound(...)) continue; * ret = soc_bind_dai_link(...); if (ret) goto probe_end; } ... } Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87a79a3jns.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87bltq3jo7.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
soc_init_dai_link() is needed to be called before soc_bind_dai_link(). int snd_soc_instantiate_card() { for_each_card_prelinks(...) { (1) ret = soc_init_dai_link(...); ... } ... for_each_card_prelinks(...) { (2) ret = soc_bind_dai_link(...); ... } ... for_each_card_links(...) { ... (A) ret = soc_init_dai_link(...); ... (B) ret = soc_bind_dai_link(...); } ... (1) is for (2), and (A) is for (B) (1) and (2) are for card prelink dai_link. (A) and (B) are for topology added dai_link. soc_init_dai_link() is sanity check for dai_link, not initializing today. Therefore, it is confusable naming. We can rename it as sanity_check. And this check is for soc_bind_dai_link(). It can be more simple code if we can call it from soc_bind_dai_link(). This patch renames it to soc_dai_link_sanity_check(), and call it from soc_bind_dai_link(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87d0e63joh.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
This patch moves soc_init_dai_link() next to soc_bind_dai_link(). This is prepare for soc_bind_dai_link() cleanup. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87eeym3joq.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Maxime Ripard authored
The ADAU7118 has an example where the codec has an i2c address of 14, and the unit address set to 14 as well. However, while the address is expressed in decimal, the unit-address is supposed to be in hexadecimal, which ends up with two different addresses that trigger a DTC warning. Fix this by setting the address to 0x14. Cc: Nuno Sá <nuno.sa@analog.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Fixes: 969d49b2 ("dt-bindings: asoc: Add ADAU7118 documentation") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105105615.21391-1-maxime@cerno.techSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ranjani Sridharan authored
Set trigger order for FE DAI links to SND_SOC_DPCM_TRIGGER_POST to trigger the BE DAI's before the FE DAI's. This prevents the xruns seen on playback pipelines using the link DMA. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191104224812.3393-3-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ranjani Sridharan authored
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST determine the order in which FE DAI and BE DAI are triggered. In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is triggered before the BE DAI and in the case of SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before the FE DAI. And this order remains the same irrespective of the trigger command. In the case of the SOF driver, during playback, the FW expects the BE DAI to be triggered before the FE DAI during the START trigger. The BE DAI trigger handles the starting of Link DMA and so it must be started before the FE DAI is started to prevent xruns during pause/release. This can be addressed by setting the trigger order for the FE dai link to SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger, the FW expects the FE DAI to be triggered before the BE DAI. Retaining the same order during the START and STOP commands, results in FW error as the DAI component in the FW is still active. The issue can be fixed by mirroring the trigger order of FE and BE DAI's during the START and STOP trigger. So, with the trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME and the BE DAI will be triggered first during the STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands and the FE DAI will be triggered first during the SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 04 Nov, 2019 15 commits
-
-
Pierre-Louis Bossart authored
The wrong dependency is used and the build can be broken Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-12-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
Geminilake machine drivers are only tested and recommended with SOF. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-11-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
The same driver is reused for 3 different configurations, but the driver will only be build if ApolloLake is selected. Fix and make sure each device can work without dependencies on others (useful for minimal configurations). Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-10-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
This option is only required with the Skylake platform driver, there is no reason to have this option in machine drivers. This is e.g. useless for SOF-based solutions. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-9-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
This option famously broke audio on Linus' laptop and the problem have not been fixed. Mark as DEPRECATED to avoid any ambiguity with distros. Use SOF if you need HDaudio support w/ the DSP enabled, e.g. for DMIC capture. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-8-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
So far we used select to use the relevant built-in/module options, but this led to blurring layers between core and Intel Kconfigs. Use def_tristate works just as well and removes Intel stuff from the code. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-7-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
updated solution to the problem reported with randconfig: CONFIG_SND_SOC_SOF_IMX depends on CONFIG_SND_SOC_SOF, but is in turn referenced by the sof-of-dev driver. This creates a reverse dependency that manifests in a link error when CONFIG_SND_SOC_SOF_OF is built-in but CONFIG_SND_SOC_SOF_IMX=m: sound/soc/sof/sof-of-dev.o:(.data+0x118): undefined reference to `sof_imx8_ops' use def_trisate to propagate the right settings without select. Fixes: f4df4e40 ("ASoC: SOF: imx8: Fix COMPILE_TEST error") Fixes: 202acc56 ("ASoC: SOF: imx: Add i.MX8 HW support") Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-6-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
Some distros select all possible options, despite existing warnings to be careful. This leads to e.g. user reports that the HDaudio codec and DMIC are not handled by SOF. Add an explicit menu item to unlock developer options, and make them dependent on CONFIG_EXPERT. Hopefully with this double-lock these options will only be selected by developers. GitHub issue: https://github.com/thesofproject/sof/issues/1885Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-5-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
This legacy driver is already deprecated, let's make sure there is no conflict with SOF. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-4-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
Some distros select all options blindly, which leads to confusion and bug reports. SOF does not fully support Broadwell due to firmware dependencies, the machine drivers can only support one option, and UCM/topology files are still being propagated to downstream distros, so make SOF on Broadwell an opt-in option that first require distros to opt-out of existing defaults. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204237 Fixes: f35bf70f ('ASoC: Intel: Make sure BDW based machine drivers build for SOF') Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-3-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
Some distros select all options blindly, which leads to confusion and bug reports. Since SOF does not support Baytrail-CR for now, and UCM/topology files are still being propagated to downstream distros, make SOF on Baytrail an opt-in option that first require distros to opt-out of existing defaults. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-2-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ranjani Sridharan authored
Remove the retry argument for the hda_dsp_wait_d0i3c_done() function and use the HDA_DSP_REG_POLL_RETRY_COUNT macro directly. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101170916.26517-4-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Naveen Manohar authored
Machine driver to enable RT5682 on SSP0, DMIC, HDMI and RT1011 AMP on SSP1 with 2 CH / 24 bit TDM Playback over 4 individual codecs and 4 CH / 24 bit Capture to provide feedback. Signed-off-by: Naveen Manohar <naveen.m@intel.com> Signed-off-by: Sathya Prakash M R <sathya.prakash.m.r@intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101171847.26767-3-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Naveen Manohar authored
Add match for CML m/c with RT1011 and RT5682 Signed-off-by: Naveen Manohar <naveen.m@intel.com> Signed-off-by: Sathya Prakash M R <sathya.prakash.m.r@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101171847.26767-2-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
zhong jiang authored
local variable "status" is not used. hence it is safe to remove and just return 0. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Link: https://lore.kernel.org/r/1572528855-25990-1-git-send-email-zhongjiang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 31 Oct, 2019 5 commits
-
-
Shuming Fan authored
There is no other code use the RT1011_INIT_REG_LEN definition, except rt1011_reg_init(). Hence, we remove it and fix the typo. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191031115446.21108-1-shumingf@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Shuming Fan authored
The driver will check the range for temperature_calib. It should be from 1 to 255. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191031115436.21055-1-shumingf@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Shuming Fan authored
There are unnecessary tabs inside some statements. It uses sapces instead. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191031115425.21003-1-shumingf@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Shuming Fan authored
If there is a wrong format setting, the driver will goto the end of the function directly. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191031115414.20951-1-shumingf@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Shuming Fan authored
The !component->card->instantiated statement should remove in kcontrol. It is no need to check the card->instantiated in kcontrol. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191031115401.20898-1-shumingf@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 30 Oct, 2019 4 commits
-
-
Shuming Fan authored
The btndet-delay device property could control the HW debounce time. It is easy to adjust the sensitivity of push button. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191030085556.14351-1-shumingf@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Shuming Fan authored
The sensitivity could improve by decreasing the HW debounce time and reduce the delay time of workequeue. This patch added a device property for HW debounce time control. We could change this value to tune the sensitivity of push button. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191030085533.14299-1-shumingf@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
snd_soc_tplg_component_remove() is pair of snd_soc_tplg_component_load(), and it is topology related cleanup function. The driver which called _load() needs to call _remove() by its responsibility. Today, skl-pcm and topology are the user, and these are calling both _load() and _remove(). soc-core doesn't need to call it. This patch remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/8736fbdnwt.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
This patch fixup this warning LINUX/sound/soc/codecs/rt5677-spi.c: In function ‘rt5677_spi_pcm_close’: LINUX/sound/soc/codecs/rt5677-spi.c:114:30: warning: unused variable ‘rtd’ [-Wunused-variable] struct snd_soc_pcm_runtime *rtd = substream->private_data; ^~~ Fixes: a0e0d135 ("ASoC: rt5677: Add a PCM device for streaming hotword via SPI") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87a79idajh.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 29 Oct, 2019 3 commits
-
-
Kai Vehmanen authored
Add support for using snd-hda-codec-hdmi driver for HDMI/DP instead of ASoC hdac-hdmi. This is aligned with how other HDA codecs are already handled. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191029134017.18901-10-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kai Vehmanen authored
Add support for using snd-hda-codec-hdmi driver for HDMI/DP instead of ASoC hdac-hdmi. This is aligned with how other HDA codecs are already handled. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191029134017.18901-9-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kai Vehmanen authored
Add support for using snd-hda-codec-hdmi driver for HDMI/DP instead of ASoC hdac-hdmi. This is aligned with how other HDA codecs are already handled. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191029134017.18901-8-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-