Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Fri, 22 Feb 2008, Zhang, Rui wrote:
> pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
> 		  2+: automatic fan control (by acpi thermal driver)

And pwm[1-*]_enable = 0 should try to bump the fan to the fasted speed
possible, BTW.  This is not very obvious :-)

Many hwmon devices already have a function assigned to lower values of
pwm_enable.  I suggest we define a static (high) value to the generic
software-based kernel-mode fan controllers (of which, ACPI thermal
management is the first one), so that the software-based fan-controllers can
control generic fans too.

say, reserve bits 7,6 and 5 to select the fan controller class:
 000 - 
     000 00000: disabled (fan at top speed)
     000 00001: manual pwm control
     000 001xx: device specific hw or sw strategies
     000 01xxx: reserved for future use
     000 1xxxx: reserved for future use

 001 -
     001 00000: ACPI thermal management controller
     001 00001: (foobar thermal management controller)
     ...

 01x - reserved for future use.
 1xx - reserved for future use.

Or something like that.  Note that the above is, AFAIK, fully backwards
compatible with all current hwmon devices.

> Yes, it can work for ACPI fan although I don't think the existing pwm
> hwmon I/F maps well to what we need and it seems like a "forced fit" to
> use it. Any better ideas? :)

Sure: we add a new "view" of the pwm controller.  hwmon drivers are allowed
to export either one or both.  If they export both, however, they MUST be
kept in complete sync.  Most hwmon devices will export either, but not both.
Stuff like thinkpad-acpi that is already complex enough anyway, can go
through the pain of providing both and keeping them in sync.

The new "view" could well use the ACPI thermal management idea, which is
nicely generic (if a bit less powerful) than hwmon's current view, and you
could very easily convert the current thermal management stuff to it.
Here's a proposal:

pwm[1-*]_max_level (RO):
   Maximum valid level for pwm[1-*]_level

pwm[1-*]_level (RO/RW):
   Alternate view of pwm[1-*].  0 means off. 1-pwm[1-*]_max_level means
   active.  The higher the level, the higher the speed.

However, that would only make sense for fans.  Using the pwm model to
control generic cooling properties of devices doesn't work well.

I propose we add an alternate "cooling power" set of attributes.  Fans could
use either one, or even both (as long as they are kept in sync):

cooling_mode (RO/RW):
   0 = disabled (no extra cooling effort)
   1 = manual
   2.. (same as pwm_enable)

   Note that this does NOT have the same behaviour of pwm_enable=0!

cooling[1-*]_max_level (RO):
   maximum cooling effort level available

cooling[1-*]_level (RW/RO):
   0 = no extra cooling
   1 = cooling effort level 1
   ...

   Increasing the cooling effort level, increases the cooling effect of the
   device (might mean downclocking buses at higher levels, etc).

I propose this, because it is actually a damn nice way to deal with fans in
most Linux platforms, as they are used only for cooling.  It has clearly
conceptual advantages over the pwm model we have right now.  And it could
be easily used by the ACPI thermal management stuff.

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