linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: Pete Popov <ppopov@mvista.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@oss.sgi.com>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	Linux/PPC Development <linuxppc-dev@lists.linuxppc.org>
Subject: Re: [RFC] generic MIPS RTC driver
Date: Mon, 12 Nov 2001 10:56:44 -0800	[thread overview]
Message-ID: <3BF01B6C.496179@mvista.com> (raw)
In-Reply-To: 3BF0145C.9795C8CC@mvista.com


Jun Sun wrote:
>
> Pete Popov wrote:
> >
> > On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote:
> > > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote:
> > >
> > > > >  Unless you use a non-MC146818 RTC, which you need to write a separate
> > > > > driver for anyway.
> > > >
> > > > Yep, so that's why both m68k and PPC have common routines to read/write the
> > > > RTC, with a /dev/rtc-compatible abstraction on top of it.
> > >
> > >  OK, then you need an RTC chipset-specific driver and not a CPU
> > > architecture-specific one.  Otherwise we'll end with a zillion of similar
> > > RTC drivers like we already have for LANCE and SCC chips.
> >
> > I agree.  We don't have arch specific network drivers so why have arch
> > specific rtc drivers.
> >
>
> Because we can have a free RTC driver working once you get kernel working.
>

Actually there is a longer answer with a little bit of the background info.

Kernel needs to know about the real calendar time when it boots up.  And
optionally it may write to RTC (based on the assumption that kernel timer is
more accurate than RTC clock).  So it already has abstraction, one form or
another, to do RTC read/write.

Based on these abstractons you can provide a hardware-independent RTC driver,
with RTC read/write operations.

Before CONFIG_NEW_TIME_C is introduced, each MIPS board has its own time
service routine, which means, even if RTC driver wants to utilize the
abstraction, it will be only for that board only.

After CONFIG_NEW_TIME_C is introduced, that RTC abstract becomes MIPS-common.
Therefore, we can afford a MIPS-common generic RTC driver.

If that abstraction ever becomes Linux-common code, then the generic RTC
driver will essentially be a Linux-common, device-indpendent driver.

For most MIPS machine, we need /dev/rtc to merely set time and read time.  The
generic driver should suffice.  Otherwire, you can wirte a complete one for a
specific board or a specific chip.

Jun

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2001-11-12 18:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20011110231746.B4342@mvista.com>
2001-11-11 10:14 ` [RFC] generic MIPS RTC driver Geert Uytterhoeven
2001-11-12 12:59   ` Maciej W. Rozycki
2001-11-12 13:11     ` Geert Uytterhoeven
2001-11-12 13:29       ` Maciej W. Rozycki
2001-11-12 16:14         ` Pete Popov
2001-11-12 18:26           ` Jun Sun
2001-11-12 18:56             ` Jun Sun [this message]
2001-11-12 21:51               ` Tom Rini
2001-11-12 18:24         ` Jun Sun
2001-11-12 19:04           ` Maciej W. Rozycki
2001-11-12 19:21             ` Jun Sun
2001-11-12 18:19       ` Jun Sun
2001-11-12 18:55         ` Maciej W. Rozycki
2001-11-12 19:13           ` Jun Sun
2001-11-12 20:02         ` Geert Uytterhoeven
2001-11-12 20:54           ` Roman Zippel
2001-11-13  1:31             ` Tom Rini
2001-11-13  6:20               ` Geert Uytterhoeven
2001-11-13 14:44                 ` Tom Rini
2001-11-13 14:47                   ` Geert Uytterhoeven
2001-11-13 15:30                   ` Roman Zippel
2001-11-13 13:42             ` Richard Zidlicky
2001-11-13 15:32               ` Roman Zippel
2001-11-14  9:46                 ` Richard Zidlicky
2001-11-13 17:58               ` Jun Sun
2001-11-14 10:08                 ` Richard Zidlicky
2001-11-15 17:41                   ` Jun Sun

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=3BF01B6C.496179@mvista.com \
    --to=jsun@mvista.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@oss.sgi.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=macro@ds2.pg.gda.pl \
    --cc=ppopov@mvista.com \
    /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).