[PATCH] RTC framework driver for CMOS RTCs
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.
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.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
#
|
2006-03-27 17:16:34 +08:00
|
|
|
# RTC class/drivers configuration
|
|
|
|
#
|
|
|
|
|
2006-03-27 17:16:37 +08:00
|
|
|
menu "Real Time Clock"
|
|
|
|
|
2006-03-27 17:16:34 +08:00
|
|
|
config RTC_LIB
|
2006-03-27 17:16:37 +08:00
|
|
|
tristate
|
|
|
|
|
|
|
|
config RTC_CLASS
|
|
|
|
tristate "RTC class"
|
|
|
|
depends on EXPERIMENTAL
|
|
|
|
default n
|
|
|
|
select RTC_LIB
|
|
|
|
help
|
|
|
|
Generic RTC class support. If you say yes here, you will
|
|
|
|
be allowed to plug one or more RTCs to your system. You will
|
2006-07-01 00:18:41 +08:00
|
|
|
probably want to enable one or more of the interfaces below.
|
2006-03-27 17:16:37 +08:00
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-class.
|
|
|
|
|
|
|
|
config RTC_HCTOSYS
|
|
|
|
bool "Set system time from RTC on startup"
|
|
|
|
depends on RTC_CLASS = y
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
If you say yes here, the system time will be set using
|
|
|
|
the value read from the specified RTC device. This is useful
|
2006-09-29 17:01:14 +08:00
|
|
|
in order to avoid unnecessary fsck runs.
|
2006-03-27 17:16:37 +08:00
|
|
|
|
|
|
|
config RTC_HCTOSYS_DEVICE
|
|
|
|
string "The RTC to read the time from"
|
|
|
|
depends on RTC_HCTOSYS = y
|
|
|
|
default "rtc0"
|
|
|
|
help
|
|
|
|
The RTC device that will be used as the source for
|
|
|
|
the system time, usually rtc0.
|
|
|
|
|
2006-10-01 14:28:14 +08:00
|
|
|
config RTC_DEBUG
|
|
|
|
bool "RTC debug support"
|
|
|
|
depends on RTC_CLASS = y
|
|
|
|
help
|
|
|
|
Say yes here to enable debugging support in the RTC framework
|
|
|
|
and individual RTC drivers.
|
|
|
|
|
2006-03-27 17:16:37 +08:00
|
|
|
comment "RTC interfaces"
|
|
|
|
depends on RTC_CLASS
|
|
|
|
|
2006-03-27 17:16:39 +08:00
|
|
|
config RTC_INTF_SYSFS
|
|
|
|
tristate "sysfs"
|
|
|
|
depends on RTC_CLASS && SYSFS
|
|
|
|
default RTC_CLASS
|
|
|
|
help
|
2006-10-01 14:28:14 +08:00
|
|
|
Say yes here if you want to use your RTCs using sysfs interfaces,
|
|
|
|
/sys/class/rtc/rtc0 through /sys/.../rtcN.
|
2006-03-27 17:16:39 +08:00
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-sysfs.
|
|
|
|
|
2006-03-27 17:16:40 +08:00
|
|
|
config RTC_INTF_PROC
|
|
|
|
tristate "proc"
|
|
|
|
depends on RTC_CLASS && PROC_FS
|
|
|
|
default RTC_CLASS
|
|
|
|
help
|
2006-10-01 14:28:14 +08:00
|
|
|
Say yes here if you want to use your first RTC through the proc
|
|
|
|
interface, /proc/driver/rtc. Other RTCs will not be available
|
|
|
|
through that API.
|
2006-03-27 17:16:40 +08:00
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-proc.
|
|
|
|
|
2006-03-27 17:16:41 +08:00
|
|
|
config RTC_INTF_DEV
|
|
|
|
tristate "dev"
|
|
|
|
depends on RTC_CLASS
|
|
|
|
default RTC_CLASS
|
|
|
|
help
|
2006-10-01 14:28:14 +08:00
|
|
|
Say yes here if you want to use your RTCs using the /dev
|
|
|
|
interfaces, which "udev" sets up as /dev/rtc0 through
|
|
|
|
/dev/rtcN. You may want to set up a symbolic link so one
|
|
|
|
of these can be accessed as /dev/rtc, which is a name
|
|
|
|
expected by "hwclock" and some other programs.
|
2006-03-27 17:16:41 +08:00
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-dev.
|
|
|
|
|
2006-06-25 20:48:17 +08:00
|
|
|
config RTC_INTF_DEV_UIE_EMUL
|
|
|
|
bool "RTC UIE emulation on dev interface"
|
|
|
|
depends on RTC_INTF_DEV
|
|
|
|
help
|
|
|
|
Provides an emulation for RTC_UIE if the underlaying rtc chip
|
2006-10-01 14:28:14 +08:00
|
|
|
driver does not expose RTC_UIE ioctls. Those requests generate
|
|
|
|
once-per-second update interrupts, used for synchronization.
|
2006-06-25 20:48:17 +08:00
|
|
|
|
2006-03-27 17:16:37 +08:00
|
|
|
comment "RTC drivers"
|
|
|
|
depends on RTC_CLASS
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
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.
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.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
# 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"
|
2007-02-21 05:58:07 +08:00
|
|
|
depends on RTC_CLASS && (X86 || ALPHA || ARM26 || ARM \
|
[PATCH] RTC framework driver for CMOS RTCs
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.
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.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|| M32R || ATARI || POWERPC)
|
|
|
|
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.
|
|
|
|
|
2006-03-27 17:16:42 +08:00
|
|
|
config RTC_DRV_X1205
|
|
|
|
tristate "Xicor/Intersil X1205"
|
|
|
|
depends on RTC_CLASS && I2C
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
Xicor/Intersil X1205 RTC chip.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-x1205.
|
|
|
|
|
2006-06-25 20:48:17 +08:00
|
|
|
config RTC_DRV_DS1307
|
|
|
|
tristate "Dallas/Maxim DS1307 and similar I2C RTC chips"
|
|
|
|
depends on RTC_CLASS && I2C
|
|
|
|
help
|
|
|
|
If you say yes here you get support for various compatible RTC
|
|
|
|
chips (often with battery backup) connected with I2C. This driver
|
|
|
|
should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00,
|
|
|
|
and probably other chips. In some cases the RTC must already
|
|
|
|
have been initialized (by manufacturing or a bootloader).
|
|
|
|
|
|
|
|
The first seven registers on these chips hold an RTC, and other
|
|
|
|
registers may add features such as NVRAM, a trickle charger for
|
|
|
|
the RTC/NVRAM backup power, and alarms. This driver may not
|
|
|
|
expose all those available chip features.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-ds1307.
|
|
|
|
|
2006-06-25 20:48:28 +08:00
|
|
|
config RTC_DRV_DS1553
|
|
|
|
tristate "Dallas DS1553"
|
|
|
|
depends on RTC_CLASS
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
Dallas DS1553 timekeeping chip.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-ds1553.
|
|
|
|
|
2006-07-14 15:24:11 +08:00
|
|
|
config RTC_DRV_ISL1208
|
|
|
|
tristate "Intersil 1208"
|
|
|
|
depends on RTC_CLASS && I2C
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
Intersil 1208 RTC chip.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-isl1208.
|
|
|
|
|
2006-03-27 17:16:43 +08:00
|
|
|
config RTC_DRV_DS1672
|
|
|
|
tristate "Dallas/Maxim DS1672"
|
|
|
|
depends on RTC_CLASS && I2C
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
Dallas/Maxim DS1672 timekeeping chip.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-ds1672.
|
|
|
|
|
2006-06-25 20:48:29 +08:00
|
|
|
config RTC_DRV_DS1742
|
2006-12-07 12:39:41 +08:00
|
|
|
tristate "Dallas DS1742/1743"
|
2006-06-25 20:48:29 +08:00
|
|
|
depends on RTC_CLASS
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
2006-12-07 12:39:41 +08:00
|
|
|
Dallas DS1742/1743 timekeeping chip.
|
2006-06-25 20:48:29 +08:00
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-ds1742.
|
|
|
|
|
2006-12-07 12:38:36 +08:00
|
|
|
config RTC_DRV_OMAP
|
|
|
|
tristate "TI OMAP1"
|
|
|
|
depends on RTC_CLASS && ( \
|
|
|
|
ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 )
|
|
|
|
help
|
|
|
|
Say "yes" here to support the real time clock on TI OMAP1 chips.
|
|
|
|
This driver can also be built as a module called rtc-omap.
|
|
|
|
|
2006-03-27 17:16:44 +08:00
|
|
|
config RTC_DRV_PCF8563
|
|
|
|
tristate "Philips PCF8563/Epson RTC8564"
|
|
|
|
depends on RTC_CLASS && I2C
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
Philips PCF8563 RTC chip. The Epson RTC8564
|
|
|
|
should work as well.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-pcf8563.
|
|
|
|
|
2006-06-25 20:48:18 +08:00
|
|
|
config RTC_DRV_PCF8583
|
|
|
|
tristate "Philips PCF8583"
|
|
|
|
depends on RTC_CLASS && I2C
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
Philips PCF8583 RTC chip.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-pcf8583.
|
|
|
|
|
2006-06-28 19:26:47 +08:00
|
|
|
config RTC_DRV_RS5C348
|
|
|
|
tristate "Ricoh RS5C348A/B"
|
|
|
|
depends on RTC_CLASS && SPI
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
Ricoh RS5C348A and RS5C348B RTC chips.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-rs5c348.
|
|
|
|
|
2006-03-27 17:16:45 +08:00
|
|
|
config RTC_DRV_RS5C372
|
|
|
|
tristate "Ricoh RS5C372A/B"
|
|
|
|
depends on RTC_CLASS && I2C
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
Ricoh RS5C372A and RS5C372B RTC chips.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-rs5c372.
|
|
|
|
|
2006-07-01 19:36:26 +08:00
|
|
|
config RTC_DRV_S3C
|
|
|
|
tristate "Samsung S3C series SoC RTC"
|
|
|
|
depends on RTC_CLASS && ARCH_S3C2410
|
|
|
|
help
|
|
|
|
RTC (Realtime Clock) driver for the clock inbuilt into the
|
|
|
|
Samsung S3C24XX series of SoCs. This can provide periodic
|
|
|
|
interrupt rates from 1Hz to 64Hz for user programs, and
|
|
|
|
wakeup from Alarm.
|
|
|
|
|
|
|
|
The driver currently supports the common features on all the
|
|
|
|
S3C24XX range, such as the S3C2410, S3C2412, S3C2413, S3C2440
|
|
|
|
and S3C2442.
|
|
|
|
|
|
|
|
This driver can also be build as a module. If so, the module
|
|
|
|
will be called rtc-s3c.
|
|
|
|
|
2006-03-27 17:16:47 +08:00
|
|
|
config RTC_DRV_M48T86
|
|
|
|
tristate "ST M48T86/Dallas DS12887"
|
|
|
|
depends on RTC_CLASS
|
|
|
|
help
|
|
|
|
If you say Y here you will get support for the
|
|
|
|
ST M48T86 and Dallas DS12887 RTC chips.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-m48t86.
|
|
|
|
|
2006-03-27 17:16:45 +08:00
|
|
|
config RTC_DRV_EP93XX
|
|
|
|
tristate "Cirrus Logic EP93XX"
|
|
|
|
depends on RTC_CLASS && ARCH_EP93XX
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
RTC embedded in the Cirrus Logic EP93XX processors.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-ep93xx.
|
|
|
|
|
2006-03-27 17:16:46 +08:00
|
|
|
config RTC_DRV_SA1100
|
|
|
|
tristate "SA11x0/PXA2xx"
|
|
|
|
depends on RTC_CLASS && (ARCH_SA1100 || ARCH_PXA)
|
|
|
|
help
|
|
|
|
If you say Y here you will get access to the real time clock
|
|
|
|
built into your SA11x0 or PXA2xx CPU.
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
module will be called rtc-sa1100.
|
2006-03-27 17:16:45 +08:00
|
|
|
|
2006-09-27 16:13:19 +08:00
|
|
|
config RTC_DRV_SH
|
|
|
|
tristate "SuperH On-Chip RTC"
|
|
|
|
depends on RTC_CLASS && SUPERH
|
|
|
|
help
|
|
|
|
Say Y here to enable support for the on-chip RTC found in
|
|
|
|
most SuperH processors.
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
module will be called rtc-sh.
|
|
|
|
|
2006-04-11 13:54:47 +08:00
|
|
|
config RTC_DRV_VR41XX
|
2006-04-11 13:54:48 +08:00
|
|
|
tristate "NEC VR41XX"
|
2006-04-11 13:54:47 +08:00
|
|
|
depends on RTC_CLASS && CPU_VR41XX
|
2006-04-11 13:54:48 +08:00
|
|
|
help
|
|
|
|
If you say Y here you will get access to the real time clock
|
|
|
|
built into your NEC VR41XX CPU.
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
module will be called rtc-vr41xx.
|
2006-04-11 13:54:47 +08:00
|
|
|
|
2006-06-25 20:47:38 +08:00
|
|
|
config RTC_DRV_PL031
|
|
|
|
tristate "ARM AMBA PL031 RTC"
|
|
|
|
depends on RTC_CLASS && ARM_AMBA
|
|
|
|
help
|
|
|
|
If you say Y here you will get access to ARM AMBA
|
|
|
|
PrimeCell PL031 UART found on certain ARM SOCs.
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
module will be called rtc-pl031.
|
|
|
|
|
2006-12-10 18:19:03 +08:00
|
|
|
config RTC_DRV_AT91RM9200
|
2006-06-25 20:48:27 +08:00
|
|
|
tristate "AT91RM9200"
|
|
|
|
depends on RTC_CLASS && ARCH_AT91RM9200
|
|
|
|
help
|
|
|
|
Driver for the Atmel AT91RM9200's internal RTC (Realtime Clock).
|
|
|
|
|
2006-03-27 17:16:42 +08:00
|
|
|
config RTC_DRV_TEST
|
|
|
|
tristate "Test driver/device"
|
|
|
|
depends on RTC_CLASS
|
|
|
|
help
|
|
|
|
If you say yes here you get support for the
|
|
|
|
RTC test driver. It's a software RTC which can be
|
|
|
|
used to test the RTC subsystem APIs. It gets
|
|
|
|
the time from the system clock.
|
|
|
|
You want this driver only if you are doing development
|
|
|
|
on the RTC subsystem. Please read the source code
|
|
|
|
for further details.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-test.
|
|
|
|
|
2006-06-25 20:48:23 +08:00
|
|
|
config RTC_DRV_MAX6902
|
|
|
|
tristate "Maxim 6902"
|
|
|
|
depends on RTC_CLASS && SPI
|
|
|
|
help
|
|
|
|
If you say yes here you will get support for the
|
|
|
|
Maxim MAX6902 spi RTC chip.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-max6902.
|
|
|
|
|
2006-06-25 20:48:24 +08:00
|
|
|
config RTC_DRV_V3020
|
|
|
|
tristate "EM Microelectronic V3020"
|
|
|
|
depends on RTC_CLASS
|
|
|
|
help
|
|
|
|
If you say yes here you will get support for the
|
|
|
|
EM Microelectronic v3020 RTC chip.
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
will be called rtc-v3020.
|
|
|
|
|
2006-03-27 17:16:37 +08:00
|
|
|
endmenu
|