| Message ID | 1556585557-28795-1-git-send-email-Anson.Huang@nxp.com (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Commit | a048fe996b5109d3c94c243bb0733419fbd0ed8f |
| Headers | show |
| Series | [V2] clk: imx: pllv4: add fractional-N pll support | expand |
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:sboyd@kernel.org] > 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:sboyd@kernel.org] > Sent: Thursday, May 2, 2019 5:01 AM > To: festevam@gmail.com; kernel@pengutronix.de; linux-arm- > kernel@lists.infradead.org; linux-clk@vger.kernel.org; linux- > kernel@vger.kernel.org; mturquette@baylibre.com; > s.hauer@pengutronix.de; shawnguo@kernel.org; Aisheng Dong > <aisheng.dong@nxp.com>; Anson Huang <anson.huang@nxp.com> > Cc: dl-linux-imx <linux-imx@nxp.com> > 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 = Anson.Huang@nxp.com 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:sboyd@kernel.org] > > 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:sboyd@kernel.org] > > 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:sboyd@kernel.org] > 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:sboyd@kernel.org] > > > 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
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; }
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 <Anson.Huang@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> --- drivers/clk/imx/clk-pllv4.c | 72 +++++++++++++++++++++++++++++++++++++++------ 1 file changed, 63 insertions(+), 9 deletions(-)