Skip to contentSkip to conversation

make pit clocksource continuous

PATCH In review Stas Sergeev 4 participants 11 messages May 12, 2007 – May 13, 2007

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 make pit clocksource continuous

Hello.

Without the attached patch, I wasn't able to get the PIT to work as a clocksource for high-res timers.
I don't know whether the patch is correct, but I tested it and it works.
Can someone please tell me what exactly does this flag mean? google reveals nothing sensible to me, sorry...

---
Set CLOCK_SOURCE_IS_CONTINUOUS flag for the PIT clocksource

CC Thomas Gleixner <[email protected]>
arch/i386/kernel/i8253.c +1 -0
@@ -193,6 +193,7 @@
 	.mask	= CLOCKSOURCE_MASK(32),
 	.mult	= 0,
 	.shift	= 20,
+	.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
 static int __init init_pit_clocksource(void)
#1 lore raw
Quoted 11 lines · Stas Sergeev

Hello.

Without the attached patch, I wasn't able to get the PIT to work as a clocksource for high-res timers.
I don't know whether the patch is correct, but I tested it and it works.
Can someone please tell me what exactly does this flag mean? google reveals nothing sensible to me, sorry...

Quoted 2 lines

---
Set CLOCK_SOURCE_IS_CONTINUOUS flag for the PIT clocksource

The flag means that the clock doesn't have any help from interrupts to extend it's precision. In the case of the PIT clocksource it does in fact use an interrupt (the timer I think) to get a higher precision. It would be wrong to add the flag in this case..

Daniel

#2 lore raw
In reply to Stas Sergeev
Quoted 11 lines · Stas Sergeev

Hello.

Without the attached patch, I wasn't able to get the PIT to work as a clocksource for high-res timers.
I don't know whether the patch is correct, but I tested it and it works.
Can someone please tell me what exactly does this flag mean? google reveals nothing sensible to me, sorry...

Quoted 2 lines

---
Set CLOCK_SOURCE_IS_CONTINUOUS flag for the PIT clocksource

Ouch no. The PIT has no continuous counter, especially not when we use the PIT to generate the next event interrupt with variable length intervals.

The PIT can only be used as a clock source, when it is in periodic mode, but it is never continuous. If we miss one PIT interrupt the time keeping is hosed.

tglx

#3 lore raw

Hello.

Quoted 3 lines · Thomas Gleixner

The PIT can only be used as a clock source, when it is in periodic mode, but it is never continuous. If we miss one PIT interrupt the time keeping is hosed.

OK, thank you and Daniel for the explanations about the flag, but now to the problem. Before hrtimer_switch_to_hres() is called, the check for timekeeping_is_continuous() is performed in tick_ckeck_oneshot_change(), and that check fails (by adding a flag I compel it to succeed). With that check failing, hrtimer_switch_to_hres() is never called, and the hrtimers do not work. That's why I posted that patch, but what would be the right way of getting the hrtimers to work? /proc/timer_list lists only the pit timesource. If I enable lapic then it is also listed, yet it doesn't help at all.

#4 lore raw
Quoted 7 lines · Stas Sergeev

Hello.

Quoted 3 lines · Thomas Gleixner

The PIT can only be used as a clock source, when it is in periodic mode, but it is never continuous. If we miss one PIT interrupt the time keeping is hosed.

Quoted 7 lines

OK, thank you and Daniel for the explanations about the flag, but now to the problem. Before hrtimer_switch_to_hres() is called, the check for timekeeping_is_continuous() is performed in tick_ckeck_oneshot_change(), and that check fails (by adding a flag I compel it to succeed).

It succeeds, but it does not work correctly, because your time keeping is unreliable.

Quoted 8 lines

With that check failing,
hrtimer_switch_to_hres() is never called, and the hrtimers do not work. That's why I posted that patch, but what would be the right way of getting the hrtimers to work? /proc/timer_list lists only the pit timesource. If I enable lapic then it is also listed, yet it doesn't help at all.

You need either pm_timer or hpet in order to switch to highres / dynticks. Are those enabled in the kernel config ?

tglx

#5 lore raw

Hello.

Quoted 2 lines · Thomas Gleixner

You need either pm_timer or hpet in order to switch to highres / dynticks. Are those enabled in the kernel config ?

Yes, both were enabled.
However, since this board is very old (bios is dated 2000), I had "acpi=off". Now removing that, makes the hrtimers to work.
Does this mean that on even an older boards (without acpi at all) the hrtimers won't work?

Thanks!

#6 lore raw
Quoted 5 lines · Stas Sergeev

Hello.

Quoted 2 lines · Thomas Gleixner

You need either pm_timer or hpet in order to switch to highres / dynticks. Are those enabled in the kernel config ?

Quoted 8 lines

Yes, both were enabled.
However, since this board is very old (bios is dated 2000), I had "acpi=off". Now removing that, makes the hrtimers to work.
Does this mean that on even an older boards (without acpi at all) the hrtimers won't work?

Not if PIT is the only clocksource available.

tglx

#7 lore raw

Hello.

Quoted 4 lines · Thomas Gleixner
Quoted 3 lines

Does this mean that on even an older
boards (without acpi at all) the hrtimers
won't work?

Not if PIT is the only clocksource available.

So you mean it can work without both the pm_timer and hpet? Sorry for bothering you too much, but I am trying to use the hrtimers in my driver module, so I'd like to know all the corner-cases.

How can I test that situation when the hrtimers work only with PIT? Apparently disabling the pm_timer and hpet in config doesn't help testing it at all, since it simply refuses to work then.

Should I use hrtimer_get_res() to see if the hrtimers are available, or is there any better way?

#8 lore raw
Quoted 6 lines · Stas Sergeev

Hello.

Quoted 3 lines · Thomas Gleixner
Quoted 3 lines

Does this mean that on even an older
boards (without acpi at all) the hrtimers
won't work?

Quoted 6 lines
Quoted 1 line

Not if PIT is the only clocksource available.

So you mean it can work without both the pm_timer and hpet? Sorry for bothering you too much, but I am trying to use the hrtimers in my driver module, so I'd like to know all the corner-cases.

It does _NOT_ work without pm_timer or hpet for the reasons explained before.

When PIT is the only clocksource in the system, i.e. no HPET and no PM_TIMER is available, then highres and dynticks are disabled.

Quoted 4 lines

How can I test that situation when the hrtimers work only with PIT? Apparently disabling the pm_timer and hpet in config doesn't help testing it at all, since it simply refuses to work then.

It is supposed to refuse to switch to highres / dyntick when you disabled pm_timer and hpet.

Quoted 2 lines

Should I use hrtimer_get_res() to see if the hrtimers are available, or is there any better way?

hrtimer_get_res() works, but I have no idea why you need hrtimers in your driver at all.

tglx

#9 lore raw

Hi,

Quoted 6 lines · Thomas Gleixner
Quoted 5 lines · Stas Sergeev

Hello.

Quoted 2 lines · Thomas Gleixner
Quoted 2 lines

Does this mean that on even an older
boards (without acpi at all) the hrtimers won't work?

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Not if PIT is the only clocksource available.

So you mean it can work without both the pm_timer and hpet? Sorry for bothering you too much, but I am trying to use the hrtimers in my driver module, so I'd like to know all the corner-cases.

It does _NOT_ work without pm_timer or hpet for the reasons explained before.

there something I don't understand : "pm_timer or hpet" aren't clockevent ?

Without acpi there should be still pit and tsc as clocksource ?

Also while talking about clockevent why rtc couldn't be used for that ?

Thanks

Matthieu

#10 lore raw
In reply to Thomas Gleixner

Hello.

Quoted 4 lines · Thomas Gleixner
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines

Does this mean that on even an older
boards (without acpi at all) the hrtimers
won't work?

Not if PIT is the only clocksource available.

I was confused as to where the above "not" applies.

Quoted 1 line

It does _NOT_ work without pm_timer or hpet

Thanks, now its clear enough. :)

Quoted 2 lines

hrtimer_get_res() works, but I have no idea why you need hrtimers in your driver at all.

This is a pc-speaker PCM driver which needs a 18.5KHz periodic freq at least (the normal freq is 37KHz).
I used the PIT and only PIT for it in the past, but now with using hrtimers, the PIT is no longer enough. This is a bit annoying, and really, after I added the flag to pit_clocksource, it just started to work, so I thought something can be done in order for it to keep working with PIT only. But if there is no way to do it with hrtimers, then oh well.