From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>,
linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [patch] Generic time fixes
Date: Tue, 22 Jul 2003 18:14:30 -0700 [thread overview]
Message-ID: <20030722181430.I3135@mvista.com> (raw)
In-Reply-To: <Pine.GSO.3.96.1030723014418.607S-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Jul 23, 2003 at 02:30:53AM +0200
On Wed, Jul 23, 2003 at 02:30:53AM +0200, Maciej W. Rozycki wrote:
> On Tue, 22 Jul 2003, Jun Sun wrote:
>
> > Isn't it cool to take care of the board-specific with the same interface
> > kernel time system uses? Every MIPS board gets a basic RTC driver for free!
>
> Well, I'm not that convinced. What's wrong with making real support for
> the RTC chip instead?
>
Nothing wrong with full RTC driver support - it is just that when
30+ MIPS boards don't have to add #ifdef's to rtc.c and mc146818rtc.h
and hwclock still works people start appreciate more about the
existence of rtc_set_time().
> >
> > What is the race condition? And what is the performance hit?
>
> You need to read from the RTC, modify minutes and seconds as appropriate
> and write the RTC back. Meanwhile the time as stored in the RTC may
> change. With the 500 ms offset approximation as used by time.c it may be
> unlikely, but that assumption is for the MC146818 and it may not be true
> for incompatible RTC chips. That is the race. The performance hit is
> obvious -- now a read is added to the write.
>
OK, I see the performance hit now.
If you really want, how about the following change:
1) add set_rtc_mmss() function pointer in asm/time.h.
2) set it equal to set_rtc_time in time_init(). Board can override
this decision in board_timer_setup() for better performance.
3) RTC update is changed to call set_rtc_mmss()
How does this sound? It leaves all existing code unchanged, while
gives a way for optimization. The default setting of set_rtc_mmss
to set_rtc_time makes logical sense too, because set_rtc_mmss is really
a "back door" version of set_rtc_time().
Jun
next prev parent reply other threads:[~2003-07-23 1:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-22 7:58 [patch] Generic time fixes Maciej W. Rozycki
2003-07-22 8:32 ` Jan-Benedict Glaw
2003-07-22 10:04 ` Ralf Baechle
2003-07-22 10:21 ` Wolfgang Denk
2003-07-22 11:21 ` Ralf Baechle
2003-07-22 20:54 ` Maciej W. Rozycki
2003-07-22 17:16 ` Jun Sun
2003-07-22 21:24 ` Maciej W. Rozycki
2003-07-22 20:38 ` Maciej W. Rozycki
2003-07-22 17:10 ` Jun Sun
2003-07-22 21:21 ` Maciej W. Rozycki
2003-07-22 22:37 ` Ralf Baechle
2003-07-22 22:55 ` Maciej W. Rozycki
2003-07-22 22:43 ` Jun Sun
2003-07-22 23:10 ` Maciej W. Rozycki
2003-07-22 23:37 ` Jun Sun
2003-07-23 0:30 ` Maciej W. Rozycki
2003-07-23 1:14 ` Jun Sun [this message]
2003-07-23 14:52 ` Maciej W. Rozycki
2003-07-23 17:00 ` Jun Sun
2003-07-24 11:13 ` Maciej W. Rozycki
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=20030722181430.I3135@mvista.com \
--to=jsun@mvista.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@ds2.pg.gda.pl \
--cc=ralf@linux-mips.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