Re: [PATCH 7/9] net: ethernet: ti: cpts: calc mult and shift from refclk freq
flat view
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: 2016-09-14 20:52:09
Also in:
linux-omap, lkml
On 09/14/2016 11:26 PM, Richard Cochran wrote:
On Wed, Sep 14, 2016 at 04:02:29PM +0300, Grygorii Strashko wrote:quoted
+static void cpts_calc_mult_shift(struct cpts *cpts) +{ + u64 maxsec; + u32 freq; + u32 mult; + u32 shift; + u64 ns; + u64 frac; + + if (cpts->cc_mult || cpts->cc.shift) + return; + + freq = clk_get_rate(cpts->refclk); + + /* Calc the maximum number of seconds which we can run before + * wrapping around. + */ + maxsec = cpts->cc.mask; + do_div(maxsec, freq); + if (!maxsec) + maxsec = 1;This doesn't pass the smell test. If the max counter value is M, you are figuring M*1/F which is the time in seconds corresponding to M. We set M=2^32-1, and so 'freq' would have to be greater than 4 GHz in order for 'maxsec' to be zero. Do you really expect such high frequency input clocks?
no. can drop it.
quoted
+ else if (maxsec > 600 && cpts->cc.mask > UINT_MAX) + maxsec = 600;What is this all about? cc.mask is always 2^32 - 1.
Oh. Not sure if we will update CPTS to support this, but on KS2 E/L (66AK2E) CPTS counter can work in 64bit mode.
quoted
+ clocks_calc_mult_shift(&mult, &shift, freq, NSEC_PER_SEC, maxsec); + + cpts->cc_mult = mult; + cpts->cc.mult = mult;In order to get good resolution on the frequency adjustment, we want to keep 'mult' as large as possible. I don't see your code doing this. We can rely on the watchdog reader (work queue) to prevent overflows.
As I understand (and tested), clocks_calc_mult_shift() will return max possible mult which can be used without overflow. if calculated results do not satisfy end user - the custom values can be passed in DT. -- regards, -grygorii