Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753188AbeADT2Z convert rfc822-to-8bit (ORCPT + 1 other); Thu, 4 Jan 2018 14:28:25 -0500 Received: from mailoutvs3.siol.net ([213.250.19.136]:50934 "EHLO mail.siol.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751946AbeADT2X (ORCPT ); Thu, 4 Jan 2018 14:28:23 -0500 From: Jernej =?utf-8?B?xaBrcmFiZWM=?= To: Chen-Yu Tsai Cc: Maxime Ripard , David Airlie , Rob Herring , Mark Rutland , Archit Taneja , a.hajda@samsung.com, Laurent Pinchart , Mike Turquette , Stephen Boyd , Jose.Abreu@synopsys.com, Neil Armstrong , dri-devel , devicetree , linux-arm-kernel , linux-kernel , linux-clk , linux-sunxi Subject: Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls Date: Thu, 04 Jan 2018 20:28:16 +0100 Message-ID: <3625461.aU9oqMdpo3@jernej-laptop> In-Reply-To: References: <20171230210203.24115-1-jernej.skrabec@siol.net> <20171230210203.24115-2-jernej.skrabec@siol.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi, Dne četrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a): > On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec wrote: > > For example, A83T have nmp plls which are modelled as nkmp plls. Since k > > is not specified, it has offset 0, shift 0 and lowest value 1. This > > means that LSB bit is always set to 1, which may change clock rate. > > > > Fix that by applying k factor only if k width is greater than 0. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +++++++++++++-------- > > 1 file changed, 13 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c > > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3 100644 > > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c > > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c > > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw > > *hw,> > > unsigned long parent_rate) > > > > { > > > > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw); > > > > - unsigned long n, m, k, p; > > + unsigned long n, m, k = 1, p; > > > > u32 reg; > > > > reg = readl(nkmp->common.base + nkmp->common.reg); > > > > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct > > clk_hw *hw,> > > if (!n) > > > > n++; > > > > - k = reg >> nkmp->k.shift; > > - k &= (1 << nkmp->k.width) - 1; > > - k += nkmp->k.offset; > > - if (!k) > > - k++; > > + if (nkmp->k.width) { > > + k = reg >> nkmp->k.shift; > > + k &= (1 << nkmp->k.width) - 1; > > + k += nkmp->k.offset; > > + if (!k) > > + k++; > > + } > > The conditional shouldn't be necessary. With nkmp->k.width = 0, > you'd simply get k & 0, which is 0, which then gets bumped up to 1, > unless k.offset > 1, which would be a bug. > > > m = reg >> nkmp->m.shift; > > m &= (1 << nkmp->m.width) - 1; > > > > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, > > unsigned long rate,> > > reg = readl(nkmp->common.base + nkmp->common.reg); > > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift); > > > > - reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift); > > + if (nkmp->k.width) > > + reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, > > + nkmp->k.shift); > > > > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift); > > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift); > > > > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift; > > > > - reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift; > > + if (nkmp->k.width) > > + reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift; > > I think a better way would be > > reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) & > GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift); > > And do this for all the factors, not just k. This pattern is what > regmap_update_bits does, which seems much safer. I wonder what > GENMASK() with a negative value would do though... You're right, GENMASK(-1, 0) equals 0 (calculated by hand, not tested). This seems much more elegant solution. Semi-related question: All nmp PLLs have much wider N range than real nkmp PLLs. This causes integer overflow when using nkmp formula from datasheet. Usually, N is 1-256 for nmp PLLs, which means that for very high N factors, it overflows. This also causes issue that M factor is never higher than 1. I was wondering, if patch would be acceptable which would change this formula: RATE = (24MHz * N * K) / (M * P) to this: RATE ((24MHz / M) * N * K) / P I checked all M factors and are all in 1-4 or 1-2 range, which means it wouldn't have any impact for real nkmp PLLs when parent is 24 MHz clock which is probably always. What do you think? I discovered that when I tried to set A83T PLL_VIDEO to 346.5 MHz which is possible only when above formula is changed. Best regards, Jernej > > ChenYu > > > reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift; > > reg |= ilog2(_nkmp.p) << nkmp->p.shift; > > > > -- > > 2.15.1