From: davidsen@tmr.com (Bill Davidsen)
To: LM Sensors <sensors@stimpy.netroedge.com>,
LKML <linux-kernel@vger.kernel.org>
Cc: Greg KH <greg@kroah.com>
Subject: [PATCH] I2C update for 2.6.9
Date: Thu, 19 May 2005 06:25:20 +0000 [thread overview]
Message-ID: <417EBBB8.3020807@tmr.com> (raw)
In-Reply-To: <20041025225459.5ffc37ba.khali@linux-fr.org>
Jean Delvare wrote:
> Hi Bill,
>
>
>>Greg KH wrote:
>
>
> I actually wrote this.
>
>
>>>Trip points
>>>=====>>>
>>>Trip points are now numbered (point1, point2, etc...) instead of
>>>named(_off, _min, _max, _full...). This solves the problem of
>>>various chips having a different number of trip points. The
>>>interface is still chip independent in that it doesn't require
>>>chip-specific knowledge to be used by user-space apps.
>>
>>It would seem that all chips would have off, max, full, etc, but
>>mapping nondescript names into functionality may require some chip
>>info anyway. As you note, with some chips these are not nice linear
>>points on a line,
>> so it would seem to tell if the top points were "max norm" and "max
>>safe" vs. "critical" and "shutdown NOW" is still going to need some
>>information on the chip, both points and operating range.
>
>
> The interface is actually (almost) self-sufficient. A point is the union
> of a temperature and a fan speed. Most often, point1 will have a speed
> of 0, which means it really is _off. point1 will be fan_min. point(P-1)
> will be _max, point(P) will have a speed of 100% and will be _full. The
> advantage of the numbered approach is that you can have has many points
> as the chip provides. It will also help user-space applications, since
> all points can be handled the exact same way, without having to
> interpret the names, know that some names have predefined fan speeds,
> etc.
>
> The only thing the interface doesn't tell is the shape of the curve
> resulting from the various trip points. This is admittedly chip
> dependent. I think it would be next to impossible to export this through
> sysfs, and I'm not sure it would be worth the pain anyway. The exact
> shape of the curve isn't that important IMHO.
>
> Your objection about "critical", "shutdown NOW" etc if out of the scope
> of this interface. The critical limits are defined by tempN_crit files.
> Actions taken by the chip when the limit is crossed is admittedly
> chip-dependent. Not a big deal either, since in most cases this is
> either not configurable or motherboard-dependent and set by the BIOS for
> us anyway.
>
> I hope I answered your question-which-was-not-really-one. :)
>
You have definitely given me a lot more information, and I do understand
why you do it this way. The shape of the curve may be of interest I
would think, if point3 to point4 is 30C to 40C I'm in a normal chip
range. If they represent 40c to 85C I really worry about flames coming
out next. That clearly can be known in the application as well, but it
isn't as easy to to as having names like max_norm, etc.
Anyway, thinks for the expanded info, more than I expected from a
non-question.
BTW: I see that the new G5 dual-CPU Mac does run the CPUs at 85C, liquid
cooled. At least ComputerWorld says they do. Yikes!
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
WARNING: multiple messages have this Message-ID (diff)
From: Bill Davidsen <davidsen@tmr.com>
To: LM Sensors <sensors@stimpy.netroedge.com>,
LKML <linux-kernel@vger.kernel.org>
Cc: Greg KH <greg@kroah.com>
Subject: Re: [PATCH] I2C update for 2.6.9
Date: Tue, 26 Oct 2004 17:03:52 -0400 [thread overview]
Message-ID: <417EBBB8.3020807@tmr.com> (raw)
In-Reply-To: <20041025225459.5ffc37ba.khali@linux-fr.org>
Jean Delvare wrote:
> Hi Bill,
>
>
>>Greg KH wrote:
>
>
> I actually wrote this.
>
>
>>>Trip points
>>>===========
>>>
>>>Trip points are now numbered (point1, point2, etc...) instead of
>>>named(_off, _min, _max, _full...). This solves the problem of
>>>various chips having a different number of trip points. The
>>>interface is still chip independent in that it doesn't require
>>>chip-specific knowledge to be used by user-space apps.
>>
>>It would seem that all chips would have off, max, full, etc, but
>>mapping nondescript names into functionality may require some chip
>>info anyway. As you note, with some chips these are not nice linear
>>points on a line,
>> so it would seem to tell if the top points were "max norm" and "max
>>safe" vs. "critical" and "shutdown NOW" is still going to need some
>>information on the chip, both points and operating range.
>
>
> The interface is actually (almost) self-sufficient. A point is the union
> of a temperature and a fan speed. Most often, point1 will have a speed
> of 0, which means it really is _off. point1 will be fan_min. point(P-1)
> will be _max, point(P) will have a speed of 100% and will be _full. The
> advantage of the numbered approach is that you can have has many points
> as the chip provides. It will also help user-space applications, since
> all points can be handled the exact same way, without having to
> interpret the names, know that some names have predefined fan speeds,
> etc.
>
> The only thing the interface doesn't tell is the shape of the curve
> resulting from the various trip points. This is admittedly chip
> dependent. I think it would be next to impossible to export this through
> sysfs, and I'm not sure it would be worth the pain anyway. The exact
> shape of the curve isn't that important IMHO.
>
> Your objection about "critical", "shutdown NOW" etc if out of the scope
> of this interface. The critical limits are defined by tempN_crit files.
> Actions taken by the chip when the limit is crossed is admittedly
> chip-dependent. Not a big deal either, since in most cases this is
> either not configurable or motherboard-dependent and set by the BIOS for
> us anyway.
>
> I hope I answered your question-which-was-not-really-one. :)
>
You have definitely given me a lot more information, and I do understand
why you do it this way. The shape of the curve may be of interest I
would think, if point3 to point4 is 30C to 40C I'm in a normal chip
range. If they represent 40c to 85C I really worry about flames coming
out next. That clearly can be known in the application as well, but it
isn't as easy to to as having names like max_norm, etc.
Anyway, thinks for the expanded info, more than I expected from a
non-question.
BTW: I see that the new G5 dual-CPU Mac does run the CPUs at 85C, liquid
cooled. At least ComputerWorld says they do. Yikes!
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
next prev parent reply other threads:[~2005-05-19 6:25 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 0:16 [BK PATCH] I2C update for 2.6.9 Greg KH
2005-05-19 6:25 ` Greg KH
2004-10-20 0:18 ` [PATCH] " Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2005-05-19 6:25 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2005-05-19 6:25 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 0:18 ` Greg KH
2004-10-20 5:21 ` Eugene Surovegin
2005-05-19 6:25 ` Eugene Surovegin
2004-10-20 6:26 ` [PATCH] fix recently introduced race in IBM PPC4xx I2C driver Eugene Surovegin
2005-05-19 6:25 ` Eugene Surovegin
2004-10-22 19:55 ` Greg KH
2005-05-19 6:25 ` Greg KH
2004-10-25 18:29 ` [PATCH] I2C update for 2.6.9 Bill Davidsen
2005-05-19 6:25 ` Bill Davidsen
2004-10-25 20:54 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-10-26 21:03 ` Bill Davidsen [this message]
2005-05-19 6:25 ` Bill Davidsen
2004-10-20 15:57 ` [BK PATCH] " Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-10-20 16:40 ` Lee Revell
2005-05-19 6:25 ` Lee Revell
2004-10-22 21:34 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=417EBBB8.3020807@tmr.com \
--to=davidsen@tmr.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sensors@stimpy.netroedge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.