diff mbox series

ASoC: fsl_sai: remove reset code from dai_probe

Message ID 1615886826-30844-1-git-send-email-shengjiu.wang@nxp.com (mailing list archive)
State Not Applicable
Headers show
Series ASoC: fsl_sai: remove reset code from dai_probe | expand

Checks

Context Check Description
snowpatch_ozlabs/apply_patch success Successfully applied on branch powerpc/merge (0512161accb8b6f6dacc85d165350b1812ddcc33)
snowpatch_ozlabs/build-ppc64le success Build succeeded
snowpatch_ozlabs/build-ppc64be success Build succeeded
snowpatch_ozlabs/build-ppc64e success Build succeeded
snowpatch_ozlabs/build-pmac32 success Build succeeded
snowpatch_ozlabs/checkpatch success total: 0 errors, 0 warnings, 0 checks, 13 lines checked
snowpatch_ozlabs/needsstable success Patch has no Fixes tags

Commit Message

Shengjiu Wang March 16, 2021, 9:27 a.m. UTC 
From: Viorel Suman <viorel.suman@nxp.com>

SAI software reset is done in runtime resume,
there is no need to do it in fsl_sai_dai_probe.

Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
 sound/soc/fsl/fsl_sai.c | 7 -------
 1 file changed, 7 deletions(-)

Comments

Mark Brown March 16, 2021, 12:58 p.m. UTC | #1 
On Tue, Mar 16, 2021 at 05:27:06PM +0800, Shengjiu Wang wrote:
> From: Viorel Suman <viorel.suman@nxp.com>
> 
> SAI software reset is done in runtime resume,
> there is no need to do it in fsl_sai_dai_probe.

People can disable runtime PM in their configurations - do you not still
need a reset on probe in case there's no runtime PM?  It'd probably make
sense to factor the rest code out itno a function though.
Shengjiu Wang March 16, 2021, 1:33 p.m. UTC | #2 
On Tue, Mar 16, 2021 at 9:01 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Mar 16, 2021 at 05:27:06PM +0800, Shengjiu Wang wrote:
> > From: Viorel Suman <viorel.suman@nxp.com>
> >
> > SAI software reset is done in runtime resume,
> > there is no need to do it in fsl_sai_dai_probe.
>
> People can disable runtime PM in their configurations - do you not still
> need a reset on probe in case there's no runtime PM?  It'd probably make
> sense to factor the rest code out itno a function though.

Right, didn't consider the case of disable runtime PM.
Will move the reset code to a function.

Best regards
wang shengjiu
Viorel Suman March 16, 2021, 1:42 p.m. UTC | #3 
> On Tue, Mar 16, 2021 at 05:27:06PM +0800, Shengjiu Wang wrote:
> > From: Viorel Suman <viorel.suman@nxp.com>
> >
> > SAI software reset is done in runtime resume, there is no need to do
> > it in fsl_sai_dai_probe.
> 
> People can disable runtime PM in their configurations - do you not still need a
> reset on probe in case there's no runtime PM?  It'd probably make sense to
> factor the rest code out itno a function though.

Hi Mark, Shengjiu,

To me it makes sense to manage the clocks and reset from the same place.
Currently we have the clocks management moved completely into runtime PM
fsl_sai_runtime_resume and fsl_sai_runtime_suspend callbacks. 

/Viorel
Mark Brown March 16, 2021, 1:49 p.m. UTC | #4 
On Tue, Mar 16, 2021 at 01:42:40PM +0000, Viorel Suman wrote:

> To me it makes sense to manage the clocks and reset from the same place.
> Currently we have the clocks management moved completely into runtime PM
> fsl_sai_runtime_resume and fsl_sai_runtime_suspend callbacks. 

Usually the pattern is to have probe() leave everything powered up then
let runtime PM power things down if it's enabled, you can often do the
power up by having an open coded call to the resume callback in probe().
Shengjiu Wang March 19, 2021, 4:10 a.m. UTC | #5 
Hi Mark

On Tue, Mar 16, 2021 at 9:51 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Mar 16, 2021 at 01:42:40PM +0000, Viorel Suman wrote:
>
> > To me it makes sense to manage the clocks and reset from the same place.
> > Currently we have the clocks management moved completely into runtime PM
> > fsl_sai_runtime_resume and fsl_sai_runtime_suspend callbacks.
>
> Usually the pattern is to have probe() leave everything powered up then
> let runtime PM power things down if it's enabled, you can often do the
> power up by having an open coded call to the resume callback in probe().

It seems some drivers very depend on runtime PM, if the CONFIG_PM=n,
the drivers should not work.  What's the strategy for this?
Do we need to support both cases, or only one case is also acceptable?

Best regards
Wang Shengjiu
diff mbox series

Patch

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 6ef2ce348232..9e7893f91882 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -711,13 +711,6 @@  static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
 	struct fsl_sai *sai = dev_get_drvdata(cpu_dai->dev);
 	unsigned int ofs = sai->soc_data->reg_offset;
 
-	/* Software Reset for both Tx and Rx */
-	regmap_write(sai->regmap, FSL_SAI_TCSR(ofs), FSL_SAI_CSR_SR);
-	regmap_write(sai->regmap, FSL_SAI_RCSR(ofs), FSL_SAI_CSR_SR);
-	/* Clear SR bit to finish the reset */
-	regmap_write(sai->regmap, FSL_SAI_TCSR(ofs), 0);
-	regmap_write(sai->regmap, FSL_SAI_RCSR(ofs), 0);
-
 	regmap_update_bits(sai->regmap, FSL_SAI_TCR1(ofs),
 			   FSL_SAI_CR1_RFW_MASK(sai->soc_data->fifo_depth),
 			   sai->soc_data->fifo_depth - FSL_SAI_MAXBURST_TX);