146818 RTC set-time curious...

146818 RTC set-time curious...

[Guennadi Liakhovetski]

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

Re: 146818 RTC set-time curious...

[Paul Gortmaker]

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.