On Thu 30 Jul 2020 at 20:52, Mark Brown broonie@kernel.org wrote:
On Thu, Jul 30, 2020 at 11:06:23AM -0500, Pierre-Louis Bossart 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:
The flag previously allowed card drivers to disable a stream direction on a link (whether or not such feature is deemed useful).
Right, and I can see a use case for this if someone has a board that for some reason didn't physically connect one of the directions for some reason - perhaps they were running out of pins or something. It's not clear if anyone's actually doing that though.
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.
I'm not 100% clear, have we actually found cases where the flags are used or is this something found through inspection and review?
One last thing I'd like to understand. Is this behavior of throwing an error going to applied to the non-DPCM case as well ? so at least thing are consistent between both cases ?
IOW: * An error is now throw if dpcm_capture is set on the link and the CPU DAI support playback_only * on non-DPCM links, will an error be thrown as well if playback_only is not set and the CPU on the link happen to not support capture ?
- 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.
This was all triggered by Morimoto-san's changes like you say. DPCM has quite a lot of problems in general, here IIRC the issues were that we had multiple different ways of doing similar things which it wasn't quite clear if people were even using. The intention with the warnings was to remove them one way or another, they're mainly intended to flush out actual active usage of the flags as opposed to redundant usage of them which could be confused/broken.
This could definitely have been clearer in the changelogs though.