Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Monday 28 May 2007, Matthew Garrett wrote: > On Fri, Jan 05, 2007 at 10:01:57AM -0800, David Brownell wrote: > > This is an "RTC framework" driver for the "CMOS" RTCs which are standard > > on PCs and some other platforms. That's MC146818 compatible silicon. > > ... > > +static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t) > > This is awkward. At the very least, year will be set to -1. This then > gets passed through to rtc_tm_to_time, which results in reading > wakealarm providing very odd feedback. I guess the "right" fix is for > rtc_tm_to_time to use the current values for anything that's -1? Well ... legacy APIs allow "-1" there; /proc/driver/rtc certainly interprets wildcards consistently too. That is, historically it's not been legit to call rtc_tm_to_time(>time). A counter-argument could be made that rtc_read_alarm() should get rid of wildcards. It's got the right RTC in hand; rtc_tm_to_time() doesn't. Other RTCs can have this same type of "wildcard" issue. Me, I'd prefer to make the API treat alarms as purely oneshot. That whole "wildcard" model is, as you noted, awkward ... even though it's got hardware support in cases like MC146818 and clones, it's not very portable. But I don't want to push that issue either way just now. > > + rtc_control = CMOS_READ(RTC_CONTROL); > > + rtc_control &= ~(RTC_PIE | RTC_AIE | RTC_UIE); > > Do you really want to clobber RTC_AIE on probe? If an alarm has been set > by the BIOS, it seems a little unfair to disable it on boot. I was wondering about that in the context of a different RTC, which happens to run on BIOS-less hardware. Which, curiously, may be the opposite of BIOS-impaired hardware ... :) In general, I suspect the alarm should stay active ... unless its time has already passed. That was the original intent of that tweak, but of course PCs don't actually *have* oneshot alarms, so there's no way to tell if a given alarm is in the past. Leading to the conclusion that AIE should probably stay enabled. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Fri, Jan 05, 2007 at 10:01:57AM -0800, David Brownell wrote: > This is an "RTC framework" driver for the "CMOS" RTCs which are standard > on PCs and some other platforms. That's MC146818 compatible silicon. > Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only > one will be able to claim the RTC irq) include: Sorry for getting to this so late - I've only just started playing with this driver. > +static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t) This is awkward. At the very least, year will be set to -1. This then gets passed through to rtc_tm_to_time, which results in reading wakealarm providing very odd feedback. I guess the "right" fix is for rtc_tm_to_time to use the current values for anything that's -1? > + rtc_control = CMOS_READ(RTC_CONTROL); > + rtc_control &= ~(RTC_PIE | RTC_AIE | RTC_UIE); Do you really want to clobber RTC_AIE on probe? If an alarm has been set by the BIOS, it seems a little unfair to disable it on boot. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Fri, Jan 05, 2007 at 10:01:57AM -0800, David Brownell wrote: This is an RTC framework driver for the CMOS RTCs which are standard on PCs and some other platforms. That's MC146818 compatible silicon. Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only one will be able to claim the RTC irq) include: Sorry for getting to this so late - I've only just started playing with this driver. +static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t) This is awkward. At the very least, year will be set to -1. This then gets passed through to rtc_tm_to_time, which results in reading wakealarm providing very odd feedback. I guess the right fix is for rtc_tm_to_time to use the current values for anything that's -1? + rtc_control = CMOS_READ(RTC_CONTROL); + rtc_control = ~(RTC_PIE | RTC_AIE | RTC_UIE); Do you really want to clobber RTC_AIE on probe? If an alarm has been set by the BIOS, it seems a little unfair to disable it on boot. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Monday 28 May 2007, Matthew Garrett wrote: On Fri, Jan 05, 2007 at 10:01:57AM -0800, David Brownell wrote: This is an RTC framework driver for the CMOS RTCs which are standard on PCs and some other platforms. That's MC146818 compatible silicon. ... +static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t) This is awkward. At the very least, year will be set to -1. This then gets passed through to rtc_tm_to_time, which results in reading wakealarm providing very odd feedback. I guess the right fix is for rtc_tm_to_time to use the current values for anything that's -1? Well ... legacy APIs allow -1 there; /proc/driver/rtc certainly interprets wildcards consistently too. That is, historically it's not been legit to call rtc_tm_to_time(t-time). A counter-argument could be made that rtc_read_alarm() should get rid of wildcards. It's got the right RTC in hand; rtc_tm_to_time() doesn't. Other RTCs can have this same type of wildcard issue. Me, I'd prefer to make the API treat alarms as purely oneshot. That whole wildcard model is, as you noted, awkward ... even though it's got hardware support in cases like MC146818 and clones, it's not very portable. But I don't want to push that issue either way just now. + rtc_control = CMOS_READ(RTC_CONTROL); + rtc_control = ~(RTC_PIE | RTC_AIE | RTC_UIE); Do you really want to clobber RTC_AIE on probe? If an alarm has been set by the BIOS, it seems a little unfair to disable it on boot. I was wondering about that in the context of a different RTC, which happens to run on BIOS-less hardware. Which, curiously, may be the opposite of BIOS-impaired hardware ... :) In general, I suspect the alarm should stay active ... unless its time has already passed. That was the original intent of that tweak, but of course PCs don't actually *have* oneshot alarms, so there's no way to tell if a given alarm is in the past. Leading to the conclusion that AIE should probably stay enabled. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Tuesday 09 January 2007 4:01 pm, David Brownell wrote:
> So the attached version of the rtc-cmos patch uses asm-generic
> and also adds Kconfig dependencies for architectures with usable
> versions of that header.
No really ... _this_ version. I seem to have too many versions
floating around, in too many different trees.
This is an "RTC framework" driver for the "CMOS" RTCs which are standard
on PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily),
not limited to sorting out the "/dev/rtc0" issue (udev easily tweaked).
Also, the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the
old drivers/char/rtc.c driver, and should help the non-embedded distros
(and the new timekeeping code) start to switch to the framework.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
drivers/rtc/Kconfig | 13
drivers/rtc/Makefile|1
drivers/rtc/rtc-cmos.c | 718
include/linux/mc146818rtc.h | 10
4 files changed, 742 insertions(+)
Index: g26/drivers/rtc/Kconfig
===
--- g26.orig/drivers/rtc/Kconfig 2007-01-07 17:42:43.0 -0800
+++ g26/drivers/rtc/Kconfig 2007-01-09 15:41:06.0 -0800
@@ -95,6 +95,29 @@ config RTC_INTF_DEV_UIE_EMUL
comment "RTC drivers"
depends on RTC_CLASS
+# this 'CMOS' RTC driver is arch dependent because
+# requires defining CMOS_READ/CMOS_WRITE, and a
+# global rtc_lock ... it's not yet just another platform_device.
+
+config RTC_DRV_CMOS
+ tristate "PC-style 'CMOS' real time clock"
+ depends on RTC_CLASS && (X86_PC || ALPHA || ARM26 || ARM \
+ || M32R || ATARI || POWERPC || SPARC64 || SPARC)
+ help
+ Say "yes" here to get direct support for the real time clock
+ found in every PC or ACPI-based system, and some other boards.
+ Specifically the original MC146818, compatibles like those in
+ PC south bridges, the DS12887 or M48T86, some multifunction
+ or LPC bus chips, and so on.
+
+ Your system will need to define the platform device used by
+ this driver, otherwise it won't be accessible. This means
+ you can safely enable this driver if you don't know whether
+ or not your board has this kind of hardware.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-cmos.
+
config RTC_DRV_X1205
tristate "Xicor/Intersil X1205"
depends on RTC_CLASS && I2C
Index: g26/drivers/rtc/Makefile
===
--- g26.orig/drivers/rtc/Makefile 2007-01-07 17:42:43.0 -0800
+++ g26/drivers/rtc/Makefile 2007-01-07 17:54:21.0 -0800
@@ -15,6 +15,7 @@ obj-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysf
obj-$(CONFIG_RTC_INTF_PROC) += rtc-proc.o
obj-$(CONFIG_RTC_INTF_DEV) += rtc-dev.o
+obj-$(CONFIG_RTC_DRV_CMOS) += rtc-cmos.o
obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o
obj-$(CONFIG_RTC_DRV_TEST) += rtc-test.o
Index: g26/include/linux/mc146818rtc.h
===
--- g26.orig/include/linux/mc146818rtc.h 2007-01-07 17:42:43.0 -0800
+++ g26/include/linux/mc146818rtc.h 2007-01-07 17:54:21.0 -0800
@@ -18,6 +18,16 @@
#ifdef __KERNEL__
#include /* spinlock_t */
extern spinlock_t rtc_lock; /* serialize CMOS RAM access */
+
+/* Some RTCs extend the mc146818 register set to support alarms of more
+ * than 24 hours in the future; or dates that include a century code.
+ * This platform_data structure can pass this information to the driver.
+ */
+struct cmos_rtc_board_info {
+ u8 rtc_day_alarm; /* zero, or register index
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Tuesday 09 January 2007 8:37 am, Woody Suwalski wrote: > As to the patch: applied to 2.6.20-rc4, both on PC and ARM, commented > out "EXPERIMENTAL"... > > To build your new patch for ARM I have modified the line "depends on > RTC_CLASS && (X86_PC || ACPI || ARM)"... > > On Netwinder ARM - can not build (see: rtc_build.log) Heh, so it's a good thing I disabled the build there. :) > OK, changed the include/asm/rtc.h to look like i386 == include > asm-generic/rtc.h In drivers/rtc/rtc-cmos.c I hope ... seems to not give equivalent functionality even on platforms which have it. Looks to me like is the right solution, though that still implies arch-level support for which does not exist on all platforms. So the attached version of the rtc-cmos patch uses asm-generic and also adds Kconfig dependencies for architectures with usable versions of that header. Of course, the "right" answer is to make this be like any other driver and allow the registers to go anywhere in the address space, not hard-wiring them to a platform-specific I/O space address. That is, CMOS_READ/CMOS_WRITE are legacy baggage. But that's not an issue to be addressed by this particular patch. > Still does not build - see rtc_build2.log > > Could you please check what other defs are missing on ARM? I'm not sure what you changed. I updated the rtc-cmos patch to use directly, then did an ARM build which configured that driver as a module. No compile-time problems. (I think you changed the wrong file...) But at link time I ran into the problem that arm/kernel/time.c defines "rtc_lock" but only exports it to an obsolete SA1100 driver. See attached "rtc-arm.patch". But static linking was no problem ... of course, I didn't add any code to define the platform_device (with or without the platform_data teling about extra registers) and couldn't test anything other than the build. > >>> > <[EMAIL PROTECTED]> > As for the RTC patch, it does work on the shark, and is needed. > <<< > > So is there a reason to have RTC build blocked on all ARM? The original reason was that it's not known to work. Given the attached patches, that issue is resolved at least from the build perspective. - Dave Fix build problem on ARM ... the only user of "rtc_lock" today is the optional PC-style "CMOS" RTC driver, not the legacy SA1100 RTC driver. Signed-off-by: David Brownell <[EMAIL PROTECTED]> Index: at91/arch/arm/kernel/time.c === --- at91.orig/arch/arm/kernel/time.c 2006-11-10 09:47:46.0 -0800 +++ at91/arch/arm/kernel/time.c 2007-01-09 15:08:39.0 -0800 @@ -38,12 +38,14 @@ */ struct sys_timer *system_timer; +#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) /* this needs a better home */ DEFINE_SPINLOCK(rtc_lock); -#ifdef CONFIG_SA1100_RTC_MODULE +#ifdef CONFIG_RTC_DRV_CMOS_MODULE EXPORT_SYMBOL(rtc_lock); #endif +#endif /* pc-style 'CMOS' RTC support */ /* change this if you have some constant time drift */ #define USECS_PER_JIFFY (100/HZ) This is an "RTC framework" driver for the "CMOS" RTCs which are standard on PCs and some other platforms. That's MC146818 compatible silicon. Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only one will be able to claim the RTC irq) include: - This leverages both the new RTC framework and the driver model; both PNPACPI and platform device modes are supported. (A separate patch creates a platform device on PCs where PNPACPI isn't configured.) - It supports common extensions like longer alarms. (A separate patch exports that information from ACPI through platform_data.) - Likewise, system wakeup events use "real driver model support", with policy control via sysfs "wakeup" attributes and and using normal rtc ioctls to manage wakeup. (Patch in the works. The ACPI hooks are known; /proc/acpi/alarm can vanish. Making it work with EFI will be a minor challenge to someone with e.g. a MiniMac.) It's not yet been tested on non-x86 systems, without ACPI, or with HPET. And the RTC framework will surely have teething pains on "mainstream" PC-based systems (though must embedded Linux systems use it heavily), not limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also, the ALSA rtctimer code doesn't use the new RTC API. Otherwise, this should be a no-known-regressions replacement for the old drivers/char/rtc.c driver, and should help the non-embedded distros (and the new timekeeping code) start to switch to the framework. Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- Note also that any systems using "rtc-m48t86" are candidates to switch over to this more functional driver; the platform data is different, and the way bytes are read is different (no CMOS_READ/CMOS_WRITE, or even normal readb and writeb), but otherwise those chips should be compatible. drivers/rtc/Kconfig | 13 drivers/rtc/Makefile
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
Russell King wrote: On Sat, Jan 06, 2007 at 01:17:25PM -0800, David Brownell wrote: On Saturday 06 January 2007 9:17 am, Woody Suwalski wrote: There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. ... Let me put that differently. That should be done as a separate patch, adding (a) that platform_device, and maybe platform_data if it's got additional alarm registers, and (b) Kconfig support to let that work. I'd call it a "patch #4 of 3". ;) ... I will try to play with the new code on Monday on ARM... Thanks. Could you describe your ARM board? None of mine have an RTC using this register API. Does it support system sleep states (/sys/power/state) with a wakeup-capable (enable_irq_wake) RTC irq? Woody will be using a Netwinder (he's part of the original development team.) So no sleep states and therefore no wakeup. There's various other ARM-based systems using the PC RTC, but none of them have sleep or wakeup abilities afaik. I think that Russell is correct - the RTC is just part of a Winbond multifunction chip. It has no special wake-up or alarm hooks (as far as I remember). As to the patch: applied to 2.6.20-rc4, both on PC and ARM, commented out "EXPERIMENTAL"... To build your new patch for ARM I have modified the line "depends on RTC_CLASS && (X86_PC || ACPI || ARM)"... On Netwinder ARM - can not build (see: rtc_build.log) OK, changed the include/asm/rtc.h to look like i386 == include asm-generic/rtc.h Still does not build - see rtc_build2.log Could you please check what other defs are missing on ARM? Thanks, Woody BTW. Current RTC is broken same way on Shark ARM as it is on Netwinder ARM: >>> <[EMAIL PROTECTED]> As for the RTC patch, it does work on the shark, and is needed. <<< So is there a reason to have RTC build blocked on all ARM? CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/compile.h CHK include/linux/utsrelease.h CC [M] drivers/rtc/rtc-cmos.o In file included from drivers/rtc/rtc-cmos.c:39: include/asm/rtc.h:21: warning: 'struct rtc_time' declared inside parameter list include/asm/rtc.h:21: warning: its scope is only this definition or declaration, which is probably not what you want include/asm/rtc.h:22: warning: 'struct rtc_time' declared inside parameter list include/asm/rtc.h:23: warning: 'struct rtc_wkalrm' declared inside parameter list include/asm/rtc.h:24: warning: 'struct rtc_wkalrm' declared inside parameter list include/asm/rtc.h:28: warning: 'struct rtc_time' declared inside parameter list include/asm/rtc.h:33: warning: 'struct rtc_time' declared inside parameter list include/asm/rtc.h: In function 'rtc_periodic_alarm': include/asm/rtc.h:35: error: dereferencing pointer to incomplete type include/asm/rtc.h:36: error: dereferencing pointer to incomplete type include/asm/rtc.h:37: error: dereferencing pointer to incomplete type include/asm/rtc.h:38: error: dereferencing pointer to incomplete type include/asm/rtc.h:39: error: dereferencing pointer to incomplete type include/asm/rtc.h:40: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c: At top level: drivers/rtc/rtc-cmos.c:63: warning: 'struct rtc_time' declared inside parameter list drivers/rtc/rtc-cmos.c: In function 'cmos_read_time': drivers/rtc/rtc-cmos.c:69: warning: implicit declaration of function 'get_rtc_time' drivers/rtc/rtc-cmos.c: At top level: drivers/rtc/rtc-cmos.c:73: warning: 'struct rtc_time' declared inside parameter list drivers/rtc/rtc-cmos.c: In function 'cmos_set_time': drivers/rtc/rtc-cmos.c:81: warning: implicit declaration of function 'set_rtc_time' drivers/rtc/rtc-cmos.c: At top level: drivers/rtc/rtc-cmos.c:84: warning: 'struct rtc_wkalrm' declared inside parameter list drivers/rtc/rtc-cmos.c: In function 'cmos_read_alarm': drivers/rtc/rtc-cmos.c:96: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c:97: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c:99: error: 'rtc_lock' undeclared (first use in this function) drivers/rtc/rtc-cmos.c:99: error: (Each undeclared identifier is reported only once drivers/rtc/rtc-cmos.c:99: error: for each function it appears in.) drivers/rtc/rtc-cmos.c:100: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c:100: warning: implicit declaration of function 'CMOS_READ' drivers/rtc/rtc-cmos.c:100: error: 'RTC_SECONDS_ALARM' undeclared (first use in this function) drivers/rtc/rtc-cmos.c:101: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c:101: error: 'RTC_MINUTES_ALARM' undeclared (first use in this function) CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/compile.h CHK include/linux/utsrelease.h CC arch/arm/common/rtctime.o arch/arm/common/rtctime.c:34: error: static declaration of
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
Russell King wrote: On Sat, Jan 06, 2007 at 01:17:25PM -0800, David Brownell wrote: On Saturday 06 January 2007 9:17 am, Woody Suwalski wrote: There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. ... Let me put that differently. That should be done as a separate patch, adding (a) that platform_device, and maybe platform_data if it's got additional alarm registers, and (b) Kconfig support to let that work. I'd call it a patch #4 of 3. ;) ... I will try to play with the new code on Monday on ARM... Thanks. Could you describe your ARM board? None of mine have an RTC using this register API. Does it support system sleep states (/sys/power/state) with a wakeup-capable (enable_irq_wake) RTC irq? Woody will be using a Netwinder (he's part of the original development team.) So no sleep states and therefore no wakeup. There's various other ARM-based systems using the PC RTC, but none of them have sleep or wakeup abilities afaik. I think that Russell is correct - the RTC is just part of a Winbond multifunction chip. It has no special wake-up or alarm hooks (as far as I remember). As to the patch: applied to 2.6.20-rc4, both on PC and ARM, commented out EXPERIMENTAL... To build your new patch for ARM I have modified the line depends on RTC_CLASS (X86_PC || ACPI || ARM)... On Netwinder ARM - can not build (see: rtc_build.log) OK, changed the include/asm/rtc.h to look like i386 == include asm-generic/rtc.h Still does not build - see rtc_build2.log Could you please check what other defs are missing on ARM? Thanks, Woody BTW. Current RTC is broken same way on Shark ARM as it is on Netwinder ARM: [EMAIL PROTECTED] As for the RTC patch, it does work on the shark, and is needed. So is there a reason to have RTC build blocked on all ARM? CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/compile.h CHK include/linux/utsrelease.h CC [M] drivers/rtc/rtc-cmos.o In file included from drivers/rtc/rtc-cmos.c:39: include/asm/rtc.h:21: warning: 'struct rtc_time' declared inside parameter list include/asm/rtc.h:21: warning: its scope is only this definition or declaration, which is probably not what you want include/asm/rtc.h:22: warning: 'struct rtc_time' declared inside parameter list include/asm/rtc.h:23: warning: 'struct rtc_wkalrm' declared inside parameter list include/asm/rtc.h:24: warning: 'struct rtc_wkalrm' declared inside parameter list include/asm/rtc.h:28: warning: 'struct rtc_time' declared inside parameter list include/asm/rtc.h:33: warning: 'struct rtc_time' declared inside parameter list include/asm/rtc.h: In function 'rtc_periodic_alarm': include/asm/rtc.h:35: error: dereferencing pointer to incomplete type include/asm/rtc.h:36: error: dereferencing pointer to incomplete type include/asm/rtc.h:37: error: dereferencing pointer to incomplete type include/asm/rtc.h:38: error: dereferencing pointer to incomplete type include/asm/rtc.h:39: error: dereferencing pointer to incomplete type include/asm/rtc.h:40: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c: At top level: drivers/rtc/rtc-cmos.c:63: warning: 'struct rtc_time' declared inside parameter list drivers/rtc/rtc-cmos.c: In function 'cmos_read_time': drivers/rtc/rtc-cmos.c:69: warning: implicit declaration of function 'get_rtc_time' drivers/rtc/rtc-cmos.c: At top level: drivers/rtc/rtc-cmos.c:73: warning: 'struct rtc_time' declared inside parameter list drivers/rtc/rtc-cmos.c: In function 'cmos_set_time': drivers/rtc/rtc-cmos.c:81: warning: implicit declaration of function 'set_rtc_time' drivers/rtc/rtc-cmos.c: At top level: drivers/rtc/rtc-cmos.c:84: warning: 'struct rtc_wkalrm' declared inside parameter list drivers/rtc/rtc-cmos.c: In function 'cmos_read_alarm': drivers/rtc/rtc-cmos.c:96: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c:97: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c:99: error: 'rtc_lock' undeclared (first use in this function) drivers/rtc/rtc-cmos.c:99: error: (Each undeclared identifier is reported only once drivers/rtc/rtc-cmos.c:99: error: for each function it appears in.) drivers/rtc/rtc-cmos.c:100: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c:100: warning: implicit declaration of function 'CMOS_READ' drivers/rtc/rtc-cmos.c:100: error: 'RTC_SECONDS_ALARM' undeclared (first use in this function) drivers/rtc/rtc-cmos.c:101: error: dereferencing pointer to incomplete type drivers/rtc/rtc-cmos.c:101: error: 'RTC_MINUTES_ALARM' undeclared (first use in this function) CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/compile.h CHK include/linux/utsrelease.h CC arch/arm/common/rtctime.o arch/arm/common/rtctime.c:34: error: static declaration of 'rtc_lock'
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Tuesday 09 January 2007 8:37 am, Woody Suwalski wrote: As to the patch: applied to 2.6.20-rc4, both on PC and ARM, commented out EXPERIMENTAL... To build your new patch for ARM I have modified the line depends on RTC_CLASS (X86_PC || ACPI || ARM)... On Netwinder ARM - can not build (see: rtc_build.log) Heh, so it's a good thing I disabled the build there. :) OK, changed the include/asm/rtc.h to look like i386 == include asm-generic/rtc.h In drivers/rtc/rtc-cmos.c I hope ... asm/rtc.h seems to not give equivalent functionality even on platforms which have it. Looks to me like asm-generic/rtc.h is the right solution, though that still implies arch-level support for asm/mc146818rtc.h which does not exist on all platforms. So the attached version of the rtc-cmos patch uses asm-generic and also adds Kconfig dependencies for architectures with usable versions of that header. Of course, the right answer is to make this be like any other driver and allow the registers to go anywhere in the address space, not hard-wiring them to a platform-specific I/O space address. That is, CMOS_READ/CMOS_WRITE are legacy baggage. But that's not an issue to be addressed by this particular patch. Still does not build - see rtc_build2.log Could you please check what other defs are missing on ARM? I'm not sure what you changed. I updated the rtc-cmos patch to use asm-generic/rtc.h directly, then did an ARM build which configured that driver as a module. No compile-time problems. (I think you changed the wrong file...) But at link time I ran into the problem that arm/kernel/time.c defines rtc_lock but only exports it to an obsolete SA1100 driver. See attached rtc-arm.patch. But static linking was no problem ... of course, I didn't add any code to define the platform_device (with or without the platform_data teling about extra registers) and couldn't test anything other than the build. [EMAIL PROTECTED] As for the RTC patch, it does work on the shark, and is needed. So is there a reason to have RTC build blocked on all ARM? The original reason was that it's not known to work. Given the attached patches, that issue is resolved at least from the build perspective. - Dave Fix build problem on ARM ... the only user of rtc_lock today is the optional PC-style CMOS RTC driver, not the legacy SA1100 RTC driver. Signed-off-by: David Brownell [EMAIL PROTECTED] Index: at91/arch/arm/kernel/time.c === --- at91.orig/arch/arm/kernel/time.c 2006-11-10 09:47:46.0 -0800 +++ at91/arch/arm/kernel/time.c 2007-01-09 15:08:39.0 -0800 @@ -38,12 +38,14 @@ */ struct sys_timer *system_timer; +#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) /* this needs a better home */ DEFINE_SPINLOCK(rtc_lock); -#ifdef CONFIG_SA1100_RTC_MODULE +#ifdef CONFIG_RTC_DRV_CMOS_MODULE EXPORT_SYMBOL(rtc_lock); #endif +#endif /* pc-style 'CMOS' RTC support */ /* change this if you have some constant time drift */ #define USECS_PER_JIFFY (100/HZ) This is an RTC framework driver for the CMOS RTCs which are standard on PCs and some other platforms. That's MC146818 compatible silicon. Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only one will be able to claim the RTC irq) include: - This leverages both the new RTC framework and the driver model; both PNPACPI and platform device modes are supported. (A separate patch creates a platform device on PCs where PNPACPI isn't configured.) - It supports common extensions like longer alarms. (A separate patch exports that information from ACPI through platform_data.) - Likewise, system wakeup events use real driver model support, with policy control via sysfs wakeup attributes and and using normal rtc ioctls to manage wakeup. (Patch in the works. The ACPI hooks are known; /proc/acpi/alarm can vanish. Making it work with EFI will be a minor challenge to someone with e.g. a MiniMac.) It's not yet been tested on non-x86 systems, without ACPI, or with HPET. And the RTC framework will surely have teething pains on mainstream PC-based systems (though must embedded Linux systems use it heavily), not limited to sorting out the /dev/rtc0 issue (udev easily tweaked). Also, the ALSA rtctimer code doesn't use the new RTC API. Otherwise, this should be a no-known-regressions replacement for the old drivers/char/rtc.c driver, and should help the non-embedded distros (and the new timekeeping code) start to switch to the framework. Signed-off-by: David Brownell [EMAIL PROTECTED] --- Note also that any systems using rtc-m48t86 are candidates to switch over to this more functional driver; the platform data is different, and the way bytes are read is different (no CMOS_READ/CMOS_WRITE, or even normal readb and writeb), but otherwise those chips should be compatible. drivers/rtc/Kconfig | 13 drivers/rtc/Makefile
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Tuesday 09 January 2007 4:01 pm, David Brownell wrote:
So the attached version of the rtc-cmos patch uses asm-generic
and also adds Kconfig dependencies for architectures with usable
versions of that header.
No really ... _this_ version. I seem to have too many versions
floating around, in too many different trees.
This is an RTC framework driver for the CMOS RTCs which are standard
on PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use real driver model support, with
policy control via sysfs wakeup attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on mainstream
PC-based systems (though must embedded Linux systems use it heavily),
not limited to sorting out the /dev/rtc0 issue (udev easily tweaked).
Also, the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the
old drivers/char/rtc.c driver, and should help the non-embedded distros
(and the new timekeeping code) start to switch to the framework.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Note also that any systems using rtc-m48t86 are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
drivers/rtc/Kconfig | 13
drivers/rtc/Makefile|1
drivers/rtc/rtc-cmos.c | 718
include/linux/mc146818rtc.h | 10
4 files changed, 742 insertions(+)
Index: g26/drivers/rtc/Kconfig
===
--- g26.orig/drivers/rtc/Kconfig 2007-01-07 17:42:43.0 -0800
+++ g26/drivers/rtc/Kconfig 2007-01-09 15:41:06.0 -0800
@@ -95,6 +95,29 @@ config RTC_INTF_DEV_UIE_EMUL
comment RTC drivers
depends on RTC_CLASS
+# this 'CMOS' RTC driver is arch dependent because asm-generic/rtc.h
+# requires asm/mc146818rtc.h defining CMOS_READ/CMOS_WRITE, and a
+# global rtc_lock ... it's not yet just another platform_device.
+
+config RTC_DRV_CMOS
+ tristate PC-style 'CMOS' real time clock
+ depends on RTC_CLASS (X86_PC || ALPHA || ARM26 || ARM \
+ || M32R || ATARI || POWERPC || SPARC64 || SPARC)
+ help
+ Say yes here to get direct support for the real time clock
+ found in every PC or ACPI-based system, and some other boards.
+ Specifically the original MC146818, compatibles like those in
+ PC south bridges, the DS12887 or M48T86, some multifunction
+ or LPC bus chips, and so on.
+
+ Your system will need to define the platform device used by
+ this driver, otherwise it won't be accessible. This means
+ you can safely enable this driver if you don't know whether
+ or not your board has this kind of hardware.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-cmos.
+
config RTC_DRV_X1205
tristate Xicor/Intersil X1205
depends on RTC_CLASS I2C
Index: g26/drivers/rtc/Makefile
===
--- g26.orig/drivers/rtc/Makefile 2007-01-07 17:42:43.0 -0800
+++ g26/drivers/rtc/Makefile 2007-01-07 17:54:21.0 -0800
@@ -15,6 +15,7 @@ obj-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysf
obj-$(CONFIG_RTC_INTF_PROC) += rtc-proc.o
obj-$(CONFIG_RTC_INTF_DEV) += rtc-dev.o
+obj-$(CONFIG_RTC_DRV_CMOS) += rtc-cmos.o
obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o
obj-$(CONFIG_RTC_DRV_TEST) += rtc-test.o
Index: g26/include/linux/mc146818rtc.h
===
--- g26.orig/include/linux/mc146818rtc.h 2007-01-07 17:42:43.0 -0800
+++ g26/include/linux/mc146818rtc.h 2007-01-07 17:54:21.0 -0800
@@ -18,6 +18,16 @@
#ifdef __KERNEL__
#include linux/spinlock.h /* spinlock_t */
extern spinlock_t rtc_lock; /* serialize CMOS RAM access */
+
+/* Some RTCs extend the mc146818 register set to support alarms of more
+ * than 24 hours in the future; or dates that include a century code.
+ * This platform_data structure can pass this information to the driver.
+ */
+struct cmos_rtc_board_info {
+ u8 rtc_day_alarm; /* zero,
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Sat, Jan 06, 2007 at 01:17:25PM -0800, David Brownell wrote: > On Saturday 06 January 2007 9:17 am, Woody Suwalski wrote: > > >> There are PPC, M68K, SPARC, and other boards that could also > > >> use this; ARMs tend to integrate some other RTC on-chip. ... > > > > > Let me put that differently. That should be done as a separate > > > patch, adding (a) that platform_device, and maybe platform_data > > > if it's got additional alarm registers, and (b) Kconfig support > > > to let that work. I'd call it a "patch #4 of 3". ;) > > > ... > > > > I will try to play with the new code on Monday on ARM... > > Thanks. Could you describe your ARM board? None of mine have an > RTC using this register API. Does it support system sleep states > (/sys/power/state) with a wakeup-capable (enable_irq_wake) RTC irq? Woody will be using a Netwinder (he's part of the original development team.) So no sleep states and therefore no wakeup. There's various other ARM-based systems using the PC RTC, but none of them have sleep or wakeup abilities afaik. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Sat, Jan 06, 2007 at 01:17:25PM -0800, David Brownell wrote: On Saturday 06 January 2007 9:17 am, Woody Suwalski wrote: There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. ... Let me put that differently. That should be done as a separate patch, adding (a) that platform_device, and maybe platform_data if it's got additional alarm registers, and (b) Kconfig support to let that work. I'd call it a patch #4 of 3. ;) ... I will try to play with the new code on Monday on ARM... Thanks. Could you describe your ARM board? None of mine have an RTC using this register API. Does it support system sleep states (/sys/power/state) with a wakeup-capable (enable_irq_wake) RTC irq? Woody will be using a Netwinder (he's part of the original development team.) So no sleep states and therefore no wakeup. There's various other ARM-based systems using the PC RTC, but none of them have sleep or wakeup abilities afaik. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Saturday 06 January 2007 9:17 am, Woody Suwalski wrote: > >> There are PPC, M68K, SPARC, and other boards that could also > >> use this; ARMs tend to integrate some other RTC on-chip. ... > > > Let me put that differently. That should be done as a separate > > patch, adding (a) that platform_device, and maybe platform_data > > if it's got additional alarm registers, and (b) Kconfig support > > to let that work. I'd call it a "patch #4 of 3". ;) > > ... > > I will try to play with the new code on Monday on ARM... Thanks. Could you describe your ARM board? None of mine have an RTC using this register API. Does it support system sleep states (/sys/power/state) with a wakeup-capable (enable_irq_wake) RTC irq? - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
David Brownell wrote: On Friday 05 January 2007 7:10 pm, David Brownell wrote: On Friday 05 January 2007 12:45 pm, Alessandro Zummo wrote: I'd appreciate if someone (Woody?) can test this code on ARM. There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. But on whatever non-PC platform is involved in such sanity testing, that involves adding a platform_device to board setup code. Let me put that differently. That should be done as a separate patch, adding (a) that platform_device, and maybe platform_data if it's got additional alarm registers, and (b) Kconfig support to let that work. I'd call it a "patch #4 of 3". ;) The current Kconfig uses: +config RTC_DRV_CMOS + tristate "CMOS real time clock" + depends on RTC_CLASS && (X86_PC || ACPI) Eventually maybe the PC-or-ACPI stuff should vanish, but IMO not until this code has been used on a few other platforms. - Dave I will try to play with the new code on Monday on ARM... Thanks, Woody - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
David Brownell wrote: On Friday 05 January 2007 7:10 pm, David Brownell wrote: On Friday 05 January 2007 12:45 pm, Alessandro Zummo wrote: I'd appreciate if someone (Woody?) can test this code on ARM. There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. But on whatever non-PC platform is involved in such sanity testing, that involves adding a platform_device to board setup code. Let me put that differently. That should be done as a separate patch, adding (a) that platform_device, and maybe platform_data if it's got additional alarm registers, and (b) Kconfig support to let that work. I'd call it a patch #4 of 3. ;) The current Kconfig uses: +config RTC_DRV_CMOS + tristate CMOS real time clock + depends on RTC_CLASS (X86_PC || ACPI) Eventually maybe the PC-or-ACPI stuff should vanish, but IMO not until this code has been used on a few other platforms. - Dave I will try to play with the new code on Monday on ARM... Thanks, Woody - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Saturday 06 January 2007 9:17 am, Woody Suwalski wrote: There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. ... Let me put that differently. That should be done as a separate patch, adding (a) that platform_device, and maybe platform_data if it's got additional alarm registers, and (b) Kconfig support to let that work. I'd call it a patch #4 of 3. ;) ... I will try to play with the new code on Monday on ARM... Thanks. Could you describe your ARM board? None of mine have an RTC using this register API. Does it support system sleep states (/sys/power/state) with a wakeup-capable (enable_irq_wake) RTC irq? - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Friday 05 January 2007 7:10 pm, David Brownell wrote: > On Friday 05 January 2007 12:45 pm, Alessandro Zummo wrote: > > I'd appreciate if someone (Woody?) can test > > this code on ARM. > > There are PPC, M68K, SPARC, and other boards that could also > use this; ARMs tend to integrate some other RTC on-chip. But > on whatever non-PC platform is involved in such sanity testing, > that involves adding a platform_device to board setup code. Let me put that differently. That should be done as a separate patch, adding (a) that platform_device, and maybe platform_data if it's got additional alarm registers, and (b) Kconfig support to let that work. I'd call it a "patch #4 of 3". ;) The current Kconfig uses: > +config RTC_DRV_CMOS > + tristate "CMOS real time clock" > + depends on RTC_CLASS && (X86_PC || ACPI) Eventually maybe the PC-or-ACPI stuff should vanish, but IMO not until this code has been used on a few other platforms. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Friday 05 January 2007 12:45 pm, Alessandro Zummo wrote: > On Fri, 5 Jan 2007 10:01:57 -0800 > David Brownell <[EMAIL PROTECTED]> wrote: > > > This is an "RTC framework" driver for the "CMOS" RTCs which are standard > > on PCs and some other platforms. That's MC146818 compatible silicon. > > Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only > > one will be able to claim the RTC irq) include: > > Hi David, > > good code and well commented, thank you. Glad to hear it! > I only have some comments: > > - I would put anything that is x86 related (pnp,acpi) > in a separate file so that people working on > non x86 systems can have a better grasp of the driver. I believe that splitting this driver into multiple files would create more confusion confusion than it solves. Bus glue is actually a very small part of the code, and it's cleanly split out. So I'm not keen on this change at all. And having done a grep of the source tree, splitting out PNP bus glue (and platform bus glue?) into a separate file isn't common. IDE does, and 8250; both cases with a *very* complex core, shared with many drivers. But the normal case #ifdefs PNP support, combining it with alternative bus glue which is all too often nasty legacy "probe the hardware" logic. (Also: there are no longer any ACPI calls in this driver; and do recall that at least ia64 uses ACPI too. So _none_ of that code is x86-specific...) > - the name should be rtc-mc146818 to be coherent with > the other drivers, but this can cause confusion. Yes, I used the "rtc-cmos" name to minimize confusion. It's a generic name; I've even seen multiple books, including some southbridge docs, talking about "CMOS RTC" or "CMOS clock". "MC146818" is easy to mistype, hard to say, obsolete (!), and virtually unused in most technical contexts. But "cmos clock" is widely understood, at least in PC-derived contexts, and make sense talking about most any southbridge. I guess I'm surprised you called rtc-m48t86 that, instead of using the name rtc-mc146818 (since ST markets that M48 chip as a replacement for the mc146818)... :) I'm not deeply attached to this name, but I couldn't come up with a better generic name. > - please put yourself in MODULE_AUTHOR OK. Appended. > other than that, I'm fine with the code. > > I'd appreciate if someone (Woody?) can test > this code on ARM. There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. But on whatever non-PC platform is involved in such sanity testing, that involves adding a platform_device to board setup code. - Dave == CUT HERE This is an "RTC framework" driver for the "CMOS" RTCs which are standard on PCs and some other platforms. That's MC146818 compatible silicon. Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only one will be able to claim the RTC irq) include: - This leverages both the new RTC framework and the driver model; both PNPACPI and platform device modes are supported. (A separate patch creates a platform device on PCs where PNPACPI isn't configured.) - It supports common extensions like longer alarms. (A separate patch exports that information from ACPI through platform_data.) - Likewise, system wakeup events use "real driver model support", with policy control via sysfs "wakeup" attributes and and using normal rtc ioctls to manage wakeup. (Patch in the works. The ACPI hooks are known; /proc/acpi/alarm can vanish. Making it work with EFI will be a minor challenge to someone with e.g. a MiniMac.) It's not yet been tested on non-x86 systems, without ACPI, or with HPET. And the RTC framework will surely have teething pains on "mainstream" PC-based systems (though must embedded Linux systems use it heavily), not limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also, the ALSA rtctimer code doesn't use the new RTC API. Otherwise, this should be a no-known-regressions replacement for the old drivers/char/rtc.c driver, and should help the non-embedded distros (and the new timekeeping code) start to switch to the framework. Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- Note also that any systems using "rtc-m48t86" are candidates to switch over to this more functional driver; the platform data is different, and the way bytes are read is different, but otherwise those chips should be compatible. drivers/rtc/Kconfig | 13 drivers/rtc/Makefile|1 drivers/rtc/rtc-cmos.c | 718 include/linux/mc146818rtc.h | 10 4 files changed, 742 insertions(+) Index: g26/drivers/rtc/Kconfig === --- g26.orig/drivers/rtc/Kconfig2007-01-02 19:24:32.0 -0800 +++ g26/drivers/rtc/Kconfig 2007-01-02 23:35:41.0 -0800 @@ -95,6 +95,19 @@ config RTC_INTF_DEV_UIE_EMUL
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Fri, 5 Jan 2007 10:01:57 -0800 David Brownell <[EMAIL PROTECTED]> wrote: > This is an "RTC framework" driver for the "CMOS" RTCs which are standard > on PCs and some other platforms. That's MC146818 compatible silicon. > Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only > one will be able to claim the RTC irq) include: Hi David, good code and well commented, thank you. I only have some comments: - I would put anything that is x86 related (pnp,acpi) in a separate file so that people working on non x86 systems can have a better grasp of the driver. - the name should be rtc-mc146818 to be coherent with the other drivers, but this can cause confusion. - please put yourself in MODULE_AUTHOR other than that, I'm fine with the code. I'd appreciate if someone (Woody?) can test this code on ARM. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.20-rc3 1/3] rtc-cmos driver
This is an "RTC framework" driver for the "CMOS" RTCs which are standard
on PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily),
not limited to sorting out the "/dev/rtc0" issue (udev easily tweaked).
Also, the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the
old drivers/char/rtc.c driver, and should help the non-embedded distros
(and the new timekeeping code) start to switch to the framework.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
drivers/rtc/Kconfig | 13
drivers/rtc/Makefile|1
drivers/rtc/rtc-cmos.c | 718
include/linux/mc146818rtc.h | 10
4 files changed, 742 insertions(+)
Index: g26/drivers/rtc/Kconfig
===
--- g26.orig/drivers/rtc/Kconfig2006-12-27 18:21:01.0 -0800
+++ g26/drivers/rtc/Kconfig 2006-12-28 01:38:47.0 -0800
@@ -95,6 +95,19 @@ config RTC_INTF_DEV_UIE_EMUL
comment "RTC drivers"
depends on RTC_CLASS
+config RTC_DRV_CMOS
+ tristate "CMOS real time clock"
+ depends on RTC_CLASS && (X86_PC || ACPI)
+ help
+ Say "yes" here to get direct support for the real time clock
+ found in every PC or ACPI-based system, and some others.
+ Specifically the original MC146818, compatibles like those
+ in PC south bridges, the DS12887 or M48T86, some LPC bus
+ chips, and so on.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-cmos.
+
config RTC_DRV_X1205
tristate "Xicor/Intersil X1205"
depends on RTC_CLASS && I2C
Index: g26/drivers/rtc/Makefile
===
--- g26.orig/drivers/rtc/Makefile 2006-12-27 13:49:11.0 -0800
+++ g26/drivers/rtc/Makefile2006-12-27 18:21:02.0 -0800
@@ -15,6 +15,7 @@ obj-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysf
obj-$(CONFIG_RTC_INTF_PROC)+= rtc-proc.o
obj-$(CONFIG_RTC_INTF_DEV) += rtc-dev.o
+obj-$(CONFIG_RTC_DRV_CMOS) += rtc-cmos.o
obj-$(CONFIG_RTC_DRV_X1205)+= rtc-x1205.o
obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o
obj-$(CONFIG_RTC_DRV_TEST) += rtc-test.o
Index: g26/include/linux/mc146818rtc.h
===
--- g26.orig/include/linux/mc146818rtc.h2006-12-27 13:49:11.0
-0800
+++ g26/include/linux/mc146818rtc.h 2006-12-28 01:21:20.0 -0800
@@ -18,6 +18,16 @@
#ifdef __KERNEL__
#include /* spinlock_t */
extern spinlock_t rtc_lock;/* serialize CMOS RAM access */
+
+/* Some RTCs extend the mc146818 register set to support alarms of more
+ * than 24 hours in the future; or dates that include a century code.
+ * This platform_data structure can pass this information to the driver.
+ */
+struct cmos_rtc_board_info {
+ u8 rtc_day_alarm; /* zero, or register index */
+ u8 rtc_mon_alarm; /* zero, or register index */
+ u8 rtc_century;/* zero, or register index */
+};
#endif
/**
Index: g26/drivers/rtc/rtc-cmos.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/drivers/rtc/rtc-cmos.c 2006-12-28 01:30:33.0 -0800
@@ -0,0 +1,718 @@
+/*
+ * RTC class driver for "CMOS RTC": PCs, ACPI, etc
+ *
+ * Copyright (C) 1996 Paul Gortmaker (drivers/char/rtc.c)
+ * Copyright (C) 2006 David Brownell (convert to new framework)
+ *
+ * This program
[patch 2.6.20-rc3 1/3] rtc-cmos driver
This is an RTC framework driver for the CMOS RTCs which are standard
on PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use real driver model support, with
policy control via sysfs wakeup attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on mainstream
PC-based systems (though must embedded Linux systems use it heavily),
not limited to sorting out the /dev/rtc0 issue (udev easily tweaked).
Also, the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the
old drivers/char/rtc.c driver, and should help the non-embedded distros
(and the new timekeeping code) start to switch to the framework.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Note also that any systems using rtc-m48t86 are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
drivers/rtc/Kconfig | 13
drivers/rtc/Makefile|1
drivers/rtc/rtc-cmos.c | 718
include/linux/mc146818rtc.h | 10
4 files changed, 742 insertions(+)
Index: g26/drivers/rtc/Kconfig
===
--- g26.orig/drivers/rtc/Kconfig2006-12-27 18:21:01.0 -0800
+++ g26/drivers/rtc/Kconfig 2006-12-28 01:38:47.0 -0800
@@ -95,6 +95,19 @@ config RTC_INTF_DEV_UIE_EMUL
comment RTC drivers
depends on RTC_CLASS
+config RTC_DRV_CMOS
+ tristate CMOS real time clock
+ depends on RTC_CLASS (X86_PC || ACPI)
+ help
+ Say yes here to get direct support for the real time clock
+ found in every PC or ACPI-based system, and some others.
+ Specifically the original MC146818, compatibles like those
+ in PC south bridges, the DS12887 or M48T86, some LPC bus
+ chips, and so on.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-cmos.
+
config RTC_DRV_X1205
tristate Xicor/Intersil X1205
depends on RTC_CLASS I2C
Index: g26/drivers/rtc/Makefile
===
--- g26.orig/drivers/rtc/Makefile 2006-12-27 13:49:11.0 -0800
+++ g26/drivers/rtc/Makefile2006-12-27 18:21:02.0 -0800
@@ -15,6 +15,7 @@ obj-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysf
obj-$(CONFIG_RTC_INTF_PROC)+= rtc-proc.o
obj-$(CONFIG_RTC_INTF_DEV) += rtc-dev.o
+obj-$(CONFIG_RTC_DRV_CMOS) += rtc-cmos.o
obj-$(CONFIG_RTC_DRV_X1205)+= rtc-x1205.o
obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o
obj-$(CONFIG_RTC_DRV_TEST) += rtc-test.o
Index: g26/include/linux/mc146818rtc.h
===
--- g26.orig/include/linux/mc146818rtc.h2006-12-27 13:49:11.0
-0800
+++ g26/include/linux/mc146818rtc.h 2006-12-28 01:21:20.0 -0800
@@ -18,6 +18,16 @@
#ifdef __KERNEL__
#include linux/spinlock.h/* spinlock_t */
extern spinlock_t rtc_lock;/* serialize CMOS RAM access */
+
+/* Some RTCs extend the mc146818 register set to support alarms of more
+ * than 24 hours in the future; or dates that include a century code.
+ * This platform_data structure can pass this information to the driver.
+ */
+struct cmos_rtc_board_info {
+ u8 rtc_day_alarm; /* zero, or register index */
+ u8 rtc_mon_alarm; /* zero, or register index */
+ u8 rtc_century;/* zero, or register index */
+};
#endif
/**
Index: g26/drivers/rtc/rtc-cmos.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/drivers/rtc/rtc-cmos.c 2006-12-28 01:30:33.0 -0800
@@ -0,0 +1,718 @@
+/*
+ * RTC class driver for CMOS RTC: PCs, ACPI, etc
+ *
+ * Copyright (C) 1996 Paul Gortmaker (drivers/char/rtc.c)
+ * Copyright (C) 2006 David Brownell (convert to new framework)
+ *
+ * This program is free
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Fri, 5 Jan 2007 10:01:57 -0800 David Brownell [EMAIL PROTECTED] wrote: This is an RTC framework driver for the CMOS RTCs which are standard on PCs and some other platforms. That's MC146818 compatible silicon. Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only one will be able to claim the RTC irq) include: Hi David, good code and well commented, thank you. I only have some comments: - I would put anything that is x86 related (pnp,acpi) in a separate file so that people working on non x86 systems can have a better grasp of the driver. - the name should be rtc-mc146818 to be coherent with the other drivers, but this can cause confusion. - please put yourself in MODULE_AUTHOR other than that, I'm fine with the code. I'd appreciate if someone (Woody?) can test this code on ARM. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Friday 05 January 2007 12:45 pm, Alessandro Zummo wrote: On Fri, 5 Jan 2007 10:01:57 -0800 David Brownell [EMAIL PROTECTED] wrote: This is an RTC framework driver for the CMOS RTCs which are standard on PCs and some other platforms. That's MC146818 compatible silicon. Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only one will be able to claim the RTC irq) include: Hi David, good code and well commented, thank you. Glad to hear it! I only have some comments: - I would put anything that is x86 related (pnp,acpi) in a separate file so that people working on non x86 systems can have a better grasp of the driver. I believe that splitting this driver into multiple files would create more confusion confusion than it solves. Bus glue is actually a very small part of the code, and it's cleanly split out. So I'm not keen on this change at all. And having done a grep of the source tree, splitting out PNP bus glue (and platform bus glue?) into a separate file isn't common. IDE does, and 8250; both cases with a *very* complex core, shared with many drivers. But the normal case #ifdefs PNP support, combining it with alternative bus glue which is all too often nasty legacy probe the hardware logic. (Also: there are no longer any ACPI calls in this driver; and do recall that at least ia64 uses ACPI too. So _none_ of that code is x86-specific...) - the name should be rtc-mc146818 to be coherent with the other drivers, but this can cause confusion. Yes, I used the rtc-cmos name to minimize confusion. It's a generic name; I've even seen multiple books, including some southbridge docs, talking about CMOS RTC or CMOS clock. MC146818 is easy to mistype, hard to say, obsolete (!), and virtually unused in most technical contexts. But cmos clock is widely understood, at least in PC-derived contexts, and make sense talking about most any southbridge. I guess I'm surprised you called rtc-m48t86 that, instead of using the name rtc-mc146818 (since ST markets that M48 chip as a replacement for the mc146818)... :) I'm not deeply attached to this name, but I couldn't come up with a better generic name. - please put yourself in MODULE_AUTHOR OK. Appended. other than that, I'm fine with the code. I'd appreciate if someone (Woody?) can test this code on ARM. There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. But on whatever non-PC platform is involved in such sanity testing, that involves adding a platform_device to board setup code. - Dave == CUT HERE This is an RTC framework driver for the CMOS RTCs which are standard on PCs and some other platforms. That's MC146818 compatible silicon. Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only one will be able to claim the RTC irq) include: - This leverages both the new RTC framework and the driver model; both PNPACPI and platform device modes are supported. (A separate patch creates a platform device on PCs where PNPACPI isn't configured.) - It supports common extensions like longer alarms. (A separate patch exports that information from ACPI through platform_data.) - Likewise, system wakeup events use real driver model support, with policy control via sysfs wakeup attributes and and using normal rtc ioctls to manage wakeup. (Patch in the works. The ACPI hooks are known; /proc/acpi/alarm can vanish. Making it work with EFI will be a minor challenge to someone with e.g. a MiniMac.) It's not yet been tested on non-x86 systems, without ACPI, or with HPET. And the RTC framework will surely have teething pains on mainstream PC-based systems (though must embedded Linux systems use it heavily), not limited to sorting out the /dev/rtc0 issue (udev easily tweaked). Also, the ALSA rtctimer code doesn't use the new RTC API. Otherwise, this should be a no-known-regressions replacement for the old drivers/char/rtc.c driver, and should help the non-embedded distros (and the new timekeeping code) start to switch to the framework. Signed-off-by: David Brownell [EMAIL PROTECTED] --- Note also that any systems using rtc-m48t86 are candidates to switch over to this more functional driver; the platform data is different, and the way bytes are read is different, but otherwise those chips should be compatible. drivers/rtc/Kconfig | 13 drivers/rtc/Makefile|1 drivers/rtc/rtc-cmos.c | 718 include/linux/mc146818rtc.h | 10 4 files changed, 742 insertions(+) Index: g26/drivers/rtc/Kconfig === --- g26.orig/drivers/rtc/Kconfig2007-01-02 19:24:32.0 -0800 +++ g26/drivers/rtc/Kconfig 2007-01-02 23:35:41.0 -0800 @@ -95,6 +95,19 @@ config RTC_INTF_DEV_UIE_EMUL comment RTC drivers depends on RTC_CLASS +config
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Friday 05 January 2007 7:10 pm, David Brownell wrote: On Friday 05 January 2007 12:45 pm, Alessandro Zummo wrote: I'd appreciate if someone (Woody?) can test this code on ARM. There are PPC, M68K, SPARC, and other boards that could also use this; ARMs tend to integrate some other RTC on-chip. But on whatever non-PC platform is involved in such sanity testing, that involves adding a platform_device to board setup code. Let me put that differently. That should be done as a separate patch, adding (a) that platform_device, and maybe platform_data if it's got additional alarm registers, and (b) Kconfig support to let that work. I'd call it a patch #4 of 3. ;) The current Kconfig uses: +config RTC_DRV_CMOS + tristate CMOS real time clock + depends on RTC_CLASS (X86_PC || ACPI) Eventually maybe the PC-or-ACPI stuff should vanish, but IMO not until this code has been used on a few other platforms. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
