Removed this logic because It is BIOS which needs to
power off the ACP power domian through ACP_PGFSM_CTRL
register when you De-initialize ACP Engine.
Signed-off-by: Ravulapati Vishnu vardhan rao <Vishnuvardhanrao.Ravulapati@amd.com>
Link: https://lore.kernel.org/r/1581935964-15059-1-git-send-email-Vishnuvardhanrao.Ravulapati@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Sets plugged_cb to NULL when component removing to notify its consumers
: no further plugged status report is required.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200217105513.1.Icc323daaf71ad02f191fd8d91136b01b61eca5e3@changeidSigned-off-by: Mark Brown <broonie@kernel.org>

Reverts commit 839284e7 ("ASoC: dapm: add
snd_soc_dapm_put_enum_double_locked").
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200214105744.82258-3-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>

Reverts commit 62d5ae4c ("ASoC: max98090: save and restore
SHDN when changing sensitive registers").

A critical side-effect was observed: when keep playing something,
the recorded sound has chance to break (clipping).
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200214105744.82258-2-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>

The PCM runtime was freed during PMU in the case that the event hook
encountered an error. However, it is also unconditionally freed during
PMD. Avoid a double-free by dropping the call to kfree in the PMU hook.

Fixes: a72706ed ("ASoC: codec2codec: remove ephemeral variables")
Cc: stable@vger.kernel.org
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200213061147.29386-2-samuel@sholland.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Because of MAX BUFFER size in register,when user/app give small
buffer size produces noise of old data in buffer.
This patch rectifies this noise when using different
buffer sizes less than MAX BUFFER.
Signed-off-by: Ravulapati Vishnu vardhan rao <Vishnuvardhanrao.Ravulapati@amd.com>
Link: https://lore.kernel.org/r/1581426768-8937-1-git-send-email-Vishnuvardhanrao.Ravulapati@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

To be compliant with i915 display driver requirements, i915 power-up
must be done before any HDA communication takes place, including
parsing the bus capabilities. Otherwise the initial codec probe
may fail.

Move i915 initialization earlier in the SOF HDA sequence. This
sequence is now aligned with the snd-hda-intel driver where the
display_power() call is before snd_hdac_bus_parse_capabilities()
and rest of the capability parsing.

Also remove unnecessary ifdef around hda_codec_i915_init(). There's
a dummy implementation provided if CONFIG_SND_SOC_SOF_HDA is not
enabled.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@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/20200206200223.7715-3-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

When HDA controller is resumed from suspend, i915 HDMI/DP
codec requires that following order of actions is kept:

 - i915 display power up and configuration of link params
 - hda link reset and setup

Current SOF HDA code delegates display codec power control
to the codec driver. This works most of the time, but in
runtime PM sequences, the above constraint may be violated.
On platforms where BIOS values for HDA link parameters do
not match hardware reset defaults, this may lead to errors
in HDA verb transactions after resume.

Fix the issue by explicitly powering the display codec
in the HDA controller resume/suspend calls, thus ensuring
correct ordering. Special handling is needed for the D0i3
flow, where display power must be turned off even though
DSP is left powered.

Now that we have more invocations of the display power helper
functions, the conditional checks surrounding each call have
been moved inside hda_codec_i915_display_power(). The two
special cases of display powering at initial probe are handled
separately. The intent is to avoid powering the display whenever
no display codecs are used.

Note that early powering of display was removed in
commit 687ae9e2 ("ASoC: intel: skl: Fix display power regression").
This change was also copied to the SOF driver. No failures
have resulted as hardware default values for link parameters
have worked out of the box. However with recent i915 driver
changes like done in commit 87c16945 ("drm/i915: save
AUD_FREQ_CNTRL state at audio domain suspend"), this does not
hold anymore and errors are hit.

Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@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/20200206200223.7715-2-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

snd_hdac_ext_bus_link_get() does not work correctly in case
there are multiple codecs on the bus. It unconditionally
resets the bus->codec_mask value. As per documentation in
hdaudio.h and existing use in client code, this field should
be used to store bit flag of detected codecs on the bus.

By overwriting value of the codec_mask, information on all
detected codecs is lost. No current user of hdac is impacted,
but use of bus->codec_mask is planned in future patches
for SOF.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@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/20200206200223.7715-1-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The ssc audio driver can call into both pdc and dma backends.  With the
latest rework, the logic to do this in a safe way avoiding link errors
was removed, bringing back link errors that were fixed long ago in commit
061981ff ("ASoC: atmel: properly select dma driver state") such as

sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
atmel_ssc_dai.c:(.text+0xac): undefined reference to `atmel_pcm_pdc_platform_register'

Fix it this time using Makefile hacks and a comment to prevent this
from accidentally getting removed again rather than Kconfig hacks.

Fixes: 18291410 ("ASoC: atmel: enable SOC_SSC_PDC and SOC_SSC_DMA in Kconfig")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Link: https://lore.kernel.org/r/20200130130545.31148-1-codrin.ciubotariu@microchip.comReviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Mark Brown <broonie@kernel.org>

If the imx-sdma driver is built as a module, the fsl-sai device doesn't
disable on probing failure, which causes the warning in the next probing:

==================================================================
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
==================================================================

Disabling the device properly fixes the issue.

Fixes: 812ad463 ("ASoC: fsl_sai: Add support for runtime pm")
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://lore.kernel.org/r/20200205160436.3813642-1-oleksandr.suvorov@toradex.comSigned-off-by: Mark Brown <broonie@kernel.org>

Just adding a dependency on COMMON_CLK to SND_SOC_WCD934X is not
sufficient, as enabling SND_SOC_ALL_CODECS will still select it,
breaking the build later:

    WARNING: unmet direct dependencies detected for SND_SOC_WCD934X
      Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && COMMON_CLK [=n] && MFD_WCD934X [=m]
      Selected by [m]:
      - SND_SOC_ALL_CODECS [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && COMPILE_TEST [=y] && MFD_WCD934X [=m]
    ...
    ERROR: "of_clk_add_provider" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined!
    ERROR: "of_clk_src_simple_get" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined!
    ERROR: "clk_hw_register" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined!
    ERROR: "__clk_get_name" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined!

Fix this by adding the missing dependency to SND_SOC_ALL_CODECS

Fixes: 42b71635 ("ASoC: wcd934x: Add missing COMMON_CLK dependency")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20200204131857.7634-1-geert@linux-m68k.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Looks like some platforms are not yet using COMMON CLK.

PowerPC allyesconfig failed with below error in next

ld: sound/soc/codecs/wcd934x.o:(.toc+0x0):
	 undefined reference to `of_clk_src_simple_get'
ld: sound/soc/codecs/wcd934x.o: in function `.wcd934x_codec_probe':
wcd934x.c:(.text.wcd934x_codec_probe+0x3d4):
	 undefined reference to `.__clk_get_name'
ld: wcd934x.c:(.text.wcd934x_codec_probe+0x438):
	 undefined reference to `.clk_hw_register'
ld: wcd934x.c:(.text.wcd934x_codec_probe+0x474):
	 undefined reference to `.of_clk_add_provider'

Add the missing COMMON_CLK dependency to fix this errors.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200204111241.6927-1-srinivas.kandagatla@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Remove the maintainer "Bard Liao" since he had quitted from Realtek.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://lore.kernel.org/r/3ae27357f98a406a958304386a1457bc@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>

Commit f3ee9908 ("ASoC: tegra: Allow
24bit and 32bit samples") added 24-bit and 32-bit support for to the
Tegra30 I2S driver. However, there are two additional commits that are
also needed to get 24-bit and 32-bit support to work correctly. These
commits are not yet applied because there are still some review comments
that need to be addressed. With only this change applied, 24-bit and
32-bit support is advertised by the I2S driver, but it does not work and
the audio is distorted. Therefore, revert this patch for now until the
other changes are also ready.

Furthermore, a clock issue with 24-bit support has been identified with
this change and so if we revert this now, we can also fix that in the
updated version.
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200131091901.13014-1-jonathanh@nvidia.comSigned-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Mirror ID added for legacy HDaudio.
Signed-off-by: Yong Zhi <yong.zhi@intel.com>
Signed-off-by: Divagar Mohandass <divagar.mohandass@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200131204032.10213-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Fix the compile warnings by adding __maybe_unused to PM callbacks:
  sound/soc/codecs/rt715-sdw.c:566:12: warning: ‘rt715_dev_resume’ defined but not used [-Wunused-function]
  sound/soc/codecs/rt715-sdw.c:552:12: warning: ‘rt715_dev_suspend’ defined but not used [-Wunused-function]

Fixes: d1ede064 ("ASoC: rt715: add RT715 codec driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-5-tiwai@suse.deSigned-off-by: Mark Brown <broonie@kernel.org>

Fix the compile warnings by adding __maybe_unused to PM callbacks:
  sound/soc/codecs/rt711-sdw.c:504:12: warning: ‘rt711_dev_resume’ defined but not used [-Wunused-function]
  sound/soc/codecs/rt711-sdw.c:490:12: warning: ‘rt711_dev_suspend’ defined but not used [-Wunused-function]

Fixes: 320b8b0d ("ASoC: rt711: add rt711 codec driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-4-tiwai@suse.deSigned-off-by: Mark Brown <broonie@kernel.org>

Fix the compile warnings by adding __maybe_unused to PM callbacks:
  sound/soc/codecs/rt700-sdw.c:503:12: warning: ‘rt700_dev_resume’ defined but not used [-Wunused-function]
  sound/soc/codecs/rt700-sdw.c:489:12: warning: ‘rt700_dev_suspend’ defined but not used [-Wunused-function]

Fixes: 7d2a5f9a ("ASoC: rt700: add rt700 codec driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-3-tiwai@suse.deSigned-off-by: Mark Brown <broonie@kernel.org>

Fix the compile warnings by adding __maybe_unused to PM callbacks:
  sound/soc/codecs/rt1308-sdw.c:690:12: warning: ‘rt1308_dev_resume’ defined but not used [-Wunused-function]
  sound/soc/codecs/rt1308-sdw.c:676:12: warning: ‘rt1308_dev_suspend’ defined but not used [-Wunused-function]

Fixes: a87a6653 ("ASoC: rt1308-sdw: add rt1308 SdW amplifier driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-2-tiwai@suse.deSigned-off-by: Mark Brown <broonie@kernel.org>

Stopping of one stream is killing the other stream when they
are running simultaneously. This is because, IER register is
cleared which disables I2S and overrides any other block enables.

Clearing IER register only when all streams on a channel are disabled,
fixes the issue.
Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Link: https://lore.kernel.org/r/20200128103029.128841-1-akshu.agrawal@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Multiple Intel ASoC machine drivers repeat the same pattern in their
.late_probe() methods: they first check whether the common HDMI codec
driver is used, if not, they proceed by linking the legacy HDMI
driver to each HDMI port. While doing that they use some
inconsistent code:

1. after the loop they check, whether the list contained at least one
   element and if not, they return an error. However, the earlier
   code to use the common HDMI driver uses the first element of the
   same list without checking. To fix this we move the check to the
   top of the function.

2. some of those .late_probe() implementations execute code, only
   needed for the common HDMI driver, before checking, whether the
   driver is used. Move the code to after the check.

3. Some of those functions also perform a redundant initialisation of
   the "err" variable.

This patch fixes those issues.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200124213625.30186-8-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Fix the part id of rt715 (typo with zero in the wrong place)
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200124213625.30186-7-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

jsl_desc missed default_fw_name, this will fail the probe in
nocodec or generice HDA mode due the firmware path is intel/sof/(null)
Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200124213625.30186-6-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Check if DMA pages were successfully allocated in initialization
before calling free. For many types of memory (like sgbufs)
the extra free is harmless, but not all backends track allocation
state, so add an explicit check.
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/20200124213625.30186-5-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The initial intent of releasing resources in the .remove does not work
well with HDaudio codecs. If the probe_continue() fails in a work
queue, e.g. due to missing firmware or authentication issues, we don't
release any resources, and as a result the kernel oopses during
suspend operations.

The suggested fix is to release all resources during errors in
probe_continue(), and use fw_state to track resource allocation
state, so that .remove does not attempt to release the same
hardware resources twice. PM operations are also modified so that
no action is done if DSP resources have been freed due to
an error at probe.
Reported-by: Takashi Iwai <tiwai@suse.de>
Co-developed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Bugzilla:  http://bugzilla.suse.com/show_bug.cgi?id=1161246Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200124213625.30186-4-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

free_trace() is not called on probe errors, fix
Reviewed-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/20200124213625.30186-3-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

It is possible to create invalid topology that will cause a kernel
Oops when trying to allocate buffers for a NULL substream.
Specifically such an Oops was caused by a topology, where a DAI on a
capture pipeline was referencing the PCM ID from a playback pipeline.
Fix the Oops by explicitly checking for NULL.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200124213625.30186-2-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

If we play audio back to back, which kills one playback
and immediately start another, we can hear clicks.
This patch fixes the issue.
Signed-off-by: Ravulapati Vishnu vardhan rao <Vishnuvardhanrao.Ravulapati@amd.com>
Link: https://lore.kernel.org/r/1580124397-19842-1-git-send-email-Vishnuvardhanrao.Ravulapati@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Change HDA probe behaviour slightly so that i915 power is not
turned off if i915 audio codecs are found in the initial probe done
by SOF Intel driver, and power is kept on until HDA codec driver
probe runs.

This will reduce number of mode sets on platforms with low
minimum CDCLK (like GLK) and brings the SOF probe sequence closer
to legacy HDA driver in terms of i915 audio codec power management.

BugLink: https://github.com/thesofproject/linux/issues/1642Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200120160117.29130-3-kai.vehmanen@linux.intel.com
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

The current interface to control i915 display power is misleading.
The hda_codec_i915_get() and hda_codec_i915_put() names suggest
a refcounting based interface. This is confusing as no refcounting
is done and the underlying HDAC library interface does not support
refcounts eithers.

Clarify the code by replacing the functions with a single
hda_codec_i915_display_power() that is aligned with
snd_hdac_display_power().
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200120160117.29130-2-kai.vehmanen@linux.intel.comAcked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Clang warns:

../sound/soc/codecs/rt1015.c:392:14: warning: duplicate 'const'
declaration specifier [-Wduplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt1015_boost_mode_enum, 0, 0,
             ^
../include/sound/soc.h:355:2: note: expanded from macro
'SOC_ENUM_SINGLE_DECL'
        SOC_ENUM_DOUBLE_DECL(name, xreg, xshift, xshift, xtexts)
        ^
../include/sound/soc.h:352:2: note: expanded from macro
'SOC_ENUM_DOUBLE_DECL'
        const struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
        ^
1 warning generated.

Remove the const after static to fix it.

Fixes: df310074 ("ASoC: rt1015: add rt1015 amplifier driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/845Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://lore.kernel.org/r/20200124155750.33753-1-natechancellor@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

Commit 08df0d9a ("ASoC: max98090: revert "ASoC: max98090: fix lockdep
warning"") provided a good rationale for removing separate lock for the
SHDN register access. However it restored the lockdep warning during the
system boot. To silence the lockdep warning, mark the mutex taken in the
max98090_shdn_save() function with the lockdep class dedicated for the
runtime DAPM operations: SND_SOC_DAPM_CLASS_RUNTIME. This finally fixes
the following lockdep warning observed on Exynos4412-based Odroid U3
board:

======================================================
WARNING: possible circular locking dependency detected
5.5.0-rc7-next-20200123 #7329 Not tainted
------------------------------------------------------
alsactl/1105 is trying to acquire lock:
ed4f7cf4 (&card->dapm_mutex){+.+.}, at: max98090_shdn_save+0x1c/0x28

but task is already holding lock:
edb8d49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&card->controls_rwsem){++++}:
       snd_ctl_add_replace+0x3c/0x84
       dapm_create_or_share_kcontrol+0x24c/0x2e0
       snd_soc_dapm_new_widgets+0x308/0x594
       snd_soc_bind_card+0x834/0xa94
       devm_snd_soc_register_card+0x34/0x6c
       odroid_audio_probe+0x288/0x34c
       platform_drv_probe+0x6c/0xa4
       really_probe+0x200/0x48c
       driver_probe_device+0x78/0x1f8
       bus_for_each_drv+0x74/0xb8
       __device_attach+0xd4/0x16c
       bus_probe_device+0x88/0x90
       deferred_probe_work_func+0x3c/0xd0
       process_one_work+0x230/0x7bc
       worker_thread+0x44/0x524
       kthread+0x130/0x164
       ret_from_fork+0x14/0x20
       0x0

-> #0 (&card->dapm_mutex){+.+.}:
       lock_acquire+0xe8/0x270
       __mutex_lock+0x9c/0xb18
       mutex_lock_nested+0x1c/0x24
       max98090_shdn_save+0x1c/0x28
       max98090_put_enum_double+0x20/0x40
       snd_ctl_ioctl+0x190/0xbb8
       ksys_ioctl+0x484/0xb10
       ret_fast_syscall+0x0/0x28
       0xbede0564

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&card->controls_rwsem);
                               lock(&card->dapm_mutex);
                               lock(&card->controls_rwsem);
  lock(&card->dapm_mutex);

 *** DEADLOCK ***

1 lock held by alsactl/1105:
 #0: edb8d49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8

stack backtrace:
CPU: 2 PID: 1105 Comm: alsactl Not tainted 5.5.0-rc7-next-20200123 #7329
Hardware name: Samsung Exynos (Flattened Device Tree)
[<c01126f0>] (unwind_backtrace) from [<c010e1e8>] (show_stack+0x10/0x14)
[<c010e1e8>] (show_stack) from [<c0b5234c>] (dump_stack+0xb4/0xe0)
[<c0b5234c>] (dump_stack) from [<c018a610>] (check_noncircular+0x1ec/0x208)
[<c018a610>] (check_noncircular) from [<c018ca2c>] (__lock_acquire+0x1210/0x25ec)
[<c018ca2c>] (__lock_acquire) from [<c018e728>] (lock_acquire+0xe8/0x270)
[<c018e728>] (lock_acquire) from [<c0b71928>] (__mutex_lock+0x9c/0xb18)
[<c0b71928>] (__mutex_lock) from [<c0b723c0>] (mutex_lock_nested+0x1c/0x24)
[<c0b723c0>] (mutex_lock_nested) from [<c086097c>] (max98090_shdn_save+0x1c/0x28)
[<c086097c>] (max98090_shdn_save) from [<c08613f8>] (max98090_put_enum_double+0x20/0x40)
[<c08613f8>] (max98090_put_enum_double) from [<c0833f20>] (snd_ctl_ioctl+0x190/0xbb8)
[<c0833f20>] (snd_ctl_ioctl) from [<c02cae14>] (ksys_ioctl+0x484/0xb10)
[<c02cae14>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
Exception stack(0xed331fa8 to 0xed331ff0)
...

Fixes: 08df0d9a ("ASoC: max98090: revert "ASoC: max98090: fix lockdep warning"")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200123134046.9769-1-m.szyprowski@samsung.comSigned-off-by: Mark Brown <broonie@kernel.org>

All rtd->dai_link callback functions are controlled by soc_rtd_xxxx(),
and checking rtd->dai_link->ops.
We don't need to have null_snd_soc_ops anymore.
This patch removes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhegl3oz.wl-kuninori.morimoto.gx@renesas.comReviewed-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>

Add soc_rtd_trigger() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871rrsmi9j.wl-kuninori.morimoto.gx@renesas.comReviewed-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>

Add soc_rtd_hw_free() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736c8mi9n.wl-kuninori.morimoto.gx@renesas.comReviewed-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>

Add soc_rtd_hw_params() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kwomi9r.wl-kuninori.morimoto.gx@renesas.comReviewed-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>

Add soc_rtd_prepare() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875zh4mi9v.wl-kuninori.morimoto.gx@renesas.comReviewed-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>

Add soc_rtd_shutdown() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877e1kmi9z.wl-kuninori.morimoto.gx@renesas.comReviewed-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>

Add soc_rtd_startup() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878sm0mia4.wl-kuninori.morimoto.gx@renesas.comReviewed-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>