1
0
Fork 0
alistair23-linux/drivers/hwmon/tmp102.c

315 lines
8.4 KiB
C
Raw Normal View History

/* Texas Instruments TMP102 SMBus temperature sensor driver
*
* Copyright (C) 2010 Steven King <sfking@fdwdc.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., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA
*/
#include <linux/module.h>
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/hwmon.h>
#include <linux/hwmon-sysfs.h>
#include <linux/err.h>
#include <linux/mutex.h>
#include <linux/device.h>
#include <linux/jiffies.h>
#include <linux/thermal.h>
#include <linux/of.h>
#define DRIVER_NAME "tmp102"
#define TMP102_TEMP_REG 0x00
#define TMP102_CONF_REG 0x01
/* note: these bit definitions are byte swapped */
#define TMP102_CONF_SD 0x0100
#define TMP102_CONF_TM 0x0200
#define TMP102_CONF_POL 0x0400
#define TMP102_CONF_F0 0x0800
#define TMP102_CONF_F1 0x1000
#define TMP102_CONF_R0 0x2000
#define TMP102_CONF_R1 0x4000
#define TMP102_CONF_OS 0x8000
#define TMP102_CONF_EM 0x0010
#define TMP102_CONF_AL 0x0020
#define TMP102_CONF_CR0 0x0040
#define TMP102_CONF_CR1 0x0080
#define TMP102_TLOW_REG 0x02
#define TMP102_THIGH_REG 0x03
struct tmp102 {
struct i2c_client *client;
struct device *hwmon_dev;
struct mutex lock;
u16 config_orig;
unsigned long last_update;
int temp[3];
hwmon: (tmp102) Force wait for conversion time for the first valid data TMP102 works based on conversions done periodically. However, as per the TMP102 data sheet[1] the first conversion is triggered immediately after we program the configuration register. The temperature data registers do not reflect proper data until the first conversion is complete (in our case HZ/4). The driver currently sets the last_update to be jiffies - HZ, just after the configuration is complete. When TMP102 driver registers with the thermal framework, it immediately tries to read the sensor temperature data. This takes place even before the conversion on the TMP102 is complete and results in an invalid temperature read. Depending on the value read, this may cause thermal framework to assume that a critical temperature event has occurred and attempts to shutdown the system. Instead of causing an invalid mid-conversion value to be read erroneously, we mark the last_update to be in-line with the current jiffies. This allows the tmp102_update_device function to skip update until the required conversion time is complete. Further, we ensure to return -EAGAIN result instead of returning spurious temperature (such as 0C) values to the caller to prevent any wrong decisions made with such values. NOTE: this allows the read functions not to be blocking and allows the callers to make the decision if they would like to block or try again later. At least the current user(thermal) seems to handle this by retrying later. A simpler alternative approach could be to sleep in the probe for the duration required, but that will result in latency that is undesirable and delay boot sequence un-necessarily. [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf Cc: Eduardo Valentin <edubezval@gmail.com> Reported-by: Aparna Balasubramanian <aparnab@ti.com> Reported-by: Elvita Lobo <elvita@ti.com> Reported-by: Yan Liu <yan-liu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-12-01 09:10:21 -07:00
bool first_time;
};
/* convert left adjusted 13-bit TMP102 register value to milliCelsius */
static inline int tmp102_reg_to_mC(s16 val)
{
return ((val & ~0x01) * 1000) / 128;
}
/* convert milliCelsius to left adjusted 13-bit TMP102 register value */
static inline u16 tmp102_mC_to_reg(int val)
{
return (val * 128) / 1000;
}
static const u8 tmp102_reg[] = {
TMP102_TEMP_REG,
TMP102_TLOW_REG,
TMP102_THIGH_REG,
};
static struct tmp102 *tmp102_update_device(struct device *dev)
{
struct tmp102 *tmp102 = dev_get_drvdata(dev);
struct i2c_client *client = tmp102->client;
mutex_lock(&tmp102->lock);
if (time_after(jiffies, tmp102->last_update + HZ / 3)) {
int i;
for (i = 0; i < ARRAY_SIZE(tmp102->temp); ++i) {
int status = i2c_smbus_read_word_swapped(client,
tmp102_reg[i]);
if (status > -1)
tmp102->temp[i] = tmp102_reg_to_mC(status);
}
tmp102->last_update = jiffies;
hwmon: (tmp102) Force wait for conversion time for the first valid data TMP102 works based on conversions done periodically. However, as per the TMP102 data sheet[1] the first conversion is triggered immediately after we program the configuration register. The temperature data registers do not reflect proper data until the first conversion is complete (in our case HZ/4). The driver currently sets the last_update to be jiffies - HZ, just after the configuration is complete. When TMP102 driver registers with the thermal framework, it immediately tries to read the sensor temperature data. This takes place even before the conversion on the TMP102 is complete and results in an invalid temperature read. Depending on the value read, this may cause thermal framework to assume that a critical temperature event has occurred and attempts to shutdown the system. Instead of causing an invalid mid-conversion value to be read erroneously, we mark the last_update to be in-line with the current jiffies. This allows the tmp102_update_device function to skip update until the required conversion time is complete. Further, we ensure to return -EAGAIN result instead of returning spurious temperature (such as 0C) values to the caller to prevent any wrong decisions made with such values. NOTE: this allows the read functions not to be blocking and allows the callers to make the decision if they would like to block or try again later. At least the current user(thermal) seems to handle this by retrying later. A simpler alternative approach could be to sleep in the probe for the duration required, but that will result in latency that is undesirable and delay boot sequence un-necessarily. [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf Cc: Eduardo Valentin <edubezval@gmail.com> Reported-by: Aparna Balasubramanian <aparnab@ti.com> Reported-by: Elvita Lobo <elvita@ti.com> Reported-by: Yan Liu <yan-liu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-12-01 09:10:21 -07:00
tmp102->first_time = false;
}
mutex_unlock(&tmp102->lock);
return tmp102;
}
thermal: consistently use int for temperatures The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Lukasz Majewski <l.majewski@samsung.com> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Peter Feuerer <peter@piie.net> Cc: Punit Agrawal <punit.agrawal@arm.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Jean Delvare <jdelvare@suse.de> Cc: Peter Feuerer <peter@piie.net> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: linux-acpi@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: Guenter Roeck <linux@roeck-us.net> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Darren Hart <dvhart@infradead.org> Cc: lm-sensors@lm-sensors.org Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2015-07-24 00:12:54 -06:00
static int tmp102_read_temp(void *dev, int *temp)
{
struct tmp102 *tmp102 = tmp102_update_device(dev);
hwmon: (tmp102) Force wait for conversion time for the first valid data TMP102 works based on conversions done periodically. However, as per the TMP102 data sheet[1] the first conversion is triggered immediately after we program the configuration register. The temperature data registers do not reflect proper data until the first conversion is complete (in our case HZ/4). The driver currently sets the last_update to be jiffies - HZ, just after the configuration is complete. When TMP102 driver registers with the thermal framework, it immediately tries to read the sensor temperature data. This takes place even before the conversion on the TMP102 is complete and results in an invalid temperature read. Depending on the value read, this may cause thermal framework to assume that a critical temperature event has occurred and attempts to shutdown the system. Instead of causing an invalid mid-conversion value to be read erroneously, we mark the last_update to be in-line with the current jiffies. This allows the tmp102_update_device function to skip update until the required conversion time is complete. Further, we ensure to return -EAGAIN result instead of returning spurious temperature (such as 0C) values to the caller to prevent any wrong decisions made with such values. NOTE: this allows the read functions not to be blocking and allows the callers to make the decision if they would like to block or try again later. At least the current user(thermal) seems to handle this by retrying later. A simpler alternative approach could be to sleep in the probe for the duration required, but that will result in latency that is undesirable and delay boot sequence un-necessarily. [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf Cc: Eduardo Valentin <edubezval@gmail.com> Reported-by: Aparna Balasubramanian <aparnab@ti.com> Reported-by: Elvita Lobo <elvita@ti.com> Reported-by: Yan Liu <yan-liu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-12-01 09:10:21 -07:00
/* Is it too early even to return a conversion? */
if (tmp102->first_time) {
dev_dbg(dev, "%s: Conversion not ready yet..\n", __func__);
return -EAGAIN;
}
*temp = tmp102->temp[0];
return 0;
}
static ssize_t tmp102_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
{
struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
struct tmp102 *tmp102 = tmp102_update_device(dev);
hwmon: (tmp102) Force wait for conversion time for the first valid data TMP102 works based on conversions done periodically. However, as per the TMP102 data sheet[1] the first conversion is triggered immediately after we program the configuration register. The temperature data registers do not reflect proper data until the first conversion is complete (in our case HZ/4). The driver currently sets the last_update to be jiffies - HZ, just after the configuration is complete. When TMP102 driver registers with the thermal framework, it immediately tries to read the sensor temperature data. This takes place even before the conversion on the TMP102 is complete and results in an invalid temperature read. Depending on the value read, this may cause thermal framework to assume that a critical temperature event has occurred and attempts to shutdown the system. Instead of causing an invalid mid-conversion value to be read erroneously, we mark the last_update to be in-line with the current jiffies. This allows the tmp102_update_device function to skip update until the required conversion time is complete. Further, we ensure to return -EAGAIN result instead of returning spurious temperature (such as 0C) values to the caller to prevent any wrong decisions made with such values. NOTE: this allows the read functions not to be blocking and allows the callers to make the decision if they would like to block or try again later. At least the current user(thermal) seems to handle this by retrying later. A simpler alternative approach could be to sleep in the probe for the duration required, but that will result in latency that is undesirable and delay boot sequence un-necessarily. [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf Cc: Eduardo Valentin <edubezval@gmail.com> Reported-by: Aparna Balasubramanian <aparnab@ti.com> Reported-by: Elvita Lobo <elvita@ti.com> Reported-by: Yan Liu <yan-liu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-12-01 09:10:21 -07:00
/* Is it too early even to return a read? */
if (tmp102->first_time)
return -EAGAIN;
return sprintf(buf, "%d\n", tmp102->temp[sda->index]);
}
static ssize_t tmp102_set_temp(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
struct tmp102 *tmp102 = dev_get_drvdata(dev);
struct i2c_client *client = tmp102->client;
long val;
int status;
if (kstrtol(buf, 10, &val) < 0)
return -EINVAL;
val = clamp_val(val, -256000, 255000);
mutex_lock(&tmp102->lock);
tmp102->temp[sda->index] = val;
status = i2c_smbus_write_word_swapped(client, tmp102_reg[sda->index],
tmp102_mC_to_reg(val));
mutex_unlock(&tmp102->lock);
return status ? : count;
}
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, tmp102_show_temp, NULL , 0);
static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IWUSR | S_IRUGO, tmp102_show_temp,
tmp102_set_temp, 1);
static SENSOR_DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO, tmp102_show_temp,
tmp102_set_temp, 2);
static struct attribute *tmp102_attrs[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp1_max_hyst.dev_attr.attr,
&sensor_dev_attr_temp1_max.dev_attr.attr,
NULL
};
ATTRIBUTE_GROUPS(tmp102);
#define TMP102_CONFIG (TMP102_CONF_TM | TMP102_CONF_EM | TMP102_CONF_CR1)
#define TMP102_CONFIG_RD_ONLY (TMP102_CONF_R0 | TMP102_CONF_R1 | TMP102_CONF_AL)
static const struct thermal_zone_of_device_ops tmp102_of_thermal_ops = {
.get_temp = tmp102_read_temp,
};
static int tmp102_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct device *dev = &client->dev;
struct device *hwmon_dev;
struct tmp102 *tmp102;
int status;
if (!i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_WORD_DATA)) {
dev_err(dev,
"adapter doesn't support SMBus word transactions\n");
return -ENODEV;
}
tmp102 = devm_kzalloc(dev, sizeof(*tmp102), GFP_KERNEL);
if (!tmp102)
return -ENOMEM;
i2c_set_clientdata(client, tmp102);
tmp102->client = client;
status = i2c_smbus_read_word_swapped(client, TMP102_CONF_REG);
if (status < 0) {
dev_err(dev, "error reading config register\n");
return status;
}
tmp102->config_orig = status;
status = i2c_smbus_write_word_swapped(client, TMP102_CONF_REG,
TMP102_CONFIG);
if (status < 0) {
dev_err(dev, "error writing config register\n");
goto fail_restore_config;
}
status = i2c_smbus_read_word_swapped(client, TMP102_CONF_REG);
if (status < 0) {
dev_err(dev, "error reading config register\n");
goto fail_restore_config;
}
status &= ~TMP102_CONFIG_RD_ONLY;
if (status != TMP102_CONFIG) {
dev_err(dev, "config settings did not stick\n");
status = -ENODEV;
goto fail_restore_config;
}
hwmon: (tmp102) Force wait for conversion time for the first valid data TMP102 works based on conversions done periodically. However, as per the TMP102 data sheet[1] the first conversion is triggered immediately after we program the configuration register. The temperature data registers do not reflect proper data until the first conversion is complete (in our case HZ/4). The driver currently sets the last_update to be jiffies - HZ, just after the configuration is complete. When TMP102 driver registers with the thermal framework, it immediately tries to read the sensor temperature data. This takes place even before the conversion on the TMP102 is complete and results in an invalid temperature read. Depending on the value read, this may cause thermal framework to assume that a critical temperature event has occurred and attempts to shutdown the system. Instead of causing an invalid mid-conversion value to be read erroneously, we mark the last_update to be in-line with the current jiffies. This allows the tmp102_update_device function to skip update until the required conversion time is complete. Further, we ensure to return -EAGAIN result instead of returning spurious temperature (such as 0C) values to the caller to prevent any wrong decisions made with such values. NOTE: this allows the read functions not to be blocking and allows the callers to make the decision if they would like to block or try again later. At least the current user(thermal) seems to handle this by retrying later. A simpler alternative approach could be to sleep in the probe for the duration required, but that will result in latency that is undesirable and delay boot sequence un-necessarily. [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf Cc: Eduardo Valentin <edubezval@gmail.com> Reported-by: Aparna Balasubramanian <aparnab@ti.com> Reported-by: Elvita Lobo <elvita@ti.com> Reported-by: Yan Liu <yan-liu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-12-01 09:10:21 -07:00
tmp102->last_update = jiffies;
/* Mark that we are not ready with data until conversion is complete */
tmp102->first_time = true;
mutex_init(&tmp102->lock);
hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
tmp102, tmp102_groups);
if (IS_ERR(hwmon_dev)) {
dev_dbg(dev, "unable to register hwmon device\n");
status = PTR_ERR(hwmon_dev);
goto fail_restore_config;
}
tmp102->hwmon_dev = hwmon_dev;
devm_thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
&tmp102_of_thermal_ops);
dev_info(dev, "initialized\n");
return 0;
fail_restore_config:
i2c_smbus_write_word_swapped(client, TMP102_CONF_REG,
tmp102->config_orig);
return status;
}
static int tmp102_remove(struct i2c_client *client)
{
struct tmp102 *tmp102 = i2c_get_clientdata(client);
hwmon_device_unregister(tmp102->hwmon_dev);
/* Stop monitoring if device was stopped originally */
if (tmp102->config_orig & TMP102_CONF_SD) {
int config;
config = i2c_smbus_read_word_swapped(client, TMP102_CONF_REG);
if (config >= 0)
i2c_smbus_write_word_swapped(client, TMP102_CONF_REG,
config | TMP102_CONF_SD);
}
return 0;
}
#ifdef CONFIG_PM_SLEEP
static int tmp102_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
int config;
config = i2c_smbus_read_word_swapped(client, TMP102_CONF_REG);
if (config < 0)
return config;
config |= TMP102_CONF_SD;
return i2c_smbus_write_word_swapped(client, TMP102_CONF_REG, config);
}
static int tmp102_resume(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
int config;
config = i2c_smbus_read_word_swapped(client, TMP102_CONF_REG);
if (config < 0)
return config;
config &= ~TMP102_CONF_SD;
return i2c_smbus_write_word_swapped(client, TMP102_CONF_REG, config);
}
#endif /* CONFIG_PM */
static SIMPLE_DEV_PM_OPS(tmp102_dev_pm_ops, tmp102_suspend, tmp102_resume);
static const struct i2c_device_id tmp102_id[] = {
{ "tmp102", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, tmp102_id);
static struct i2c_driver tmp102_driver = {
.driver.name = DRIVER_NAME,
.driver.pm = &tmp102_dev_pm_ops,
.probe = tmp102_probe,
.remove = tmp102_remove,
.id_table = tmp102_id,
};
module_i2c_driver(tmp102_driver);
MODULE_AUTHOR("Steven King <sfking@fdwdc.com>");
MODULE_DESCRIPTION("Texas Instruments TMP102 temperature sensor driver");
MODULE_LICENSE("GPL");