5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"
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
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?
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
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.
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
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.
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.
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?
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.
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.
participants (4)
-
Jaroslav Kysela -
Mark Brown -
Pierre-Louis Bossart -
Sasha Levin