Re: acpihpet quality
Ted Unangst [t...@tedunangst.com] wrote: On Thu, Sep 13, 2012 at 15:46, Chris Cappuccio wrote: Mark Kettenis [mark.kette...@xs4all.nl] wrote: Date: Wed, 15 Aug 2012 11:02:43 -0400 From: Ted Unangst t...@tedunangst.com The acpihpet timer is, in my testing, lots better than the acpitimer. Faster to read and more precise. They should not have the same quality value. Double acpihpet. Since both acpitimer(4) and acpihpet(4) are based on an abstract specification that AFAIK doesn't say anything about the actual underlying hardware I'm totally unconvinced unless you can show this to be true on a wide variety of hardware. HPET on some processors is emulated in software via BIOS. Ring -1 or whatever. I believe one of either the AMD Elan SC420 or the AMD Geode LX fits in this category. hpet or just regular acpi timer? I'm not sure why I thought it was those two. Must be this that i'm thinking of from acpihpet.c but it's for a newer chip that provides an HPET (sometimes). /* * Revisions 0x30 through 0x3a of the AMD SB700, with spread * spectrum enabled, have an SMM based HPET emulation that's * subtly broken. The hardware is initialized upon first * access of the configuration register. Initialization takes * some time during which the configuration register returns * 0x. */
Re: acpihpet quality
Mark Kettenis [mark.kette...@xs4all.nl] wrote: Date: Wed, 15 Aug 2012 11:02:43 -0400 From: Ted Unangst t...@tedunangst.com The acpihpet timer is, in my testing, lots better than the acpitimer. Faster to read and more precise. They should not have the same quality value. Double acpihpet. Since both acpitimer(4) and acpihpet(4) are based on an abstract specification that AFAIK doesn't say anything about the actual underlying hardware I'm totally unconvinced unless you can show this to be true on a wide variety of hardware. HPET on some processors is emulated in software via BIOS. Ring -1 or whatever. I believe one of either the AMD Elan SC420 or the AMD Geode LX fits in this category.
acpihpet quality
The acpihpet timer is, in my testing, lots better than the acpitimer. Faster to read and more precise. They should not have the same quality value. Double acpihpet. Index: acpihpet.c === RCS file: /cvs/src/sys/dev/acpi/acpihpet.c,v retrieving revision 1.13 diff -u -p -r1.13 acpihpet.c --- acpihpet.c 10 Jan 2011 13:36:57 - 1.13 +++ acpihpet.c 15 Aug 2012 14:59:40 - @@ -44,7 +44,7 @@ static struct timecounter hpet_timecount 0x, /* counter_mask (24 bits) */ 0, /* frequency */ 0, /* name */ - 1000/* quality */ + 2000/* quality */ }; #endif
Re: acpihpet quality
Date: Wed, 15 Aug 2012 11:02:43 -0400 From: Ted Unangst t...@tedunangst.com The acpihpet timer is, in my testing, lots better than the acpitimer. Faster to read and more precise. They should not have the same quality value. Double acpihpet. Since both acpitimer(4) and acpihpet(4) are based on an abstract specification that AFAIK doesn't say anything about the actual underlying hardware I'm totally unconvinced unless you can show this to be true on a wide variety of hardware. If we do this, the quality of the amdpcib(4) and tcpcib(4) drivers should probably be raised to 3000. I intentionally assigned them a higher number than the acpitimer(4) and acpihpet(4) because for these drivers the underlying hardware is actually known! Index: acpihpet.c === RCS file: /cvs/src/sys/dev/acpi/acpihpet.c,v retrieving revision 1.13 diff -u -p -r1.13 acpihpet.c --- acpihpet.c10 Jan 2011 13:36:57 - 1.13 +++ acpihpet.c15 Aug 2012 14:59:40 - @@ -44,7 +44,7 @@ static struct timecounter hpet_timecount 0x, /* counter_mask (24 bits) */ 0, /* frequency */ 0, /* name */ - 1000/* quality */ + 2000/* quality */ }; #endif
Re: acpihpet quality
This reminds me... On Wed, Aug 15, 2012 at 8:02 AM, Ted Unangst t...@tedunangst.com wrote: 0x, /* counter_mask (24 bits) */ ... this comment has been bugging me for a while. I'm pretty sure it should be 32 bits. Seems like a bad copy/paste from acpitimer.c.
Re: acpihpet quality
On Wed, Aug 15, 2012 at 5:02 PM, Ted Unangst t...@tedunangst.com wrote: The acpihpet timer is, in my testing, lots better than the acpitimer. Faster to read and more precise. They should not have the same quality value. Double acpihpet. as long as acpi subsystem attaches acpitimer earlier we don't need that since acpihpet always prevails.
Re: acpihpet quality
On Wed, Aug 15, 2012 at 17:21, Mark Kettenis wrote: Date: Wed, 15 Aug 2012 11:02:43 -0400 From: Ted Unangst t...@tedunangst.com The acpihpet timer is, in my testing, lots better than the acpitimer. Faster to read and more precise. They should not have the same quality value. Double acpihpet. Since both acpitimer(4) and acpihpet(4) are based on an abstract specification that AFAIK doesn't say anything about the actual underlying hardware I'm totally unconvinced unless you can show this to be true on a wide variety of hardware. If we do this, the quality of the amdpcib(4) and tcpcib(4) drivers should probably be raised to 3000. I intentionally assigned them a higher number than the acpitimer(4) and acpihpet(4) because for these drivers the underlying hardware is actually known! Take a look at dmesglog. There are no acpihpet timers slower than 14mhz. If either of the above are present, they are almost certainly the clock you're talking to via acpihpet. acpitimer on the other hand, ticks at a fixed 3mhz. And reading it does this little latching dance I'm not impressed with. I'd be happy making it 1500, if you think there's some possibility that a system would have a bad acpihpet timer and a good amdpcib timer.
Re: acpihpet quality
On Wed, Aug 15, 2012 at 5:36 PM, Mike Belopuhov m...@crypt.org.ru wrote: On Wed, Aug 15, 2012 at 5:02 PM, Ted Unangst t...@tedunangst.com wrote: The acpihpet timer is, in my testing, lots better than the acpitimer. Faster to read and more precise. They should not have the same quality value. Double acpihpet. as long as acpi subsystem attaches acpitimer earlier we don't need that since acpihpet always prevails. actually regardless when it gets attached, it will always prevail as long as it's frequency is higher.
