"New" Real Time Clock vs "Old" RTC in 2.6.24 (Hardy 8.04)

[Colin Ian King]

Hi all,

While investigating a minor Real Time Clock (RTC) mismatch between the
i386 and x86_64 configs, I realised that the RTC configs are more
complex that I originally expected. In fact, I stumbled upon a new layer
of RTC complexity which I shall describe as follows...

RTC History.
-----------

On the 8th May 2007, David Brownell <david_b at pacbell.net> introduced
into 2.6.22 a new set of RTC patches that basically:

1. Introduced the ACPI RTC implementation
2. Made /proc/acpi/alarm a legacy config option
3. Introduced /sys/class/rtc/rtcN/wakealarm (to
replace /proc/acpi/alarm)

Essentially, these replace the RTC driver in device/char with a more
modular and layered RTC implementation in device/rtc

Enabling the new RTC code
-------------------------

To enable the new RTC implementation, one needs to:

1. unset CONFIG_RTC, CONFIG_GEN_RTC (generic), CONFIG_GEN_RTC_X
(enhanced/extended RTC). This removes /dev/rtc and /proc/driver/rtc

2. set RTC_CLASS
   set RTC_INTF_SYSFS (enables /sys/class/rtc/rtcN)
   set RTC_INTF_PROC  (enables /proc/driver/rtc)
   set RTC_INTF_DEV_UIE_EMUL (enables RTC UIE emulation on dev
interface)
 
and set I2C drivers (as modules or statically linked): 
        RTC_DRV_DS1307 RTC_DRV_DS1374 RTC_DRV_DS1672 RTC_DRV_MAX6900
        RTC_DRV_RS5C372 RTC_DRV_ISL1208 RTC_DRV_X1205 RTC_DRV_PCF8563
        RTC_DRV_PCF8583 RTC_DRV_M41T80 RTC_DRV_M41T80_WDT

and set SPI RTC drivers (as modules or statically linked):
	RTC_DRV_RS5C348 RTC_DRV_MAX6902

and set Platform RTC drivers (as modules or statically linked):
	RTC_DRV_CMOS   (PC-style "CMOS", derived from the original
devices/char/rtc.c)
        RTC_DRV_DS1216 RTC_DRV_DS1553 RTC_DRV_STK17TA8 RTC_DRV_DS1742
        RTC_DRV_M48T86 RTC_DRV_M48T59 RTC_DRV_V3020

and also set on-CPU RTC drivers:
        RTC_DRV_OMAP            for ARCH_OMAP15XX || ARCH_OMAP16XX ||
ARCH_OMAP730
        RTC_DRV_S3C             for ARCH_S3C2410
        RTC_DRV_EP93XX          for ARCH_EP93XX
        RTC_DRV_SA1100          for ARCH_SA1100 || ARCH_PXA
        RTC_DRV_SH              for RTC_CLASS && (CPU_SH3 || CPU_SH4)
        RTC_DRV_VR41XX          for CPU_VR41XX
        RTC_DRV_PL031           for ARM_AMBA
        RTC_DRV_AT32AP700X      for PLATFORM_AT32AP
        RTC_DRV_AT91RM9200      for ARCH_AT91RM9200
        RTC_DRV_BFIN            for BLACKFIN
        RTC_DRV_RS5C313         for SH_LANDISK

Implications of new RTC
-----------------------

I believe the current 2.6.22 and 2.6.24 kernel choices for the i386 and
x86_64 builds are to use the "old" style drivers/char/rtc.c code for the
CMOS clock. If we move to the new style RTC clock driver then:

1. /proc/acpi/alarm is removed and instead we
gain /sys/class/rtc/rtcN/wakealarm.  This interface allows users
configure a wakeup time of their PC, for example, used by MythTV.  This
has been discussed in the MythTV forums, e.g.
http://www.mythtv.org/wiki/index.php/ACPI_Wakeup.

   From my understanding, MythTV only uses /dev/rtc and the user
tweaks /proc/acpi/alarm manually, so I don't expect any RTC changes to
impact here.

2. More concerning is that /dev/rtc becomes /dev/rtcN, starting from N =
0. This I expect will break applications that expect just /dev/rtc.

3. An ABI change is required, since the old RTC code exports
rtc_register, rtc_unregister, rtc_control.  It appears that only
sound/core/rtctimer.c uses these symbols. However, moving to the new RTC
means that we will have to either fix sound/core/rtctimer.c or disable
it. I am unsure how significant an impact this will be.

4. An *interesting* feature of the new RTC is that the RTC_HCTOSYS and
RTC_HCTOSYS_DEVICE config options require the RTC device drivers to be
*statically* linked into the kernel for the kernel to be able to set the
system clock on kernel startup because the RTC device driver needs to be
loaded before late_initcall occurs. This is not pleasant. :-(

As things stand 8.04 is using the core old style RTC code and we should
probably move to the new RTC post 8.04 just because it will impact on
apps.

Any comments?

Colin King