--- /dev/null
+From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001
+From: Arun Raghavan <arun@asymptotic.io>
+Date: Thu, 26 Jun 2025 09:08:25 -0400
+Subject: ASoC: fsl_sai: Force a software reset when starting in consumer mode
+
+From: Arun Raghavan <arun@asymptotic.io>
+
+commit dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 upstream.
+
+On an imx8mm platform with an external clock provider, when running the
+receiver (arecord) and triggering an xrun with xrun_injection, we see a
+channel swap/offset. This happens sometimes when running only the
+receiver, but occurs reliably if a transmitter (aplay) is also
+concurrently running.
+
+It seems that the SAI loses track of frame sync during the trigger stop
+-> trigger start cycle that occurs during an xrun. Doing just a FIFO
+reset in this case does not suffice, and only a software reset seems to
+get it back on track.
+
+This looks like the same h/w bug that is already handled for the
+producer case, so we now do the reset unconditionally on config disable.
+
+Signed-off-by: Arun Raghavan <arun@asymptotic.io>
+Reported-by: Pieterjan Camerlynck <p.camerlynck@televic.com>
+Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode")
+Cc: stable@vger.kernel.org
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/fsl/fsl_sai.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/sound/soc/fsl/fsl_sai.c
++++ b/sound/soc/fsl/fsl_sai.c
+@@ -762,13 +762,15 @@ static void fsl_sai_config_disable(struc
+ * anymore. Add software reset to fix this issue.
+ * This is a hardware bug, and will be fix in the
+ * next sai version.
++ *
++ * In consumer mode, this can happen even after a
++ * single open/close, especially if both tx and rx
++ * are running concurrently.
+ */
+- if (!sai->is_consumer_mode) {
+- /* Software Reset */
+- regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR);
+- /* Clear SR bit to finish the reset */
+- regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0);
+- }
++ /* Software Reset */
++ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR);
++ /* Clear SR bit to finish the reset */
++ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0);
+ }
+
+ static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
--- /dev/null
+From b6ef830c60b6f4adfb72d0780b4363df3a1feb9c Mon Sep 17 00:00:00 2001
+From: Jayesh Choudhary <j-choudhary@ti.com>
+Date: Tue, 18 Mar 2025 16:06:22 +0530
+Subject: i2c: omap: Add support for setting mux
+
+From: Jayesh Choudhary <j-choudhary@ti.com>
+
+commit b6ef830c60b6f4adfb72d0780b4363df3a1feb9c upstream.
+
+Some SoCs require muxes in the routing for SDA and SCL lines.
+Therefore, add support for setting the mux by reading the mux-states
+property from the dt-node.
+
+Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
+Link: https://lore.kernel.org/r/20250318103622.29979-3-j-choudhary@ti.com
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Stable-dep-of: a9503a2ecd95 ("i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/Kconfig | 1 +
+ drivers/i2c/busses/i2c-omap.c | 22 ++++++++++++++++++++++
+ 2 files changed, 23 insertions(+)
+
+--- a/drivers/i2c/busses/Kconfig
++++ b/drivers/i2c/busses/Kconfig
+@@ -899,6 +899,7 @@ config I2C_OMAP
+ tristate "OMAP I2C adapter"
+ depends on ARCH_OMAP || ARCH_K3 || COMPILE_TEST
+ default MACH_OMAP_OSK
++ select MULTIPLEXER
+ help
+ If you say yes to this option, support will be included for the
+ I2C interface on the Texas Instruments OMAP1/2 family of processors.
+--- a/drivers/i2c/busses/i2c-omap.c
++++ b/drivers/i2c/busses/i2c-omap.c
+@@ -24,6 +24,7 @@
+ #include <linux/platform_device.h>
+ #include <linux/clk.h>
+ #include <linux/io.h>
++#include <linux/mux/consumer.h>
+ #include <linux/of.h>
+ #include <linux/of_device.h>
+ #include <linux/slab.h>
+@@ -211,6 +212,7 @@ struct omap_i2c_dev {
+ u16 syscstate;
+ u16 westate;
+ u16 errata;
++ struct mux_state *mux_state;
+ };
+
+ static const u8 reg_map_ip_v1[] = {
+@@ -1455,6 +1457,23 @@ omap_i2c_probe(struct platform_device *p
+ (1000 * omap->speed / 8);
+ }
+
++ if (of_property_read_bool(node, "mux-states")) {
++ struct mux_state *mux_state;
++
++ mux_state = devm_mux_state_get(&pdev->dev, NULL);
++ if (IS_ERR(mux_state)) {
++ r = PTR_ERR(mux_state);
++ dev_dbg(&pdev->dev, "failed to get I2C mux: %d\n", r);
++ goto err_disable_pm;
++ }
++ omap->mux_state = mux_state;
++ r = mux_state_select(omap->mux_state);
++ if (r) {
++ dev_err(&pdev->dev, "failed to select I2C mux: %d\n", r);
++ goto err_disable_pm;
++ }
++ }
++
+ /* reset ASAP, clearing any IRQs */
+ omap_i2c_init(omap);
+
+@@ -1514,6 +1533,9 @@ static void omap_i2c_remove(struct platf
+
+ i2c_del_adapter(&omap->adapter);
+
++ if (omap->mux_state)
++ mux_state_deselect(omap->mux_state);
++
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret < 0)
+ dev_err(omap->dev, "Failed to resume hardware, skip disable\n");
--- /dev/null
+From 666c23af755dccca8c25b5d5200ca28153c69a05 Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sat, 14 Jun 2025 16:59:26 +0200
+Subject: i2c: omap: Fix an error handling path in omap_i2c_probe()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 666c23af755dccca8c25b5d5200ca28153c69a05 upstream.
+
+If an error occurs after calling mux_state_select(), mux_state_deselect()
+should be called as already done in the remove function.
+
+Fixes: b6ef830c60b6 ("i2c: omap: Add support for setting mux")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Cc: <stable@vger.kernel.org> # v6.15+
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/998542981b6d2435c057dd8b9fe71743927babab.1749913149.git.christophe.jaillet@wanadoo.fr
+Stable-dep-of: a9503a2ecd95 ("i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-omap.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-omap.c
++++ b/drivers/i2c/busses/i2c-omap.c
+@@ -1464,13 +1464,13 @@ omap_i2c_probe(struct platform_device *p
+ if (IS_ERR(mux_state)) {
+ r = PTR_ERR(mux_state);
+ dev_dbg(&pdev->dev, "failed to get I2C mux: %d\n", r);
+- goto err_disable_pm;
++ goto err_put_pm;
+ }
+ omap->mux_state = mux_state;
+ r = mux_state_select(omap->mux_state);
+ if (r) {
+ dev_err(&pdev->dev, "failed to select I2C mux: %d\n", r);
+- goto err_disable_pm;
++ goto err_put_pm;
+ }
+ }
+
+@@ -1518,6 +1518,9 @@ omap_i2c_probe(struct platform_device *p
+
+ err_unuse_clocks:
+ omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
++ if (omap->mux_state)
++ mux_state_deselect(omap->mux_state);
++err_put_pm:
+ pm_runtime_dont_use_autosuspend(omap->dev);
+ pm_runtime_put_sync(omap->dev);
+ err_disable_pm:
--- /dev/null
+From a9503a2ecd95e23d7243bcde7138192de8c1c281 Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sat, 5 Jul 2025 09:57:37 +0200
+Subject: i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit a9503a2ecd95e23d7243bcde7138192de8c1c281 upstream.
+
+omap_i2c_init() can fail. Handle this error in omap_i2c_probe().
+
+Fixes: 010d442c4a29 ("i2c: New bus driver for TI OMAP boards")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Cc: <stable@vger.kernel.org> # v2.6.19+
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/565311abf9bafd7291ca82bcecb48c1fac1e727b.1751701715.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-omap.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/i2c/busses/i2c-omap.c
++++ b/drivers/i2c/busses/i2c-omap.c
+@@ -1475,7 +1475,9 @@ omap_i2c_probe(struct platform_device *p
+ }
+
+ /* reset ASAP, clearing any IRQs */
+- omap_i2c_init(omap);
++ r = omap_i2c_init(omap);
++ if (r)
++ goto err_mux_state_deselect;
+
+ if (omap->rev < OMAP_I2C_OMAP1_REV_2)
+ r = devm_request_irq(&pdev->dev, omap->irq, omap_i2c_omap1_isr,
+@@ -1518,6 +1520,7 @@ omap_i2c_probe(struct platform_device *p
+
+ err_unuse_clocks:
+ omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
++err_mux_state_deselect:
+ if (omap->mux_state)
+ mux_state_deselect(omap->mux_state);
+ err_put_pm:
--- /dev/null
+From 6a7d11efd6915d80a025f2a0be4ae09d797b91ec Mon Sep 17 00:00:00 2001
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Date: Sat, 13 Jan 2024 23:46:27 +0100
+Subject: regulator: pwm-regulator: Calculate the output voltage for disabled PWMs
+
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+commit 6a7d11efd6915d80a025f2a0be4ae09d797b91ec upstream.
+
+If a PWM output is disabled then it's voltage has to be calculated
+based on a zero duty cycle (for normal polarity) or duty cycle being
+equal to the PWM period (for inverted polarity). Add support for this
+to pwm_regulator_get_voltage().
+
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Link: https://msgid.link/r/20240113224628.377993-3-martin.blumenstingl@googlemail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/regulator/pwm-regulator.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/regulator/pwm-regulator.c
++++ b/drivers/regulator/pwm-regulator.c
+@@ -157,6 +157,13 @@ static int pwm_regulator_get_voltage(str
+
+ pwm_get_state(drvdata->pwm, &pstate);
+
++ if (!pstate.enabled) {
++ if (pstate.polarity == PWM_POLARITY_INVERSED)
++ pstate.duty_cycle = pstate.period;
++ else
++ pstate.duty_cycle = 0;
++ }
++
+ voltage = pwm_get_relative_duty_cycle(&pstate, duty_unit);
+ if (voltage < min(max_uV_duty, min_uV_duty) ||
+ voltage > max(max_uV_duty, min_uV_duty))
--- /dev/null
+From b3cbdcc191819b75c04178142e2d0d4c668f68c0 Mon Sep 17 00:00:00 2001
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Date: Sat, 13 Jan 2024 23:46:28 +0100
+Subject: regulator: pwm-regulator: Manage boot-on with disabled PWM channels
+
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+commit b3cbdcc191819b75c04178142e2d0d4c668f68c0 upstream.
+
+Odroid-C1 uses a Monolithic Power Systems MP2161 controlled via PWM for
+the VDDEE voltage supply of the Meson8b SoC. Commit 6b9352f3f8a1 ("pwm:
+meson: modify and simplify calculation in meson_pwm_get_state") results
+in my Odroid-C1 crashing with memory corruption in many different places
+(seemingly at random). It turns out that this is due to a currently not
+supported corner case.
+
+The VDDEE regulator can generate between 860mV (duty cycle of ~91%) and
+1140mV (duty cycle of 0%). We consider it to be enabled by the bootloader
+(which is why it has the regulator-boot-on flag in .dts) as well as
+being always-on (which is why it has the regulator-always-on flag in
+.dts) because the VDDEE voltage is generally required for the Meson8b
+SoC to work. The public S805 datasheet [0] states on page 17 (where "A5"
+refers to the Cortex-A5 CPU cores):
+ [...] So if EE domains is shut off, A5 memory is also shut off. That
+ does not matter. Before EE power domain is shut off, A5 should be shut
+ off at first.
+
+It turns out that at least some bootloader versions are keeping the PWM
+output disabled. This is not a problem due to the specific design of the
+regulator: when the PWM output is disabled the output pin is pulled LOW,
+effectively achieving a 0% duty cycle (which in return means that VDDEE
+voltage is at 1140mV).
+
+The problem comes when the pwm-regulator driver tries to initialize the
+PWM output. To do so it reads the current state from the hardware, which
+is:
+ period: 3666ns
+ duty cycle: 3333ns (= ~91%)
+ enabled: false
+Then those values are translated using the continuous voltage range to
+860mV.
+Later, when the regulator is being enabled (either by the regulator core
+due to the always-on flag or first consumer - in this case the lima
+driver for the Mali-450 GPU) the pwm-regulator driver tries to keep the
+voltage (at 860mV) and just enable the PWM output. This is when things
+start to go wrong as the typical voltage used for VDDEE is 1100mV.
+
+Commit 6b9352f3f8a1 ("pwm: meson: modify and simplify calculation in
+meson_pwm_get_state") triggers above condition as before that change
+period and duty cycle were both at 0. Since the change to the pwm-meson
+driver is considered correct the solution is to be found in the
+pwm-regulator driver. Update the duty cycle during driver probe if the
+regulator is flagged as boot-on so that a call to pwm_regulator_enable()
+(by the regulator core during initialization of a regulator flagged with
+boot-on) without any preceding call to pwm_regulator_set_voltage() does
+not change the output voltage.
+
+[0] https://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf
+
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Link: https://msgid.link/r/20240113224628.377993-4-martin.blumenstingl@googlemail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/regulator/pwm-regulator.c | 33 +++++++++++++++++++++++++++++++++
+ 1 file changed, 33 insertions(+)
+
+--- a/drivers/regulator/pwm-regulator.c
++++ b/drivers/regulator/pwm-regulator.c
+@@ -323,6 +323,32 @@ static int pwm_regulator_init_continuous
+ return 0;
+ }
+
++static int pwm_regulator_init_boot_on(struct platform_device *pdev,
++ struct pwm_regulator_data *drvdata,
++ const struct regulator_init_data *init_data)
++{
++ struct pwm_state pstate;
++
++ if (!init_data->constraints.boot_on || drvdata->enb_gpio)
++ return 0;
++
++ pwm_get_state(drvdata->pwm, &pstate);
++ if (pstate.enabled)
++ return 0;
++
++ /*
++ * Update the duty cycle so the output does not change
++ * when the regulator core enables the regulator (and
++ * thus the PWM channel).
++ */
++ if (pstate.polarity == PWM_POLARITY_INVERSED)
++ pstate.duty_cycle = pstate.period;
++ else
++ pstate.duty_cycle = 0;
++
++ return pwm_apply_might_sleep(drvdata->pwm, &pstate);
++}
++
+ static int pwm_regulator_probe(struct platform_device *pdev)
+ {
+ const struct regulator_init_data *init_data;
+@@ -382,6 +408,13 @@ static int pwm_regulator_probe(struct pl
+ if (ret)
+ return ret;
+
++ ret = pwm_regulator_init_boot_on(pdev, drvdata, init_data);
++ if (ret) {
++ dev_err(&pdev->dev, "Failed to apply boot_on settings: %d\n",
++ ret);
++ return ret;
++ }
++
+ regulator = devm_regulator_register(&pdev->dev,
+ &drvdata->desc, &config);
+ if (IS_ERR(regulator)) {
usb-hub-fix-flushing-of-delayed-work-used-for-post-resume-purposes.patch
usb-hub-don-t-try-to-recover-devices-lost-during-warm-reset.patch
usb-dwc3-qcom-don-t-leave-bcr-asserted.patch
+i2c-omap-add-support-for-setting-mux.patch
+i2c-omap-fix-an-error-handling-path-in-omap_i2c_probe.patch
+i2c-omap-handle-omap_i2c_init-errors-in-omap_i2c_probe.patch
+regulator-pwm-regulator-calculate-the-output-voltage-for-disabled-pwms.patch
+regulator-pwm-regulator-manage-boot-on-with-disabled-pwm-channels.patch
+asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
