linux-2.6-microblaze.git
5 years agoASoC: SOF: Intel: implement runtime idle for CNL/APL
Kai Vehmanen [Tue, 2 Jul 2019 13:24:28 +0000 (16:24 +0300)]
ASoC: SOF: Intel: implement runtime idle for CNL/APL

Implement runtime idle for CNL/APL devices using similar runtime
PM idle logic as the Intel AZX HDA driver. If any HDA codecs are
powered when runtime suspend request comes, return -EBUSY. By doing
this, strict ordering is enforced between HDA codec and the HDA
controller.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190702132428.13129-4-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: SOF: add runtime idle callback
Kai Vehmanen [Tue, 2 Jul 2019 13:24:27 +0000 (16:24 +0300)]
ASoC: SOF: add runtime idle callback

Add ability to implement a SOF device level runtime idle callback.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190702132428.13129-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: hdac_hdmi: report codec link up/down status to bus
Kai Vehmanen [Tue, 2 Jul 2019 13:24:26 +0000 (16:24 +0300)]
ASoC: hdac_hdmi: report codec link up/down status to bus

Report codec power status to the HDA codec bus from runtime pm
suspend and resume callbacks. This is required to implement
runtime idle logic that relies on 'codec_powered' field of hdac_bus
to be maintained for all codecs.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190702132428.13129-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: SOF: debug: fix possible memory leak in sof_dfsentry_write()
Wei Yongjun [Fri, 5 Jul 2019 08:16:37 +0000 (08:16 +0000)]
ASoC: SOF: debug: fix possible memory leak in sof_dfsentry_write()

'string' is malloced in sof_dfsentry_write() and should be freed
before leaving from the error handling cases, otherwise it will cause
memory leak.

Fixes: 091c12e1f50c ("ASoC: SOF: debug: add new debugfs entries for IPC flood test")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20190705081637.157169-1-weiyongjun1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: sunxi: sun50i-codec-analog: Add earpiece
Luca Weiss [Wed, 3 Jul 2019 18:48:11 +0000 (20:48 +0200)]
ASoC: sunxi: sun50i-codec-analog: Add earpiece

This adds the necessary registers and audio routes to play audio using
the Earpiece, that's supported on the A64.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20190703184814.27191-1-luca@z3ntu.xyz
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rt5665: remove redundant assignment to variable idx
Colin Ian King [Fri, 5 Jul 2019 07:53:03 +0000 (08:53 +0100)]
ASoC: rt5665: remove redundant assignment to variable idx

The variable idx is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190705075303.14692-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: wcd9335: remove multiple defines.
Srinivas Kandagatla [Thu, 4 Jul 2019 16:54:10 +0000 (17:54 +0100)]
ASoC: wcd9335: remove multiple defines.

Found during review that there are multiple defines of same constants.
This patch removes them!

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20190704165410.7173-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: qdsp6: q6afe-dai: Add missing Slimbus0 audio route
Srinivas Kandagatla [Wed, 3 Jul 2019 12:31:02 +0000 (13:31 +0100)]
ASoC: qdsp6: q6afe-dai: Add missing Slimbus0 audio route

For some reason SLIMBus RX0 playback is not added to audio routes.
This patch adds the missing route.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20190703123102.12626-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: core: Return -ENOTSUPP from set_channel_map() if no operation provided
Srinivas Kandagatla [Wed, 3 Jul 2019 12:30:02 +0000 (13:30 +0100)]
ASoC: core: Return -ENOTSUPP from set_channel_map() if no operation provided

It makes it easier for common code to work with snd_soc_dai_set_channel_map()
by distinguishing between operation not being supported and an error.
This is done inline with others snd_soc_dai.* apis.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20190703123002.12427-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: meson: axg-tdm-formatter: add reset
Jerome Brunet [Wed, 3 Jul 2019 12:07:49 +0000 (14:07 +0200)]
ASoC: meson: axg-tdm-formatter: add reset

Add the optional reset line handling which is present on the new SoC
families, such as the g12a. Triggering this reset is not critical but
it helps solve a channel shift issue on the g12a.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20190703120749.32341-3-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: meson: axg-tdm-formatter: add reset to the bindings documentation
Jerome Brunet [Wed, 3 Jul 2019 12:07:48 +0000 (14:07 +0200)]
ASoC: meson: axg-tdm-formatter: add reset to the bindings documentation

Add an optional reset property to the tdm formatter bindings. The
dedicated reset line is present on some SoC families, such as the g12a.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20190703120749.32341-2-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: max98357a: avoid speaker pop when playback startup
Mac Chiang [Wed, 19 Jun 2019 10:18:33 +0000 (18:18 +0800)]
ASoC: max98357a: avoid speaker pop when playback startup

Loud speaker pop happens during playback even when in slience
playback. Specify Max98357a amp delay times to make sure
clocks are always earlier than sdmode on.

Signed-off-by: Mac Chiang <mac.chiang@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: pxa: pxa2xx-ac97.c: use devm_snd_soc_register_component()
Kuninori Morimoto [Fri, 28 Jun 2019 04:10:31 +0000 (13:10 +0900)]
ASoC: pxa: pxa2xx-ac97.c: use devm_snd_soc_register_component()

We have devm_xxx version of snd_soc_register_component,
let's use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: cros_ec_codec: use devm_snd_soc_register_component()
Kuninori Morimoto [Fri, 28 Jun 2019 04:09:50 +0000 (13:09 +0900)]
ASoC: cros_ec_codec: use devm_snd_soc_register_component()

We have devm_xxx version of snd_soc_register_component,
let's use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: ak4118: use devm_snd_soc_register_component()
Kuninori Morimoto [Fri, 28 Jun 2019 04:09:40 +0000 (13:09 +0900)]
ASoC: ak4118: use devm_snd_soc_register_component()

We have devm_xxx version of snd_soc_register_component,
let's use it.

This patch also removes related empty functions

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rt5682: use devm_snd_soc_register_component()
Kuninori Morimoto [Fri, 28 Jun 2019 04:09:28 +0000 (13:09 +0900)]
ASoC: rt5682: use devm_snd_soc_register_component()

We have devm_xxx version of snd_soc_register_component,
let's use it.

This patch also removes related empty functions

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: cirrus: ep93xx-i2s.c: use devm_snd_soc_register_component()
Kuninori Morimoto [Fri, 28 Jun 2019 04:09:00 +0000 (13:09 +0900)]
ASoC: cirrus: ep93xx-i2s.c: use devm_snd_soc_register_component()

We have devm_xxx version of snd_soc_register_component,
let's use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: au1x: psc-i2s.c: use devm_snd_soc_register_component()
Kuninori Morimoto [Fri, 28 Jun 2019 04:08:48 +0000 (13:08 +0900)]
ASoC: au1x: psc-i2s.c: use devm_snd_soc_register_component()

We have devm_xxx version of snd_soc_register_component,
let's use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rt1308: Fix platform_no_drv_owner.cocci warnings
YueHaibing [Tue, 2 Jul 2019 06:17:38 +0000 (06:17 +0000)]
ASoC: rt1308: Fix platform_no_drv_owner.cocci warnings

Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: madera: Remove duplicated include from cs47l35.c
YueHaibing [Sat, 29 Jun 2019 02:43:33 +0000 (02:43 +0000)]
ASoC: madera: Remove duplicated include from cs47l35.c

Remove duplicated include.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rt1308: Add RT1308 amplifier driver
Derek Fang [Fri, 28 Jun 2019 12:51:43 +0000 (20:51 +0800)]
ASoC: rt1308: Add RT1308 amplifier driver

This is the initial amplifier driver for rt1308.

Signed-off-by: Derek Fang <derek.fang@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: soc-utils: respawn dummy Platform
Kuninori Morimoto [Fri, 28 Jun 2019 01:50:04 +0000 (10:50 +0900)]
ASoC: soc-utils: respawn dummy Platform

commit 64ee5067cf64 ("ASoC: soc-utils: remove dummy Platform") removed
dummy Platform from ALSA SoC, but it is over-kill.
This patch respawn it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rockchip: rk3399_gru_sound: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:52 +0000 (10:49 +0900)]
ASoC: rockchip: rk3399_gru_sound: consider CPU-Platform possibility

commit 961fb3c206dc ("ASoC: rockchip: rk3399_gru_sound: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 961fb3c206dc ("ASoC: rockchip: rk3399_gru_sound: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: qcom: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:48 +0000 (10:49 +0900)]
ASoC: qcom: consider CPU-Platform possibility

commit 0814c6412967 ("ASoC: qcom: don't select unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 0814c6412967 ("ASoC: qcom: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: simple-card-utils: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:44 +0000 (10:49 +0900)]
ASoC: simple-card-utils: consider CPU-Platform possibility

commit 6f0437445735 ("ASoC: simple-card-utils: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 6f0437445735 ("ASoC: simple-card-utils: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: ux500: mop500: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:40 +0000 (10:49 +0900)]
ASoC: ux500: mop500: consider CPU-Platform possibility

commit 9ae6cdb184b6 ("ASoC: ux500: mop500: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 9ae6cdb184b6 ("ASoC: ux500: mop500: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: ti: rx51: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:34 +0000 (10:49 +0900)]
ASoC: ti: rx51: consider CPU-Platform possibility

commit f0edc6c1ee48 ("ASoC: ti: rx51: don't select unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit f0edc6c1ee48 ("ASoC: ti: rx51: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: ti: omap-twl4030: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:30 +0000 (10:49 +0900)]
ASoC: ti: omap-twl4030: consider CPU-Platform possibility

commit bfe1273c65e1 ("ASoC: ti: omap-twl4030: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit bfe1273c65e1 ("ASoC: ti: omap-twl4030: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: ti: omap-hdmi: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:26 +0000 (10:49 +0900)]
ASoC: ti: omap-hdmi: consider CPU-Platform possibility

commit edba13aeae88 ("ASoC: ti: omap-hdmi: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit edba13aeae88 ("ASoC: ti: omap-hdmi: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: ti: omap-abe-twl6040: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:22 +0000 (10:49 +0900)]
ASoC: ti: omap-abe-twl6040: consider CPU-Platform possibility

commit 1306ab2eddd1 ("ASoC: ti: omap-abe-twl6040: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 1306ab2eddd1 ("ASoC: ti: omap-abe-twl6040: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: ti: davinci-evm: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:18 +0000 (10:49 +0900)]
ASoC: ti: davinci-evm: consider CPU-Platform possibility

commit f46da1b9046e ("ASoC: ti: davinci-evm: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit f46da1b9046e ("ASoC: ti: davinci-evm: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: trimslice: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:14 +0000 (10:49 +0900)]
ASoC: tegra: trimslice: consider CPU-Platform possibility

commit 567b374d9973 ("ASoC: tegra: trimslice: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 567b374d9973 ("ASoC: tegra: trimslice: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: tegra_wm9712: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:10 +0000 (10:49 +0900)]
ASoC: tegra: tegra_wm9712: consider CPU-Platform possibility

commit 5d62677238e9 ("ASoC: tegra: tegra_wm9712: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 5d62677238e9 ("ASoC: tegra: tegra_wm9712: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: tegra_wm8903: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:06 +0000 (10:49 +0900)]
ASoC: tegra: tegra_wm8903: consider CPU-Platform possibility

commit b28d98527157 ("ASoC: tegra: tegra_wm8903: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit b28d98527157 ("ASoC: tegra: tegra_wm8903: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: tegra_wm8753: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:49:02 +0000 (10:49 +0900)]
ASoC: tegra: tegra_wm8753: consider CPU-Platform possibility

commit 404b229b84af ("ASoC: tegra: tegra_wm8753: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 404b229b84af ("ASoC: tegra: tegra_wm8753: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: tegra_sgtl5000: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:58 +0000 (10:48 +0900)]
ASoC: tegra: tegra_sgtl5000: consider CPU-Platform possibility

commit cee1cf3f9f9e ("ASoC: tegra: tegra_sgtl5000: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit cee1cf3f9f9e ("ASoC: tegra: tegra_sgtl5000: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: tegra_rt5677: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:53 +0000 (10:48 +0900)]
ASoC: tegra: tegra_rt5677: consider CPU-Platform possibility

commit d035d13b2277 ("ASoC: tegra: tegra_rt5677: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit d035d13b2277 ("ASoC: tegra: tegra_rt5677: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: tegra_rt5640: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:49 +0000 (10:48 +0900)]
ASoC: tegra: tegra_rt5640: consider CPU-Platform possibility

commit 1d641e1523ca ("ASoC: tegra: tegra_rt5640: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 1d641e1523ca ("ASoC: tegra: tegra_rt5640: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: tegra_max98090: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:45 +0000 (10:48 +0900)]
ASoC: tegra: tegra_max98090: consider CPU-Platform possibility

commit 4bfd08540b44 ("ASoC: tegra: tegra_max98090: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 4bfd08540b44 ("ASoC: tegra: tegra_max98090: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: tegra: tegra_alc5632: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:40 +0000 (10:48 +0900)]
ASoC: tegra: tegra_alc5632: consider CPU-Platform possibility

commit e7fc99e641da ("ASoC: tegra: tegra_alc5632: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit e7fc99e641da ("ASoC: tegra: tegra_alc5632: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: sunxi: sun4i-codec: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:35 +0000 (10:48 +0900)]
ASoC: sunxi: sun4i-codec: consider CPU-Platform possibility

commit 3f780533bac9 ("ASoC: sunxi: sun4i-codec: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 3f780533bac9 ("ASoC: sunxi: sun4i-codec: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: sirf: sirf-audio: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:31 +0000 (10:48 +0900)]
ASoC: sirf: sirf-audio: consider CPU-Platform possibility

commit e562a5f13c94 ("ASoC: sirf: sirf-audio: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit e562a5f13c94 ("ASoC: sirf: sirf-audio: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: samsung: tm2_wm5110: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:27 +0000 (10:48 +0900)]
ASoC: samsung: tm2_wm5110: consider CPU-Platform possibility

commit ae7cbcc43b8c ("ASoC: samsung: tm2_wm5110: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit ae7cbcc43b8c ("ASoC: samsung: tm2_wm5110: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: samsung: snow: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:23 +0000 (10:48 +0900)]
ASoC: samsung: snow: consider CPU-Platform possibility

commit a555b6a959e6 ("ASoC: samsung: snow: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit a555b6a959e6 ("ASoC: samsung: snow: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: samsung: smdk_wm8994: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:19 +0000 (10:48 +0900)]
ASoC: samsung: smdk_wm8994: consider CPU-Platform possibility

commit d815e0f08fdd ("ASoC: samsung: smdk_wm8994: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit d815e0f08fdd ("ASoC: samsung: smdk_wm8994: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: samsung: arndale_rt5631: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:15 +0000 (10:48 +0900)]
ASoC: samsung: arndale_rt5631: consider CPU-Platform possibility

commit 33949eb5019d ("ASoC: samsung: arndale_rt5631: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 33949eb5019d ("ASoC: samsung: arndale_rt5631: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rockchip: rockchip_rt5645: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:48:01 +0000 (10:48 +0900)]
ASoC: rockchip: rockchip_rt5645: consider CPU-Platform possibility

commit 27a37973a6f1 ("ASoC: rockchip: rockchip_rt5645: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 27a37973a6f1 ("ASoC: rockchip: rockchip_rt5645: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rockchip: rockchip_max98090: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:57 +0000 (10:47 +0900)]
ASoC: rockchip: rockchip_max98090: consider CPU-Platform possibility

commit 7df405ae5895 ("ASoC: rockchip: rockchip_max98090: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 7df405ae5895 ("ASoC: rockchip: rockchip_max98090: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rockchip: rk3288_hdmi_analog: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:54 +0000 (10:47 +0900)]
ASoC: rockchip: rk3288_hdmi_analog: consider CPU-Platform possibility

commit 9c21e82c165c ("ASoC: rockchip: rk3288_hdmi_analog: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 9c21e82c165c ("ASoC: rockchip: rk3288_hdmi_analog: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: qcom: storm: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:50 +0000 (10:47 +0900)]
ASoC: qcom: storm: consider CPU-Platform possibility

commit 3caf11fa88a9 ("ASoC: qcom: storm: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 3caf11fa88a9 ("ASoC: qcom: storm: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: qcom: apq8016_sbc: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:46 +0000 (10:47 +0900)]
ASoC: qcom: apq8016_sbc: consider CPU-Platform possibility

commit 564684387969 ("ASoC: qcom: apq8016_sbc: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 564684387969 ("ASoC: qcom: apq8016_sbc: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: mxs: mxs-sgtl5000: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:42 +0000 (10:47 +0900)]
ASoC: mxs: mxs-sgtl5000: consider CPU-Platform possibility

commit 5f92229d184b ("ASoC: mxs: mxs-sgtl5000: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 5f92229d184b ("ASoC: mxs: mxs-sgtl5000: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: kirkwood: armada-370-db: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:38 +0000 (10:47 +0900)]
ASoC: kirkwood: armada-370-db: consider CPU-Platform possibility

commit 717f16331712 ("ASoC: kirkwood: armada-370-db: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 717f16331712 ("ASoC: kirkwood: armada-370-db: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: fsl: imx-audmix: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:35 +0000 (10:47 +0900)]
ASoC: fsl: imx-audmix: consider CPU-Platform possibility

commit d8893261a7d32 ("ASoC: fsl: imx-audmix: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit d8893261a7d32 ("ASoC: fsl: imx-audmix: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: fsl: imx-spdif: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:30 +0000 (10:47 +0900)]
ASoC: fsl: imx-spdif: consider CPU-Platform possibility

commit 014f07ca1cb12 ("ASoC: fsl: imx-spdif: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 014f07ca1cb12 ("ASoC: fsl: imx-spdif: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: fsl: imx-sgtl5000: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:26 +0000 (10:47 +0900)]
ASoC: fsl: imx-sgtl5000: consider CPU-Platform possibility

commit 82bf78ca49a3 ("ASoC: fsl: imx-sgtl5000: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 82bf78ca49a3 ("ASoC: fsl: imx-sgtl5000: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: fsl: imx-es8328: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:22 +0000 (10:47 +0900)]
ASoC: fsl: imx-es8328: consider CPU-Platform possibility

commit 577cf50d4dc8 ("ASoC: fsl: imx-es8328: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 577cf50d4dc8 ("ASoC: fsl: imx-es8328: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: fsl: fsl-asoc-card: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:18 +0000 (10:47 +0900)]
ASoC: fsl: fsl-asoc-card: consider CPU-Platform possibility

commit e57a4c2f15df27 ("ASoC: fsl: fsl-asoc-card: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit e57a4c2f15df27 ("ASoC: fsl: fsl-asoc-card: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: fsl: eukrea-tlv320: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:14 +0000 (10:47 +0900)]
ASoC: fsl: eukrea-tlv320: consider CPU-Platform possibility

commit 2058ea1c4f514a ("ASoC: fsl: eukrea-tlv320: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 2058ea1c4f514a ("ASoC: fsl: eukrea-tlv320: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: atmel: tse850-pcm5142: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:10 +0000 (10:47 +0900)]
ASoC: atmel: tse850-pcm5142: consider CPU-Platform possibility

commit 655368dfc75e8 ("ASoC: atmel: tse850-pcm5142: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 655368dfc75e8 ("ASoC: atmel: tse850-pcm5142: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: atmel: sam9x5_wm8731: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:06 +0000 (10:47 +0900)]
ASoC: atmel: sam9x5_wm8731: consider CPU-Platform possibility

commit ced5b08020cd ("ASoC: atmel: sam9x5_wm8731: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit ced5b08020cd ("ASoC: atmel: sam9x5_wm8731: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: atmel: sam9g20_wm8731: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:47:02 +0000 (10:47 +0900)]
ASoC: atmel: sam9g20_wm8731: consider CPU-Platform possibility

commit bfc7938e58142a5 ("ASoC: atmel: sam9g20_wm8731: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit bfc7938e58142a5 ("ASoC: atmel: sam9g20_wm8731: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: amtel: mikroe-proto: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:46:49 +0000 (10:46 +0900)]
ASoC: amtel: mikroe-proto: consider CPU-Platform possibility

commit 318ebbe8060d96 ("ASoC: atmel: mikroe-proto: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 318ebbe8060d96 ("ASoC: atmel: mikroe-proto: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: atmel: atmel_wm8904: consider CPU-Platform possibility unnecessary Platform"
Kuninori Morimoto [Fri, 28 Jun 2019 01:46:37 +0000 (10:46 +0900)]
ASoC: atmel: atmel_wm8904: consider CPU-Platform possibility unnecessary Platform"

commit 3609750e9d4ba9db ("ASoC: atmel: atmel_wm8904: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 3609750e9d4ba9db ("ASoC: atmel: atmel_wm8904: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: atmel: atmel-pdmic: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:46:24 +0000 (10:46 +0900)]
ASoC: atmel: atmel-pdmic: consider CPU-Platform possibility

commit 7baf32e164da5d4 ("ASoC: atmel: atmel-pdmic: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 7baf32e164da5d4 ("ASoC: atmel: atmel-pdmic: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: atmel: atmel-classd: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:46:19 +0000 (10:46 +0900)]
ASoC: atmel: atmel-classd: consider CPU-Platform possibility

commit 02602401e5316 ("ASoC: atmel: atmel-classd: don't select
unnecessary Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 02602401e5316 ("ASoC: atmel: atmel-classd: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: vc4: vc4_htmi: consider CPU-Platform possibility
Kuninori Morimoto [Fri, 28 Jun 2019 01:46:14 +0000 (10:46 +0900)]
ASoC: vc4: vc4_htmi: consider CPU-Platform possibility

commit 6c6de1c9e2bf2 ("ASoC: vc4: vc4_hdmi: don't select unnecessary
Platform")

Current ALSA SoC avoid to add duplicate component to rtd,
and this driver was selecting CPU component as Platform component.
Thus, above patch removed Platform settings from this driver,
because it assumed these are same component.

But, some CPU driver is using generic DMAEngine, in such case, both
CPU component and Platform component will have same of_node/name.
In other words, there are some components which are different but
have same of_node/name.

In such case, Card driver definitely need to select Platform even
though it is same as CPU.
It is depends on CPU driver, but is difficult to know it from Card driver.
This patch reverts above patch.

Fixes: commit 6c6de1c9e2bf2 ("ASoC: vc4: vc4_hdmi: don't select unnecessary Platform")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: topology: fix memory leaks on sm, se and sbe
Colin Ian King [Thu, 27 Jun 2019 13:32:08 +0000 (14:32 +0100)]
ASoC: topology: fix memory leaks on sm, se and sbe

Currently when a kstrdup fails the error exit paths don't free
the allocations for sm, se and sbe.  This can be fixed by assigning
kc[i].private_value to these before doing the ksrtdup so that the error
exit path will be able to free these objects.

Addresses-Coverity: ("Resource leak")
Fixes: 9f90af3a9952 ("ASoC: topology: Consolidate and fix asoc_tplg_dapm_widget_*_create flow")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: atmel: atmel-pcm-dma.c: use devm_snd_dmaengine_pcm_register()
Kuninori Morimoto [Fri, 28 Jun 2019 04:07:05 +0000 (13:07 +0900)]
ASoC: atmel: atmel-pcm-dma.c: use devm_snd_dmaengine_pcm_register()

We have devm_xxx version of snd_dmaengine_pcm_register,
let's use it.

This patch also removes related empty functions

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: meson: axg-card: remove useless check on codec
Jerome Brunet [Fri, 28 Jun 2019 08:17:08 +0000 (10:17 +0200)]
ASoC: meson: axg-card: remove useless check on codec

While checking cpus before dereferencing the pointer is required, it is
not necessary for codecs. 'codec' can't possibly be NULL in the loop

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: soc-core: support dai_link with platforms_num != 1
Jerome Brunet [Thu, 27 Jun 2019 12:13:50 +0000 (14:13 +0200)]
ASoC: soc-core: support dai_link with platforms_num != 1

Add support platforms_num != 1 in dai_link. Initially, the main purpose of
this change was to make the platform optional in the dai_link, instead of
inserting the dummy platform driver.

This particular case had just been solved by Kuninori Morimoto with
commit 1d7689892878 ("ASoC: soc-core: allow no Platform on dai_link").

However, this change may still be useful for those who need multiple
platform components on a single dai_link (it solves one of the FIXME
note in soc-core)

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: soc-core: defer card registration if codec component is missing
Jerome Brunet [Thu, 27 Jun 2019 12:13:49 +0000 (14:13 +0200)]
ASoC: soc-core: defer card registration if codec component is missing

Like cpus and platforms, defer sound card initialization if the codec
component is missing when initializing the dai_link

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: codecs: ad193x: Reset used registers at probe
Codrin Ciubotariu [Thu, 27 Jun 2019 12:02:08 +0000 (15:02 +0300)]
ASoC: codecs: ad193x: Reset used registers at probe

Since the ad193x codecs have no software reset, we have to reinitialize the
registers after a hardware reset to assure no previous values are kept.

Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: codecs: ad193x: Group register initialization at probe
Codrin Ciubotariu [Thu, 27 Jun 2019 12:02:07 +0000 (15:02 +0300)]
ASoC: codecs: ad193x: Group register initialization at probe

Create a structure with the register initialization values at probe and
use it to initialize all the registers at once.

Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoMerge tag 'v5.2-rc6' into asoc-5.3
Mark Brown [Wed, 26 Jun 2019 11:39:34 +0000 (12:39 +0100)]
Merge tag 'v5.2-rc6' into asoc-5.3

Linux 5.2-rc6

5 years agoASoC: soc-core: don't use soc_find_component() at snd_soc_find_dai()
Kuninori Morimoto [Wed, 26 Jun 2019 01:40:59 +0000 (10:40 +0900)]
ASoC: soc-core: don't use soc_find_component() at snd_soc_find_dai()

commit b9f2e25c599bb ("ASoC: soc-core: use soc_find_component() at
snd_soc_find_dai()") used soc_find_component() at snd_soc_find_dai(),
but, some CPU driver has CPU component for DAI and Platform component,
for example generic DMAEngine component.
In such case, CPU component and Platform component have same
of_node / name.

Here soc_find_component() returns *1st* found component.
Thus, we shouldn't use soc_find_component() at snd_soc_find_dai().
This patch fixup this it, and add comment to indicate this limitation.

Fixes: commit b9f2e25c599bb ("ASoC: soc-core: use soc_find_component() at snd_soc_find_dai()")
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rsnd: add missing pin sharing with SSI9
Kuninori Morimoto [Wed, 26 Jun 2019 02:00:05 +0000 (11:00 +0900)]
ASoC: rsnd: add missing pin sharing with SSI9

When SSI9 is sharing pin with SSI0, we need to care about it,
but is missing. This patch fixup it.

Reported-by: Hien Dang <hien.dang.eb@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Chaoliang Qin <chaoliang.qin.jg@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rsnd: ssiu: tidyup SSI_MODE1/2 settings
Kuninori Morimoto [Wed, 26 Jun 2019 01:58:56 +0000 (10:58 +0900)]
ASoC: rsnd: ssiu: tidyup SSI_MODE1/2 settings

R-Car Sound can use pin sharing and multi-SSI for
SSI0/1/2/3/4/9.
Because complex HW settings and spaghetti code,
the settings for SSI9 pin sharing with SSI0 doesn't work.

This patch tidyup settings for it.

Reported-by: Hien Dang <hien.dang.eb@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Chaoliang Qin <chaoliang.qin.jg@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: madera: Update SPDX headers
Charles Keepax [Tue, 25 Jun 2019 15:37:27 +0000 (16:37 +0100)]
ASoC: madera: Update SPDX headers

The madera driver was merged too late to catch Thomas Gleixner's cleanup
of the SPDX headers tree wide. Update the headers to match what was done
in that patch.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Strip T and L from TLV IPCs
Kamil Lulko [Thu, 13 Jun 2019 19:04:36 +0000 (21:04 +0200)]
ASoC: Intel: Skylake: Strip T and L from TLV IPCs

cAVS modules do not require Type and Length header within the
set_module_params IPC. This is also true for Vendor modules. The
userspace (like tinymix) always appends this header to TLV controls
which are used for set_module_params. Simply assume this header is
always present in the payload and omit it from the IPC.

Signed-off-by: Kamil Lulko <kamilx.lulko@intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Reset pipeline before its deletion
Amadeusz Sławiński [Thu, 13 Jun 2019 19:04:35 +0000 (21:04 +0200)]
ASoC: Intel: Skylake: Reset pipeline before its deletion

Before actual deletion, pipeline should enter RESET state. Currently,
pipe skips this checkpoint and goes straight to the finish line.
This is not the expected path by the FW, so correct it.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Common: Fix NULL dereference in tx_wait_done
Cezary Rojewski [Thu, 13 Jun 2019 19:04:34 +0000 (21:04 +0200)]
ASoC: Intel: Common: Fix NULL dereference in tx_wait_done

rx_data and rx_bytes present for tx_wait_done are optional parameters.
If not provided, function should not attempt to copy received data.
This change fixes memcpy NULL pointer dereference issue occurring when
optional rx_data is NULL while received message size is non-zero.

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Fix race condition in IPC rx list
Gustaw Lewandowski [Thu, 13 Jun 2019 19:04:33 +0000 (21:04 +0200)]
ASoC: Intel: Fix race condition in IPC rx list

Since there are multiple IPCs being sent in a short span of time, there
is a possibility of more than one message being on the Rx list after
receiving response from firmware. In such cases, when the first
notification of interrupt from firmware is received, driver retrieves
the message from the Rx list but does not delete it from the list till
the next lock. In the meantime, when another interrupt is received from
the firmware, driver is reading the previous message again since the
previous message has not been removed from the list.

Signed-off-by: Gustaw Lewandowski <gustaw.lewandowski@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Read HIPCT extension before clearing DONE bit
Cezary Rojewski [Thu, 13 Jun 2019 19:04:32 +0000 (21:04 +0200)]
ASoC: Intel: Skylake: Read HIPCT extension before clearing DONE bit

Host clears DONE bit to signal IPC target it has completed the
operation. Once this is done, IPC target i.e. DSP may proceed with the
next reply, filling registers with new portion of data.

Because of this, host should always read all registers prior to clearing
DONE and BUSY bits to ensure no desynchronization happens the time in
between clearing bits and reading message data (here, extension).

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: topology: Consolidate and fix asoc_tplg_dapm_widget_*_create flow
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:44 +0000 (13:36 +0200)]
ASoC: topology: Consolidate and fix asoc_tplg_dapm_widget_*_create flow

There are a few soc_tplg_dapm_widget_*_create functions with similar
content, but slightly different flow, unify their flow and make sure
that we go to error handler and free memory in case of failure.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Acked-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: topology: Consolidate how dtexts and dvalues are freed
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:43 +0000 (13:36 +0200)]
ASoC: topology: Consolidate how dtexts and dvalues are freed

Provide helper functions and use them to free dtexts and dvalues in
topology. This is followup cleanup after related changes in this area as
suggested in:
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-January/144761.html

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: hdac_hdmi: Set ops to NULL on remove
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:42 +0000 (13:36 +0200)]
ASoC: Intel: hdac_hdmi: Set ops to NULL on remove

When we unload Skylake driver we may end up calling
hdac_component_master_unbind(), it uses acomp->audio_ops, which we set
in hdmi_codec_probe(), so we need to set it to NULL in hdmi_codec_remove(),
otherwise we will dereference no longer existing pointer.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Fix NULL ptr dereference when unloading clk dev
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:41 +0000 (13:36 +0200)]
ASoC: Intel: Skylake: Fix NULL ptr dereference when unloading clk dev

When driver is probed, we iterate over NHLT and check if clk entries are
present. For each such entry we call register_skl_clk and keep the
result in data->clk[].
Currently data->clk is sparsely indexed using NHLT table iterator, while
when freeing we use number of registered entries. Let's just use
data->avail_clk_cnt as index, so it can be reset back in
unregister_src_clk.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Properly cleanup on component removal
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:40 +0000 (13:36 +0200)]
ASoC: Intel: Skylake: Properly cleanup on component removal

When we remove component we need to reverse things which were done on
init, this consists of topology cleanup, lists cleanup and releasing
firmware.

Currently cleanup handlers are put in wrong places or otherwise missing.
So add proper component cleanup function and perform cleanups in it.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Add function to cleanup debugfs interface
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:39 +0000 (13:36 +0200)]
ASoC: Intel: Skylake: Add function to cleanup debugfs interface

Currently debugfs has no cleanup function. Add skl_debufs_exit function
so we can clean after ourselves properly.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Don't return failure on machine driver reload
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:37 +0000 (13:36 +0200)]
ASoC: Intel: Skylake: Don't return failure on machine driver reload

When we unload and reload machine driver, we shouldn't return that we
failed to initialize. This allows to reload machine driver, without
having to unload whole stack.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: compress: Fix memory leak from snd_soc_new_compress
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:36 +0000 (13:36 +0200)]
ASoC: compress: Fix memory leak from snd_soc_new_compress

Change kzalloc to devm_kzalloc, so compr gets automatically freed when
it's no longer needed.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoALSA: hdac: Fix codec name after machine driver is unloaded and reloaded
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:35 +0000 (13:36 +0200)]
ALSA: hdac: Fix codec name after machine driver is unloaded and reloaded

Currently on each driver reload internal counter is being increased. It
causes failure to enumerate driver devices, as they have hardcoded:
.codec_name = "ehdaudio0D2",
As there is currently no devices with multiple hda codecs and there is
currently no established way to reliably differentiate, between them,
always assign bus->idx = 0;

This fixes a problem when we unload and reload machine driver idx gets
incremented, so .codec_name would've needed to be set to "ehdaudio1D2"
after first reload and so on.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Initialize lists before access so they are safe to use
Amadeusz Sławiński [Mon, 17 Jun 2019 11:36:34 +0000 (13:36 +0200)]
ASoC: Intel: Skylake: Initialize lists before access so they are safe to use

If skl_probe_work() was not run driver ends up dereferencing NULL
pointer when operating on lists in skl_platform_unregister().
To fix this initialize lists in skl_create(). Also run
cancel_work_sync() before all cleanup functions, so we don't end up
unnecessarily running probe work.

Easily reproducible with:
while true; do modprobe snd_soc_skl; rmmod snd_soc_skl; done
(with the assumption that relevant drivers are added to blacklist on
system boot)

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: Intel: Skylake: Use recommended SDxFMT programming sequence
Paweł Harłoziński [Thu, 13 Jun 2019 19:04:31 +0000 (21:04 +0200)]
ASoC: Intel: Skylake: Use recommended SDxFMT programming sequence

For BXT platforms, the recommended sequence to program the SDxFMT is to
first couple the stream, write the format and decouple again.
For all other platforms said sequence remains unchanged.

To prevent code duplication, IS_BXT (and consequently IS_CFL) macro is
relocated to hda_codec.h file so it can be accessed by SKL driver.

Signed-off-by: Paweł Harłoziński <pawel.harlozinski@intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rt5677: depop stereo dac
Curtis Malainey [Mon, 24 Jun 2019 20:52:39 +0000 (13:52 -0700)]
ASoC: rt5677: depop stereo dac

Upon enabling the ASRC DAC we need a delay to avoid popping the
speakers.

Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Cc: Ross Zwisler <zwisler@chromium.org>
Tested-by: Ross Zwisler <zwisler@google.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: rk3399_gru_sound: Support 32, 44.1 and 88.2 kHz sample rates
Enric Balletbo i Serra [Fri, 21 Jun 2019 15:58:08 +0000 (17:58 +0200)]
ASoC: rk3399_gru_sound: Support 32, 44.1 and 88.2 kHz sample rates

According to the datasheet the max98357a also supports 32, 44.1 and
88.2 kHz sample rate. This support was also introduced recently by
commit fdf34366d324 ("ASoC: max98357a: add missing supported rates").

Actually the machine driver validates the supported sample rates but
this is not really needed because the component driver can all apply
whatever constraints are needed and do their own validation. So, remove
the checks from the machine driver as are not needed at all. This way,
we also support 32, 44.1 and 88.2 kHz sample rates and we get rid of the
errors like the below.

  rk3399-gru-sound sound: rockchip_sound_max98357a_hw_params() doesn't support this sample rate: 44100
  rk3399-gru-sound sound: ASoC: machine hw_params failed: -22

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: soc-core: use soc_find_component() at snd_soc_find_dai()
Kuninori Morimoto [Thu, 20 Jun 2019 00:49:33 +0000 (09:49 +0900)]
ASoC: soc-core: use soc_find_component() at snd_soc_find_dai()

snd_soc_find_dai() finds component first via specified
snd_soc_dai_link_component, and find DAI from it.

We already have soc_find_component() to find component,
but soc_find_dai() has original implementation to find component.

We shouldn't have duplicate implementation to do same things.
This patch uses soc_find_component() at soc_find_dai()

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: soc-core: soc_find_component() uses snd_soc_dai_link_component
Kuninori Morimoto [Thu, 20 Jun 2019 00:49:27 +0000 (09:49 +0900)]
ASoC: soc-core: soc_find_component() uses snd_soc_dai_link_component

soc_find_component() is using "of_node" and "name" to finding component,
but we should use snd_soc_dai_link_component now, because it is created
to such purpose.

This patch uses snd_soc_dai_link_component for soc_find_component().

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
5 years agoASoC: soc-core: soc_find_component() uses snd_soc_is_matching_component()
Kuninori Morimoto [Thu, 20 Jun 2019 00:49:23 +0000 (09:49 +0900)]
ASoC: soc-core: soc_find_component() uses snd_soc_is_matching_component()

ALSA SoC already has snd_soc_is_matching_component() to confirming
matching component, but, soc_find_component() has original
implementation to confirm component.

We shouldn't have duplicate implementation to do same things.
This patch uses snd_soc_is_matching_component() at soc_find_component()

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>