Hi,
I'm trying to use clocksource and clockevent new subsystem. My
platform has a timer that I'd like to use both as a clocksource and a
clockevent devices. This timer is continueous in sense that it can run
without any interruption so I assume I can flag the clocksource device
with "CLOCK_SOURCE_IS_CONTINUOUS". However I noticed that clockevent
device can be stopped by using "set_mode()" method. Are these two
behaviours compatible ?
Another question is that I have another embedded 16 bits timer that I
would like to use. Since the timer is only 16 bits, the maximum
interval is tiny, My question if a user ask for a clockevent device
using an interval is bigger that 2^16, the clockevent system doesn't
return an error. Instead it silently reduce the interval to 2^16. Is
this correct ? if so why ?
Thanks for your answers
--
Francis
Francis,
On Sat, 2007-05-12 at 16:54 +0200, Francis Moreau wrote:
> I'm trying to use clocksource and clockevent new subsystem. My
> platform has a timer that I'd like to use both as a clocksource and a
> clockevent devices.
See arch/i386/kernel/hpet.c
> This timer is continueous in sense that it can run
> without any interruption
-ENOPARSE
Has your timer a free running counter and a match register based event
mechanism ?
> so I assume I can flag the clocksource device
> with "CLOCK_SOURCE_IS_CONTINUOUS". However I noticed that clockevent
> device can be stopped by using "set_mode()" method. Are these two
> behaviours compatible ?
the clock event stop only stops the event mechanism, it does not stop
the counter.
See arch/i386/kernel/hpet.c
> Another question is that I have another embedded 16 bits timer that I
> would like to use. Since the timer is only 16 bits, the maximum
> interval is tiny, My question if a user ask for a clockevent device
> using an interval is bigger that 2^16, the clockevent system doesn't
> return an error. Instead it silently reduce the interval to 2^16. Is
> this correct ? if so why ?
Yes, it is correct. The generic timer code requests an event in the
future. It does not care, whether the hardware device can handle that or
not. So the clock event code limits the delta to the maximum delta the
device can handle. The interrupt fires and the generic timer code
reschedules the event with the remaining delta time.
tglx
Hi Thomas,
Thanks for answering so quickly !
On 5/12/07, Thomas Gleixner <[email protected]> wrote:
> Francis,
>
> On Sat, 2007-05-12 at 16:54 +0200, Francis Moreau wrote:
> > I'm trying to use clocksource and clockevent new subsystem. My
> > platform has a timer that I'd like to use both as a clocksource and a
> > clockevent devices.
>
> See arch/i386/kernel/hpet.c
>
thanks for the pointer
> > This timer is continueous in sense that it can run
> > without any interruption
>
> -ENOPARSE
>
> Has your timer a free running counter and a match register based event
> mechanism ?
>
yes
> > so I assume I can flag the clocksource device
> > with "CLOCK_SOURCE_IS_CONTINUOUS". However I noticed that clockevent
> > device can be stopped by using "set_mode()" method. Are these two
> > behaviours compatible ?
>
> the clock event stop only stops the event mechanism, it does not stop
> the counter.
>
> See arch/i386/kernel/hpet.c
>
OK. I got it now, In my initial plan, I was thinking to stop the
counter to stop the event. But that's not the right thing to do. It
seems that I should disable event interrupt instead.
> > Another question is that I have another embedded 16 bits timer that I
> > would like to use. Since the timer is only 16 bits, the maximum
> > interval is tiny, My question if a user ask for a clockevent device
> > using an interval is bigger that 2^16, the clockevent system doesn't
> > return an error. Instead it silently reduce the interval to 2^16. Is
> > this correct ? if so why ?
>
> Yes, it is correct. The generic timer code requests an event in the
> future. It does not care, whether the hardware device can handle that or
> not. So the clock event code limits the delta to the maximum delta the
> device can handle. The interrupt fires and the generic timer code
> reschedules the event with the remaining delta time.
>
Thanks again for explanations. Could you give me a pointer of this reschedules ?
--
Francis
On Sat, 2007-05-12 at 22:13 +0200, Francis Moreau wrote:
> > Yes, it is correct. The generic timer code requests an event in the
> > future. It does not care, whether the hardware device can handle that or
> > not. So the clock event code limits the delta to the maximum delta the
> > device can handle. The interrupt fires and the generic timer code
> > reschedules the event with the remaining delta time.
> >
>
> Thanks again for explanations. Could you give me a pointer of this reschedules ?
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.
tglx
On 5/12/07, Thomas Gleixner <[email protected]> wrote:
> On Sat, 2007-05-12 at 22:13 +0200, Francis Moreau wrote:
> > > Yes, it is correct. The generic timer code requests an event in the
> > > future. It does not care, whether the hardware device can handle that or
> > > not. So the clock event code limits the delta to the maximum delta the
> > > device can handle. The interrupt fires and the generic timer code
> > > reschedules the event with the remaining delta time.
> > >
> >
> > Thanks again for explanations. Could you give me a pointer of this reschedules ?
>
> 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.
>
OK, I'll give it a deeper look soon.
Thanks for your great work !
--
Francis
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
Francis,
On Tue, 2007-05-15 at 10:47 +0200, Francis Moreau wrote:
> 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 ?
you are right. It is a bit strange. The resolution info is not really
reflecting the clock event source capability. I look if there is a sane
solution for that.
tglx
Hi Thomas,
On 5/16/07, Thomas Gleixner <[email protected]> wrote:
> Francis,
>
> On Tue, 2007-05-15 at 10:47 +0200, Francis Moreau wrote:
> > 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 ?
>
> you are right. It is a bit strange. The resolution info is not really
> reflecting the clock event source capability. I look if there is a sane
> solution for that.
>
Doesn't that make hrtimer_get_res() and its callers buggy since they
return this 1ns value which is not reflecting the correct clock event
capability ?
Another question about the output of '/proc/timer_list':
[...]
active timers:
#0: <c03fde10>, tick_sched_timer, S:01
# expires at 64696546875000 nsecs [in 2514469 nsecs]
.expires_next : 64696546875000 nsecs
[...]
Doesn't the 2 expire time lines give the same information ? If so,
couldn't we merge them into : ".expires_next : 64696546875000 nsecs
[in 2514469 nsecs]" ?
Thanks
--
Francis
On Wed, 2007-05-16 at 09:42 +0200, Francis Moreau wrote:
> > On Tue, 2007-05-15 at 10:47 +0200, Francis Moreau wrote:
> > > 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 ?
> >
> > you are right. It is a bit strange. The resolution info is not really
> > reflecting the clock event source capability. I look if there is a sane
> > solution for that.
> >
>
> Doesn't that make hrtimer_get_res() and its callers buggy since they
> return this 1ns value which is not reflecting the correct clock event
> capability ?
Well, it's not really buggy. It's just not telling the truth.
> Another question about the output of '/proc/timer_list':
>
> [...]
> active timers:
> #0: <c03fde10>, tick_sched_timer, S:01
> # expires at 64696546875000 nsecs [in 2514469 nsecs]
> .expires_next : 64696546875000 nsecs
> [...]
>
> Doesn't the 2 expire time lines give the same information ? If so,
> couldn't we merge them into : ".expires_next : 64696546875000 nsecs
> [in 2514469 nsecs]" ?
No. The timers are taken from the hrtimer queue and the expires_next
value is the clock events code internal value of the next timer event.
The expiry time of the first timer and the clock events code should
match of course, but we definitely want to have them seperate.
tglx