YAMON requires and enforces the RTC Data Mode (Register B, DM bit) to binary, that is the bit is set every time the board goes through the firmware bootstrap sequence. Likewise its calendar manipulation commands interpret or set the RTC registers unconditionally as binary, never actually checking what the value of the DM bit is, under the (correct) assumption that it has been previously set, to indicate the binary mode. A change to Linux a while ago however introduced a platform-specific tweak that clears that bit and therefore forces the data mode to BCD. This causes clock corruption and misinterpretation that has to be fixed up by user-mode tools in system startup scripts as the initial clock is often incorrect according to the BCD interpretation forced. This change removes the hack; a comment included refers to alarm code, but even if it was broken at one point by requiring the BCD mode, it should have been trivially corrected and even if not, given how rarely the alarm feature is used, that was not really a reasonable justification to break the system clock that is indeed used by virtually everything. And either way the alarm code has been since fixed anyway. Signed-off-by: Maciej W. Rozycki <macro@xxxxxxxxxxxxxxxx> --- Please apply -- this ends a long battle trying to track down where the annoying clock corruption has come from. Maciej linux-malta-rtc.diff diff --git a/arch/mips/mti-malta/malta-platform.c b/arch/mips/mti-malta/malta-platform.c index 4c35301..80562b8 100644 --- a/arch/mips/mti-malta/malta-platform.c +++ b/arch/mips/mti-malta/malta-platform.c @@ -138,11 +138,6 @@ static int __init malta_add_devices(void) if (err) return err; - /* - * Set RTC to BCD mode to support current alarm code. - */ - CMOS_WRITE(CMOS_READ(RTC_CONTROL) & ~RTC_DM_BINARY, RTC_CONTROL); - return 0; }
