[PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode
On i.MX8MM, the MCTL_MCLK_EN bit it is not only the gate for MCLK output to PAD, but also the gate bit between root clock and SAI module, So it is need to be enabled for master mode, otherwise there is no bclk generated.
Signed-off-by: Shengjiu Wang shengjiu.wang@nxp.com --- sound/soc/fsl/fsl_sai.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index fa950dde5310..dae16a14f177 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -437,6 +437,12 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq) FSL_SAI_CR2_DIV_MASK | FSL_SAI_CR2_BYP, savediv / 2 - 1);
+ if (sai->soc_data->max_register >= FSL_SAI_MCTL) { + /* SAI is in master mode at this point, so enable MCLK */ + regmap_update_bits(sai->regmap, FSL_SAI_MCTL, + FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN); + } + return 0; }
Hi Shengjiu,
On Thu, May 19, 2022 at 9:49 AM Shengjiu Wang shengjiu.wang@nxp.com wrote:
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index fa950dde5310..dae16a14f177 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -437,6 +437,12 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq) FSL_SAI_CR2_DIV_MASK | FSL_SAI_CR2_BYP, savediv / 2 - 1);
if (sai->soc_data->max_register >= FSL_SAI_MCTL) {
Isn't it a bit fragile to take this decision based on the number of SAI registers in the SoC?
What about adding a specific field in soc_data for such a purpose?
On Thu, May 19, 2022 at 9:23 PM Fabio Estevam festevam@gmail.com wrote:
Hi Shengjiu,
On Thu, May 19, 2022 at 9:49 AM Shengjiu Wang shengjiu.wang@nxp.com wrote:
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index fa950dde5310..dae16a14f177 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -437,6 +437,12 @@ static int fsl_sai_set_bclk(struct snd_soc_dai
*dai, bool tx, u32 freq)
FSL_SAI_CR2_DIV_MASK |FSL_SAI_CR2_BYP,
savediv / 2 - 1);
if (sai->soc_data->max_register >= FSL_SAI_MCTL) {Isn't it a bit fragile to take this decision based on the number of SAI registers in the SoC?
What about adding a specific field in soc_data for such a purpose?
'max_register' is one field in the soc_data, until now in our internal usage it seems ok for using this condition.
Thanks.
Best regards Wang shengjiu
Hello Shengjiu, Fabio,
On Thu, May 19, 2022 at 10:23:06AM -0300, Fabio Estevam wrote:
Hi Shengjiu,
On Thu, May 19, 2022 at 9:49 AM Shengjiu Wang shengjiu.wang@nxp.com wrote:
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index fa950dde5310..dae16a14f177 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -437,6 +437,12 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq) FSL_SAI_CR2_DIV_MASK | FSL_SAI_CR2_BYP, savediv / 2 - 1);
if (sai->soc_data->max_register >= FSL_SAI_MCTL) {Isn't it a bit fragile to take this decision based on the number of SAI registers in the SoC?
What about adding a specific field in soc_data for such a purpose?
We've been working on an i.MX8MP where MCLK needs to be input and found that this enables the MCLK as output despite not having set the `fsl,sai-mclk-direction-output;` devicetree property in our DT. Reverting the patch fixes the issues for us.
I have to say that the code comment made me a bit confused, but once I found the commit message I understood why this code existed. If this is really i.MX8MM specific maybe mention that in the code comment and please make the code actually only trigger on i.MX8MM. It seems to me like these all fulfill the current criteria: imx7ulp, imx8mq, imx8mm, imx8mp, imx8ulp, imx93
Should I report this in bugzilla.kernel.org ?
Regards, Andreas Henriksson
On Thu, Jul 6, 2023 at 4:47 PM Andreas Henriksson andreas@fatal.se wrote:
Hello Shengjiu, Fabio,
On Thu, May 19, 2022 at 10:23:06AM -0300, Fabio Estevam wrote:
Hi Shengjiu,
On Thu, May 19, 2022 at 9:49 AM Shengjiu Wang shengjiu.wang@nxp.com
wrote:
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index fa950dde5310..dae16a14f177 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -437,6 +437,12 @@ static int fsl_sai_set_bclk(struct snd_soc_dai
*dai, bool tx, u32 freq)
FSL_SAI_CR2_DIV_MASK |FSL_SAI_CR2_BYP,
savediv / 2 - 1);
if (sai->soc_data->max_register >= FSL_SAI_MCTL) {Isn't it a bit fragile to take this decision based on the number of SAI registers in the SoC?
What about adding a specific field in soc_data for such a purpose?
We've been working on an i.MX8MP where MCLK needs to be input and found that this enables the MCLK as output despite not having set the `fsl,sai-mclk-direction-output;` devicetree property in our DT. Reverting the patch fixes the issues for us.
Good catch. seems there is an issue here.
best regards wang shengjiu
I have to say that the code comment made me a bit confused, but once
I found the commit message I understood why this code existed. If this is really i.MX8MM specific maybe mention that in the code comment and please make the code actually only trigger on i.MX8MM. It seems to me like these all fulfill the current criteria: imx7ulp, imx8mq, imx8mm, imx8mp, imx8ulp, imx93
Should I report this in bugzilla.kernel.org ?
Regards, Andreas Henriksson
Hi Andreas,
On Thu, Jul 6, 2023 at 5:47 AM Andreas Henriksson andreas@fatal.se wrote:
We've been working on an i.MX8MP where MCLK needs to be input and found that this enables the MCLK as output despite not having set the `fsl,sai-mclk-direction-output;` devicetree property in our DT. Reverting the patch fixes the issues for us.
I have to say that the code comment made me a bit confused, but once I found the commit message I understood why this code existed. If this is really i.MX8MM specific maybe mention that in the code comment and please make the code actually only trigger on i.MX8MM. It seems to me like these all fulfill the current criteria: imx7ulp, imx8mq, imx8mm, imx8mp, imx8ulp, imx93
Should I report this in bugzilla.kernel.org ?
Should we do a fix like this?
--- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -1453,7 +1453,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
/* Select MCLK direction */ if (sai->mclk_direction_output && - sai->soc_data->max_register >= FSL_SAI_MCTL) { + sai->soc_data->max_register >= FSL_SAI_MCTL && sai->mclk_direction_output) { regmap_update_bits(sai->regmap, FSL_SAI_MCTL, FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN); }
On Thu, Jul 6, 2023 at 7:08 PM Fabio Estevam festevam@gmail.com wrote:
Hi Andreas,
On Thu, Jul 6, 2023 at 5:47 AM Andreas Henriksson andreas@fatal.se wrote:
We've been working on an i.MX8MP where MCLK needs to be input and found that this enables the MCLK as output despite not having set the `fsl,sai-mclk-direction-output;` devicetree property in our DT. Reverting the patch fixes the issues for us.
I have to say that the code comment made me a bit confused, but once I found the commit message I understood why this code existed. If this is really i.MX8MM specific maybe mention that in the code comment and please make the code actually only trigger on i.MX8MM. It seems to me like these all fulfill the current criteria: imx7ulp, imx8mq, imx8mm, imx8mp, imx8ulp, imx93
Should I report this in bugzilla.kernel.org ?
Should we do a fix like this?
--- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -1453,7 +1453,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
/* Select MCLK direction */ if (sai->mclk_direction_output &&
sai->soc_data->max_register >= FSL_SAI_MCTL) {
sai->soc_data->max_register >= FSL_SAI_MCTL &&sai->mclk_direction_output) { regmap_update_bits(sai->regmap, FSL_SAI_MCTL, FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN); }
No, this is the code in probe(). The code with the issue is in fsl_sai_set_bclk().
The clean way for fixing is to remove the code in fsl_sai_set_bclk() and add "fsl,sai-mclk-direction-output;" property in dts for some node.
best regards wang shengjiu
On Thu, Jul 6, 2023 at 8:19 AM Shengjiu Wang shengjiu.wang@gmail.com wrote:
No, this is the code in probe(). The code with the issue is in fsl_sai_set_bclk().
Yes, I put it in the wrong place.
The clean way for fixing is to remove the code in fsl_sai_set_bclk() and add "fsl,sai-mclk-direction-output;" property in dts for some node.
Yes, what about this?
--- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -507,7 +507,7 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq) savediv / 2 - 1); }
- if (sai->soc_data->max_register >= FSL_SAI_MCTL) { + if (sai->soc_data->max_register >= FSL_SAI_MCTL && sai->mclk_direction_output) { /* SAI is in master mode at this point, so enable MCLK */ regmap_update_bits(sai->regmap, FSL_SAI_MCTL, FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN);
Hello Fabio,
Maybe I shouldn't comment as I'm already on deep water, but...
On Thu, Jul 06, 2023 at 08:32:57AM -0300, Fabio Estevam wrote:
On Thu, Jul 6, 2023 at 8:19 AM Shengjiu Wang shengjiu.wang@gmail.com wrote:
No, this is the code in probe(). The code with the issue is in fsl_sai_set_bclk().
Yes, I put it in the wrong place.
The clean way for fixing is to remove the code in fsl_sai_set_bclk() and add "fsl,sai-mclk-direction-output;" property in dts for some node.
Yes, what about this?
--- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -507,7 +507,7 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq) savediv / 2 - 1); }
if (sai->soc_data->max_register >= FSL_SAI_MCTL) {
if (sai->soc_data->max_register >= FSL_SAI_MCTL &&sai->mclk_direction_output) { /* SAI is in master mode at this point, so enable MCLK */ regmap_update_bits(sai->regmap, FSL_SAI_MCTL, FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN);
This is exactly the same as and thus redundant to the code already in the probe function?!
If I understood it correctly, the problem Shengjiu was trying to adress was that apparently on i.MX8MM (and only imx8mm?!), even when using MCLK in *input*, you still need to enable it because otherwise BCLK will not be generated. (I personally don't know anything about this or the imx8mm variant though.)
The problem could probably equally well be worked around by always setting the fsl,sai-mclk-direction-output; devicetree property on imx8mm, even when using MCLK in input..... But I'm just guessing here to be honest. This is just as I understood what purpose the initial patch that was merged had.
The current state affects more devices than imx8mm though, making MCLK in input mode not possible.
I think your initial review comment was spot on Fabio. There probably needs to be a(n imx8mm) specific flag that says when this workaround should be applied and gate the code in bclk function on that. Atleast that's the only thing I can think of if my interpretation of the problem for imx8mm is correct.
Regards, Andreas Henriksson
Hi Andreas,
On Thu, Jul 6, 2023 at 9:34 AM Andreas Henriksson andreas@fatal.se wrote:
I think your initial review comment was spot on Fabio. There probably needs to be a(n imx8mm) specific flag that says when this workaround should be applied and gate the code in bclk function on that. Atleast that's the only thing I can think of if my interpretation of the problem for imx8mm is correct.
Yes, deciding whether MCLK_EN should act as a clock gate based on the number of SAI registers seems fragile to me.
I have sent a proposal as RFC. Please give it a try if you have a chance.
I would like Shengjiu to confirm if imx8mn and imx93 should also behave like imx8mm in this aspect.
Cheers
On Thu, Jul 6, 2023 at 8:19 AM Shengjiu Wang shengjiu.wang@gmail.com wrote:
The clean way for fixing is to remove the code in fsl_sai_set_bclk() and add "fsl,sai-mclk-direction-output;" property in dts for some node.
Yes, after thinking more about it, I agree.
So what you are proposing is basically a revert of the patch in Subject and I assume that the reason you did the original patch was that you missed passing fsl,sai-mclk-direction-output in DT.
I will send the revert.
Thanks
On Thu, 19 May 2022 20:36:48 +0800, Shengjiu Wang wrote:
On i.MX8MM, the MCTL_MCLK_EN bit it is not only the gate for MCLK output to PAD, but also the gate bit between root clock and SAI module, So it is need to be enabled for master mode, otherwise there is no bclk generated.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode commit: ff87d619ac180444db297f043962a5c325ded47b
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
participants (5)
-
Andreas Henriksson -
Fabio Estevam -
Mark Brown -
Shengjiu Wang -
Shengjiu Wang