The audio output may become abnormal after a warm reboot from Windows. Reset the codec once during hardware initialization to restore it to a known state and prevent the issue. BugLink: https://github.com/thesofproject/linux/issues/5845 Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://patch.msgid.link/20260728090111.3676617-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
The SINEGAIN2_REG case in cali_reg_update() references t->sin_gn[]
rather than t->sin_gn2[], causing the second pilot tone gain
calibration to be programmed with the wrong register address.
These are distinct fields in struct fct_param_address and are
populated from separate firmware parameters by the parser in
tas2781-fmwlib.c.
Fixes: 84d6a465f211 ("ASoC: tas2781: Support dsp firmware Alpha and Beta seaies")
Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260720081616.631413-1-wangdich9700@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In max98090_probe(), the -EPROBE_DEFER check after devm_clk_get() is
broken due to a missing IS_ERR() guard.
The code intends to return -EPROBE_DEFER only when the clock lookup
fails with that specific error. However, without IS_ERR() the check:
if (PTR_ERR(max98090->mclk) == -EPROBE_DEFER)
is called unconditionally, including when devm_clk_get() succeeds and
returns a valid pointer. Calling PTR_ERR() on a valid pointer
reinterprets its address as a signed long; the result is arbitrary
and is almost never equal to -EPROBE_DEFER, so the check silently
does nothing in the success case. When devm_clk_get() fails with
any error other than -EPROBE_DEFER the check is also skipped, leaving
max98090->mclk holding an error pointer with no indication to the caller.
This means a deferred probe will never actually be triggered for this
device, and any non-EPROBE_DEFER clock error is silently swallowed with
the error pointer left in the mclk field.
Fix this by adding the missing IS_ERR() guard around the PTR_ERR() call,
matching the pattern already used in the sibling max98088 and wm8960
drivers.
Fixes: b10ab7b838bd ("ASoC: max98090: Add master clock handling")
Signed-off-by: Uday Khare <udaykhare77@gmail.com>
Link: https://patch.msgid.link/20260720104254.14948-1-udaykhare77@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In max98095_probe(), the -EPROBE_DEFER check after devm_clk_get() is
broken due to a missing IS_ERR() guard.
The code intends to return -EPROBE_DEFER only when the clock lookup
fails with that specific error. However, without IS_ERR() the check:
if (PTR_ERR(max98095->mclk) == -EPROBE_DEFER)
is called unconditionally, including when devm_clk_get() succeeds and
returns a valid pointer. Calling PTR_ERR() on a valid pointer
reinterprets its address as a signed long; the result is arbitrary
and is almost never equal to -EPROBE_DEFER, so the check silently
does nothing in the success case. When devm_clk_get() fails with
any error other than -EPROBE_DEFER the check is also skipped, leaving
max98095->mclk holding an error pointer with no indication to the caller.
This means a deferred probe will never actually be triggered for this
device, and any non-EPROBE_DEFER clock error is silently swallowed with
the error pointer left in the mclk field.
Fix this by adding the missing IS_ERR() guard around the PTR_ERR() call,
matching the pattern already used in the sibling max98088 and wm8960
drivers.
Fixes: e3048c3d2be5 ("ASoC: max98095: Add master clock handling")
Signed-off-by: Uday Khare <udaykhare77@gmail.com>
Link: https://patch.msgid.link/20260720103950.14474-1-udaykhare77@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown <broonie@kernel.org> says: While reviewing another fix for the tas2562 volume control I noticed a few issues with the put() operation, this series fixes them. It's also a bit weird that the volume control is defined with twice as many values as can actually be set, probably the best fix there is to regnerate the table of volume values with the intermediate values. Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-0-97bf467c924e@kernel.org
The tas2562 digital volume is spread over four registers and is implemented as lookups into a table so the driver stores the value for the userspace control in the driver data. This defaults to 0 due to kzalloc() but the register default is 0x40400000 which maps onto something a bit over the largest value defined in the lookup table. While it's not an exact match update the default to the largest value, avoiding user surprise due to a sudden change on first write. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-3-97bf467c924e@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA put() operations should return 0 for noop updates and 1 if the value of the control changed, this is used by the ALSA core to generate events to userspace. tas2562_volume_control_put() does not implement this, it just writes whatever value userspace wrote to the device and returns 0 regardless of what the previous value was. Fix this by suppressing writes if the value is unchanged and returning 1 if the writes succeed. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-2-97bf467c924e@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device. Add validation that we are loading a value we have in the array. Cc: stable@vger.kernel.org Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-1-97bf467c924e@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Haidar Lee <haidar.lee@adlinktech.com> says: The 'Digital Volume Control' added in v5.7 has never worked correctly: the driver writes the 32-bit DVC coefficient LSB first, but the device latches the whole coefficient on the write to the last byte (DVC_CFG4), so every volume change applies a mix of the previous coefficient's upper bytes and the new LSB. Depending on the sequence of values this mutes the output entirely or plays at full volume regardless of the requested level. Debugged on a TAS2562 (ADLINK OSM-520 / MT8189): traced the I2C writes with ftrace to confirm the driver writes the intended bytes, then reproduced both behaviours by writing the same coefficients manually in each byte order. Patch 1 fixes the write order; patch 2 fixes two wrong entries in the volume lookup table found while debugging this. Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-0-072b13901b20@adlinktech.com
The float_vol_db_lookup table is supposed to hold
round(10^(dB/20) * 2^30) for every 2 dB step from -110 dB to 0 dB,
which is 56 entries, but it only has 55: the -90 dB entry duplicates
the -92 dB value (0x0000695b) and the -20 dB entry (0x06666666) is
missing altogether. As a result every step between -90 dB and -22 dB
is off by 2 dB, and the control's maximum raw value of 110 indexes one
element past the end of the array.
Replace the duplicated -90 dB entry with the correct value 0x000084a3
and add the missing -20 dB entry, bringing the table to the full 56
entries so index 55 (raw value 110, 0 dB) is in range again.
Fixes: bf726b1c86f2 ("ASoC: tas2562: Add support for digital volume control")
Cc: stable@vger.kernel.org
Signed-off-by: Haidar Lee <haidar.lee@adlinktech.com>
Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-2-072b13901b20@adlinktech.com
Signed-off-by: Mark Brown <broonie@kernel.org>