On Thu 30 Jul 2020 at 20:52, Mark Brown <broonie@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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.
