From: Jean Delvare <khali@linux-fr.org>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: ibm-acpi-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org,
lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs
Date: Tue, 27 Feb 2007 10:01:29 +0100 [thread overview]
Message-ID: <20070227100129.fa962c81.khali@linux-fr.org> (raw)
In-Reply-To: <20070226180635.GG2909@khazad-dum.debian.net>
Hi Henrique,
On Mon, 26 Feb 2007 15:06:35 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 26 Feb 2007, Jean Delvare wrote:
> > Either way, I do not think that knowing the last measured speed is that
> > useful. Given that it may be completely unrelated with the current
>
> It is, actually, because it lets one mess with the embedded controller and
> completely override the fan control loop while not letting anyone else
> notice (i.e. without disturbing fan monitor applets, etc).
>
> Check http://thinkwiki.org/wiki/Embedded_Controller_Firmware and
> http://thinkwiki.org/wiki/ACPI_fan_control_script if you are
> curious about the whys for these weird things.
I don't really have time for such long reads, sorry. If there's
anything in particular you think I should know, just tell me.
> > value, I'd rather return -ENXIO or -ERETRY if there is a reasonable
> > chance to get a valid reading soon after. If applications wants to
>
> I will return the stale value or an error, then. Not returning the stale
> value actually requires that I implement some sort of back/white lists to
> differentiate models which don't have the stale tachometer bug from those
> that do... or I need to detect that the tachometer seems to be stuck.
I see. In that case I am fine with you returning the stale value. After
all, the driver is supposed to return the value as read from the
hardware.
> > pwm#_enable = 0 means fan# at full speed, _not_ fan# stopped. Fan# stopped
> > is pwm#_enable = 1 and pwm# = 0.
>
> The hwmon sysfs interface documentation is not clear on that. Turning PWM
> off might lock the hardware into 0% duty or 100% duty depending on how it
> was designed.
Feel free to submit a patch improving the documentation.
> Anyway, I can map it to:
> pwm_enable = 0: disengaged mode on
> 1: manual mode on
> 2+: EC auto mode on (default)
>
> no problem.
> (...)
> Ok. pwm = 0 in manual mode will stop fan, 1..255 will be mapped to 1..7 to
> select the thinkpad fan level, which the EC itself will map to (usually)
> three different speeds.
Yes, this looks good.
> BTW, ibm-acpi implements a "fan watchdog", to help fan-control userspace
> applications. It resets the fan to a safe "on" mode if nothing tries any
> control operation on the fans in a given time period.
>
> Is there any interest in trying for a fan-watchdog generic interface, or
> should I just implement that in sysfs as I see fit for ibm-acpi?
We don't have anything like that in the other drivers. I guess it only
applies to manual mode? The idea is interesting, I have to admit. I
don't have a particular opinion on how to implement that (specific vs
standard), do as you wish.
--
Jean Delvare
WARNING: multiple messages have this Message-ID (diff)
From: khali@linux-fr.org (Jean Delvare)
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: ibm-acpi-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org,
lm-sensors@lm-sensors.org
Subject: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs
Date: Tue, 27 Feb 2007 09:01:29 +0000 [thread overview]
Message-ID: <20070227100129.fa962c81.khali@linux-fr.org> (raw)
In-Reply-To: <20070226180635.GG2909@khazad-dum.debian.net>
Hi Henrique,
On Mon, 26 Feb 2007 15:06:35 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 26 Feb 2007, Jean Delvare wrote:
> > Either way, I do not think that knowing the last measured speed is that
> > useful. Given that it may be completely unrelated with the current
>
> It is, actually, because it lets one mess with the embedded controller and
> completely override the fan control loop while not letting anyone else
> notice (i.e. without disturbing fan monitor applets, etc).
>
> Check http://thinkwiki.org/wiki/Embedded_Controller_Firmware and
> http://thinkwiki.org/wiki/ACPI_fan_control_script if you are
> curious about the whys for these weird things.
I don't really have time for such long reads, sorry. If there's
anything in particular you think I should know, just tell me.
> > value, I'd rather return -ENXIO or -ERETRY if there is a reasonable
> > chance to get a valid reading soon after. If applications wants to
>
> I will return the stale value or an error, then. Not returning the stale
> value actually requires that I implement some sort of back/white lists to
> differentiate models which don't have the stale tachometer bug from those
> that do... or I need to detect that the tachometer seems to be stuck.
I see. In that case I am fine with you returning the stale value. After
all, the driver is supposed to return the value as read from the
hardware.
> > pwm#_enable = 0 means fan# at full speed, _not_ fan# stopped. Fan# stopped
> > is pwm#_enable = 1 and pwm# = 0.
>
> The hwmon sysfs interface documentation is not clear on that. Turning PWM
> off might lock the hardware into 0% duty or 100% duty depending on how it
> was designed.
Feel free to submit a patch improving the documentation.
> Anyway, I can map it to:
> pwm_enable = 0: disengaged mode on
> 1: manual mode on
> 2+: EC auto mode on (default)
>
> no problem.
> (...)
> Ok. pwm = 0 in manual mode will stop fan, 1..255 will be mapped to 1..7 to
> select the thinkpad fan level, which the EC itself will map to (usually)
> three different speeds.
Yes, this looks good.
> BTW, ibm-acpi implements a "fan watchdog", to help fan-control userspace
> applications. It resets the fan to a safe "on" mode if nothing tries any
> control operation on the fans in a given time period.
>
> Is there any interest in trying for a fan-watchdog generic interface, or
> should I just implement that in sysfs as I see fit for ibm-acpi?
We don't have anything like that in the other drivers. I guess it only
applies to manual mode? The idea is interesting, I have to admit. I
don't have a particular opinion on how to implement that (specific vs
standard), do as you wish.
--
Jean Delvare
next prev parent reply other threads:[~2007-02-27 9:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-24 18:20 RFC: conversion of ibm-acpi to hwmon sysfs Henrique de Moraes Holschuh
2007-02-24 18:20 ` [lm-sensors] " Henrique de Moraes Holschuh
2007-02-26 16:27 ` Jean Delvare
2007-02-26 16:27 ` Jean Delvare
2007-02-28 9:31 ` Zhang Rui
2007-02-28 9:31 ` Zhang Rui
2007-02-28 14:34 ` Conversion of ACPI fan+thermal " Henrique de Moraes Holschuh
2007-02-28 14:34 ` [lm-sensors] " Henrique de Moraes Holschuh
2007-03-01 9:37 ` Zhang Rui
2007-03-02 1:12 ` Zhang Rui
2007-03-02 1:12 ` [lm-sensors] " Zhang Rui
2007-03-02 11:13 ` Jean Delvare
2007-03-02 11:13 ` [lm-sensors] " Jean Delvare
2007-03-02 11:43 ` Matthew Garrett
2007-03-02 11:43 ` [lm-sensors] " Matthew Garrett
2007-03-08 9:28 ` Zhang Rui
2007-03-08 9:28 ` [lm-sensors] " Zhang Rui
2007-03-08 11:13 ` Hans de Goede
2007-03-08 11:13 ` Hans de Goede
2007-03-08 13:13 ` Henrique de Moraes Holschuh
2007-03-08 13:13 ` [lm-sensors] " Henrique de Moraes Holschuh
2007-03-09 8:53 ` Jean Delvare
2007-03-09 8:53 ` [lm-sensors] " Jean Delvare
2007-03-01 7:06 ` [lm-sensors] RFC: conversion of ibm-acpi " Jean Delvare
2007-03-01 7:06 ` Jean Delvare
[not found] ` <20070226172716.b2e956b7.khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
2007-02-26 18:06 ` Henrique de Moraes Holschuh
2007-02-26 18:06 ` Henrique de Moraes Holschuh
2007-02-27 9:01 ` Jean Delvare [this message]
2007-02-27 9:01 ` Jean Delvare
2007-02-27 15:41 ` Henrique de Moraes Holschuh
2007-02-27 15:41 ` Henrique de Moraes Holschuh
2007-02-28 14:38 ` Henrique de Moraes Holschuh
2007-02-28 14:38 ` Henrique de Moraes Holschuh
2007-03-01 7:10 ` Jean Delvare
2007-03-01 7:10 ` 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=20070227100129.fa962c81.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=hmh@hmh.eng.br \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=linux-acpi@vger.kernel.org \
--cc=lm-sensors@lm-sensors.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.