Not that I think it matters, but I understand that util-linux-ng
now has a 2.13-rc1 release out, so you're not using the latest
version of "hwclock". That shouldn't affect HPET though.
That said, this situation is likely going to be a mess until
some new HPET support gets merged. Issues include:
- There are two drivers for the "cmos rtc" ... the legacy
version (/dev/rtc), and the one using the new RTC framework
("rtc-cmos" driver, likely /dev/rtc0 on your system).
To use the new one, you'll probably want the latest hwclock,
which understands that not ever RTC uses /dev/rtc0. (Or you
can symlink /dev/rtc to /dev/rtc0 ...)
- HPET itself has two modes. I think of them as "break things
mode" and "sane mode"; but I think they have official names
that make the first one sound like it might be reasonable to
use. (Yet it isn't; and I suspect that's a big reason why
HPET isn't enabled by default on most systems.)
The difference is that the "break things" mode overrides
the RTC interrupt line so the RTC can't use it, where the
"sane" mode just routes HPET irqs like other IRQs.
- Until the new HPET stuff gets merged (and I don't know what
schedule that's on), Linux uses the "break things" mode.
Which means that it breaks rtc-cmos ... but the legacy RTC
driver has some fairly ugly hacks to cope with it.
The new HPET stuff will among other things let HPET be used
to provide per-CPU clockevent sources (assuming there are as
many HPET instances as there are CPUs). That's on top of
other advantages, like "not breaking things".
So for the short term, I think there might be some set of config
options using the legacy (drivers/char/rtc.c) driver that will
let you enable HPET, with minimal breakage. I don't know what
those options are, or what hwclock would need to do (or not do).
And longer term, the rtc framework version (rtc-cmos) will work
just fine with new HPET code, since Linux will be able to use
HPET in "sane mode" not "break things" mode.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
