From: mingo@elte.hu (Ingo Molnar)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 7/7] x86: hpet: Cleanup the clockevents init and register code
Date: Thu, 19 May 2011 11:33:18 +0200 [thread overview]
Message-ID: <20110519093318.GC6251@elte.hu> (raw)
In-Reply-To: <20110518210136.646482357@linutronix.de>
* Thomas Gleixner <tglx@linutronix.de> wrote:
> @@ -884,6 +835,14 @@ int __init hpet_enable(void)
> goto out_nohpet;
>
> /*
> + * The period is a femto seconds value. Convert it to a
> + * frequency.
> + */
> + freq = FSEC_PER_SEC;
> + do_div(freq, hpet_period);
> + hpet_freq = freq;
Something i just noticed: with a typical hpet frequency of around 14 MHz we get
a period of 71428571 femtoseconds.
Our HPET_MAX_PERIOD is 100000000 at the moment, so our limits look like this:
100000
71428571
100000000
Note how close the max period (lowest frequency) is to our typical value!
So if there's a 10 MHz hpet somewhere, with just slightly below spec, we'd fail
due to:
if (hpet_period < HPET_MIN_PERIOD || hpet_period > HPET_MAX_PERIOD)
goto out_nohpet;
unless i got my numbers wrong it might be worth upping the max period to
1000000000, to allow down to 1 MHz hpet frequencies. Or at least up it enough
to make 10 MHz possible modulo small noise.
Patch looks good:
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
LAK <linux-arm-kernel@lists.infradead.org>,
John Stultz <john.stultz@linaro.org>
Subject: Re: [patch 7/7] x86: hpet: Cleanup the clockevents init and register code
Date: Thu, 19 May 2011 11:33:18 +0200 [thread overview]
Message-ID: <20110519093318.GC6251@elte.hu> (raw)
In-Reply-To: <20110518210136.646482357@linutronix.de>
* Thomas Gleixner <tglx@linutronix.de> wrote:
> @@ -884,6 +835,14 @@ int __init hpet_enable(void)
> goto out_nohpet;
>
> /*
> + * The period is a femto seconds value. Convert it to a
> + * frequency.
> + */
> + freq = FSEC_PER_SEC;
> + do_div(freq, hpet_period);
> + hpet_freq = freq;
Something i just noticed: with a typical hpet frequency of around 14 MHz we get
a period of 71428571 femtoseconds.
Our HPET_MAX_PERIOD is 100000000 at the moment, so our limits look like this:
100000
71428571
100000000
Note how close the max period (lowest frequency) is to our typical value!
So if there's a 10 MHz hpet somewhere, with just slightly below spec, we'd fail
due to:
if (hpet_period < HPET_MIN_PERIOD || hpet_period > HPET_MAX_PERIOD)
goto out_nohpet;
unless i got my numbers wrong it might be worth upping the max period to
1000000000, to allow down to 1 MHz hpet frequencies. Or at least up it enough
to make 10 MHz possible modulo small noise.
Patch looks good:
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Thanks,
Ingo
next prev parent reply other threads:[~2011-05-19 9:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-18 21:33 [patch 0/7] clocksources/clockevents improvements Thomas Gleixner
2011-05-18 21:33 ` Thomas Gleixner
2011-05-18 21:33 ` [patch 2/7] clocksource: Get rid of the hardcoded 5 seconds sleep time limit Thomas Gleixner
2011-05-18 21:33 ` Thomas Gleixner
2011-05-19 0:57 ` John Stultz
2011-05-19 0:57 ` John Stultz
2011-05-19 8:43 ` Thomas Gleixner
2011-05-19 8:43 ` Thomas Gleixner
2011-05-20 1:10 ` john stultz
2011-05-20 1:10 ` john stultz
2011-05-18 21:33 ` [patch 1/7] clocksource: Restructure clocksource struct members Thomas Gleixner
2011-05-18 21:33 ` Thomas Gleixner
2011-05-18 21:33 ` [patch 4/7] clockevents: Provide combined configure and register function Thomas Gleixner
2011-05-18 21:33 ` Thomas Gleixner
2011-05-19 9:08 ` Ingo Molnar
2011-05-19 9:08 ` Ingo Molnar
2011-05-19 10:00 ` Thomas Gleixner
2011-05-19 10:00 ` Thomas Gleixner
2011-05-19 18:10 ` Ingo Molnar
2011-05-19 18:10 ` Ingo Molnar
2011-05-18 21:33 ` [patch 3/7] clockevents: Restructure clock_event_device members Thomas Gleixner
2011-05-18 21:33 ` Thomas Gleixner
2011-05-18 21:33 ` [patch 5/7] clockevents: Provide interface to reconfigure an active clock event device Thomas Gleixner
2011-05-18 21:33 ` Thomas Gleixner
2011-05-19 7:26 ` Linus Walleij
2011-05-19 7:26 ` Linus Walleij
2011-05-19 9:10 ` Ingo Molnar
2011-05-19 9:10 ` Ingo Molnar
2011-05-19 9:33 ` Thomas Gleixner
2011-05-19 9:33 ` Thomas Gleixner
2011-05-19 9:37 ` Ingo Molnar
2011-05-19 9:37 ` Ingo Molnar
2011-05-18 21:33 ` [patch 6/7] x86: Convert PIT to clockevents_config_and_register() Thomas Gleixner
2011-05-18 21:33 ` Thomas Gleixner
2011-05-18 21:33 ` [patch 7/7] x86: hpet: Cleanup the clockevents init and register code Thomas Gleixner
2011-05-18 21:33 ` Thomas Gleixner
2011-05-19 9:33 ` Ingo Molnar [this message]
2011-05-19 9:33 ` Ingo Molnar
2011-05-19 9:34 ` [patch 0/7] clocksources/clockevents improvements Ingo Molnar
2011-05-19 9:34 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110519093318.GC6251@elte.hu \
--to=mingo@elte.hu \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.