From: Stephen Boyd <sboyd@codeaurora.org>
To: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: Chunyan Zhang <chunyan.zhang@spreadtrum.com>,
Michael Turquette <mturquette@baylibre.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-clk <linux-clk@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Arnd Bergmann <arnd@arndb.de>, Mark Brown <broonie@kernel.org>,
Xiaolong Zhang <xiaolong.zhang@spreadtrum.com>,
Orson Zhai <orson.zhai@spreadtrum.com>,
Geng Ren <geng.ren@spreadtrum.com>,
Ben Li <ben.li@spreadtrum.com>
Subject: Re: [PATCH V1 7/9] clk: sprd: add adjustable pll support
Date: Fri, 30 Jun 2017 12:22:28 -0700 [thread overview]
Message-ID: <20170630192228.GO22780@codeaurora.org> (raw)
In-Reply-To: <CAAfSe-smKqgd42jDAGDA=NtYvRZExNanU7fHrRkT4W-WH-2=ug@mail.gmail.com>
On 06/30, Chunyan Zhang wrote:
> Hi Stephen,
>
> On 30 June 2017 at 09:44, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 06/22, Chunyan Zhang wrote:
> >> On 20 June 2017 at 09:37, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >> > On 06/18, Chunyan Zhang wrote:
> >> >> + pll->factors[member].width
> >> >> +
> >> >> +#define pmask(pll, member) \
> >> >> + ((pwidth(pll, member)) ? \
> >> >> + GENMASK(pwidth(pll, member) + pshift(pll, member) - 1, \
> >> >> + pshift(pll, member)) : 0)
> >> >> +
> >> >> +#define pinternal(pll, cfg, member) \
> >> >> + (cfg[pindex(pll, member)] & pmask(pll, member))
> >> >> +
> >> >> +#define pinternal_val(pll, cfg, member) \
> >> >> + (pinternal(pll, cfg, member) >> pshift(pll, member))
> >> >> +
> >> >> +static unsigned long pll_get_refin_rate(struct ccu_pll *pll)
> >> >
> >> > pll could be const?
> >>
> >> What this function returns is a factor used to calculate the pll rate
> >> later, I will rename this function in the next iterator.
> >>
> >
> > Rename is fine, but pll can still be marked const?
>
> Oh, sorry I misunderstood :)
> You mean mark the input parameter "pll" const, right?
Yes.
> >> >> +
> >> >> +static int ccu_pll_helper_set_rate(struct ccu_pll *pll,
> >> >> + unsigned long rate,
> >> >> + unsigned long parent_rate)
> >> >> +{
> >> >> + u32 mask, shift, width, ibias_val, index, kint, nint;
> >> >> + u32 reg_num = pll->regs[0], i = 0;
> >> >> + unsigned long refin, fvco = rate;
> >> >> + struct reg_cfg *cfg;
> >> >> +
> >> >> + cfg = kcalloc(reg_num, sizeof(*cfg), GFP_KERNEL);
> >> >> + if (!cfg)
> >> >> + return -ENOMEM;
> >> >> +
> >> >> + refin = pll_get_refin_rate(pll);
> >> >> +
> >> >> + mask = pmask(pll, PLL_PREDIV);
> >> >> + index = pindex(pll, PLL_PREDIV);
> >> >> + width = pwidth(pll, PLL_PREDIV);
> >> >> + if (width && (ccu_pll_readl(pll, index) & mask))
> >> >> + refin = refin * 2;
> >> >> +
> >> >> + mask = pmask(pll, PLL_POSTDIV);
> >> >> + index = pindex(pll, PLL_POSTDIV);
> >> >> + width = pwidth(pll, PLL_POSTDIV);
> >> >> + cfg[index].msk = mask;
> >> >> + if (width && ((pll->fflag == 1 && fvco <= pll->fvco) ||
> >> >> + (pll->fflag == 0 && fvco > pll->fvco)))
> >> >> + cfg[index].val |= mask;
> >> >> +
> >> >> + if (width && fvco <= pll->fvco)
> >> >> + fvco = fvco * 2;
> >> >> +
> >> >> + mask = pmask(pll, PLL_DIV_S);
> >> >> + index = pindex(pll, PLL_DIV_S);
> >> >> + cfg[index].val |= mask;
> >> >> + cfg[index].msk |= mask;
> >> >> +
> >> >> + mask = pmask(pll, PLL_SDM_EN);
> >> >> + index = pindex(pll, PLL_SDM_EN);
> >> >> + cfg[index].val |= mask;
> >> >> + cfg[index].msk |= mask;
> >> >> +
> >> >> + nint = fvco/(refin * CCU_PLL_1M);
> >> >> +
> >> >> + mask = pmask(pll, PLL_NINT);
> >> >> + index = pindex(pll, PLL_NINT);
> >> >> + shift = pshift(pll, PLL_NINT);
> >> >> + cfg[index].val |= (nint << shift) & mask;
> >> >> + cfg[index].msk |= mask;
> >> >> +
> >> >> + mask = pmask(pll, PLL_KINT);
> >> >> + index = pindex(pll, PLL_KINT);
> >> >> + width = pwidth(pll, PLL_KINT);
> >> >> + shift = pshift(pll, PLL_KINT);
> >> >> +#ifndef CONFIG_64BIT
> >> >> + i = width < 21 ? 0 : i - 21;
> >> >> +#endif
> >> >
> >> > What's this? Why do we depend on CONFIG_64BIT?
> >>
> >> On 32-bit SoCs, the largest width we can support is limited due to the
> >> limitation of calculation precision.
> >
> > Does the hardware width change? Still not clear to me what's
> > going on here.
>
> I heard from my colleague, that because the calculation precision on
> Spreadtrum's 32-bit SoCs is different from on 64-bit SoCs, when the
> width of the value of PLL_KINT is larger than 21, the value is too
> large to be multiplied on 32-bit Spreadtrum's SoCs.
It sounds like you're saying that the clk hardware is not
changing, but the sizeof(long) is different on 64-bit and 32-bit
CPUs so you've added this ifndef here for that.
>
> i = width < 21 ? 0 : i - 21;
>
> Here ' i ' is used to adjust 'shift' rather than 'width' like below (
> wrote the code back for convenience of understanding)
>
> + kint = DIV_ROUND_CLOSEST(((fvco - refin * nint * CCU_PLL_1M)/10000) *
> + ((mask >> (shift + i)) + 1), refin * 100) << i;
>
Having the types for all these variables would also be helpful.
u32 mask, shift, width, kint, nint;
unsigned long refin, fvco;
Why don't we do 64-bit math here instead of 32-bit math? And use
DIV_ROUND_CLOSEST_ULL?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V1 7/9] clk: sprd: add adjustable pll support
Date: Fri, 30 Jun 2017 12:22:28 -0700 [thread overview]
Message-ID: <20170630192228.GO22780@codeaurora.org> (raw)
In-Reply-To: <CAAfSe-smKqgd42jDAGDA=NtYvRZExNanU7fHrRkT4W-WH-2=ug@mail.gmail.com>
On 06/30, Chunyan Zhang wrote:
> Hi Stephen,
>
> On 30 June 2017 at 09:44, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 06/22, Chunyan Zhang wrote:
> >> On 20 June 2017 at 09:37, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >> > On 06/18, Chunyan Zhang wrote:
> >> >> + pll->factors[member].width
> >> >> +
> >> >> +#define pmask(pll, member) \
> >> >> + ((pwidth(pll, member)) ? \
> >> >> + GENMASK(pwidth(pll, member) + pshift(pll, member) - 1, \
> >> >> + pshift(pll, member)) : 0)
> >> >> +
> >> >> +#define pinternal(pll, cfg, member) \
> >> >> + (cfg[pindex(pll, member)] & pmask(pll, member))
> >> >> +
> >> >> +#define pinternal_val(pll, cfg, member) \
> >> >> + (pinternal(pll, cfg, member) >> pshift(pll, member))
> >> >> +
> >> >> +static unsigned long pll_get_refin_rate(struct ccu_pll *pll)
> >> >
> >> > pll could be const?
> >>
> >> What this function returns is a factor used to calculate the pll rate
> >> later, I will rename this function in the next iterator.
> >>
> >
> > Rename is fine, but pll can still be marked const?
>
> Oh, sorry I misunderstood :)
> You mean mark the input parameter "pll" const, right?
Yes.
> >> >> +
> >> >> +static int ccu_pll_helper_set_rate(struct ccu_pll *pll,
> >> >> + unsigned long rate,
> >> >> + unsigned long parent_rate)
> >> >> +{
> >> >> + u32 mask, shift, width, ibias_val, index, kint, nint;
> >> >> + u32 reg_num = pll->regs[0], i = 0;
> >> >> + unsigned long refin, fvco = rate;
> >> >> + struct reg_cfg *cfg;
> >> >> +
> >> >> + cfg = kcalloc(reg_num, sizeof(*cfg), GFP_KERNEL);
> >> >> + if (!cfg)
> >> >> + return -ENOMEM;
> >> >> +
> >> >> + refin = pll_get_refin_rate(pll);
> >> >> +
> >> >> + mask = pmask(pll, PLL_PREDIV);
> >> >> + index = pindex(pll, PLL_PREDIV);
> >> >> + width = pwidth(pll, PLL_PREDIV);
> >> >> + if (width && (ccu_pll_readl(pll, index) & mask))
> >> >> + refin = refin * 2;
> >> >> +
> >> >> + mask = pmask(pll, PLL_POSTDIV);
> >> >> + index = pindex(pll, PLL_POSTDIV);
> >> >> + width = pwidth(pll, PLL_POSTDIV);
> >> >> + cfg[index].msk = mask;
> >> >> + if (width && ((pll->fflag == 1 && fvco <= pll->fvco) ||
> >> >> + (pll->fflag == 0 && fvco > pll->fvco)))
> >> >> + cfg[index].val |= mask;
> >> >> +
> >> >> + if (width && fvco <= pll->fvco)
> >> >> + fvco = fvco * 2;
> >> >> +
> >> >> + mask = pmask(pll, PLL_DIV_S);
> >> >> + index = pindex(pll, PLL_DIV_S);
> >> >> + cfg[index].val |= mask;
> >> >> + cfg[index].msk |= mask;
> >> >> +
> >> >> + mask = pmask(pll, PLL_SDM_EN);
> >> >> + index = pindex(pll, PLL_SDM_EN);
> >> >> + cfg[index].val |= mask;
> >> >> + cfg[index].msk |= mask;
> >> >> +
> >> >> + nint = fvco/(refin * CCU_PLL_1M);
> >> >> +
> >> >> + mask = pmask(pll, PLL_NINT);
> >> >> + index = pindex(pll, PLL_NINT);
> >> >> + shift = pshift(pll, PLL_NINT);
> >> >> + cfg[index].val |= (nint << shift) & mask;
> >> >> + cfg[index].msk |= mask;
> >> >> +
> >> >> + mask = pmask(pll, PLL_KINT);
> >> >> + index = pindex(pll, PLL_KINT);
> >> >> + width = pwidth(pll, PLL_KINT);
> >> >> + shift = pshift(pll, PLL_KINT);
> >> >> +#ifndef CONFIG_64BIT
> >> >> + i = width < 21 ? 0 : i - 21;
> >> >> +#endif
> >> >
> >> > What's this? Why do we depend on CONFIG_64BIT?
> >>
> >> On 32-bit SoCs, the largest width we can support is limited due to the
> >> limitation of calculation precision.
> >
> > Does the hardware width change? Still not clear to me what's
> > going on here.
>
> I heard from my colleague, that because the calculation precision on
> Spreadtrum's 32-bit SoCs is different from on 64-bit SoCs, when the
> width of the value of PLL_KINT is larger than 21, the value is too
> large to be multiplied on 32-bit Spreadtrum's SoCs.
It sounds like you're saying that the clk hardware is not
changing, but the sizeof(long) is different on 64-bit and 32-bit
CPUs so you've added this ifndef here for that.
>
> i = width < 21 ? 0 : i - 21;
>
> Here ' i ' is used to adjust 'shift' rather than 'width' like below (
> wrote the code back for convenience of understanding)
>
> + kint = DIV_ROUND_CLOSEST(((fvco - refin * nint * CCU_PLL_1M)/10000) *
> + ((mask >> (shift + i)) + 1), refin * 100) << i;
>
Having the types for all these variables would also be helpful.
u32 mask, shift, width, kint, nint;
unsigned long refin, fvco;
Why don't we do 64-bit math here instead of 32-bit math? And use
DIV_ROUND_CLOSEST_ULL?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2017-06-30 19:22 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-18 1:58 [PATCH V1 0/9] add clock driver for Spreadtrum platforms Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` [PATCH V1 1/9] dt-bindings: Add Spreadtrum CCU binding documentation Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-23 20:05 ` Rob Herring
2017-06-23 20:05 ` Rob Herring
2017-06-18 1:58 ` [PATCH V1 2/9] clk: sprd: Add common infrastructure Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-20 1:29 ` Stephen Boyd
2017-06-20 1:29 ` Stephen Boyd
2017-06-22 10:12 ` Chunyan Zhang
2017-06-22 10:12 ` Chunyan Zhang
2017-06-18 1:58 ` [PATCH V1 3/9] clk: sprd: add gate clock support Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-20 1:31 ` Stephen Boyd
2017-06-20 1:31 ` Stephen Boyd
2017-06-20 1:31 ` Stephen Boyd
2017-06-22 10:16 ` Chunyan Zhang
2017-06-22 10:16 ` Chunyan Zhang
2017-06-30 1:43 ` Stephen Boyd
2017-06-30 1:43 ` Stephen Boyd
2017-06-30 1:43 ` Stephen Boyd
2017-06-18 1:58 ` [PATCH V1 4/9] clk: sprd: add mux " Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` [PATCH V1 5/9] clk: sprd: add divider " Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` [PATCH V1 6/9] clk: sprd: add composite " Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-19 0:13 ` kbuild test robot
2017-06-19 0:13 ` kbuild test robot
2017-06-19 0:13 ` kbuild test robot
2017-06-18 1:58 ` [PATCH V1 7/9] clk: sprd: add adjustable pll support Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-20 1:37 ` Stephen Boyd
2017-06-20 1:37 ` Stephen Boyd
2017-06-22 10:17 ` Chunyan Zhang
2017-06-22 10:17 ` Chunyan Zhang
2017-06-22 10:17 ` Chunyan Zhang
2017-06-22 11:15 ` Arnd Bergmann
2017-06-22 11:15 ` Arnd Bergmann
2017-06-22 12:06 ` Chunyan Zhang
2017-06-22 12:06 ` Chunyan Zhang
2017-06-30 1:44 ` Stephen Boyd
2017-06-30 1:44 ` Stephen Boyd
2017-06-30 1:44 ` Stephen Boyd
2017-06-30 7:55 ` Chunyan Zhang
2017-06-30 7:55 ` Chunyan Zhang
2017-06-30 19:22 ` Stephen Boyd [this message]
2017-06-30 19:22 ` Stephen Boyd
2017-07-03 7:41 ` Chunyan Zhang
2017-07-03 7:41 ` Chunyan Zhang
2017-07-03 7:41 ` Chunyan Zhang
2017-06-18 1:58 ` [PATCH V1 8/9] clk: sprd: add clocks support for SC9860 Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-20 1:41 ` Stephen Boyd
2017-06-20 1:41 ` Stephen Boyd
2017-06-20 1:41 ` Stephen Boyd
2017-06-22 10:21 ` Chunyan Zhang
2017-06-22 10:21 ` Chunyan Zhang
2017-06-30 1:41 ` Stephen Boyd
2017-06-30 1:41 ` Stephen Boyd
2017-06-30 1:41 ` Stephen Boyd
2017-06-18 1:58 ` [PATCH V1 9/9] arm64: dts: add ccu " Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-18 1:58 ` Chunyan Zhang
2017-06-20 1:24 ` Stephen Boyd
2017-06-20 1:24 ` Stephen Boyd
2017-06-22 10:24 ` Chunyan Zhang
2017-06-22 10:24 ` Chunyan Zhang
2017-06-22 10:24 ` Chunyan Zhang
2017-06-30 0:57 ` Stephen Boyd
2017-06-30 0:57 ` Stephen Boyd
2017-06-30 7:37 ` Chunyan Zhang
2017-06-30 7:37 ` Chunyan Zhang
2017-06-20 1:25 ` [PATCH V1 0/9] add clock driver for Spreadtrum platforms Stephen Boyd
2017-06-20 1:25 ` Stephen Boyd
2017-06-22 10:07 ` Chunyan Zhang
2017-06-22 10:07 ` Chunyan Zhang
2017-06-30 0:45 ` Stephen Boyd
2017-06-30 0:45 ` Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170630192228.GO22780@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=arnd@arndb.de \
--cc=ben.li@spreadtrum.com \
--cc=broonie@kernel.org \
--cc=chunyan.zhang@spreadtrum.com \
--cc=devicetree@vger.kernel.org \
--cc=geng.ren@spreadtrum.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mturquette@baylibre.com \
--cc=orson.zhai@spreadtrum.com \
--cc=robh+dt@kernel.org \
--cc=xiaolong.zhang@spreadtrum.com \
--cc=zhang.lyra@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.