FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 02-15-2008, 01:42 PM
Colin Ian King
 
Default "New" Real Time Clock vs "Old" RTC in 2.6.24 (Hardy 8.04)

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@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


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-15-2008, 01:46 PM
Colin Ian King
 
Default "New" Real Time Clock vs "Old" RTC in 2.6.24 (Hardy 8.04)

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@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




--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-15-2008, 02:41 PM
Tim Gardner
 
Default "New" Real Time Clock vs "Old" RTC in 2.6.24 (Hardy 8.04)

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@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@ubuntu.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-15-2008, 03:29 PM
Colin Ian King
 
Default "New" Real Time Clock vs "Old" RTC in 2.6.24 (Hardy 8.04)

Tim,

Good point. How are deprecated features handled normally in a LTS disto?
Surely we must have seen a lot of /proc features being deprecated and
their replacements appear in /sys before now.

I suppose the /dev/rtc --> /dev/rtc0 is not too problematic as one
could, for example, symlink around the problem as an ugly hack.
The /dev/rtc0 interface should be backwardly compatible.

As for /proc/acpi/alarm, this is a more complex issue - I am unsure if
we can retain it for 5 years if the new RTC mechanism becomes the
de-facto way of doing things.

Colin.


On Fri, 2008-02-15 at 08:41 -0700, Tim Gardner wrote:
<snip snip> 8< --------------
stuff delete
<snip snip> 8< -------------

> 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


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 01:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org