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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.