On 7/30/20 4:04 AM, Jerome Brunet wrote:
On Wed 29 Jul 2020 at 17:56, Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote:
On 7/29/20 10:46 AM, Jerome Brunet wrote:
commit b73287f0b0745 ('ASoC: soc-pcm: dpcm: fix playback/capture checks')
changed dpcm_playback and dpcm_capture semantic by throwing an error if
these flags are not aligned with DAIs capabilities on the link.
The former semantic did not force the flags and DAI caps to be aligned.
The flag previously allowed card drivers to disable a stream direction on
a link (whether or not such feature is deemed useful).
With change ('ASoC: core: use less strict tests for dailink capabilities')
an error is thrown if the flags and and the DAI caps are not aligned. Those
parameters were not meant to aligned initially. No technical reason was
given about why cards should now be considered "broken" in such condition
is not met, or why it should be considered to be an improvement to enforce
that.
Forcing the flags to be aligned with DAI caps just make the information
the flag carry redundant with DAI caps, breaking a few cards along the way.
This change drops the added error conditions and restore the initial flag
semantics.
or rather lack thereof.
Again, why ? All there is so far is your personal preference. no facts.
What would be the meaning/purpose of a dailink with .dpcm_capture set,
with only dais that support playback only?
What would be the meaning/purpose of a dailink with .capture_only set,
but with a dai that supports playback?
What happens if none of these flags are set?
What happens when all these flags are set?
No one seems to know, so my suggestion is to align first on consistent
configurations, then see what can be removed.
* What we had gave capabilities to the link, independent of the DAI
components. ASoC just computes the intersection of all that to
determine which direction needs to be enabled. Seems rather simple
and straight forward.
that's what my last patch did, and when there is no intersection it
complains. Please clarify what you expect when there is no overlap
between dai and dailink capabilities. Keep in mind that we have a mix of
hard-codec configuration and DT-created ones, your case is not the
general one.
* It worked for every user of DPCM so a far.
Not completely true, when Morimoto-san added snd_soc_dai_stream_valid()
it exposed tons of cases where the information on direction was not
provided in a reliable at the DAI level. I will assert that we are still
finding out cases with broken DAI configurations, and as a result we
will also find broken dailink configurations. Your picture of DPCM as a
perfectly functional system that I broke is a distortion of reality.
The reality is that we have to work in steps, first make sure all DAIs
are properly described, then work on the dailinks and optimize at a
later point. we will need warnings to find out what the problem cases
are, and move slowly.
