Thread (42 messages) 42 messages, 7 authors, 2014-06-07

[RFC PATCH 2/5] clk: Introduce 'clk_round_rate_nearest()'

From: Sören Brinkmann <hidden>
Date: 2014-05-26 21:55:30
Also in: linux-pm, lkml

On Mon, 2014-05-26 at 01:47PM +0200, Rafael J. Wysocki wrote:
On Monday, May 26, 2014 04:37:13 PM Viresh Kumar wrote:
quoted
On 26 May 2014 16:52, Rafael J. Wysocki [off-list ref] wrote:
quoted
I agree as far as the 64-bit thing goes, but is switching to Hz really
necessary?
Don't really know that.. It seems that there will always be problems with
close enough frequencies whenever rounding is done.
Well, rounding errors are a problem, but question is if that is enough of
a problem to justify expanding the storage size twice.  Also, that'd be
a performance hit on 32-bit systems.
quoted
More can be elaborated by Soren.
OK
I'd say it's probably not worth switching. As you and I said, rounding
issues are likely to happen no matter what. In this particular case,
switching would not remove the need for the patch I proposed to allow
for rounding errors. The error margin could be reduced, but that's it.
I think it would be nice if CCF, OPP and cpufreq would use the same
resolution and types, since it would remove the need for all these
conversions that are going on in cpufreq drivers, but looking at the
wide usage of cpufreq and the potential drawbacks Rafael pointed at:
nice-to-have is probably not enough of a justification.

	S?ren
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help