Re: [GIT PULL] sound updates for 5.9
On Mon, Aug 10, 2020 at 10:06 AM Srinivas Kandagatla wrote: > > Hi John, > Thanks for reporting this. > > On 08/08/2020 01:23, John Stultz wrote: > > q6routing remoteproc-adsp:glink-edge:apr:apr-service@8:routing: ASoC: > > error at soc_component_read_no_lock on > > remoteproc-adsp:glink-edge:apr:: -5 > > This is an -EIO error which is reported when the ASoC component driver > does not have both regmap and read callback and someone is trying to > read a register! > > In q6routing case all the dapm widgets reuse reg field in > snd_soc_dapm_widget to store offset information or routing table indexs > or some DSP related id and so on... These are not real registers. > > I think the core is trying to read the state of these widgets during > startup, Which will fail in qdsp6 case as we do not have any regmap or > read callback associated with this ASoC component. > > Previously we never had chance to see these messages so we did not > implement any dummy read callback. > > Adding a dummy callback to q6routing and q6afe-dai ASoC component will > fix this issue at-least in Qualcomm case! Yea, just to confirm. The patch you sent me privately that does the above seems to work! Thanks so much! -john
Re: [GIT PULL] sound updates for 5.9
On Mon, Aug 10, 2020 at 06:06:14PM +0100, Srinivas Kandagatla wrote: > In q6routing case all the dapm widgets reuse reg field in > snd_soc_dapm_widget to store offset information or routing table indexs or > some DSP related id and so on... These are not real registers. > I think the core is trying to read the state of these widgets during > startup, Which will fail in qdsp6 case as we do not have any regmap or read > callback associated with this ASoC component. Yes, it will try to figure out the current state of things during startup. > Previously we never had chance to see these messages so we did not implement > any dummy read callback. So I guess this is another instance of the issues with other things, just having an effect beyond the cosmetic this time :/ > Adding a dummy callback to q6routing and q6afe-dai ASoC component will fix > this issue at-least in Qualcomm case! Yes, that's going to be better for robustness regardless of changes in the core - just pick a default state if the underlying thing is undefined. signature.asc Description: PGP signature
Re: [GIT PULL] sound updates for 5.9
Hi John, Thanks for reporting this. On 08/08/2020 01:23, John Stultz wrote: q6routing remoteproc-adsp:glink-edge:apr:apr-service@8:routing: ASoC: error at soc_component_read_no_lock on remoteproc-adsp:glink-edge:apr:: -5 This is an -EIO error which is reported when the ASoC component driver does not have both regmap and read callback and someone is trying to read a register! In q6routing case all the dapm widgets reuse reg field in snd_soc_dapm_widget to store offset information or routing table indexs or some DSP related id and so on... These are not real registers. I think the core is trying to read the state of these widgets during startup, Which will fail in qdsp6 case as we do not have any regmap or read callback associated with this ASoC component. Previously we never had chance to see these messages so we did not implement any dummy read callback. Adding a dummy callback to q6routing and q6afe-dai ASoC component will fix this issue at-least in Qualcomm case! thanks, srini
Re: [GIT PULL] sound updates for 5.9
On Mon, 10 Aug 2020 14:22:54 +0200, Mark Brown wrote: > > On Sat, Aug 08, 2020 at 10:07:36AM +0200, Takashi Iwai wrote: > > Takashi Iwai wrote: > > > > Does the patch below fix the bug? If so, it's rather a bug in the > > > commit cf6e26c71bfd ("ASoC: soc-component: merge > > > snd_soc_component_read() and snd_soc_component_read32()"). > > > That said, the commit cf6e26c71bfd dropped the capability of returning > > an error code from snd_soc_component_read() completely, while many > > code still expect an error gets returned. The assumption mentioned in > > the patch (the error can be ignored) looks too naive. > > I did an audit of the users when the series was posted and wasn't able > to turn up any code doing anything constructive with the return values, > but then once you're past probe error handling often makes things worse > if you try. This is the first one which actually seems to have had an > impact. > > > Morimoto-san, Mark, could you address it? IMO, we may still need two > > variants in the end again: the former snd_soc_component_read32() that > > returns the value directly and snd_soc_component_read() that returns 0 > > or an error. Only once after we deal with the error handling in each > > caller side, we can unify the read functions. > > I'm not sure if that specifically is what we need but yeah we should do > something, if it fixes things your change is certainly good for the > immediate problem so could you send it with a signoff please? OK, will do soon later. > With the new code we do now have the core code printing an error message > if the I/O fails, before they were just being ignored more often than > not. This did turn up a couple of cases where drivers were relying on > being able to do things like silently read from registers that just > don't exist or aren't currently accessible without any diagnostics which > is it's own problem :/ (especially the volatile cases). Yeah, we may need some raw access helper for such a case... thanks, Takashi
Re: [GIT PULL] sound updates for 5.9
On Sat, Aug 08, 2020 at 10:07:36AM +0200, Takashi Iwai wrote: > Takashi Iwai wrote: > > Does the patch below fix the bug? If so, it's rather a bug in the > > commit cf6e26c71bfd ("ASoC: soc-component: merge > > snd_soc_component_read() and snd_soc_component_read32()"). > That said, the commit cf6e26c71bfd dropped the capability of returning > an error code from snd_soc_component_read() completely, while many > code still expect an error gets returned. The assumption mentioned in > the patch (the error can be ignored) looks too naive. I did an audit of the users when the series was posted and wasn't able to turn up any code doing anything constructive with the return values, but then once you're past probe error handling often makes things worse if you try. This is the first one which actually seems to have had an impact. > Morimoto-san, Mark, could you address it? IMO, we may still need two > variants in the end again: the former snd_soc_component_read32() that > returns the value directly and snd_soc_component_read() that returns 0 > or an error. Only once after we deal with the error handling in each > caller side, we can unify the read functions. I'm not sure if that specifically is what we need but yeah we should do something, if it fixes things your change is certainly good for the immediate problem so could you send it with a signoff please? With the new code we do now have the core code printing an error message if the I/O fails, before they were just being ignored more often than not. This did turn up a couple of cases where drivers were relying on being able to do things like silently read from registers that just don't exist or aren't currently accessible without any diagnostics which is it's own problem :/ (especially the volatile cases). signature.asc Description: PGP signature
Re: [GIT PULL] sound updates for 5.9
On Fri, Aug 7, 2020 at 11:46 PM Takashi Iwai wrote: > > On Sat, 08 Aug 2020 02:23:24 +0200, > John Stultz wrote: > > > > On Thu, Aug 6, 2020 at 3:33 AM Takashi Iwai wrote: > > > > > > Linus, > > > > > > please pull sound updates for v5.9 from: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > > > tags/sound-5.9-rc1 > > > > > > The topmost commit is c7fabbc51352f50cc58242a6dc3b9c1a3599849b > > > > > > > > > > > > sound updates for 5.9 > > > > > > This became wide and scattered updates all over the sound tree as > > > diffstat shows: lots of (still ongoing) refactoring works in ASoC, > > > fixes and cleanups caught by static analysis, inclusive term > > > conversions as well as lots of new drivers. Below are highlights: > > > > > > ASoC core: > > > * API cleanups and conversions to the unified mute_stream() call > > > * Simplify I/O helper functions > > > * Use helper macros to retrieve RTD from substreams > > ... > > > Kuninori Morimoto (90): > > > ASoC: soc-component: add soc_component_pin() and share code > > > ASoC: soc-component: move snd_soc_component_xxx_regmap() to > > > soc-component > > > ASoC: soc-component: move snd_soc_component_initialize() to > > > soc-component.c > > > ASoC: soc-component: add soc_component_err() > > > ASoC: soc-component: add snd_soc_pcm_component_prepare() > > > ASoC: soc-component: add snd_soc_pcm_component_hw_params() > > > ASoC: soc-component: add snd_soc_pcm_component_hw_free() > > > ASoC: soc-component: add snd_soc_pcm_component_trigger() > > > ASoC: soc-component: add snd_soc_component_init() > > > ASoC: soc-component: merge soc-io.c into soc-component.c > > > > So oddly, today I bisected down the change "ASoC: soc-component: merge > > soc-io.c into soc-component.c": > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=460b42d162e3cf634586999e6a84e74ca52e626d > > > > as causing audio regressions on Dragonboard 845c running AOSP. > > > > On boot I was seeing tons of: > > q6routing remoteproc-adsp:glink-edge:apr:apr-service@8:routing: ASoC: > > error at soc_component_read_no_lock on > > remoteproc-adsp:glink-edge:apr:: -5 > > > > And when audio was supposed to play I'd see: > > [ 227.462986] qcom-q6afe aprsvc:apr-service:4:4: cmd = 0x100e5 > > returned error = 0x9 > > [ 227.470720] qcom-q6afe aprsvc:apr-service:4:4: DSP returned error[9] > > [ 227.477168] qcom-q6afe aprsvc:apr-service:4:4: AFE enable for port > > 0x4000 failed -22 > > [ 227.485038] q6afe-dai > > remoteproc-adsp:glink-edge:apr:apr-service@4:dais: fail to start AFE > > port 2 > > [ 227.494013] q6afe-dai > > remoteproc-adsp:glink-edge:apr:apr-service@4:dais: ASoC: error at > > snd_soc_pcm_dai_prepare on SLIMBUS_0_RX: -22 > > [ 227.506034] SLIM Playback: ASoC: DAI prepare error: -22 > > [ 227.511415] SLIM Playback: ASoC: backend prepare failed -22 > > > > Its strange, as the bisected patch is really just moving code around > > and there's very little in the way of logic changes. After minimizing > > the code movement and just focusing on what changed I forward ported a > > revert to mainline and minimized it until things were working. > > > > The resulting patch is a twoliner here: > > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/db845c-mainline-WIP&id=a3527193f39b1224d59bf1519fce3ef8c57d0f5e > > > > I'm a bit baffled as to why this patch works. Logically we are > > returning the same value. I suspect when we hit the error, all the > > extra error print messages on the console slow things down and end up > > causing some timing related initialization failure? > > Does the patch below fix the bug? If so, it's rather a bug in the > commit cf6e26c71bfd ("ASoC: soc-component: merge > snd_soc_component_read() and snd_soc_component_read32()"). > > > thanks, > > Takashi > > --- a/sound/soc/soc-component.c > +++ b/sound/soc/soc-component.c > @@ -406,7 +406,7 @@ static unsigned int soc_component_read_no_lock( > ret = -EIO; > > if (ret < 0) > - soc_component_ret(component, ret); > + return soc_component_ret(component, ret); Oh, that's so obvious now! I can't believe I was staring at that code and just didn't see it! Thanks so much for pointing this out! I'm sure this will fix it, but will validate on monday when I am working with the board. thanks! -john
Re: [GIT PULL] sound updates for 5.9
On Sat, 08 Aug 2020 08:46:18 +0200, Takashi Iwai wrote: > > On Sat, 08 Aug 2020 02:23:24 +0200, > John Stultz wrote: > > > > On Thu, Aug 6, 2020 at 3:33 AM Takashi Iwai wrote: > > > > > > Linus, > > > > > > please pull sound updates for v5.9 from: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > > > tags/sound-5.9-rc1 > > > > > > The topmost commit is c7fabbc51352f50cc58242a6dc3b9c1a3599849b > > > > > > > > > > > > sound updates for 5.9 > > > > > > This became wide and scattered updates all over the sound tree as > > > diffstat shows: lots of (still ongoing) refactoring works in ASoC, > > > fixes and cleanups caught by static analysis, inclusive term > > > conversions as well as lots of new drivers. Below are highlights: > > > > > > ASoC core: > > > * API cleanups and conversions to the unified mute_stream() call > > > * Simplify I/O helper functions > > > * Use helper macros to retrieve RTD from substreams > > ... > > > Kuninori Morimoto (90): > > > ASoC: soc-component: add soc_component_pin() and share code > > > ASoC: soc-component: move snd_soc_component_xxx_regmap() to > > > soc-component > > > ASoC: soc-component: move snd_soc_component_initialize() to > > > soc-component.c > > > ASoC: soc-component: add soc_component_err() > > > ASoC: soc-component: add snd_soc_pcm_component_prepare() > > > ASoC: soc-component: add snd_soc_pcm_component_hw_params() > > > ASoC: soc-component: add snd_soc_pcm_component_hw_free() > > > ASoC: soc-component: add snd_soc_pcm_component_trigger() > > > ASoC: soc-component: add snd_soc_component_init() > > > ASoC: soc-component: merge soc-io.c into soc-component.c > > > > So oddly, today I bisected down the change "ASoC: soc-component: merge > > soc-io.c into soc-component.c": > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=460b42d162e3cf634586999e6a84e74ca52e626d > > > > as causing audio regressions on Dragonboard 845c running AOSP. > > > > On boot I was seeing tons of: > > q6routing remoteproc-adsp:glink-edge:apr:apr-service@8:routing: ASoC: > > error at soc_component_read_no_lock on > > remoteproc-adsp:glink-edge:apr:: -5 > > > > And when audio was supposed to play I'd see: > > [ 227.462986] qcom-q6afe aprsvc:apr-service:4:4: cmd = 0x100e5 > > returned error = 0x9 > > [ 227.470720] qcom-q6afe aprsvc:apr-service:4:4: DSP returned error[9] > > [ 227.477168] qcom-q6afe aprsvc:apr-service:4:4: AFE enable for port > > 0x4000 failed -22 > > [ 227.485038] q6afe-dai > > remoteproc-adsp:glink-edge:apr:apr-service@4:dais: fail to start AFE > > port 2 > > [ 227.494013] q6afe-dai > > remoteproc-adsp:glink-edge:apr:apr-service@4:dais: ASoC: error at > > snd_soc_pcm_dai_prepare on SLIMBUS_0_RX: -22 > > [ 227.506034] SLIM Playback: ASoC: DAI prepare error: -22 > > [ 227.511415] SLIM Playback: ASoC: backend prepare failed -22 > > > > Its strange, as the bisected patch is really just moving code around > > and there's very little in the way of logic changes. After minimizing > > the code movement and just focusing on what changed I forward ported a > > revert to mainline and minimized it until things were working. > > > > The resulting patch is a twoliner here: > > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/db845c-mainline-WIP&id=a3527193f39b1224d59bf1519fce3ef8c57d0f5e > > > > I'm a bit baffled as to why this patch works. Logically we are > > returning the same value. I suspect when we hit the error, all the > > extra error print messages on the console slow things down and end up > > causing some timing related initialization failure? > > Does the patch below fix the bug? If so, it's rather a bug in the > commit cf6e26c71bfd ("ASoC: soc-component: merge > snd_soc_component_read() and snd_soc_component_read32()"). That said, the commit cf6e26c71bfd dropped the capability of returning an error code from snd_soc_component_read() completely, while many code still expect an error gets returned. The assumption mentioned in the patch (the error can be ignored) looks too naive. Morimoto-san, Mark, could you address it? IMO, we may still need two variants in the end again: the former snd_soc_component_read32() that returns the value directly and snd_soc_component_read() that returns 0 or an error. Only once after we deal with the error handling in each caller side, we can unify the read functions. Takashi > > thanks, > > Takashi > > --- a/sound/soc/soc-component.c > +++ b/sound/soc/soc-component.c > @@ -406,7 +406,7 @@ static unsigned int soc_component_read_no_lock( > ret = -EIO; > > if (ret < 0) > - soc_component_ret(component, ret); > + return soc_component_ret(component, ret); > > return val; > }
Re: [GIT PULL] sound updates for 5.9
On Sat, 08 Aug 2020 02:23:24 +0200, John Stultz wrote: > > On Thu, Aug 6, 2020 at 3:33 AM Takashi Iwai wrote: > > > > Linus, > > > > please pull sound updates for v5.9 from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > > tags/sound-5.9-rc1 > > > > The topmost commit is c7fabbc51352f50cc58242a6dc3b9c1a3599849b > > > > > > > > sound updates for 5.9 > > > > This became wide and scattered updates all over the sound tree as > > diffstat shows: lots of (still ongoing) refactoring works in ASoC, > > fixes and cleanups caught by static analysis, inclusive term > > conversions as well as lots of new drivers. Below are highlights: > > > > ASoC core: > > * API cleanups and conversions to the unified mute_stream() call > > * Simplify I/O helper functions > > * Use helper macros to retrieve RTD from substreams > ... > > Kuninori Morimoto (90): > > ASoC: soc-component: add soc_component_pin() and share code > > ASoC: soc-component: move snd_soc_component_xxx_regmap() to > > soc-component > > ASoC: soc-component: move snd_soc_component_initialize() to > > soc-component.c > > ASoC: soc-component: add soc_component_err() > > ASoC: soc-component: add snd_soc_pcm_component_prepare() > > ASoC: soc-component: add snd_soc_pcm_component_hw_params() > > ASoC: soc-component: add snd_soc_pcm_component_hw_free() > > ASoC: soc-component: add snd_soc_pcm_component_trigger() > > ASoC: soc-component: add snd_soc_component_init() > > ASoC: soc-component: merge soc-io.c into soc-component.c > > So oddly, today I bisected down the change "ASoC: soc-component: merge > soc-io.c into soc-component.c": > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=460b42d162e3cf634586999e6a84e74ca52e626d > > as causing audio regressions on Dragonboard 845c running AOSP. > > On boot I was seeing tons of: > q6routing remoteproc-adsp:glink-edge:apr:apr-service@8:routing: ASoC: > error at soc_component_read_no_lock on > remoteproc-adsp:glink-edge:apr:: -5 > > And when audio was supposed to play I'd see: > [ 227.462986] qcom-q6afe aprsvc:apr-service:4:4: cmd = 0x100e5 > returned error = 0x9 > [ 227.470720] qcom-q6afe aprsvc:apr-service:4:4: DSP returned error[9] > [ 227.477168] qcom-q6afe aprsvc:apr-service:4:4: AFE enable for port > 0x4000 failed -22 > [ 227.485038] q6afe-dai > remoteproc-adsp:glink-edge:apr:apr-service@4:dais: fail to start AFE > port 2 > [ 227.494013] q6afe-dai > remoteproc-adsp:glink-edge:apr:apr-service@4:dais: ASoC: error at > snd_soc_pcm_dai_prepare on SLIMBUS_0_RX: -22 > [ 227.506034] SLIM Playback: ASoC: DAI prepare error: -22 > [ 227.511415] SLIM Playback: ASoC: backend prepare failed -22 > > Its strange, as the bisected patch is really just moving code around > and there's very little in the way of logic changes. After minimizing > the code movement and just focusing on what changed I forward ported a > revert to mainline and minimized it until things were working. > > The resulting patch is a twoliner here: > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/db845c-mainline-WIP&id=a3527193f39b1224d59bf1519fce3ef8c57d0f5e > > I'm a bit baffled as to why this patch works. Logically we are > returning the same value. I suspect when we hit the error, all the > extra error print messages on the console slow things down and end up > causing some timing related initialization failure? Does the patch below fix the bug? If so, it's rather a bug in the commit cf6e26c71bfd ("ASoC: soc-component: merge snd_soc_component_read() and snd_soc_component_read32()"). thanks, Takashi --- a/sound/soc/soc-component.c +++ b/sound/soc/soc-component.c @@ -406,7 +406,7 @@ static unsigned int soc_component_read_no_lock( ret = -EIO; if (ret < 0) - soc_component_ret(component, ret); + return soc_component_ret(component, ret); return val; }
Re: [GIT PULL] sound updates for 5.9
On Thu, Aug 6, 2020 at 3:33 AM Takashi Iwai wrote: > > Linus, > > please pull sound updates for v5.9 from: > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > tags/sound-5.9-rc1 > > The topmost commit is c7fabbc51352f50cc58242a6dc3b9c1a3599849b > > > > sound updates for 5.9 > > This became wide and scattered updates all over the sound tree as > diffstat shows: lots of (still ongoing) refactoring works in ASoC, > fixes and cleanups caught by static analysis, inclusive term > conversions as well as lots of new drivers. Below are highlights: > > ASoC core: > * API cleanups and conversions to the unified mute_stream() call > * Simplify I/O helper functions > * Use helper macros to retrieve RTD from substreams ... > Kuninori Morimoto (90): > ASoC: soc-component: add soc_component_pin() and share code > ASoC: soc-component: move snd_soc_component_xxx_regmap() to > soc-component > ASoC: soc-component: move snd_soc_component_initialize() to > soc-component.c > ASoC: soc-component: add soc_component_err() > ASoC: soc-component: add snd_soc_pcm_component_prepare() > ASoC: soc-component: add snd_soc_pcm_component_hw_params() > ASoC: soc-component: add snd_soc_pcm_component_hw_free() > ASoC: soc-component: add snd_soc_pcm_component_trigger() > ASoC: soc-component: add snd_soc_component_init() > ASoC: soc-component: merge soc-io.c into soc-component.c So oddly, today I bisected down the change "ASoC: soc-component: merge soc-io.c into soc-component.c": https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=460b42d162e3cf634586999e6a84e74ca52e626d as causing audio regressions on Dragonboard 845c running AOSP. On boot I was seeing tons of: q6routing remoteproc-adsp:glink-edge:apr:apr-service@8:routing: ASoC: error at soc_component_read_no_lock on remoteproc-adsp:glink-edge:apr:: -5 And when audio was supposed to play I'd see: [ 227.462986] qcom-q6afe aprsvc:apr-service:4:4: cmd = 0x100e5 returned error = 0x9 [ 227.470720] qcom-q6afe aprsvc:apr-service:4:4: DSP returned error[9] [ 227.477168] qcom-q6afe aprsvc:apr-service:4:4: AFE enable for port 0x4000 failed -22 [ 227.485038] q6afe-dai remoteproc-adsp:glink-edge:apr:apr-service@4:dais: fail to start AFE port 2 [ 227.494013] q6afe-dai remoteproc-adsp:glink-edge:apr:apr-service@4:dais: ASoC: error at snd_soc_pcm_dai_prepare on SLIMBUS_0_RX: -22 [ 227.506034] SLIM Playback: ASoC: DAI prepare error: -22 [ 227.511415] SLIM Playback: ASoC: backend prepare failed -22 Its strange, as the bisected patch is really just moving code around and there's very little in the way of logic changes. After minimizing the code movement and just focusing on what changed I forward ported a revert to mainline and minimized it until things were working. The resulting patch is a twoliner here: https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/db845c-mainline-WIP&id=a3527193f39b1224d59bf1519fce3ef8c57d0f5e I'm a bit baffled as to why this patch works. Logically we are returning the same value. I suspect when we hit the error, all the extra error print messages on the console slow things down and end up causing some timing related initialization failure? Anyway, I wanted to raise the issue in case anyone had ideas what might be going wrong. thanks -john
Re: [GIT PULL] sound updates for 5.9
The pull request you sent on Thu, 06 Aug 2020 12:21:10 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > tags/sound-5.9-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3f9df56480fc8ce492fc9e988d67bdea884ed15c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[GIT PULL] sound updates for 5.9
Linus, please pull sound updates for v5.9 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-5.9-rc1 The topmost commit is c7fabbc51352f50cc58242a6dc3b9c1a3599849b sound updates for 5.9 This became wide and scattered updates all over the sound tree as diffstat shows: lots of (still ongoing) refactoring works in ASoC, fixes and cleanups caught by static analysis, inclusive term conversions as well as lots of new drivers. Below are highlights: ASoC core: * API cleanups and conversions to the unified mute_stream() call * Simplify I/O helper functions * Use helper macros to retrieve RTD from substreams ASoC drivers: * Lots of fixes and cleanups in Intel ASoC drivers * Lots of new stuff: Freescale MQS and i.MX6sx, Intel KeemBay I2S, Maxim MAX98360A and MAX98373 SoundWire, various Mediatek boards, nVidia Tegra 186 and 210, RealTek RL6231, Samsung Midas and Aries boards, TI J721e EVM ALSA core: * Minor code refacotring for SG-buffer handling HD-audio: * Generalization of mute-LED handling with LED classdev * Intel silent stream support for HDMI * Device-specific fixes: CA0132, Loongson-3 Others: * Usual USB- and HD-audio quirks for various devices * Fixes for echoaudio DMA position handling * Various documents and trivial fixes for sparse warnings * Conversion to adapt inclusive terms Akshu Agrawal (3): ASoC: AMD: Use mixer control to switch between DMICs ASoC: amd: Enable interrupt in dma_open ASoC: AMD: Restore PME_EN state at Power On Alexander A. Klimov (5): ALSA: Replace HTTP links with HTTPS ones ASoC: Replace HTTP links with HTTPS ones ASoC: ti: Replace HTTP links with HTTPS ones ASoC: fsl: Replace HTTP links with HTTPS ones ASoC: omap: Replace HTTP links with HTTPS ones Alexander Tsoy (1): ALSA: usb-audio: Fix some typos Alper Nebi Yasak (1): ASoC: rk3399_gru_sound: Add DAPM pins, kcontrols for jack detection Bard Liao (2): ASoC: intel: cml_rt1011_rt5682: use for_each_card_prelinks ASoC: Intel: sof_sdw_rt711: remove hard-coded codec name Brent Lu (1): ASoC: Intel: bxt-da7219-max98357a: support MAX98390 speaker amp Cezary Rojewski (3): ASoC: core: Relocate and expose snd_soc_component_initialize ASoC: core: Simplify snd_soc_component_initialize declaration ASoC: core: Two step component registration Charles Keepax (2): ASoC: madera: Add channel numbers to AIFs ASoC: soc-core: Fix regression causing sysfs entries to disappear Codrin Ciubotariu (2): ASoC: atmel-classd: remove codec component ASoC: atmel-pdmic: remove codec component Colin Ian King (1): ASoC: Intel: bxt-da7219-max98357a: return -EINVAL on unrecognized speaker amplifier Colton Lewis (1): snd/soc: correct trivial kernel-doc inconsistency Connor McAdams (3): ALSA: hda/ca0132 - Fix ZxR Headphone gain control get value. ALSA: hda/ca0132 - Add new quirk ID for Recon3D. ALSA: hda/ca0132 - Fix AE-5 microphone selection commands. Curtis Malainey (1): ALSA: usb-audio: add startech usb audio dock name Dan Carpenter (1): ALSA: echoaudio: re-enable IRQs on failure path Dan Murphy (17): ASoC: tas2562: Update shutdown GPIO property ASoC: tas2562: Fix format issue for extra space before a comma ASoC: tas2562: Fix shut-down gpio property ASoC: tas2562: Add right and left channel slot programming ASoC: tas2562: Add voltage sense slot configuration ASoC: tas2562: Add voltage sense slot property ASoC: tlv320adcx140: Add ASI enable for channel 5-8 ASoC: tlv320adcx140: Add tx offset slot programming ASoC: tas2770: Fix reset gpio property name ASoC: tas2770: Convert tas2770 binding to yaml ASoC: tas2562: Update shutdown GPIO property ASoC: tas2562: Convert the tas2562 binding to yaml ASoC: tlv320adcx140: Fix various style errors and warnings dt-bindings: tlv320adcx140: Add GPO config and drive config ASoC: tlv320adcx140: Add GPO configuration and drive output config ASoC: tlv320adcx140: Fix GPO register start address ASoC: tlv320adcx140: Move device reset to before programming Daniel Baluta (7): ASoC: SOF: define INFO_ flags in dsp_ops for imx8 ASoC: SOF: imx: Use ARRAY_SIZE instead of hardcoded value ASoC: SOF: imx8: Fix ESAI DAI driver name for i.MX8/iMX8X ASoC: SOF: imx8m: Fix SAI DAI driver for i.MX8M ASoC: SOF: imx8: Add SAI dai driver for i.MX/i.MX8X ASoC: SOF: topology: Update SAI config bclk/fsync rate ASoC: SOF: pcm: Update rate/channels for SAI/ESAI DAIs Dharageswari R (3): ASoC: Intel: Boards: tgl_max98373: add dai_trigger function ASoC: Intel: Boards: tgl_max98373: Fix the comment for max_98373_components ASoC: Intel: Boards: tgl_max98373: