Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1195007yba; Sun, 21 Apr 2019 01:01:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqzr29zR2mL6lIgK68lFfYfsovK16Lfn0YS7gOWSLZH5NMSQgxj/1Zkj4zwi2BvZ5ToCFJSk X-Received: by 2002:aa7:8083:: with SMTP id v3mr14252346pff.135.1555833688023; Sun, 21 Apr 2019 01:01:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555833688; cv=none; d=google.com; s=arc-20160816; b=mY6l4jiAIsPuFrFy1S8f6ttzbWkl6c5s6oyKRKMwm9m+iuBh1kV/t/j1QRtcpzQ8h7 emL5wCprGNQsjpQsw8Yj3tEPbnm6HzlDfEmaEdxQSDkV+OE4DMn7B6ghWLjx3Nht7VbY kGw+w3AyfRoPeRxtKb1SwmVS5EDy4WaUuUdemOGb8U/6hoIb+AcF2tAr0DeQc7RGx1g+ LlL2vQnnbAlOwAKO3xPbXsbEz3Vut/mt+Z5/tqXXywS25ZZPwMAKfHCIFzVa26VpIIxa jrQl8Ilpfq+g10dic9qJbP2YYNFsJCirp7KrnefKy2i3pXvSEfHo1TCjf6v3MW2EG4Ti JJFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RwZZBuIT2g03XvndH8sbHe1AHIfLw+gx2oqC1JgvpJQ=; b=Sx1+y4fiZvj5wJarDglmZ6ZaU5B2WHTBzyZjPz8YrUuBmB1D9zv56NgkzuLuCVapOp IVanM23Ljaj5wNjSUeLO/ZfT/p+vW9GAl4lnYlWZ1iahoweUbOuqmbuNDBCKBIhh3nFy sFaoNSi0q41HAxXnRkj9ZvemLEAXI2P2ckXgVbOztOZtR6gW35GRCtUnYPpvYDQbergP t7IiFw0SLDpM1hwLnnW6D7ZqKiRbgTuHs2ShXdkSDPCnhAsbc9aCdlGyzKoAe61JArof KCu9QHoABrRXkuOzxqJ92LbxMWUlBzurx2V2+SZRnj14t0yi28sqA8hF2lrOCl/0x0Pd 3FXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="K/2xkpcA"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s145si9403478pgs.228.2019.04.21.01.00.59; Sun, 21 Apr 2019 01:01:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="K/2xkpcA"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726146AbfDUH0z (ORCPT + 99 others); Sun, 21 Apr 2019 03:26:55 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:39359 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725936AbfDUH0z (ORCPT ); Sun, 21 Apr 2019 03:26:55 -0400 Received: by mail-ed1-f67.google.com with SMTP id k45so7365672edb.6 for ; Sun, 21 Apr 2019 00:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RwZZBuIT2g03XvndH8sbHe1AHIfLw+gx2oqC1JgvpJQ=; b=K/2xkpcAw8XJTQUSiBs2SyTT/7muXOLLGwSYcHLc2ShR6wJKQI/AmnzvhT2A7kXaR9 OEM2xGCX1KPIjD1+5j6kYKr1+ToIXED4xZPLeYzjDuUJfYIFLOKJa02dfqjO+lQAPGCZ DQ8j5MUuwU4hcd9BG6Jof4WedjEed46fISr8Hq4JP2V5IGqbRhk8mdDpC8jpgpWDgmKt +5TfSf/eR8WWxZ2iBwHUiAT5vtfgVAbI60/+XcfHccEXsqan34Cm9v8QZkbTzjGDpxF4 wgGFA5ze5MvbW/7TKAvCHUIxGRJRWKMfhO65ss1rjjsV7JW5Ng298GGvhdsURGN65MGH BZJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RwZZBuIT2g03XvndH8sbHe1AHIfLw+gx2oqC1JgvpJQ=; b=W7eGf2lcBvZhfJMN9BfhoCc4HJf4oioKwXP3GMTLPLYBINl+KVIzsy0zZE3TRPLUV9 wqjCSyfbxP+0jauo5EMRpYRG1CvJY+3otMzFHPKOtegvqDqSmq+VTrN1aFtzTmYx6swJ 38amsxJeDevUfE7kh89sKQWG5Z4j9dlrTNNxmdB93aIUweYzuIjEanWqPrC/oWgl8YaR 2oqcDELpz5jd6QHIcBXbddGZ4i7uiX+kopurtP+Tpd0SOjcyZ/9GLqHMUiIv/NBXQI/I X0oGZNJF6V9dGmS8YZpZFSWXt10tKZidt8HnY7jwZeIlxeN32IOrSXtPYQQ7Y4Hi1o5j +LNA== X-Gm-Message-State: APjAAAVDd/+6E82d/NIF6pa1pXbIiGSTwFPFURySnMbmo2Ewhr3JAEMb MKpV7QgJf1AuKgO2zJnj9HVvEN94VPO1Q9XvOOfnozsC X-Received: by 2002:a50:a3c2:: with SMTP id t2mr8188138edb.46.1555831612567; Sun, 21 Apr 2019 00:26:52 -0700 (PDT) MIME-Version: 1.0 References: <20190420154038.14576-1-daniel.baluta@nxp.com> <20190421053749.GA5552@Asurada> In-Reply-To: <20190421053749.GA5552@Asurada> From: Daniel Baluta Date: Sun, 21 Apr 2019 10:26:40 +0300 Message-ID: Subject: Re: [alsa-devel] [PATCH] ASoC: fsl: sai: Fix clock source for mclk0 To: Nicolin Chen Cc: Daniel Baluta , "alsa-devel@alsa-project.org" , "timur@kernel.org" , "Xiubo.Lee@gmail.com" , "linuxppc-dev@lists.ozlabs.org" , "S.j. Wang" , "tiwai@suse.com" , "lgirdwood@gmail.com" , "broonie@kernel.org" , dl-linux-imx , "festevam@gmail.com" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nicolin, Thanks for review! On Sun, Apr 21, 2019 at 8:39 AM Nicolin Chen wrote: > > By following the pattern of previous Subjects: > ASoC: fsl_sai: Fix clock Source for mclk0 I see. Will fix in v2. > > On Sat, Apr 20, 2019 at 03:41:04PM +0000, Daniel Baluta wrote: > > SAI provide multiple master clock source options selectable > > via bit MSEL of TCR2/RCR2. > > > > All possible master clock sources are stored in sai->mclk_clk > > array. Current implementation assumes that MCLK0 source is always > > busclk, but this is wrong! > > > > For example, on i.MX8QM we have: > > > > 00b - Bus Clock selected. > > 01b - Master Clock (MCLK) 1 option selected. > > 10b - Master Clock (MCLK) 2 option selected. > > 11b - Master Clock (MCLK) 3 option selected. > > > > while on i.MX6SX we have: > > > > 00b - Master Clock (MCLK) 1 option selected. > > 01b - Master Clock (MCLK) 1 option selected. > > 10b - Master Clock (MCLK) 2 option selected. > > 11b - Master Clock (MCLK) 3 option selected. > > > > So, this patch will read mclk0 source clock from device tree. > > > > Signed-off-by: Shengjiu Wang > > Signed-off-by: Daniel Baluta > > --- > > sound/soc/fsl/fsl_sai.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c > > index d2a4dc744fd7..faa8de87ff83 100644 > > --- a/sound/soc/fsl/fsl_sai.c > > +++ b/sound/soc/fsl/fsl_sai.c > > @@ -829,8 +829,7 @@ static int fsl_sai_probe(struct platform_device *pdev) > > sai->bus_clk = NULL; > > } > > > > - sai->mclk_clk[0] = sai->bus_clk; > > - for (i = 1; i < FSL_SAI_MCLK_MAX; i++) { > > + for (i = 0; i < FSL_SAI_MCLK_MAX; i++) { > > sprintf(tmp, "mclk%d", i); > > Firstly, according to your commit message, neither imx8qm nor > imx6sx has an "mclk0" clock in the clock list. Either of them > starts with "mclk1". So, before you change the driver, I don't > think it's even a right thing to define an "mclk0" in the DT. From what I understand mclk0 means option 00b of MSEL bits which is: * busclk for i.MX8 * mclk1 for i.MX6/7. Adding a mclk0 in the DT and making it point to the correct option (busclk or mclk1) does no harm as the driver doesn't yet parse mclk0. I have already sent a patch to add mclk0 to imx6/7 DTS here: https://lkml.org/lkml/2019/4/20/56 So, even if the DT change gets accepted first there shouldn't pe any problem, as the driver won't parse mclk0 string yet. Even if the current patch gets accepted first it shouldn't be any problem also as the probe will try to find "mclk0" in the DT and will just print a warning and move on looking for mclk1, mclk2... > > > sai->mclk_clk[i] = devm_clk_get(&pdev->dev, tmp); > > if (IS_ERR(sai->mclk_clk[i])) { > > Secondly, this would break existing DT bindings of imx6sx and > imx7 platforms as they both have clock-names defined in DTB: > clock-names = "bus", "mclk1", "mclk2", "mclk3"; > Since there's no "mclk0", the entire probe() would error-out. Not exactly. The probe won't error-out. It will just print a warning message dev_err(&pdev->dev, "failed to get mclk%d clock: %ld\n" and move on. The functionality, will still be the same. > And mainline has a DT backward-compatible policy, which means > you can't just rename the "bus" in the DTBs but would have to > support them, not to mention "mclk0" is still questionable. My patch doesn't rename "bus" in the DTB. "bus" clock stays there. It just adds another clock "mclk0". In my opinion, the current implementation of fsl_sai has a bug for imx6/7. Currently, fsl_sai.c driver does: sai->mclk_clk[0] = sai->bus_clk; is wrong, because on imx6/7 mclk_clk[0] should point to the same clk as mclk_clk[1] > > So the right way to fix it is, in my option, to differentiate > the mclk_clk[0] clock source name with the compatible string. > Then you can get the clock name and simply do: > - sai->mclk_clk[0] = sai->bus_clk; > + sai->mclk_clk[0] = devm_clk_get(&pdev->dev, tmp); > + if (IS_ERR(sai->mclk_clk[0)) { > + /* error-out*/ > + } My approach is to add mclk0 in the DT and make it point to: * busclk for i.MX8 * mclk1 for i.MX6/7. So, here it is how the DT nodes will look like: $ arch/arm/boot/dts/imx6sx.dtsi clocks = <&clks IMX6SX_CLK_SAI1_IPG>, <&clks IMX6SX_CLK_SAI1>, <&clks IMX6SX_CLK_SAI1>, <&clks 0>, <&clks 0>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3"; $ arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi clocks = <&clk IMX8MQ_CLK_SAI2_IPG>, <&clk IMX8MQ_CLK_SAI2_IPG>, <&clk IMX8MQ_CLK_SAI2_ROOT>, <&clk IMX8MQ_CLK_DUMMY>, <&clk IMX8MQ_CLK_DUMMY>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3"; This approach makes busclk/mclk0 handling generic and avoids the looking for compatible strings. thanks, Daniel.