of the following 2 patches:
On Mon, 5 Feb 2007, Johannes Berg wrote:
This patch removes the time suspend/restore code that was done through
a PMU notifier in arch/platforms/powermac/time.c.
Instead, we introduce arch/powerpc/sysdev/timer.c which creates a sys
device and handles time of day suspend/resume through that.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Andrew Morton <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[patch trimmed]
On Wed, 21 Feb 2007, David Brownell wrote:
RTC class suspend/resume support, re-initializing the system clock on resume
quoted
from the clock used to initialize it at boot time.
- Inlining the same code used by ARM, which saves and restores the
delta between a selected RTC and the current system wall-clock time.
- Removes calls to that ARM code from AT91, OMAP, and S3C RTCs.
This goes on top of the patch series removing "struct class_device" usage
quoted
from the RTC framework. That makes class suspend()/resume() work.
Signed-off-by: David Brownell <redacted>
---
drivers/rtc/Kconfig | 24 +++++++++----
drivers/rtc/class.c | 74 +++++++++++++++++++++++++++++++++++++++++++
drivers/rtc/rtc-at91rm9200.c | 30 -----------------
drivers/rtc/rtc-omap.c | 17 ---------
drivers/rtc/rtc-s3c.c | 22 ------------
5 files changed, 91 insertions(+), 76 deletions(-)
[patch trimmed]
I think, we only want 1, right? And the latter seems to be more generic /
platform independent? And as a side-effect, powermac would have to migrate
to generic rtc:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
On Thursday 22 February 2007 2:58 pm, Guennadi Liakhovetski wrote:
I think, we only want 1, right? And the latter seems to be more generic /
platform independent? And as a side-effect, powermac would have to migrate
to generic rtc:-)
I'd certainly think that restoring the system clock should be, as much
as possible, in platform-agnostic code. Like the generic RTC framework.
And hmm, that powermac/time.c file replicates other RTC code...
Minor obstacle: removing the EXPERIMENTAL label from that code.
- Dave
On Thu, 2007-02-22 at 23:58 +0100, Guennadi Liakhovetski wrote:
I think, we only want 1, right? And the latter seems to be more generic /
platform independent? And as a side-effect, powermac would have to migrate
to generic rtc:-)
Can we migrate all of powerpc to genrtc? But yes, I agree. Had enough to
do though already to get suspend working :)
johannes
First, sorry for messing up the subject line.
On Fri, 23 Feb 2007, Johannes Berg wrote:
On Thu, 2007-02-22 at 23:58 +0100, Guennadi Liakhovetski wrote:
quoted
I think, we only want 1, right? And the latter seems to be more generic /
platform independent? And as a side-effect, powermac would have to migrate
to generic rtc:-)
Can we migrate all of powerpc to genrtc? But yes, I agree. Had enough to
do though already to get suspend working :)
Johannes, is there any special meaning in "migrate all of powerpc to
genrtc"? Or is it just porting every single rtc driver to the generic rtc
API, moving it under drivers/rtc and adjusting its users or are there any
global changes required to arch/powerpc? Linkstation is now happily using
a driver under drivers/rtc, whereas originally it also had a "all special"
driver, and the migration for me wasn't that difficult... Or is there more
to do for other platforms?
Thanks
Guennadi
---
Guennadi Liakhovetski
On Fri, 2007-02-23 at 19:31 +0100, Guennadi Liakhovetski wrote:
Johannes, is there any special meaning in "migrate all of powerpc to
genrtc"? Or is it just porting every single rtc driver to the generic rtc
API, moving it under drivers/rtc and adjusting its users or are there any
global changes required to arch/powerpc?
I don't know. powerpc has some platform-specific rtc hooks that will
want conversion (or deletion?), I think.
johannes