The change to avoid dummy components will leave the component name and
dai_name NULL which will cause NULL dereference when trying to access to
it in the machine driver when applying fixups.

Link: https://github.com/thesofproject/linux/pull/4759#issuecomment-1878641868
Fixes: 13f58267 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://msgid.link/r/20240108094842.28782-2-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from cy_huang@richtek.com:

This patch series fix rtq9128 pm_runtime and TDM usage.

To enable TDM mode, the current control flow limits the function
calling order should be 'set_tdm_slot->set_dai_fmt'. But not all
platform sound card like as simeple card to follow this design.
To bypass this limit, adjust the DAI format setting in runtime
'hw_param' callback.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://msgid.link/r/c4c8df00d8d179b8b5b39a8521de3a85325c57e8.1703813842.git.cy_huang@richtek.comSigned-off-by: Mark Brown <broonie@kernel.org>

If 'pm_runtime_resume_and_get' is used, must check the return value to
prevent the active count not matched problem.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://msgid.link/r/bebd9e2bed9e0528a7fd9c528d785da02caf4f1a.1703813842.git.cy_huang@richtek.comSigned-off-by: Mark Brown <broonie@kernel.org>

Move tas2563 from tas2562 driver to tas2781 driver to unbind tas2563 from
tas2562 driver code and bind it to tas2781 driver code, because tas2563
only work in bypass-DSP mode with tas2562 driver. In order to enable DSP
mode for tas2563, it has been moved to tas2781 driver. As to the hardware
part, such as register setting and DSP firmware, all these are stored in
the binary firmware. What tas2781 drivder does is to parse the firmware
and download it to the chip, then power on the chip. So, tas2781 driver
can be resued as tas2563 driver. Only attention will be paid to downloading
corresponding firmware.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://msgid.link/r/20240104145721.1398-4-shenghao-ding@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

Move tas2563 from tas2562 header file to tas2781 header file to unbind
tas2563 from tas2562 driver code and bind it to tas2781 driver code,
because tas2563 only work in bypass-DSP mode with tas2562 driver. In
order to enable DSP mode for tas2563, it has been moved to tas2781
driver. As to the hardware part, such as register setting and DSP
firmware, all these are stored in the binary firmware. What tas2781
drivder does is to parse the firmware and download it to the chip,
then power on the chip. So, tas2781 driver can be resued as tas2563
driver. Only attention will be paid to downloading corresponding firmware.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://msgid.link/r/20240104145721.1398-3-shenghao-ding@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

Move tas2563 from tas2562 driver to tas2781 driver to unbind tas2563 from
tas2562 driver code and bind it to tas2781 driver code, because tas2563
only work in bypass-DSP mode with tas2562 driver. In order to enable DSP
mode for tas2563, it has been moved to tas2781 driver. As to the hardware
part, such as register setting and DSP firmware, all these are stored in
the binary firmware. What tas2781 drivder does is to parse the firmware
and download it to the chip, then power on the chip. So, tas2781 driver
can be resued as tas2563 driver. Only attention will be paid to
downloading corresponding firmware.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://msgid.link/r/20240104145721.1398-2-shenghao-ding@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

Move tas2563 from tas2562.yaml to tas2781.yaml to unbind tas2563 from
tas2562 driver code and bind it to tas2781 driver code, because tas2563
only work in bypass-DSP mode with tas2562 driver. In order to enable DSP
mode for tas2563, it has been moved to tas2781 driver. As to the hardware
part, such as register setting and DSP firmware, all these are stored in
the binary firmware. What tas2781 drivder does is to parse the firmware
and download it to the chip, then power on the chip. So, tas2781 driver
can be resued as tas2563 driver. Only attention will be paid to
downloading corresponding firmware.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://msgid.link/r/20240104145721.1398-1-shenghao-ding@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

On ARM64 platforms, SND_ARM shouldn't be selectable, but enabling
SND_SOC_MMP_SSPA will enable SND_ARM and cause build errors if
SND_ARMAACI is enabled (which it is by default). Since the SSPA driver
doesn't depend on AACI nor PXA2XX_LIB, remove this false dependency.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310230518.zs9Qpg3j-lkp@intel.com/Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20231226200025.30870-1-duje.mihanovic@skole.hrSigned-off-by: Mark Brown <broonie@kernel.org>

This patch makes sure that the workqueue is completed before the system suspends.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20231229092922.853-1-shumingf@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>

The sof imx pcm device is a device which should support
double buffering.

Found this issue with pipewire. When there is no
SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will
set headroom to be zero, and because sof pcm device
don't support residue report, when the latency setting
is small, the "delay" always larger than "target" in
alsa-pcm.c, that reading next period data is not
scheduled on time.

With SNDRV_PCM_INFO_BATCH flag in driver, the pipewire
will select a smaller period size for device, then
the task of reading next period data will be scheduled
on time.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1703669263-13832-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

Set the card.components string using the new rt5645_components() helper
which returns a components string based on the DMI quirks inside the
rt5645 codec driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://msgid.link/r/20231126214024.300505-8-hdegoede@redhat.comSigned-off-by: Mark Brown <broonie@kernel.org>

The GPD Win and Teclast X80 Pro both only have 1 speaker add information
about this to the components string.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://msgid.link/r/20231126214024.300505-7-hdegoede@redhat.comSigned-off-by: Mark Brown <broonie@kernel.org>

The rt5645 codec driver uses DMI quirks to configure the DMIC data-pins,
which means that it knows which DMIC interface is used on a specific
device.

ATM we duplicate this DMI matching inside the UCM profiles to select
the right DMIC interface. Add a rt5645_components() helper which the
machine-driver can use to set the components string of the card so
that UCM can get the info from the components string.

This way we only need to add new DMI quirks in one place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://msgid.link/r/20231126214024.300505-6-hdegoede@redhat.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add a rt5645_get_pdata() helper function which retreives the platform-data
and overrides it with the quirks module parameter if that is set.

This is a preparation patch for adding the rt5645_components() function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://msgid.link/r/20231126214024.300505-5-hdegoede@redhat.comSigned-off-by: Mark Brown <broonie@kernel.org>

Refactor rt5645_parse_dt(), make it take a pointer to
struct rt5645_platform_data as argument instead of passing in
the complete rt5645_priv struct.

While at it also make it void since it always succeeds.

This is a preparation patch for factoring the code to get
the platform-data out into a separate helper function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://msgid.link/r/20231126214024.300505-4-hdegoede@redhat.comSigned-off-by: Mark Brown <broonie@kernel.org>

The Acer Switch V 10 uses the default jack-detect mode 3, but instead of
using an analog microphone it is using a DMIC on dmic-data-pin 1,
like other models following Intel's Braswell's reference design.

Add a DMI quirk pointing to the intel_braswell_platform_data for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://msgid.link/r/20231126214024.300505-3-hdegoede@redhat.comSigned-off-by: Mark Brown <broonie@kernel.org>

dmi_platform_data[] first contains a DMI entry matching:

   DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),

and then contains an identical entry except for the match being:

   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),

Since these are partial (non exact) DMI matches the first match
will also match any board with "EF20EA" in their DMI product-name,
drop the second, redundant, entry.

Fixes: a4dae468 ("ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series")
Cc: Chris Chiu <chiu@endlessos.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://msgid.link/r/20231126214024.300505-2-hdegoede@redhat.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Neil Armstrong <neil.armstrong@linaro.org>:

Document the SM8650 sound card using the SM8450 fallback
and add the SM8650 compatible to the sc8280xp sound card
driver to use the sm8650 card driver_name like SM8450 & SM8550.

Merge series from Rui Zhou <zhourui@huaqin.corp-partner.google.com>:

Add dt-bindings for es8326 and codec es8326 support.
Remove duplicate code, commonize headset codec init/exit API.
At the same time, Enable dual amp max98390 for rt5682s.

Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:

This patch series provides several fixes and improvements to AMD ACP drivers
targeting the Vangogh platform, as found on the Valve's new Steam Deck OLED.

Although in theory the board should have been supported by both SOF and legacy
ACP drivers, as of next-20231208 the audio seems to be completely broken.

Please note this only restores the legacy support, while SOF will be handled in
a separate series.

Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:

"Empty" dlc might be used on Platform, but "dummy" dlc is not needed
for it. [PATCH 1/5][PATCH 2/5] removes "dummy" dlc from Platform.

Now ASoC have common dummy dlc (= snd_soc_dummy_dlc).
[PATCH 3/5][PATCH 4/5] will use it instead of original dummy dlc.

Many drivers are using below macro

	SND_SOC_DAILINK_DEFS(link,
		     DAILINK_COMP_ARRAY(COMP_CPU(...)),
(X)		     DAILINK_COMP_ARRAY(COMP_DUMMY()),
		     DAILINK_COMP_ARRAY(COMP_EMPTY()));

But (X) part will create original dummy dlc.
[PATCH 5/5] will try not to create original dummy dlc, and replace
it to common dummy dlc.

Merge series from Linus Walleij <linus.walleij@linaro.org>:

Mostly dropping unused headers, and a single driver rewrite.

Remove this spurious "contains" which causes the bindings check of
qcom,sm8450-lpass-va-macro compatible to fail with:
codec@33f0000: clocks: [[156, 57, 1], [156, 102, 1], [156, 103, 1], [156, 70, 1]] is too long
        from schema $id: http://devicetree.org/schemas/sound/qcom,lpass-va-macro.yaml#
codec@33f0000: clock-names: ['mclk', 'macro', 'dcodec', 'npl'] is too long
        from schema $id: http://devicetree.org/schemas/sound/qcom,lpass-va-macro.yaml#

Seems the double "contains" was considered as valid by the tool but broke
the entire if statements.

Fixes: f243ef74 ("ASoC: dt-bindings: qcom,lpass-va-macro: Add SM8650 LPASS VA")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://msgid.link/r/20231219-topic-sm8x50-upstream-va-macro-bindings-fix-v1-1-ae133886f70e@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>

'sg' is freed at the end sprd_platform_compr_dma_config() both in the
normal and in the error handling path.

There is no need to use the devm_kcalloc()/devm_kfree(), kcalloc()/kfree()
is enough.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://msgid.link/r/d16f22ae0627249a9fc658927832590cd88c544e.1702960856.git.christophe.jaillet@wanadoo.frSigned-off-by: Mark Brown <broonie@kernel.org>

Add acp-psp mailbox communication interface for iram-dram size
modification to notify psp.
Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Link: https://msgid.link/r/20231219112416.3334928-5-venkataprasad.potturu@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Rename amd_bt sof_dai_type from ACP to ACP_BT.
Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Link: https://msgid.link/r/20231219112416.3334928-4-venkataprasad.potturu@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add support for i2s bt dai configuration from topology.
Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Link: https://msgid.link/r/20231219112416.3334928-3-venkataprasad.potturu@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Refactor sof_i2s_tokens reading to update config->acpbt.
Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Link: https://msgid.link/r/20231219112416.3334928-2-venkataprasad.potturu@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Refactor spinlock_irq(&sdev->ipc_lock) sequence in irq_handler
to avoid race conditions for acquiring hw_semaphore.
Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Link: https://msgid.link/r/20231219112416.3334928-1-venkataprasad.potturu@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Many ASoC drivers define CPU/Codec/Platform dai_link by below macro.

	SND_SOC_DAILINK_DEFS(link,
(A)		     DAILINK_COMP_ARRAY(COMP_CPU("cpu_dai")),
(B)		     DAILINK_COMP_ARRAY(COMP_CODEC("codec", "dai1"),
(B)					COMP_CODEC("codec", "dai2")),
(C)		     DAILINK_COMP_ARRAY(COMP_EMPTY()));

In this case, this macro will be converted to like below

	[o] = static struct snd_soc_dai_link_component

(A)	[o] link_cpus[]      = {{ .dai_name = "cpu_dai" }};
(B)	[o] link_codecs[]    = {{ .dai_name = "dai1", .name = "codec" },
				{ .dai_name = "dai2", .name = "codec" }}
(C)	[o] link_platforms[] = {{ }};

CPU and Codec info will be filled by COMP_CPU() / COMP_CODEC (= A,B),
and Platform will have empty data by COMP_EMPTY() (= C) in this case.

Platform empty info will be filled when driver probe()
(most of case, CPU info will be copied to use soc-generic-dmaengine-pcm).

For example in case of DPCM FE/BE, it will be like below.
Codec will be dummy Component / DAI in this case (X).

	SND_SOC_DAILINK_DEFS(link,
		     DAILINK_COMP_ARRAY(COMP_CPU(...)),
(X)		     DAILINK_COMP_ARRAY(COMP_DUMMY()),
		     DAILINK_COMP_ARRAY(COMP_EMPTY()));

(X) part will converted like below

	[o] link_codecs[]    = {{ .name = "snd-soc-dummy",
				  .dai_name = "snd-soc-dummy-dai", }}

Even though we already have common asoc_dummy_dlc for dummy
Component / DAI, this macro will re-create new dummy dlc.
Some drivers defines many dai_link info via SND_SOC_DAILINK_DEFS(),
this means many dummy dlc also will be re-created. This is waste of
memory.

If we can use existing common asoc_dummy_dlc at (X),
we can avoid to re-creating dummy dlc, then, we can save the memory.

At that time, we want to keep existing code as much as possible, because
too many drivers are using this macro. But because of its original style,
using common asoc_dummy_dlc from it is very difficult or impossible.

So let's change the mind. The macro is used like below

	SND_SOC_DAILINK_DEFS(link,
		     DAILINK_COMP_ARRAY(COMP_CPU(...)),
(x)		     DAILINK_COMP_ARRAY(COMP_DUMMY()),
		     DAILINK_COMP_ARRAY(COMP_EMPTY()));

	static struct snd_soc_dai_link dai_links[] = {
	{
		.name = ...,
		.stream_name = ...,
(y)		SND_SOC_DAILINK_REG(link),
	},

(y) part will be like below

        static struct snd_soc_dai_link dai_links[] = {
        {
                .name = ...,
                .stream_name = ...,
 ^		...
 |		.codecs		= link_codecs,
(y)		.num_codecs	= ARRAY_SIZE(link_codecs),
 v		...
	}

This patch try to use trick on COMP_DUMMY()

-	#define COMP_DUMMY()	{ .name = "snd-soc-dummy", .dai_name = "snd-soc-dummy-dai", }
+	#define COMP_DUMMY()

By this tric, (x) part will be like below.

before
	[o] link_codecs[] = {{ .name = "snd-soc-dummy", .dai_name = "snd-soc-dummy-dai", }}
after
	[o] link_codecs[] = { };

This is same as below

	[o] link_codecs[0];

This means it has pointer (link_codecs), but the array size is 0.
(y) part will be like below.

	static struct snd_soc_dai_link dai_links[] = {
	{
		...
		.codecs		= link_codecs,
		.num_codecs	= 0,
		...
	},

This is very special settings that normal use usually not do,
but new macro do.
We can find this special settings on soc-core.c and fill it as
"dummy DAI" (= asoc_dummy_dlc). By this tric, we can avoid to re-create
dummy dlc and save the memory.

This patch add tric at COMP_DUMMY() and add snd_soc_fill_dummy_dai()
to fill dummy DAI.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://msgid.link/r/871qbi93qu.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We already have snd_soc_dummy_dlc.
Let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://msgid.link/r/8734vy93r8.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We already have snd_soc_dummy_dlc.
Let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://msgid.link/r/874jge93ri.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We can use SND_SOC_DAILINK_REG() with 2 parameter.
DUMMY Platform is not needed.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://msgid.link/r/875y0u93rq.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We can use SND_SOC_DAILINK_REG() with 2 parameter.
DUMMY Platform is not needed.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://msgid.link/r/877cla93ry.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Removed Unneeded variable: "ret"
Signed-off-by: Himanshu Bhavani <himanshu.bhavani@siliconsignals.io>

Link: https://msgid.link/r/20231218143214.939885-1-himanshu.bhavani@siliconsignals.ioSigned-off-by: Mark Brown <broonie@kernel.org>

Layout of FW version 0x0503 is compatible with 0x0502.
Already supported by TI's tas2781-linux-driver tree.
https://git.ti.com/cgit/tas2781-linux-drivers/tas2781-linux-driver/

Fixes: 915f5ead ("ASoC: tas2781: firmware lib")
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Link: https://msgid.link/r/98d4ee4e01e834af72a1a0bea6736facf43582e0.1702513517.git.soyer@irl.huSigned-off-by: Mark Brown <broonie@kernel.org>

Add bindings for Qualcomm X1E80100 SoC Low Power Audio SubSystem (LPASS)
WSA macro codec, which looks like compatible with earlier SM8550.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://msgid.link/r/20231211123104.72963-4-krzysztof.kozlowski@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Add bindings for Qualcomm X1E80100 SoC Low Power Audio SubSystem (LPASS)
VA macro codec, which looks like compatible with earlier SM8550.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://msgid.link/r/20231211123104.72963-3-krzysztof.kozlowski@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Add bindings for Qualcomm X1E80100 SoC Low Power Audio SubSystem (LPASS)
TX macro codec, which looks like compatible with earlier SM8550.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://msgid.link/r/20231211123104.72963-2-krzysztof.kozlowski@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>