From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: "Zhang, Rui" <rui.zhang@intel.com>
Cc: Jean Delvare <khali@linux-fr.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Thomas Renninger <trenn@suse.de>,
"Thomas, Sujith" <sujith.thomas@intel.com>,
"Mark M. Hoffman" <mhoffman@lightlink.com>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
linux-acpi@vger.kernel.org, lm-sensors@lm-sensors.org,
Len Brown <lenb@kernel.org>, Richard Hughes <hughsient@gmail.com>
Subject: Re: The new thermal management sysfs class, and hwmon
Date: Mon, 25 Feb 2008 09:53:36 +0100 [thread overview]
Message-ID: <47C28210.3050506@hhs.nl> (raw)
In-Reply-To: <1203893565.10256.21.camel@localhost.localdomain>
Zhang, Rui wrote:
> On Sat, 2008-02-23 at 16:29 +0800, Jean Delvare wrote:
>> On Fri, 22 Feb 2008 11:54:06 +0100, Hans de Goede wrote:
>>> Zhang, Rui wrote:
>>>> Hi, Hans,
>>>>
>>>> On Fri, 2008-02-22 at 16:00 +0800, Hans de Goede wrote:
>>>>
>>>>> I think all that is really needed and asked for is for the new
>> thermal
>>>>> ACPI
>>>>> code to:
>>>>> 1) provide temp readings in the same format as hwmon (so milli
>> degrees
>>>>> celcius,
>>>>> not degrees celcius
>>>> Agree.
>>>>> 2) provide a hwmon interface so that tools like (but not limited
>> too):
>>>>> * net-snmp
>>>>> * mrtg
>>>>> * sensors
>>>>> * sensors-applet (gnome)
>>>>> * xfce-sensors-applet
>>>>> * ksysguard
>>>>> * ksensors
>>>>> * gkrellm
>>>>>
>>>>> Can provide temp and fan readings without having to be modified.
>>>> hmm, for fan device, maybe something like this?
>>>> pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
>>>> 2+: automatic fan control (by acpi thermal driver)
>>>> pwm[1-*] = 0 : fan is off.
>>>> pwm[1-*] = 255: fan is on.
>>>> pwm[1-*] has only two valid values as ACPI fan only support
>>>> two states, ON/OFF. and it doesn't need fan[1-*]_input because the
>> fan
>>>> speed is not available.
>>>> 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? :)
>>>>
>>> I wouldn't expose a pwm interface, doing so isn't that important as
>> none of the
>>> above listed apps actually use it, the pwm interface really only is
>> for people
>>
>> Note: libsensors itself doesn't care about the pwm files.
>>
>>> who want to manually tweak their fan speed and / or use some scripts
>> to control
>>> the fan speed based on temp when the hardware doesn't support it, as
>> such it
>>> doesn't get widely used, also since there isn't a really good
>> mapping between
>>> acpi thermalzone stuff and the hwmon pwm interface I wouldn't add a
>> pwm
>>> interface to a hwmon interface the the thermal zone code.
>>>
>>> And if fan speeds aren't available (aren't they?) then I would only
>> add a hwmon
>>> class reference to a sysfs dir containing tempX_input's and a name
>> atrribute
>>> and leave it at that.
>>>
>>> But thats just my 2 euro-cents
>> FWIW, I agree with pretty much everything Hans said.
>>
>> Additionally, we could map the critical trip point to tempX_crit
>> (read-only).
>>
>> Note that since lm-sensors 3.0.1, libsensors accepts hardware
>> monitoring attributes in the hwmon "class" device directory, and I
>> recommend doing this so as to have a separate namespace. This will
>> ensure that we don't get name collisions, and it makes things cleaner
>> anyway.
> then we'll have have duplicate attributes for temperature and critical
> trip point, like:
> /sys/class/hwmon/
> |hwmon0
> |---name
> |---temp1_input
> |---temp1_crit
> |device --->/sys/class/thermal/thermal_zone1
> |---type
> |---temp(in millidegree Celsius)
> |---trip_point_0_type: critical
> |---trip_point_0_temp(in millidegree Celsius)
> ...
> It's okay if we always keep these them in sync, right?
>
Yes thats the whole idea, then lm_sensors using applications can get the info
you add to the hwmon dir without having to learn yet another API (esp since
allmost all these applications are always only reading things like temperature
and maybe limits, and are not interested in the more advanced stuff.
Regards,
Hans
next prev parent reply other threads:[~2008-02-25 9:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 2:26 The new thermal management sysfs class, and hwmon Henrique de Moraes Holschuh
2008-02-03 9:31 ` Zhang Rui
2008-02-03 16:44 ` Mark M. Hoffman
2008-02-03 17:50 ` Henrique de Moraes Holschuh
2008-02-05 10:14 ` Thomas, Sujith
2008-02-05 13:57 ` Mark M. Hoffman
2008-02-05 14:55 ` [lm-sensors] " Henrique de Moraes Holschuh
2008-02-07 7:01 ` Len Brown
2008-02-07 12:30 ` Henrique de Moraes Holschuh
2008-02-06 5:23 ` Thomas, Sujith
2008-02-13 15:10 ` Thomas Renninger
2008-02-14 14:08 ` Matthew Garrett
2008-02-15 11:04 ` Thomas, Sujith
2008-02-15 11:56 ` Matthew Garrett
2008-02-15 12:19 ` [lm-sensors] " Henrique de Moraes Holschuh
2008-02-22 5:47 ` zhangrui
2008-02-22 8:00 ` [lm-sensors] " Hans de Goede
2008-02-22 8:33 ` Zhang, Rui
2008-02-22 10:54 ` Hans de Goede
2008-02-23 7:43 ` Len Brown
2008-02-23 8:29 ` Jean Delvare
2008-02-24 22:52 ` Zhang, Rui
2008-02-25 8:53 ` Hans de Goede [this message]
2008-02-23 20:39 ` [lm-sensors] " Henrique de Moraes Holschuh
2008-02-07 6:41 ` Len Brown
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=47C28210.3050506@hhs.nl \
--to=j.w.r.degoede@hhs.nl \
--cc=hmh@hmh.eng.br \
--cc=hughsient@gmail.com \
--cc=khali@linux-fr.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=mhoffman@lightlink.com \
--cc=mjg59@srcf.ucam.org \
--cc=rui.zhang@intel.com \
--cc=sujith.thomas@intel.com \
--cc=trenn@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox