[xiulipan]

pcm_prepare will call only sof_pcm_hw_params and it will skip BE dai.
There will be some issue to find the right BE dai with
snd_sof_find_spcm_dai.

Signed-off-by: Pan Xiuli xiuli.pan@linux.intel.com

[xiulipan]

@plbossart @ranj063 some kind of fix to thesofproject/sof#1250
Still not sure why we skip all BE dai in sof_pcm_ and if we need to support find the right BE with snd_sof_find_spcm_dai.
If we did, we may need to have some more logic here.

@RanderWang
I think for the mixer issues, here is the main problem. We will have two pcm stream bind with the same BE. I am very sure now the snd_sof_find_spcm_dai will not find the right BE for this situation.

[ranj063]

@xiulipan i just fixed a bunch of these copy past errors. "todo" is not one word. it should be "to do". Otherwise the fix looks correct.

[xiulipan]

@ranj063
So should I fix this only or just fix all the todo? Since I copy paste it from the existing other function.

[xiulipan]

@ranj063
And any idea if we will need to find BE from snd_sof_find_spcm_dai?

[ranj063]

@ranj063
And any idea if we will need to find BE from snd_sof_find_spcm_dai?

@xiulipan no, if you look at sof_load_dai(), we dont create spcm for a BE.

[plbossart]

For Pete's sake, please do not use 'some issue' in any issue or commit message. You have to clearly state what you are fixing

[xiulipan]

@plbossart @ranj063
Update the comments as I am sure what the problem here now.
I first thought it was a tplg issue, since only happen on BYT-NOCODEC but not on APL-NOCODEC.
Now I know that APL have some luck in tplg that have same id for FE and BE.

[ranj063]

LGTM

[plbossart]

@plbossart @ranj063
Update the comments as I am sure what the problem here now.
I first thought it was a tplg issue, since only happen on BYT-NOCODEC but not on APL-NOCODEC.
Now I know that APL have some luck in tplg that have same id for FE and BE.

Sorry, what are you trying to say with 'some luck'. it's not a common English wording and I could interpret it in ways you did not intend.

[xiulipan]

@plbossart
If coincidence would work for you? To me the UP2 is very luck to not be influenced by this bug.
For UP2 all FE and BE share the same dai id.
But for BYT, FE have dai id of 0 and 1. The BE dai id is 2.

[plbossart]

@xiulipan did you mean the Up2 board works by accident? I can accept the argument, but I don't get what changed and resulted in the Minnowboard no longer working because of dai link indexes. I am not aware of topology changes and I do recall testing a long time ago when we fixed the SSP register settings.

[xiulipan]

@plbossart
As in this PR, we skip the sof_pcm_prepare for BE.
If sof_pcm_prepare is called on BE and it will call snd_sof_find_spcm_dai to get the spcm of BE. This should not be happen before. And APL can get the spcm with snd_sof_find_spcm_dai by accident since it have same id for BE and FE. In fact sof_pcm_prepare actually will did nothing for BE and just return 0.
But if no spcm of BE is found, error will be reported

	spcm = snd_sof_find_spcm_dai(sdev, rtd);
	if (!spcm)	
		return -EINVAL;

[ranj063]

@plbossart I can explain this. pcm_prepare ioctl is a recent addition following Takashi's suggestion and the first thing it does it look up the spcm with the dai link id to see if the hw_params needs to be set up again or not and this ioctl is called for both FE and BE dailinks. In the case of BE, we should just return without doing anything (which is what this PR does).

As to why we didnt create trouble on the UP2 nocodec case: It's because when we find a spcm for a dai link we use the dai link ID to match and if you look in the topology we have a perfect match between FE and BE dai link ID's. So we will return a valid spcm for all the BE dai links as well.

But in the byt nocodec topology, the FE dai link ID's are 0 and 1 whereas we only define BE dai link for SSP2 is 2 and this results in the match returning a NULL.

[plbossart]

thanks @ranj063. I wish I had seen those explanations earlier with a bit more context on what problem this addressed. It's really a consistent pattern of not describing what is being fixed, what generated the issue and how it's being fixed.