All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: Bill Davidsen <davidsen@tmr.com>
Cc: Greg KH <greg@kroah.com>, LKML <linux-kernel@vger.kernel.org>,
	LM Sensors <sensors@stimpy.netroedge.com>
Subject: [PATCH] I2C update for 2.6.9
Date: Thu, 19 May 2005 06:25:20 +0000	[thread overview]
Message-ID: <20041025225459.5ffc37ba.khali@linux-fr.org> (raw)
In-Reply-To: <417D4621.5010604@tmr.com>

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

-- 
Jean Delvare
http://khali.linux-fr.org/

WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Greg KH <greg@kroah.com>, LKML <linux-kernel@vger.kernel.org>,
	LM Sensors <sensors@stimpy.netroedge.com>
Subject: Re: [PATCH] I2C update for 2.6.9
Date: Mon, 25 Oct 2004 22:54:59 +0200	[thread overview]
Message-ID: <20041025225459.5ffc37ba.khali@linux-fr.org> (raw)
In-Reply-To: <417D4621.5010604@tmr.com>

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

-- 
Jean Delvare
http://khali.linux-fr.org/

  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 [this message]
2005-05-19  6:25                                                   ` Jean Delvare
2004-10-26 21:03                                                   ` Bill Davidsen
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=20041025225459.5ffc37ba.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=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.