[PATCH] Use todc on Mot PReP platforms

This restores behavior from 2.4 where PReP platforms identified
as Motorola would calibrate the decrementer using the RTC. On
real Motorola PReP hardware this isn't needed. However, in order
to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
PReP system) it is necessary to allow it to calibrate the decrementer
using an emulated RTC.  If the decrementer rate is read from
residual data then timing is screwed since a qemu PReP system typically
runs much faster than the original hardware.

If anybody has objections to this as the default, let me know. It
still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
affect the IBM PReP paths. My goal with this is to be able to run
a stock 2.6 defconfig PReP build on qemu.

-Matt

diff --git a/arch/ppc/platforms/prep_setup.c b/arch/ppc/platforms/prep_setup.c
--- a/arch/ppc/platforms/prep_setup.c
+++ b/arch/ppc/platforms/prep_setup.c

@@ -940,8 +940,7 @@ prep_calibrate_decr(void)
 			tb_to_us = mulhwu_scale_factor(freq/divisor, 1000000);
 			tb_ticks_per_jiffy = freq / HZ / divisor;
 		}
-	}
-	else
+	} else
 		todc_calibrate_decr();
 }
 

@@ -1155,16 +1154,17 @@ prep_init(unsigned long r3, unsigned lon
 
 	ppc_md.time_init      = todc_time_init;
 	if (_prep_type == _PREP_IBM) {
+		ppc_md.calibrate_decr = prep_calibrate_decr;
 		ppc_md.rtc_read_val = todc_mc146818_read_val;
 		ppc_md.rtc_write_val = todc_mc146818_write_val;
 		TODC_INIT(TODC_TYPE_MC146818, RTC_PORT(0), NULL, RTC_PORT(1),
 				8);
 	} else {
+		ppc_md.calibrate_decr = todc_calibrate_decr;
 		TODC_INIT(TODC_TYPE_MK48T59, PREP_NVRAM_AS0, PREP_NVRAM_AS1,
 				PREP_NVRAM_DATA, 8);
 	}
 
-	ppc_md.calibrate_decr = prep_calibrate_decr;
 	ppc_md.set_rtc_time   = todc_set_rtc_time;
 	ppc_md.get_rtc_time   = todc_get_rtc_time;
 

On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:

This restores behavior from 2.4 where PReP platforms identified
as Motorola would calibrate the decrementer using the RTC. On
real Motorola PReP hardware this isn't needed. However, in order
to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
PReP system) it is necessary to allow it to calibrate the decrementer
using an emulated RTC.  If the decrementer rate is read from
residual data then timing is screwed since a qemu PReP system typically
runs much faster than the original hardware.

If anybody has objections to this as the default, let me know. It
still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
affect the IBM PReP paths. My goal with this is to be able to run
a stock 2.6 defconfig PReP build on qemu.

So, I like this, and not just because I'm playing with qemu as well.
Leigh, can you run this on any 'interesting' PReP you've got that might
tickle a bug here?  Thanks.

-- 
Tom Rini
http://gate.crashing.org/~trini/

On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:

quoted

If anybody has objections to this as the default, let me know. It
still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
affect the IBM PReP paths. My goal with this is to be able to run
a stock 2.6 defconfig PReP build on qemu.

i applied the patch to the latest 2.6-git tree and my PReP[1] boots just 
fine!

thanks for maintaining this exotic platform,
Christian.

[1] http://www.nerdbynature.de/bits/hal/2.6.13-rc6
-- 
BOFH excuse #367:

Webmasters kidnapped by evil cult.

Does anyone enable CONFIG_RTC on chrp/prep?  Tom tells me these are  
the only platforms that it is even valid to do so on.

- kumar

On Thu, Sep 01, 2005 at 12:57:55PM -0500, Kumar Gala wrote:

Does anyone enable CONFIG_RTC on chrp/prep?  Tom tells me these are  
the only platforms that it is even valid to do so on.

The debian powerpc kernels enables :

  $ grep RTC /boot/config-2.6.12-1-powerpc
  CONFIG_GEN_RTC=y
  CONFIG_GEN_RTC_X=y

and not the CONFIG_RTC variant, and it works well on pegasos, and prep boxes,
and probably on ibm chrps too, altough i have not tested personally.

Friendly,

Sven Luther

On Sep 1, 2005, at 1:38 PM, Sven Luther wrote:

On Thu, Sep 01, 2005 at 12:57:55PM -0500, Kumar Gala wrote:

quoted

Does anyone enable CONFIG_RTC on chrp/prep?  Tom tells me these are
the only platforms that it is even valid to do so on.

The debian powerpc kernels enables :

  $ grep RTC /boot/config-2.6.12-1-powerpc
  CONFIG_GEN_RTC=y
  CONFIG_GEN_RTC_X=y

and not the CONFIG_RTC variant, and it works well on pegasos, and prep
boxes,
and probably on ibm chrps too, altough i have not tested personally.

Thanks, as far as I can tell no one is using CONFIG_RTC, which means  
I can "fix" asm-ppc/mc146818rtc.h to no longer #define RTC_IRQ 8

- kumar

On Thu, Sep 01, 2005 at 01:47:36PM -0500, Kumar Gala wrote:

On Sep 1, 2005, at 1:38 PM, Sven Luther wrote:

quoted

On Thu, Sep 01, 2005 at 12:57:55PM -0500, Kumar Gala wrote:

quoted

Does anyone enable CONFIG_RTC on chrp/prep?  Tom tells me these are
the only platforms that it is even valid to do so on.

The debian powerpc kernels enables :

 $ grep RTC /boot/config-2.6.12-1-powerpc
 CONFIG_GEN_RTC=y
 CONFIG_GEN_RTC_X=y

and not the CONFIG_RTC variant, and it works well on pegasos, and prep
boxes,
and probably on ibm chrps too, altough i have not tested personally.

Thanks, as far as I can tell no one is using CONFIG_RTC, which means  
I can "fix" asm-ppc/mc146818rtc.h to no longer #define RTC_IRQ 8

For the record, on MVME boards with PowerPlus bridges, the RTC driver 
cannot work because the interrupt output is not connected. IRQ 8 is 
instead connected to a front panel switch labelled abort that nobody 
uses either (at least under Linux).

Anyway, there are better ways to obtain regularly spaced interrupts
on PPC. They are just not implemented (yet).

	Gabriel

Kumar Gala schrieb:

Does anyone enable CONFIG_RTC on chrp/prep?  Tom tells me these are  the
only platforms that it is even valid to do so on.

hm, "grep CONFIG_RTC arch/ppc/configs/*" returns nothing and i don't find
this option in my .config (anymore?). CONFIG_GEN_RTC and CNFIG_GEN_RTC_X
is working fine here [1].

Christian.

[1] http://nerdbynature.de/bits/hal/2.6.13/
-- 
BOFH excuse #1:

clock speed