[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7cd79261-6f8d-cad0-c65b-57570a40a6b6@linux.intel.com>
Date: Fri, 12 Jun 2020 08:54:11 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Mark Brown <broonie@...nel.org>,
John Stultz <john.stultz@...aro.org>
Cc: Takashi Iwai <tiwai@...e.de>, Liam Girdwood <lgirdwood@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Bard Liao <yung-chuan.liao@...ux.intel.com>,
Guennadi Liakhovetski <guennadi.liakhovetski@...ux.intel.com>,
Srini Kandagatla <srinivas.kandagatla@...aro.org>,
Vinod Koul <vinod.koul@...aro.org>,
Amit Pundir <amit.pundir@...aro.org>
Subject: Re: [GIT PULL] sound fixes for 5.8-rc1
On 6/12/20 7:19 AM, Mark Brown wrote:
> On Thu, Jun 11, 2020 at 05:49:29PM -0700, John Stultz wrote:
>> On Thu, Jun 11, 2020 at 5:13 PM John Stultz <john.stultz@...aro.org> wrote:
>
>>> I've bisected it down to the following commit from this pull req:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b73287f0b0745961b14e5ebcce92cc8ed24d4d52
>
> For the benefit of readers that's "ASoC: soc-pcm: dpcm: fix
> playback/capture checks".
>
>> I don't know the backgroun again, but would something like the
>> following make sense?
>> https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/db845c-mainline-WIP&id=7e49b248db77b5ed29b2aa278268e77650c75482
>
> That's a small out of tree test patch which has no changelog so I'm not
> entirely clear what the intent or motivation is but it looks like the
> goal is to change so that we only warn when a link says it supports
> playback/capture but some of the DAIs lack the capability instead of
> returning an error. I'm not sure I understand how that helps, it seems
> like the link is still misconfigured and we still have a warning which
> isn't great? Surely the issue is that we've flagged the link as
> supporting capture when it doesn't?
Indeed the addition of stricter checks will expose cases where the links
are not well configured, probably for years. The patch "ASoC: soc-pcm:
dpcm: fix playback/capture checks" did not add those checks, only fixed
them for the multi-dai case.
I think that those configuration errors are the problem and should be
fixed as a prerequisite to the removal of the duplication between
dpcm_playback/dpcm_capture/playback_only/capture_only. it may be painful
and generate noise for a while, but if we only throw a warning what are
the odds all those configuration errors will eventually be fixed?
If we need more time for validation on all platforms, then maybe we can
first relax the check for 5.8-rc1 as suggested by John, but re-add the
-EINVAL on -next to give a target of 5.9 with all configurations fixed?
Powered by blists - more mailing lists