[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230706084706.bzwsbi3zisx5m5rl@fatal.se>
Date: Thu, 6 Jul 2023 10:47:06 +0200
From: Andreas Henriksson <andreas@...al.se>
To: Fabio Estevam <festevam@...il.com>
Cc: Shengjiu Wang <shengjiu.wang@....com>,
Nicolin Chen <nicoleotsuka@...il.com>,
Xiubo Li <Xiubo.Lee@...il.com>,
Shengjiu Wang <shengjiu.wang@...il.com>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Linux-ALSA <alsa-devel@...a-project.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Hans Söderlund <hans.soderlund@...lbit.se>
Subject: Re: [PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode
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@....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
Powered by blists - more mailing lists