Idisp indexes

[juimonen]

demux topologies won't load without this change in apl/up2

[plbossart]

what does this have to do with demux? Or this is to align with recent changes on the hdaudio machine driver?

[plbossart]

also the second index is the dailink_index, and I don't see it having changed so far:

structsnd_soc_dai_linkskl_hda_be_dai_links[HDA_DSP_MAX_BE_DAI_LINKS] = {
/* Back End DAI links */
{
.name="iDisp1",
.id=1,
.dpcm_playback=1,
.no_pcm=1,
SND_SOC_DAILINK_REG(idisp1_cpu, idisp1_codec, platform),
},
{
.name="iDisp2",
.id=2,
.dpcm_playback=1,
.no_pcm=1,
SND_SOC_DAILINK_REG(idisp2_cpu, idisp2_codec, platform),
},
{
.name="iDisp3",
.id=3,
.dpcm_playback=1,
.no_pcm=1,
SND_SOC_DAILINK_REG(idisp3_cpu, idisp3_codec, platform),
},

[juimonen]

@kv2019i is this correct?

[kv2019i]

@juimonen wrote (and @plbossart asked):

@kv2019i is this correct?

This is related to @lyakh changed ad7b1d2 that was recently merged.

Kernel driver is now changes to use to new ids, so all topologies need to match.

[juimonen]

@kv2019i but I should not change this in generic-hda, which was the other commit in this pr?

[kv2019i]

@kv2019i but I should not change this in generic-hda, which was the other commit in this pr?

Aa, sorry -- no, the generic-hda should not be changed, the ids were only changed for up2-pcm512.

[juimonen]

@kv2019i@plbossart ok my mistake. Removed hda-generic from this PR, now only includes the demux-apl prt.

[plbossart]

the comment above is incorrect

[juimonen]

ok fixed now.

[plbossart]

ok the indices look fine, but I am not sure I understand this line

# currently this dai is here as "virtual" capture backend
W_DAI_IN(SSP, 5, SSP5-Codec, s24le, 3, 0)

what is the purpose of this line?

What happens if we truly want to use SSP5 for capture?

[juimonen]

@plbossart I have to test and think that a bit. Frankly I was just now trying to load the demux component for testing my topology work and loading stopped because of wrong idisp indexes. IOW I didn't actually test does the topology work, with this it at least loads.

[juimonen]

anything blocking of merging this simple PR?

[plbossart]

anything blocking of merging this simple PR?

" I didn't actually test does the topology work, with this it at least loads."

Shouldn't we have functional topologies in the SOF tree?

[juimonen]

@plbossart well ok let's say this is an improvement to the current status. But yeah, no traction so let's close it. I can push it later if someone needs it. Maybe then remove the apl-demux conf altogether as it really doesn't load atm?