Architecture specific implementations for tickless kernel and deferrable timers

[vikram186@gmail.com (Vikram Narayanan)]

On Thu, Apr 28, 2011 at 11:54 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> 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@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.
Ok. I will use this.
>
>> 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.
Yes. in periodic mode. I mistyped it.
>
>> 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.
Can you also give some idea on how the system's RTC is hooked up with
the generic timekeeping code.
Is it hooked up in someway so that the walltime is calculated wrt the
initial value of the RTC?
>
>> > 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.
>
Thanks for your detailed explanations.
Will update this thread if I have more doubts on this.

Thanks,
Vikram