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

[Tim Gardner]

Colin Ian King wrote:
> 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
> 
> 
> 
> 

Since there does not seem to be a backwards compatible solution, my
opinion is that this is a Hardy+1 feature. Especially since the Hardy
feature freeze started today (or yesterday according to
https://wiki.ubuntu.com/HardyReleaseSchedule?highlight=%28hardyrelease%29 ).

On the other hand, we also have to think about supporting this release
for the next 5 years as it is targeted as an LTS. Is there no way to
preserve /dev/rtc and /proc/acpi/alarm ?

rtg
-- 
Tim Gardner tim.gardner at ubuntu.com