From: Wolfgang Denk <wd@denx.de>
To: linuxppc-dev@lists.linuxppc.org
Subject: set_rtc_time() cleanup / normalization
Date: Mon, 12 May 2003 23:17:28 +0200 [thread overview]
Message-ID: <20030512211733.B489EC6092@atlas.denx.de> (raw)
Hi everybody,
I would like to find out if there is some consensus about the use of
set_rtc_time() in the timer interrupt handler.
Note: this question relates to a thread that was started by
Stephen Johnson on Tue, 22 Apr 2003; see message:
http://lists.linuxppc.org/linuxppc-embedded/200304/msg00233.html
The problem: some systems use RTC chips which are attached to the
system using an I2C bus (or similar). To control the device you will
have to setup one or more I2C transactions, which usually result in
one or more interrupts which must be processed.
Depending on which architecture and/or board you are using, there may
or may not be a call to set_rtc_time() be performed in the timer
interrupt handler. This call will happen every 11 minutes (659
seconds, to be precise) - see "arch/ppc/kernel/time.c".
I would like to know if there is a rationale in putting this call
into a general part of the source code.
Other architectures handle this differently. For example, in the ARM
kernel tree the timer interrupt implementation is essentially
board-specific (located in a include/asm/arch-.../time.h file). Some
ARM boards' timer interrupt handlers do call set_rtc_time(), others
don't.
Shouldn't we do the same on PPC?
Or maybe we should delete this code completely? If somebody wants to
sync the RTC against the system time a simple daemon or cron job (for
example calling "hwclock --systohc" every 11 minutes) would result in
more or less identical results.
More information:
Calling set_rtc_time() is useful only in a situation where there is
an external reference time against which the system time is synchro-
nized. In such a configuration this call would make sure that the RTC
is kept in sync with the reference time. This allows to start with
minimal deviation in case of a crash, where no orderly shutdown was
performed. In case of a normal shutcown / reboot the shutdown scripts
would take care of saving the system time to RTC anyway...
In all other cases such a call to set_rtc_time() is not needed, or
even harmful.
Many embedded systems run in a configuration where they use a high
precision RTC chip and want to have the system time kept in sync with
it. In such a configuration, the call to set_rtc_time() is plainly
wrong and must be avoided.
Oliver Amft posted a solution which includes spawning a kernel thread
to perform the set_rtc_time() call outside the timer inteerupt; see
http://lists.linuxppc.org/linuxppc-embedded/200304/msg00272.html; in
my opinion this is only a workaround, but not a solution. Limited
accuracy (scheduling delay for the thread) and code size overhead are
just two of the problems of such a solution.
All feedback welcome.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
PROGRAM - n. A magic spell cast over a computer allowing it to turn
one's input into error messages.
v. tr. - To engage in a pastime similar to banging one's head against
a wall, but with fewer opportunities for reward.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next reply other threads:[~2003-05-12 21:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-12 21:17 Wolfgang Denk [this message]
2003-05-13 0:16 ` set_rtc_time() cleanup / normalization Dan Malek
2003-05-13 7:52 ` Geert Uytterhoeven
2003-05-13 8:18 ` Gabriel Paubert
[not found] ` <Pine.GSO.4.21.0305131051420.20323-100000@vervain.sonytel.be>
2003-05-13 10:21 ` Gabriel Paubert
2003-05-13 13:35 ` Wolfgang Denk
2003-05-13 12:03 ` Richard Zidlicky
2003-05-13 23:05 ` Paul Mackerras
2003-05-13 23:33 ` Eugene Surovegin
2003-05-14 0:08 ` Wolfgang Denk
[not found] ` <5.1.0.14.2.20030513171616.037f6800@mail.ebshome.net>
2003-05-14 3:47 ` Matt Porter
[not found] ` <5.1.0.14.2.20030513214040.02a6e6d0@mail.ebshome.net>
[not found] ` <3EC1DB1F.8000408@embeddededge.com>
2003-05-14 6:41 ` Eugene Surovegin
2003-05-14 6:47 ` Wolfgang Denk
2003-05-14 8:32 ` Benjamin Herrenschmidt
2003-05-14 15:57 ` Gabriel Paubert
2003-05-14 16:41 ` Eugene Surovegin
2003-05-14 15:50 ` Gabriel Paubert
2003-05-14 15:43 ` Gabriel Paubert
2003-05-14 16:28 ` Dan Malek
2003-05-15 18:04 ` Gabriel Paubert
2003-05-15 18:21 ` Wolfgang Denk
[not found] ` <20030515184412.GA22327@iram.es>
2003-05-15 19:37 ` Benjamin Herrenschmidt
[not found] <20030514230638.GB1687@linux-m68k.org>
[not found] ` <Pine.GSO.4.21.0305151031410.13683-100000@vervain.sonytel.be>
2003-05-15 10:45 ` Gabriel Paubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030512211733.B489EC6092@atlas.denx.de \
--to=wd@denx.de \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).