linux/drivers/rtc, branch v2.6.20

[PATCH] remove __devinit markings from rtc_sysfs_add_device()

2007-01-26T21:51:00Z

rtc_sysfs_add_device is needed even after dev initialization, so drop __devinit. Signed-off-by: Mike Frysinger Acked-by: Alessandro Zummo Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] rtc-sh: act on rtc_wkalrm.enabled when setting an alarm

2007-01-23T15:52:06Z

This fixes the SH rtc driver correctly act on the "enabled" flag when setting an alarm. Signed-off-by: Jamie Lenehan Cc: David Brownell Cc: Alessandro Zummo Cc: Paul Mundt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] rtc-sh: correctly report rtc_wkalrm.enabled

2007-01-12T02:18:20Z

This fixes the SH rtc driver to (a) correctly report 'enabled' status with other alarm status; (b) not duplicate that status in its procfs dump Signed-off-by: David Brownell Acked-by: Paul Mundt Cc: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Update the rtc-rs5c372 driver

2007-01-06T07:55:23Z

Bugfixes: - Handle RTCs which are configured to use 12-hour mode. - Never report bogus/un-initialized times. - Displaying "raw trim" requires not masking it first! - Fix the sysfs and procfs display of crystal and trim data. Features: - Handle other RTCs in this family, notably rv5c386/rv5c387. - Declare the other registers. - Provide alarm get/set functionality. - Handle AIE and UIE; but no IRQ handling yet. Cleanup: - Shrink object by not including needless sysfs or procfs support - We don't need no steenkin' forward declarations. (Except one.) Until the I2C framework merges "new style" driver support, matching the driver model better, using rv5c chips or alarm IRQs requires a separate board-specific patch. (And an IRQ handler, handing off labor through a work_struct...) This uses the "method 3" register reads, but notes that it's done to work around an evident i2c adapter driver bug. Signed-off-by: David Brownell Acked-by: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] rtc-at91rm9200 build fix

2007-01-06T07:55:22Z

The at91rm9200 RTC driver needs some assistance to build, because of recent header file rearrangement. Signed-off-by: David Brownell Cc: Alessandro Zummo Cc: Andrew Victor Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] rtc framewok: rtc_wkalrm.enabled reporting updates

2006-12-13T17:05:52Z

Fix a glitch in the procfs dumping of whether the alarm IRQ is enabled: use the traditional name (from drivers/char/rtc.c and many other places) of "alarm_IRQ", not "alrm_wakeup" (which didn't even match the efirtc code, which originated that reporting API). Also, update a few of the RTC drivers to stop providing that duplicate status, and/or to expose it properly when reporting the alarm state. We really don't want every RTC driver doing their own thing here... Signed-off-by: David Brownell Acked-by: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] rtc: remove syslog spam on registration

2006-12-13T17:05:52Z

This removes some syslog spam as RTC drivers register; debug messages shouldn't come out at "info" level. Signed-off-by: David Brownell Acked-by: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

rtc: rtc-sh: alarm support.

2006-12-11T23:42:08Z

This adds alarm support for the RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET and RTC_WKALM_RD operations to rtc-sh. The only unusual part is the handling of the alarm interrupt. If you clear the alarm flag (AF) while the time in the RTC still matches the time in the alarm registers than AF is immediately re-set, and if the alarm interrupt (AIE) is still enabled then it re-triggers. I was originally getting around 20k+ interrupts generated during the second when the RTC and alarm registers matches. The solution I've used is to clear AIE when the alarm goes off and then use the carry interrupt to re-enabled it. The carry interrupt will check AF and re-enabled AIE if it's clear. If AF is not clear it'll clear it and then the check will be repeated next carry interrupt. This a bit in rtc structure that indicates that it's waiting to have AIE re-enabled so it doesn't turn it on when it wasn't enabled anyway. Signed-off-by: Jamie Lenehan Signed-off-by: Paul Mundt

rtc: rtc-sh: fix rtc for out-by-one for the month.

2006-12-11T23:42:08Z

The RMONCNT register, which holds the month in the RTC, takes a value between 1 and 12 while the tm_mon field in the time structures takes a value between 0 and 11. This wasn't being taken into account in rtc-sh resulting in the month being out by one. eg, on my board during boot the RTC is set to: RTC is set to Thu Jul 01 09:00:00 1999 but "hwclock -r" immediately after logging in was showing: Sun Aug 1 09:01:43 1999 0.000000 seconds Signed-off-by: Jamie Lenehan Signed-off-by: Paul Mundt

rtc: rtc-sh: fix for period rtc interrupts.

2006-12-11T23:42:07Z

When testing the per second interrupt support (RTC_UIE_ON/RTC_UIE_OFF) of the new RTC system it would die in sh_rtc_interrupt due to a null ptr dereference. The following gets it working correctly. Signed-off-by: Jamie Lenehan Signed-off-by: Paul Mundt