linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Gabriel Paubert <paubert@iram.es>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
Date: Fri, 7 Sep 2007 10:21:43 +0200	[thread overview]
Message-ID: <20070907082143.GA27058@iram.es> (raw)
In-Reply-To: <20070906172415.GA18226@ld0162-tx32.am.freescale.net>

On Thu, Sep 06, 2007 at 12:24:15PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 07:05:47PM +0200, Gabriel Paubert wrote:
> > On Thu, Sep 06, 2007 at 12:01:23PM -0500, Scott Wood wrote:
> > > On Thu, Sep 06, 2007 at 06:55:35PM +0200, Gabriel Paubert wrote:
> > > > So who will be in charge of updating the RTC now? The update 
> > > > every 11 min is there to stay on x86(-64) it seems.
> > > 
> > > Put something in crontab to run hwclock periodically.
> > 
> > I have many machines on which cron is not even installed.
> 
> OK, so use something else that waits in a loop and periodically updates
> the clock.  It shouldn't be the kernel's responsibility.

It ha been the kernel's reposnibility ever since the NTP code
was included with the kernel. The only way to move it out
is to agree to something with NTP folks.

It is going to break working setups who rely on this feature, 
which is a big no-no.

The solution now used by i386/x86-64/sparc64 is
CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched
to use something similar, but the generic code has some
problems (it assumes that you have to set the clock
on a half-second, which is not the case of the RTC on 
my boards to start with).

Now I'm aware that some PowerPC RTC are messy to handle
in a timer/interrupt/whatever because some hardware designers
thought it was wise to put the RTC on a dog-slow bus like
I2C. You have however a variable to disable this update
if you want (no_sync_cmos_clock), set it to 1 by default
but please let people that use (and need) the functionality
enable it (even do it by default when the RTC access is fast).

	Gabriel

  reply	other threads:[~2007-09-07  8:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-06 14:41 [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC Paul Mackerras
2007-09-06 16:55 ` Gabriel Paubert
2007-09-06 17:01   ` Scott Wood
2007-09-06 17:05     ` Gabriel Paubert
2007-09-06 17:24       ` Scott Wood
2007-09-07  8:21         ` Gabriel Paubert [this message]
2007-09-09  9:55           ` Paul Mackerras
2007-09-10  9:09             ` Gabriel Paubert
2007-09-06 18:20   ` Paul Mackerras
2007-09-07  8:50     ` 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=20070907082143.GA27058@iram.es \
    --to=paubert@iram.es \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=scottwood@freescale.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).