DSP on i.MX8MP doesn't have a direct reset line so according to hardware
design team in order to handle assert/deassert/reset functionality we
need to use a combination of control bits from two modules. Audio block
control module for Run/Stall control of the DSP and DAP module in order
to do software reset.

In a first step, for i.MX8MP we are switching on using the reset
controller API to handle the DSP Run/Stall bits i.MX8MP. This comes with
the advantage of offering a better probe ordering and a more natural way
of abstracting the Audio block control bits.

Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Tested-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
---
 sound/soc/sof/imx/imx8.c | 24 ++++++++----------------
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/sound/soc/sof/imx/imx8.c b/sound/soc/sof/imx/imx8.c
index ab07512e511d..a40a8047873e 100644
--- a/sound/soc/sof/imx/imx8.c
+++ b/sound/soc/sof/imx/imx8.c
@@ -11,6 +11,7 @@
 #include <linux/arm-smccc.h>
 #include <linux/firmware/imx/svc/misc.h>
 #include <linux/mfd/syscon.h>
+#include <linux/reset.h>
 
 #include "imx-common.h"
 
@@ -23,13 +24,6 @@
 #define IMX8M_DAP_PWRCTL (0x4000 + 0x3020)
 #define IMX8M_PWRCTL_CORERESET BIT(16)
 
-#define AudioDSP_REG0 0x100
-#define AudioDSP_REG1 0x104
-#define AudioDSP_REG2 0x108
-#define AudioDSP_REG3 0x10c
-
-#define AudioDSP_REG2_RUNSTALL  BIT(5)
-
 /* imx8ulp macros */
 #define FSL_SIP_HIFI_XRDC       0xc200000e
 #define SYSCTRL0                0x8
@@ -43,6 +37,7 @@
 struct imx8m_chip_data {
 	void __iomem *dap;
 	struct regmap *regmap;
+	struct reset_control *run_stall;
 };
 
 /*
@@ -137,8 +132,7 @@ static int imx8m_reset(struct snd_sof_dev *sdev)
 	/* keep reset asserted for 10 cycles */
 	usleep_range(1, 2);
 
-	regmap_update_bits(chip->regmap, AudioDSP_REG2,
-			   AudioDSP_REG2_RUNSTALL, AudioDSP_REG2_RUNSTALL);
+	reset_control_assert(chip->run_stall);
 
 	/* take the DSP out of reset and keep stalled for FW loading */
 	pwrctl = readl(chip->dap + IMX8M_DAP_PWRCTL);
@@ -152,9 +146,7 @@ static int imx8m_run(struct snd_sof_dev *sdev)
 {
 	struct imx8m_chip_data *chip = get_chip_pdata(sdev);
 
-	regmap_update_bits(chip->regmap, AudioDSP_REG2, AudioDSP_REG2_RUNSTALL, 0);
-
-	return 0;
+	return reset_control_deassert(chip->run_stall);
 }
 
 static int imx8m_probe(struct snd_sof_dev *sdev)
@@ -174,10 +166,10 @@ static int imx8m_probe(struct snd_sof_dev *sdev)
 		return dev_err_probe(sdev->dev, -ENODEV,
 				     "failed to ioremap DAP\n");
 
-	chip->regmap = syscon_regmap_lookup_by_phandle(sdev->dev->of_node, "fsl,dsp-ctrl");
-	if (IS_ERR(chip->regmap))
-		return dev_err_probe(sdev->dev, PTR_ERR(chip->regmap),
-				     "failed to fetch dsp ctrl regmap\n");
+	chip->run_stall = devm_reset_control_get_exclusive(sdev->dev, "runstall");
+	if (IS_ERR(chip->run_stall))
+		return dev_err_probe(sdev->dev, PTR_ERR(chip->run_stall),
+				     "failed to get dsp runstall reset control\n");
 
 	common->chip_pdata = chip;
 
-- 
2.43.0

On Mon, 05 May 2025 14:42:51 +0300, Daniel Baluta wrote:
> DSP on i.MX8MP doesn't have a direct reset line so according to hardware
> design team in order to handle assert/deassert/reset functionality we
> need to use a combination of control bits from two modules. Audio block
> control module for Run/Stall control of the DSP and DAP module in order
> to do software reset.
> 
> In a first step, for i.MX8MP we are switching on using the reset
> controller API to handle the DSP Run/Stall bits i.MX8MP. This comes with
> the advantage of offering a better probe ordering and a more natural way
> of abstracting the Audio block control bits.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: SOF: imx8m: Use reset controller API to control the DSP
      commit: a71b261c19a455f7f8e560b4ddfac44d3150ae39

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark