From: rutger@nospam.com (Rutger Nijlunsing)
To: LM Sensors <sensors@stimpy.netroedge.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: [RFC] Dynamic fan clock divider changes (long)
Date: Thu, 19 May 2005 06:24:58 +0000 [thread overview]
Message-ID: <20040516213645.GA18906@nospam.com> (raw)
In-Reply-To: <20040516222809.2c3d1ea2.khali@linux-fr.org>
On Sun, May 16, 2004 at 10:28:09PM +0200, Jean Delvare wrote:
> Hi all,
>
[snip]
Another implementation to add to the pool. Note I'm not convinced this
is the best solution, since I know little about the hardware
limitations...
Implementation #5
Since the divider can be programmed, it is possible to take two
measurements (all in the driver): first with the highest divider
allowed by the chipset to get an indication of the current speed, and
then a new measurement followed as close as possible to the first one
with a divider fitting the first measured speed.
Example: set divider to 64 (or highest possible divider); fan speed
gives 2500 +- 500. Not set divider to 2 or 1 and re-measure.
Advantages:
- no 'low limit' has to be set magically
- most accurate reading possible on the whole range
- invisible to the user
Disadvantages:
- no 'low limit' can be set in the hardware; low limit must be
processed in software.
- Update frequency of the fan speed will be halved.
Maybe-problem:
- The 'as close as possible' must be in a small range or otherwise
the fan speed may be dropping to fast to fall outside the
measurable range. I do not know with which frequency the fan speed
can be measured.
Processing the low limit in software will also solve the 'BIOS
triggering false alarms'.
> ### CONCLUSION
>
> I think I'll stick to #2 for now. The extra code is reasonable, and I
> don't really see the low accuracy at high speed as a problem. What
> matters much to me is that the user shouldn't have to worry about
> selecting dividers himself, and #2 does this.
I agree with the stated 'I don't really see the low accuracy at high
speed as a problem', but this would suggest a simple
3-or-so-line-patch to solve the problems: just use the highest fan
divider by default. If a user really knows what he is doing, he can
change the divider himself.
--
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: Rutger Nijlunsing <rutger@nospam.com>
To: LM Sensors <sensors@stimpy.netroedge.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Dynamic fan clock divider changes (long)
Date: Sun, 16 May 2004 23:36:45 +0200 [thread overview]
Message-ID: <20040516213645.GA18906@nospam.com> (raw)
In-Reply-To: <20040516222809.2c3d1ea2.khali@linux-fr.org>
On Sun, May 16, 2004 at 10:28:09PM +0200, Jean Delvare wrote:
> Hi all,
>
[snip]
Another implementation to add to the pool. Note I'm not convinced this
is the best solution, since I know little about the hardware
limitations...
Implementation #5
Since the divider can be programmed, it is possible to take two
measurements (all in the driver): first with the highest divider
allowed by the chipset to get an indication of the current speed, and
then a new measurement followed as close as possible to the first one
with a divider fitting the first measured speed.
Example: set divider to 64 (or highest possible divider); fan speed
gives 2500 +- 500. Not set divider to 2 or 1 and re-measure.
Advantages:
- no 'low limit' has to be set magically
- most accurate reading possible on the whole range
- invisible to the user
Disadvantages:
- no 'low limit' can be set in the hardware; low limit must be
processed in software.
- Update frequency of the fan speed will be halved.
Maybe-problem:
- The 'as close as possible' must be in a small range or otherwise
the fan speed may be dropping to fast to fall outside the
measurable range. I do not know with which frequency the fan speed
can be measured.
Processing the low limit in software will also solve the 'BIOS
triggering false alarms'.
> ### CONCLUSION
>
> I think I'll stick to #2 for now. The extra code is reasonable, and I
> don't really see the low accuracy at high speed as a problem. What
> matters much to me is that the user shouldn't have to worry about
> selecting dividers himself, and #2 does this.
I agree with the stated 'I don't really see the low accuracy at high
speed as a problem', but this would suggest a simple
3-or-so-line-patch to solve the problems: just use the highest fan
divider by default. If a user really knows what he is doing, he can
change the divider himself.
--
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
next prev parent reply other threads:[~2005-05-19 6:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-16 20:28 [RFC] Dynamic fan clock divider changes (long) Jean Delvare
2005-05-19 6:24 ` Jean Delvare
2004-05-16 21:36 ` Rutger Nijlunsing [this message]
2005-05-19 6:24 ` Rutger Nijlunsing
2004-05-19 21:28 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
2004-05-20 11:20 ` Paulo Marques
2005-05-19 6:24 ` Paulo Marques
2004-05-22 14:46 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Mark M. Hoffman
2004-05-20 9:03 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:25 ` Mark Studebaker
2005-05-19 6:25 ` Jean Delvare
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=20040516213645.GA18906@nospam.com \
--to=rutger@nospam.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sensors@stimpy.netroedge.com \
/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.