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: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-4-tiwai@suse.deSigned-off-by: NMark 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: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-3-tiwai@suse.deSigned-off-by: NMark 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: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-2-tiwai@suse.deSigned-off-by: NMark 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: NAkshu Agrawal <akshu.agrawal@amd.com>
Link: https://lore.kernel.org/r/20200128103029.128841-1-akshu.agrawal@amd.comSigned-off-by: NMark 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: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NPierre-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: NMark Brown <broonie@kernel.org>

Fix the part id of rt715 (typo with zero in the wrong place)
Signed-off-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: NPierre-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: NMark 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: NPan Xiuli <xiuli.pan@linux.intel.com>
Signed-off-by: NPierre-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: NMark 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: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: NPierre-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: NMark 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: NTakashi Iwai <tiwai@suse.de>
Co-developed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Bugzilla:  http://bugzilla.suse.com/show_bug.cgi?id=1161246Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200124213625.30186-4-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

free_trace() is not called on probe errors, fix
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: NPierre-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: NMark 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: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NPierre-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: NMark 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: NRavulapati 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: NMark 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: NKai 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: NMark 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: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200120160117.29130-2-kai.vehmanen@linux.intel.comAcked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark 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: NNathan Chancellor <natechancellor@gmail.com>
Link: https://lore.kernel.org/r/20200124155750.33753-1-natechancellor@gmail.comSigned-off-by: NMark 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: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200123134046.9769-1-m.szyprowski@samsung.comSigned-off-by: NMark 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: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhegl3oz.wl-kuninori.morimoto.gx@renesas.comReviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add soc_rtd_trigger() to make the code easier to read
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871rrsmi9j.wl-kuninori.morimoto.gx@renesas.comReviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add soc_rtd_hw_free() to make the code easier to read
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736c8mi9n.wl-kuninori.morimoto.gx@renesas.comReviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add soc_rtd_hw_params() to make the code easier to read
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kwomi9r.wl-kuninori.morimoto.gx@renesas.comReviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add soc_rtd_prepare() to make the code easier to read
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875zh4mi9v.wl-kuninori.morimoto.gx@renesas.comReviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add soc_rtd_shutdown() to make the code easier to read
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877e1kmi9z.wl-kuninori.morimoto.gx@renesas.comReviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add soc_rtd_startup() to make the code easier to read
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878sm0mia4.wl-kuninori.morimoto.gx@renesas.comReviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is initial amplifier driver for rt1015.
Signed-off-by: NJack Yu <jack.yu@realtek.com>
Link: https://lore.kernel.org/r/20200115112519.22050-1-jack.yu@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200122104559.17043-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

The MT6660 is a boosted BTL class-D amplifier with V/I sensing.
A built-in DC-DC step-up converter is used to provide efficient
power for class-D amplifier with multi-level class-G operation.
The digital audio interface supports I2S, left-justified,
right-justified, TDM and DSP A/B format for audio in with a data
out used for chip information like voltage sense and current
sense, which are able to be monitored via DATAO through proper
Signed-off-by: NJeff Chang <jeff_chang@richtek.com>
Link: https://lore.kernel.org/r/1579153597-23286-1-git-send-email-richtek.jeff.chang@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The rt5645 and rt5650 have two suppliers, document them.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>

Link: https://lore.kernel.org/r/20200114150151.8537-1-matthias.bgg@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when
changing sensitive registers SHDN bit") uses dapm_mutex to protect SHDN
bit.  However, snd_soc_dapm_put_enum_double() in
max98090_dapm_put_enum_double() acquires the dapm_mutex again which
cause a deadlock.

Use snd_soc_dapm_put_enum_double_locked() instead to fix the deadlock.

Fixes: 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers SHDN bit")
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200117073814.82441-4-tzungbi@google.comSigned-off-by: NMark Brown <broonie@kernel.org>

Adds snd_soc_dapm_put_enum_double_locked() for those use cases if
dapm_mutex has already locked.
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200117073814.82441-3-tzungbi@google.comSigned-off-by: NMark Brown <broonie@kernel.org>

Commit 2dc98af6 ("ASoC: max98090: fix lockdep warning") introduced
a helpful-less small lock: shdn_lock.  Reverts the commit.

Reasons:

1. Lockdep should not be happy by either the original or current code.
From lockdep's point of view, there is a lock inversion anyway.

Let d = dapm_mutex, c = controls_rwsem, s = shdn_lock,

From the reported calling stack: lock acquisition order of
snd_soc_register_card() is: d -> c.
> snd_ctl_add_replace+0x3c/0x84
> dapm_create_or_share_kcontrol+0x24c/0x2e0
> snd_soc_dapm_new_widgets+0x308/0x594
> snd_soc_bind_card+0x80c/0xad4
> devm_snd_soc_register_card+0x34/0x6c

If calling snd_soc_dapm_put_enum_double() in kcontrol's put (e.g.
SOC_DAPM_ENUM_EXT), lock acquisition order is: c -> d.  Note that,
snd_soc_dapm_put_enum_double() acquires d.

The possible lock inversion is always there if registering sound card
and putting mixer control happen at the same time.  In fact, it never
happens because the control device don't show up to the userspace until
the sound card build success.

Commit 2dc98af6 ("ASoC: max98090: fix lockdep warning") changes the
order to: c -> s -> d.  The lock inversion is still there.

2. Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when
changing sensitive registers SHDN bit") designed to use dapm_mutex to
protect SHDN bit.  Use a separate lock breaks the protection.

DAPM changes SHDN bit automatically when it finds the path.  Thus, any
code wants to change the SHDN bit, need to acquire the dapm_mutex first.

> SND_SOC_DAPM_SUPPLY("SHDN", M98090_REG_DEVICE_SHUTDOWN,
>        M98090_SHDNN_SHIFT, 0, NULL, 0),

Fixes: 2dc98af6 ("ASoC: max98090: fix lockdep warning")
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200117073814.82441-2-tzungbi@google.comSigned-off-by: NMark Brown <broonie@kernel.org>

Now, snd_soc_dai_driver::bus_control is used for how to resume.
But, no driver which has bus_control has DAI driver suspend/resume
support.
This patch removes pointless bus_control from ALSA SoC.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pnffx7i4.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Historically, CPU and Codec were implemented different, but now it is
merged as Component.
ALSA SoC is supporting suspend/resume at DAI and Component level.
The method is like below.

	1) Suspend/Resume all CPU DAI if bus-control was 0
	2) Suspend/Resume all Component
	3) Suspend/Resume all CPU DAI if bus-control was 1

Historically 2) was Codec special operation.
Because CPU and Codec were merged into Component,
CPU   suspend/resume has 3 chance to suspend(= 1/2/3), but
Codec suspend/resume has 1 chance (= 2).

Here, DAI side suspend/resume is caring bus-control, but no driver
which is supporting suspend/resume is setting bus-control.
This means 3) was never used.

Here, used parameter for suspend/resume component->dev and dai->dev are
same pointer.
For that reason, we can merge DAI and Component suspend/resume.
One note is that we should use 2), because it is caring BIAS level.

This patch removes 1) and 3).
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r1zvx7i8.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.

Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87sgkbx7ic.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can swtcih all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.

Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.

This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87tv4rx7ij.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch removes unused DAI driver .suspend/.resume
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87v9p7x7io.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.

Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.

This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wo9nx7it.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.

Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.

This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87y2u3x7iy.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.

Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.

This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhejx7j4.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.

Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.

This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/871rrvym3p.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.

Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.

This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736cbym3x.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>