All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michel Lanners <mlan@cpu.lu>
To: trini@kernel.crashing.org
Cc: ad@mpifr-bonn.mpg.de, linuxppc-dev@lists.linuxppc.org
Subject: Re: CPU Temperature Patch
Date: Thu, 21 Sep 2000 21:40:58 +0200 (CEST)	[thread overview]
Message-ID: <200009211941.VAA05085@piglet.grunz.lu> (raw)
In-Reply-To: <20000920110436.C15401@opus.bloom.county>


Hi all,

On  20 Sep, this message from Tom Rini echoed through cyberspace:
>
> On Wed, Sep 20, 2000 at 05:03:42PM +0200, Albrecht Dreß wrote:
>>
>> "D.J. Osguthorpe" wrote:
>> > Here are two patches that appear to fix the cpu_temp function in setup.c.
>> > They have been applied to a number of Ben Herrenschmidt kernels on a 500 MHz
>> > Pismo powerbook and print reasonable values when you cat /proc/cpuinfo.
>>
>> The patch seems to work on my Lombard/333, too... Really great!
>>
>> > +       /* this set for 500 MHz Pismo - how do we get access to clock?? */
>>
>> There is, in the same file, around line 319 code to read the clock speed from
>> the device tree. However, is it really necessary to include the clock speed at
>> this point? What is the drawback if we just assume 500 MHz (or even the max
>> value) for every G3 based machine?
>
> Why assume when we can do it properly?  Besides, a friend of mine oc'ed his
> B&W to 550, so it's possible to have >500Mhz :)

To do it properly on all machines requires a processor frequency
calculating routine, that doesn't depend on OF. Note that on all
upgraded machines that did not initially have a G3, OF's value is wrong
(too low, actually)!

On the other hand, Motorola's doc states that setting too large a value
doesn't hurt, so I guess we can safely hardcode something like 600 MHz.

At the only expense of busy-waiting a bit too long on slower machines...
but how often do you look at /proc/cpuinfo? Besides, you could always do
the aproximation using the interrupt ;-)

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

  parent reply	other threads:[~2000-09-21 19:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-20 12:42 CPU Temperature Patch D.J. Osguthorpe
2000-09-20 12:42 ` D.J. Osguthorpe
2000-09-20 15:03 ` Albrecht Dre_
2000-09-20 18:04   ` Tom Rini
2000-09-20 19:15     ` Michael Schmitz
2000-09-21  2:24       ` Tom Rini
2000-09-21 19:40     ` Michel Lanners [this message]
2000-09-21 19:02 ` Michel Lanners

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=200009211941.VAA05085@piglet.grunz.lu \
    --to=mlan@cpu.lu \
    --cc=ad@mpifr-bonn.mpg.de \
    --cc=linuxppc-dev@lists.linuxppc.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.