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:[~2004-10-26 21:03 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 0:16 [BK PATCH] " 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
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
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
2004-10-20 6:26 ` [PATCH] fix recently introduced race in IBM PPC4xx I2C driver Eugene Surovegin
2004-10-22 19:55 ` Greg KH
2004-10-25 18:29 ` [PATCH] I2C update for 2.6.9 Bill Davidsen
2004-10-25 20:54 ` Jean Delvare
2004-10-26 21:03 ` Bill Davidsen [this message]
2004-10-20 15:57 ` [BK PATCH] " Jean Delvare
2004-10-20 16:40 ` Lee Revell
2004-10-22 21:34 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome