Re: [PATCH] ASoC: core: restore dpcm flags semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux