Hi,
> -----Original Message-----
> From: Guenter Roeck [mailto:guenter.roeck@xxxxxxxxxxxx]
> Sent: Monday, November 28, 2011 6:14 PM
> Subject: Re: [f75387] modifying f75375s module
> If you have a patch adding support for the F75387, can you
> submit it to
> the list ? After all, you are asking for support, so it would only be
> fair to give something back.
This is my current patch for adding f75387 support. However, meanwhile I know because of the 11-bit temp handling the original chip model is not supported any more yet:
--- linux-2.6.39.4-orig/drivers/hwmon/f75375s.c 2011-11-23 09:48:00.000000000 +0100
+++ linux-2.6.39.4/drivers/hwmon/f75375s.c 2011-11-25 16:16:51.000000000 +0100
@@ -40,7 +40,7 @@
/* Addresses to scan */
static const unsigned short normal_i2c[] = { 0x2d, 0x2e, I2C_CLIENT_END };
-enum chips { f75373, f75375 };
+enum chips { f75373, f75375, f75387 };
/* Fintek F75375 registers */
#define F75375_REG_CONFIG0 0x0
@@ -58,7 +58,8 @@
#define F75375_REG_VOLT_HIGH(nr) (0x20 + (nr) * 2)
#define F75375_REG_VOLT_LOW(nr) (0x21 + (nr) * 2)
-#define F75375_REG_TEMP(nr) (0x14 + (nr))
+#define F75375_REG_TEMP_READ_MSB(nr) (0x14 + (nr))
+#define F75375_REG_TEMP_READ_LSB(nr) (0x14 + (nr) + 6)
#define F75375_REG_TEMP_HIGH(nr) (0x28 + (nr) * 2)
#define F75375_REG_TEMP_HYST(nr) (0x29 + (nr) * 2)
@@ -111,6 +112,10 @@
s8 temp[2];
s8 temp_high[2];
s8 temp_max_hyst[2];
+ /* f75387: For remote temperature reading, it uses signed 11-bit
+ * values with LSB = 0.125 degree Celsius, left-justified in 16-bit registers.
+ */
+ s16 temp11[2];
};
static int f75375_detect(struct i2c_client *client,
@@ -122,6 +127,7 @@
static const struct i2c_device_id f75375_id[] = {
{ "f75373", f75373 },
{ "f75375", f75375 },
+ { "f75387", f75387 },
{ }
};
MODULE_DEVICE_TABLE(i2c, f75375_id);
@@ -205,8 +211,12 @@
if (time_after(jiffies, data->last_updated + 2 * HZ)
|| !data->valid) {
for (nr = 0; nr < 2; nr++) {
- data->temp[nr] =
- f75375_read8(client, F75375_REG_TEMP(nr));
+ /* First assign the most significant byte, therefore shift it by 8 bits */
+ data->temp11[nr] =
+ f75375_read8(client, F75375_REG_TEMP_READ_MSB(nr)) << 8;
+ /* ..then assign the least significant byte without changing MSB */
+ data->temp11[nr] =
+ data->temp11[nr] | f75375_read8(client, F75375_REG_TEMP_READ_LSB(nr));
data->fan[nr] =
f75375_read16(client, F75375_REG_FAN(nr));
}
@@ -491,6 +501,17 @@
return count;
}
+#define TEMP11_FROM_REG(reg) ((reg) / 32 * 125)
+
+static ssize_t show_temp11(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ int nr = to_sensor_dev_attr(attr)->index;
+ struct f75375_data *data = "">
+ return sprintf(buf, "%d\n", TEMP11_FROM_REG(data->temp11[nr]));
+}
+
+
#define show_fan(thing) \
static ssize_t show_##thing(struct device *dev, struct device_attribute *attr, \
char *buf)\
@@ -525,12 +546,14 @@
show_in_max, set_in_max, 3);
static SENSOR_DEVICE_ATTR(in3_min, S_IRUGO|S_IWUSR,
show_in_min, set_in_min, 3);
-static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL, 0);
+/* static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL, 0); */
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp11, NULL, 0);
static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IRUGO|S_IWUSR,
show_temp_max_hyst, set_temp_max_hyst, 0);
static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO|S_IWUSR,
show_temp_max, set_temp_max, 0);
-static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp, NULL, 1);
+/* static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp, NULL, 1); */
+static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp11, NULL, 1);
static SENSOR_DEVICE_ATTR(temp2_max_hyst, S_IRUGO|S_IWUSR,
show_temp_max_hyst, set_temp_max_hyst, 1);
static SENSOR_DEVICE_ATTR(temp2_max, S_IRUGO|S_IWUSR,
@@ -689,6 +712,8 @@
name = "f75375";
else if (chipid == 0x0204 && vendid == 0x1934)
name = "f75373";
+ else if (chipid == 0x0410 && vendid == 0x1934)
+ name = "f75387";
else
return -ENODEV;
@@ -711,7 +736,7 @@
MODULE_AUTHOR("Riku Voipio");
MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("F75373/F75375 hardware monitoring driver");
+MODULE_DESCRIPTION("F75373/F75375/F75387 hardware monitoring driver");
module_init(sensors_f75375_init);
module_exit(sensors_f75375_exit);
> The relevant entries of your configuration file as well as
> the output of
> "sensors" might help.
This is the relevant part of my sensors3.conf file:
# /etc/sensors3.conf
#
chip "F75387-*"
ignore temp1
label temp2 "CPU_Temp"
set temp2_min 0
set temp2_max 80
ignore fan1
ignore fan2
..and this is the corresponding output of the sensors command:
[root@wnlpos ~]# LANG=C sensors
f75387-i2c-0-2e
Adapter: SMBus SCH adapter at 0400
in0: +1.65 V (min = +0.00 V, max = +2.04 V)
in1: +1.09 V (min = +0.00 V, max = +2.04 V)
in2: +1.06 V (min = +0.00 V, max = +2.04 V)
in3: +1.02 V (min = +0.00 V, max = +2.04 V)
fan1: 366 RPM (min = 97 RPM)
fan2: 366 RPM (min = 5882 RPM)
temp1: -0.2 C (high = +100.0 C, hyst = +95.0 C)
temp2: +41.5 C (high = +100.0 C, hyst = +95.0 C)
> Not sure I understand. Are you saying that "sensors -s" does
> not work ?
I'm wondering why the labels of the normal sensors command are not getting interpreted and why the thresholds (in this case temp2_max) do not have any effect. The "ignore" statements also do not have any effect. After each modification of sensors3.conf I reloaded the module for the changes to take effect.
When strace'ing the sensors command, some output line looks like this:
open("/sys/class/hwmon/hwmon0/device/temp2_label", O_RDONLY) = -1 ENOENT (No such file or directory)
For support the "label" statements with the above sensors command, would it be required to create such a label file for each sensor?
> You might want to remove such disclaimers from e-mails sent to public
> lists, at least if you don't want your e-mail to be ignored
> (or deleted
> as requested).
Sorry for that. I changed my email handling now for avoiding my company's disclaimer.
Björn
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
