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
Signed-off-by: Stas Sergeev <[email protected]>
CC: Thomas Gleixner <[email protected]>
On Sun, 2007-05-13 at 03:18 +0400, Stas Sergeev wrote:
> 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
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
On Sun, 2007-05-13 at 03:18 +0400, Stas Sergeev wrote:
> 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
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
Hello.
Thomas Gleixner wrote:
> 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.
On Sun, 2007-05-13 at 13:04 +0400, Stas Sergeev wrote:
> Hello.
>
> Thomas Gleixner wrote:
> > 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).
It succeeds, but it does not work correctly, because your time keeping
is unreliable.
> 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
Hello.
Thomas Gleixner wrote:
> 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!
On Sun, 2007-05-13 at 20:48 +0400, Stas Sergeev wrote:
> Hello.
>
> Thomas Gleixner wrote:
> > 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?
Not if PIT is the only clocksource available.
tglx
Hello.
Thomas Gleixner wrote:
>> 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?
On Sun, 2007-05-13 at 21:23 +0400, Stas Sergeev wrote:
> Hello.
>
> Thomas Gleixner wrote:
> >> 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.
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.
> 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.
> 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
Hi,
On Sun, 13 May 2007 19:36:12 +0200, Thomas Gleixner wrote:
> On Sun, 2007-05-13 at 21:23 +0400, Stas Sergeev wrote:
>> Hello.
>>
>> Thomas Gleixner wrote:
>> >> 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.
>
> 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
Hello.
Thomas Gleixner wrote:
>>>> 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.
> It does _NOT_ work without pm_timer or hpet
Thanks, now its clear enough. :)
> 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.