linux-stable.git/sound, branch v5.8.2 Linux kernel stable tree ALSA: usb-audio: add quirk for Pioneer DDJ-RB 2020-08-19T06:27:01+00:00 Hector Martin marcan@marcan.st 2020-08-10T08:25:02+00:00 ec0cf56ee03190bda9477fcc7bffdb92b53d988f commit 6e8596172ee1cd46ec0bfd5adcf4ff86371478b6 upstream. This is just another Pioneer device with fixed endpoints. Input is dummy but used as feedback (it always returns silence). Cc: stable@vger.kernel.org Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20200810082502.225979-1-marcan@marcan.st Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6e8596172ee1cd46ec0bfd5adcf4ff86371478b6 upstream.

This is just another Pioneer device with fixed endpoints. Input is dummy
but used as feedback (it always returns silence).

Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>
Link: https://lore.kernel.org/r/20200810082502.225979-1-marcan@marcan.st
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: usb-audio: work around streaming quirk for MacroSilicon MS2109 2020-08-19T06:27:01+00:00 Hector Martin marcan@marcan.st 2020-08-10T08:24:00+00:00 f8b0754bb14193feb7a1868c9cf3ddb20b535b89 commit 1b7ecc241a67ad6b584e071bd791a54e0cd5f097 upstream. Further investigation of the L-R swap problem on the MS2109 reveals that the problem isn't that the channels are swapped, but rather that they are swapped and also out of phase by one sample. In other words, the issue is actually that the very first frame that comes from the hardware is a half-frame containing only the right channel, and after that everything becomes offset. So introduce a new quirk field to drop the very first 2 bytes that come in after the format is configured and a capture stream starts. This puts the channels in phase and in the correct order. Cc: stable@vger.kernel.org Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20200810082400.225858-1-marcan@marcan.st Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1b7ecc241a67ad6b584e071bd791a54e0cd5f097 upstream.

Further investigation of the L-R swap problem on the MS2109 reveals that
the problem isn't that the channels are swapped, but rather that they
are swapped and also out of phase by one sample. In other words, the
issue is actually that the very first frame that comes from the hardware
is a half-frame containing only the right channel, and after that
everything becomes offset.

So introduce a new quirk field to drop the very first 2 bytes that come
in after the format is configured and a capture stream starts. This puts
the channels in phase and in the correct order.

Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>
Link: https://lore.kernel.org/r/20200810082400.225858-1-marcan@marcan.st
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: usb-audio: fix overeager device match for MacroSilicon MS2109 2020-08-19T06:27:01+00:00 Hector Martin marcan@marcan.st 2020-08-10T04:53:19+00:00 184f08d3789fea141018daed2c293ead37e2f805 commit 14a720dc1f5332f3bdf30a23a3bc549e81be974c upstream. Matching by device matches all interfaces, which breaks the video/HID portions of the device depending on module load order. Fixes: e337bf19f6af ("ALSA: usb-audio: add quirk for MacroSilicon MS2109") Cc: stable@vger.kernel.org Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20200810045319.128745-1-marcan@marcan.st Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 14a720dc1f5332f3bdf30a23a3bc549e81be974c upstream.

Matching by device matches all interfaces, which breaks the video/HID
portions of the device depending on module load order.

Fixes: e337bf19f6af ("ALSA: usb-audio: add quirk for MacroSilicon MS2109")
Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>
Link: https://lore.kernel.org/r/20200810045319.128745-1-marcan@marcan.st
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: usb-audio: Creative USB X-Fi Pro SB1095 volume knob support 2020-08-19T06:27:01+00:00 Mirko Dietrich buzz@l4m1.de 2020-08-06T12:48:50+00:00 2b4d81f58d9daa0333c0e1198bffb8e73ee0d59a commit fec9008828cde0076aae595ac031bfcf49d335a4 upstream. Adds an entry for Creative USB X-Fi to the rc_config array in mixer_quirks.c to allow use of volume knob on the device. Adds support for newer X-Fi Pro card, known as "Model No. SB1095" with USB ID "041e:3263" Signed-off-by: Mirko Dietrich <buzz@l4m1.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200806124850.20334-1-buzz@l4m1.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fec9008828cde0076aae595ac031bfcf49d335a4 upstream.

Adds an entry for Creative USB X-Fi to the rc_config array in
mixer_quirks.c to allow use of volume knob on the device.
Adds support for newer X-Fi Pro card, known as "Model No. SB1095"
with USB ID "041e:3263"

Signed-off-by: Mirko Dietrich <buzz@l4m1.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200806124850.20334-1-buzz@l4m1.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - reverse the setting value in the micmute_led_set 2020-08-19T06:27:01+00:00 Hui Wang hui.wang@canonical.com 2020-08-11T12:24:30+00:00 9af94db4d1b7c83ad8f5a1ef5c10e47872af25b5 commit 404690649e6a52ee39817168f2d984726412e091 upstream. Before the micmute_led_set() is introduced, the function of alc_gpio_micmute_update() will set the gpio value with the !micmute_led.led_value, and the machines have the correct micmute led status. After the micmute_led_set() is introduced, it sets the gpio value with !!micmute_led.led_value, so the led status is not correct anymore, we need to set micmute_led_polarity = 1 to workaround it. Now we fix the micmute_led_set() and remove micmute_led_polarity = 1. Fixes: 87dc36482cab ("ALSA: hda/realtek - Add LED class support for micmute LED") Reported-and-suggested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20200811122430.6546-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 404690649e6a52ee39817168f2d984726412e091 upstream.

Before the micmute_led_set() is introduced, the function of
alc_gpio_micmute_update() will set the gpio value with the
!micmute_led.led_value, and the machines have the correct micmute led
status. After the micmute_led_set() is introduced, it sets the gpio
value with !!micmute_led.led_value, so the led status is not correct
anymore, we need to set micmute_led_polarity = 1 to workaround it.

Now we fix the micmute_led_set() and remove micmute_led_polarity = 1.

Fixes: 87dc36482cab ("ALSA: hda/realtek - Add LED class support for micmute LED")
Reported-and-suggested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20200811122430.6546-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - fix the micmute led status for Lenovo ThinkCentre AIO 2020-08-19T06:27:01+00:00 Hui Wang hui.wang@canonical.com 2020-08-10T02:16:59+00:00 d81a84e7bba0a42b6205f7a4a592f4214c86bb48 commit 386a6539992b82fe9ac4f9dc3f548956fd894d8c upstream. After installing the Ubuntu Linux, the micmute led status is not correct. Users expect that the led is on if the capture is disabled, but with the current kernel, the led is off with the capture disabled. We tried the old linux kernel like linux-4.15, there is no this issue. It looks like we introduced this issue when switching to the led_cdev. Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20200810021659.7429-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 386a6539992b82fe9ac4f9dc3f548956fd894d8c upstream.

After installing the Ubuntu Linux, the micmute led status is not
correct. Users expect that the led is on if the capture is disabled,
but with the current kernel, the led is off with the capture disabled.

We tried the old linux kernel like linux-4.15, there is no this issue.
It looks like we introduced this issue when switching to the led_cdev.

Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20200810021659.7429-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ASoC: fsl_sai: Fix value of FSL_SAI_CR1_RFW_MASK 2020-08-19T06:26:51+00:00 Shengjiu Wang shengjiu.wang@nxp.com 2020-07-31T06:28:15+00:00 ee9f0d33c0243071047bb65ca615b92fa4ca7461 [ Upstream commit 5aef1ff2397d021f93d874b57dff032fdfac73de ] The fifo_depth is 64 on i.MX8QM/i.MX8QXP, 128 on i.MX8MQ, 16 on i.MX7ULP. Original FSL_SAI_CR1_RFW_MASK value 0x1F is not suitable for these platform, the FIFO watermark mask should be updated according to the fifo_depth. Fixes: a860fac42097 ("ASoC: fsl_sai: Add support for imx7ulp/imx8mq") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/1596176895-28724-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5aef1ff2397d021f93d874b57dff032fdfac73de ]

The fifo_depth is 64 on i.MX8QM/i.MX8QXP, 128 on i.MX8MQ, 16 on
i.MX7ULP.

Original FSL_SAI_CR1_RFW_MASK value 0x1F is not suitable for
these platform, the FIFO watermark mask should be updated
according to the fifo_depth.

Fixes: a860fac42097 ("ASoC: fsl_sai: Add support for imx7ulp/imx8mq")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/1596176895-28724-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: meson: cards: deal dpcm flag change 2020-08-19T06:26:51+00:00 Jerome Brunet jbrunet@baylibre.com 2020-07-31T12:06:03+00:00 3d26a53f004d00c0d8220990d387b544bcf281fc [ Upstream commit da3f23fde9d7b4a7e0ca9a9a096cec3104df1b82 ] Commit b73287f0b074 ("ASoC: soc-pcm: dpcm: fix playback/capture checks") changed the meaning of dpcm_playback/dpcm_capture and now requires the CPU DAI BE to aligned with those flags. This broke all Amlogic cards with uni-directional backends (All gx and most axg cards). While I'm still confused as to how this change is an improvement, those cards can't remain broken forever. Hopefully, next time an API change is done like that, all the users will be updated as part of the change, and not left to fend for themselves. Fixes: b73287f0b074 ("ASoC: soc-pcm: dpcm: fix playback/capture checks") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200731120603.2243261-1-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit da3f23fde9d7b4a7e0ca9a9a096cec3104df1b82 ]

Commit b73287f0b074 ("ASoC: soc-pcm: dpcm: fix playback/capture checks")
changed the meaning of dpcm_playback/dpcm_capture and now requires the
CPU DAI BE to aligned with those flags.

This broke all Amlogic cards with uni-directional backends (All gx and
most axg cards).

While I'm still confused as to how this change is an improvement, those
cards can't remain broken forever. Hopefully, next time an API change is
done like that, all the users will be updated as part of the change, and
not left to fend for themselves.

Fixes: b73287f0b074 ("ASoC: soc-pcm: dpcm: fix playback/capture checks")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200731120603.2243261-1-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: core: use less strict tests for dailink capabilities 2020-08-19T06:26:51+00:00 Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com 2020-07-23T18:05:33+00:00 224e149995885a4a47fdfa96a7db1485bd33120b [ Upstream commit 4f8721542f7b75954bfad98c51aa59d683d35b50 ] Previous updates to set dailink capabilities and check dailink capabilities were based on a flawed assumption that all dais support the same capabilities as the dailink. This is true for TDM configurations but existing configurations use an amplifier and a capture device on the same dailink, and the tests would prevent the card from probing. This patch modifies the snd_soc_dai_link_set_capabilities() helper so that the dpcm_playback (resp. dpcm_capture) dailink capabilities are set if at least one dai supports playback (resp. capture). Likewise the checks are modified so that an error is reported only when dpcm_playback (resp. dpcm_capture) is set but none of the CPU DAIs support playback (resp. capture). Fixes: 25612477d20b5 ('ASoC: soc-dai: set dai_link dpcm_ flags with a helper') Fixes: b73287f0b0745 ('ASoC: soc-pcm: dpcm: fix playback/capture checks') Suggested-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200723180533.220312-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4f8721542f7b75954bfad98c51aa59d683d35b50 ]

Previous updates to set dailink capabilities and check dailink
capabilities were based on a flawed assumption that all dais support
the same capabilities as the dailink. This is true for TDM
configurations but existing configurations use an amplifier and a
capture device on the same dailink, and the tests would prevent the
card from probing.

This patch modifies the snd_soc_dai_link_set_capabilities()
helper so that the dpcm_playback (resp. dpcm_capture) dailink
capabilities are set if at least one dai supports playback (resp. capture).

Likewise the checks are modified so that an error is reported only
when dpcm_playback (resp. dpcm_capture) is set but none of the CPU
DAIs support playback (resp. capture).

Fixes: 25612477d20b5 ('ASoC: soc-dai: set dai_link dpcm_ flags with a helper')
Fixes: b73287f0b0745 ('ASoC: soc-pcm: dpcm: fix playback/capture checks')
Suggested-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200723180533.220312-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: soc-core: Fix regression causing sysfs entries to disappear 2020-08-19T06:26:50+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2020-07-30T12:07:14+00:00 7a4c9d17c8bc33eaff046adc1baeda79a8cafede [ Upstream commit 5c74c9d34aec1ac756de6979dd5580096aba8643 ] The allocation order of things in soc_new_pcm_runtime was changed to move the device_register before the allocation of the rtd structure. This was to allow the rtd allocation to be managed by devm. However currently the sysfs entries are added by device_register and their visibility depends on variables within the rtd structure, this causes the pmdown_time and dapm_widgets sysfs entries to be missing for all rtds. Correct this issue by manually calling device_add_groups after the appropriate information is available. Fixes: d918a37610b1 ("ASoC: soc-core: tidyup soc_new_pcm_runtime() alloc order") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200730120715.637-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5c74c9d34aec1ac756de6979dd5580096aba8643 ]

The allocation order of things in soc_new_pcm_runtime was changed to
move the device_register before the allocation of the rtd structure.
This was to allow the rtd allocation to be managed by devm. However
currently the sysfs entries are added by device_register and their
visibility depends on variables within the rtd structure, this causes
the pmdown_time and dapm_widgets sysfs entries to be missing for all
rtds.

Correct this issue by manually calling device_add_groups after the
appropriate information is available.

Fixes: d918a37610b1 ("ASoC: soc-core: tidyup soc_new_pcm_runtime() alloc order")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200730120715.637-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>