On Thu 30 Jul 2020 at 18:06, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
On 7/30/20 4:04 AM, Jerome Brunet wrote:
On Wed 29 Jul 2020 at 17:56, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com 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?
You get to throw an error in those case
What happens if none of these flags are set?
I think I already suggested to throw an error in the initial review of your patch
What happens when all these flags are set?
I don't see the problem here
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.
If it was not working, it was certainly not clear in the changelog. What's clear is the regression it caused
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.
Sure, have it your way