The pllv4 supports fractional-N function, the formula is:
PLL output freq = input * (mult + num/denom),
This patch adds fractional-N function support, including
clock round rate, calculate rate and set rate, with this
patch, the clock rate of APLL in clock tree is more accurate
than before:
Without fraction:
apll_pre_sel 1 1 1 24000000 0 0 50000
apll_pre_div 1 1 2 24000000 0 0 50000
apll 1 1 2 528000000 0 0 50000
apll_pfd3 0 0 0 792000000 0 0 50000
apll_pfd2 0 0 0 339428571 0 0 50000
apll_pfd1 0 0 0 352000000 0 0 50000
usdhc0 0 0 0 352000000 0 0 50000
apll_pfd0 1 1 1 352000000 0 0 50000
With fraction:
apll_pre_sel 1 1 1 24000000 0 0 50000
apll_pre_div 1 1 2 24000000 0 0 50000
apll 1 1 2 529200000 0 0 50000
apll_pfd3 0 0 0 793800000 0 0 50000
apll_pfd2 0 0 0 340200000 0 0 50000
apll_pfd1 0 0 0 352800000 0 0 50000
usdhc0 0 0 0 352800000 0 0 50000
apll_pfd0 1 1 1 352800000 0 0 50000
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
---
drivers/clk/imx/clk-pllv4.c | 72 +++++++++++++++++++++++++++++++++++++++------
1 file changed, 63 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/imx/clk-pllv4.c b/drivers/clk/imx/clk-pllv4.c
index d38bc9f..d7e62c3 100644
--- a/drivers/clk/imx/clk-pllv4.c
+++ b/drivers/clk/imx/clk-pllv4.c
@@ -30,6 +30,9 @@
/* PLL Denominator Register (xPLLDENOM) */
#define PLL_DENOM_OFFSET 0x14
+#define MAX_MFD 0x3fffffff
+#define DEFAULT_MFD 1000000
+
struct clk_pllv4 {
struct clk_hw hw;
void __iomem *base;
@@ -64,13 +67,20 @@ static unsigned long clk_pllv4_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
struct clk_pllv4 *pll = to_clk_pllv4(hw);
- u32 div;
+ u32 mult, mfn, mfd;
+ u64 temp64;
+
+ mult = readl_relaxed(pll->base + PLL_CFG_OFFSET);
+ mult &= BM_PLL_MULT;
+ mult >>= BP_PLL_MULT;
- div = readl_relaxed(pll->base + PLL_CFG_OFFSET);
- div &= BM_PLL_MULT;
- div >>= BP_PLL_MULT;
+ mfn = readl_relaxed(pll->base + PLL_NUM_OFFSET);
+ mfd = readl_relaxed(pll->base + PLL_DENOM_OFFSET);
+ temp64 = parent_rate;
+ temp64 *= mfn;
+ do_div(temp64, mfd);
- return parent_rate * div;
+ return (parent_rate * mult) + (u32)temp64;
}
static long clk_pllv4_round_rate(struct clk_hw *hw, unsigned long rate,
@@ -78,14 +88,46 @@ static long clk_pllv4_round_rate(struct clk_hw *hw, unsigned long rate,
{
unsigned long parent_rate = *prate;
unsigned long round_rate, i;
+ u32 mfn, mfd = DEFAULT_MFD;
+ bool found = false;
+ u64 temp64;
for (i = 0; i < ARRAY_SIZE(pllv4_mult_table); i++) {
round_rate = parent_rate * pllv4_mult_table[i];
- if (rate >= round_rate)
- return round_rate;
+ if (rate >= round_rate) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found) {
+ pr_warn("%s: unable to round rate %lu, parent rate %lu\n",
+ clk_hw_get_name(hw), rate, parent_rate);
+ return 0;
}
- return round_rate;
+ if (parent_rate <= MAX_MFD)
+ mfd = parent_rate;
+
+ temp64 = (u64)(rate - round_rate);
+ temp64 *= mfd;
+ do_div(temp64, parent_rate);
+ mfn = temp64;
+
+ /*
+ * NOTE: The value of numerator must always be configured to be
+ * less than the value of the denominator. If we can't get a proper
+ * pair of mfn/mfd, we simply return the round_rate without using
+ * the frac part.
+ */
+ if (mfn >= mfd)
+ return round_rate;
+
+ temp64 = (u64)parent_rate;
+ temp64 *= mfn;
+ do_div(temp64, mfd);
+
+ return round_rate + (u32)temp64;
}
static bool clk_pllv4_is_valid_mult(unsigned int mult)
@@ -105,18 +147,30 @@ static int clk_pllv4_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
struct clk_pllv4 *pll = to_clk_pllv4(hw);
- u32 val, mult;
+ u32 val, mult, mfn, mfd = DEFAULT_MFD;
+ u64 temp64;
mult = rate / parent_rate;
if (!clk_pllv4_is_valid_mult(mult))
return -EINVAL;
+ if (parent_rate <= MAX_MFD)
+ mfd = parent_rate;
+
+ temp64 = (u64)(rate - mult * parent_rate);
+ temp64 *= mfd;
+ do_div(temp64, parent_rate);
+ mfn = temp64;
+
val = readl_relaxed(pll->base + PLL_CFG_OFFSET);
val &= ~BM_PLL_MULT;
val |= mult << BP_PLL_MULT;
writel_relaxed(val, pll->base + PLL_CFG_OFFSET);
+ writel_relaxed(mfn, pll->base + PLL_NUM_OFFSET);
+ writel_relaxed(mfd, pll->base + PLL_DENOM_OFFSET);
+
return 0;
}
--
2.7.4
The Content-transfer-encoding header is still base64. I guess it can't
be fixed.
Quoting Anson Huang (2019-04-29 17:57:22)
> The pllv4 supports fractional-N function, the formula is:
>
> PLL output freq = input * (mult + num/denom),
>
> This patch adds fractional-N function support, including
> clock round rate, calculate rate and set rate, with this
> patch, the clock rate of APLL in clock tree is more accurate
> than before:
>
> From: Stephen Boyd [mailto:[email protected]]
> Sent: Thursday, May 2, 2019 5:01 AM
>
> The Content-transfer-encoding header is still base64. I guess it can't be fixed.
>
How can we know it's base64?
As I saw from the 'Headers' in patchwork, it's:
"Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit"
https://patchwork.kernel.org/patch/10922657/
We'd like to fix it this.
Regards
Dong Aisheng
> Quoting Anson Huang (2019-04-29 17:57:22)
> > The pllv4 supports fractional-N function, the formula is:
> >
> > PLL output freq = input * (mult + num/denom),
> >
> > This patch adds fractional-N function support, including clock round
> > rate, calculate rate and set rate, with this patch, the clock rate of
> > APLL in clock tree is more accurate than before:
> >
Hi, Stephen
> -----Original Message-----
> From: Stephen Boyd [mailto:[email protected]]
> Sent: Thursday, May 2, 2019 5:01 AM
> To: [email protected]; [email protected]; linux-arm-
> [email protected]; [email protected]; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; Aisheng Dong
> <[email protected]>; Anson Huang <[email protected]>
> Cc: dl-linux-imx <[email protected]>
> Subject: Re: [PATCH V2] clk: imx: pllv4: add fractional-N pll support
>
> The Content-transfer-encoding header is still base64. I guess it can't be fixed.
Below is my git sendmail configuration, the encoding is set to UTF-8, I don't know
why it is still base64, let me know if you know how to fix it, thanks. And, will you still
review this patch?
Anson.
6 [sendemail]
7 smtpserver = outlook.office365.com
8 smtpencryption = tls
9 smtpuser = [email protected]
10 smtpserverport = 587
11 confirm = never
12 assume8bitEncoding = UTF-8
>
> Quoting Anson Huang (2019-04-29 17:57:22)
> > The pllv4 supports fractional-N function, the formula is:
> >
> > PLL output freq = input * (mult + num/denom),
> >
> > This patch adds fractional-N function support, including clock round
> > rate, calculate rate and set rate, with this patch, the clock rate of
> > APLL in clock tree is more accurate than before:
> >
Quoting Aisheng Dong (2019-05-02 19:38:34)
> > From: Stephen Boyd [mailto:[email protected]]
> > Sent: Thursday, May 2, 2019 5:01 AM
> >
> > The Content-transfer-encoding header is still base64. I guess it can't be fixed.
> >
>
> How can we know it's base64?
> As I saw from the 'Headers' in patchwork, it's:
> "Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit"
> https://patchwork.kernel.org/patch/10922657/
>
> We'd like to fix it this.
>
I see:
Content-Type text/plain; charset="utf-8"
Content-Transfer-Encoding base64
Maybe that's because I'm getting the mail directly instead of from the
mailing list?
Quoting Aisheng Dong (2019-05-02 19:38:34)
> > From: Stephen Boyd [mailto:[email protected]]
> > Sent: Thursday, May 2, 2019 5:01 AM
> >
> > The Content-transfer-encoding header is still base64. I guess it can't be fixed.
> >
>
> How can we know it's base64?
> As I saw from the 'Headers' in patchwork, it's:
> "Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit"
> https://patchwork.kernel.org/patch/10922657/
>
> We'd like to fix it this.
>
Also, if you look at the one for linux-clk mailing list you'll see
base64 CTE: https://patchwork.kernel.org/patch/10921115/
> From: Stephen Boyd [mailto:[email protected]]
> Sent: Saturday, May 4, 2019 12:01 AM
> Subject: RE: [PATCH V2] clk: imx: pllv4: add fractional-N pll support
>
> Quoting Aisheng Dong (2019-05-02 19:38:34)
> > > From: Stephen Boyd [mailto:[email protected]]
> > > Sent: Thursday, May 2, 2019 5:01 AM
> > >
> > > The Content-transfer-encoding header is still base64. I guess it can't be
> fixed.
> > >
> > How can we know it's base64?
> > As I saw from the 'Headers' in patchwork, it's:
> > "Content-Type: text/plain; charset="us-ascii"
> > Content-Transfer-Encoding: 7bit"
> >
> > https://patchwork.kernel.org/patch/10922657/
> >
> > We'd like to fix it this.
> >
>
> Also, if you look at the one for linux-clk mailing list you'll see
> base64 CTE:
> https://patchwork.kernel.org/patch/10921115/
We suspect it's our server configuration issue.
I've already submitted a ticket for our IT department to check.
BTW, for why we did not see base64 encoding from arm Linux maillist,
Not sure if it's automatically converted to 8bit encoding by arm-linux
maillist patchwork.
Regards
Dong Aisheng