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?
