Dell BIOS and HPET timer support
Jon Smirl
most Dell BIOSs don't include the ACPI entry for the HPET timer. The
official reason for this is that no version of Windows uses the HPET
and adding the ACPI entry might cause compatibility problems.
So I added this to force the HPET on:
extern unsigned long hpet_address;
hpet_address = 0xfed00000ULL;
Now my HPET seems to be working:
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 0ns tick, 3 64-bit timers
Using HPET for base-timer
Using HPET for gettimeofday
What does the 0ns tick mean, is this bad? Is there any way to verify
my HPET is working correctly? My date/time is advancing.
If my HPET is working correctly is it ok to add a probe to find the timer?
--
Jon Smirl
jons...@gmail.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matt Domsch
> After several communications with Dell support I have determined that
> most Dell BIOSs don't include the ACPI entry for the HPET timer. The
> official reason for this is that no version of Windows uses the HPET
> and adding the ACPI entry might cause compatibility problems.
What platform/BIOS version please? PowerEdge x8xx servers certainly
do have HPET enabled in their ACPI tables.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Jon Smirl
> On Wed, Jun 08, 2005 at 04:11:39PM -0400, Jon Smirl wrote:
> > After several communications with Dell support I have determined that
> > most Dell BIOSs don't include the ACPI entry for the HPET timer. The
> > official reason for this is that no version of Windows uses the HPET
> > and adding the ACPI entry might cause compatibility problems.
>
> What platform/BIOS version please? PowerEdge x8xx servers certainly
> do have HPET enabled in their ACPI tables.
All Dell PE400SC, Dim8300, Precision360 for sure. From my talk with
them none of the desktops have it enabled. They acknowledge that it is
on for some server boxes but not for most other systems.
--
Jon Smirl
jons...@gmail.com
Pallipadi, Venkatesh
HPET timer will be useful for different purposes:
1) Kernel uses it for timer interrupt and time source (gettimeofday).
Kernel will use one particular timer among available HPET timers
(typically 3).
2) The HPET driver exports the HPET device in /dev which can be used by
other kernel drivers or user programs.
In this particular case, with forcing of HPET, (1) above seems to be
working fine.
But, (2) is printing 0ns. Probably because missing HPET information in
ACPI. You may need to do some more changes in drivers/char/hpet.c in
case BIOS doesn not support HPET.
But, this will not affect normal kernel functioning. This will only
affect is someone wants to use /dev/hpet interface.
Thanks,
Venki
>-----Original Message-----
>From: linux-ker...@vger.kernel.org
>[mailto:linux-ker...@vger.kernel.org] On Behalf Of Jon Smirl
>Sent: Wednesday, June 08, 2005 1:12 PM
>To: lkml
>Subject: Dell BIOS and HPET timer support
>
>After several communications with Dell support I have determined that
>most Dell BIOSs don't include the ACPI entry for the HPET timer. The
>official reason for this is that no version of Windows uses the HPET
>and adding the ACPI entry might cause compatibility problems.
>
>So I added this to force the HPET on:
> extern unsigned long hpet_address;
> hpet_address = 0xfed00000ULL;
>
>Now my HPET seems to be working:
>hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
>hpet0: 0ns tick, 3 64-bit timers
>Using HPET for base-timer
>Using HPET for gettimeofday
>
>What does the 0ns tick mean, is this bad? Is there any way to verify
>my HPET is working correctly? My date/time is advancing.
>
>If my HPET is working correctly is it ok to add a probe to
>find the timer?
>
Jon Smirl
> But, this will not affect normal kernel functioning. This will only
> affect is someone wants to use /dev/hpet interface.
I tried the little demo program in Documentation/hpet.txt It seems to work fine.
Still not sure what 0ns tick signifies. This is an Intel ICH5 chipset.
Lee Revell
> On 6/8/05, Pallipadi, Venkatesh <venkatesh...@intel.com> wrote:
> > But, this will not affect normal kernel functioning. This will only
> > affect is someone wants to use /dev/hpet interface.
>
> I tried the little demo program in Documentation/hpet.txt It seems to work fine.
>
> Still not sure what 0ns tick signifies. This is an Intel ICH5 chipset.
>
Check the source, it's self-explanatory. See hpet_alloc().
Lee
Jon Smirl
> Check the source, it's self-explanatory. See hpet_alloc().
What is going on with do_div()?
0x0429b17f /100000 = 69.8 in my caculator. It comes back as 0 from do_div().
[jonsmirl@jonsmirl ~]$ dmesg | grep HPET
HPET: cap 0429b17f8086a201 period 0429b17f
HPET: period 0429b17f ns 0429b17f
HPET: period 0429b17f ns 00000000
Using HPET for base-timer
Using HPET for gettimeofday
[jonsmirl@jonsmirl ~]$
hpetp->hp_period = (cap & HPET_COUNTER_CLK_PERIOD_MASK) >>
HPET_COUNTER_CLK_PERIOD_SHIFT;
printk(KERN_ERR "HPET: cap %016llx period %08lx\n", cap, hpetp->hp_period);
ns = hpetp->hp_period; /* femptoseconds, 10^-15 */
printk(KERN_ERR "HPET: period %08lx ns %08lx \n", hpetp->hp_period, ns);
do_div(ns, 1000000); /* convert to nanoseconds, 10^-9 */
printk(KERN_ERR "HPET: period %08lx ns %08lx \n", hpetp->hp_period, ns);
printk(KERN_INFO "hpet%d: %ldns tick, %d %d-bit timers\n",
hpetp->hp_which, ns, hpetp->hp_ntimer,
cap & HPET_COUNTER_SIZE_MASK ? 64 : 32);
--
Jon Smirl
jons...@gmail.com
Pallipadi, Venkatesh
I think do_div expects a 64 bit 1st argument. Can you change ns to
unsigneld long long and try...
Thanks,
Venki
Jon Smirl
> unsigneld long long and try...
I already posted a patch. The field is 32 bits so a long is correct.
The do_div() is just wrong, it should have been /.