[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cfceb49f-ffe9-4473-9877-ed92ab0ace1a@prevas.dk>
Date: Mon, 13 May 2024 13:49:10 +0200
From: Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To: "Peng Fan (OSS)" <peng.fan@....nxp.com>, Abel Vesa <abelvesa@...nel.org>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>, Jacky Bai <ping.bai@....com>,
Ye Li <ye.li@....com>, Dong Aisheng <aisheng.dong@....com>
Cc: linux-clk@...r.kernel.org, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Abel Vesa <abel.vesa@...aro.org>, Peng Fan <peng.fan@....com>,
Shengjiu Wang <shengjiu.wang@....com>
Subject: Re: [PATCH v2 06/17] clk: imx: pll14xx: use rate_table for audio plls
On 10/05/2024 11.19, Peng Fan (OSS) wrote:
> From: Shengjiu Wang <shengjiu.wang@....com>
>
> The generated clock frequency may not accurate, for example
> the expected rate is 361267200U, but result is 361267199U.
> Add rate_table for audio clocks to avoid such issue.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@....com>
> Reviewed-by: Jacky Bai <ping.bai@....com>
> Signed-off-by: Peng Fan <peng.fan@....com>
> ---
> drivers/clk/imx/clk-pll14xx.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
> index 55812bfb9ec2..6b2c849f8b71 100644
> --- a/drivers/clk/imx/clk-pll14xx.c
> +++ b/drivers/clk/imx/clk-pll14xx.c
> @@ -64,6 +64,17 @@ static const struct imx_pll14xx_rate_table imx_pll1443x_tbl[] = {
> PLL_1443X_RATE(650000000U, 325, 3, 2, 0),
> PLL_1443X_RATE(594000000U, 198, 2, 2, 0),
> PLL_1443X_RATE(519750000U, 173, 2, 2, 16384),
> + PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
> + PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
Sorry, what? This reintroduces the two entries that were removed in
72d00e560d10, claiming that this produces an exact output, whereas that
commit very clearly states (and it's easy to do the math and verify)
that those entries actually resulted in output values of 393215995 and
361267196. So even if the dynamic computation would result in 361267199
(it doesn't, it gives an exact output), that would still be better than
what these hard-coded entries achieve.
Rasmus
Powered by blists - more mailing lists