5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Jaroslav Kysela]

Hi,

   could we cherry-pick patch 8cd9956f61c65022209ce6d1e55ed12aea12357d to the 
5.5 stable tree?

8cd9956f61c65022209ce6d1e55ed12aea12357d :
  "ASoC: intel/skl/hda - export number of digital microphones via control 
components"

   Rerefences:

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/817

				Thank you,
					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Wed, Mar 04, 2020 at 04:25:54PM +0100, Jaroslav Kysela wrote:
> Hi,
> 
>   could we cherry-pick patch 8cd9956f61c65022209ce6d1e55ed12aea12357d to the
> 5.5 stable tree?
> 
> 8cd9956f61c65022209ce6d1e55ed12aea12357d :
>  "ASoC: intel/skl/hda - export number of digital microphones via control
> components"

This looks more like a new feature than a bug fix and I've been trying
to get the stable people to calm down with the backports, there's been
*far* too many regressions introduced recently in just the x86 stuff
found after the fact.  Does this fix systems that used to work?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Jaroslav Kysela]

Dne 04. 03. 20 v 16:44 Mark Brown napsal(a):
> On Wed, Mar 04, 2020 at 04:25:54PM +0100, Jaroslav Kysela wrote:
>> Hi,
>>
>>    could we cherry-pick patch 8cd9956f61c65022209ce6d1e55ed12aea12357d to the
>> 5.5 stable tree?
>>
>> 8cd9956f61c65022209ce6d1e55ed12aea12357d :
>>   "ASoC: intel/skl/hda - export number of digital microphones via control
>> components"
> 
> This looks more like a new feature than a bug fix and I've been trying
> to get the stable people to calm down with the backports, there's been
> *far* too many regressions introduced recently in just the x86 stuff
> found after the fact.  Does this fix systems that used to work?

The released ALSA UCM does not work correctly for some platforms without this 
information (the number of digital microphones is not identified correctly).

The regression probability is really low for this one and we're using it in 
Fedora kernels for months without issues (in this code).

				Thanks,
					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On Wed, Mar 04, 2020 at 04:53:27PM +0100, Jaroslav Kysela wrote:
> Dne 04. 03. 20 v 16:44 Mark Brown napsal(a):

> > This looks more like a new feature than a bug fix and I've been trying
> > to get the stable people to calm down with the backports, there's been
> > *far* too many regressions introduced recently in just the x86 stuff
> > found after the fact.  Does this fix systems that used to work?

> The released ALSA UCM does not work correctly for some platforms without
> this information (the number of digital microphones is not identified
> correctly).

That's not the question I asked - have these platforms ever worked with
older kernel versions?

> The regression probability is really low for this one and we're using it in
> Fedora kernels for months without issues (in this code).

It's partly the principle of the thing, if it were just patches that
had individually been identified as being good for stable by someone
with some understanding of the code (like this one :/ ) that were being
backported I'd be a lot less concerned but the automated selections are
missing dependencies or other context and people are reporting problems
with them so I'm inclined to push back on things.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Pierre-Louis Bossart]

>>> This looks more like a new feature than a bug fix and I've been trying
>>> to get the stable people to calm down with the backports, there's been
>>> *far* too many regressions introduced recently in just the x86 stuff
>>> found after the fact.  Does this fix systems that used to work?
> 
>> The released ALSA UCM does not work correctly for some platforms without
>> this information (the number of digital microphones is not identified
>> correctly).
> 
> That's not the question I asked - have these platforms ever worked with
> older kernel versions?

Yes in that digital microphones have been enabled for a very long time 
(5.2 if I am not mistaken).

No in that the automatic selection of the SOF driver was only enabled 
for v5.5. In other words before 5.5 the user or distro needed to 
blacklist the legacy snd-hda-intel HDAudio driver to get DMICs to work.

This patch also removes the need for userspace configuration, pulseaudio 
now directly receives the information on the number of microphones. It 
was provided days after the merge window was opened, but the intent was 
that v5.5 was the first release where users don't need to muck with 
configuration files.

>> The regression probability is really low for this one and we're using it in
>> Fedora kernels for months without issues (in this code).
> 
> It's partly the principle of the thing, if it were just patches that
> had individually been identified as being good for stable by someone
> with some understanding of the code (like this one :/ ) that were being
> backported I'd be a lot less concerned but the automated selections are
> missing dependencies or other context and people are reporting problems
> with them so I'm inclined to push back on things.

You are correct that the process can appear confusing, mainly since the 
initial patch was contributed after the merge window on November 26.

Looking back at the emails, I didn't see any objections but somehow the 
patch never landed in 5.5 updates. Jaroslav's intentions and work are 
not without merit, we really appreciate his ucm2 work, and I support 
this integration on v5.5-y to make the life of downstream distros simpler.

Would it help if we provide a Tested-by tag with 5.5-y + this patch applied?

Thanks
-Pierre

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]

On Wed, Mar 04, 2020 at 11:17:41AM -0600, Pierre-Louis Bossart wrote:

> > That's not the question I asked - have these platforms ever worked with
> > older kernel versions?

> Yes in that digital microphones have been enabled for a very long time (5.2
> if I am not mistaken).

> No in that the automatic selection of the SOF driver was only enabled for
> v5.5. In other words before 5.5 the user or distro needed to blacklist the
> legacy snd-hda-intel HDAudio driver to get DMICs to work.

Ugh, so it is actually fixing a regression since older releases would
have been using snd-hda-audio?

> This patch also removes the need for userspace configuration, pulseaudio now
> directly receives the information on the number of microphones. It was
> provided days after the merge window was opened, but the intent was that
> v5.5 was the first release where users don't need to muck with configuration
> files.

If you're sending patches after the merge window has opened you've
obviously missed the boat, things need to be in -next before the merge
window.  If that's a problem for your schedules that's unfortunate for
you but not really relevant upstream, you need to ensure that people
know that getting features depends on upstream review which definitely
isn't going to happen if you don't post the patches before the merge
window.  If things are important you should ensure they're out there
well before the merge window in case there's any issues with review or
the merge window opens sooner than expected for some reason.

> > It's partly the principle of the thing, if it were just patches that
> > had individually been identified as being good for stable by someone
> > with some understanding of the code (like this one :/ ) that were being
> > backported I'd be a lot less concerned but the automated selections are
> > missing dependencies or other context and people are reporting problems
> > with them so I'm inclined to push back on things.

> You are correct that the process can appear confusing, mainly since the
> initial patch was contributed after the merge window on November 26.

I'm sorry but I'm unclear what process confusion you're referring to?

> Looking back at the emails, I didn't see any objections but somehow the
> patch never landed in 5.5 updates. Jaroslav's intentions and work are not
> without merit, we really appreciate his ucm2 work, and I support this
> integration on v5.5-y to make the life of downstream distros simpler.

If something is a fix you need to clearly identify it as a fix when you
submit it upstream.

This thread is the first suggestion I've seen that this is any kind of
bug fix.  There's no Fixes tag and the patch description itself sounds
like it's adding a new feature to enable new functionality in userspace
(autodetection by UCM) and it was posted as part of a series "ASoC: SOF:
initial cleanup for DT and multi-client support" which again doesn't
give any indication that this might be supposed to be a bug fix.  It
looks perfectly fine as a new feature so of course there were no
objections.

> Would it help if we provide a Tested-by tag with 5.5-y + this patch applied?

It won't hurt but that's not really the point here.  Lots of new
features don't actually break things if they're backported.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Pierre-Louis Bossart]

> This thread is the first suggestion I've seen that this is any kind of
> bug fix.  There's no Fixes tag and the patch description itself sounds
> like it's adding a new feature to enable new functionality in userspace
> (autodetection by UCM) and it was posted as part of a series "ASoC: SOF:
> initial cleanup for DT and multi-client support" which again doesn't
> give any indication that this might be supposed to be a bug fix. 

the initial patch came from Jaroslav on 11/26, not from me. Quoting your 
own words:

"Since Pierre seems happy with it even if he didn't ack it explicitly
I'll guess I'll apply it.  If git can figure out applying it after the
merge window and it doesn't get negative reviews there's no need to
resend.  If it can't and it doesn't turn up in a bigger series before
then I'll let you know.
"

That patch was however not applied, that's the confusion I was referring 
to, and I included it in an SOF v2 series as agreed along with a rebase 
of the DT/multiclient support stuff to avoid conflicts between patchsets.

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

On Wed, Mar 04, 2020 at 12:50:54PM -0600, Pierre-Louis Bossart wrote:

> > This thread is the first suggestion I've seen that this is any kind of
> > bug fix.  There's no Fixes tag and the patch description itself sounds
> > like it's adding a new feature to enable new functionality in userspace
> > (autodetection by UCM) and it was posted as part of a series "ASoC: SOF:
> > initial cleanup for DT and multi-client support" which again doesn't
> > give any indication that this might be supposed to be a bug fix.

> the initial patch came from Jaroslav on 11/26, not from me. Quoting your own
> words:

> "Since Pierre seems happy with it even if he didn't ack it explicitly
> I'll guess I'll apply it.  If git can figure out applying it after the
> merge window and it doesn't get negative reviews there's no need to
> resend.  If it can't and it doesn't turn up in a bigger series before
> then I'll let you know.
> "

Right, that's me saying I'll apply something that looks like normal
development work after the merge window as with other normal development
work (even Jaroslav's initial version was sent after the merge window
opened), not that I'll apply it as a fix.  There's no hint in any of
that thread or in your resend that this was anything other than a new
feature, and indeed you were talking about wanting to integrate it with
a series that you didn't want to see in v5.5.  Jaroslav mentioned not
wanting to delay if it'd cause him to miss the merge window but didn't
seem to complain when I said he'd missed it with his initial posting.

Anyway, is my understanding correct that this is fixing a regression
caused by switching the default to SOF?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Pierre-Louis Bossart]

On 3/4/20 1:06 PM, Mark Brown wrote:
> On Wed, Mar 04, 2020 at 12:50:54PM -0600, Pierre-Louis Bossart wrote:
> 
>>> This thread is the first suggestion I've seen that this is any kind of
>>> bug fix.  There's no Fixes tag and the patch description itself sounds
>>> like it's adding a new feature to enable new functionality in userspace
>>> (autodetection by UCM) and it was posted as part of a series "ASoC: SOF:
>>> initial cleanup for DT and multi-client support" which again doesn't
>>> give any indication that this might be supposed to be a bug fix.
> 
>> the initial patch came from Jaroslav on 11/26, not from me. Quoting your own
>> words:
> 
>> "Since Pierre seems happy with it even if he didn't ack it explicitly
>> I'll guess I'll apply it.  If git can figure out applying it after the
>> merge window and it doesn't get negative reviews there's no need to
>> resend.  If it can't and it doesn't turn up in a bigger series before
>> then I'll let you know.
>> "
> 
> Right, that's me saying I'll apply something that looks like normal
> development work after the merge window as with other normal development
> work (even Jaroslav's initial version was sent after the merge window
> opened), not that I'll apply it as a fix.  There's no hint in any of
> that thread or in your resend that this was anything other than a new
> feature, and indeed you were talking about wanting to integrate it with
> a series that you didn't want to see in v5.5.  Jaroslav mentioned not
> wanting to delay if it'd cause him to miss the merge window but didn't
> seem to complain when I said he'd missed it with his initial posting.

ok, I misunderstood your reply then. I thought you would provide it as 
an update for v5.5, thanks for the clarification

> Anyway, is my understanding correct that this is fixing a regression
> caused by switching the default to SOF?

This is fixing a regression on platforms that have digital microphones, 
where SOF is automatically selected by default. For platforms without 
DMICs, the legacy driver is still used and this patch has no effect.

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Wed, Mar 04, 2020 at 01:30:59PM -0600, Pierre-Louis Bossart wrote:
> On 3/4/20 1:06 PM, Mark Brown wrote:

> > Anyway, is my understanding correct that this is fixing a regression
> > caused by switching the default to SOF?

> This is fixing a regression on platforms that have digital microphones,
> where SOF is automatically selected by default. For platforms without DMICs,
> the legacy driver is still used and this patch has no effect.

OK, in that case this should go in then - it's certainly a lot better
than reverting the switch to SOF.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Sasha Levin]

On Wed, Mar 04, 2020 at 04:25:54PM +0100, Jaroslav Kysela wrote:
>Hi,
>
>  could we cherry-pick patch 8cd9956f61c65022209ce6d1e55ed12aea12357d 
>to the 5.5 stable tree?

Queued up for 5.5, thank you.

-- 
Thanks,
Sasha