linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sven Luther <sven.luther@wanadoo.fr>
To: Matt Porter <mporter@kernel.crashing.org>
Cc: Tom Rini <trini@kernel.crashing.org>, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] Use todc on Mot PReP platforms
Date: Tue, 16 Aug 2005 09:19:12 +0200	[thread overview]
Message-ID: <20050816071912.GA18653@localhost.localdomain> (raw)
In-Reply-To: <20050815225224.F28706@cox.net>

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

  reply	other threads:[~2005-08-16  7:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-10 16:37 [PATCH] Use todc on Mot PReP platforms Matt Porter
2005-08-11 19:43 ` Tom Rini
2005-08-12 10:20   ` Christian
2005-09-01 17:57     ` use of rtc.c on chrp/prep? Kumar Gala
2005-09-01 18:38       ` Sven Luther
2005-09-01 18:47         ` Kumar Gala
2005-09-02  7:21           ` Gabriel Paubert
2005-09-04  0:41       ` evilninja
2005-08-16  5:52   ` [PATCH] Use todc on Mot PReP platforms Matt Porter
2005-08-16  7:19     ` Sven Luther [this message]
2005-08-16  7:33       ` Matt Porter
2005-08-16 14:49     ` Tom Rini

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=20050816071912.GA18653@localhost.localdomain \
    --to=sven.luther@wanadoo.fr \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mporter@kernel.crashing.org \
    --cc=trini@kernel.crashing.org \
    /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).