All of lore.kernel.org
 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 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.