405LP RTC reset

405LP RTC reset

[Hollis Blanchard]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

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.

Please apply to _2_4_devel.

Before similar changes can be made to 2.5, the non-todc RTC code will
have to be ported there (which Todd says is on his list :).

-Hollis
-- 
PowerPC Linux
IBM Linux Technology Center

[-- Attachment #2: 405LP-rtc-reset.diff --]
[-- Type: text/plain, Size: 2558 bytes --]

===== arch/ppc/platforms/ibm405lp.h 1.8 vs edited =====
--- 1.8/arch/ppc/platforms/ibm405lp.h	Tue Dec 17 11:26:06 2002
+++ edited/arch/ppc/platforms/ibm405lp.h	Tue Dec 17 11:52:10 2002
@@ -860,6 +860,11 @@
 
 #define SLA0_SLPMD_MASK 0x07dfffff	/* AND to clear all non-reserved fields */
 
+/* these defines are for the DV bits of RTC0_CR0 */
+#define RTC_DVBITS_4MHZ		0	/* 4.194304 MHz */
+#define RTC_DVBITS_1MHZ		1	/* 1.048576 MHz */
+#define RTC_DVBITS_33KHZ	2	/*   32.768 KHz */
+
 /* Several direct-write DCRs on the 405LP have an interlock requirement,
    implemented by a "valid" bit in the low-order bit.  This routine handles the
    handshaking for these registers, by
===== arch/ppc/platforms/ibm405lp.c 1.4 vs edited =====
--- 1.4/arch/ppc/platforms/ibm405lp.c	Thu Dec 12 17:06:37 2002
+++ edited/arch/ppc/platforms/ibm405lp.c	Tue Dec 17 11:50:01 2002
@@ -282,12 +282,16 @@
 	/* Make sure clocks are running */
 	if (not_initialized) {
 
-		/* Reset the core and ensure it's enabled.  We assume
-		   only that the BIOS has set the correct frequency. */
-		
-		mtdcr(DCRN_RTC0_WRAP, 0);
+		/* Reset the core and ensure it's enabled. */
+		mtdcr(DCRN_RTC0_WRAP, 0);		/* toggle NRST & NMR */
 		mtdcr(DCRN_RTC0_WRAP, 3);
-		mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f);
+		mtdcr(DCRN_RTC0_CR0, 0x60);		/* No divider chain, No square wave */
+		mtdcr(DCRN_RTC0_CR1, 0x80);		/* Disable update cycles/interrupts*/
+		mtdcr(DCRN_RTC0_WRAP, 0);       /* toggle NRST & NMR */
+		mtdcr(DCRN_RTC0_WRAP, 3);
+		mtdcr(DCRN_RTC0_CR0, (RTC_DVBITS & 0x7) << 4);		/* input clock */
+		mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f);	/* allow updates */
+
 		not_initialized = 0;
 	}
 
===== arch/ppc/platforms/beech.h 1.7 vs edited =====
--- 1.7/arch/ppc/platforms/beech.h	Thu Dec 12 17:10:24 2002
+++ edited/arch/ppc/platforms/beech.h	Tue Dec 17 11:50:10 2002
@@ -181,6 +181,8 @@
 #define PPC4xx_SERCLK_FREQ		11059200
 #define BASE_BAUD			(PPC4xx_SERCLK_FREQ / 16)
 
+#define RTC_DVBITS			RTC_DVBITS_1MHZ	/* 1MHz RTC */
+
 #define PPC4xx_MACHINE_NAME		"IBM 405LP Beech"
 
 #define _IO_BASE        isa_io_base
===== arch/ppc/platforms/arctic2.h 1.1 vs edited =====
--- 1.1/arch/ppc/platforms/arctic2.h	Sun Dec 15 19:59:59 2002
+++ edited/arch/ppc/platforms/arctic2.h	Tue Dec 17 11:50:18 2002
@@ -56,6 +56,8 @@
 
 #define BASE_BAUD (PPC4xx_SERCLK_FREQ / 16)
 
+#define RTC_DVBITS	RTC_DVBITS_33KHZ	/* 33KHz RTC */
+
 #define PPC4xx_MACHINE_NAME	"IBM Arctic II"
 
 #endif /* !__ASSEMBLY__ */

Re: 405LP RTC reset

[David Gibson]

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.
>
> Please apply to _2_4_devel.

Seems to work on my Arctic-2, and now applied.

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.  So, unless I'm
mistaken, things will be bogus anyway if the divider isn't already
correct when the driver initializes - so it seems a bit misleading to
set it in the driver itself.

--
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/

Re: 405LP RTC reset

[Hollis Blanchard]

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?

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
--
PowerPC Linux
IBM Linux Technology Center

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

Re: 405LP RTC reset

[David Gibson]

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/

Re: 405LP RTC reset

[Hollis Blanchard]

On Wed, 2002-12-18 at 15:15, David Gibson wrote:
> On Wed, Dec 18, 2002 at 09:38:53AM -0600, Hollis Blanchard wrote:
> >
> > 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.

Sounds like a very good idea. I'll add it to my list unless someone
beats me to it. :)

-Hollis
--
PowerPC Linux
IBM Linux Technology Center

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