Shifts for clocksources and clockevents

Shifts for clocksources and clockevents

[Linus Walleij]

I asked this on the ARM Linux mailing list a while back, but
it appears noone there really has a clue. (Or they didn't see
it.)

Can someone give me a rationale behind the values assigned to
the .shift field in clock_event_device and clocksource in the current
ARM platforms?

When I read the documentation in Documentation/hrtimers/highres.txt
it points me to the PDF
http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf
from which I get the impression that shift shall be assigned so
that

(time in ns for 1 cycle)
--------------------------     = 1
           shift
         2

So for a timer running cycles at 1MHz shift would be something like
10 so that 1000/1024 ~= 1.

However the current assignments doesn't look like that at all. I get
the impression that .shift for clock_event_device seem to be set
to 32 at all times in order to blow 32bit counters up to 64 bit,
and clocksource .shift is set to something like 18, 20 or 24 for
unclear reasons.

Any hints here?

Yours,
Linus Walleij

Re: Shifts for clocksources and clockevents

[john stultz]

On Tue, May 27, 2008 at 7:54 AM, Linus Walleij
<linus.ml.walleij@gmail.com> wrote:
> I asked this on the ARM Linux mailing list a while back, but
> it appears noone there really has a clue. (Or they didn't see
> it.)
>
> Can someone give me a rationale behind the values assigned to
> the .shift field in clock_event_device and clocksource in the current
> ARM platforms?
>
> When I read the documentation in Documentation/hrtimers/highres.txt
> it points me to the PDF
> http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf
> from which I get the impression that shift shall be assigned so
> that
>
> (time in ns for 1 cycle)
> --------------------------     = 1
>           shift
>         2
>
> So for a timer running cycles at 1MHz shift would be something like
> 10 so that 1000/1024 ~= 1.
>
> However the current assignments doesn't look like that at all. I get
> the impression that .shift for clock_event_device seem to be set
> to 32 at all times in order to blow 32bit counters up to 64 bit,
> and clocksource .shift is set to something like 18, 20 or 24 for
> unclear reasons.
>
> Any hints here?

The goal is to have the highest shift-value possible (providing
improved slewing accuracy for ntp), while not overflowing on the
multiply if the cycles are not accumulated over an extended period of
time (usually 2-5 seconds).

See the comments in kernel/time/jiffies.c for an example.

thanks
-john