topology: add ADL SoundWire support

[plbossart]

add topologies based on early hardware information

For tests and checks only for now, need to make sure new macros don't introduce regressions

[plbossart]

@bardliao @RanderWang I am completely lost on the meaning of the 'SDW%d-Playback/Capture' string, is this actually used for anything? If yes, what is the convention that needs to be followed when we swap devices around?

[plbossart]

FWIW I tested the output of the first patch (with the removal of hex values) and the last, and the .tplg binaries are identical. The .conf are different only with blanks, no content difference.

[bardliao]

@bardliao @RanderWang I am completely lost on the meaning of the 'SDW%d-Playback/Capture' string, is this actually used for anything? If yes, what is the convention that needs to be followed when we swap devices around?

@plbossart 'SDW%d-Playback/Capture' is the stream name, and the %d represents sdw ink id.
See https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/intel/boards/sof_sdw.c#L787

[plbossart]

@bardliao @RanderWang I am completely lost on the meaning of the 'SDW%d-Playback/Capture' string, is this actually used for anything? If yes, what is the convention that needs to be followed when we swap devices around?

@plbossart 'SDW%d-Playback/Capture' is the stream name, and the %d represents sdw ink id.
See https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/intel/boards/sof_sdw.c#L787

Hehe. If I asked the question @RanderWang, that's precisely because I have no idea what this code does. What I was asking is a high-level description of how these link IDs are determined.

[lgirdwood]

SOFCI TEST

[RanderWang]

@bardliao @RanderWang I am completely lost on the meaning of the 'SDW%d-Playback/Capture' string, is this actually used for anything? If yes, what is the convention that needs to be followed when we swap devices around?

@plbossart 'SDW%d-Playback/Capture' is the stream name, and the %d represents sdw ink id.
See https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/intel/boards/sof_sdw.c#L787

Hehe. If I asked the question @RanderWang, that's precisely because I have no idea what this code does. What I was asking is a high-level description of how these link IDs are determined.

ASoC use 'SDW%d-Playback/Capture' to match FE in topology and BE in machine driver. the %d here means link id, this requires that DAI name in topology should match this stream name in BE, .e.g if rt711 is at link0, it should always set DAI name to SDW0-playback/capture in topology. We don't care its position in ADR table in ACPI_MACH

[RanderWang]

And if the definition sequence of rt711 in topology and _ADR table is different, be care of DAI index in topology since machine driver allocates DAI index based on the definition sequence in _ADR table (id++)

[plbossart]

And if the definition sequence of rt711 in topology and _ADR table is different, be care of DAI index in topology since machine driver allocates DAI index based on the definition sequence in _ADR table (id++)

Not getting the idea, sorry. The wording above refers twice to _ADR table and I don't understand it at all.

The _ADR table also have some inversions, and I wonder if this was intentional, harmless or a mistake that the links are not ordered in the following case:

static const struct snd_soc_acpi_link_adr tgl_sdw_rt711_link1_rt1308_link2_rt715_link0[] = {
	{
		.mask = BIT(1),
		.num_adr = ARRAY_SIZE(rt711_1_adr),
		.adr_d = rt711_1_adr,
	},
	{
		.mask = BIT(2),
		.num_adr = ARRAY_SIZE(rt1308_2_single_adr),
		.adr_d = rt1308_2_single_adr,
	},
	{
		.mask = BIT(0),
		.num_adr = ARRAY_SIZE(rt715_0_adr),
		.adr_d = rt715_0_adr,
	},
	{}
};

[marc-hb]

Github Actions hang fixed by #3992, please git commit --amend and force push if you want to re-trigger.

[RanderWang]

And if the definition sequence of rt711 in topology and _ADR table is different, be care of DAI index in topology since machine driver allocates DAI index based on the definition sequence in _ADR table (id++)

Not getting the idea, sorry. The wording above refers twice to _ADR table and I don't understand it at all.

The _ADR table also have some inversions, and I wonder if this was intentional, harmless or a mistake that the links are not ordered in the following case:

static const struct snd_soc_acpi_link_adr tgl_sdw_rt711_link1_rt1308_link2_rt715_link0[] = {
	{
		.mask = BIT(1),
		.num_adr = ARRAY_SIZE(rt711_1_adr),
		.adr_d = rt711_1_adr,
	},
	{
		.mask = BIT(2),
		.num_adr = ARRAY_SIZE(rt1308_2_single_adr),
		.adr_d = rt1308_2_single_adr,
	},
	{
		.mask = BIT(0),
		.num_adr = ARRAY_SIZE(rt715_0_adr),
		.adr_d = rt715_0_adr,
	},
	{}
};

For this case, we need to set SDW1-playback & capture to rt711 , and SDW0-capture to rt715, SDW2-playback to rt1308 in topology

And even we put rt715 at first entry in this table, we still need to follow above setting since we only care link id (.mask). I mean the order is harmless and we only check link id (.mask)

[plbossart]

This PR was tested by @libinyang, the ACPI changes were merged with thesofproject/acpi-scripts#11

This looks good enough for a review now.

[RanderWang]

LGTM