kernel/git/stable/linux.git/sound/soc/codecs, branch linux-4.4.y

ASoC: sti-sas: add missing MODULE_DEVICE_TABLE

2021-06-16T09:34:51+00:00

[ Upstream commit e072b2671606c77538d6a4dd5dda80b508cb4816 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Zou Wei Link: https://lore.kernel.org/r/1620789145-14936-1-git-send-email-zou_wei@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: rt286: Make RT286_SET_GPIO_* readable and writable

2021-05-22T08:38:28+00:00

[ Upstream commit cd8499d5c03ba260e3191e90236d0e5f6b147563 ] The GPIO configuration cannot be applied if the registers are inaccessible. This prevented the headset mic from working on the Dell XPS 13 9343. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=114171 Signed-off-by: David Ward Link: https://lore.kernel.org/r/20210418134658.4333-5-david.ward@gatech.edu Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: rt286: Generalize support for ALC3263 codec

2021-05-22T08:38:27+00:00

[ Upstream commit aa2f9c12821e6a4ba1df4fb34a3dbc6a2a1ee7fe ] The ALC3263 codec on the XPS 13 9343 is also found on the Latitude 13 7350 and Venue 11 Pro 7140. They require the same handling for the combo jack to work with a headset: GPIO pin 6 must be set. The HDA driver always sets this pin on the ALC3263, which it distinguishes by the codec vendor/device ID 0x10ec0288 and PCI subsystem vendor ID 0x1028 (Dell). The ASoC driver does not use PCI, so adapt this check to use DMI to determine if Dell is the system vendor. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=150601 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205961 Signed-off-by: David Ward Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210418134658.4333-6-david.ward@gatech.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: sgtl5000: set DAP_AVC_CTRL register to correct default value on probe

2021-04-07T10:04:20+00:00

[ Upstream commit f86f58e3594fb0ab1993d833d3b9a2496f3c928c ] According to the SGTL5000 datasheet [1], the DAP_AVC_CTRL register has the following bit field definitions: | BITS | FIELD | RW | RESET | DEFINITION | | 15 | RSVD | RO | 0x0 | Reserved | | 14 | RSVD | RW | 0x1 | Reserved | | 13:12 | MAX_GAIN | RW | 0x1 | Max Gain of AVC in expander mode | | 11:10 | RSVD | RO | 0x0 | Reserved | | 9:8 | LBI_RESP | RW | 0x1 | Integrator Response | | 7:6 | RSVD | RO | 0x0 | Reserved | | 5 | HARD_LMT_EN | RW | 0x0 | Enable hard limiter mode | | 4:1 | RSVD | RO | 0x0 | Reserved | | 0 | EN | RW | 0x0 | Enable/Disable AVC | The original default value written to the DAP_AVC_CTRL register during sgtl5000_i2c_probe() was 0x0510. This would incorrectly write values to bits 4 and 10, which are defined as RESERVED. It would also not set bits 12 and 14 to their correct RESET values of 0x1, and instead set them to 0x0. While the DAP_AVC module is effectively disabled because the EN bit is 0, this default value is still writing invalid values to registers that are marked as read-only and RESERVED as well as not setting bits 12 and 14 to their correct default values as defined by the datasheet. The correct value that should be written to the DAP_AVC_CTRL register is 0x5100, which configures the register bits to the default values defined by the datasheet, and prevents any writes to bits defined as 'read-only'. Generally speaking, it is best practice to NOT attempt to write values to registers/bits defined as RESERVED, as it generally produces unwanted/undefined behavior, or errors. Also, all credit for this patch should go to my colleague Dan MacDonald for finding this error in the first place. [1] https://www.nxp.com/docs/en/data-sheet/SGTL5000.pdf Signed-off-by: Benjamin Rood Reviewed-by: Fabio Estevam Link: https://lore.kernel.org/r/20210219183308.GA2117@ubuntu-dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: rt5651: Fix dac- and adc- vol-tlv values being off by a factor of 10

2021-04-07T10:04:20+00:00

[ Upstream commit eee51df776bd6cac10a76b2779a9fdee3f622b2b ] The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale. E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer. Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize. Note this mirrors commit 3f31f7d9b540 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210226143817.84287-3-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: rt5640: Fix dac- and adc- vol-tlv values being off by a factor of 10

2021-04-07T10:04:20+00:00

[ Upstream commit cfa26ed1f9f885c2fd8f53ca492989d1e16d0199 ] The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale. E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer. Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize. Note this mirrors commit 3f31f7d9b540 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210226143817.84287-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: cs42l56: fix up error handling in probe

2021-03-03T15:44:17+00:00

[ Upstream commit 856fe64da84c95a1d415564b981ae3908eea2a76 ] There are two issues with this code. The first error path forgot to set the error code and instead returns success. The second error path doesn't clean up. Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/X9NE/9nK9/TuxuL+@mwanda Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: wm_adsp: remove "ctl" from list on error in wm_adsp_create_control()

2020-12-29T12:42:40+00:00

[ Upstream commit 85a7555575a0e48f9b73db310d0d762a08a46d63 ] The error handling frees "ctl" but it's still on the "dsp->ctl_list" list so that could result in a use after free. Remove it from the list before returning. Fixes: 2323736dca72 ("ASoC: wm_adsp: Add basic support for rev 1 firmware file format") Signed-off-by: Dan Carpenter Acked-by: Charles Keepax Link: https://lore.kernel.org/r/X9B0keV/02wrx9Xs@mwanda Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: rt5670: Correct RT5670_LDO_SEL_MASK

2020-07-31T14:43:12+00:00

commit 5cacc6f5764e94fa753b2c1f5f7f1f3f74286e82 upstream. The RT5670_PWR_ANLG1 register has 3 bits to select the LDO voltage, so the correct mask is 0x7 not 0x3. Because of this wrong mask we were programming the ldo bits to a setting of binary 001 (0x05 & 0x03) instead of binary 101 when moving to SND_SOC_BIAS_PREPARE. According to the datasheet 001 is a reserved value, so no idea what it did, since the driver was working fine before I guess we got lucky and it does something which is ok. Fixes: 5e8351de740d ("ASoC: add RT5670 CODEC driver") Signed-off-by: Hans de Goede Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200628155231.71089-3-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: wm8960: Fix WM8960_SYSCLK_PLL mode

2020-05-05T17:13:25+00:00

commit 6bb7451429084cefcb3a18fff809f7992595d2af upstream. With the introduction of WM8960_SYSCLK_AUTO mode, WM8960_SYSCLK_PLL mode was made unusable. Ensure we're not PLL mode before trying to use MCLK. Fixes: 3176bf2d7ccd ("ASoC: wm8960: update pll and clock setting function") Signed-off-by: Stuart Henderson Reviewed-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman