RFC: conversion of ibm-acpi to hwmon sysfs

RFC: conversion of ibm-acpi to hwmon sysfs

[Henrique de Moraes Holschuh]

I am working on a conversion of ibm-acpi to sysfs, and in the process I am
trying to do away with every non-generic interface I can.  At least two
ibm-acpi interfaces map directly to hwmon/lm-sensors style: fan and thermal.
I'd like to expose them as hwmon attributes, using the hwmon generic
interfaces for fan control and thermal sensor readings.

I would really appreciate feedback from the lm-sensors/hwmon group on how to
best achieve that.

Thermal is relatively easy.  A thinkpad has either 8 or up to 16 thermal
sensors (typically, 12 sensors), and I can simply export them as
temp##_input, already converted to milidegree Celcius.

However, some thinkpad thermal sensors are hotswappable (they're inside
battery packs, for example).  What is the recommended way to deal with that?

I was planning to return -ENXIO for sensors thare are currently unavailable,
and I could also try to make their sysfs attributes go away (and come back
again) when the driver detects such a change -- note that I don't get events
from the thinkpad firmware when a sensor gets disconnected or reconnected, I
need to poll them to know that).  Is that the recommended way to go about
it?  Or should I just leave all entries there and return -ENXIO on the
invalid ones (the firmware returns -128 for invalid sensors).

fan control is a bit more hard to map to the hwmon interface, as the
thinkpad firmware exports a higher level interface than your regular
thermal-and-fan-monitor chip (and it is far less documented and far more
buggy than regular chips :p):

Most thinkpads have a tachometer that returns data in RPM, and that gets
mapped to fan##_input.  The tachometer can get stale in fan control
disengaged mode (see below), how should I export that information to
userspace?  There is nothing in the standard hwmon sysfs for that, and it
*is* useful to userspace to know the last measured speed, so I don't want to
return -ENXIO or somesuch on fan##_input...   What do you guys suggest I do?
Add an ibm-acpi specific fan##_input_valid attribute that reads 0/1?  Or not
export that information in the first place?  Should I propose such an
attribute to the generic interface?

The thinkpad EC has three modes of fan operation: manual, where there are
seven fan speed levels (0=off, 1=slowest, 7=fastest) that map to different
speeds (usually fan stopped plus three different speeds, so it is not a 1:1
mapping).  auto, where it selects one of the levels by itself, and
disengaged, where it kicks the fan to its highest speed (which usually is
quite higher than level 7).  The levels are closed-loop-controlled, and
track a model-specific desired RPM value.  That allows for consistent
hardware behaviour with fans that are going old or are somewhat dirty.

I was thinking of using pwm##_enable to: force manual mode, level 0 (fan
off) when pwm##_enable is 0, force manual mode when it is 1, and force auto
mode when it is 2+.  I can query what mode the firmware is in, so reading
pwm##_enable is not a problem.

The level for manual mode would be set by pwm##: if it is 0, force level 0.
If it is between 1..90, I'd select one of the six non-stopped fan speed
levels.  If it is above 90, I'd select disengaged mode.

Reading pwm## is not easy.  It is indeterminate if pwm##_enable is set to 2+
(auto mode)... what should I return, then?   For manual mode, I was planning
to return the quantized value (i.e. if 1..26 select fan level 1, a read will
return 26).  For disengaged value (a write of 90..100 with pwm##_enable set
to 1), I'd always return 100.  Is that a good way to implement it?

Note that this interface does not map exacly what the hardware is doing.
When one sets the fan to disengaged mode, the firmware slowly increases fan
speed until it hits max, for example.  There is no way to get any feedback
on what the firmware is *really* doing to the fan, other than the tachometer
readings.

I was going to place all fan attributes in a sysfs group (subdirectory)
named "fan", and all thermal attributes in a sysfs group named "thermal". Is
that acceptable?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Henrique de Moraes Holschuh]

I am working on a conversion of ibm-acpi to sysfs, and in the process I am
trying to do away with every non-generic interface I can.  At least two
ibm-acpi interfaces map directly to hwmon/lm-sensors style: fan and thermal.
I'd like to expose them as hwmon attributes, using the hwmon generic
interfaces for fan control and thermal sensor readings.

I would really appreciate feedback from the lm-sensors/hwmon group on how to
best achieve that.

Thermal is relatively easy.  A thinkpad has either 8 or up to 16 thermal
sensors (typically, 12 sensors), and I can simply export them as
temp##_input, already converted to milidegree Celcius.

However, some thinkpad thermal sensors are hotswappable (they're inside
battery packs, for example).  What is the recommended way to deal with that?

I was planning to return -ENXIO for sensors thare are currently unavailable,
and I could also try to make their sysfs attributes go away (and come back
again) when the driver detects such a change -- note that I don't get events
from the thinkpad firmware when a sensor gets disconnected or reconnected, I
need to poll them to know that).  Is that the recommended way to go about
it?  Or should I just leave all entries there and return -ENXIO on the
invalid ones (the firmware returns -128 for invalid sensors).

fan control is a bit more hard to map to the hwmon interface, as the
thinkpad firmware exports a higher level interface than your regular
thermal-and-fan-monitor chip (and it is far less documented and far more
buggy than regular chips :p):

Most thinkpads have a tachometer that returns data in RPM, and that gets
mapped to fan##_input.  The tachometer can get stale in fan control
disengaged mode (see below), how should I export that information to
userspace?  There is nothing in the standard hwmon sysfs for that, and it
*is* useful to userspace to know the last measured speed, so I don't want to
return -ENXIO or somesuch on fan##_input...   What do you guys suggest I do?
Add an ibm-acpi specific fan##_input_valid attribute that reads 0/1?  Or not
export that information in the first place?  Should I propose such an
attribute to the generic interface?

The thinkpad EC has three modes of fan operation: manual, where there are
seven fan speed levels (0=off, 1=slowest, 7ústest) that map to different
speeds (usually fan stopped plus three different speeds, so it is not a 1:1
mapping).  auto, where it selects one of the levels by itself, and
disengaged, where it kicks the fan to its highest speed (which usually is
quite higher than level 7).  The levels are closed-loop-controlled, and
track a model-specific desired RPM value.  That allows for consistent
hardware behaviour with fans that are going old or are somewhat dirty.

I was thinking of using pwm##_enable to: force manual mode, level 0 (fan
off) when pwm##_enable is 0, force manual mode when it is 1, and force auto
mode when it is 2+.  I can query what mode the firmware is in, so reading
pwm##_enable is not a problem.

The level for manual mode would be set by pwm##: if it is 0, force level 0.
If it is between 1..90, I'd select one of the six non-stopped fan speed
levels.  If it is above 90, I'd select disengaged mode.

Reading pwm## is not easy.  It is indeterminate if pwm##_enable is set to 2+
(auto mode)... what should I return, then?   For manual mode, I was planning
to return the quantized value (i.e. if 1..26 select fan level 1, a read will
return 26).  For disengaged value (a write of 90..100 with pwm##_enable set
to 1), I'd always return 100.  Is that a good way to implement it?

Note that this interface does not map exacly what the hardware is doing.
When one sets the fan to disengaged mode, the firmware slowly increases fan
speed until it hits max, for example.  There is no way to get any feedback
on what the firmware is *really* doing to the fan, other than the tachometer
readings.

I was going to place all fan attributes in a sysfs group (subdirectory)
named "fan", and all thermal attributes in a sysfs group named "thermal". Is
that acceptable?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Jean Delvare]

Hi Henrique,

On Sat, 24 Feb 2007 16:20:24 -0200, Henrique de Moraes Holschuh wrote:
> I am working on a conversion of ibm-acpi to sysfs, and in the process I am
> trying to do away with every non-generic interface I can.  At least two
> ibm-acpi interfaces map directly to hwmon/lm-sensors style: fan and thermal.
> I'd like to expose them as hwmon attributes, using the hwmon generic
> interfaces for fan control and thermal sensor readings.

This would be really great. I was thinking about doing the same for the
standard ACPI "fan" and "thermal" modules too, but I happen to be too
busy for that :( Making these drivers compatible with the hwmon
interface is one way to solve the ACPI vs. hwmon issues which have been
reported and discussed lately.

> I would really appreciate feedback from the lm-sensors/hwmon group on how to
> best achieve that.
> 
> Thermal is relatively easy.  A thinkpad has either 8 or up to 16 thermal
> sensors (typically, 12 sensors), and I can simply export them as
> temp##_input, already converted to milidegree Celcius.
> 
> However, some thinkpad thermal sensors are hotswappable (they're inside
> battery packs, for example).  What is the recommended way to deal with that?
> 
> I was planning to return -ENXIO for sensors thare are currently unavailable,
> and I could also try to make their sysfs attributes go away (and come back
> again) when the driver detects such a change -- note that I don't get events
> from the thinkpad firmware when a sensor gets disconnected or reconnected, I
> need to poll them to know that).  Is that the recommended way to go about
> it?  Or should I just leave all entries there and return -ENXIO on the
> invalid ones (the firmware returns -128 for invalid sensors).

Had you been able to detect disconnections and reconnections as they
happen, removing and creating the files on the file would have been
nice. But as you can't do that, returning -ENXIO on disconnected
sensors sounds sensible. I don't think any other driver does this at
the moment though, so maybe libsensors will need to be updated to
handle this behavior properly.

> fan control is a bit more hard to map to the hwmon interface, as the
> thinkpad firmware exports a higher level interface than your regular
> thermal-and-fan-monitor chip (and it is far less documented and far more
> buggy than regular chips :p):
> 
> Most thinkpads have a tachometer that returns data in RPM, and that gets
> mapped to fan##_input.  The tachometer can get stale in fan control
> disengaged mode (see below), how should I export that information to
> userspace?  There is nothing in the standard hwmon sysfs for that, and it
> *is* useful to userspace to know the last measured speed, so I don't want to
> return -ENXIO or somesuch on fan##_input...   What do you guys suggest I do?
> Add an ibm-acpi specific fan##_input_valid attribute that reads 0/1?  Or not
> export that information in the first place?  Should I propose such an
> attribute to the generic interface?

I'm surprised that the fan speed reading goes stale when a fan runs at
max speed, it doesn't make much physical sense and it's quite the
opposite of what happens usually: tachometers start failing when PWM
modulation distorts the signal to much.

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
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
cache the last read value instead of reporting an error, it's up to
them, not the driver's decision.

I don't want to see *_valid files being created, it doesn't add any
value. Just try to read the data from the file, and check for errors.

> The thinkpad EC has three modes of fan operation: manual, where there are
> seven fan speed levels (0=off, 1=slowest, 7=fastest) that map to different
> speeds (usually fan stopped plus three different speeds, so it is not a 1:1
> mapping).  auto, where it selects one of the levels by itself, and
> disengaged, where it kicks the fan to its highest speed (which usually is
> quite higher than level 7).  The levels are closed-loop-controlled, and
> track a model-specific desired RPM value.  That allows for consistent
> hardware behaviour with fans that are going old or are somewhat dirty.
> 
> I was thinking of using pwm##_enable to: force manual mode, level 0 (fan
> off) when pwm##_enable is 0, force manual mode when it is 1, and force auto
> mode when it is 2+.  I can query what mode the firmware is in, so reading
> pwm##_enable is not a problem.

pwm#_enable = 0 means fan# at full speed, _not_ fan# stopped. Fan# stopped
is pwm#_enable = 1 and pwm# = 0.

> The level for manual mode would be set by pwm##: if it is 0, force level 0.
> If it is between 1..90, I'd select one of the six non-stopped fan speed
> levels.  If it is above 90, I'd select disengaged mode.

According to your description, the disengaged mode corresponds to
pwm_enable = 0 (full speed), so I don't want it to be set automatically
when the user writes a high value to pwm.

> Reading pwm## is not easy.  It is indeterminate if pwm##_enable is set to 2+
> (auto mode)... what should I return, then?   For manual mode, I was planning
> to return the quantized value (i.e. if 1..26 select fan level 1, a read will
> return 26).  For disengaged value (a write of 90..100 with pwm##_enable set
> to 1), I'd always return 100.  Is that a good way to implement it?

Note that the "native" PWM scale is from 0 to 255, not 0 to 100 (I know
it's somewhat confusing, but it's historical and makes drivers more
simple.)

You do not have to return the actual PWM value in automatic mode. Most
chips don't report it and as a result most drivers don't. In automatic
mode, pwm usually holds the value which would be set if manual mode was
to be enabled. Only a few drivers report the current PWM value in
automatic mode there.

> Note that this interface does not map exacly what the hardware is doing.
> When one sets the fan to disengaged mode, the firmware slowly increases fan
> speed until it hits max, for example.  There is no way to get any feedback
> on what the firmware is *really* doing to the fan, other than the tachometer
> readings.

No big deal.

> I was going to place all fan attributes in a sysfs group (subdirectory)
> named "fan", and all thermal attributes in a sysfs group named "thermal". Is
> that acceptable?

No, it's not, as it wouldn't be compatible with what all the other
drivers do and what libsensors expects.

Thanks,
-- 
Jean Delvare

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Jean Delvare]

Hi Henrique,

On Sat, 24 Feb 2007 16:20:24 -0200, Henrique de Moraes Holschuh wrote:
> I am working on a conversion of ibm-acpi to sysfs, and in the process I am
> trying to do away with every non-generic interface I can.  At least two
> ibm-acpi interfaces map directly to hwmon/lm-sensors style: fan and thermal.
> I'd like to expose them as hwmon attributes, using the hwmon generic
> interfaces for fan control and thermal sensor readings.

This would be really great. I was thinking about doing the same for the
standard ACPI "fan" and "thermal" modules too, but I happen to be too
busy for that :( Making these drivers compatible with the hwmon
interface is one way to solve the ACPI vs. hwmon issues which have been
reported and discussed lately.

> I would really appreciate feedback from the lm-sensors/hwmon group on how to
> best achieve that.
> 
> Thermal is relatively easy.  A thinkpad has either 8 or up to 16 thermal
> sensors (typically, 12 sensors), and I can simply export them as
> temp##_input, already converted to milidegree Celcius.
> 
> However, some thinkpad thermal sensors are hotswappable (they're inside
> battery packs, for example).  What is the recommended way to deal with that?
> 
> I was planning to return -ENXIO for sensors thare are currently unavailable,
> and I could also try to make their sysfs attributes go away (and come back
> again) when the driver detects such a change -- note that I don't get events
> from the thinkpad firmware when a sensor gets disconnected or reconnected, I
> need to poll them to know that).  Is that the recommended way to go about
> it?  Or should I just leave all entries there and return -ENXIO on the
> invalid ones (the firmware returns -128 for invalid sensors).

Had you been able to detect disconnections and reconnections as they
happen, removing and creating the files on the file would have been
nice. But as you can't do that, returning -ENXIO on disconnected
sensors sounds sensible. I don't think any other driver does this at
the moment though, so maybe libsensors will need to be updated to
handle this behavior properly.

> fan control is a bit more hard to map to the hwmon interface, as the
> thinkpad firmware exports a higher level interface than your regular
> thermal-and-fan-monitor chip (and it is far less documented and far more
> buggy than regular chips :p):
> 
> Most thinkpads have a tachometer that returns data in RPM, and that gets
> mapped to fan##_input.  The tachometer can get stale in fan control
> disengaged mode (see below), how should I export that information to
> userspace?  There is nothing in the standard hwmon sysfs for that, and it
> *is* useful to userspace to know the last measured speed, so I don't want to
> return -ENXIO or somesuch on fan##_input...   What do you guys suggest I do?
> Add an ibm-acpi specific fan##_input_valid attribute that reads 0/1?  Or not
> export that information in the first place?  Should I propose such an
> attribute to the generic interface?

I'm surprised that the fan speed reading goes stale when a fan runs at
max speed, it doesn't make much physical sense and it's quite the
opposite of what happens usually: tachometers start failing when PWM
modulation distorts the signal to much.

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
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
cache the last read value instead of reporting an error, it's up to
them, not the driver's decision.

I don't want to see *_valid files being created, it doesn't add any
value. Just try to read the data from the file, and check for errors.

> The thinkpad EC has three modes of fan operation: manual, where there are
> seven fan speed levels (0=off, 1=slowest, 7ústest) that map to different
> speeds (usually fan stopped plus three different speeds, so it is not a 1:1
> mapping).  auto, where it selects one of the levels by itself, and
> disengaged, where it kicks the fan to its highest speed (which usually is
> quite higher than level 7).  The levels are closed-loop-controlled, and
> track a model-specific desired RPM value.  That allows for consistent
> hardware behaviour with fans that are going old or are somewhat dirty.
> 
> I was thinking of using pwm##_enable to: force manual mode, level 0 (fan
> off) when pwm##_enable is 0, force manual mode when it is 1, and force auto
> mode when it is 2+.  I can query what mode the firmware is in, so reading
> pwm##_enable is not a problem.

pwm#_enable = 0 means fan# at full speed, _not_ fan# stopped. Fan# stopped
is pwm#_enable = 1 and pwm# = 0.

> The level for manual mode would be set by pwm##: if it is 0, force level 0.
> If it is between 1..90, I'd select one of the six non-stopped fan speed
> levels.  If it is above 90, I'd select disengaged mode.

According to your description, the disengaged mode corresponds to
pwm_enable = 0 (full speed), so I don't want it to be set automatically
when the user writes a high value to pwm.

> Reading pwm## is not easy.  It is indeterminate if pwm##_enable is set to 2+
> (auto mode)... what should I return, then?   For manual mode, I was planning
> to return the quantized value (i.e. if 1..26 select fan level 1, a read will
> return 26).  For disengaged value (a write of 90..100 with pwm##_enable set
> to 1), I'd always return 100.  Is that a good way to implement it?

Note that the "native" PWM scale is from 0 to 255, not 0 to 100 (I know
it's somewhat confusing, but it's historical and makes drivers more
simple.)

You do not have to return the actual PWM value in automatic mode. Most
chips don't report it and as a result most drivers don't. In automatic
mode, pwm usually holds the value which would be set if manual mode was
to be enabled. Only a few drivers report the current PWM value in
automatic mode there.

> Note that this interface does not map exacly what the hardware is doing.
> When one sets the fan to disengaged mode, the firmware slowly increases fan
> speed until it hits max, for example.  There is no way to get any feedback
> on what the firmware is *really* doing to the fan, other than the tachometer
> readings.

No big deal.

> I was going to place all fan attributes in a sysfs group (subdirectory)
> named "fan", and all thermal attributes in a sysfs group named "thermal". Is
> that acceptable?

No, it's not, as it wouldn't be compatible with what all the other
drivers do and what libsensors expects.

Thanks,
-- 
Jean Delvare

Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Henrique de Moraes Holschuh]

On Mon, 26 Feb 2007, Jean Delvare wrote:
> > However, some thinkpad thermal sensors are hotswappable (they're inside
> > battery packs, for example).  What is the recommended way to deal with that?
> > 
> > I was planning to return -ENXIO for sensors thare are currently unavailable,
> > and I could also try to make their sysfs attributes go away (and come back
> > again) when the driver detects such a change -- note that I don't get events
> > from the thinkpad firmware when a sensor gets disconnected or reconnected, I
> > need to poll them to know that).  Is that the recommended way to go about
> > it?  Or should I just leave all entries there and return -ENXIO on the
> > invalid ones (the firmware returns -128 for invalid sensors).
> 
> Had you been able to detect disconnections and reconnections as they
> happen, removing and creating the files on the file would have been
> nice. But as you can't do that, returning -ENXIO on disconnected
> sensors sounds sensible. I don't think any other driver does this at
> the moment though, so maybe libsensors will need to be updated to
> handle this behavior properly.

Ok. -ENXIO it is, that will be a lot easier on the code side too.

> > fan control is a bit more hard to map to the hwmon interface, as the
> > thinkpad firmware exports a higher level interface than your regular
> > thermal-and-fan-monitor chip (and it is far less documented and far more
> > buggy than regular chips :p):
> > 
> > Most thinkpads have a tachometer that returns data in RPM, and that gets
> > mapped to fan##_input.  The tachometer can get stale in fan control
> > disengaged mode (see below), how should I export that information to
> > userspace?  There is nothing in the standard hwmon sysfs for that, and it
> > *is* useful to userspace to know the last measured speed, so I don't want to
> > return -ENXIO or somesuch on fan##_input...   What do you guys suggest I do?
> > Add an ibm-acpi specific fan##_input_valid attribute that reads 0/1?  Or not
> > export that information in the first place?  Should I propose such an
> > attribute to the generic interface?
> 
> I'm surprised that the fan speed reading goes stale when a fan runs at
> max speed, it doesn't make much physical sense and it's quite the
> opposite of what happens usually: tachometers start failing when PWM
> modulation distorts the signal to much.

What can I say? Thinkpad firmware is weird. The EC simply stops updating the
tachometer registers when you tell it to go full-blast on the fans, that's
why we call it "disengaged" mode -- it disengages the control loop.  OTOH,
we got reports that some older ThinkPads (A30) do keep the tachometer
updated even while in full-blast mode
:p

> 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.

> 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.

-ERETRY doesn't make much sense, as the value will only be available when
disengaged mode is disabled, same goes for -EAGAIN.  -ENXIO seems to be the
best choice, as -ESTALE might confuse things, -EIO is for an real IO error,
etc.

> I don't want to see *_valid files being created, it doesn't add any
> value. Just try to read the data from the file, and check for errors.

Ok.

> > The thinkpad EC has three modes of fan operation: manual, where there are
> > seven fan speed levels (0=off, 1=slowest, 7=fastest) that map to different
> > speeds (usually fan stopped plus three different speeds, so it is not a 1:1
> > mapping).  auto, where it selects one of the levels by itself, and
> > disengaged, where it kicks the fan to its highest speed (which usually is
> > quite higher than level 7).  The levels are closed-loop-controlled, and
> > track a model-specific desired RPM value.  That allows for consistent
> > hardware behaviour with fans that are going old or are somewhat dirty.
> > 
> > I was thinking of using pwm##_enable to: force manual mode, level 0 (fan
> > off) when pwm##_enable is 0, force manual mode when it is 1, and force auto
> > mode when it is 2+.  I can query what mode the firmware is in, so reading
> > pwm##_enable is not a problem.
> 
> 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.

Anyway, I can map it to:
	pwm_enable = 0: disengaged mode on
		     1: manual mode on
		     2+: EC auto mode on (default)

no problem.

> > The level for manual mode would be set by pwm##: if it is 0, force level 0.
> > If it is between 1..90, I'd select one of the six non-stopped fan speed
> > levels.  If it is above 90, I'd select disengaged mode.
> 
> According to your description, the disengaged mode corresponds to
> pwm_enable = 0 (full speed), so I don't want it to be set automatically
> when the user writes a high value to pwm.

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.

> Note that the "native" PWM scale is from 0 to 255, not 0 to 100 (I know
> it's somewhat confusing, but it's historical and makes drivers more
> simple.)

Thanks, I failed to notice that for some reason.

> You do not have to return the actual PWM value in automatic mode. Most
> chips don't report it and as a result most drivers don't. In automatic
> mode, pwm usually holds the value which would be set if manual mode was
> to be enabled. Only a few drivers report the current PWM value in
> automatic mode there.

Ok, thanks.

> > I was going to place all fan attributes in a sysfs group (subdirectory)
> > named "fan", and all thermal attributes in a sysfs group named "thermal". Is
> > that acceptable?
> 
> No, it's not, as it wouldn't be compatible with what all the other
> drivers do and what libsensors expects.

Very well.  No sysfs groups for fan or thermal.

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?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Henrique de Moraes Holschuh]

On Mon, 26 Feb 2007, Jean Delvare wrote:
> > However, some thinkpad thermal sensors are hotswappable (they're inside
> > battery packs, for example).  What is the recommended way to deal with that?
> > 
> > I was planning to return -ENXIO for sensors thare are currently unavailable,
> > and I could also try to make their sysfs attributes go away (and come back
> > again) when the driver detects such a change -- note that I don't get events
> > from the thinkpad firmware when a sensor gets disconnected or reconnected, I
> > need to poll them to know that).  Is that the recommended way to go about
> > it?  Or should I just leave all entries there and return -ENXIO on the
> > invalid ones (the firmware returns -128 for invalid sensors).
> 
> Had you been able to detect disconnections and reconnections as they
> happen, removing and creating the files on the file would have been
> nice. But as you can't do that, returning -ENXIO on disconnected
> sensors sounds sensible. I don't think any other driver does this at
> the moment though, so maybe libsensors will need to be updated to
> handle this behavior properly.

Ok. -ENXIO it is, that will be a lot easier on the code side too.

> > fan control is a bit more hard to map to the hwmon interface, as the
> > thinkpad firmware exports a higher level interface than your regular
> > thermal-and-fan-monitor chip (and it is far less documented and far more
> > buggy than regular chips :p):
> > 
> > Most thinkpads have a tachometer that returns data in RPM, and that gets
> > mapped to fan##_input.  The tachometer can get stale in fan control
> > disengaged mode (see below), how should I export that information to
> > userspace?  There is nothing in the standard hwmon sysfs for that, and it
> > *is* useful to userspace to know the last measured speed, so I don't want to
> > return -ENXIO or somesuch on fan##_input...   What do you guys suggest I do?
> > Add an ibm-acpi specific fan##_input_valid attribute that reads 0/1?  Or not
> > export that information in the first place?  Should I propose such an
> > attribute to the generic interface?
> 
> I'm surprised that the fan speed reading goes stale when a fan runs at
> max speed, it doesn't make much physical sense and it's quite the
> opposite of what happens usually: tachometers start failing when PWM
> modulation distorts the signal to much.

What can I say? Thinkpad firmware is weird. The EC simply stops updating the
tachometer registers when you tell it to go full-blast on the fans, that's
why we call it "disengaged" mode -- it disengages the control loop.  OTOH,
we got reports that some older ThinkPads (A30) do keep the tachometer
updated even while in full-blast mode
:p

> 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.

> 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.

-ERETRY doesn't make much sense, as the value will only be available when
disengaged mode is disabled, same goes for -EAGAIN.  -ENXIO seems to be the
best choice, as -ESTALE might confuse things, -EIO is for an real IO error,
etc.

> I don't want to see *_valid files being created, it doesn't add any
> value. Just try to read the data from the file, and check for errors.

Ok.

> > The thinkpad EC has three modes of fan operation: manual, where there are
> > seven fan speed levels (0=off, 1=slowest, 7ústest) that map to different
> > speeds (usually fan stopped plus three different speeds, so it is not a 1:1
> > mapping).  auto, where it selects one of the levels by itself, and
> > disengaged, where it kicks the fan to its highest speed (which usually is
> > quite higher than level 7).  The levels are closed-loop-controlled, and
> > track a model-specific desired RPM value.  That allows for consistent
> > hardware behaviour with fans that are going old or are somewhat dirty.
> > 
> > I was thinking of using pwm##_enable to: force manual mode, level 0 (fan
> > off) when pwm##_enable is 0, force manual mode when it is 1, and force auto
> > mode when it is 2+.  I can query what mode the firmware is in, so reading
> > pwm##_enable is not a problem.
> 
> 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.

Anyway, I can map it to:
	pwm_enable = 0: disengaged mode on
		     1: manual mode on
		     2+: EC auto mode on (default)

no problem.

> > The level for manual mode would be set by pwm##: if it is 0, force level 0.
> > If it is between 1..90, I'd select one of the six non-stopped fan speed
> > levels.  If it is above 90, I'd select disengaged mode.
> 
> According to your description, the disengaged mode corresponds to
> pwm_enable = 0 (full speed), so I don't want it to be set automatically
> when the user writes a high value to pwm.

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.

> Note that the "native" PWM scale is from 0 to 255, not 0 to 100 (I know
> it's somewhat confusing, but it's historical and makes drivers more
> simple.)

Thanks, I failed to notice that for some reason.

> You do not have to return the actual PWM value in automatic mode. Most
> chips don't report it and as a result most drivers don't. In automatic
> mode, pwm usually holds the value which would be set if manual mode was
> to be enabled. Only a few drivers report the current PWM value in
> automatic mode there.

Ok, thanks.

> > I was going to place all fan attributes in a sysfs group (subdirectory)
> > named "fan", and all thermal attributes in a sysfs group named "thermal". Is
> > that acceptable?
> 
> No, it's not, as it wouldn't be compatible with what all the other
> drivers do and what libsensors expects.

Very well.  No sysfs groups for fan or thermal.

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?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Jean Delvare]

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

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Jean Delvare]

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

Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Henrique de Moraes Holschuh]

On Tue, 27 Feb 2007, Jean Delvare wrote:
> 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.

Just that the stale value is indeed useful on one particular case.

> > > 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.

Ok.

> > 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.

The fan watchdog is a driver thing, it could be implemented by any driver
for any chip that has a manual mode (it doesn't make sense if the chip is
always in auto mode).  I will implement it in a suitable-to-be-generic way
and propose a patch for the sysfs hwmon docs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Henrique de Moraes Holschuh]

On Tue, 27 Feb 2007, Jean Delvare wrote:
> 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.

Just that the stale value is indeed useful on one particular case.

> > > 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.

Ok.

> > 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.

The fan watchdog is a driver thing, it could be implemented by any driver
for any chip that has a manual mode (it doesn't make sense if the chip is
always in auto mode).  I will implement it in a suitable-to-be-generic way
and propose a patch for the sysfs hwmon docs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Zhang Rui]

On Mon, 2007-02-26 at 17:27 +0100, Jean Delvare wrote:
> Hi Henrique,
> 
> On Sat, 24 Feb 2007 16:20:24 -0200, Henrique de Moraes Holschuh wrote:
> > I am working on a conversion of ibm-acpi to sysfs, and in the process I am
> > trying to do away with every non-generic interface I can.  At least two
> > ibm-acpi interfaces map directly to hwmon/lm-sensors style: fan and thermal.
> > I'd like to expose them as hwmon attributes, using the hwmon generic
> > interfaces for fan control and thermal sensor readings.
> 
> This would be really great. I was thinking about doing the same for the
> standard ACPI "fan" and "thermal" modules too, but I happen to be too
> busy for that :( Making these drivers compatible with the hwmon
> interface is one way to solve the ACPI vs. hwmon issues which have been
> reported and discussed lately.
> 
The standard ACPI "fan" and "thermal" modules?
I'm converting these two modules to sysfs. I think "thermal" has too
much ACPI specific information and is not that easy to have a generic
interface.
Could you give some more detailed descriptions please? :)

Thanks,
Rui

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Zhang Rui]

On Mon, 2007-02-26 at 17:27 +0100, Jean Delvare wrote:
> Hi Henrique,
> 
> On Sat, 24 Feb 2007 16:20:24 -0200, Henrique de Moraes Holschuh wrote:
> > I am working on a conversion of ibm-acpi to sysfs, and in the process I am
> > trying to do away with every non-generic interface I can.  At least two
> > ibm-acpi interfaces map directly to hwmon/lm-sensors style: fan and thermal.
> > I'd like to expose them as hwmon attributes, using the hwmon generic
> > interfaces for fan control and thermal sensor readings.
> 
> This would be really great. I was thinking about doing the same for the
> standard ACPI "fan" and "thermal" modules too, but I happen to be too
> busy for that :( Making these drivers compatible with the hwmon
> interface is one way to solve the ACPI vs. hwmon issues which have been
> reported and discussed lately.
> 
The standard ACPI "fan" and "thermal" modules?
I'm converting these two modules to sysfs. I think "thermal" has too
much ACPI specific information and is not that easy to have a generic
interface.
Could you give some more detailed descriptions please? :)

Thanks,
Rui

Conversion of ACPI fan+thermal to hwmon sysfs

[Henrique de Moraes Holschuh]

(ibm-acpi-devel removed from cc, subject changed)

On Wed, 28 Feb 2007, Zhang Rui wrote:
> I'm converting these two modules to sysfs. I think "thermal" has too
> much ACPI specific information and is not that easy to have a generic
> interface.

It is not easy.  In fact, it could be quite complicated.  But when combined
with the fan objects, it should be possible.

hwmon's idea of thermal zones are chip-specific, so the way to get ACPI to
work with that without much changes is to think of the entire ACPI model as
a "single chip".  This probably means ACPI fan and thermal zones need to
cooperate to be ported to the hwmon model.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Henrique de Moraes Holschuh]

(ibm-acpi-devel removed from cc, subject changed)

On Wed, 28 Feb 2007, Zhang Rui wrote:
> I'm converting these two modules to sysfs. I think "thermal" has too
> much ACPI specific information and is not that easy to have a generic
> interface.

It is not easy.  In fact, it could be quite complicated.  But when combined
with the fan objects, it should be possible.

hwmon's idea of thermal zones are chip-specific, so the way to get ACPI to
work with that without much changes is to think of the entire ACPI model as
a "single chip".  This probably means ACPI fan and thermal zones need to
cooperate to be ported to the hwmon model.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Henrique de Moraes Holschuh]

On Mon, 26 Feb 2007, Jean Delvare wrote:
> > I was going to place all fan attributes in a sysfs group (subdirectory)
> > named "fan", and all thermal attributes in a sysfs group named "thermal". Is
> > that acceptable?
> 
> No, it's not, as it wouldn't be compatible with what all the other
> drivers do and what libsensors expects.

Ok, I have fan*_* and temp*_input hanging directly from the device (no
groups).  However, that device has a lot of other stuff that is not even
remotely accounted for in hwmon, such as control of video outputs and
hotkeys, the firmware action beeper, etc.

Does that cause problems for lm-sensors, or would it just ignore the extra
attributes and groups?

I can provide two devices, ibm-acpi.0 and ibm-acpi.1, and have the hwmon
attributes in only one of them, and register just that one with the hwmon
class.  Would that be better/safer?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Henrique de Moraes Holschuh]

On Mon, 26 Feb 2007, Jean Delvare wrote:
> > I was going to place all fan attributes in a sysfs group (subdirectory)
> > named "fan", and all thermal attributes in a sysfs group named "thermal". Is
> > that acceptable?
> 
> No, it's not, as it wouldn't be compatible with what all the other
> drivers do and what libsensors expects.

Ok, I have fan*_* and temp*_input hanging directly from the device (no
groups).  However, that device has a lot of other stuff that is not even
remotely accounted for in hwmon, such as control of video outputs and
hotkeys, the firmware action beeper, etc.

Does that cause problems for lm-sensors, or would it just ignore the extra
attributes and groups?

I can provide two devices, ibm-acpi.0 and ibm-acpi.1, and have the hwmon
attributes in only one of them, and register just that one with the hwmon
class.  Would that be better/safer?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Jean Delvare]

On Wed, 28 Feb 2007 17:31:51 +0800, Zhang Rui wrote:
> The standard ACPI "fan" and "thermal" modules?
> I'm converting these two modules to sysfs. I think "thermal" has too
> much ACPI specific information and is not that easy to have a generic
> interface.
> Could you give some more detailed descriptions please? :)

Indeed, ACPI thermal zone may have more thermal trip points than the
hwmon interface specifies. Two of the trip points can be mapped to
temp1_max and temp1_crit, respectively. If we want to handle them all,
then probably we have to implement Henrique's suggestion and really
think in terms of thermal zones, i.e. the trip points would be mapped
to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
output.

-- 
Jean Delvare

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Jean Delvare]

On Wed, 28 Feb 2007 17:31:51 +0800, Zhang Rui wrote:
> The standard ACPI "fan" and "thermal" modules?
> I'm converting these two modules to sysfs. I think "thermal" has too
> much ACPI specific information and is not that easy to have a generic
> interface.
> Could you give some more detailed descriptions please? :)

Indeed, ACPI thermal zone may have more thermal trip points than the
hwmon interface specifies. Two of the trip points can be mapped to
temp1_max and temp1_crit, respectively. If we want to handle them all,
then probably we have to implement Henrique's suggestion and really
think in terms of thermal zones, i.e. the trip points would be mapped
to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
output.

-- 
Jean Delvare

Re: [lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Jean Delvare]

On Wed, 28 Feb 2007 11:38:36 -0300, Henrique de Moraes Holschuh wrote:
> Ok, I have fan*_* and temp*_input hanging directly from the device (no
> groups).  However, that device has a lot of other stuff that is not even
> remotely accounted for in hwmon, such as control of video outputs and
> hotkeys, the firmware action beeper, etc.
> 
> Does that cause problems for lm-sensors, or would it just ignore the extra
> attributes and groups?

As long as the other file names do not collide with the any of names in
Documentation/hwmon/sysfs-interface, it's OK. libsensors will ignore
the extra stuff.

> I can provide two devices, ibm-acpi.0 and ibm-acpi.1, and have the hwmon
> attributes in only one of them, and register just that one with the hwmon
> class.  Would that be better/safer?

A single device would be fine. In the long run we will probbaly have to
turn the hwmon attributes into class attributes anyway, so they will
get their own naming space.

-- 
Jean Delvare

[lm-sensors] RFC: conversion of ibm-acpi to hwmon sysfs

[Jean Delvare]

On Wed, 28 Feb 2007 11:38:36 -0300, Henrique de Moraes Holschuh wrote:
> Ok, I have fan*_* and temp*_input hanging directly from the device (no
> groups).  However, that device has a lot of other stuff that is not even
> remotely accounted for in hwmon, such as control of video outputs and
> hotkeys, the firmware action beeper, etc.
> 
> Does that cause problems for lm-sensors, or would it just ignore the extra
> attributes and groups?

As long as the other file names do not collide with the any of names in
Documentation/hwmon/sysfs-interface, it's OK. libsensors will ignore
the extra stuff.

> I can provide two devices, ibm-acpi.0 and ibm-acpi.1, and have the hwmon
> attributes in only one of them, and register just that one with the hwmon
> class.  Would that be better/safer?

A single device would be fine. In the long run we will probbaly have to
turn the hwmon attributes into class attributes anyway, so they will
get their own naming space.

-- 
Jean Delvare

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Zhang Rui]

On Wed, 2007-02-28 at 11:34 -0300, Henrique de Moraes Holschuh wrote:
> 
> On Wed, 28 Feb 2007, Zhang Rui wrote:
> > I'm converting these two modules to sysfs. I think "thermal" has too
> > much ACPI specific information and is not that easy to have a generic
> > interface.
> 
> It is not easy.  In fact, it could be quite complicated.  But when combined
> with the fan objects, it should be possible.
> 
> hwmon's idea of thermal zones are chip-specific, so the way to get ACPI to
> work with that without much changes is to think of the entire ACPI model as
> a "single chip".  This probably means ACPI fan and thermal zones need to
> cooperate to be ported to the hwmon model.
> 
On Thu, 2007-03-01 at 08:06 +0100, Jean Delvare wrote: 
> Indeed, ACPI thermal zone may have more thermal trip points than the
> hwmon interface specifies. Two of the trip points can be mapped to
> temp1_max and temp1_crit, respectively. If we want to handle them all,
> then probably we have to implement Henrique's suggestion and really
> think in terms of thermal zones, i.e. the trip points would be mapped
> to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
> output.
> 
Well, ACPI thermal zones are not only a logical collection of interfaces
to temperature sensors, trip points and thermal property information,
but also take charge of thermal controls, i.e. setting platform's
cooling mode policies.
I don't know if I missed something, but from Documentation/hwmon/sysfs-
interface, I can't find any interface that make it possible.
And, porting ACPI fan and thermal zones to the hwmon model? That is
really complicated.
Add Len and Konstantin to cc list and see if they have any ideas. :)

Re: Conversion of ACPI fan+thermal to hwmon sysfs

[Zhang Rui]

On Wed, 2007-02-28 at 11:34 -0300, Henrique de Moraes Holschuh wrote:
> (ibm-acpi-devel removed from cc, subject changed)
> 
> On Wed, 28 Feb 2007, Zhang Rui wrote:
> > I'm converting these two modules to sysfs. I think "thermal" has too
> > much ACPI specific information and is not that easy to have a generic
> > interface.
> 
> It is not easy.  In fact, it could be quite complicated.  But when combined
> with the fan objects, it should be possible.
> 
> hwmon's idea of thermal zones are chip-specific, so the way to get ACPI to
> work with that without much changes is to think of the entire ACPI model as
> a "single chip".  This probably means ACPI fan and thermal zones need to
> cooperate to be ported to the hwmon model.
> 

On Thu, 2007-03-01 at 08:06 +0100, Jean Delvare wrote: 
> Indeed, ACPI thermal zone may have more thermal trip points than the
> hwmon interface specifies. Two of the trip points can be mapped to
> temp1_max and temp1_crit, respectively. If we want to handle them all,
> then probably we have to implement Henrique's suggestion and really
> think in terms of thermal zones, i.e. the trip points would be mapped
> to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
> output.
> 

Well, ACPI thermal zones are not only a logical collection of interfaces
to temperature sensors, trip points and thermal property information,
but also take charge of thermal controls, i.e. setting platform's
cooling mode policies.
I don't know if I missed something, but from Documentation/hwmon/sysfs-
interface, I can't find any interface that make it possible.
And, porting ACPI fan and thermal zones to the hwmon model? That is
really complicated.
Add Len and Konstantin to cc list and see if they have any ideas. :)

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Zhang Rui]

On Wed, 2007-02-28 at 11:34 -0300, Henrique de Moraes Holschuh wrote:
> (ibm-acpi-devel removed from cc, subject changed)
> 
> On Wed, 28 Feb 2007, Zhang Rui wrote:
> > I'm converting these two modules to sysfs. I think "thermal" has too
> > much ACPI specific information and is not that easy to have a generic
> > interface.
> 
> It is not easy.  In fact, it could be quite complicated.  But when combined
> with the fan objects, it should be possible.
> 
> hwmon's idea of thermal zones are chip-specific, so the way to get ACPI to
> work with that without much changes is to think of the entire ACPI model as
> a "single chip".  This probably means ACPI fan and thermal zones need to
> cooperate to be ported to the hwmon model.
> 

On Thu, 2007-03-01 at 08:06 +0100, Jean Delvare wrote: 
> Indeed, ACPI thermal zone may have more thermal trip points than the
> hwmon interface specifies. Two of the trip points can be mapped to
> temp1_max and temp1_crit, respectively. If we want to handle them all,
> then probably we have to implement Henrique's suggestion and really
> think in terms of thermal zones, i.e. the trip points would be mapped
> to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
> output.
> 

Well, ACPI thermal zones are not only a logical collection of interfaces
to temperature sensors, trip points and thermal property information,
but also take charge of thermal controls, i.e. setting platform's
cooling mode policies.
I don't know if I missed something, but from Documentation/hwmon/sysfs-
interface, I can't find any interface that make it possible.
And, porting ACPI fan and thermal zones to the hwmon model? That is
really complicated.
Add Len and Konstantin to cc list and see if they have any ideas. :)

Re: Conversion of ACPI fan+thermal to hwmon sysfs

[Jean Delvare]

Hi Zhang,

> On Thu, 2007-03-01 at 08:06 +0100, Jean Delvare wrote: 
> > Indeed, ACPI thermal zone may have more thermal trip points than the
> > hwmon interface specifies. Two of the trip points can be mapped to
> > temp1_max and temp1_crit, respectively. If we want to handle them all,
> > then probably we have to implement Henrique's suggestion and really
> > think in terms of thermal zones, i.e. the trip points would be mapped
> > to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
> > output.
> 
> Well, ACPI thermal zones are not only a logical collection of interfaces
> to temperature sensors, trip points and thermal property information,
> but also take charge of thermal controls, i.e. setting platform's
> cooling mode policies.
> I don't know if I missed something, but from Documentation/hwmon/sysfs-
> interface, I can't find any interface that make it possible.

As I don't know what these "cooling mode policies" are, I can't really
tell. Trip points in hwmon let the user define the desired fan speed
depending on a temperature measurement, and that's about it. You can't
associate other actions at the moment, essentially because hardware
monitoring chips themselves can't do anything else. If it would be
convenient for the ACPI case to add something else, we can discuss
additional interface files.

> And, porting ACPI fan and thermal zones to the hwmon model? That is
> really complicated.
> Add Len and Konstantin to cc list and see if they have any ideas. :)

My original idea was to simply add a read-only hwmon-like interface to
the acpi fan and thermal modules. I didn't plan to replace the current
interfaces offered by these modules, at least not directly. There must
be many user-space tools and scripts relying on these at the moment, so
we need a transition period anyway.

-- 
Jean Delvare

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Jean Delvare]

Hi Zhang,

> On Thu, 2007-03-01 at 08:06 +0100, Jean Delvare wrote: 
> > Indeed, ACPI thermal zone may have more thermal trip points than the
> > hwmon interface specifies. Two of the trip points can be mapped to
> > temp1_max and temp1_crit, respectively. If we want to handle them all,
> > then probably we have to implement Henrique's suggestion and really
> > think in terms of thermal zones, i.e. the trip points would be mapped
> > to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
> > output.
> 
> Well, ACPI thermal zones are not only a logical collection of interfaces
> to temperature sensors, trip points and thermal property information,
> but also take charge of thermal controls, i.e. setting platform's
> cooling mode policies.
> I don't know if I missed something, but from Documentation/hwmon/sysfs-
> interface, I can't find any interface that make it possible.

As I don't know what these "cooling mode policies" are, I can't really
tell. Trip points in hwmon let the user define the desired fan speed
depending on a temperature measurement, and that's about it. You can't
associate other actions at the moment, essentially because hardware
monitoring chips themselves can't do anything else. If it would be
convenient for the ACPI case to add something else, we can discuss
additional interface files.

> And, porting ACPI fan and thermal zones to the hwmon model? That is
> really complicated.
> Add Len and Konstantin to cc list and see if they have any ideas. :)

My original idea was to simply add a read-only hwmon-like interface to
the acpi fan and thermal modules. I didn't plan to replace the current
interfaces offered by these modules, at least not directly. There must
be many user-space tools and scripts relying on these at the moment, so
we need a transition period anyway.

-- 
Jean Delvare

Re: Conversion of ACPI fan+thermal to hwmon sysfs

[Matthew Garrett]

On Fri, Mar 02, 2007 at 12:13:04PM +0100, Jean Delvare wrote:

> As I don't know what these "cooling mode policies" are, I can't really
> tell. Trip points in hwmon let the user define the desired fan speed
> depending on a temperature measurement, and that's about it. You can't
> associate other actions at the moment, essentially because hardware
> monitoring chips themselves can't do anything else. If it would be
> convenient for the ACPI case to add something else, we can discuss
> additional interface files.

ACPI cooling mode policies may be related to fans, but can also be 
associated with passive cooling of the CPU by throttling or voltage 
scaling. Some machines keep the fan under BIOS control, so the only 
information exposed via the thermal module will be something like:

critical (S5):           95 C
passive:                 91 C: tc1=5 tc2=4 tsp=600 devices=0xc16dd310 

indicating that the CPU should be throttled at 91C, and the system 
forcibly shut down at 95C. 

> My original idea was to simply add a read-only hwmon-like interface to
> the acpi fan and thermal modules. I didn't plan to replace the current
> interfaces offered by these modules, at least not directly. There must
> be many user-space tools and scripts relying on these at the moment, so
> we need a transition period anyway.

That doesn't sound like a bad plan.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Matthew Garrett]

On Fri, Mar 02, 2007 at 12:13:04PM +0100, Jean Delvare wrote:

> As I don't know what these "cooling mode policies" are, I can't really
> tell. Trip points in hwmon let the user define the desired fan speed
> depending on a temperature measurement, and that's about it. You can't
> associate other actions at the moment, essentially because hardware
> monitoring chips themselves can't do anything else. If it would be
> convenient for the ACPI case to add something else, we can discuss
> additional interface files.

ACPI cooling mode policies may be related to fans, but can also be 
associated with passive cooling of the CPU by throttling or voltage 
scaling. Some machines keep the fan under BIOS control, so the only 
information exposed via the thermal module will be something like:

critical (S5):           95 C
passive:                 91 C: tc1=5 tc2=4 tsp`0 devices=0xc16dd310 

indicating that the CPU should be throttled at 91C, and the system 
forcibly shut down at 95C. 

> My original idea was to simply add a read-only hwmon-like interface to
> the acpi fan and thermal modules. I didn't plan to replace the current
> interfaces offered by these modules, at least not directly. There must
> be many user-space tools and scripts relying on these at the moment, so
> we need a transition period anyway.

That doesn't sound like a bad plan.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

Re: Conversion of ACPI fan+thermal to hwmon sysfs

[Zhang Rui]

On Fri, 2007-03-02 at 12:13 +0100, Jean Delvare wrote:
> Hi Zhang,
> 
> > On Thu, 2007-03-01 at 08:06 +0100, Jean Delvare wrote: 
> > > Indeed, ACPI thermal zone may have more thermal trip points than the
> > > hwmon interface specifies. Two of the trip points can be mapped to
> > > temp1_max and temp1_crit, respectively. If we want to handle them all,
> > > then probably we have to implement Henrique's suggestion and really
> > > think in terms of thermal zones, i.e. the trip points would be mapped
> > > to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
> > > output.
> > 
> > Well, ACPI thermal zones are not only a logical collection of interfaces
> > to temperature sensors, trip points and thermal property information,
> > but also take charge of thermal controls, i.e. setting platform's
> > cooling mode policies.
> > I don't know if I missed something, but from Documentation/hwmon/sysfs-
> > interface, I can't find any interface that make it possible.
> 
> As I don't know what these "cooling mode policies" are, I can't really
> tell. Trip points in hwmon let the user define the desired fan speed
> depending on a temperature measurement, and that's about it. You can't
> associate other actions at the moment, essentially because hardware
> monitoring chips themselves can't do anything else. If it would be
> convenient for the ACPI case to add something else, we can discuss
> additional interface files.
> 
OK.
I still have some problems.

First, ACPI thermal zone can be used to set different cooling policies,
i.e. passive cooling mode and active cooling mode.
In passive mode, just as Matthew Garrett described, ACPI thermal may
throttle the CPU if the passive trip point is triggered, i.e. cool a
thermal zone by decreasing the performance of the devices(always CPU
now) in the zone.
The active cooling mode will use one or more active devices(usually fan)
to decrease the temperature, which consume extra power. And this is
really like the way that the hwmon is doing.
So we can only map the active cooling policy to hwmon, right?

Second, one ACPI thermal zone may have more than one fan devices, even
one active trip point may associate with several fan devices. And this
seems to be different from the sensors, doesn't it?

Third, ACPI can not get/set the fan speed. It can only deal with the fan
D-state. Fan is on in D0 state and off in D3 state.
IMO, the hwmon sysfs interface make it very convenient for users to
define the desired fan speed depending on a temperature measurement.
And it seems that we can't take use of this if we map ACPI thermal and
fan to hwmon-like sysfs interface, right?

This is my understanding of the hwmon. And if there is something wrong,
please help me point it out. :)

> My original idea was to simply add a read-only hwmon-like interface to
> the acpi fan and thermal modules. I didn't plan to replace the current
> interfaces offered by these modules, at least not directly. There must
> be many user-space tools and scripts relying on these at the moment, so
> we need a transition period anyway.
> 
Agree.
I've already finished the patch to duplicate ACPI procfs function in
sysfs, i.e. export the similar information while in sysfs style. And I
think this can make it not so painful for use-space tools and scripts to
convert to sysfs interface.
Oh, a _read-only_ interface? Then, it will be much easier.
But what is it used for?

Thanks,
Rui

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Zhang Rui]

On Fri, 2007-03-02 at 12:13 +0100, Jean Delvare wrote:
> Hi Zhang,
> 
> > On Thu, 2007-03-01 at 08:06 +0100, Jean Delvare wrote: 
> > > Indeed, ACPI thermal zone may have more thermal trip points than the
> > > hwmon interface specifies. Two of the trip points can be mapped to
> > > temp1_max and temp1_crit, respectively. If we want to handle them all,
> > > then probably we have to implement Henrique's suggestion and really
> > > think in terms of thermal zones, i.e. the trip points would be mapped
> > > to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
> > > output.
> > 
> > Well, ACPI thermal zones are not only a logical collection of interfaces
> > to temperature sensors, trip points and thermal property information,
> > but also take charge of thermal controls, i.e. setting platform's
> > cooling mode policies.
> > I don't know if I missed something, but from Documentation/hwmon/sysfs-
> > interface, I can't find any interface that make it possible.
> 
> As I don't know what these "cooling mode policies" are, I can't really
> tell. Trip points in hwmon let the user define the desired fan speed
> depending on a temperature measurement, and that's about it. You can't
> associate other actions at the moment, essentially because hardware
> monitoring chips themselves can't do anything else. If it would be
> convenient for the ACPI case to add something else, we can discuss
> additional interface files.
> 
OK.
I still have some problems.

First, ACPI thermal zone can be used to set different cooling policies,
i.e. passive cooling mode and active cooling mode.
In passive mode, just as Matthew Garrett described, ACPI thermal may
throttle the CPU if the passive trip point is triggered, i.e. cool a
thermal zone by decreasing the performance of the devices(always CPU
now) in the zone.
The active cooling mode will use one or more active devices(usually fan)
to decrease the temperature, which consume extra power. And this is
really like the way that the hwmon is doing.
So we can only map the active cooling policy to hwmon, right?

Second, one ACPI thermal zone may have more than one fan devices, even
one active trip point may associate with several fan devices. And this
seems to be different from the sensors, doesn't it?

Third, ACPI can not get/set the fan speed. It can only deal with the fan
D-state. Fan is on in D0 state and off in D3 state.
IMO, the hwmon sysfs interface make it very convenient for users to
define the desired fan speed depending on a temperature measurement.
And it seems that we can't take use of this if we map ACPI thermal and
fan to hwmon-like sysfs interface, right?

This is my understanding of the hwmon. And if there is something wrong,
please help me point it out. :)

> My original idea was to simply add a read-only hwmon-like interface to
> the acpi fan and thermal modules. I didn't plan to replace the current
> interfaces offered by these modules, at least not directly. There must
> be many user-space tools and scripts relying on these at the moment, so
> we need a transition period anyway.
> 
Agree.
I've already finished the patch to duplicate ACPI procfs function in
sysfs, i.e. export the similar information while in sysfs style. And I
think this can make it not so painful for use-space tools and scripts to
convert to sysfs interface.
Oh, a _read-only_ interface? Then, it will be much easier.
But what is it used for?

Thanks,
Rui

Re: [lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Hans de Goede]

Zhang Rui wrote:
> On Fri, 2007-03-02 at 12:13 +0100, Jean Delvare wrote:
>> My original idea was to simply add a read-only hwmon-like interface to
>> the acpi fan and thermal modules. I didn't plan to replace the current
>> interfaces offered by these modules, at least not directly. There must
>> be many user-space tools and scripts relying on these at the moment, so
>> we need a transition period anyway.
>>
> Agree.
> I've already finished the patch to duplicate ACPI procfs function in
> sysfs, i.e. export the similar information while in sysfs style. And I
> think this can make it not so painful for use-space tools and scripts to
> convert to sysfs interface.
> Oh, a _read-only_ interface? Then, it will be much easier.
> But what is it used for?
> 

For libsensors using applications like sensors, gkrellm and ksensors to display 
temp and fan info?

Regards,

Hans

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Hans de Goede]

Zhang Rui wrote:
> On Fri, 2007-03-02 at 12:13 +0100, Jean Delvare wrote:
>> My original idea was to simply add a read-only hwmon-like interface to
>> the acpi fan and thermal modules. I didn't plan to replace the current
>> interfaces offered by these modules, at least not directly. There must
>> be many user-space tools and scripts relying on these at the moment, so
>> we need a transition period anyway.
>>
> Agree.
> I've already finished the patch to duplicate ACPI procfs function in
> sysfs, i.e. export the similar information while in sysfs style. And I
> think this can make it not so painful for use-space tools and scripts to
> convert to sysfs interface.
> Oh, a _read-only_ interface? Then, it will be much easier.
> But what is it used for?
> 

For libsensors using applications like sensors, gkrellm and ksensors to display 
temp and fan info?

Regards,

Hans

Re: Conversion of ACPI fan+thermal to hwmon sysfs

[Henrique de Moraes Holschuh]

On Thu, 08 Mar 2007, Zhang Rui wrote:
> First, ACPI thermal zone can be used to set different cooling policies,
> i.e. passive cooling mode and active cooling mode.
> In passive mode, just as Matthew Garrett described, ACPI thermal may
> throttle the CPU if the passive trip point is triggered, i.e. cool a
> thermal zone by decreasing the performance of the devices(always CPU
> now) in the zone.
> The active cooling mode will use one or more active devices(usually fan)
> to decrease the temperature, which consume extra power. And this is
> really like the way that the hwmon is doing.
> So we can only map the active cooling policy to hwmon, right?

Right, which is not to say we can't extend hwmon to also cover passive.

> Second, one ACPI thermal zone may have more than one fan devices, even
> one active trip point may associate with several fan devices. And this
> seems to be different from the sensors, doesn't it?

No, a LM85 does that too.  I don't recall if the current interface allows
for that mapping easily, but if it doesn't, it needs to be modified.

> Third, ACPI can not get/set the fan speed. It can only deal with the fan
> D-state. Fan is on in D0 state and off in D3 state.

That is easy to map to hwmon, you just don't implement some of the pwm
stuff.

> IMO, the hwmon sysfs interface make it very convenient for users to
> define the desired fan speed depending on a temperature measurement.
> And it seems that we can't take use of this if we map ACPI thermal and
> fan to hwmon-like sysfs interface, right?

Well, it is certainly not easy.  I am not really sure the answer is "we
cannot", though, but I don't really have the inclination to break out the
paper and pencil and start thinking *hard* on it right now, sorry :(

> Oh, a _read-only_ interface? Then, it will be much easier.
> But what is it used for?

Monitoring.  It is actually used more than the read-write interface...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Henrique de Moraes Holschuh]

On Thu, 08 Mar 2007, Zhang Rui wrote:
> First, ACPI thermal zone can be used to set different cooling policies,
> i.e. passive cooling mode and active cooling mode.
> In passive mode, just as Matthew Garrett described, ACPI thermal may
> throttle the CPU if the passive trip point is triggered, i.e. cool a
> thermal zone by decreasing the performance of the devices(always CPU
> now) in the zone.
> The active cooling mode will use one or more active devices(usually fan)
> to decrease the temperature, which consume extra power. And this is
> really like the way that the hwmon is doing.
> So we can only map the active cooling policy to hwmon, right?

Right, which is not to say we can't extend hwmon to also cover passive.

> Second, one ACPI thermal zone may have more than one fan devices, even
> one active trip point may associate with several fan devices. And this
> seems to be different from the sensors, doesn't it?

No, a LM85 does that too.  I don't recall if the current interface allows
for that mapping easily, but if it doesn't, it needs to be modified.

> Third, ACPI can not get/set the fan speed. It can only deal with the fan
> D-state. Fan is on in D0 state and off in D3 state.

That is easy to map to hwmon, you just don't implement some of the pwm
stuff.

> IMO, the hwmon sysfs interface make it very convenient for users to
> define the desired fan speed depending on a temperature measurement.
> And it seems that we can't take use of this if we map ACPI thermal and
> fan to hwmon-like sysfs interface, right?

Well, it is certainly not easy.  I am not really sure the answer is "we
cannot", though, but I don't really have the inclination to break out the
paper and pencil and start thinking *hard* on it right now, sorry :(

> Oh, a _read-only_ interface? Then, it will be much easier.
> But what is it used for?

Monitoring.  It is actually used more than the read-write interface...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Conversion of ACPI fan+thermal to hwmon sysfs

[Jean Delvare]

On Thu, 8 Mar 2007 10:13:23 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 08 Mar 2007, Zhang Rui wrote:
> > First, ACPI thermal zone can be used to set different cooling policies,
> > i.e. passive cooling mode and active cooling mode.
> > In passive mode, just as Matthew Garrett described, ACPI thermal may
> > throttle the CPU if the passive trip point is triggered, i.e. cool a
> > thermal zone by decreasing the performance of the devices(always CPU
> > now) in the zone.
> > The active cooling mode will use one or more active devices(usually fan)
> > to decrease the temperature, which consume extra power. And this is
> > really like the way that the hwmon is doing.
> > So we can only map the active cooling policy to hwmon, right?
> 
> Right, which is not to say we can't extend hwmon to also cover passive.

Correct. The hwmon interface had no reason to mention passive cooling
as hardware monitoring chips have no control over CPU speed. So far
this kind of passive cooling was implemented in user-space, using the
temperature as one of the decision factor for CPU frequency in cpufreqd
or similar. Of course, if the ACPI virtual hardware monitoring device
can control the speed, it might be convenient to extend the interface
to let the user do it. But I have no idea what it would look like.

> > Second, one ACPI thermal zone may have more than one fan devices, even
> > one active trip point may associate with several fan devices. And this
> > seems to be different from the sensors, doesn't it?
> 
> No, a LM85 does that too.  I don't recall if the current interface allows
> for that mapping easily, but if it doesn't, it needs to be modified.

It does, see item pwm[1-*]_auto_channels_temp in
Documentation/hwmon/sysfs-interface. Whether it qualifies as "easily"
is another problem ;)

-- 
Jean Delvare

[lm-sensors] Conversion of ACPI fan+thermal to hwmon sysfs

[Jean Delvare]

On Thu, 8 Mar 2007 10:13:23 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 08 Mar 2007, Zhang Rui wrote:
> > First, ACPI thermal zone can be used to set different cooling policies,
> > i.e. passive cooling mode and active cooling mode.
> > In passive mode, just as Matthew Garrett described, ACPI thermal may
> > throttle the CPU if the passive trip point is triggered, i.e. cool a
> > thermal zone by decreasing the performance of the devices(always CPU
> > now) in the zone.
> > The active cooling mode will use one or more active devices(usually fan)
> > to decrease the temperature, which consume extra power. And this is
> > really like the way that the hwmon is doing.
> > So we can only map the active cooling policy to hwmon, right?
> 
> Right, which is not to say we can't extend hwmon to also cover passive.

Correct. The hwmon interface had no reason to mention passive cooling
as hardware monitoring chips have no control over CPU speed. So far
this kind of passive cooling was implemented in user-space, using the
temperature as one of the decision factor for CPU frequency in cpufreqd
or similar. Of course, if the ACPI virtual hardware monitoring device
can control the speed, it might be convenient to extend the interface
to let the user do it. But I have no idea what it would look like.

> > Second, one ACPI thermal zone may have more than one fan devices, even
> > one active trip point may associate with several fan devices. And this
> > seems to be different from the sensors, doesn't it?
> 
> No, a LM85 does that too.  I don't recall if the current interface allows
> for that mapping easily, but if it doesn't, it needs to be modified.

It does, see item pwm[1-*]_auto_channels_temp in
Documentation/hwmon/sysfs-interface. Whether it qualifies as "easily"
is another problem ;)

-- 
Jean Delvare