All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Hollis Blanchard <hollis@austin.ibm.com>
Cc: embedded list <linuxppc-embedded@lists.linuxppc.org>,
	Todd Poynor <tpoynor@mvista.com>
Subject: Re: 405LP RTC reset
Date: Thu, 19 Dec 2002 08:15:56 +1100	[thread overview]
Message-ID: <20021218211556.GA8947@zax.zax> (raw)
In-Reply-To: <1040225939.29647.11.camel@granite.austin.ibm.com>


On Wed, Dec 18, 2002 at 09:38:53AM -0600, Hollis Blanchard wrote:
>
> On Tue, 2002-12-17 at 18:55, David Gibson wrote:
> >
> > On Tue, Dec 17, 2002 at 12:43:32PM -0600, Hollis Blanchard wrote:
> > > Here's the updated 405LP RTC reset diff (after David's move of the RTC
> > > functions to ibm405lp.c). This patch
> > > a) does a full RTC reset as specified in the docs
> > > b) sets the RTC clock speed in RTC "Register A" DV bits, i.e. it does
> > > not assume the firmware has done this correctly.
> >
> > One query though (I didn't think of this earlier) - is it such a great
> > idea to go setting the reference clock frequency?  Unlike most other
> > drivers, we can't just take over the RTC and do what we like with it
> > once the kernel boots, because it has to keep running at the same rate
> > even when the device is rebooting or (mostly) off.
>
> The only issue I can think of here is the firmware setting it
> incorrectly or not at all. In that case, a few seconds will be expanded
> or compressed, but that's better than time running too fast or slow
> forever, right?

That's true.  Still, I think it might be worth testing what the rate
is set to when we come in, and printing a warning if it's not what we
expect before we adjust it.  If it just silently corrects it I could
imagine it being pretty nasty to track down why the device is
losing/gaining time each boot.

> Of course the rate settings must be battery-backed along with the time,
> so you only need to set it once per RTC power loss. That includes
> rebooting time and power off time.
>
> -Hollis

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

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

  reply	other threads:[~2002-12-18 21:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-17 18:43 405LP RTC reset Hollis Blanchard
2002-12-18  0:55 ` David Gibson
2002-12-18 15:38   ` Hollis Blanchard
2002-12-18 21:15     ` David Gibson [this message]
2002-12-18 21:49       ` Hollis Blanchard

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=20021218211556.GA8947@zax.zax \
    --to=david@gibson.dropbear.id.au \
    --cc=hollis@austin.ibm.com \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=tpoynor@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 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.