Architecture specific implementations for tickless kernel and deferrable timers

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 10:59:01PM +0530, Vikram Narayanan wrote:
> On Thu, Apr 28, 2011 at 7:58 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > What basically happens is:
> >
> >        now = cs->read(cs);
> >        delta = (now - cs->cycle_last) & cs->mask;
> >        cs->cycle_last = now;
> >
> >        ns = clocksource_cyc2ns(delta, cs...);
> >
> > ns now represents the amount of time which passed between this read and
> > the previous read.  Note the mask in the calculation of delta ensures
> > that overflows are taken care of.
> 
> The timekeeping_get_ns() in kernel/time/timekeeping.c takes care of the above.
> So my job is to provide a good *continuous* clocksource with correct
> mult,shift and mask values.
> And also, the mult and shift values can be calculated from the
> clocks_calc_mult_shift() function.

For clocksources, please, no, don't use clocks_calc_mult_shift().  There
is clocksource_register_hz() and clocksource_register_khz() which will
sort out the shift and multiplier automatically for you.

> The define HZ is important only for one-shot mode. and for a tickless
> kernel this value is not of great importance.

ITYM periodic mode.

> And also if I use the same timer for clocksource and clockevent, it
> will surely gonna mess up my system's time sooner or latter.

Indeed it will.

> > When you're called to switch to one-shot mode, program it for one-shot
> > mode, disable it, and wait for set_next_event().  On set_next_event(),
> > you program the timer to produce an interrupt after the specified
> > interval and enable it.
>
> For the clockevent device, If I provide all the data structures,
> next_event and set_mode, then this will work perfectly.
> 
> Hope I have understood your explanations in the right way and all my
> above statements make sense.

I think so.