[PATCH] Use todc on Mot PReP platforms

[PATCH] Use todc on Mot PReP platforms

[Matt Porter]

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;
 

Re: [PATCH] Use todc on Mot PReP platforms

[Tom Rini]

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/

Re: [PATCH] Use todc on Mot PReP platforms

[Christian]

> On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
>>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.

Re: [PATCH] Use todc on Mot PReP platforms

[Matt Porter]

On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
> 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.

Why? It has no other redeeming quality except that it makes qemu work.
It's better to use residual data versus todc calibration in real machine
cases since residual data is accurate for this particular value on these
machines. I'm just curious why you would like this patch outside of
its qemu value.

BTW, it's _possible_ that we might eventually modify the open
hackware OF to do a timing loop and dynamically fill in the
residual data time base freq but that's unfamiliar territory and
this is an easy workaround.

> Leigh, can you run this on any 'interesting' PReP you've got that might
> tickle a bug here?  Thanks.

Let me know if there's anything more that needs to be tested. Otherwise,
I plan to send upstream soon.

Thanks,
Matt

Re: [PATCH] Use todc on Mot PReP platforms

[Sven Luther]

On Mon, Aug 15, 2005 at 10:52:24PM -0700, Matt Porter wrote:
> On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
> > 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.
> 
> Why? It has no other redeeming quality except that it makes qemu work.
> It's better to use residual data versus todc calibration in real machine
> cases since residual data is accurate for this particular value on these
> machines. I'm just curious why you would like this patch outside of
> its qemu value.
> 
> BTW, it's _possible_ that we might eventually modify the open
> hackware OF to do a timing loop and dynamically fill in the
> residual data time base freq but that's unfamiliar territory and
> this is an easy workaround.

What about modifying qemu's OF to emulate a chrp machine instead ?

Friendly,

Sven Luther

Re: [PATCH] Use todc on Mot PReP platforms

[Matt Porter]

On Tue, Aug 16, 2005 at 09:19:12AM +0200, Sven Luther wrote:
> On Mon, Aug 15, 2005 at 10:52:24PM -0700, Matt Porter wrote:
> > On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
> > > 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.
> > 
> > Why? It has no other redeeming quality except that it makes qemu work.
> > It's better to use residual data versus todc calibration in real machine
> > cases since residual data is accurate for this particular value on these
> > machines. I'm just curious why you would like this patch outside of
> > its qemu value.
> > 
> > BTW, it's _possible_ that we might eventually modify the open
> > hackware OF to do a timing loop and dynamically fill in the
> > residual data time base freq but that's unfamiliar territory and
> > this is an easy workaround.
> 
> What about modifying qemu's OF to emulate a chrp machine instead ?

That's good, but not the point of this exercise...at least for me. :)
Eventually, we should be able to boot a stock prep, chrp, or pmac
image built from the mainline kernel defconfig. Personally, I
want to boot some stock embedded kernels as well, but that's a
lot more work emulating on-chip I/O.

FWIW, jmayer did PReP first because all the PeeCee hardware was
already emulated. I believe CHRP/Pmac work to some degree but
I haven't personally tried them yet.

-Matt

Re: [PATCH] Use todc on Mot PReP platforms

[Tom Rini]

On Mon, Aug 15, 2005 at 10:52:24PM -0700, Matt Porter wrote:
> On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
> > 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.
> 
> Why? It has no other redeeming quality except that it makes qemu work.

And it gets us away from residual data which can be crap or non
existant.  FWIW, I've move past using qemu, and I still like the change.

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

use of rtc.c on chrp/prep?

[Kumar Gala]

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

Re: use of rtc.c on chrp/prep?

[Sven Luther]

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

Re: use of rtc.c on chrp/prep?

[Kumar Gala]

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

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

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

Re: use of rtc.c on chrp/prep?

[Gabriel Paubert]

On Thu, Sep 01, 2005 at 01:47:36PM -0500, Kumar Gala wrote:
> On Sep 1, 2005, at 1:38 PM, Sven Luther wrote:
> 
> >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.
> 
> 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

Re: use of rtc.c on chrp/prep?

[evilninja]

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