* [PATCH 2.6] sensors chip updates
@ 2003-12-16 3:52 Mark M. Hoffman
2003-12-16 4:02 ` [PATCH 2.6] sensors chip updates (1 of 4) Mark M. Hoffman
` (5 more replies)
0 siblings, 6 replies; 8+ messages in thread
From: Mark M. Hoffman @ 2003-12-16 3:52 UTC (permalink / raw)
To: Greg KH; +Cc: LKML, Sensors
Hi Greg:
The following are four patchsets for 2.6 which were either direct
from or inspired by recent updates in the lm_sensors CVS.
These patches should be applied, in order, on top of your -test11
megapatch [1]. Please queue these up for inclusion after 2.6.0.
LKML: please CC me on comments, thanks
[1] http://www.kernel.org/pub/linux/kernel/people/gregkh/i2c/2.6/2.6.0-test11/i2c-devel-2.6.0-test11.patch
Regards,
--
Mark M. Hoffman
mhoffman@lightlink.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2.6] sensors chip updates (1 of 4)
2003-12-16 3:52 [PATCH 2.6] sensors chip updates Mark M. Hoffman
@ 2003-12-16 4:02 ` Mark M. Hoffman
2003-12-16 4:02 ` [PATCH 2.6] sensors chip updates (2 " Mark M. Hoffman
` (4 subsequent siblings)
5 siblings, 0 replies; 8+ messages in thread
From: Mark M. Hoffman @ 2003-12-16 4:02 UTC (permalink / raw)
To: Greg KH; +Cc: LKML, Sensors
This patch improves chip detection. It was forward ported from the
lm_sensors project CVS, from these revisions:
1.104 (Khali) Enhance chip detection (stricter).
1.108 (Khali) Fix W83627HF detection.
--- linux-2.6.0-test11-gkh/drivers/i2c/chips/w83781d.c 2003-12-14 13:53:50.000000000 -0500
+++ linux-2.6.0-test11-mmh/drivers/i2c/chips/w83781d.c 2003-12-14 15:50:46.000000000 -0500
@@ -24,10 +24,11 @@
Supports following chips:
Chip #vin #fanin #pwm #temp wchipid vendid i2c ISA
- as99127f 7 3 1? 3 0x30 0x12c3 yes no
- asb100 "bach" (type_name = as99127f) 0x30 0x0694 yes no
- w83781d 7 3 0 3 0x10 0x5ca3 yes yes
- w83627hf 9 3 2 3 0x20 0x5ca3 yes yes(LPC)
+ as99127f 7 3 1? 3 0x31 0x12c3 yes no
+ as99127f rev.2 (type_name = 1299127f) 0x31 0x5ca3 yes no
+ asb100 "bach" (type_name = as99127f) 0x31 0x0694 yes no
+ w83781d 7 3 0 3 0x10-1 0x5ca3 yes yes
+ w83627hf 9 3 2 3 0x21 0x5ca3 yes yes(LPC)
w83627thf 9 3 2 3 0x90 0x5ca3 no yes(LPC)
w83782d 9 3 2-4 3 0x30 0x5ca3 yes yes
w83783s 5-6 3 2 1-2 0x40 0x5ca3 yes no
@@ -1264,7 +1265,7 @@
goto ERROR2;
}
/* If Winbond SMBus, check address at 0x48.
- Asus doesn't support */
+ Asus doesn't support, except for as99127f rev.2 */
if ((!is_isa) && (((!(val1 & 0x80)) && (val2 == 0xa3)) ||
((val1 & 0x80) && (val2 == 0x5c)))) {
if (w83781d_read_value
@@ -1295,18 +1296,17 @@
goto ERROR2;
}
- /* mask off lower bit, not reliable */
- val1 =
- w83781d_read_value(new_client, W83781D_REG_WCHIPID) & 0xfe;
- if (val1 == 0x10 && vendid == winbond)
+ val1 = w83781d_read_value(new_client, W83781D_REG_WCHIPID);
+ if ((val1 == 0x10 || val1 == 0x11) && vendid == winbond)
kind = w83781d;
else if (val1 == 0x30 && vendid == winbond)
kind = w83782d;
- else if (val1 == 0x40 && vendid == winbond && !is_isa)
+ else if (val1 == 0x40 && vendid == winbond && !is_isa
+ && address == 0x2d)
kind = w83783s;
- else if ((val1 == 0x20 || val1 == 0x90) && vendid == winbond)
+ else if ((val1 == 0x21 || val1 == 0x90) && vendid == winbond)
kind = w83627hf;
- else if (val1 == 0x30 && vendid == asus && !is_isa)
+ else if (val1 == 0x31 && !is_isa && address >= 0x28)
kind = as99127f;
else if (val1 == 0x60 && vendid == winbond && is_isa)
kind = w83697hf;
--
Mark M. Hoffman
mhoffman@lightlink.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2.6] sensors chip updates (2 of 4)
2003-12-16 3:52 [PATCH 2.6] sensors chip updates Mark M. Hoffman
2003-12-16 4:02 ` [PATCH 2.6] sensors chip updates (1 of 4) Mark M. Hoffman
@ 2003-12-16 4:02 ` Mark M. Hoffman
2003-12-16 4:03 ` [PATCH 2.6] sensors chip updates (3 " Mark M. Hoffman
` (3 subsequent siblings)
5 siblings, 0 replies; 8+ messages in thread
From: Mark M. Hoffman @ 2003-12-16 4:02 UTC (permalink / raw)
To: Greg KH; +Cc: LKML, Sensors
This patch is from the lm_sensors project CVS, from this revision:
1.111 (mds) remove initialization of limits by driver
It is better to set these limits by a combination of /etc/sensors.conf
and 'sensors -s'; "mechanism not policy." And what's not to like about
a patch that removes 163 lines?
--- linux-2.6.0-test11-mmh/drivers/i2c/chips/w83781d.c.old 2003-12-14 17:22:51.307815925 -0500
+++ linux-2.6.0-test11-mmh/drivers/i2c/chips/w83781d.c 2003-12-14 17:20:35.000000000 -0500
@@ -208,72 +208,6 @@
return ((u8) i);
}
-/* Initial limits */
-#define W83781D_INIT_IN_0 (vid == 3500 ? 280 : vid / 10)
-#define W83781D_INIT_IN_1 (vid == 3500 ? 280 : vid / 10)
-#define W83781D_INIT_IN_2 330
-#define W83781D_INIT_IN_3 (((500) * 100) / 168)
-#define W83781D_INIT_IN_4 (((1200) * 10) / 38)
-#define W83781D_INIT_IN_5 (((-1200) * -604) / 2100)
-#define W83781D_INIT_IN_6 (((-500) * -604) / 909)
-#define W83781D_INIT_IN_7 (((500) * 100) / 168)
-#define W83781D_INIT_IN_8 300
-/* Initial limits for 782d/783s negative voltages */
-/* Note level shift. Change min/max below if you change these. */
-#define W83782D_INIT_IN_5 ((((-1200) + 1491) * 100)/514)
-#define W83782D_INIT_IN_6 ((( (-500) + 771) * 100)/314)
-
-#define W83781D_INIT_IN_PERCENTAGE 10
-#define W83781D_INIT_IN_MIN(val) (val - val * W83781D_INIT_IN_PERCENTAGE / 100)
-#define W83781D_INIT_IN_MAX(val) (val + val * W83781D_INIT_IN_PERCENTAGE / 100)
-
-#define W83781D_INIT_IN_MIN_0 W83781D_INIT_IN_MIN(W83781D_INIT_IN_0)
-#define W83781D_INIT_IN_MAX_0 W83781D_INIT_IN_MAX(W83781D_INIT_IN_0)
-#define W83781D_INIT_IN_MIN_1 W83781D_INIT_IN_MIN(W83781D_INIT_IN_1)
-#define W83781D_INIT_IN_MAX_1 W83781D_INIT_IN_MAX(W83781D_INIT_IN_1)
-#define W83781D_INIT_IN_MIN_2 W83781D_INIT_IN_MIN(W83781D_INIT_IN_2)
-#define W83781D_INIT_IN_MAX_2 W83781D_INIT_IN_MAX(W83781D_INIT_IN_2)
-#define W83781D_INIT_IN_MIN_3 W83781D_INIT_IN_MIN(W83781D_INIT_IN_3)
-#define W83781D_INIT_IN_MAX_3 W83781D_INIT_IN_MAX(W83781D_INIT_IN_3)
-#define W83781D_INIT_IN_MIN_4 W83781D_INIT_IN_MIN(W83781D_INIT_IN_4)
-#define W83781D_INIT_IN_MAX_4 W83781D_INIT_IN_MAX(W83781D_INIT_IN_4)
-#define W83781D_INIT_IN_MIN_5 W83781D_INIT_IN_MIN(W83781D_INIT_IN_5)
-#define W83781D_INIT_IN_MAX_5 W83781D_INIT_IN_MAX(W83781D_INIT_IN_5)
-#define W83781D_INIT_IN_MIN_6 W83781D_INIT_IN_MIN(W83781D_INIT_IN_6)
-#define W83781D_INIT_IN_MAX_6 W83781D_INIT_IN_MAX(W83781D_INIT_IN_6)
-#define W83781D_INIT_IN_MIN_7 W83781D_INIT_IN_MIN(W83781D_INIT_IN_7)
-#define W83781D_INIT_IN_MAX_7 W83781D_INIT_IN_MAX(W83781D_INIT_IN_7)
-#define W83781D_INIT_IN_MIN_8 W83781D_INIT_IN_MIN(W83781D_INIT_IN_8)
-#define W83781D_INIT_IN_MAX_8 W83781D_INIT_IN_MAX(W83781D_INIT_IN_8)
-
-/* Initial limits for 782d/783s negative voltages */
-/* These aren't direct multiples because of level shift */
-/* Beware going negative - check */
-#define W83782D_INIT_IN_MIN_5_TMP \
- (((-1200 * (100 + W83781D_INIT_IN_PERCENTAGE)) + (1491 * 100))/514)
-#define W83782D_INIT_IN_MIN_5 \
- ((W83782D_INIT_IN_MIN_5_TMP > 0) ? W83782D_INIT_IN_MIN_5_TMP : 0)
-#define W83782D_INIT_IN_MAX_5 \
- (((-1200 * (100 - W83781D_INIT_IN_PERCENTAGE)) + (1491 * 100))/514)
-#define W83782D_INIT_IN_MIN_6_TMP \
- ((( -500 * (100 + W83781D_INIT_IN_PERCENTAGE)) + (771 * 100))/314)
-#define W83782D_INIT_IN_MIN_6 \
- ((W83782D_INIT_IN_MIN_6_TMP > 0) ? W83782D_INIT_IN_MIN_6_TMP : 0)
-#define W83782D_INIT_IN_MAX_6 \
- ((( -500 * (100 - W83781D_INIT_IN_PERCENTAGE)) + (771 * 100))/314)
-
-#define W83781D_INIT_FAN_MIN_1 3000
-#define W83781D_INIT_FAN_MIN_2 3000
-#define W83781D_INIT_FAN_MIN_3 3000
-
-/* temp = value / 100 */
-#define W83781D_INIT_TEMP_OVER 6000
-#define W83781D_INIT_TEMP_HYST 12700 /* must be 127 for ALARM to work */
-#define W83781D_INIT_TEMP2_OVER 6000
-#define W83781D_INIT_TEMP2_HYST 5000
-#define W83781D_INIT_TEMP3_OVER 6000
-#define W83781D_INIT_TEMP3_HYST 5000
-
/* There are some complications in a module like this. First off, W83781D chips
may be both present on the SMBus and the ISA bus, and we have to handle
those cases separately at some places. Second, there might be several
@@ -1688,113 +1622,6 @@
#endif /* W83781D_RT */
if (init) {
- w83781d_write_value(client, W83781D_REG_IN_MIN(0),
- IN_TO_REG(W83781D_INIT_IN_MIN_0));
- w83781d_write_value(client, W83781D_REG_IN_MAX(0),
- IN_TO_REG(W83781D_INIT_IN_MAX_0));
- if (type != w83783s && type != w83697hf) {
- w83781d_write_value(client, W83781D_REG_IN_MIN(1),
- IN_TO_REG(W83781D_INIT_IN_MIN_1));
- w83781d_write_value(client, W83781D_REG_IN_MAX(1),
- IN_TO_REG(W83781D_INIT_IN_MAX_1));
- }
-
- w83781d_write_value(client, W83781D_REG_IN_MIN(2),
- IN_TO_REG(W83781D_INIT_IN_MIN_2));
- w83781d_write_value(client, W83781D_REG_IN_MAX(2),
- IN_TO_REG(W83781D_INIT_IN_MAX_2));
- w83781d_write_value(client, W83781D_REG_IN_MIN(3),
- IN_TO_REG(W83781D_INIT_IN_MIN_3));
- w83781d_write_value(client, W83781D_REG_IN_MAX(3),
- IN_TO_REG(W83781D_INIT_IN_MAX_3));
- w83781d_write_value(client, W83781D_REG_IN_MIN(4),
- IN_TO_REG(W83781D_INIT_IN_MIN_4));
- w83781d_write_value(client, W83781D_REG_IN_MAX(4),
- IN_TO_REG(W83781D_INIT_IN_MAX_4));
- if (type == w83781d || type == as99127f) {
- w83781d_write_value(client, W83781D_REG_IN_MIN(5),
- IN_TO_REG(W83781D_INIT_IN_MIN_5));
- w83781d_write_value(client, W83781D_REG_IN_MAX(5),
- IN_TO_REG(W83781D_INIT_IN_MAX_5));
- } else {
- w83781d_write_value(client, W83781D_REG_IN_MIN(5),
- IN_TO_REG(W83782D_INIT_IN_MIN_5));
- w83781d_write_value(client, W83781D_REG_IN_MAX(5),
- IN_TO_REG(W83782D_INIT_IN_MAX_5));
- }
- if (type == w83781d || type == as99127f) {
- w83781d_write_value(client, W83781D_REG_IN_MIN(6),
- IN_TO_REG(W83781D_INIT_IN_MIN_6));
- w83781d_write_value(client, W83781D_REG_IN_MAX(6),
- IN_TO_REG(W83781D_INIT_IN_MAX_6));
- } else {
- w83781d_write_value(client, W83781D_REG_IN_MIN(6),
- IN_TO_REG(W83782D_INIT_IN_MIN_6));
- w83781d_write_value(client, W83781D_REG_IN_MAX(6),
- IN_TO_REG(W83782D_INIT_IN_MAX_6));
- }
- if ((type == w83782d) || (type == w83627hf) ||
- (type == w83697hf)) {
- w83781d_write_value(client, W83781D_REG_IN_MIN(7),
- IN_TO_REG(W83781D_INIT_IN_MIN_7));
- w83781d_write_value(client, W83781D_REG_IN_MAX(7),
- IN_TO_REG(W83781D_INIT_IN_MAX_7));
- w83781d_write_value(client, W83781D_REG_IN_MIN(8),
- IN_TO_REG(W83781D_INIT_IN_MIN_8));
- w83781d_write_value(client, W83781D_REG_IN_MAX(8),
- IN_TO_REG(W83781D_INIT_IN_MAX_8));
- w83781d_write_value(client, W83781D_REG_VBAT,
- (w83781d_read_value
- (client,
- W83781D_REG_VBAT) | 0x01));
- }
- w83781d_write_value(client, W83781D_REG_FAN_MIN(1),
- FAN_TO_REG(W83781D_INIT_FAN_MIN_1, 2));
- w83781d_write_value(client, W83781D_REG_FAN_MIN(2),
- FAN_TO_REG(W83781D_INIT_FAN_MIN_2, 2));
- if (type != w83697hf) {
- w83781d_write_value(client, W83781D_REG_FAN_MIN(3),
- FAN_TO_REG(W83781D_INIT_FAN_MIN_3,
- 2));
- }
-
- w83781d_write_value(client, W83781D_REG_TEMP_OVER(1),
- TEMP_TO_REG(W83781D_INIT_TEMP_OVER));
- w83781d_write_value(client, W83781D_REG_TEMP_HYST(1),
- TEMP_TO_REG(W83781D_INIT_TEMP_HYST));
-
- if (type == as99127f) {
- w83781d_write_value(client, W83781D_REG_TEMP_OVER(2),
- AS99127_TEMP_ADD_TO_REG
- (W83781D_INIT_TEMP2_OVER));
- w83781d_write_value(client, W83781D_REG_TEMP_HYST(2),
- AS99127_TEMP_ADD_TO_REG
- (W83781D_INIT_TEMP2_HYST));
- } else {
- w83781d_write_value(client, W83781D_REG_TEMP_OVER(2),
- TEMP_ADD_TO_REG
- (W83781D_INIT_TEMP2_OVER));
- w83781d_write_value(client, W83781D_REG_TEMP_HYST(2),
- TEMP_ADD_TO_REG
- (W83781D_INIT_TEMP2_HYST));
- }
- w83781d_write_value(client, W83781D_REG_TEMP2_CONFIG, 0x00);
-
- if (type == as99127f) {
- w83781d_write_value(client, W83781D_REG_TEMP_OVER(3),
- AS99127_TEMP_ADD_TO_REG
- (W83781D_INIT_TEMP3_OVER));
- w83781d_write_value(client, W83781D_REG_TEMP_HYST(3),
- AS99127_TEMP_ADD_TO_REG
- (W83781D_INIT_TEMP3_HYST));
- } else if (type != w83783s && type != w83697hf) {
- w83781d_write_value(client, W83781D_REG_TEMP_OVER(3),
- TEMP_ADD_TO_REG
- (W83781D_INIT_TEMP3_OVER));
- w83781d_write_value(client, W83781D_REG_TEMP_HYST(3),
- TEMP_ADD_TO_REG
- (W83781D_INIT_TEMP3_HYST));
- }
if (type != w83783s && type != w83697hf) {
w83781d_write_value(client, W83781D_REG_TEMP3_CONFIG,
0x00);
--
Mark M. Hoffman
mhoffman@lightlink.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2.6] sensors chip updates (3 of 4)
2003-12-16 3:52 [PATCH 2.6] sensors chip updates Mark M. Hoffman
2003-12-16 4:02 ` [PATCH 2.6] sensors chip updates (1 of 4) Mark M. Hoffman
2003-12-16 4:02 ` [PATCH 2.6] sensors chip updates (2 " Mark M. Hoffman
@ 2003-12-16 4:03 ` Mark M. Hoffman
2003-12-16 4:04 ` [PATCH 2.6] sensors chip updates (4 " Mark M. Hoffman
` (2 subsequent siblings)
5 siblings, 0 replies; 8+ messages in thread
From: Mark M. Hoffman @ 2003-12-16 4:03 UTC (permalink / raw)
To: Greg KH; +Cc: LKML, Sensors
This patch is from the lm_sensors project CVS, from this revision:
1.44 (mds) remove initialization of limits by driver
It is better to set these limits by a combination of /etc/sensors.conf
and 'sensors -s'; "mechanism not policy."
--- linux-2.6.0-test11-gkh/drivers/i2c/chips/lm75.c 2003-12-14 13:53:50.000000000 -0500
+++ linux-2.6.0-test11-mmh/drivers/i2c/chips/lm75.c 2003-12-14 17:52:49.000000000 -0500
@@ -51,10 +51,6 @@
#define TEMP_FROM_REG(val) ((((val & 0x7fff) >> 7) * 5) | ((val & 0x8000)?-256:0))
#define TEMP_TO_REG(val) (SENSORS_LIMIT((val<0?(0x200+((val)/5))<<7:(((val) + 2) / 5) << 7),0,0xffff))
-/* Initial values */
-#define LM75_INIT_TEMP_OS 600
-#define LM75_INIT_TEMP_HYST 500
-
/* Each client has this additional data */
struct lm75_data {
struct semaphore update_lock;
@@ -258,10 +254,6 @@
static void lm75_init_client(struct i2c_client *client)
{
/* Initialize the LM75 chip */
- lm75_write_value(client, LM75_REG_TEMP_OS,
- TEMP_TO_REG(LM75_INIT_TEMP_OS));
- lm75_write_value(client, LM75_REG_TEMP_HYST,
- TEMP_TO_REG(LM75_INIT_TEMP_HYST));
lm75_write_value(client, LM75_REG_CONF, 0);
}
--
Mark M. Hoffman
mhoffman@lightlink.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2.6] sensors chip updates (4 of 4)
2003-12-16 3:52 [PATCH 2.6] sensors chip updates Mark M. Hoffman
` (2 preceding siblings ...)
2003-12-16 4:03 ` [PATCH 2.6] sensors chip updates (3 " Mark M. Hoffman
@ 2003-12-16 4:04 ` Mark M. Hoffman
2003-12-16 21:56 ` [PATCH 2.6] sensors chip updates Jean Delvare
2003-12-18 0:04 ` [PATCH 2.6] sensors chip updates Greg KH
5 siblings, 0 replies; 8+ messages in thread
From: Mark M. Hoffman @ 2003-12-16 4:04 UTC (permalink / raw)
To: Greg KH; +Cc: LKML, Sensors
This patch is based on the lm_sensors project CVS, from revisions 1.45 and 1.1
of lm75.c and lm75.h, respectively.
The patch fixes the conversion routines (according to datasheet) and moves
them into a header file - as these conversions can be used by several drivers
which emulate LM75s as subclients. Also, temps are now reported in 1/1000 C
in sysfs as per documentation.
--- linux-2.6.0-test11-mmh/drivers/i2c/chips/lm75.c.old 2003-12-14 18:02:18.000000000 -0500
+++ linux-2.6.0-test11-mmh/drivers/i2c/chips/lm75.c 2003-12-14 19:28:08.000000000 -0500
@@ -25,6 +25,7 @@
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/i2c-sensor.h>
+#include "lm75.h"
/* Addresses to scan */
@@ -44,13 +45,6 @@
#define LM75_REG_TEMP_HYST 0x02
#define LM75_REG_TEMP_OS 0x03
-/* Conversions. Rounding and limit checking is only done on the TO_REG
- variants. Note that you should be a bit careful with which arguments
- these macros are called: arguments may be evaluated more than once.
- Fixing this is just not worth it. */
-#define TEMP_FROM_REG(val) ((((val & 0x7fff) >> 7) * 5) | ((val & 0x8000)?-256:0))
-#define TEMP_TO_REG(val) (SENSORS_LIMIT((val<0?(0x200+((val)/5))<<7:(((val) + 2) / 5) << 7),0,0xffff))
-
/* Each client has this additional data */
struct lm75_data {
struct semaphore update_lock;
@@ -83,15 +77,12 @@
static int lm75_id = 0;
#define show(value) \
-static ssize_t show_##value(struct device *dev, char *buf) \
-{ \
- struct i2c_client *client = to_i2c_client(dev); \
- struct lm75_data *data = i2c_get_clientdata(client); \
- int temp; \
- \
- lm75_update_client(client); \
- temp = TEMP_FROM_REG(data->value); \
- return sprintf(buf, "%d\n", temp * 100); \
+static ssize_t show_##value(struct device *dev, char *buf) \
+{ \
+ struct i2c_client *client = to_i2c_client(dev); \
+ struct lm75_data *data = i2c_get_clientdata(client); \
+ lm75_update_client(client); \
+ return sprintf(buf, "%d\n", LM75_TEMP_FROM_REG(data->value)); \
}
show(temp_max);
show(temp_hyst);
@@ -102,9 +93,8 @@
{ \
struct i2c_client *client = to_i2c_client(dev); \
struct lm75_data *data = i2c_get_clientdata(client); \
- int temp = simple_strtoul(buf, NULL, 10) / 100; \
- \
- data->value = TEMP_TO_REG(temp); \
+ int temp = simple_strtoul(buf, NULL, 10); \
+ data->value = LM75_TEMP_TO_REG(temp); \
lm75_write_value(client, reg, data->value); \
return count; \
}
--- linux-2.6.0-test11-mmh/drivers/i2c/chips/lm75.h.old 2003-12-14 18:05:09.000000000 -0500
+++ linux-2.6.0-test11-mmh/drivers/i2c/chips/lm75.h 2003-12-14 18:32:46.000000000 -0500
@@ -0,0 +1,49 @@
+/*
+ lm75.h - Part of lm_sensors, Linux kernel modules for hardware
+ monitoring
+ Copyright (c) 2003 Mark M. Hoffman <mhoffman@lightlink.com>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+/*
+ This file contains common code for encoding/decoding LM75 type
+ temperature readings, which are emulated by many of the chips
+ we support. As the user is unlikely to load more than one driver
+ which contains this code, we don't worry about the wasted space.
+*/
+
+#include <linux/i2c-sensor.h>
+
+/* straight from the datasheet */
+#define LM75_TEMP_MIN (-55000)
+#define LM75_TEMP_MAX 125000
+
+/* TEMP: 0.001C/bit (-55C to +125C)
+ REG: (0.5C/bit, two's complement) << 7 */
+static inline u16 LM75_TEMP_TO_REG(int temp)
+{
+ int ntemp = SENSORS_LIMIT(temp, LM75_TEMP_MIN, LM75_TEMP_MAX);
+ ntemp += (ntemp<0 ? -250 : 250);
+ return (u16)((ntemp / 500) << 7);
+}
+
+static inline int LM75_TEMP_FROM_REG(u16 reg)
+{
+ /* use integer division instead of equivalent right shift to
+ guarantee arithmetic shift and preserve the sign */
+ return ((s16)reg / 128) * 500;
+}
+
--
Mark M. Hoffman
mhoffman@lightlink.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2.6] sensors chip updates
2003-12-16 3:52 [PATCH 2.6] sensors chip updates Mark M. Hoffman
` (3 preceding siblings ...)
2003-12-16 4:04 ` [PATCH 2.6] sensors chip updates (4 " Mark M. Hoffman
@ 2003-12-16 21:56 ` Jean Delvare
2003-12-20 11:41 ` nforce2 one card per irq only Bob
2003-12-18 0:04 ` [PATCH 2.6] sensors chip updates Greg KH
5 siblings, 1 reply; 8+ messages in thread
From: Jean Delvare @ 2003-12-16 21:56 UTC (permalink / raw)
To: sensors; +Cc: Greg KH, LKML
> The following are four patchsets for 2.6 which were either direct
> from or inspired by recent updates in the lm_sensors CVS.
>
> These patches should be applied, in order, on top of your -test11
> megapatch. Please queue these up for inclusion after 2.6.0.
Checked to apply correctly, with my other patches too. Checked to
compile too. Not tested to work since I don't have a system running 2.6
these days (hopefully such a situtation won't last) but I'm confident
(the same changes were made to our CVS repository some times ago after
all).
I've added these patches to my personal i2c-related for-Linux-2.6
patches repository [1], and regenerated my own "megapatch" (which is a
superset of Greg's one, and will melt after Greg's changes are actually
merged into the 2.6 kernel). You'll notice that I've merged parts 2 and
3 into one single patch, since both do the same thing on different
drivers.
Thanks Mark for the patches, we really need to keep merging our CVS
changes to Linux 2.6 each time it applies.
[1] http://www.ensicaen.ismra.fr/~delvare/devel/i2c/linux-2.6/
mirrored at http://delvare.nerim.net/i2c/linux-2.6/.
--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2.6] sensors chip updates
2003-12-16 3:52 [PATCH 2.6] sensors chip updates Mark M. Hoffman
` (4 preceding siblings ...)
2003-12-16 21:56 ` [PATCH 2.6] sensors chip updates Jean Delvare
@ 2003-12-18 0:04 ` Greg KH
5 siblings, 0 replies; 8+ messages in thread
From: Greg KH @ 2003-12-18 0:04 UTC (permalink / raw)
To: Mark M. Hoffman; +Cc: LKML, Sensors
On Mon, Dec 15, 2003 at 10:52:19PM -0500, Mark M. Hoffman wrote:
> Hi Greg:
>
> The following are four patchsets for 2.6 which were either direct
> from or inspired by recent updates in the lm_sensors CVS.
>
> These patches should be applied, in order, on top of your -test11
> megapatch [1]. Please queue these up for inclusion after 2.6.0.
Thanks, I've applied all 4 of these to my "after 2.6.0" i2c tree.
greg k-h
^ permalink raw reply [flat|nested] 8+ messages in thread
* nforce2 one card per irq only
2003-12-16 21:56 ` [PATCH 2.6] sensors chip updates Jean Delvare
@ 2003-12-20 11:41 ` Bob
0 siblings, 0 replies; 8+ messages in thread
From: Bob @ 2003-12-20 11:41 UTC (permalink / raw)
To: kernel list
Why does dmesg and dmesg -s65536 and
CONFIG_LOG_BUF_SHIFT 14 or 16 have
my dmesg and kern.log truncate here?
I can't see Ross' delay patch printk
In case of odd devfs vc tty thing I
tried "console=vc/0 console=tty0"
dmesg begins--
been registered
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fc660
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xc690, dseg 0xf0000
pnp: match found with the PnP device '00:07' and the driver 'system'
pnp: match found with the PnP device '00:08' and the driver 'system'
PnPBIOS: 13 nodes reported by PnP BIOS; 13 recorded by driver
SCSI subsystem initialized
ACPI: PCI Interrupt Link [APCS] enabled at IRQ 23
IOAPIC[0]: Set PCI routing entry (2-23 -> 0xa9 -> IRQ 23 Mode:1 Active:0)
and if I use smp instead of uniprocessor kernel,
I get a few lines more showing so Ross' numbers
show but PIC timer is on so the numbers are
useless
________________________________________________
MSI K7N2 Delta MCP2-T amd xp3000+ 333mhz fsb 1:1
nforce2, Award bios update stopped crashing
kernel 2.6.0-test11
I need Ross' ioapic patch to get ioapic edge timer
working.
cpu disconnect defaults to on, and on or off makes
no diff except 50% more MIS count, ERR 0 either way,
no crashes.
Once I moved a tulip ethernet 10/100 nic off the
irq of a promise ide controller I got ERR 0 and
much less MIS count.
24 hours uptime
CPU0
0: 84527308 IO-APIC-edge timer
1: 37635 IO-APIC-edge i8042
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 532175 IO-APIC-edge i8042
14: 106 IO-APIC-edge ide0
15: 215 IO-APIC-edge ide1
16: 354495 IO-APIC-level ide2, ide3
17: 0 IO-APIC-level yenta, yenta
19: 151532 IO-APIC-level ide4, ide5
20: 309690 IO-APIC-level eth0
21: 1579 IO-APIC-level NVidia nForce2
NMI: 0
LOC: 84527227
ERR: 0
MIS: 188
according to athcool, cpu disconnect on
So one irq per slot is still necessary with pci on
this system, and hdparm unmask off did not help.
This is a uniprocessor but the hd controller and
tulip card on one irq would produce a lot of APIC
errors when cp over nfs while bonnie++, and here
is something from Maciej nominally for smp--
/usr/src/linux-2.6.0-test11/arch/i386/kernel/apic.c
/*
* Some unknown Intel IO/APIC (or APIC) errata is biting us with
* certain networking cards. If high frequency interrupts are
* happening on a particular IOAPIC pin, plus the IOAPIC routing
* entry is masked/unmasked at a high rate as well then sooner or
* later IOAPIC line gets 'stuck', no more interrupts are received
* from the device. If focus CPU is disabled then the hang goes
* away, oh well :-(
*
* [ This bug can be reproduced easily with a level-triggered
* PCI Ne2000 networking cards and PII/PIII processors, dual
* BX chipset. ]
*/
/*
* Actually disabling the focus CPU check just makes the hang less
* frequent as it makes the interrupt distributon model be more
* like LRU than MRU (the short-term load is more even across CPUs).
* See also the comment in end_level_ioapic_irq(). --macro
*/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-12-20 11:40 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-16 3:52 [PATCH 2.6] sensors chip updates Mark M. Hoffman
2003-12-16 4:02 ` [PATCH 2.6] sensors chip updates (1 of 4) Mark M. Hoffman
2003-12-16 4:02 ` [PATCH 2.6] sensors chip updates (2 " Mark M. Hoffman
2003-12-16 4:03 ` [PATCH 2.6] sensors chip updates (3 " Mark M. Hoffman
2003-12-16 4:04 ` [PATCH 2.6] sensors chip updates (4 " Mark M. Hoffman
2003-12-16 21:56 ` [PATCH 2.6] sensors chip updates Jean Delvare
2003-12-20 11:41 ` nforce2 one card per irq only Bob
2003-12-18 0:04 ` [PATCH 2.6] sensors chip updates Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).