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 16:37:01 -0700 [thread overview]
Message-ID: <20030722163701.G3135@mvista.com> (raw)
In-Reply-To: <Pine.GSO.3.96.1030723005534.607Q-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Jul 23, 2003 at 01:10:54AM +0200
On Wed, Jul 23, 2003 at 01:10:54AM +0200, Maciej W. Rozycki wrote:
> On Tue, 22 Jul 2003, Jun Sun wrote:
>
> > > Well, rtc_set_time() is only used by the timekeeping code, so I see no
> > > problem with renaming it. And the interface remains the same -- it's a
> > > number of seconds. So if a full update is faster than changing minutes
> > > and seconds only (e.g. the RTC is a monotonic counter -- I know a system
> > > that just counts 10 ms intervals), an implementation is free to do so
> > > (although that enforces UTC to be kept in the RTC; a good thing anyway),
> > > but it shouldn't be required to. And I think the name should be changed
> > > to reflect that.
> >
> > Actually the drivers/char/mips-rtc.c uses it too. In that context
> > a full rtc set is needed.
> >
> > The same interface can be used for the 2.6 gen-rtc.c as well, where
> > a full rtc update is needed also.
>
> But that function should be provided by the driver (it may use
> system-specific backends at will -- drivers/char/rtc.c does so as well),
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!
> > I like the current way it is because :
> >
> > 1) rtc_set_time() is a more generic interface so that it can be used
> > in more places (such as mips-rtc.c and gen-rtc.c).
>
> I see no problem with that interface being used there.
Eh? I assume you mean "no problem with rtc_set_mmss() being used there", true?
How come no problem? rtc_set_mmss() does not even allow you set the time
if the new time is too off.
>
> > 2) rtc_set_mmss() can be reasonally emulated if it is desired on a particular
> > board
>
> I don't think so -- it would incur a race and a severe performance hit.
> It makes no sense anyway.
What is the race condition? And what is the performance hit?
> > 3) it is better to have just one rtc_set_xxx() instead of two.
>
> Please define "better". I think it's better to have a fast variation for
> timekeeping as it's been used for years now for MC146818 and clones.
>
Oh, yeah? Look at those ugly #ifdefs include/asm-mips/mc146818rtc.h.
It is a poor abstraction of RTC.
If you convert DEC to the new RTC interface we could get rid of that
file completely.
And make no mistake, you _can_ have fast implementation that you are
looking for.
BTW, are you proposing to rename rtc_set_time() to rtc_set_mmss() and change
its semantic accordingly? Or are you suggesting to add rtc_set_mmss()?
If you are suggesting the later, clearly fewer interface functions
between MIPS common and board layer is better.
> > Actually searching through the kernel I can't find the place where
> > the flag is cleared. Am I mistaken?
>
> See do_adjtimex().
>
I see. Thanks.
Jun
next prev parent reply other threads:[~2003-07-22 23:37 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 [this message]
2003-07-23 0:30 ` Maciej W. Rozycki
2003-07-23 1:14 ` Jun Sun
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=20030722163701.G3135@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