From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16BECEB64D9 for ; Thu, 6 Jul 2023 12:34:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230196AbjGFMeP (ORCPT ); Thu, 6 Jul 2023 08:34:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229501AbjGFMeK (ORCPT ); Thu, 6 Jul 2023 08:34:10 -0400 Received: from pi.fatal.se (andreasfatal-1-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:f16::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 27DDC1BE3 for ; Thu, 6 Jul 2023 05:34:03 -0700 (PDT) Received: by pi.fatal.se (Postfix, from userid 1000) id E76412A8E0; Thu, 6 Jul 2023 14:34:01 +0200 (CEST) Date: Thu, 6 Jul 2023 14:34:01 +0200 From: Andreas Henriksson To: Fabio Estevam Cc: Shengjiu Wang , Shengjiu Wang , Nicolin Chen , Xiubo Li , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , Linux-ALSA , linuxppc-dev , linux-kernel , Hans =?iso-8859-1?Q?S=F6derlund?= Subject: Re: [PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode Message-ID: <20230706123401.kctossjho26bry7e@fatal.se> References: <1652963808-14515-1-git-send-email-shengjiu.wang@nxp.com> <20230706084706.bzwsbi3zisx5m5rl@fatal.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EBD33EB64D9 for ; Thu, 6 Jul 2023 13:23:34 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Qxcfs3jsWz3cc6 for ; Thu, 6 Jul 2023 23:23:33 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=fatal.se (client-ip=2001:470:1f04:f16::2; helo=pi.fatal.se; envelope-from=ah@fatal.se; receiver=lists.ozlabs.org) X-Greylist: delayed 13597 seconds by postgrey-1.37 at boromir; Thu, 06 Jul 2023 22:34:07 AEST Received: from pi.fatal.se (andreasfatal-1-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:f16::2]) by lists.ozlabs.org (Postfix) with ESMTP id 4QxbYq3ccRz3bqh for ; Thu, 6 Jul 2023 22:34:05 +1000 (AEST) Received: by pi.fatal.se (Postfix, from userid 1000) id E76412A8E0; Thu, 6 Jul 2023 14:34:01 +0200 (CEST) Date: Thu, 6 Jul 2023 14:34:01 +0200 From: Andreas Henriksson To: Fabio Estevam Subject: Re: [PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode Message-ID: <20230706123401.kctossjho26bry7e@fatal.se> References: <1652963808-14515-1-git-send-email-shengjiu.wang@nxp.com> <20230706084706.bzwsbi3zisx5m5rl@fatal.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Mailman-Approved-At: Thu, 06 Jul 2023 23:17:34 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux-ALSA , Xiubo Li , linuxppc-dev , Shengjiu Wang , Takashi Iwai , Liam Girdwood , Jaroslav Kysela , Nicolin Chen , Mark Brown , Hans =?iso-8859-1?Q?S=F6derlund?= , Shengjiu Wang , linux-kernel Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 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