If we focus to soc_bind_dai_link() at snd_soc_instantiate_card(),
we will notice very complex operation.

static int snd_soc_instantiate_card(...)
{
	...
	/*
	 * (1) Bind dai_link via card pre-linked dai_link
	 *
	 * Bind dai_link via card pre-linked.
	 * 1 dai_link will be 1 rtd, and connected to card.
	 * for_each_card_prelinks() is for card pre-linked dai_link.
	 *
	 * Image
	 *
	 * card
	 * - rtd(A)
	 * - rtd(A)
	 */
	for_each_card_prelinks(card, i, dai_link) {
		ret = soc_bind_dai_link(card, dai_link);
		...
	}
	...
	/*
	 * (2) Connect card pre-linked dai_link to card list
	 *
	 * Connect all card pre-linked dai_link to *card list*.
	 * Here, (A) means from card pre-linked.
	 *
	 * Image
	 *
	 * card		card list
	 *  - rtd(A)	 - dai_link(A)
	 *  - rtd(A)	 - dai_link(A)
	 *  - ...	 - ...
	 */
	for_each_card_prelinks(card, i, dai_link) {
		ret = snd_soc_add_dai_link(card, dai_link);
		...
	}
	...
	/*
	 * (3) Probe binded component
	 *
	 * Each rtd has many components.
	 * Here probes each rtd connected components.
	 * rtd(A) in Image is the probe target.
	 *
	 * During this component probe, topology may add new dai_link to
	 * *card list* by using snd_soc_add_dai_link() which is
	 * used at (2).
	 * Here, (B) means from topology
	 *
	 * Image
	 *
	 * card		card list
	 *  - rtd(A)	 - dai_link(A)
	 *  - rtd(A)	 - dai_link(A)
	 *  - ...	 - ...
	 *		 - dai_link(B)
	 *		 - dai_link(B)
	 */
	ret = soc_probe_link_components(card);
	...

	/*
	 * (4) Bind dai_link again
	 *
	 * Bind dai_link again for topology.
	 * Note, (1) used for_each_card_prelinks(),
	 * here is using  for_each_card_links()
	 *
	 * This means from card list.
	 * As Image indicating, it has dai_link(A) (from card pre-link)
	 * and dai_link(B) (from topology).
	 * main target here is dai_link(B).
	 * soc_bind_dai_link() ignores already used
	 * dai_link (= dai_link(A))
	 *
	 * Image
	 *
	 * card		card list
	 *  - rtd(A)	 - dai_link(A)
	 *  - rtd(A)	 - dai_link(A)
	 *  - ...	 - ...
	 *  - rtd(B)	 - dai_link(B)
	 *  - rtd(B)	 - dai_link(B)
	 */
	for_each_card_links(card, dai_link) {
		ret = soc_bind_dai_link(card, dai_link);
		...
	}
	...
}

As you see above, it is doing very complex method.
The problem is binding dai_link via "card pre-linked" (= (1)) and
"topology added dai_link" (= (3)) are separated.
The code can be simple if we can bind dai_link when dai_link
is connected to *card list*.
This patch do it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/878sou3jnn.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

soc_is_dai_link_bound() check will be called both
*before* soc_bind_dai_link() (A), and
*under*  soc_bind_dai_link() (B).
These are very verbose code. Let's remove one of them.

*	static int soc_bind_dai_link(...)
	{
		...
(B)		if (soc_is_dai_link_bound(...)) {
			...
			return 0;
		}
		...
	}

	static int snd_soc_instantiate_card(...)
	{
		...
		for_each_card_links(...) {
(A)			if (soc_is_dai_link_bound(...))
				continue;

*			ret = soc_bind_dai_link(...);
			if (ret)
				goto probe_end;
		}
		...
	}
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a79a3jns.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Reported-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87bltq3jo7.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

soc_init_dai_link() is needed to be called before soc_bind_dai_link().

	int snd_soc_instantiate_card()
	{
		for_each_card_prelinks(...) {
(1)			ret = soc_init_dai_link(...);
			...
		}
		...
		for_each_card_prelinks(...) {
(2)			ret = soc_bind_dai_link(...);
			...
		}
		...
		for_each_card_links(...) {
			...
(A)			ret = soc_init_dai_link(...);
			...
(B)			ret = soc_bind_dai_link(...);
		}
		...

(1) is for (2), and (A) is for (B)
(1) and (2) are for card prelink   dai_link.
(A) and (B) are for topology added dai_link.

soc_init_dai_link() is sanity check for dai_link, not initializing today.
Therefore, it is confusable naming. We can rename it as sanity_check.

And this check is for soc_bind_dai_link().
It can be more simple code if we can call it from soc_bind_dai_link().

This patch renames it to soc_dai_link_sanity_check(), and
call it from soc_bind_dai_link().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87d0e63joh.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch moves soc_init_dai_link() next to soc_bind_dai_link().
This is prepare for soc_bind_dai_link() cleanup.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87eeym3joq.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

The ADAU7118 has an example where the codec has an i2c address of 14, and
the unit address set to 14 as well.

However, while the address is expressed in decimal, the unit-address is
supposed to be in hexadecimal, which ends up with two different addresses
that trigger a DTC warning. Fix this by setting the address to 0x14.

Cc: Nuno Sá <nuno.sa@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Fixes: 969d49b2 ("dt-bindings: asoc: Add ADAU7118 documentation")
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20191105105615.21391-1-maxime@cerno.techSigned-off-by: NMark Brown <broonie@kernel.org>

Set trigger order for FE DAI links to SND_SOC_DPCM_TRIGGER_POST
to trigger the BE DAI's before the FE DAI's. This prevents the
xruns seen on playback pipelines using the link DMA.
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-3-ranjani.sridharan@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.

In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.

The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The wrong dependency is used and the build can be broken
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-12-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Geminilake machine drivers are only tested and recommended with SOF.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-11-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The same driver is reused for 3 different configurations, but the
driver will only be build if ApolloLake is selected.

Fix and make sure each device can work without dependencies on others
(useful for minimal configurations).
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-10-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

This option is only required with the Skylake platform driver, there
is no reason to have this option in machine drivers. This is
e.g. useless for SOF-based solutions.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-9-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

This option famously broke audio on Linus' laptop and the problem have
not been fixed.

Mark as DEPRECATED to avoid any ambiguity with distros.

Use SOF if you need HDaudio support w/ the DSP enabled, e.g. for DMIC
capture.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-8-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

So far we used select to use the relevant built-in/module options, but
this led to blurring layers between core and Intel Kconfigs.

Use def_tristate works just as well and removes Intel stuff from the code.
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-7-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

updated solution to the problem reported with randconfig:

CONFIG_SND_SOC_SOF_IMX depends on CONFIG_SND_SOC_SOF, but is in
turn referenced by the sof-of-dev driver. This creates a reverse
dependency that manifests in a link error when CONFIG_SND_SOC_SOF_OF
is built-in but CONFIG_SND_SOC_SOF_IMX=m:

sound/soc/sof/sof-of-dev.o:(.data+0x118): undefined reference to `sof_imx8_ops'

use def_trisate to propagate the right settings without select.

Fixes: f4df4e40 ("ASoC: SOF: imx8: Fix COMPILE_TEST error")
Fixes: 202acc56 ("ASoC: SOF: imx: Add i.MX8 HW support")
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-6-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some distros select all possible options, despite existing warnings to
be careful. This leads to e.g. user reports that the HDaudio codec and
DMIC are not handled by SOF.

Add an explicit menu item to unlock developer options, and make them
dependent on CONFIG_EXPERT. Hopefully with this double-lock these
options will only be selected by developers.

GitHub issue: https://github.com/thesofproject/sof/issues/1885Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-5-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

This legacy driver is already deprecated, let's make sure there is no
conflict with SOF.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-4-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some distros select all options blindly, which leads to confusion and
bug reports. SOF does not fully support Broadwell due to firmware
dependencies, the machine drivers can only support one option, and
UCM/topology files are still being propagated to downstream distros,
so make SOF on Broadwell an opt-in option that first require distros
to opt-out of existing defaults.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204237
Fixes: f35bf70f ('ASoC: Intel: Make sure BDW based machine drivers build for SOF')
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-3-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some distros select all options blindly, which leads to confusion and
bug reports. Since SOF does not support Baytrail-CR for now, and
UCM/topology files are still being propagated to downstream distros,
make SOF on Baytrail an opt-in option that first require distros to
opt-out of existing defaults.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-2-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Remove the retry argument for the hda_dsp_wait_d0i3c_done()
function and use the HDA_DSP_REG_POLL_RETRY_COUNT macro
directly.
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101170916.26517-4-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Machine driver to enable
RT5682 on SSP0, DMIC, HDMI and
RT1011 AMP on SSP1 with
2 CH / 24 bit TDM Playback over 4 individual codecs and
4 CH / 24 bit Capture to provide feedback.
Signed-off-by: NNaveen Manohar <naveen.m@intel.com>
Signed-off-by: NSathya Prakash M R <sathya.prakash.m.r@intel.com>
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/20191101171847.26767-3-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add match for CML m/c with RT1011 and RT5682
Signed-off-by: NNaveen Manohar <naveen.m@intel.com>
Signed-off-by: NSathya Prakash M R <sathya.prakash.m.r@intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101171847.26767-2-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

local variable "status" is not used. hence it is safe to remove and
just return 0.
Signed-off-by: Nzhong jiang <zhongjiang@huawei.com>
Link: https://lore.kernel.org/r/1572528855-25990-1-git-send-email-zhongjiang@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is no other code use the RT1011_INIT_REG_LEN definition,
except rt1011_reg_init().
Hence, we remove it and fix the typo.
Signed-off-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191031115446.21108-1-shumingf@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

The driver will check the range for temperature_calib.
It should be from 1 to 255.
Signed-off-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191031115436.21055-1-shumingf@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

There are unnecessary tabs inside some statements.
It uses sapces instead.
Signed-off-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191031115425.21003-1-shumingf@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

If there is a wrong format setting,
the driver will goto the end of the function directly.
Signed-off-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191031115414.20951-1-shumingf@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

The !component->card->instantiated statement should remove in kcontrol.
It is no need to check the card->instantiated in kcontrol.
Signed-off-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191031115401.20898-1-shumingf@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

The btndet-delay device property could control the HW debounce time.
It is easy to adjust the sensitivity of push button.
Signed-off-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191030085556.14351-1-shumingf@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

The sensitivity could improve by decreasing the HW debounce time
and reduce the delay time of workequeue.
This patch added a device property for HW debounce time control.
We could change this value to tune the sensitivity of push button.
Signed-off-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191030085533.14299-1-shumingf@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

snd_soc_tplg_component_remove() is pair of snd_soc_tplg_component_load(),
and it is topology related cleanup function.

The driver which called _load() needs to call _remove() by its responsibility.
Today, skl-pcm and topology are the user, and these are calling both
_load() and _remove().

soc-core doesn't need to call it.
This patch remove it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736fbdnwt.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch fixup this warning

LINUX/sound/soc/codecs/rt5677-spi.c: In function ‘rt5677_spi_pcm_close’:
LINUX/sound/soc/codecs/rt5677-spi.c:114:30: warning: unused variable ‘rtd’ [-Wunused-variable]
  struct snd_soc_pcm_runtime *rtd = substream->private_data;
                              ^~~

Fixes: a0e0d135 ("ASoC: rt5677: Add a PCM device for streaming hotword via SPI")
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a79idajh.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for using snd-hda-codec-hdmi driver for HDMI/DP
instead of ASoC hdac-hdmi. This is aligned with how other
HDA codecs are already handled.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191029134017.18901-10-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for using snd-hda-codec-hdmi driver for HDMI/DP
instead of ASoC hdac-hdmi. This is aligned with how other
HDA codecs are already handled.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191029134017.18901-9-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for using snd-hda-codec-hdmi driver for HDMI/DP
instead of ASoC hdac-hdmi. This is aligned with how other
HDA codecs are already handled.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191029134017.18901-8-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for using snd-hda-codec-hdmi driver for HDMI/DP
instead of ASoC hdac-hdmi. This is aligned with how other
HDA codecs are already handled.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191029134017.18901-7-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support to implement HDMI/DP audio by using the common
snd-hda-codec-hdmi driver.

Change of codec driver affects user-space as the two
drivers expose different mixer controls. A new kernel
module option "use_common_hdmi" is added to user-space
to indicate which interface should be used. The default
driver can be selected via a Kconfig option.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191029134017.18901-6-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Match the include guard define to actual filename. The source
directory now has an actual hda_dsp_common.h header, so the old
include guard may cause confusion.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191029134017.18901-5-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for using snd-hda-codec-hdmi driver for HDMI/DP
instead of ASoC hdac-hdmi. This is aligned with how other
HDA codecs are already handled.

When snd-hda-codec-hdmi is used, the PCM device numbers are
parsed from card topology and passed to the codec driver.
This needs to be done at runtime as topology changes may
affect PCM device allocation.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191029134017.18901-4-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Handle all HDA codecs using same logic, including HDMI/DP.

Call to snd_hda_codec_build_controls() is delayed for HDMI/DP HDA
devices. This is needed to discover the PCM device numbers as
defined in topology.
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191029134017.18901-3-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>