Hello
Not a bug report, nothing critical (hopefully), just a question - in rtc.c
driver on time-set ioctl() the following is done:
save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
which writes 0x7X to rtc regs=ister 0xA... Why? I read a few documents and
all agree on, what's expressed in one of them as "bits 4-6 should be 0x2,
other values don't do anything useful on PCs, really..." VERY curious...
Thanks
Guennadi
---
Guennadi Liakhovetski
Guennadi Liakhovetski wrote:
>
> Not a bug report, nothing critical (hopefully), just a question - in rtc.c
> driver on time-set ioctl() the following is done:
> save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> which writes 0x7X to rtc regs=ister 0xA... Why? I read a few documents and
> all agree on, what's expressed in one of them as "bits 4-6 should be 0x2,
> other values don't do anything useful on PCs, really..." VERY curious...
This code predates the rtc driver (and linux-1.0 in general) since it first
appeared in kernel/time.c: set_rtc_mmss(). [now arch/*/kernel/time.c]
I've seen that "..don't do anything useful..." before and it is incorrect.
The RESET and RESET2 values (functionally equivalent, IIRC) stop the
internal xtal input divider and once cleared back to normal operating state
(6-4 are 010) the next rtc update will take place precisely 0.5 seconds later.
This is a documented feature of the original mc146818 to allow for precise
setting of the clock, but I wouldn't be surprised if some el-cheapo chipset
implementations don't honour it. Might be amusing to write a little test
program and run it on a few different machines to see what happens...
Paul.