Commit 25612477d20b ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper") makes things worse (for me) by requiring all the elements on the link to support the stream direction for the direction to be enabled.
This breaks platforms where there is multiple codecs with different capabilities on a link. For example, we may have 2 codecs on a link, one doing playback, the other capture. This is the case on several Amlogic platforms.
With the new meaning of those flag, the card driver has to set something that ASoC core will also compute on its own, and verify it agrees with the card. This is redundant. What is the point of this ? Can't we just cut the middle man then ?
The old meaning at least allowed to pass the additional information that a direction was to be forcefully disabled. This is also redundant with capture_only/playback_only though ...
My plan was to remove two of the 4 flags after all configurations were checked.
Can we revert this change until we figure out to do with those flags ?
I could propose a patch to move on but I'm not entirely clear what it kind of restriction we were trying to put on Multi-CPU links
IMO, on a Multi-CPU/Multi-Codec link, we should allow the direction as long as at least one CPU and one Codec on the link are capable of handling the direction (not all of them, as it seems to be set now)
You have a valid point Jerome. I must admit I was looking at TDM configurations, where we do want all DAIs in the same dailink to be consistent.
But when I checked older code there is indeed a precedent for some KabyLake platforms with an amplifier on playback and a microphone codec on capture for the same dailink.
I think your proposal of checking that at least one DAI matches the dailink capabilities, and conversely changing the helper to set the properties if one or more dais support a direction smay indeed be required.
If this was a feature and not a bug to have different capabilities on the same link so be it. Mark, do you concur?