platform/kernel/linux-starfive.git
4 years agoASoC: dapm: Expose snd_soc_dapm_new_control_unlocked properly
Amadeusz Sławiński [Tue, 27 Aug 2019 14:17:09 +0000 (16:17 +0200)]
ASoC: dapm: Expose snd_soc_dapm_new_control_unlocked properly

We use snd_soc_dapm_new_control_unlocked for topology and have local
declaration, instead declare it properly in header like already declared
snd_soc_dapm_new_control.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
Link: https://lore.kernel.org/r/20190827141712.21015-4-amadeuszx.slawinski@linux.intel.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: Intel: Fix use of potentially uninitialized variable
Amadeusz Sławiński [Tue, 27 Aug 2019 14:17:08 +0000 (16:17 +0200)]
ASoC: Intel: Fix use of potentially uninitialized variable

If ipc->ops.reply_msg_match is NULL, we may end up using uninitialized
mask value.

reported by smatch:
sound/soc/intel/common/sst-ipc.c:266 sst_ipc_reply_find_msg() error: uninitialized symbol 'mask'.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
Link: https://lore.kernel.org/r/20190827141712.21015-3-amadeuszx.slawinski@linux.intel.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
4 years agoASoC: Intel: Skylake: Use correct function to access iomem space
Amadeusz Sławiński [Tue, 27 Aug 2019 14:17:07 +0000 (16:17 +0200)]
ASoC: Intel: Skylake: Use correct function to access iomem space

For copying from __iomem, we should use __ioread32_copy.

reported by sparse:
sound/soc/intel/skylake/skl-debug.c:437:34: warning: incorrect type in argument 1 (different address spaces)
sound/soc/intel/skylake/skl-debug.c:437:34:    expected void [noderef] <asn:2> *to
sound/soc/intel/skylake/skl-debug.c:437:34:    got unsigned char *
sound/soc/intel/skylake/skl-debug.c:437:51: warning: incorrect type in argument 2 (different address spaces)
sound/soc/intel/skylake/skl-debug.c:437:51:    expected void const *from
sound/soc/intel/skylake/skl-debug.c:437:51:    got void [noderef] <asn:2> *[assigned] fw_reg_addr

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
Link: https://lore.kernel.org/r/20190827141712.21015-2-amadeuszx.slawinski@linux.intel.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
4 years agoASoC: AMD: Fix Kconfig warning without GPIOLIB
YueHaibing [Thu, 22 Aug 2019 14:30:07 +0000 (22:30 +0800)]
ASoC: AMD: Fix Kconfig warning without GPIOLIB

While do rand build without GPIOLIB, we get Kconfig warning:\

WARNING: unmet direct dependencies detected for SND_SOC_MAX98357A
  Depends on [n]: SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] && GPIOLIB [=n]
  Selected by [m]:
  - SND_SOC_AMD_CZ_DA7219MX98357_MACH [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_AMD_ACP [=m] && I2C [=y]

Add GPIOLIB dependency to fix this.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190822143007.73644-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: mchp-i2s-mcc: Wait for RX/TX RDY only if controller is running
Codrin Ciubotariu [Tue, 20 Aug 2019 16:24:10 +0000 (19:24 +0300)]
ASoC: mchp-i2s-mcc: Wait for RX/TX RDY only if controller is running

Since hw_free() can be called multiple times and not just after a stop
trigger command, we should check whether the RX or TX ready interrupt was
truly enabled previously. For this, we assure that the condition of the
wait event is always true, except when RX/TX interrupts are enabled.

Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Link: https://lore.kernel.org/r/20190820162411.24836-3-codrin.ciubotariu@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: mchp-i2s-mcc: Fix unprepare of GCLK
Codrin Ciubotariu [Tue, 20 Aug 2019 16:24:09 +0000 (19:24 +0300)]
ASoC: mchp-i2s-mcc: Fix unprepare of GCLK

If hw_free() gets called after hw_params(), GCLK remains prepared,
preventing further use of it. This patch fixes this by unpreparing the
clock in hw_free() or if hw_params() gets an error.

Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Link: https://lore.kernel.org/r/20190820162411.24836-2-codrin.ciubotariu@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: sun4i-i2s: Register regmap and PCM before our component
Maxime Ripard [Mon, 19 Aug 2019 19:25:08 +0000 (21:25 +0200)]
ASoC: sun4i-i2s: Register regmap and PCM before our component

So far the regmap and the dmaengine PCM are registered after our component
has been, which means that our driver isn't properly initialised by then.

Let's fix that.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/67e303f37f141ef73ce9ed47d7f831b63c694424.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: wm8904: implement input mode select as a mux
Michał Mirosław [Tue, 20 Aug 2019 11:02:37 +0000 (13:02 +0200)]
ASoC: wm8904: implement input mode select as a mux

Make '* Capture Mode' a mux. This makes DAPM know that in single-ended
mode only inverting mux paths need to be enabled.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/125cd3c9f298da9b08a4d6002d4c00d70a898950.1566298834.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: wm8904: fix typo in DAPM kcontrol name
Michał Mirosław [Tue, 20 Aug 2019 11:02:35 +0000 (13:02 +0200)]
ASoC: wm8904: fix typo in DAPM kcontrol name

Trivial fix for typo in "Capture Inverting Mux"es' name.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/f95ae1085f9f3c137a122c4d95728711613c15f7.1566298834.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: intel: cht_bsw_max98090_ti: Add all Chromebooks that need pmc_plt_clk_0 quirk
Daniel Stuart [Thu, 15 Aug 2019 17:12:55 +0000 (14:12 -0300)]
ASoC: intel: cht_bsw_max98090_ti: Add all Chromebooks that need pmc_plt_clk_0 quirk

Every single baytrail chromebook sets PMC to 0, as can be seeing
below by searching through coreboot source code:
$ grep -rl "PMC_PLT_CLK\[0\]" .
./rambi/variants/glimmer/devicetree.cb
./rambi/variants/clapper/devicetree.cb
./rambi/variants/swanky/devicetree.cb
./rambi/variants/enguarde/devicetree.cb
./rambi/variants/winky/devicetree.cb
./rambi/variants/kip/devicetree.cb
./rambi/variants/squawks/devicetree.cb
./rambi/variants/orco/devicetree.cb
./rambi/variants/ninja/devicetree.cb
./rambi/variants/heli/devicetree.cb
./rambi/variants/sumo/devicetree.cb
./rambi/variants/banjo/devicetree.cb
./rambi/variants/candy/devicetree.cb
./rambi/variants/gnawty/devicetree.cb
./rambi/variants/rambi/devicetree.cb
./rambi/variants/quawks/devicetree.cb

Plus, Cyan (only non-baytrail chromebook with max98090) also needs
this patch for audio to work.

Thus, this commit adds all the missing devices to bsw_max98090 quirk
table, implemented by commit a182ecd3809c ("ASoC: intel:
cht_bsw_max98090_ti: Add quirk for boards using pmc_plt_clk_0").

Signed-off-by: Daniel Stuart <daniel.stuart14@gmail.com>
Link: https://lore.kernel.org/r/20190815171300.30126-1-daniel.stuart14@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: meson: g12a-tohdmitx: require regmap mmio
Jerome Brunet [Tue, 20 Aug 2019 12:35:10 +0000 (14:35 +0200)]
ASoC: meson: g12a-tohdmitx: require regmap mmio

The tohdmitx glue uses regmap MMIO so it should require it.

Fixes: c8609f3870f7 ("ASoC: meson: add g12a tohdmitx control")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20190820123510.22491-1-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: meson: axg-tdm-formatter: free reset on device removal
Jerome Brunet [Tue, 20 Aug 2019 12:34:13 +0000 (14:34 +0200)]
ASoC: meson: axg-tdm-formatter: free reset on device removal

Use the devm variant to get the formatter reset so it is properly freed
on device removal

Fixes: 751bd5db5260 ("ASoC: meson: axg-tdm-formatter: add reset")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20190820123413.22249-1-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: uniphier: Fix double reset assersion when transitioning to suspend state
Kunihiko Hayashi [Tue, 20 Aug 2019 06:16:04 +0000 (15:16 +0900)]
ASoC: uniphier: Fix double reset assersion when transitioning to suspend state

When transitioning to supend state, uniphier_aio_dai_suspend() is called
and asserts reset lines and disables clocks.

However, if there are two or more DAIs, uniphier_aio_dai_suspend() are
called multiple times, and double reset assersion will cause.

This patch defines the counter that has the number of DAIs at first, and
whenever uniphier_aio_dai_suspend() are called, it decrements the
counter. And only if the counter is zero, it asserts reset lines and
disables clocks.

In the same way, uniphier_aio_dai_resume() are called, it increments the
counter after deasserting reset lines and enabling clocks.

Fixes: 139a34200233 ("ASoC: uniphier: add support for UniPhier AIO CPU DAI driver")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1566281764-14059-1-git-send-email-hayashi.kunihiko@socionext.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: imx-audmux: Add driver suspend and resume to support MEGA Fast
Shengjiu Wang [Fri, 16 Aug 2019 05:03:14 +0000 (01:03 -0400)]
ASoC: imx-audmux: Add driver suspend and resume to support MEGA Fast

For i.MX6 SoloX, there is a mode of the SoC to shutdown all power
source of modules during system suspend and resume procedure.
Thus, AUDMUX needs to save all the values of registers before the
system suspend and restore them after the system resume.

Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1565931794-7218-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: wm8737: Fix copy-paste error in wm8737_snd_controls
YueHaibing [Thu, 15 Aug 2019 09:19:20 +0000 (17:19 +0800)]
ASoC: wm8737: Fix copy-paste error in wm8737_snd_controls

sound/soc/codecs/wm8737.c:112:29: warning:
 high_3d defined but not used [-Wunused-const-variable=]

'high_3d' should be used for 3D High Cut-off.

Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 2a9ae13a2641 ("ASoC: Add initial WM8737 driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20190815091920.64480-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: cs4349: Use PM ops 'cs4349_runtime_pm'
YueHaibing [Thu, 15 Aug 2019 09:01:57 +0000 (17:01 +0800)]
ASoC: cs4349: Use PM ops 'cs4349_runtime_pm'

sound/soc/codecs/cs4349.c:358:32: warning:
 cs4349_runtime_pm defined but not used [-Wunused-const-variable=]

cs4349_runtime_pm ops already defined, it seems
we should enable it.

Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: e40da86 ("ASoC: cs4349: Add support for Cirrus Logic CS4349")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190815090157.70036-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: es8328: Fix copy-paste error in es8328_right_line_controls
YueHaibing [Thu, 15 Aug 2019 09:23:00 +0000 (17:23 +0800)]
ASoC: es8328: Fix copy-paste error in es8328_right_line_controls

It seems 'es8328_rline_enum' should be used
in es8328_right_line_controls

Fixes: 567e4f98922c ("ASoC: add es8328 codec driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190815092300.68712-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: rockchip: rockchip_max98090: Set period size to 240
Cheng-Yi Chiang [Tue, 13 Aug 2019 07:44:30 +0000 (15:44 +0800)]
ASoC: rockchip: rockchip_max98090: Set period size to 240

From stress testing of arecord, we found that period size
greater than ~900 will bring pl330 to DYING state and
can not recover within 100 iterations.
The result is that arecord will stuck and get I/O error,
and issue can not be recovered until reboot.

This issue does not happen when period size is small.
Set constraint of period size to 240 to prevent such issue.
With the constraint, there will be no issue after 2000 iterations.

We can revert this patch once the root cause is found
in rockchip's pl330 implementation.

Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Link: https://lore.kernel.org/r/20190813074430.191791-1-cychiang@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: Intel: sof-rt5682: add dmic dapm widget to support dmic PCM
Keyon Jie [Fri, 9 Aug 2019 23:22:34 +0000 (18:22 -0500)]
ASoC: Intel: sof-rt5682: add dmic dapm widget to support dmic PCM

We need add DAPM MIC endpoint widget "SoC DMIC" and route, to enable
DMIC PCM DAPM support.

Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190809232236.21182-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: hdac_hdmi: Offload dapm update at jack detection
Takashi Iwai [Fri, 9 Aug 2019 15:15:31 +0000 (17:15 +0200)]
ASoC: hdac_hdmi: Offload dapm update at jack detection

hdac_hdmi_present_sense() calls the audio component to get ELD update,
then it reports the jack status change and updates DAPM graph
accordingly.  This works when it's called from the normal code paths.

However, it may lead to a dead lock when it's called from the audio
component notifier.  Namely, the DAPM update involves with the runtime
PM, and it eventually calls again the audio component get_power()
ops.  Since i915 driver already takes a mutex around the audio
component ops calls, we'll eventually get the mutex doubly.

As a workaround, in this patch, only the jack state is updated in the
code path from hdac_hdmi_eld_notify_cb(), and the DAPM update is
deferred to a work so that it's processed in another context.

Reported-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190809151531.24359-1-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: hdac_hda: fix page fault issue by removing race
Keyon Jie [Wed, 7 Aug 2019 14:50:30 +0000 (09:50 -0500)]
ASoC: hdac_hda: fix page fault issue by removing race

There is a race between hda codec device removing and the
jack-detecting work, which will lead to a page fault issue as the
latter work is accessing codec device which could be already removed.

Here add the cancellation of jack-detecting work before codecs are actually
removed to avoid the race and fix the issue.

Bug: https://github.com/thesofproject/linux/issues/1067
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190807145030.26117-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: SOF: Intel: hda: Initialize HDA controller after i915 init
Ranjani Sridharan [Tue, 6 Aug 2019 22:19:58 +0000 (15:19 -0700)]
ASoC: SOF: Intel: hda: Initialize HDA controller after i915 init

On some platforms, sound card registration fails when a HDMI
monitor is not connected. This is caused by a recent commit
that switched the order in which the HDA controller and the
i915 are initialized. Initializing the i915 before initializing
the HDA controller fixes the problem.

Fixes: be1b577d01787c ("ASoC: SOF: Intel: hda: fix the hda init chip"
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190806221958.19180-1-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: rsnd: don't call clk_get_rate() under atomic context
Kuninori Morimoto [Tue, 6 Aug 2019 03:45:38 +0000 (12:45 +0900)]
ASoC: rsnd: don't call clk_get_rate() under atomic context

ADG is using clk_get_rate() under atomic context, thus, we might
have scheduling issue.
To avoid this issue, we need to get/keep clk rate under
non atomic context.

We need to handle ADG as special device at Renesas Sound driver.
From SW point of view, we want to impletent it as
rsnd_mod_ops :: prepare, but it makes code just complicate.

To avoid complicated code/patch, this patch adds new clk_rate[] array,
and keep clk IN rate when rsnd_adg_clk_enable() was called.

Reported-by: Leon Kong <Leon.KONG@cn.bosch.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Leon Kong <Leon.KONG@cn.bosch.com>
Link: https://lore.kernel.org/r/87v9vb0xkp.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: max98373: Remove executable bits
Mark Brown [Tue, 6 Aug 2019 10:15:06 +0000 (11:15 +0100)]
ASoC: max98373: Remove executable bits

Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: amd: acp3x: use dma address for acp3x dma driver
Vijendar Mukunda [Fri, 2 Aug 2019 13:51:24 +0000 (19:21 +0530)]
ASoC: amd: acp3x: use dma address for acp3x dma driver

We shouldn't assume CPU physical address we get from page_to_phys()
is same as DMA address we get from dma_alloc_coherent(). On x86_64,
we won't run into any problem with the assumption when dma_ops is
nommu_dma_ops. However, DMA address is IOVA when IOMMU is enabled.
And it's most likely different from CPU physical address when AMD
IOMMU is not in passthrough mode.

This patch fixes page faults when IOMMU is enabled.

Signed-off-by: Vijendar Mukunda <vijendar.mukunda@amd.com>
Link: https://lore.kernel.org/r/1564753899-17124-2-git-send-email-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: amd: acp3x: use dma_ops of parent device for acp3x dma driver
Vijendar Mukunda [Fri, 2 Aug 2019 13:51:23 +0000 (19:21 +0530)]
ASoC: amd: acp3x: use dma_ops of parent device for acp3x dma driver

AMD platform device acp3x_rv_i2s created by parent PCI device
driver. Pass struct device of the parent to
snd_pcm_lib_preallocate_pages() so dma_alloc_coherent() can use
correct dma_ops. Otherwise, it will use default dma_ops which
is nommu_dma_ops on x86_64 even when IOMMU is enabled and
set to non passthrough mode.

Signed-off-by: Vijendar Mukunda <vijendar.mukunda@amd.com>
Link: https://lore.kernel.org/r/1564753899-17124-1-git-send-email-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: max98373: add 88200 and 96000 sampling rate support
fengchunguo [Wed, 31 Jul 2019 07:41:56 +0000 (15:41 +0800)]
ASoC: max98373: add 88200 and 96000 sampling rate support

88200 and 96000 sampling rate was not enabled on driver, so can't be played.

The error information:
max98373 3-0031:rate 96000 not supported
max98373 3-0031:ASoC: can't set max98373-aif1 hw params: -22

Signed-off-by: fengchunguo <chunguo.feng@amlogic.com>
Link: https://lore.kernel.org/r/20190731074156.5620-1-chunguo.feng@amlogic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: sun4i-i2s: Incorrect SR and WSS computation
Marcus Cooper [Mon, 29 Jul 2019 15:21:30 +0000 (17:21 +0200)]
ASoC: sun4i-i2s: Incorrect SR and WSS computation

The A64 audio codec uses the original I2S block but the SR and
WSS computation currently assigned is for the newer block.

Fixes: 619c15f7fac9 (ASoC: sun4i-i2s: Change SR and WSS computation)
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Link: https://lore.kernel.org/r/20190729152130.27955-1-codekipper@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoMAINTAINERS: Update Intel ASoC drivers maintainers
Cezary Rojewski [Fri, 26 Jul 2019 18:15:17 +0000 (20:15 +0200)]
MAINTAINERS: Update Intel ASoC drivers maintainers

Adding myself to Intel ASoC drivers maintainers list.

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190726181517.27655-1-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: ti: davinci-mcasp: Correct slot_width posed constraint
Peter Ujfalusi [Fri, 26 Jul 2019 06:42:43 +0000 (09:42 +0300)]
ASoC: ti: davinci-mcasp: Correct slot_width posed constraint

The slot_width is a property for the bus while the constraint for
SNDRV_PCM_HW_PARAM_SAMPLE_BITS is for the in memory format.

Applying slot_width constraint to sample_bits works most of the time, but
it will blacklist valid formats in some cases.

With slot_width 24 we can support S24_3LE and S24_LE formats as they both
look the same on the bus, but a a 24 constraint on sample_bits would not
allow S24_LE as it is stored in 32bits in memory.

Implement a simple hw_rule function to allow all formats which require less
or equal number of bits on the bus as slot_width (if configured).

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20190726064244.3762-2-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: rockchip: Fix mono capture
Cheng-Yi Chiang [Fri, 26 Jul 2019 04:42:02 +0000 (12:42 +0800)]
ASoC: rockchip: Fix mono capture

This reverts commit db51707b9c9aeedd310ebce60f15d5bb006567e0.
Revert "ASoC: rockchip: i2s: Support mono capture"

Previous discussion in

https://patchwork.kernel.org/patch/10147153/

explains the issue of the patch.
While device is configured as 1-ch, hardware is still
generating a 2-ch stream.
When user space reads the data and assumes it is a 1-ch stream,
the rate will be slower by 2x.

Revert the change so 1-ch is not supported.
User space can selectively take one channel data out of two channel
if 1-ch is preferred.
Currently, both channels record identical data.

Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Link: https://lore.kernel.org/r/20190726044202.26866-1-cychiang@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: Intel: Fix some acpi vs apci typo in somme comments
Christophe JAILLET [Thu, 25 Jul 2019 05:35:23 +0000 (07:35 +0200)]
ASoC: Intel: Fix some acpi vs apci typo in somme comments

Fix some typo to have the filaname given in a comment match the real name
of the file.
Some 'acpi' have erroneously been written 'apci'

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20190725053523.16542-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: ti: davinci-mcasp: Fix clk PDIR handling for i2s master mode
Peter Ujfalusi [Thu, 25 Jul 2019 08:34:23 +0000 (11:34 +0300)]
ASoC: ti: davinci-mcasp: Fix clk PDIR handling for i2s master mode

When running McASP as master capture alone will not record any audio unless
a parallel playback stream is running. As soon as the playback stops the
captured data is going to be silent again.

In McASP master mode we need to set the PDIR for the clock pins and fix
the mcasp_set_axr_pdir() to skip the bits in the PDIR registers above
AMUTE.

This went unnoticed as most of the boards uses McASP as slave and neither
of these issues are visible (audible) in those setups.

Fixes: ca3d9433349e ("ASoC: davinci-mcasp: Update PDIR (pin direction) register handling")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20190725083423.7321-1-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: Fail card instantiation if DAI format setup fails
Ricard Wanderlof [Wed, 24 Jul 2019 09:38:44 +0000 (11:38 +0200)]
ASoC: Fail card instantiation if DAI format setup fails

If the DAI format setup fails, there is no valid communication format
between CPU and CODEC, so fail card instantiation, rather than continue
with a card that will most likely not function properly.

Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Link: https://lore.kernel.org/r/alpine.DEB.2.20.1907241132350.6338@lnxricardw1.se.axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: SOF: Intel: hda: remove misleading error trace from IRQ thread
Kai Vehmanen [Mon, 22 Jul 2019 14:14:01 +0000 (09:14 -0500)]
ASoC: SOF: Intel: hda: remove misleading error trace from IRQ thread

Downgrade "nothing to do in IRQ thread" message from error to a debug
message in the IPC interrupt handler thread.

The spurious wake-up can happen if a HDA stream interrupt is
raised while the IPC interrupt thread is running. IPC functionality
is not impacted by this condition, so debug is a more appropriate
trace level.

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/20190722141402.7194-21-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: qcom: apq8016_sbc: Fix oops with multiple DAI links
Stephan Gerhold [Mon, 22 Jul 2019 13:03:52 +0000 (15:03 +0200)]
ASoC: qcom: apq8016_sbc: Fix oops with multiple DAI links

apq8016_sbc_parse_of() sets up multiple DAI links, depending on the
number of nodes in the device tree. However, at the moment
CPU and platform components are only allocated for the first link.
This causes an oops when more than one link is defined:

Internal error: Oops: 96000044 [#1] SMP
CPU: 0 PID: 1015 Comm: kworker/0:2 Not tainted 5.3.0-rc1 #4
Call trace:
 apq8016_sbc_platform_probe+0x1a8/0x3f0
 platform_drv_probe+0x50/0xa0
...

Move the allocation inside the loop to ensure that each link is
properly initialized.

Fixes: 98b232ca9e0e ("ASoC: qcom: apq8016_sbc: use modern dai_link style")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20190722130352.95874-1-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: dapm: fix a memory leak bug
Wenwen Wang [Mon, 22 Jul 2019 13:57:44 +0000 (08:57 -0500)]
ASoC: dapm: fix a memory leak bug

In snd_soc_dapm_new_control_unlocked(), a kernel buffer is allocated in
dapm_cnew_widget() to hold the new dapm widget. Then, different actions are
taken according to the id of the widget, i.e., 'w->id'. If any failure
occurs during this process, snd_soc_dapm_new_control_unlocked() should be
terminated by going to the 'request_failed' label. However, the allocated
kernel buffer is not freed on this code path, leading to a memory leak bug.

To fix the above issue, free the buffer before returning from
snd_soc_dapm_new_control_unlocked() through the 'request_failed' label.

Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Link: https://lore.kernel.org/r/1563803864-2809-1-git-send-email-wang6495@umn.edu
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: SOF: use __u32 instead of uint32_t in uapi headers
Masahiro Yamada [Sun, 21 Jul 2019 14:23:08 +0000 (23:23 +0900)]
ASoC: SOF: use __u32 instead of uint32_t in uapi headers

When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
make sure they can be included from user-space.

Currently, header.h and fw.h are excluded from the test coverage.
To make them join the compile-test, we need to fix the build errors
attached below.

For a case like this, we decided to use __u{8,16,32,64} variable types
in this discussion:

  https://lkml.org/lkml/2019/6/5/18

Build log:

  CC      usr/include/sound/sof/header.h.s
  CC      usr/include/sound/sof/fw.h.s
In file included from <command-line>:32:0:
./usr/include/sound/sof/header.h:19:2: error: unknown type name ‘uint32_t’
  uint32_t magic;  /**< 'S', 'O', 'F', '\0' */
  ^~~~~~~~
./usr/include/sound/sof/header.h:20:2: error: unknown type name ‘uint32_t’
  uint32_t type;  /**< component specific type */
  ^~~~~~~~
./usr/include/sound/sof/header.h:21:2: error: unknown type name ‘uint32_t’
  uint32_t size;  /**< size in bytes of data excl. this struct */
  ^~~~~~~~
./usr/include/sound/sof/header.h:22:2: error: unknown type name ‘uint32_t’
  uint32_t abi;  /**< SOF ABI version */
  ^~~~~~~~
./usr/include/sound/sof/header.h:23:2: error: unknown type name ‘uint32_t’
  uint32_t reserved[4]; /**< reserved for future use */
  ^~~~~~~~
./usr/include/sound/sof/header.h:24:2: error: unknown type name ‘uint32_t’
  uint32_t data[0]; /**< Component data - opaque to core */
  ^~~~~~~~
In file included from <command-line>:32:0:
./usr/include/sound/sof/fw.h:49:2: error: unknown type name ‘uint32_t’
  uint32_t size;  /* bytes minus this header */
  ^~~~~~~~
./usr/include/sound/sof/fw.h:50:2: error: unknown type name ‘uint32_t’
  uint32_t offset; /* offset from base */
  ^~~~~~~~
./usr/include/sound/sof/fw.h:64:2: error: unknown type name ‘uint32_t’
  uint32_t size;  /* bytes minus this header */
  ^~~~~~~~
./usr/include/sound/sof/fw.h:65:2: error: unknown type name ‘uint32_t’
  uint32_t num_blocks; /* number of blocks */
  ^~~~~~~~
./usr/include/sound/sof/fw.h:73:2: error: unknown type name ‘uint32_t’
  uint32_t file_size; /* size of file minus this header */
  ^~~~~~~~
./usr/include/sound/sof/fw.h:74:2: error: unknown type name ‘uint32_t’
  uint32_t num_modules; /* number of modules */
  ^~~~~~~~
./usr/include/sound/sof/fw.h:75:2: error: unknown type name ‘uint32_t’
  uint32_t abi;  /* version of header format */
  ^~~~~~~~

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Link: https://lore.kernel.org/r/20190721142308.30306-1-yamada.masahiro@socionext.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoSoC: rockchip: rockchip_max98090: Enable MICBIAS for headset keypress detection
Enric Balletbo i Serra [Fri, 19 Jul 2019 17:39:29 +0000 (19:39 +0200)]
SoC: rockchip: rockchip_max98090: Enable MICBIAS for headset keypress detection

The TS3A227E says that the headset keypress detection needs the MICBIAS
power in order to report the key events to ensure proper operation
The headset keypress detection needs the MICBIAS power in order to report
the key events all the time as long as MIC is present. So MICBIAS pin
is forced on when a MICROPHONE is detected.

On Veyron Minnie I observed that if the MICBIAS power is not present and
the key press detection is activated (just because it is enabled when you
insert a headset), it randomly reports a keypress on insert.
E.g. (KEY_PLAYPAUSE)

 Event: (SW_HEADPHONE_INSERT), value 1
 Event: (SW_MICROPHONE_INSERT), value 1
 Event: -------------- SYN_REPORT ------------
 Event: (KEY_PLAYPAUSE), value 1

Userspace thinks that KEY_PLAYPAUSE is pressed and produces the annoying
effect that the media player starts a play/pause loop.

Note that, although most of the time the key reported is the one
associated with BTN_0, not always this is true. On my tests I also saw
different keys reported

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20190719173929.24065-1-enric.balletbo@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: cs42xx8: Fix MFREQ selection issue for async mode
Shengjiu Wang [Tue, 16 Jul 2019 09:45:47 +0000 (17:45 +0800)]
ASoC: cs42xx8: Fix MFREQ selection issue for async mode

When sample rate of TX is different with sample rate of RX in
async mode, the MFreq selection will be wrong.

For example, sysclk = 24.576MHz, TX rate = 96000Hz, RX rate = 48000Hz.
Then ratio of TX = 256, ratio of RX = 512, For MFreq is shared by TX
and RX instance, the correct value of MFreq is 2 for both TX and RX.

But original method will cause MFreq = 0 for TX, MFreq = 2 for RX.
If TX is started after RX, RX will be impacted, RX work abnormal with
MFreq = 0.

This patch is to select proper MFreq value according to TX rate and
RX rate.

Fixes: 0c516b4ff85c ("ASoC: cs42xx8: Add codec driver support for CS42448/CS42888")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/20190716094547.46787-1-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks
Charles Keepax [Thu, 18 Jul 2019 08:43:33 +0000 (09:43 +0100)]
ASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks

DPCM uses snd_soc_dapm_dai_get_connected_widgets to build a
list of the widgets connected to a specific front end DAI so it
can search through this list for available back end DAIs. The
custom_stop_condition was added to is_connected_ep to facilitate this
list not containing more widgets than is necessary. Doing so both
speeds up the DPCM handling as less widgets need to be searched and
avoids issues with CODEC to CODEC links as these would be confused
with back end DAIs if they appeared in the list of available widgets.

custom_stop_condition was implemented by aborting the graph walk
when the condition is triggered, however there is an issue with this
approach. Whilst walking the graph is_connected_ep should update the
endpoints cache on each widget, if the walk is aborted the number
of attached end points is unknown for that sub-graph. When the stop
condition triggered, the original patch ignored the triggering widget
and returned zero connected end points; a later patch updated this
to set the triggering widget's cache to 1 and return that. Both of
these approaches result in inaccurate values being stored in various
end point caches as the values propagate back through the graph,
which can result in later issues with widgets powering/not powering
unexpectedly.

As the original goal was to reduce the size of the widget list passed
to the DPCM code, the simplest solution is to limit the functionality
of the custom_stop_condition to the widget list. This means the rest
of the graph will still be processed resulting in correct end point
caches, but only widgets up to the stop condition will be added to the
returned widget list.

Fixes: 6742064aef7f ("ASoC: dapm: support user-defined stop condition in dai_get_connected_widgets")
Fixes: 5fdd022c2026 ("ASoC: dpcm: play nice with CODEC<->CODEC links")
Fixes: 09464974eaa8 ("ASoC: dapm: Fix to return correct path list in is_connected_ep.")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20190718084333.15598-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: Intel: bytcht_es8316: Add quirk for Irbis NB41 netbook
Hans de Goede [Fri, 12 Jul 2019 11:27:08 +0000 (13:27 +0200)]
ASoC: Intel: bytcht_es8316: Add quirk for Irbis NB41 netbook

The Irbis NB41 netbook has its internal mic on IN2, inverted jack-detect
and stereo speakers, add a quirk for this.

Cc: russianneuromancer@ya.ru
Reported-and-tested-by: russianneuromancer@ya.ru
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20190712112708.25327-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: samsung: odroid: fix a double-free issue for cpu_dai
Wen Yang [Sat, 13 Jul 2019 03:46:15 +0000 (11:46 +0800)]
ASoC: samsung: odroid: fix a double-free issue for cpu_dai

The cpu_dai variable is still being used after the of_node_put() call,
which may result in double-free:

        of_node_put(cpu_dai);            ---> released here

        ret = devm_snd_soc_register_card(dev, card);
        if (ret < 0) {
...
                goto err_put_clk_i2s;    --> jump to err_put_clk_i2s
...

err_put_clk_i2s:
        clk_put(priv->clk_i2s_bus);
err_put_sclk:
        clk_put(priv->sclk_i2s);
err_put_cpu_dai:
        of_node_put(cpu_dai);            --> double-free here

Fixes: d832d2b246c5 ("ASoC: samsung: odroid: Fix of_node refcount unbalance")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/1562989575-33785-3-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: samsung: odroid: fix an use-after-free issue for codec
Wen Yang [Sat, 13 Jul 2019 03:46:14 +0000 (11:46 +0800)]
ASoC: samsung: odroid: fix an use-after-free issue for codec

The codec variable is still being used after the of_node_put() call,
which may result in use-after-free.

Fixes: bc3cf17b575a ("ASoC: samsung: odroid: Add support for secondary CPU DAI")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/1562989575-33785-2-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: audio-graph-card: add missing const at graph_get_dai_id()
Kuninori Morimoto [Thu, 11 Jul 2019 04:10:45 +0000 (13:10 +0900)]
ASoC: audio-graph-card: add missing const at graph_get_dai_id()

commit c152f8491a8d9 ("ASoC: audio-graph-card: fix an use-after-free in
graph_get_dai_id()") fixups use-after-free issue,
but, it need to use "const" for reg. This patch adds it.

We will have below without this patch

LINUX/sound/soc/generic/audio-graph-card.c: In function 'graph_get_dai_id':
LINUX/sound/soc/generic/audio-graph-card.c:87:7: warning: assignment discards\
 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
   reg = of_get_property(node, "reg", NULL);

Fixes: c152f8491a8d9 ("ASoC: audio-graph-card: fix an use-after-free in graph_get_dai_id()")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Wen Yang <wen.yang99@zte.com.cn>
Link: https://lore.kernel.org/r/87sgrd43ja.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: rt1011: fix DC calibration offset not applying
Shuming Fan [Thu, 11 Jul 2019 08:22:14 +0000 (16:22 +0800)]
ASoC: rt1011: fix DC calibration offset not applying

There are two issues to fix:
- DC offset calibration data will be reset after stopping playback.
- DC offset calibration data should be applied in the initial setting.

Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20190711082214.8142-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: audio-graph-card: fix an use-after-free in graph_get_dai_id()
Wen Yang [Wed, 10 Jul 2019 07:25:09 +0000 (15:25 +0800)]
ASoC: audio-graph-card: fix an use-after-free in graph_get_dai_id()

After calling of_node_put() on the node variable, it is still being
used, which may result in use-after-free.
Fix this issue by calling of_node_put() after the last usage.

Fixes: a0c426fe1433 ("ASoC: simple-card-utils: check "reg" property on asoc_simple_card_get_dai_id()")
Link: https://lore.kernel.org/r/1562743509-30496-5-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: audio-graph-card: fix use-after-free in graph_dai_link_of_dpcm()
Wen Yang [Wed, 10 Jul 2019 07:25:08 +0000 (15:25 +0800)]
ASoC: audio-graph-card: fix use-after-free in graph_dai_link_of_dpcm()

After calling of_node_put() on the ports, port, and node variables,
they are still being used, which may result in use-after-free.
Fix this issue by calling of_node_put() after the last usage.

Fixes: dd98fbc558a0 ("ASoC: audio-graph-card: cleanup DAI link loop method - step1")
Link: https://lore.kernel.org/r/1562743509-30496-4-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: simple-card: fix an use-after-free in simple_for_each_link()
Wen Yang [Wed, 10 Jul 2019 07:25:07 +0000 (15:25 +0800)]
ASoC: simple-card: fix an use-after-free in simple_for_each_link()

The codec variable is still being used after the of_node_put() call,
which may result in use-after-free.

Fixes: d947cdfd4be2 ("ASoC: simple-card: cleanup DAI link loop method - step1")
Link: https://lore.kernel.org/r/1562743509-30496-3-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: simple-card: fix an use-after-free in simple_dai_link_of_dpcm()
Wen Yang [Wed, 10 Jul 2019 07:25:06 +0000 (15:25 +0800)]
ASoC: simple-card: fix an use-after-free in simple_dai_link_of_dpcm()

The node variable is still being used after the of_node_put() call,
which may result in use-after-free.

Fixes: cfc652a73331 ("ASoC: simple-card: tidyup prefix for snd_soc_codec_conf")
Link: https://lore.kernel.org/r/1562743509-30496-2-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: simple-card-utils: care no Platform for DPCM
Kuninori Morimoto [Wed, 10 Jul 2019 08:01:12 +0000 (17:01 +0900)]
ASoC: simple-card-utils: care no Platform for DPCM

commit 34614739988ad ("ASoC: soc-core: support dai_link with
platforms_num != 1") supports multi Platform, and
commit 9f3eb91753451 ("ASoC: simple-card-utils: consider CPU-Platform
possibility") removed no Platform from simple-card.

Multi Platform is now checking both Platform name/of_node are NULL case.
But in normal case, DPCM be doesn't have Platform.

asoc_simple_canonicalize_platform() try to use CPU of_node
to Platform (This is needed for DMAEngine platform case),
but it still might be NULL at DPCM be.

This patch try to use no Platform after that if Platform of_node
is still NULL. It can't probe without this patch.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87muhmgw2o.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: simple_card_utils.h: care NULL dai at asoc_simple_debug_dai()
Kuninori Morimoto [Wed, 10 Jul 2019 07:59:55 +0000 (16:59 +0900)]
ASoC: simple_card_utils.h: care NULL dai at asoc_simple_debug_dai()

props->xxx_dai might be NULL when DPCM.
This patch cares it for debug.

Fixes: commit 0580dde59438 ("ASoC: simple-card-utils: add asoc_simple_debug_info()")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87o922gw4u.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: Relocate my e-mail to .com domain zone
Kirill Marinushkin [Wed, 10 Jul 2019 05:51:35 +0000 (07:51 +0200)]
ASoC: Relocate my e-mail to .com domain zone

Signed-off-by: Kirill Marinushkin <kmarinushkin@birdec.com>
Link: https://lore.kernel.org/r/20190710055135.21377-1-kmarinushkin@birdec.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: rt1308: Remove executable attribute from source files
Joe Perches [Tue, 9 Jul 2019 17:22:16 +0000 (10:22 -0700)]
ASoC: rt1308: Remove executable attribute from source files

These are source files not executable.

Signed-off-by: Joe Perches <joe@perches.com>
Link: https://lore.kernel.org/r/d198a3e6ed3a0e9070afeb6aca69903c3e985149.camel@perches.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 years agoASoC: max98357a: use mdelay for sdmode-delay
Tzung-Bi Shih [Mon, 8 Jul 2019 14:19:01 +0000 (22:19 +0800)]
ASoC: max98357a: use mdelay for sdmode-delay

max98357a_daiops_trigger() is possible to be called in atomic context if
the .nonatomic flag is equal to 0 in the DAI links.

When cancel_delayed_work_sync() in max98357a_daiops_trigger() is called
in atomic context, kernel emits the following message: "BUG: sleeping
function called from invalid context".

According to the DT binding document, value less than or equal to 5ms of
sdmod-delay should be sufficient to avoid the pop noise.  Use mdelay
(i.e. busy loop) for such low delay should be acceptable.

Fixes: cec5b01f8f1c ("ASoC: max98357a: avoid speaker pop when playback
startup")

Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20190708141901.68797-1-tzungbi@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>