Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp544663imu; Tue, 27 Nov 2018 17:01:47 -0800 (PST) X-Google-Smtp-Source: AFSGD/XyusGDrAG8kRzmjlZtYb3S3+4I6poeQlnf+/jORscKS+jCE2bAfOxNjkzzj4+CDUW47Qpo X-Received: by 2002:a63:a452:: with SMTP id c18mr28540256pgp.204.1543366907551; Tue, 27 Nov 2018 17:01:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543366907; cv=none; d=google.com; s=arc-20160816; b=MGrFbnYdl+6K1QgWQvqOA+vUtyhuO6W1RbpsKzmdv5nVgGnKRQk9ZwOBWU9axBwhth ijFSMVJkT5+o4711GDwsPe/piBzGvV+HH5nbNJoPpLZGcqPlR0lZ/bS9FHhEPhQCB0/3 JgILIC8Vg2BfScF3UMtw8f9DnCczTjSBejuJejKTSInYcSyew+Z7OfsAp5OfDYThduMV PHVmxwazS7AS5v+ket32NKVccyu41ilqzGMOvHrkqweynjRtfa7m2xuf0f+Cw6kPVluV 3hUqRVuleWrOQL5xaWbCASno5BaXVrNcXA5RGXTQqFXpZL4ewRN7tGzgbwWVF6MX0zg/ HjHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=EJk6utP5DpD+YhSMiGCrdWyh7ppaAuHdS24KLkPx540=; b=fkk3O7b1DLCp9CajFs35EjBWYUO/hc3Pt4G7RR8EFkdkwOL7EwZhBMWYZ8yG2X1bW0 uWwEt/pYo/oUcmZh1nxiP22wIvvPR1FJTfa+kHML+clr6on02Wd/x5mRMQdR3tgXy49Y 6mEGAHztpdXx8kHUZ/0BcCHGd2OurGcZbytDI1eZJJL+n16JedlfkAJ1l/EA6tct7y0q 8aKz6CZtcKF0mqog0Nq3j9UrgMBq3Qjn635cgZ81k+llTkewT14EfufsICTtwPumlCGp IUi0d68Iu5/G849H4O1JUrPxQIl4vnm+5ZMsdXm59Eu8lLATggjf3W+0UDS0wWdLjw2z dxaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NZYKLGhZ; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 20si4930519pgt.469.2018.11.27.17.01.31; Tue, 27 Nov 2018 17:01:47 -0800 (PST) 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=@kernel.org header.s=default header.b=NZYKLGhZ; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727062AbeK1L6y (ORCPT + 99 others); Wed, 28 Nov 2018 06:58:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:52318 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726457AbeK1L6x (ORCPT ); Wed, 28 Nov 2018 06:58:53 -0500 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3A0DA20645; Wed, 28 Nov 2018 00:59:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543366749; bh=7q54EERWrarCm09cdl5l6CxJn23chAyNp6Jjc1wr4Ck=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NZYKLGhZD6YUBlFMzPwRuS+Zwp7BVa3wiC32o7vEPWqzxog4/XE2QFp5leOeR23JP AjNnbtdDjnDdvA/gfYJP33FTv2RCkIfGdkPYVGBKCO3uzGL8hMTm7LG+HQDZzb92zK Ot8vjMGpzJfai61AbTjIciuekTUs0sRG/ZBciyJg= Received: by mail-wr1-f51.google.com with SMTP id j2so24601670wrw.1; Tue, 27 Nov 2018 16:59:09 -0800 (PST) X-Gm-Message-State: AA+aEWZw7QNij29Y3BXPDiU0CUsoxGV96xfN0LdEqKjvWkND1KPVhSN+ YcyQFK5WTBIdeXERr+yj6gWCL0HkQpNrUWpZg/I= X-Received: by 2002:a5d:66c1:: with SMTP id k1mr28529061wrw.132.1543366747701; Tue, 27 Nov 2018 16:59:07 -0800 (PST) MIME-Version: 1.0 References: <20181127034254.24721-1-weiyi.lu@mediatek.com> <20181127034254.24721-5-weiyi.lu@mediatek.com> In-Reply-To: From: Sean Wang Date: Tue, 27 Nov 2018 16:58:57 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 03/11] clk: mediatek: Disable tuner_en before change PLL rate To: drinkcat@chromium.org Cc: weiyi.lu@mediatek.com, Matthias Brugger , sboyd@codeaurora.org, robh@kernel.org, jamesjj.liao@mediatek.com, srv_heupstream@mediatek.com, linux-kernel@vger.kernel.org, fan.chen@mediatek.com, linux-mediatek@lists.infradead.org, owen.chen@mediatek.com, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > On Wed, Nov 28, 2018 at 4:37 AM Sean Wang wrote: > > > > Weiyi Lu =E6=96=BC 2018=E5=B9=B411=E6=9C=8826= =E6=97=A5 =E9=80=B1=E4=B8=80 =E4=B8=8B=E5=8D=887:45=E5=AF=AB=E9=81=93=EF=BC= =9A > > > > > > From: Owen Chen > > > > > > PLLs with tuner_en bit, such as APLL1, need to disable > > > tuner_en before apply new frequency settings, or the new frequency > > > settings (pcw) will not be applied. > > > The tuner_en bit will be disabled during changing PLL rate > > > and be restored after new settings applied. > > > > It looks like a bug fix. If so, you should add a fixes tag and even cc > > stable tree > > > > > > > > Signed-off-by: Owen Chen > > > --- > > > drivers/clk/mediatek/clk-pll.c | 33 +++++++++++++++++++++++++++++++-= - > > > 1 file changed, 31 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/cl= k-pll.c > > > index 1db161aced31..81400601f107 100644 > > > --- a/drivers/clk/mediatek/clk-pll.c > > > +++ b/drivers/clk/mediatek/clk-pll.c > > > @@ -27,7 +27,7 @@ > > > #define CON0_BASE_EN BIT(0) > > > #define CON0_PWR_ON BIT(0) > > > #define CON0_ISO_EN BIT(1) > > > -#define CON0_PCW_CHG BIT(31) > > > +#define CON1_PCW_CHG BIT(31) > > > > it seems like an unnecessary change > > Below, you have: > con1 |=3D CON1_PCW_CHG; > > Presumably PCW_CHG is on BIT(31) of CON1(?), so I think this is a good > change. Maybe this needs to be a separate patch, though? > Sure, for me it's not easily understood why the change is necessary from the description. If it's really another fixup, it should be moved to a separate patch or add more explanations about that in the same patch. > > > > > > #define AUDPLL_TUNER_EN BIT(31) > > > > > > @@ -97,9 +97,31 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_p= ll *pll, u32 pcw, > > > { > > > u32 con1, val; > > > int pll_en; > > > + u32 tuner_en =3D 0; > > > + u32 tuner_en_mask; > > > + void __iomem *tuner_en_addr =3D NULL; > > > > > > pll_en =3D readl(pll->base_addr + REG_CON0) & CON0_BASE_EN; > > > > > > + /* disable tuner */ > > > > similar code pieces are ready on mtk_pll_[un]prepare. maybe we can add > > common tuner operations for them to reuse. > > > > > + if (pll->tuner_en_addr) { > > > + tuner_en_addr =3D pll->tuner_en_addr; > > > + tuner_en_mask =3D BIT(pll->data->tuner_en_bit); > > > + } else if (pll->tuner_addr) { > > > + tuner_en_addr =3D pll->tuner_addr; > > > + tuner_en_mask =3D AUDPLL_TUNER_EN; > > > + } > > > + > > > + if (tuner_en_addr) { > > > + val =3D readl(tuner_en_addr); > > > + tuner_en =3D val & tuner_en_mask; > > > + > > > + if (tuner_en) { > > > + val &=3D ~tuner_en_mask; > > > + writel(val, tuner_en_addr); > > > + } > > > + } > > > + > > > /* set postdiv */ > > > val =3D readl(pll->pd_addr); > > > val &=3D ~(POSTDIV_MASK << pll->data->pd_shift); > > > @@ -120,12 +142,19 @@ static void mtk_pll_set_rate_regs(struct mtk_cl= k_pll *pll, u32 pcw, > > > con1 =3D readl(pll->base_addr + REG_CON1); > > > > > > if (pll_en) > > > - con1 |=3D CON0_PCW_CHG; > > > + con1 |=3D CON1_PCW_CHG; > > > > > > writel(con1, pll->base_addr + REG_CON1); > > > if (pll->tuner_addr) > > > writel(con1 + 1, pll->tuner_addr); > > > > > > + /* restore tuner_en */ > > > + if (tuner_en_addr && tuner_en) { > > > > if (tuner_en) is sufficient > > > > > + val =3D readl(tuner_en_addr); > > > + val |=3D tuner_en_mask; > > > + writel(val, tuner_en_addr); > > > + } > > > + > > > if (pll_en) > > > udelay(20); > > > } > > > -- > > > 2.18.0 > > > > > > > > > _______________________________________________ > > > Linux-mediatek mailing list > > > Linux-mediatek@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek