Thomas, On 5/12/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Well, it ends up in hrtimer_interrupt() and the code there finds out, that the next timer is not due right now, so it simply requests the same (absolute) time event again, which is processed by the clock events code and eventually limited to the max delta of the device again.
My timer is finally using the clockevent subsystem. Below is the output of '/proc/timer_list': cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 64696544360531 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1179151153000000000 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: <c03fde10>, tick_sched_timer, S:01 # expires at 64696546875000 nsecs [in 2514469 nsecs] .expires_next : 64696546875000 nsecs .hres_active : 1 .nr_events : 16562163 .nohz_mode : 0 .idle_tick : 0 nsecs .tick_stopped : 0 .idle_jiffies : 0 .idle_calls : 0 .idle_sleeps : 0 .idle_entrytime : 0 nsecs .idle_sleeptime : 0 nsecs .last_jiffies : 0 .next_jiffies : 0 .idle_expires : 0 nsecs jiffies: 16485515 Tick Device: mode: 1 Clock Event Device: hrt max_delta_ns: 2147483647 min_delta_ns: 1000 mult: 206158430 shift: 32 mode: 3 next_event: 64696546875000 nsecs set_next_event: hrt_next_event set_mode: hrt_timer_setup event_handler: hrtimer_interrupt My question is about the clock resolution field which is equal to 1ns. How is this possible since my timer's frequency is only 100Mhz ? My 2 cents, it looks like some tabs are missing when printing the list of hrtimers of each clock... Thanks -- Francis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
