All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 10:29 ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 10:29 UTC (permalink / raw)
  To: pali.rohar, sre, sre, kernel list, linux-arm-kernel, linux-omap,
	tony, khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare, linux,
	lm-sensors


Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..9007ca9 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -28,6 +28,10 @@ config HWMON_VID
 	tristate
 	default n
 
+config SENSORS_OMAP34XX
+	bool "TI OMAP34xx internal temperature sensor"
+	depends on ARCH_OMAP3 && HIGH_RES_TIMERS
+
 config HWMON_DEBUG_CHIP
 	bool "Hardware Monitoring Chip debugging messages"
 	default n
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5c3b5d1 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)	+= nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)	+= nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)	+= ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP34XX)  += omap34xx_temp.o
 obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)	+= pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)	+= pcf8591.o
diff --git a/drivers/hwmon/omap34xx_temp.c b/drivers/hwmon/omap34xx_temp.c
new file mode 100644
index 0000000..bc7a72f
--- /dev/null
+++ b/drivers/hwmon/omap34xx_temp.c
@@ -0,0 +1,263 @@
+/*
+ * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
+ *
+ * Inspired by k8temp.c
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ */
+
+#include <linux/clk.h>
+#include <linux/hrtimer.h>
+#include <linux/module.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+
+#include "../../arch/arm/mach-omap2/control.h"
+
+#define TEMP_SENSOR_SOC BIT(8)
+#define TEMP_SENSOR_EOCZ BIT(7)
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * 30518)
+
+/* maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_RISING_DELAY (14 * 30518)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * 30518)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * 30518)
+
+struct omap34xx_data {
+	struct device *hwmon_dev;
+	struct clk *clk_32k;
+	struct mutex update_lock;
+	const char *name;
+	char valid;
+	unsigned long last_updated;
+	u32 temp;
+};
+
+static struct platform_device omap34xx_temp_device = {
+	.name	= "omap34xx_temp",
+	.id	= -1,
+};
+
+static int adc_to_temp[] = {
+	-40, -40, -40, -40, -40, -39, -38, -36, -34, -32, -31, -29, -28, -26,
+	-25, -24, -22, -21, -19, -18, -17, -15, -14, -12, -11, -9, -8, -7, -5,
+	-4, -2, -1, 0, 1, 3, 4, 5, 7, 8, 10, 11, 13, 14, 15, 17, 18, 20, 21,
+	22, 24, 25, 27, 28, 30, 31, 32, 34, 35, 37, 38, 39, 41, 42, 44, 45,
+	47, 48, 49, 51, 52, 53, 55, 56, 58, 59, 60, 62, 63, 65, 66, 67, 69,
+	70, 72, 73, 74, 76, 77, 79, 80, 81, 83, 84, 85, 87, 88, 89, 91, 92,
+	94, 95, 96, 98, 99, 100, 102, 103, 105, 106, 107, 109, 110, 111, 113,
+	114, 116, 117, 118, 120, 121, 122, 124, 124, 125, 125, 125, 125, 125};
+
+static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level)
+{
+	struct timespec timeout;
+	ktime_t expire;
+	u32 temp_sensor_reg;
+
+	level &= 1;
+	level *= TEMP_SENSOR_EOCZ;
+
+	expire = ktime_add_ns(ktime_get(), max_delay);
+	timeout = ns_to_timespec(min_delay);
+	hrtimer_nanosleep(&timeout, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+	do {
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		if ((temp_sensor_reg & TEMP_SENSOR_EOCZ) == level)
+			break;
+	} while (ktime_us_delta(expire, ktime_get()) > 0);
+
+	return (temp_sensor_reg & TEMP_SENSOR_EOCZ) == level;
+}
+
+static void omap34xx_update(struct omap34xx_data *data)
+{
+	u32 temp_sensor_reg;
+
+	mutex_lock(&data->update_lock);
+
+	if (!data->valid
+	    || time_after(jiffies, data->last_updated + HZ)) {
+		clk_prepare_enable(data->clk_32k);
+
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		temp_sensor_reg |= TEMP_SENSOR_SOC;
+		omap_ctrl_writel(temp_sensor_reg, OMAP343X_CONTROL_TEMP_SENSOR);
+
+		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
+					EOCZ_MAX_RISING_DELAY, 1))
+			goto err;
+
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		temp_sensor_reg &= ~TEMP_SENSOR_SOC;
+		omap_ctrl_writel(temp_sensor_reg, OMAP343X_CONTROL_TEMP_SENSOR);
+
+		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
+					EOCZ_MAX_FALLING_DELAY, 0))
+			goto err;
+
+		data->temp = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR) &
+						((1<<7) - 1);
+		data->last_updated = jiffies;
+		data->valid = 1;
+
+err:
+		clk_disable_unprepare(data->clk_32k);
+	}
+
+	mutex_unlock(&data->update_lock);
+}
+
+static ssize_t show_name(struct device *dev,
+			struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%s\n", data->name);
+}
+
+static ssize_t show_temp_raw(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	omap34xx_update(data);
+
+	return sprintf(buf, "%d\n", data->temp);
+}
+
+static ssize_t show_temp(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	omap34xx_update(data);
+
+	return sprintf(buf, "%d\n", adc_to_temp[data->temp]);
+}
+
+static SENSOR_DEVICE_ATTR_2(temp1_input, S_IRUGO, show_temp, NULL, 0, 0);
+static SENSOR_DEVICE_ATTR_2(temp1_input_raw, S_IRUGO, show_temp_raw,
+				NULL, 0, 0);
+static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
+
+static int omap34xx_temp_probe(void)
+{
+	int err;
+	struct omap34xx_data *data;
+
+	err = platform_device_register(&omap34xx_temp_device);
+	if (err) {
+		pr_err("Unable to register omap34xx temperature device\n");
+		goto exit;
+	}
+
+	data = kzalloc(sizeof(struct omap34xx_data), GFP_KERNEL);
+	if (!data) {
+		err = -ENOMEM;
+		goto exit_platform;
+	}
+
+	dev_set_drvdata(&omap34xx_temp_device.dev, data);
+	mutex_init(&data->update_lock);
+	data->name = "omap34xx_temp";
+
+	data->clk_32k = clk_get(&omap34xx_temp_device.dev, "ts_fck");
+	if (IS_ERR(data->clk_32k)) {
+		err = PTR_ERR(data->clk_32k);
+		goto exit_free;
+	}
+
+	err = device_create_file(&omap34xx_temp_device.dev,
+				 &sensor_dev_attr_temp1_input.dev_attr);
+	if (err)
+		goto clock_free;
+
+	err = device_create_file(&omap34xx_temp_device.dev,
+				 &sensor_dev_attr_temp1_input_raw.dev_attr);
+	if (err)
+		goto exit_remove;
+
+	err = device_create_file(&omap34xx_temp_device.dev, &dev_attr_name);
+	if (err)
+		goto exit_remove_raw;
+
+	data->hwmon_dev = hwmon_device_register(&omap34xx_temp_device.dev);
+
+	if (IS_ERR(data->hwmon_dev)) {
+		err = PTR_ERR(data->hwmon_dev);
+		goto exit_remove_all;
+	}
+
+	return 0;
+
+exit_remove_all:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &dev_attr_name);
+exit_remove_raw:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input_raw.dev_attr);
+exit_remove:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input.dev_attr);
+clock_free:
+	clk_put(data->clk_32k);
+
+exit_free:
+	kfree(data);
+exit_platform:
+	platform_device_unregister(&omap34xx_temp_device);
+exit:
+	return err;
+}
+
+static int __init omap34xx_temp_init(void)
+{
+	return omap34xx_temp_probe();
+}
+
+static void __exit omap34xx_temp_exit(void)
+{
+	struct omap34xx_data *data =
+			dev_get_drvdata(&omap34xx_temp_device.dev);
+
+	clk_put(data->clk_32k);
+	hwmon_device_unregister(data->hwmon_dev);
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input.dev_attr);
+	device_remove_file(&omap34xx_temp_device.dev, &dev_attr_name);
+	kfree(data);
+	platform_device_unregister(&omap34xx_temp_device);
+}
+
+MODULE_AUTHOR("Peter De Schrijver");
+MODULE_DESCRIPTION("Omap34xx temperature sensor");
+MODULE_LICENSE("GPL");
+
+module_init(omap34xx_temp_init)
+module_exit(omap34xx_temp_exit)
+

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 10:29 ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 10:29 UTC (permalink / raw)
  To: linux-arm-kernel


Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..9007ca9 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -28,6 +28,10 @@ config HWMON_VID
 	tristate
 	default n
 
+config SENSORS_OMAP34XX
+	bool "TI OMAP34xx internal temperature sensor"
+	depends on ARCH_OMAP3 && HIGH_RES_TIMERS
+
 config HWMON_DEBUG_CHIP
 	bool "Hardware Monitoring Chip debugging messages"
 	default n
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5c3b5d1 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)	+= nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)	+= nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)	+= ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP34XX)  += omap34xx_temp.o
 obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)	+= pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)	+= pcf8591.o
diff --git a/drivers/hwmon/omap34xx_temp.c b/drivers/hwmon/omap34xx_temp.c
new file mode 100644
index 0000000..bc7a72f
--- /dev/null
+++ b/drivers/hwmon/omap34xx_temp.c
@@ -0,0 +1,263 @@
+/*
+ * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
+ *
+ * Inspired by k8temp.c
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ */
+
+#include <linux/clk.h>
+#include <linux/hrtimer.h>
+#include <linux/module.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+
+#include "../../arch/arm/mach-omap2/control.h"
+
+#define TEMP_SENSOR_SOC BIT(8)
+#define TEMP_SENSOR_EOCZ BIT(7)
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * 30518)
+
+/* maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_RISING_DELAY (14 * 30518)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * 30518)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * 30518)
+
+struct omap34xx_data {
+	struct device *hwmon_dev;
+	struct clk *clk_32k;
+	struct mutex update_lock;
+	const char *name;
+	char valid;
+	unsigned long last_updated;
+	u32 temp;
+};
+
+static struct platform_device omap34xx_temp_device = {
+	.name	= "omap34xx_temp",
+	.id	= -1,
+};
+
+static int adc_to_temp[] = {
+	-40, -40, -40, -40, -40, -39, -38, -36, -34, -32, -31, -29, -28, -26,
+	-25, -24, -22, -21, -19, -18, -17, -15, -14, -12, -11, -9, -8, -7, -5,
+	-4, -2, -1, 0, 1, 3, 4, 5, 7, 8, 10, 11, 13, 14, 15, 17, 18, 20, 21,
+	22, 24, 25, 27, 28, 30, 31, 32, 34, 35, 37, 38, 39, 41, 42, 44, 45,
+	47, 48, 49, 51, 52, 53, 55, 56, 58, 59, 60, 62, 63, 65, 66, 67, 69,
+	70, 72, 73, 74, 76, 77, 79, 80, 81, 83, 84, 85, 87, 88, 89, 91, 92,
+	94, 95, 96, 98, 99, 100, 102, 103, 105, 106, 107, 109, 110, 111, 113,
+	114, 116, 117, 118, 120, 121, 122, 124, 124, 125, 125, 125, 125, 125};
+
+static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level)
+{
+	struct timespec timeout;
+	ktime_t expire;
+	u32 temp_sensor_reg;
+
+	level &= 1;
+	level *= TEMP_SENSOR_EOCZ;
+
+	expire = ktime_add_ns(ktime_get(), max_delay);
+	timeout = ns_to_timespec(min_delay);
+	hrtimer_nanosleep(&timeout, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+	do {
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		if ((temp_sensor_reg & TEMP_SENSOR_EOCZ) == level)
+			break;
+	} while (ktime_us_delta(expire, ktime_get()) > 0);
+
+	return (temp_sensor_reg & TEMP_SENSOR_EOCZ) == level;
+}
+
+static void omap34xx_update(struct omap34xx_data *data)
+{
+	u32 temp_sensor_reg;
+
+	mutex_lock(&data->update_lock);
+
+	if (!data->valid
+	    || time_after(jiffies, data->last_updated + HZ)) {
+		clk_prepare_enable(data->clk_32k);
+
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		temp_sensor_reg |= TEMP_SENSOR_SOC;
+		omap_ctrl_writel(temp_sensor_reg, OMAP343X_CONTROL_TEMP_SENSOR);
+
+		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
+					EOCZ_MAX_RISING_DELAY, 1))
+			goto err;
+
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		temp_sensor_reg &= ~TEMP_SENSOR_SOC;
+		omap_ctrl_writel(temp_sensor_reg, OMAP343X_CONTROL_TEMP_SENSOR);
+
+		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
+					EOCZ_MAX_FALLING_DELAY, 0))
+			goto err;
+
+		data->temp = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR) &
+						((1<<7) - 1);
+		data->last_updated = jiffies;
+		data->valid = 1;
+
+err:
+		clk_disable_unprepare(data->clk_32k);
+	}
+
+	mutex_unlock(&data->update_lock);
+}
+
+static ssize_t show_name(struct device *dev,
+			struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%s\n", data->name);
+}
+
+static ssize_t show_temp_raw(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	omap34xx_update(data);
+
+	return sprintf(buf, "%d\n", data->temp);
+}
+
+static ssize_t show_temp(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	omap34xx_update(data);
+
+	return sprintf(buf, "%d\n", adc_to_temp[data->temp]);
+}
+
+static SENSOR_DEVICE_ATTR_2(temp1_input, S_IRUGO, show_temp, NULL, 0, 0);
+static SENSOR_DEVICE_ATTR_2(temp1_input_raw, S_IRUGO, show_temp_raw,
+				NULL, 0, 0);
+static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
+
+static int omap34xx_temp_probe(void)
+{
+	int err;
+	struct omap34xx_data *data;
+
+	err = platform_device_register(&omap34xx_temp_device);
+	if (err) {
+		pr_err("Unable to register omap34xx temperature device\n");
+		goto exit;
+	}
+
+	data = kzalloc(sizeof(struct omap34xx_data), GFP_KERNEL);
+	if (!data) {
+		err = -ENOMEM;
+		goto exit_platform;
+	}
+
+	dev_set_drvdata(&omap34xx_temp_device.dev, data);
+	mutex_init(&data->update_lock);
+	data->name = "omap34xx_temp";
+
+	data->clk_32k = clk_get(&omap34xx_temp_device.dev, "ts_fck");
+	if (IS_ERR(data->clk_32k)) {
+		err = PTR_ERR(data->clk_32k);
+		goto exit_free;
+	}
+
+	err = device_create_file(&omap34xx_temp_device.dev,
+				 &sensor_dev_attr_temp1_input.dev_attr);
+	if (err)
+		goto clock_free;
+
+	err = device_create_file(&omap34xx_temp_device.dev,
+				 &sensor_dev_attr_temp1_input_raw.dev_attr);
+	if (err)
+		goto exit_remove;
+
+	err = device_create_file(&omap34xx_temp_device.dev, &dev_attr_name);
+	if (err)
+		goto exit_remove_raw;
+
+	data->hwmon_dev = hwmon_device_register(&omap34xx_temp_device.dev);
+
+	if (IS_ERR(data->hwmon_dev)) {
+		err = PTR_ERR(data->hwmon_dev);
+		goto exit_remove_all;
+	}
+
+	return 0;
+
+exit_remove_all:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &dev_attr_name);
+exit_remove_raw:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input_raw.dev_attr);
+exit_remove:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input.dev_attr);
+clock_free:
+	clk_put(data->clk_32k);
+
+exit_free:
+	kfree(data);
+exit_platform:
+	platform_device_unregister(&omap34xx_temp_device);
+exit:
+	return err;
+}
+
+static int __init omap34xx_temp_init(void)
+{
+	return omap34xx_temp_probe();
+}
+
+static void __exit omap34xx_temp_exit(void)
+{
+	struct omap34xx_data *data =
+			dev_get_drvdata(&omap34xx_temp_device.dev);
+
+	clk_put(data->clk_32k);
+	hwmon_device_unregister(data->hwmon_dev);
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input.dev_attr);
+	device_remove_file(&omap34xx_temp_device.dev, &dev_attr_name);
+	kfree(data);
+	platform_device_unregister(&omap34xx_temp_device);
+}
+
+MODULE_AUTHOR("Peter De Schrijver");
+MODULE_DESCRIPTION("Omap34xx temperature sensor");
+MODULE_LICENSE("GPL");
+
+module_init(omap34xx_temp_init)
+module_exit(omap34xx_temp_exit)
+

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [lm-sensors] [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 10:29 ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 10:29 UTC (permalink / raw)
  To: pali.rohar, sre, sre, kernel list, linux-arm-kernel, linux-omap,
	tony, khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare, linux,
	lm-sensors


Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..9007ca9 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -28,6 +28,10 @@ config HWMON_VID
 	tristate
 	default n
 
+config SENSORS_OMAP34XX
+	bool "TI OMAP34xx internal temperature sensor"
+	depends on ARCH_OMAP3 && HIGH_RES_TIMERS
+
 config HWMON_DEBUG_CHIP
 	bool "Hardware Monitoring Chip debugging messages"
 	default n
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5c3b5d1 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)	+= nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)	+= nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)	+= ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP34XX)  += omap34xx_temp.o
 obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)	+= pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)	+= pcf8591.o
diff --git a/drivers/hwmon/omap34xx_temp.c b/drivers/hwmon/omap34xx_temp.c
new file mode 100644
index 0000000..bc7a72f
--- /dev/null
+++ b/drivers/hwmon/omap34xx_temp.c
@@ -0,0 +1,263 @@
+/*
+ * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
+ *
+ * Inspired by k8temp.c
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ */
+
+#include <linux/clk.h>
+#include <linux/hrtimer.h>
+#include <linux/module.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+
+#include "../../arch/arm/mach-omap2/control.h"
+
+#define TEMP_SENSOR_SOC BIT(8)
+#define TEMP_SENSOR_EOCZ BIT(7)
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * 30518)
+
+/* maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_RISING_DELAY (14 * 30518)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * 30518)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * 30518)
+
+struct omap34xx_data {
+	struct device *hwmon_dev;
+	struct clk *clk_32k;
+	struct mutex update_lock;
+	const char *name;
+	char valid;
+	unsigned long last_updated;
+	u32 temp;
+};
+
+static struct platform_device omap34xx_temp_device = {
+	.name	= "omap34xx_temp",
+	.id	= -1,
+};
+
+static int adc_to_temp[] = {
+	-40, -40, -40, -40, -40, -39, -38, -36, -34, -32, -31, -29, -28, -26,
+	-25, -24, -22, -21, -19, -18, -17, -15, -14, -12, -11, -9, -8, -7, -5,
+	-4, -2, -1, 0, 1, 3, 4, 5, 7, 8, 10, 11, 13, 14, 15, 17, 18, 20, 21,
+	22, 24, 25, 27, 28, 30, 31, 32, 34, 35, 37, 38, 39, 41, 42, 44, 45,
+	47, 48, 49, 51, 52, 53, 55, 56, 58, 59, 60, 62, 63, 65, 66, 67, 69,
+	70, 72, 73, 74, 76, 77, 79, 80, 81, 83, 84, 85, 87, 88, 89, 91, 92,
+	94, 95, 96, 98, 99, 100, 102, 103, 105, 106, 107, 109, 110, 111, 113,
+	114, 116, 117, 118, 120, 121, 122, 124, 124, 125, 125, 125, 125, 125};
+
+static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level)
+{
+	struct timespec timeout;
+	ktime_t expire;
+	u32 temp_sensor_reg;
+
+	level &= 1;
+	level *= TEMP_SENSOR_EOCZ;
+
+	expire = ktime_add_ns(ktime_get(), max_delay);
+	timeout = ns_to_timespec(min_delay);
+	hrtimer_nanosleep(&timeout, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+	do {
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		if ((temp_sensor_reg & TEMP_SENSOR_EOCZ) = level)
+			break;
+	} while (ktime_us_delta(expire, ktime_get()) > 0);
+
+	return (temp_sensor_reg & TEMP_SENSOR_EOCZ) = level;
+}
+
+static void omap34xx_update(struct omap34xx_data *data)
+{
+	u32 temp_sensor_reg;
+
+	mutex_lock(&data->update_lock);
+
+	if (!data->valid
+	    || time_after(jiffies, data->last_updated + HZ)) {
+		clk_prepare_enable(data->clk_32k);
+
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		temp_sensor_reg |= TEMP_SENSOR_SOC;
+		omap_ctrl_writel(temp_sensor_reg, OMAP343X_CONTROL_TEMP_SENSOR);
+
+		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
+					EOCZ_MAX_RISING_DELAY, 1))
+			goto err;
+
+		temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+		temp_sensor_reg &= ~TEMP_SENSOR_SOC;
+		omap_ctrl_writel(temp_sensor_reg, OMAP343X_CONTROL_TEMP_SENSOR);
+
+		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
+					EOCZ_MAX_FALLING_DELAY, 0))
+			goto err;
+
+		data->temp = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR) &
+						((1<<7) - 1);
+		data->last_updated = jiffies;
+		data->valid = 1;
+
+err:
+		clk_disable_unprepare(data->clk_32k);
+	}
+
+	mutex_unlock(&data->update_lock);
+}
+
+static ssize_t show_name(struct device *dev,
+			struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%s\n", data->name);
+}
+
+static ssize_t show_temp_raw(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	omap34xx_update(data);
+
+	return sprintf(buf, "%d\n", data->temp);
+}
+
+static ssize_t show_temp(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap34xx_data *data = dev_get_drvdata(dev);
+
+	omap34xx_update(data);
+
+	return sprintf(buf, "%d\n", adc_to_temp[data->temp]);
+}
+
+static SENSOR_DEVICE_ATTR_2(temp1_input, S_IRUGO, show_temp, NULL, 0, 0);
+static SENSOR_DEVICE_ATTR_2(temp1_input_raw, S_IRUGO, show_temp_raw,
+				NULL, 0, 0);
+static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
+
+static int omap34xx_temp_probe(void)
+{
+	int err;
+	struct omap34xx_data *data;
+
+	err = platform_device_register(&omap34xx_temp_device);
+	if (err) {
+		pr_err("Unable to register omap34xx temperature device\n");
+		goto exit;
+	}
+
+	data = kzalloc(sizeof(struct omap34xx_data), GFP_KERNEL);
+	if (!data) {
+		err = -ENOMEM;
+		goto exit_platform;
+	}
+
+	dev_set_drvdata(&omap34xx_temp_device.dev, data);
+	mutex_init(&data->update_lock);
+	data->name = "omap34xx_temp";
+
+	data->clk_32k = clk_get(&omap34xx_temp_device.dev, "ts_fck");
+	if (IS_ERR(data->clk_32k)) {
+		err = PTR_ERR(data->clk_32k);
+		goto exit_free;
+	}
+
+	err = device_create_file(&omap34xx_temp_device.dev,
+				 &sensor_dev_attr_temp1_input.dev_attr);
+	if (err)
+		goto clock_free;
+
+	err = device_create_file(&omap34xx_temp_device.dev,
+				 &sensor_dev_attr_temp1_input_raw.dev_attr);
+	if (err)
+		goto exit_remove;
+
+	err = device_create_file(&omap34xx_temp_device.dev, &dev_attr_name);
+	if (err)
+		goto exit_remove_raw;
+
+	data->hwmon_dev = hwmon_device_register(&omap34xx_temp_device.dev);
+
+	if (IS_ERR(data->hwmon_dev)) {
+		err = PTR_ERR(data->hwmon_dev);
+		goto exit_remove_all;
+	}
+
+	return 0;
+
+exit_remove_all:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &dev_attr_name);
+exit_remove_raw:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input_raw.dev_attr);
+exit_remove:
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input.dev_attr);
+clock_free:
+	clk_put(data->clk_32k);
+
+exit_free:
+	kfree(data);
+exit_platform:
+	platform_device_unregister(&omap34xx_temp_device);
+exit:
+	return err;
+}
+
+static int __init omap34xx_temp_init(void)
+{
+	return omap34xx_temp_probe();
+}
+
+static void __exit omap34xx_temp_exit(void)
+{
+	struct omap34xx_data *data +			dev_get_drvdata(&omap34xx_temp_device.dev);
+
+	clk_put(data->clk_32k);
+	hwmon_device_unregister(data->hwmon_dev);
+	device_remove_file(&omap34xx_temp_device.dev,
+			   &sensor_dev_attr_temp1_input.dev_attr);
+	device_remove_file(&omap34xx_temp_device.dev, &dev_attr_name);
+	kfree(data);
+	platform_device_unregister(&omap34xx_temp_device);
+}
+
+MODULE_AUTHOR("Peter De Schrijver");
+MODULE_DESCRIPTION("Omap34xx temperature sensor");
+MODULE_LICENSE("GPL");
+
+module_init(omap34xx_temp_init)
+module_exit(omap34xx_temp_exit)
+

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 0/3] OMAP3 temperature sensor
  2014-12-26 10:29 ` Pavel Machek
  (?)
  (?)
@ 2014-12-26 12:34   ` Sebastian Reichel
  -1 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel, linux-arm-kernel, linux-omap, lm-sensors,
	devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
	Kumar Gala

Hi,

I've prepared an updated variant of the omap34xx temperature monitor driver.
It's based on the N9 driver instead of the N900 driver (and thus has omap36xx
support).

The differences compared to the original driver are:

 * DT based
 * No includes from arch, instead uses syscon DT node + regmap
 * Removed support for raw temperature reading
  - I assume this was used for debugging and regmap can be used
    instead with newer kernels.
 * Introduction of managed resources where possible
 * Usage of module_platform_driver() macro
 * Added some comments referencing the TRM

So far the patchset is _compile-tested only_. I will test it on my N900 in
the next days.

-- Sebastian

Sebastian Reichel (3):
  DT Binding for omap3 temperature sensor
  hwmon: Driver for OMAP3 temperature sensor
  ARM: dts: OMAP34xx/36xx: Add temperature sensor

 .../bindings/hwmon/omap3-temperature.txt           |  25 ++
 arch/arm/boot/dts/omap34xx.dtsi                    |   7 +
 arch/arm/boot/dts/omap36xx.dtsi                    |   7 +
 drivers/hwmon/Kconfig                              |   8 +
 drivers/hwmon/Makefile                             |   1 +
 drivers/hwmon/omap3-temp.c                         | 307 +++++++++++++++++++++
 6 files changed, 355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 create mode 100644 drivers/hwmon/omap3-temp.c

-- 
2.1.3


^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 0/3] OMAP3 temperature sensor
@ 2014-12-26 12:34   ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala

Hi,

I've prepared an updated variant of the omap34xx temperature monitor driver.
It's based on the N9 driver instead of the N900 driver (and thus has omap36xx
support).

The differences compared to the original driver are:

 * DT based
 * No includes from arch, instead uses syscon DT node + regmap
 * Removed support for raw temperature reading
  - I assume this was used for debugging and regmap can be used
    instead with newer kernels.
 * Introduction of managed resources where possible
 * Usage of module_platform_driver() macro
 * Added some comments referencing the TRM

So far the patchset is _compile-tested only_. I will test it on my N900 in
the next days.

-- Sebastian

Sebastian Reichel (3):
  DT Binding for omap3 temperature sensor
  hwmon: Driver for OMAP3 temperature sensor
  ARM: dts: OMAP34xx/36xx: Add temperature sensor

 .../bindings/hwmon/omap3-temperature.txt           |  25 ++
 arch/arm/boot/dts/omap34xx.dtsi                    |   7 +
 arch/arm/boot/dts/omap36xx.dtsi                    |   7 +
 drivers/hwmon/Kconfig                              |   8 +
 drivers/hwmon/Makefile                             |   1 +
 drivers/hwmon/omap3-temp.c                         | 307 +++++++++++++++++++++
 6 files changed, 355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 create mode 100644 drivers/hwmon/omap3-temp.c

-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 0/3] OMAP3 temperature sensor
@ 2014-12-26 12:34   ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

I've prepared an updated variant of the omap34xx temperature monitor driver.
It's based on the N9 driver instead of the N900 driver (and thus has omap36xx
support).

The differences compared to the original driver are:

 * DT based
 * No includes from arch, instead uses syscon DT node + regmap
 * Removed support for raw temperature reading
  - I assume this was used for debugging and regmap can be used
    instead with newer kernels.
 * Introduction of managed resources where possible
 * Usage of module_platform_driver() macro
 * Added some comments referencing the TRM

So far the patchset is _compile-tested only_. I will test it on my N900 in
the next days.

-- Sebastian

Sebastian Reichel (3):
  DT Binding for omap3 temperature sensor
  hwmon: Driver for OMAP3 temperature sensor
  ARM: dts: OMAP34xx/36xx: Add temperature sensor

 .../bindings/hwmon/omap3-temperature.txt           |  25 ++
 arch/arm/boot/dts/omap34xx.dtsi                    |   7 +
 arch/arm/boot/dts/omap36xx.dtsi                    |   7 +
 drivers/hwmon/Kconfig                              |   8 +
 drivers/hwmon/Makefile                             |   1 +
 drivers/hwmon/omap3-temp.c                         | 307 +++++++++++++++++++++
 6 files changed, 355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 create mode 100644 drivers/hwmon/omap3-temp.c

-- 
2.1.3

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [lm-sensors] [PATCH 0/3] OMAP3 temperature sensor
@ 2014-12-26 12:34   ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel, linux-arm-kernel, linux-omap, lm-sensors,
	devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
	Kumar Gala

Hi,

I've prepared an updated variant of the omap34xx temperature monitor driver.
It's based on the N9 driver instead of the N900 driver (and thus has omap36xx
support).

The differences compared to the original driver are:

 * DT based
 * No includes from arch, instead uses syscon DT node + regmap
 * Removed support for raw temperature reading
  - I assume this was used for debugging and regmap can be used
    instead with newer kernels.
 * Introduction of managed resources where possible
 * Usage of module_platform_driver() macro
 * Added some comments referencing the TRM

So far the patchset is _compile-tested only_. I will test it on my N900 in
the next days.

-- Sebastian

Sebastian Reichel (3):
  DT Binding for omap3 temperature sensor
  hwmon: Driver for OMAP3 temperature sensor
  ARM: dts: OMAP34xx/36xx: Add temperature sensor

 .../bindings/hwmon/omap3-temperature.txt           |  25 ++
 arch/arm/boot/dts/omap34xx.dtsi                    |   7 +
 arch/arm/boot/dts/omap36xx.dtsi                    |   7 +
 drivers/hwmon/Kconfig                              |   8 +
 drivers/hwmon/Makefile                             |   1 +
 drivers/hwmon/omap3-temp.c                         | 307 +++++++++++++++++++++
 6 files changed, 355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 create mode 100644 drivers/hwmon/omap3-temp.c

-- 
2.1.3


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 1/3] DT Binding for omap3 temperature sensor
  2014-12-26 12:34   ` Sebastian Reichel
  (?)
@ 2014-12-26 12:34     ` Sebastian Reichel
  -1 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel, linux-arm-kernel, linux-omap, lm-sensors,
	devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
	Kumar Gala

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This provides a
DT binding specification for the temperature monitor.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt

diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
new file mode 100644
index 0000000..99631ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
@@ -0,0 +1,25 @@
+* OMAP3 temperature sensor
+
+The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
+which can be used to determine the SoCs temperature.
+
+Requires node properties:
+- compatible :	should contain one of
+	- "ti,omap34xx-temperature-sensor" for OMAP34xx
+	- "ti,omap36xx-temperature-sensor" for OMAP36xx
+- syscon :	Should be a phandle to system configuration node which
+		encompases the temperature register
+- clocks :	Should contain 32KHz fclk clock specifier
+- clock-names :	Should contain clock names
+	- "fck" for the 32KHz fclk clock specifier
+
+Example for omap34xx:
+
+/ {
+	temperature-sensor {
+		compatible = "ti,omap34xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
+};
-- 
2.1.3


^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 12:34     ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: linux-arm-kernel

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This provides a
DT binding specification for the temperature monitor.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt

diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
new file mode 100644
index 0000000..99631ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
@@ -0,0 +1,25 @@
+* OMAP3 temperature sensor
+
+The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
+which can be used to determine the SoCs temperature.
+
+Requires node properties:
+- compatible :	should contain one of
+	- "ti,omap34xx-temperature-sensor" for OMAP34xx
+	- "ti,omap36xx-temperature-sensor" for OMAP36xx
+- syscon :	Should be a phandle to system configuration node which
+		encompases the temperature register
+- clocks :	Should contain 32KHz fclk clock specifier
+- clock-names :	Should contain clock names
+	- "fck" for the 32KHz fclk clock specifier
+
+Example for omap34xx:
+
+/ {
+	temperature-sensor {
+		compatible = "ti,omap34xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
+};
-- 
2.1.3

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [lm-sensors] [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 12:34     ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel, linux-arm-kernel, linux-omap, lm-sensors,
	devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
	Kumar Gala

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This provides a
DT binding specification for the temperature monitor.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt

diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
new file mode 100644
index 0000000..99631ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
@@ -0,0 +1,25 @@
+* OMAP3 temperature sensor
+
+The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
+which can be used to determine the SoCs temperature.
+
+Requires node properties:
+- compatible :	should contain one of
+	- "ti,omap34xx-temperature-sensor" for OMAP34xx
+	- "ti,omap36xx-temperature-sensor" for OMAP36xx
+- syscon :	Should be a phandle to system configuration node which
+		encompases the temperature register
+- clocks :	Should contain 32KHz fclk clock specifier
+- clock-names :	Should contain clock names
+	- "fck" for the 32KHz fclk clock specifier
+
+Example for omap34xx:
+
+/ {
+	temperature-sensor {
+		compatible = "ti,omap34xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
+};
-- 
2.1.3


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-26 12:34   ` Sebastian Reichel
  (?)
@ 2014-12-26 12:34     ` Sebastian Reichel
  -1 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel, linux-arm-kernel, linux-omap, lm-sensors,
	devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
	Kumar Gala

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This patch provides
a DT based driver for the temperature sensor based on an older driver
written by Peter De Schrijver for the Nokia N900 and N9.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 drivers/hwmon/Kconfig      |   8 ++
 drivers/hwmon/Makefile     |   1 +
 drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 316 insertions(+)
 create mode 100644 drivers/hwmon/omap3-temp.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..749748d 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1135,6 +1135,14 @@ config SENSORS_NCT7802
 	  This driver can also be built as a module.  If so, the module
 	  will be called nct7802.
 
+config SENSORS_OMAP3_TEMP
+	tristate "OMAP3 Temperature Sensor"
+	depends on OF && (ARCH_OMAP3 || COMPILE_TEST)
+	select MFD_SYSCON
+	help
+	  If you say yes here you get support for the temperature sensor
+	  built into OMAP3 processors.
+
 config SENSORS_PCF8591
 	tristate "Philips PCF8591 ADC/DAC"
 	depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5a69773 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)	+= nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)	+= nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)	+= ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP3_TEMP)	+= omap3-temp.o
 obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)	+= pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)	+= pcf8591.o
diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
new file mode 100644
index 0000000..5c331c5
--- /dev/null
+++ b/drivers/hwmon/omap3-temp.c
@@ -0,0 +1,307 @@
+/*
+ * omap3-temp.c - driver for OMAP34xx and OMAP36xx temperature sensor
+ *
+ * Copyright (c) 2014 Sebastian Reichel <sre@kernel.org>
+ * Copyright (C) 2008, 2009, 2010 Nokia Corporation
+ *
+ * based on Peter De Schrijver's driver for N9
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <linux/clk.h>
+#include <linux/hrtimer.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/sched.h>
+#include <linux/stat.h>
+
+/* 32.768Khz clock speed in nano seconds */
+#define CLOCK_32K_SPEED_NS 30518
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * CLOCK_32K_SPEED_NS)
+
+/* From docs, maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock. But after some experiments,
+ * 24 cycles as maximum is safer. */
+#define EOCZ_MAX_RISING_DELAY (24 * CLOCK_32K_SPEED_NS)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * CLOCK_32K_SPEED_NS)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * CLOCK_32K_SPEED_NS)
+
+/* temperature register offset in the syscon register area */
+#define SYSCON_TEMP_REG 0x02B4
+
+/* TRM: Table 7-11. ADC Codes Versus Temperature */
+static const int adc_to_temp_3430[] = {
+	-400, -400, -400, -400, -400, -390, -380, -360, -340, -320, -310,
+	-290, -280, -260, -250, -240, -220, -210, -190, -180, -170, -150,
+	-140, -120, -110, -90, -80, -70, -50, -40, -20, -10, 00, 10, 30,
+	40, 50, 70, 80, 100, 110, 130, 140, 150, 170, 180, 200, 210, 220,
+	240, 250, 270, 280, 300, 310, 320, 340, 350, 370, 380, 390, 410, 420,
+	440, 450, 470, 480, 490, 510, 520, 530, 550, 560, 580, 590, 600, 620,
+	630, 650, 660, 670, 690, 700, 720, 730, 740, 760, 770, 790, 800, 810,
+	830, 840, 850, 870, 880, 890, 910, 920, 940, 950, 960, 980, 990, 1000,
+	1020, 1030, 1050, 1060, 1070, 1090, 1100, 1110, 1130, 1140, 1160,
+	1170, 1180, 1200, 1210, 1220, 1240, 1240, 1250, 1250, 1250, 1250,
+	1250};
+
+/* TRM: Table 13-11. ADC Code Versus Temperature */
+static const int adc_to_temp_3630[] = {
+	-400, -400, -400, -400, -400, -400, -400, -400, -400, -400, -400,
+	-400, -400, -400, -380, -350, -340, -320, -300, -280, -260, -240,
+	-220, -200, -185, -170, -150, -135, -120, -100, -80, -65, -50, -35,
+	-15, 0, 20, 35, 50, 65, 85, 100, 120, 135, 150, 170, 190, 210, 230,
+	250, 270, 285, 300, 320, 335, 350, 370, 385, 400, 420, 435, 450, 470,
+	485, 500, 520, 535, 550, 570, 585, 600, 620, 640, 660, 680, 700, 715,
+	735, 750, 770, 785, 800, 820, 835, 850, 870, 885, 900, 920, 935, 950,
+	970, 985, 1000, 1020, 1035, 1050, 1070, 1090, 1110, 1130, 1150, 1170,
+	1185, 1200, 1220, 1235, 1250, 1250, 1250, 1250, 1250, 1250, 1250,
+	1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250,
+	1250, 1250, 1250};
+
+struct omap3_temp_type {
+	const int *adc_to_temp;
+	u8 soc_bit;
+	u8 eocz_bit;
+};
+
+/* TRM: Table 7-228. CONTROL_TEMP_SENSOR */
+static const struct omap3_temp_type omap34xx_temp_type = {
+	.eocz_bit = 7,
+	.soc_bit = 8,
+	.adc_to_temp = adc_to_temp_3430,
+};
+
+/* TRM: Table 13-239. CONTROL_TEMP_SENSOR */
+static const struct omap3_temp_type omap36xx_temp_type = {
+	.eocz_bit = 8,
+	.soc_bit = 9,
+	.adc_to_temp = adc_to_temp_3630,
+};
+
+struct omap3_temp_data {
+	struct device *hwmon_dev;
+	struct regmap *syscon;
+	struct clk *clk_32k;
+	struct omap3_temp_type *hwdata;
+	/* mutex to protect the update procedure while reading from sensor */
+	struct mutex update_lock;
+	const char *name;
+	unsigned long last_updated;
+	u32 temperature;
+	bool valid;
+};
+
+static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
+				struct omap3_temp_data *data)
+{
+	ktime_t timeout, expire;
+	u32 temp_sensor_reg, eocz_mask;
+
+	eocz_mask = BIT(data->hwdata->eocz_bit);
+	level &= 1;
+	level *= eocz_mask;
+
+	expire = ktime_add_ns(ktime_get(), max_delay);
+	timeout = ktime_set(0, min_delay);
+	__set_current_state(TASK_INTERRUPTIBLE);
+	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
+	do {
+		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
+		if ((temp_sensor_reg & eocz_mask) == level)
+			break;
+	} while (ktime_us_delta(expire, ktime_get()) > 0);
+
+	return (temp_sensor_reg & eocz_mask) == level;
+}
+
+static int omap3_temp_update(struct omap3_temp_data *data)
+{
+	int e = 0;
+	u32 temp_sensor_reg;
+	u32 soc_mask = BIT(data->hwdata->soc_bit);
+
+	mutex_lock(&data->update_lock);
+
+	if (!data->valid || time_after(jiffies, data->last_updated + HZ)) {
+		clk_enable(data->clk_32k);
+
+		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
+				   soc_mask, soc_mask);
+
+		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
+		    EOCZ_MAX_RISING_DELAY, 1, data)) {
+			e = -EIO;
+			goto err;
+		}
+
+		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
+
+		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
+		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
+			e = -EIO;
+			goto err;
+		}
+
+		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
+		data->temperature = temp_sensor_reg & ((1<<7) - 1);
+		data->last_updated = jiffies;
+		data->valid = true;
+
+err:
+		clk_disable(data->clk_32k);
+	}
+
+	mutex_unlock(&data->update_lock);
+	return e;
+}
+
+static ssize_t show_temp(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap3_temp_data *data = dev_get_drvdata(dev);
+	int temp;
+	int ret;
+
+	ret = omap3_temp_update(data);
+	if (ret < 0)
+		return ret;
+
+	temp = data->hwdata->adc_to_temp[data->temperature];
+
+	return sprintf(buf, "%d.%d\n", temp / 10, temp % 10);
+}
+
+static ssize_t show_name(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap3_temp_data *data = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%s\n", data->name);
+}
+
+static SENSOR_DEVICE_ATTR_2(temp_input, S_IRUGO, show_temp, NULL, 0, 0);
+static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
+
+static const struct of_device_id omap3_temp_dt_ids[] = {
+	{
+		.compatible = "ti,omap34xx-temperature-sensor",
+		.data = &omap34xx_temp_type,
+	},
+	{
+		.compatible = "ti,omap36xx-temperature-sensor",
+		.data = &omap36xx_temp_type,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, omap3_temp_dt_ids);
+
+static int omap3_temp_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct omap3_temp_data *data;
+	const struct of_device_id *of_id;
+	int err;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	of_id = of_match_device(omap3_temp_dt_ids, &pdev->dev);
+	if (!of_id) {
+		dev_warn(&pdev->dev, "unsupported device!");
+		return -ENODEV;
+	}
+
+	mutex_init(&data->update_lock);
+	data->name = "omap3-temperature";
+
+	data->clk_32k = devm_clk_get(&pdev->dev, "fck");
+	if (IS_ERR(data->clk_32k))
+		return PTR_ERR(data->clk_32k);
+
+	data->hwdata = (struct omap3_temp_type *)of_id->data;
+
+	data->syscon = syscon_regmap_lookup_by_phandle(np, "syscon");
+	if (IS_ERR(data->syscon))
+		return PTR_ERR(data->syscon);
+
+	platform_set_drvdata(pdev, data);
+
+	err = device_create_file(&pdev->dev,
+				 &sensor_dev_attr_temp_input.dev_attr);
+	if (err)
+		goto fail_temp_file;
+
+	err = device_create_file(&pdev->dev, &dev_attr_name);
+	if (err)
+		goto fail_name_file;
+
+	data->hwmon_dev = hwmon_device_register(&pdev->dev);
+	if (IS_ERR(data->hwmon_dev)) {
+		err = PTR_ERR(data->hwmon_dev);
+		goto fail_hwmon_reg;
+	}
+
+	return 0;
+
+fail_hwmon_reg:
+	device_remove_file(&pdev->dev, &dev_attr_name);
+fail_name_file:
+	device_remove_file(&pdev->dev, &sensor_dev_attr_temp_input.dev_attr);
+fail_temp_file:
+	return err;
+}
+
+static int omap3_temp_remove(struct platform_device *pdev)
+{
+	struct omap3_temp_data *data = platform_get_drvdata(pdev);
+
+	if (!data)
+		return 0;
+
+	hwmon_device_unregister(data->hwmon_dev);
+	device_remove_file(&pdev->dev, &dev_attr_name);
+	device_remove_file(&pdev->dev, &sensor_dev_attr_temp_input.dev_attr);
+
+	return 0;
+}
+
+static struct platform_driver omap3_temp_driver = {
+	.probe	= omap3_temp_probe,
+	.remove	= omap3_temp_remove,
+	.driver = {
+		.name	= "omap3-temperature",
+		.of_match_table	= omap3_temp_dt_ids,
+	},
+};
+
+module_platform_driver(omap3_temp_driver);
+
+MODULE_AUTHOR("Sebastian Reichel");
+MODULE_DESCRIPTION("OMAP34xx/OMAP36xx temperature sensor");
+MODULE_LICENSE("GPL");
-- 
2.1.3


^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-26 12:34     ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: linux-arm-kernel

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This patch provides
a DT based driver for the temperature sensor based on an older driver
written by Peter De Schrijver for the Nokia N900 and N9.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 drivers/hwmon/Kconfig      |   8 ++
 drivers/hwmon/Makefile     |   1 +
 drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 316 insertions(+)
 create mode 100644 drivers/hwmon/omap3-temp.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..749748d 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1135,6 +1135,14 @@ config SENSORS_NCT7802
 	  This driver can also be built as a module.  If so, the module
 	  will be called nct7802.
 
+config SENSORS_OMAP3_TEMP
+	tristate "OMAP3 Temperature Sensor"
+	depends on OF && (ARCH_OMAP3 || COMPILE_TEST)
+	select MFD_SYSCON
+	help
+	  If you say yes here you get support for the temperature sensor
+	  built into OMAP3 processors.
+
 config SENSORS_PCF8591
 	tristate "Philips PCF8591 ADC/DAC"
 	depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5a69773 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)	+= nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)	+= nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)	+= ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP3_TEMP)	+= omap3-temp.o
 obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)	+= pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)	+= pcf8591.o
diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
new file mode 100644
index 0000000..5c331c5
--- /dev/null
+++ b/drivers/hwmon/omap3-temp.c
@@ -0,0 +1,307 @@
+/*
+ * omap3-temp.c - driver for OMAP34xx and OMAP36xx temperature sensor
+ *
+ * Copyright (c) 2014 Sebastian Reichel <sre@kernel.org>
+ * Copyright (C) 2008, 2009, 2010 Nokia Corporation
+ *
+ * based on Peter De Schrijver's driver for N9
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <linux/clk.h>
+#include <linux/hrtimer.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/sched.h>
+#include <linux/stat.h>
+
+/* 32.768Khz clock speed in nano seconds */
+#define CLOCK_32K_SPEED_NS 30518
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * CLOCK_32K_SPEED_NS)
+
+/* From docs, maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock. But after some experiments,
+ * 24 cycles as maximum is safer. */
+#define EOCZ_MAX_RISING_DELAY (24 * CLOCK_32K_SPEED_NS)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * CLOCK_32K_SPEED_NS)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * CLOCK_32K_SPEED_NS)
+
+/* temperature register offset in the syscon register area */
+#define SYSCON_TEMP_REG 0x02B4
+
+/* TRM: Table 7-11. ADC Codes Versus Temperature */
+static const int adc_to_temp_3430[] = {
+	-400, -400, -400, -400, -400, -390, -380, -360, -340, -320, -310,
+	-290, -280, -260, -250, -240, -220, -210, -190, -180, -170, -150,
+	-140, -120, -110, -90, -80, -70, -50, -40, -20, -10, 00, 10, 30,
+	40, 50, 70, 80, 100, 110, 130, 140, 150, 170, 180, 200, 210, 220,
+	240, 250, 270, 280, 300, 310, 320, 340, 350, 370, 380, 390, 410, 420,
+	440, 450, 470, 480, 490, 510, 520, 530, 550, 560, 580, 590, 600, 620,
+	630, 650, 660, 670, 690, 700, 720, 730, 740, 760, 770, 790, 800, 810,
+	830, 840, 850, 870, 880, 890, 910, 920, 940, 950, 960, 980, 990, 1000,
+	1020, 1030, 1050, 1060, 1070, 1090, 1100, 1110, 1130, 1140, 1160,
+	1170, 1180, 1200, 1210, 1220, 1240, 1240, 1250, 1250, 1250, 1250,
+	1250};
+
+/* TRM: Table 13-11. ADC Code Versus Temperature */
+static const int adc_to_temp_3630[] = {
+	-400, -400, -400, -400, -400, -400, -400, -400, -400, -400, -400,
+	-400, -400, -400, -380, -350, -340, -320, -300, -280, -260, -240,
+	-220, -200, -185, -170, -150, -135, -120, -100, -80, -65, -50, -35,
+	-15, 0, 20, 35, 50, 65, 85, 100, 120, 135, 150, 170, 190, 210, 230,
+	250, 270, 285, 300, 320, 335, 350, 370, 385, 400, 420, 435, 450, 470,
+	485, 500, 520, 535, 550, 570, 585, 600, 620, 640, 660, 680, 700, 715,
+	735, 750, 770, 785, 800, 820, 835, 850, 870, 885, 900, 920, 935, 950,
+	970, 985, 1000, 1020, 1035, 1050, 1070, 1090, 1110, 1130, 1150, 1170,
+	1185, 1200, 1220, 1235, 1250, 1250, 1250, 1250, 1250, 1250, 1250,
+	1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250,
+	1250, 1250, 1250};
+
+struct omap3_temp_type {
+	const int *adc_to_temp;
+	u8 soc_bit;
+	u8 eocz_bit;
+};
+
+/* TRM: Table 7-228. CONTROL_TEMP_SENSOR */
+static const struct omap3_temp_type omap34xx_temp_type = {
+	.eocz_bit = 7,
+	.soc_bit = 8,
+	.adc_to_temp = adc_to_temp_3430,
+};
+
+/* TRM: Table 13-239. CONTROL_TEMP_SENSOR */
+static const struct omap3_temp_type omap36xx_temp_type = {
+	.eocz_bit = 8,
+	.soc_bit = 9,
+	.adc_to_temp = adc_to_temp_3630,
+};
+
+struct omap3_temp_data {
+	struct device *hwmon_dev;
+	struct regmap *syscon;
+	struct clk *clk_32k;
+	struct omap3_temp_type *hwdata;
+	/* mutex to protect the update procedure while reading from sensor */
+	struct mutex update_lock;
+	const char *name;
+	unsigned long last_updated;
+	u32 temperature;
+	bool valid;
+};
+
+static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
+				struct omap3_temp_data *data)
+{
+	ktime_t timeout, expire;
+	u32 temp_sensor_reg, eocz_mask;
+
+	eocz_mask = BIT(data->hwdata->eocz_bit);
+	level &= 1;
+	level *= eocz_mask;
+
+	expire = ktime_add_ns(ktime_get(), max_delay);
+	timeout = ktime_set(0, min_delay);
+	__set_current_state(TASK_INTERRUPTIBLE);
+	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
+	do {
+		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
+		if ((temp_sensor_reg & eocz_mask) == level)
+			break;
+	} while (ktime_us_delta(expire, ktime_get()) > 0);
+
+	return (temp_sensor_reg & eocz_mask) == level;
+}
+
+static int omap3_temp_update(struct omap3_temp_data *data)
+{
+	int e = 0;
+	u32 temp_sensor_reg;
+	u32 soc_mask = BIT(data->hwdata->soc_bit);
+
+	mutex_lock(&data->update_lock);
+
+	if (!data->valid || time_after(jiffies, data->last_updated + HZ)) {
+		clk_enable(data->clk_32k);
+
+		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
+				   soc_mask, soc_mask);
+
+		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
+		    EOCZ_MAX_RISING_DELAY, 1, data)) {
+			e = -EIO;
+			goto err;
+		}
+
+		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
+
+		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
+		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
+			e = -EIO;
+			goto err;
+		}
+
+		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
+		data->temperature = temp_sensor_reg & ((1<<7) - 1);
+		data->last_updated = jiffies;
+		data->valid = true;
+
+err:
+		clk_disable(data->clk_32k);
+	}
+
+	mutex_unlock(&data->update_lock);
+	return e;
+}
+
+static ssize_t show_temp(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap3_temp_data *data = dev_get_drvdata(dev);
+	int temp;
+	int ret;
+
+	ret = omap3_temp_update(data);
+	if (ret < 0)
+		return ret;
+
+	temp = data->hwdata->adc_to_temp[data->temperature];
+
+	return sprintf(buf, "%d.%d\n", temp / 10, temp % 10);
+}
+
+static ssize_t show_name(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap3_temp_data *data = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%s\n", data->name);
+}
+
+static SENSOR_DEVICE_ATTR_2(temp_input, S_IRUGO, show_temp, NULL, 0, 0);
+static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
+
+static const struct of_device_id omap3_temp_dt_ids[] = {
+	{
+		.compatible = "ti,omap34xx-temperature-sensor",
+		.data = &omap34xx_temp_type,
+	},
+	{
+		.compatible = "ti,omap36xx-temperature-sensor",
+		.data = &omap36xx_temp_type,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, omap3_temp_dt_ids);
+
+static int omap3_temp_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct omap3_temp_data *data;
+	const struct of_device_id *of_id;
+	int err;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	of_id = of_match_device(omap3_temp_dt_ids, &pdev->dev);
+	if (!of_id) {
+		dev_warn(&pdev->dev, "unsupported device!");
+		return -ENODEV;
+	}
+
+	mutex_init(&data->update_lock);
+	data->name = "omap3-temperature";
+
+	data->clk_32k = devm_clk_get(&pdev->dev, "fck");
+	if (IS_ERR(data->clk_32k))
+		return PTR_ERR(data->clk_32k);
+
+	data->hwdata = (struct omap3_temp_type *)of_id->data;
+
+	data->syscon = syscon_regmap_lookup_by_phandle(np, "syscon");
+	if (IS_ERR(data->syscon))
+		return PTR_ERR(data->syscon);
+
+	platform_set_drvdata(pdev, data);
+
+	err = device_create_file(&pdev->dev,
+				 &sensor_dev_attr_temp_input.dev_attr);
+	if (err)
+		goto fail_temp_file;
+
+	err = device_create_file(&pdev->dev, &dev_attr_name);
+	if (err)
+		goto fail_name_file;
+
+	data->hwmon_dev = hwmon_device_register(&pdev->dev);
+	if (IS_ERR(data->hwmon_dev)) {
+		err = PTR_ERR(data->hwmon_dev);
+		goto fail_hwmon_reg;
+	}
+
+	return 0;
+
+fail_hwmon_reg:
+	device_remove_file(&pdev->dev, &dev_attr_name);
+fail_name_file:
+	device_remove_file(&pdev->dev, &sensor_dev_attr_temp_input.dev_attr);
+fail_temp_file:
+	return err;
+}
+
+static int omap3_temp_remove(struct platform_device *pdev)
+{
+	struct omap3_temp_data *data = platform_get_drvdata(pdev);
+
+	if (!data)
+		return 0;
+
+	hwmon_device_unregister(data->hwmon_dev);
+	device_remove_file(&pdev->dev, &dev_attr_name);
+	device_remove_file(&pdev->dev, &sensor_dev_attr_temp_input.dev_attr);
+
+	return 0;
+}
+
+static struct platform_driver omap3_temp_driver = {
+	.probe	= omap3_temp_probe,
+	.remove	= omap3_temp_remove,
+	.driver = {
+		.name	= "omap3-temperature",
+		.of_match_table	= omap3_temp_dt_ids,
+	},
+};
+
+module_platform_driver(omap3_temp_driver);
+
+MODULE_AUTHOR("Sebastian Reichel");
+MODULE_DESCRIPTION("OMAP34xx/OMAP36xx temperature sensor");
+MODULE_LICENSE("GPL");
-- 
2.1.3

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-26 12:34     ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel, linux-arm-kernel, linux-omap, lm-sensors,
	devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
	Kumar Gala

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This patch provides
a DT based driver for the temperature sensor based on an older driver
written by Peter De Schrijver for the Nokia N900 and N9.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 drivers/hwmon/Kconfig      |   8 ++
 drivers/hwmon/Makefile     |   1 +
 drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 316 insertions(+)
 create mode 100644 drivers/hwmon/omap3-temp.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..749748d 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1135,6 +1135,14 @@ config SENSORS_NCT7802
 	  This driver can also be built as a module.  If so, the module
 	  will be called nct7802.
 
+config SENSORS_OMAP3_TEMP
+	tristate "OMAP3 Temperature Sensor"
+	depends on OF && (ARCH_OMAP3 || COMPILE_TEST)
+	select MFD_SYSCON
+	help
+	  If you say yes here you get support for the temperature sensor
+	  built into OMAP3 processors.
+
 config SENSORS_PCF8591
 	tristate "Philips PCF8591 ADC/DAC"
 	depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5a69773 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)	+= nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)	+= nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)	+= ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP3_TEMP)	+= omap3-temp.o
 obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)	+= pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)	+= pcf8591.o
diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
new file mode 100644
index 0000000..5c331c5
--- /dev/null
+++ b/drivers/hwmon/omap3-temp.c
@@ -0,0 +1,307 @@
+/*
+ * omap3-temp.c - driver for OMAP34xx and OMAP36xx temperature sensor
+ *
+ * Copyright (c) 2014 Sebastian Reichel <sre@kernel.org>
+ * Copyright (C) 2008, 2009, 2010 Nokia Corporation
+ *
+ * based on Peter De Schrijver's driver for N9
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <linux/clk.h>
+#include <linux/hrtimer.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/sched.h>
+#include <linux/stat.h>
+
+/* 32.768Khz clock speed in nano seconds */
+#define CLOCK_32K_SPEED_NS 30518
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * CLOCK_32K_SPEED_NS)
+
+/* From docs, maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock. But after some experiments,
+ * 24 cycles as maximum is safer. */
+#define EOCZ_MAX_RISING_DELAY (24 * CLOCK_32K_SPEED_NS)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * CLOCK_32K_SPEED_NS)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * CLOCK_32K_SPEED_NS)
+
+/* temperature register offset in the syscon register area */
+#define SYSCON_TEMP_REG 0x02B4
+
+/* TRM: Table 7-11. ADC Codes Versus Temperature */
+static const int adc_to_temp_3430[] = {
+	-400, -400, -400, -400, -400, -390, -380, -360, -340, -320, -310,
+	-290, -280, -260, -250, -240, -220, -210, -190, -180, -170, -150,
+	-140, -120, -110, -90, -80, -70, -50, -40, -20, -10, 00, 10, 30,
+	40, 50, 70, 80, 100, 110, 130, 140, 150, 170, 180, 200, 210, 220,
+	240, 250, 270, 280, 300, 310, 320, 340, 350, 370, 380, 390, 410, 420,
+	440, 450, 470, 480, 490, 510, 520, 530, 550, 560, 580, 590, 600, 620,
+	630, 650, 660, 670, 690, 700, 720, 730, 740, 760, 770, 790, 800, 810,
+	830, 840, 850, 870, 880, 890, 910, 920, 940, 950, 960, 980, 990, 1000,
+	1020, 1030, 1050, 1060, 1070, 1090, 1100, 1110, 1130, 1140, 1160,
+	1170, 1180, 1200, 1210, 1220, 1240, 1240, 1250, 1250, 1250, 1250,
+	1250};
+
+/* TRM: Table 13-11. ADC Code Versus Temperature */
+static const int adc_to_temp_3630[] = {
+	-400, -400, -400, -400, -400, -400, -400, -400, -400, -400, -400,
+	-400, -400, -400, -380, -350, -340, -320, -300, -280, -260, -240,
+	-220, -200, -185, -170, -150, -135, -120, -100, -80, -65, -50, -35,
+	-15, 0, 20, 35, 50, 65, 85, 100, 120, 135, 150, 170, 190, 210, 230,
+	250, 270, 285, 300, 320, 335, 350, 370, 385, 400, 420, 435, 450, 470,
+	485, 500, 520, 535, 550, 570, 585, 600, 620, 640, 660, 680, 700, 715,
+	735, 750, 770, 785, 800, 820, 835, 850, 870, 885, 900, 920, 935, 950,
+	970, 985, 1000, 1020, 1035, 1050, 1070, 1090, 1110, 1130, 1150, 1170,
+	1185, 1200, 1220, 1235, 1250, 1250, 1250, 1250, 1250, 1250, 1250,
+	1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250, 1250,
+	1250, 1250, 1250};
+
+struct omap3_temp_type {
+	const int *adc_to_temp;
+	u8 soc_bit;
+	u8 eocz_bit;
+};
+
+/* TRM: Table 7-228. CONTROL_TEMP_SENSOR */
+static const struct omap3_temp_type omap34xx_temp_type = {
+	.eocz_bit = 7,
+	.soc_bit = 8,
+	.adc_to_temp = adc_to_temp_3430,
+};
+
+/* TRM: Table 13-239. CONTROL_TEMP_SENSOR */
+static const struct omap3_temp_type omap36xx_temp_type = {
+	.eocz_bit = 8,
+	.soc_bit = 9,
+	.adc_to_temp = adc_to_temp_3630,
+};
+
+struct omap3_temp_data {
+	struct device *hwmon_dev;
+	struct regmap *syscon;
+	struct clk *clk_32k;
+	struct omap3_temp_type *hwdata;
+	/* mutex to protect the update procedure while reading from sensor */
+	struct mutex update_lock;
+	const char *name;
+	unsigned long last_updated;
+	u32 temperature;
+	bool valid;
+};
+
+static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
+				struct omap3_temp_data *data)
+{
+	ktime_t timeout, expire;
+	u32 temp_sensor_reg, eocz_mask;
+
+	eocz_mask = BIT(data->hwdata->eocz_bit);
+	level &= 1;
+	level *= eocz_mask;
+
+	expire = ktime_add_ns(ktime_get(), max_delay);
+	timeout = ktime_set(0, min_delay);
+	__set_current_state(TASK_INTERRUPTIBLE);
+	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
+	do {
+		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
+		if ((temp_sensor_reg & eocz_mask) = level)
+			break;
+	} while (ktime_us_delta(expire, ktime_get()) > 0);
+
+	return (temp_sensor_reg & eocz_mask) = level;
+}
+
+static int omap3_temp_update(struct omap3_temp_data *data)
+{
+	int e = 0;
+	u32 temp_sensor_reg;
+	u32 soc_mask = BIT(data->hwdata->soc_bit);
+
+	mutex_lock(&data->update_lock);
+
+	if (!data->valid || time_after(jiffies, data->last_updated + HZ)) {
+		clk_enable(data->clk_32k);
+
+		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
+				   soc_mask, soc_mask);
+
+		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
+		    EOCZ_MAX_RISING_DELAY, 1, data)) {
+			e = -EIO;
+			goto err;
+		}
+
+		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
+
+		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
+		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
+			e = -EIO;
+			goto err;
+		}
+
+		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
+		data->temperature = temp_sensor_reg & ((1<<7) - 1);
+		data->last_updated = jiffies;
+		data->valid = true;
+
+err:
+		clk_disable(data->clk_32k);
+	}
+
+	mutex_unlock(&data->update_lock);
+	return e;
+}
+
+static ssize_t show_temp(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap3_temp_data *data = dev_get_drvdata(dev);
+	int temp;
+	int ret;
+
+	ret = omap3_temp_update(data);
+	if (ret < 0)
+		return ret;
+
+	temp = data->hwdata->adc_to_temp[data->temperature];
+
+	return sprintf(buf, "%d.%d\n", temp / 10, temp % 10);
+}
+
+static ssize_t show_name(struct device *dev,
+			 struct device_attribute *devattr, char *buf)
+{
+	struct omap3_temp_data *data = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%s\n", data->name);
+}
+
+static SENSOR_DEVICE_ATTR_2(temp_input, S_IRUGO, show_temp, NULL, 0, 0);
+static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
+
+static const struct of_device_id omap3_temp_dt_ids[] = {
+	{
+		.compatible = "ti,omap34xx-temperature-sensor",
+		.data = &omap34xx_temp_type,
+	},
+	{
+		.compatible = "ti,omap36xx-temperature-sensor",
+		.data = &omap36xx_temp_type,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, omap3_temp_dt_ids);
+
+static int omap3_temp_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct omap3_temp_data *data;
+	const struct of_device_id *of_id;
+	int err;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	of_id = of_match_device(omap3_temp_dt_ids, &pdev->dev);
+	if (!of_id) {
+		dev_warn(&pdev->dev, "unsupported device!");
+		return -ENODEV;
+	}
+
+	mutex_init(&data->update_lock);
+	data->name = "omap3-temperature";
+
+	data->clk_32k = devm_clk_get(&pdev->dev, "fck");
+	if (IS_ERR(data->clk_32k))
+		return PTR_ERR(data->clk_32k);
+
+	data->hwdata = (struct omap3_temp_type *)of_id->data;
+
+	data->syscon = syscon_regmap_lookup_by_phandle(np, "syscon");
+	if (IS_ERR(data->syscon))
+		return PTR_ERR(data->syscon);
+
+	platform_set_drvdata(pdev, data);
+
+	err = device_create_file(&pdev->dev,
+				 &sensor_dev_attr_temp_input.dev_attr);
+	if (err)
+		goto fail_temp_file;
+
+	err = device_create_file(&pdev->dev, &dev_attr_name);
+	if (err)
+		goto fail_name_file;
+
+	data->hwmon_dev = hwmon_device_register(&pdev->dev);
+	if (IS_ERR(data->hwmon_dev)) {
+		err = PTR_ERR(data->hwmon_dev);
+		goto fail_hwmon_reg;
+	}
+
+	return 0;
+
+fail_hwmon_reg:
+	device_remove_file(&pdev->dev, &dev_attr_name);
+fail_name_file:
+	device_remove_file(&pdev->dev, &sensor_dev_attr_temp_input.dev_attr);
+fail_temp_file:
+	return err;
+}
+
+static int omap3_temp_remove(struct platform_device *pdev)
+{
+	struct omap3_temp_data *data = platform_get_drvdata(pdev);
+
+	if (!data)
+		return 0;
+
+	hwmon_device_unregister(data->hwmon_dev);
+	device_remove_file(&pdev->dev, &dev_attr_name);
+	device_remove_file(&pdev->dev, &sensor_dev_attr_temp_input.dev_attr);
+
+	return 0;
+}
+
+static struct platform_driver omap3_temp_driver = {
+	.probe	= omap3_temp_probe,
+	.remove	= omap3_temp_remove,
+	.driver = {
+		.name	= "omap3-temperature",
+		.of_match_table	= omap3_temp_dt_ids,
+	},
+};
+
+module_platform_driver(omap3_temp_driver);
+
+MODULE_AUTHOR("Sebastian Reichel");
+MODULE_DESCRIPTION("OMAP34xx/OMAP36xx temperature sensor");
+MODULE_LICENSE("GPL");
-- 
2.1.3


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor
  2014-12-26 12:34   ` Sebastian Reichel
  (?)
@ 2014-12-26 12:34     ` Sebastian Reichel
  -1 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel, linux-arm-kernel, linux-omap, lm-sensors,
	devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
	Kumar Gala

OMAP34xx and OMAP36xx processors contain a register in the
syscon area, which can be used to determine the SoCs temperature.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 arch/arm/boot/dts/omap34xx.dtsi | 7 +++++++
 arch/arm/boot/dts/omap36xx.dtsi | 7 +++++++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 3819c1e..64679ee 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -38,6 +38,13 @@
 			pinctrl-single,function-mask = <0xff1f>;
 		};
 	};
+
+	omap3_temperature_sensor: temperature-sensor {
+		compatible = "ti,omap34xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
 };
 
 &ssi {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 541704a..be9ee1d 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -70,6 +70,13 @@
 			pinctrl-single,function-mask = <0xff1f>;
 		};
 	};
+
+	omap3_temperature_sensor: temperature-sensor {
+		compatible = "ti,omap36xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
 };
 
 /* OMAP3630 needs dss_96m_fck for VENC */
-- 
2.1.3


^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor
@ 2014-12-26 12:34     ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: linux-arm-kernel

OMAP34xx and OMAP36xx processors contain a register in the
syscon area, which can be used to determine the SoCs temperature.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 arch/arm/boot/dts/omap34xx.dtsi | 7 +++++++
 arch/arm/boot/dts/omap36xx.dtsi | 7 +++++++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 3819c1e..64679ee 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -38,6 +38,13 @@
 			pinctrl-single,function-mask = <0xff1f>;
 		};
 	};
+
+	omap3_temperature_sensor: temperature-sensor {
+		compatible = "ti,omap34xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
 };
 
 &ssi {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 541704a..be9ee1d 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -70,6 +70,13 @@
 			pinctrl-single,function-mask = <0xff1f>;
 		};
 	};
+
+	omap3_temperature_sensor: temperature-sensor {
+		compatible = "ti,omap36xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
 };
 
 /* OMAP3630 needs dss_96m_fck for VENC */
-- 
2.1.3

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [lm-sensors] [PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor
@ 2014-12-26 12:34     ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 12:34 UTC (permalink / raw)
  To: Sebastian Reichel, Pavel Machek, Pali Rohar, Jean Delvare,
	Guenter Roeck, Tony Lindgren, Benoît Cousson
  Cc: linux-kernel, linux-arm-kernel, linux-omap, lm-sensors,
	devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
	Kumar Gala

OMAP34xx and OMAP36xx processors contain a register in the
syscon area, which can be used to determine the SoCs temperature.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 arch/arm/boot/dts/omap34xx.dtsi | 7 +++++++
 arch/arm/boot/dts/omap36xx.dtsi | 7 +++++++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 3819c1e..64679ee 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -38,6 +38,13 @@
 			pinctrl-single,function-mask = <0xff1f>;
 		};
 	};
+
+	omap3_temperature_sensor: temperature-sensor {
+		compatible = "ti,omap34xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
 };
 
 &ssi {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 541704a..be9ee1d 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -70,6 +70,13 @@
 			pinctrl-single,function-mask = <0xff1f>;
 		};
 	};
+
+	omap3_temperature_sensor: temperature-sensor {
+		compatible = "ti,omap36xx-temperature-sensor";
+		syscon = <&omap3_scm_general>;
+		clocks = <&ts_fck>;
+		clock-names = "fck";
+	};
 };
 
 /* OMAP3630 needs dss_96m_fck for VENC */
-- 
2.1.3


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [PATCH] add omap34xx temperature monitoring support
  2014-12-26 10:29 ` Pavel Machek
  (?)
@ 2014-12-26 15:54   ` Tony Lindgren
  -1 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 15:54 UTC (permalink / raw)
  To: Pavel Machek
  Cc: pali.rohar, sre, sre, kernel list, linux-arm-kernel, linux-omap,
	khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare, linux,
	lm-sensors

* Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> --- /dev/null
> +++ b/drivers/hwmon/omap34xx_temp.c
> @@ -0,0 +1,263 @@
> +/*
> + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
> + *
> + * Inspired by k8temp.c
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License. See the file "COPYING" in the main directory of this
> + * archive for more details.
> + *
> + * 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.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/hrtimer.h>
> +#include <linux/module.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +
> +#include "../../arch/arm/mach-omap2/control.h"

No need to do this, you can use syscon here like pbias-regulator.c
is doing.

Regards,

Tony

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 15:54   ` Tony Lindgren
  0 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 15:54 UTC (permalink / raw)
  To: linux-arm-kernel

* Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> --- /dev/null
> +++ b/drivers/hwmon/omap34xx_temp.c
> @@ -0,0 +1,263 @@
> +/*
> + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
> + *
> + * Inspired by k8temp.c
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License. See the file "COPYING" in the main directory of this
> + * archive for more details.
> + *
> + * 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.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/hrtimer.h>
> +#include <linux/module.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +
> +#include "../../arch/arm/mach-omap2/control.h"

No need to do this, you can use syscon here like pbias-regulator.c
is doing.

Regards,

Tony

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 15:54   ` Tony Lindgren
  0 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 15:54 UTC (permalink / raw)
  To: Pavel Machek
  Cc: pali.rohar, sre, sre, kernel list, linux-arm-kernel, linux-omap,
	khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare, linux,
	lm-sensors

* Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> --- /dev/null
> +++ b/drivers/hwmon/omap34xx_temp.c
> @@ -0,0 +1,263 @@
> +/*
> + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
> + *
> + * Inspired by k8temp.c
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License. See the file "COPYING" in the main directory of this
> + * archive for more details.
> + *
> + * 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.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/hrtimer.h>
> +#include <linux/module.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +
> +#include "../../arch/arm/mach-omap2/control.h"

No need to do this, you can use syscon here like pbias-regulator.c
is doing.

Regards,

Tony

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH] add omap34xx temperature monitoring support
  2014-12-26 15:54   ` Tony Lindgren
  (?)
@ 2014-12-26 16:17     ` Tony Lindgren
  -1 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 16:17 UTC (permalink / raw)
  To: Pavel Machek
  Cc: pali.rohar, sre, sre, kernel list, linux-arm-kernel, linux-omap,
	khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare, linux,
	lm-sensors

* Tony Lindgren <tony@atomide.com> [141226 07:57]:
> * Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> > --- /dev/null
> > +++ b/drivers/hwmon/omap34xx_temp.c
> > @@ -0,0 +1,263 @@
> > +/*
> > + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
> > + *
> > + * Copyright (C) 2008 Nokia Corporation
> > + *
> > + * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
> > + *
> > + * Inspired by k8temp.c
> > + *
> > + * This file is subject to the terms and conditions of the GNU General
> > + * Public License. See the file "COPYING" in the main directory of this
> > + * archive for more details.
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/hrtimer.h>
> > +#include <linux/module.h>
> > +#include <linux/hwmon.h>
> > +#include <linux/hwmon-sysfs.h>
> > +#include <linux/err.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/io.h>
> > +#include <linux/slab.h>
> > +
> > +#include "../../arch/arm/mach-omap2/control.h"
> 
> No need to do this, you can use syscon here like pbias-regulator.c
> is doing.

Oh looks like you're already using syscon, nice. What defines do you
need from control.h?

Those should be in the driver if private to the driver, or else we
should have some minimal header in include/linux somewhere if some
control.h defines really need to be exposed.

Regards,

Tony

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 16:17     ` Tony Lindgren
  0 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 16:17 UTC (permalink / raw)
  To: linux-arm-kernel

* Tony Lindgren <tony@atomide.com> [141226 07:57]:
> * Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> > --- /dev/null
> > +++ b/drivers/hwmon/omap34xx_temp.c
> > @@ -0,0 +1,263 @@
> > +/*
> > + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
> > + *
> > + * Copyright (C) 2008 Nokia Corporation
> > + *
> > + * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
> > + *
> > + * Inspired by k8temp.c
> > + *
> > + * This file is subject to the terms and conditions of the GNU General
> > + * Public License. See the file "COPYING" in the main directory of this
> > + * archive for more details.
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/hrtimer.h>
> > +#include <linux/module.h>
> > +#include <linux/hwmon.h>
> > +#include <linux/hwmon-sysfs.h>
> > +#include <linux/err.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/io.h>
> > +#include <linux/slab.h>
> > +
> > +#include "../../arch/arm/mach-omap2/control.h"
> 
> No need to do this, you can use syscon here like pbias-regulator.c
> is doing.

Oh looks like you're already using syscon, nice. What defines do you
need from control.h?

Those should be in the driver if private to the driver, or else we
should have some minimal header in include/linux somewhere if some
control.h defines really need to be exposed.

Regards,

Tony

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 16:17     ` Tony Lindgren
  0 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 16:17 UTC (permalink / raw)
  To: Pavel Machek
  Cc: pali.rohar, sre, sre, kernel list, linux-arm-kernel, linux-omap,
	khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare, linux,
	lm-sensors

* Tony Lindgren <tony@atomide.com> [141226 07:57]:
> * Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> > --- /dev/null
> > +++ b/drivers/hwmon/omap34xx_temp.c
> > @@ -0,0 +1,263 @@
> > +/*
> > + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
> > + *
> > + * Copyright (C) 2008 Nokia Corporation
> > + *
> > + * Written by Peter De Schrijver <peter.de-schrijver@nokia.com>
> > + *
> > + * Inspired by k8temp.c
> > + *
> > + * This file is subject to the terms and conditions of the GNU General
> > + * Public License. See the file "COPYING" in the main directory of this
> > + * archive for more details.
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/hrtimer.h>
> > +#include <linux/module.h>
> > +#include <linux/hwmon.h>
> > +#include <linux/hwmon-sysfs.h>
> > +#include <linux/err.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/io.h>
> > +#include <linux/slab.h>
> > +
> > +#include "../../arch/arm/mach-omap2/control.h"
> 
> No need to do this, you can use syscon here like pbias-regulator.c
> is doing.

Oh looks like you're already using syscon, nice. What defines do you
need from control.h?

Those should be in the driver if private to the driver, or else we
should have some minimal header in include/linux somewhere if some
control.h defines really need to be exposed.

Regards,

Tony

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH] add omap34xx temperature monitoring support
  2014-12-26 16:17     ` Tony Lindgren
  (?)
@ 2014-12-26 16:26       ` Pali Rohár
  -1 siblings, 0 replies; 115+ messages in thread
From: Pali Rohár @ 2014-12-26 16:26 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Pavel Machek, sre, sre, kernel list, linux-arm-kernel,
	linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare,
	linux, lm-sensors

[-- Attachment #1: Type: Text/Plain, Size: 2049 bytes --]

On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [141226 07:57]:
> > * Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> > > --- /dev/null
> > > +++ b/drivers/hwmon/omap34xx_temp.c
> > > @@ -0,0 +1,263 @@
> > > +/*
> > > + * omap34xx_temp.c - Linux kernel module for OMAP34xx
> > > hardware monitoring + *
> > > + * Copyright (C) 2008 Nokia Corporation
> > > + *
> > > + * Written by Peter De Schrijver
> > > <peter.de-schrijver@nokia.com> + *
> > > + * Inspired by k8temp.c
> > > + *
> > > + * This file is subject to the terms and conditions of
> > > the GNU General + * Public License. See the file
> > > "COPYING" in the main directory of this + * archive for
> > > more details.
> > > + *
> > > + * 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.
> > > + */
> > > +
> > > +#include <linux/clk.h>
> > > +#include <linux/hrtimer.h>
> > > +#include <linux/module.h>
> > > +#include <linux/hwmon.h>
> > > +#include <linux/hwmon-sysfs.h>
> > > +#include <linux/err.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/io.h>
> > > +#include <linux/slab.h>
> > > +
> > > +#include "../../arch/arm/mach-omap2/control.h"
> > 
> > No need to do this, you can use syscon here like
> > pbias-regulator.c is doing.
> 
> Oh looks like you're already using syscon, nice. What defines
> do you need from control.h?
> 
> Those should be in the driver if private to the driver, or
> else we should have some minimal header in include/linux
> somewhere if some control.h defines really need to be
> exposed.
> 
> Regards,
> 
> Tony

Hi Tony,

Sebastian Reichel has already sent new version of temperature 
driver. See email thread with subject:

[PATCH 0/3] OMAP3 temperature sensor

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 16:26       ` Pali Rohár
  0 siblings, 0 replies; 115+ messages in thread
From: Pali Rohár @ 2014-12-26 16:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [141226 07:57]:
> > * Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> > > --- /dev/null
> > > +++ b/drivers/hwmon/omap34xx_temp.c
> > > @@ -0,0 +1,263 @@
> > > +/*
> > > + * omap34xx_temp.c - Linux kernel module for OMAP34xx
> > > hardware monitoring + *
> > > + * Copyright (C) 2008 Nokia Corporation
> > > + *
> > > + * Written by Peter De Schrijver
> > > <peter.de-schrijver@nokia.com> + *
> > > + * Inspired by k8temp.c
> > > + *
> > > + * This file is subject to the terms and conditions of
> > > the GNU General + * Public License. See the file
> > > "COPYING" in the main directory of this + * archive for
> > > more details.
> > > + *
> > > + * 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.
> > > + */
> > > +
> > > +#include <linux/clk.h>
> > > +#include <linux/hrtimer.h>
> > > +#include <linux/module.h>
> > > +#include <linux/hwmon.h>
> > > +#include <linux/hwmon-sysfs.h>
> > > +#include <linux/err.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/io.h>
> > > +#include <linux/slab.h>
> > > +
> > > +#include "../../arch/arm/mach-omap2/control.h"
> > 
> > No need to do this, you can use syscon here like
> > pbias-regulator.c is doing.
> 
> Oh looks like you're already using syscon, nice. What defines
> do you need from control.h?
> 
> Those should be in the driver if private to the driver, or
> else we should have some minimal header in include/linux
> somewhere if some control.h defines really need to be
> exposed.
> 
> Regards,
> 
> Tony

Hi Tony,

Sebastian Reichel has already sent new version of temperature 
driver. See email thread with subject:

[PATCH 0/3] OMAP3 temperature sensor

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141226/daf8e6ad/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 16:26       ` Pali Rohár
  0 siblings, 0 replies; 115+ messages in thread
From: Pali Rohár @ 2014-12-26 16:26 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Pavel Machek, sre, sre, kernel list, linux-arm-kernel,
	linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare,
	linux, lm-sensors


[-- Attachment #1.1: Type: Text/Plain, Size: 2049 bytes --]

On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [141226 07:57]:
> > * Pavel Machek <pavel@ucw.cz> [141226 02:32]:
> > > --- /dev/null
> > > +++ b/drivers/hwmon/omap34xx_temp.c
> > > @@ -0,0 +1,263 @@
> > > +/*
> > > + * omap34xx_temp.c - Linux kernel module for OMAP34xx
> > > hardware monitoring + *
> > > + * Copyright (C) 2008 Nokia Corporation
> > > + *
> > > + * Written by Peter De Schrijver
> > > <peter.de-schrijver@nokia.com> + *
> > > + * Inspired by k8temp.c
> > > + *
> > > + * This file is subject to the terms and conditions of
> > > the GNU General + * Public License. See the file
> > > "COPYING" in the main directory of this + * archive for
> > > more details.
> > > + *
> > > + * 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.
> > > + */
> > > +
> > > +#include <linux/clk.h>
> > > +#include <linux/hrtimer.h>
> > > +#include <linux/module.h>
> > > +#include <linux/hwmon.h>
> > > +#include <linux/hwmon-sysfs.h>
> > > +#include <linux/err.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/io.h>
> > > +#include <linux/slab.h>
> > > +
> > > +#include "../../arch/arm/mach-omap2/control.h"
> > 
> > No need to do this, you can use syscon here like
> > pbias-regulator.c is doing.
> 
> Oh looks like you're already using syscon, nice. What defines
> do you need from control.h?
> 
> Those should be in the driver if private to the driver, or
> else we should have some minimal header in include/linux
> somewhere if some control.h defines really need to be
> exposed.
> 
> Regards,
> 
> Tony

Hi Tony,

Sebastian Reichel has already sent new version of temperature 
driver. See email thread with subject:

[PATCH 0/3] OMAP3 temperature sensor

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH] add omap34xx temperature monitoring support
  2014-12-26 16:26       ` Pali Rohár
  (?)
@ 2014-12-26 16:31         ` Tony Lindgren
  -1 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 16:31 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Pavel Machek, sre, sre, kernel list, linux-arm-kernel,
	linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare,
	linux, lm-sensors

* Pali Rohár <pali.rohar@gmail.com> [141226 08:29]:
> On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
> > > > +
> > > > +#include "../../arch/arm/mach-omap2/control.h"
> > > 
> > > No need to do this, you can use syscon here like
> > > pbias-regulator.c is doing.
> > 
> > Oh looks like you're already using syscon, nice. What defines
> > do you need from control.h?
> > 
> > Those should be in the driver if private to the driver, or
> > else we should have some minimal header in include/linux
> > somewhere if some control.h defines really need to be
> > exposed.
> > 
> > Regards,
> > 
> > Tony
> 
> Hi Tony,
> 
> Sebastian Reichel has already sent new version of temperature 
> driver. See email thread with subject:
> 
> [PATCH 0/3] OMAP3 temperature sensor

Yeah great, looks like I was also reading Sebastian's patch
with the syscon comments above :)

Regards,

Tony

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 16:31         ` Tony Lindgren
  0 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 16:31 UTC (permalink / raw)
  To: linux-arm-kernel

* Pali Roh?r <pali.rohar@gmail.com> [141226 08:29]:
> On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
> > > > +
> > > > +#include "../../arch/arm/mach-omap2/control.h"
> > > 
> > > No need to do this, you can use syscon here like
> > > pbias-regulator.c is doing.
> > 
> > Oh looks like you're already using syscon, nice. What defines
> > do you need from control.h?
> > 
> > Those should be in the driver if private to the driver, or
> > else we should have some minimal header in include/linux
> > somewhere if some control.h defines really need to be
> > exposed.
> > 
> > Regards,
> > 
> > Tony
> 
> Hi Tony,
> 
> Sebastian Reichel has already sent new version of temperature 
> driver. See email thread with subject:
> 
> [PATCH 0/3] OMAP3 temperature sensor

Yeah great, looks like I was also reading Sebastian's patch
with the syscon comments above :)

Regards,

Tony

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH] add omap34xx temperature monitoring support
@ 2014-12-26 16:31         ` Tony Lindgren
  0 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2014-12-26 16:31 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Pavel Machek, sre, sre, kernel list, linux-arm-kernel,
	linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, jdelvare,
	linux, lm-sensors

KiBQYWxpIFJvaMOhciA8cGFsaS5yb2hhckBnbWFpbC5jb20+IFsxNDEyMjYgMDg6MjldOgo+IE9u
IEZyaWRheSAyNiBEZWNlbWJlciAyMDE0IDE3OjE3OjU3IFRvbnkgTGluZGdyZW4gd3JvdGU6Cj4g
PiA+ID4gKwo+ID4gPiA+ICsjaW5jbHVkZSAiLi4vLi4vYXJjaC9hcm0vbWFjaC1vbWFwMi9jb250
cm9sLmgiCj4gPiA+IAo+ID4gPiBObyBuZWVkIHRvIGRvIHRoaXMsIHlvdSBjYW4gdXNlIHN5c2Nv
biBoZXJlIGxpa2UKPiA+ID4gcGJpYXMtcmVndWxhdG9yLmMgaXMgZG9pbmcuCj4gPiAKPiA+IE9o
IGxvb2tzIGxpa2UgeW91J3JlIGFscmVhZHkgdXNpbmcgc3lzY29uLCBuaWNlLiBXaGF0IGRlZmlu
ZXMKPiA+IGRvIHlvdSBuZWVkIGZyb20gY29udHJvbC5oPwo+ID4gCj4gPiBUaG9zZSBzaG91bGQg
YmUgaW4gdGhlIGRyaXZlciBpZiBwcml2YXRlIHRvIHRoZSBkcml2ZXIsIG9yCj4gPiBlbHNlIHdl
IHNob3VsZCBoYXZlIHNvbWUgbWluaW1hbCBoZWFkZXIgaW4gaW5jbHVkZS9saW51eAo+ID4gc29t
ZXdoZXJlIGlmIHNvbWUgY29udHJvbC5oIGRlZmluZXMgcmVhbGx5IG5lZWQgdG8gYmUKPiA+IGV4
cG9zZWQuCj4gPiAKPiA+IFJlZ2FyZHMsCj4gPiAKPiA+IFRvbnkKPiAKPiBIaSBUb255LAo+IAo+
IFNlYmFzdGlhbiBSZWljaGVsIGhhcyBhbHJlYWR5IHNlbnQgbmV3IHZlcnNpb24gb2YgdGVtcGVy
YXR1cmUgCj4gZHJpdmVyLiBTZWUgZW1haWwgdGhyZWFkIHdpdGggc3ViamVjdDoKPiAKPiBbUEFU
Q0ggMC8zXSBPTUFQMyB0ZW1wZXJhdHVyZSBzZW5zb3IKClllYWggZ3JlYXQsIGxvb2tzIGxpa2Ug
SSB3YXMgYWxzbyByZWFkaW5nIFNlYmFzdGlhbidzIHBhdGNoCndpdGggdGhlIHN5c2NvbiBjb21t
ZW50cyBhYm92ZSA6KQoKUmVnYXJkcywKClRvbnkKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNA
bG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGlu
Zm8vbG0tc2Vuc29ycw=

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 17:19       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 17:19 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
>  .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> new file mode 100644
> index 0000000..99631ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> @@ -0,0 +1,25 @@
> +* OMAP3 temperature sensor
> +
> +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> +which can be used to determine the SoCs temperature.
> +
> +Requires node properties:
> +- compatible :	should contain one of
> +	- "ti,omap34xx-temperature-sensor" for OMAP34xx
> +	- "ti,omap36xx-temperature-sensor" for OMAP36xx
> +- syscon :	Should be a phandle to system configuration node which
> +		encompases the temperature register
> +- clocks :	Should contain 32KHz fclk clock specifier
> +- clock-names :	Should contain clock names
> +	- "fck" for the 32KHz fclk clock specifier

I don't quite get it. The temperature sensor is internal on the CPU,
right? Why do we need device tree to describe it? As soon as we have
CPU that is compatible to ti,omap3430, we know everything we need to
know, no?

> +Example for omap34xx:
> +
> +/ {
> +	temperature-sensor {
> +		compatible = "ti,omap34xx-temperature-sensor";
> +		syscon = <&omap3_scm_general>;
> +		clocks = <&ts_fck>;
> +		clock-names = "fck";
> +	};
> +};

Or is there something that depends on the board there? Or do we want
to do it like this to be consistent with existing bindings?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 17:19       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 17:19 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
> 
> Signed-off-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>  .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> new file mode 100644
> index 0000000..99631ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> @@ -0,0 +1,25 @@
> +* OMAP3 temperature sensor
> +
> +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> +which can be used to determine the SoCs temperature.
> +
> +Requires node properties:
> +- compatible :	should contain one of
> +	- "ti,omap34xx-temperature-sensor" for OMAP34xx
> +	- "ti,omap36xx-temperature-sensor" for OMAP36xx
> +- syscon :	Should be a phandle to system configuration node which
> +		encompases the temperature register
> +- clocks :	Should contain 32KHz fclk clock specifier
> +- clock-names :	Should contain clock names
> +	- "fck" for the 32KHz fclk clock specifier

I don't quite get it. The temperature sensor is internal on the CPU,
right? Why do we need device tree to describe it? As soon as we have
CPU that is compatible to ti,omap3430, we know everything we need to
know, no?

> +Example for omap34xx:
> +
> +/ {
> +	temperature-sensor {
> +		compatible = "ti,omap34xx-temperature-sensor";
> +		syscon = <&omap3_scm_general>;
> +		clocks = <&ts_fck>;
> +		clock-names = "fck";
> +	};
> +};

Or is there something that depends on the board there? Or do we want
to do it like this to be consistent with existing bindings?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 17:19       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 17:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
>  .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> new file mode 100644
> index 0000000..99631ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> @@ -0,0 +1,25 @@
> +* OMAP3 temperature sensor
> +
> +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> +which can be used to determine the SoCs temperature.
> +
> +Requires node properties:
> +- compatible :	should contain one of
> +	- "ti,omap34xx-temperature-sensor" for OMAP34xx
> +	- "ti,omap36xx-temperature-sensor" for OMAP36xx
> +- syscon :	Should be a phandle to system configuration node which
> +		encompases the temperature register
> +- clocks :	Should contain 32KHz fclk clock specifier
> +- clock-names :	Should contain clock names
> +	- "fck" for the 32KHz fclk clock specifier

I don't quite get it. The temperature sensor is internal on the CPU,
right? Why do we need device tree to describe it? As soon as we have
CPU that is compatible to ti,omap3430, we know everything we need to
know, no?

> +Example for omap34xx:
> +
> +/ {
> +	temperature-sensor {
> +		compatible = "ti,omap34xx-temperature-sensor";
> +		syscon = <&omap3_scm_general>;
> +		clocks = <&ts_fck>;
> +		clock-names = "fck";
> +	};
> +};

Or is there something that depends on the board there? Or do we want
to do it like this to be consistent with existing bindings?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 17:19       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 17:19 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
>  .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> new file mode 100644
> index 0000000..99631ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> @@ -0,0 +1,25 @@
> +* OMAP3 temperature sensor
> +
> +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> +which can be used to determine the SoCs temperature.
> +
> +Requires node properties:
> +- compatible :	should contain one of
> +	- "ti,omap34xx-temperature-sensor" for OMAP34xx
> +	- "ti,omap36xx-temperature-sensor" for OMAP36xx
> +- syscon :	Should be a phandle to system configuration node which
> +		encompases the temperature register
> +- clocks :	Should contain 32KHz fclk clock specifier
> +- clock-names :	Should contain clock names
> +	- "fck" for the 32KHz fclk clock specifier

I don't quite get it. The temperature sensor is internal on the CPU,
right? Why do we need device tree to describe it? As soon as we have
CPU that is compatible to ti,omap3430, we know everything we need to
know, no?

> +Example for omap34xx:
> +
> +/ {
> +	temperature-sensor {
> +		compatible = "ti,omap34xx-temperature-sensor";
> +		syscon = <&omap3_scm_general>;
> +		clocks = <&ts_fck>;
> +		clock-names = "fck";
> +	};
> +};

Or is there something that depends on the board there? Or do we want
to do it like this to be consistent with existing bindings?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-26 12:34     ` Sebastian Reichel
  (?)
@ 2014-12-26 17:26       ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 17:26 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

> +	if (!data->valid || time_after(jiffies, data->last_updated + HZ)) {
> +		clk_enable(data->clk_32k);

This needs to be clk_prepare_enable()

> +		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
> +				   soc_mask, soc_mask);
> +
> +		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
> +		    EOCZ_MAX_RISING_DELAY, 1, data)) {
> +			e = -EIO;
> +			goto err;
> +		}
> +
> +		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
> +
> +		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
> +		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
> +			e = -EIO;
> +			goto err;
> +		}
> +
> +		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> +		data->temperature = temp_sensor_reg & ((1<<7) - 1);
> +		data->last_updated = jiffies;
> +		data->valid = true;
> +
> +err:
> +		clk_disable(data->clk_32k);

And this clk_disable_unprepare().

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-26 17:26       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 17:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

> +	if (!data->valid || time_after(jiffies, data->last_updated + HZ)) {
> +		clk_enable(data->clk_32k);

This needs to be clk_prepare_enable()

> +		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
> +				   soc_mask, soc_mask);
> +
> +		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
> +		    EOCZ_MAX_RISING_DELAY, 1, data)) {
> +			e = -EIO;
> +			goto err;
> +		}
> +
> +		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
> +
> +		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
> +		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
> +			e = -EIO;
> +			goto err;
> +		}
> +
> +		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> +		data->temperature = temp_sensor_reg & ((1<<7) - 1);
> +		data->last_updated = jiffies;
> +		data->valid = true;
> +
> +err:
> +		clk_disable(data->clk_32k);

And this clk_disable_unprepare().

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-26 17:26       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-26 17:26 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

> +	if (!data->valid || time_after(jiffies, data->last_updated + HZ)) {
> +		clk_enable(data->clk_32k);

This needs to be clk_prepare_enable()

> +		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
> +				   soc_mask, soc_mask);
> +
> +		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
> +		    EOCZ_MAX_RISING_DELAY, 1, data)) {
> +			e = -EIO;
> +			goto err;
> +		}
> +
> +		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
> +
> +		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
> +		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
> +			e = -EIO;
> +			goto err;
> +		}
> +
> +		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> +		data->temperature = temp_sensor_reg & ((1<<7) - 1);
> +		data->last_updated = jiffies;
> +		data->valid = true;
> +
> +err:
> +		clk_disable(data->clk_32k);

And this clk_disable_unprepare().

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 1/3] DT Binding for omap3 temperature sensor
  2014-12-26 17:19       ` Pavel Machek
  (?)
  (?)
@ 2014-12-26 23:50         ` Sebastian Reichel
  -1 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 23:50 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]

Hi Pavel,

On Fri, Dec 26, 2014 at 06:19:44PM +0100, Pavel Machek wrote:
> On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > which can be used to determine the SoCs temperature. This provides a
> > DT binding specification for the temperature monitor.
> > 
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
> >  .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > new file mode 100644
> > index 0000000..99631ad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > @@ -0,0 +1,25 @@
> > +* OMAP3 temperature sensor
> > +
> > +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > +which can be used to determine the SoCs temperature.
> > +
> > +Requires node properties:
> > +- compatible :	should contain one of
> > +	- "ti,omap34xx-temperature-sensor" for OMAP34xx
> > +	- "ti,omap36xx-temperature-sensor" for OMAP36xx
> > +- syscon :	Should be a phandle to system configuration node which
> > +		encompases the temperature register
> > +- clocks :	Should contain 32KHz fclk clock specifier
> > +- clock-names :	Should contain clock names
> > +	- "fck" for the 32KHz fclk clock specifier
> 
> I don't quite get it. The temperature sensor is internal on the CPU,
> right? Why do we need device tree to describe it? As soon as we have
> CPU that is compatible to ti,omap3430, we know everything we need to
> know, no?

Lots of stuff is SoC internal and described in the DT (e.g. serial
controllers). Just have a look in omap3.dtsi or omap34xx.dtsi.

I put the temperature sensor into its own node for the following
reasons:

 * syscon reference
 * clock reference

I first thought about loading the driver from the syscon driver,
but omap uses a generic one, so that's not an option. Apart from
that one would still need the clock reference.

> > +Example for omap34xx:
> > +
> > +/ {
> > +	temperature-sensor {
> > +		compatible = "ti,omap34xx-temperature-sensor";
> > +		syscon = <&omap3_scm_general>;
> > +		clocks = <&ts_fck>;
> > +		clock-names = "fck";
> > +	};
> > +};
> 
> Or is there something that depends on the board there? Or do we want
> to do it like this to be consistent with existing bindings?

This is SoC specific and should go into the omap34xx.dtsi and
omap36xx.dtsi files. See also PATCH 3/3.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 23:50         ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 23:50 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala

[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]

Hi Pavel,

On Fri, Dec 26, 2014 at 06:19:44PM +0100, Pavel Machek wrote:
> On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > which can be used to determine the SoCs temperature. This provides a
> > DT binding specification for the temperature monitor.
> > 
> > Signed-off-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > ---
> >  .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > new file mode 100644
> > index 0000000..99631ad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > @@ -0,0 +1,25 @@
> > +* OMAP3 temperature sensor
> > +
> > +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > +which can be used to determine the SoCs temperature.
> > +
> > +Requires node properties:
> > +- compatible :	should contain one of
> > +	- "ti,omap34xx-temperature-sensor" for OMAP34xx
> > +	- "ti,omap36xx-temperature-sensor" for OMAP36xx
> > +- syscon :	Should be a phandle to system configuration node which
> > +		encompases the temperature register
> > +- clocks :	Should contain 32KHz fclk clock specifier
> > +- clock-names :	Should contain clock names
> > +	- "fck" for the 32KHz fclk clock specifier
> 
> I don't quite get it. The temperature sensor is internal on the CPU,
> right? Why do we need device tree to describe it? As soon as we have
> CPU that is compatible to ti,omap3430, we know everything we need to
> know, no?

Lots of stuff is SoC internal and described in the DT (e.g. serial
controllers). Just have a look in omap3.dtsi or omap34xx.dtsi.

I put the temperature sensor into its own node for the following
reasons:

 * syscon reference
 * clock reference

I first thought about loading the driver from the syscon driver,
but omap uses a generic one, so that's not an option. Apart from
that one would still need the clock reference.

> > +Example for omap34xx:
> > +
> > +/ {
> > +	temperature-sensor {
> > +		compatible = "ti,omap34xx-temperature-sensor";
> > +		syscon = <&omap3_scm_general>;
> > +		clocks = <&ts_fck>;
> > +		clock-names = "fck";
> > +	};
> > +};
> 
> Or is there something that depends on the board there? Or do we want
> to do it like this to be consistent with existing bindings?

This is SoC specific and should go into the omap34xx.dtsi and
omap36xx.dtsi files. See also PATCH 3/3.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 23:50         ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 23:50 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Pavel,

On Fri, Dec 26, 2014 at 06:19:44PM +0100, Pavel Machek wrote:
> On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > which can be used to determine the SoCs temperature. This provides a
> > DT binding specification for the temperature monitor.
> > 
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
> >  .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > new file mode 100644
> > index 0000000..99631ad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > @@ -0,0 +1,25 @@
> > +* OMAP3 temperature sensor
> > +
> > +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > +which can be used to determine the SoCs temperature.
> > +
> > +Requires node properties:
> > +- compatible :	should contain one of
> > +	- "ti,omap34xx-temperature-sensor" for OMAP34xx
> > +	- "ti,omap36xx-temperature-sensor" for OMAP36xx
> > +- syscon :	Should be a phandle to system configuration node which
> > +		encompases the temperature register
> > +- clocks :	Should contain 32KHz fclk clock specifier
> > +- clock-names :	Should contain clock names
> > +	- "fck" for the 32KHz fclk clock specifier
> 
> I don't quite get it. The temperature sensor is internal on the CPU,
> right? Why do we need device tree to describe it? As soon as we have
> CPU that is compatible to ti,omap3430, we know everything we need to
> know, no?

Lots of stuff is SoC internal and described in the DT (e.g. serial
controllers). Just have a look in omap3.dtsi or omap34xx.dtsi.

I put the temperature sensor into its own node for the following
reasons:

 * syscon reference
 * clock reference

I first thought about loading the driver from the syscon driver,
but omap uses a generic one, so that's not an option. Apart from
that one would still need the clock reference.

> > +Example for omap34xx:
> > +
> > +/ {
> > +	temperature-sensor {
> > +		compatible = "ti,omap34xx-temperature-sensor";
> > +		syscon = <&omap3_scm_general>;
> > +		clocks = <&ts_fck>;
> > +		clock-names = "fck";
> > +	};
> > +};
> 
> Or is there something that depends on the board there? Or do we want
> to do it like this to be consistent with existing bindings?

This is SoC specific and should go into the omap34xx.dtsi and
omap36xx.dtsi files. See also PATCH 3/3.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141227/2b205907/attachment.sig>

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-26 23:50         ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-26 23:50 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala


[-- Attachment #1.1: Type: text/plain, Size: 2765 bytes --]

Hi Pavel,

On Fri, Dec 26, 2014 at 06:19:44PM +0100, Pavel Machek wrote:
> On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > which can be used to determine the SoCs temperature. This provides a
> > DT binding specification for the temperature monitor.
> > 
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
> >  .../bindings/hwmon/omap3-temperature.txt           | 25 ++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > new file mode 100644
> > index 0000000..99631ad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > @@ -0,0 +1,25 @@
> > +* OMAP3 temperature sensor
> > +
> > +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > +which can be used to determine the SoCs temperature.
> > +
> > +Requires node properties:
> > +- compatible :	should contain one of
> > +	- "ti,omap34xx-temperature-sensor" for OMAP34xx
> > +	- "ti,omap36xx-temperature-sensor" for OMAP36xx
> > +- syscon :	Should be a phandle to system configuration node which
> > +		encompases the temperature register
> > +- clocks :	Should contain 32KHz fclk clock specifier
> > +- clock-names :	Should contain clock names
> > +	- "fck" for the 32KHz fclk clock specifier
> 
> I don't quite get it. The temperature sensor is internal on the CPU,
> right? Why do we need device tree to describe it? As soon as we have
> CPU that is compatible to ti,omap3430, we know everything we need to
> know, no?

Lots of stuff is SoC internal and described in the DT (e.g. serial
controllers). Just have a look in omap3.dtsi or omap34xx.dtsi.

I put the temperature sensor into its own node for the following
reasons:

 * syscon reference
 * clock reference

I first thought about loading the driver from the syscon driver,
but omap uses a generic one, so that's not an option. Apart from
that one would still need the clock reference.

> > +Example for omap34xx:
> > +
> > +/ {
> > +	temperature-sensor {
> > +		compatible = "ti,omap34xx-temperature-sensor";
> > +		syscon = <&omap3_scm_general>;
> > +		clocks = <&ts_fck>;
> > +		clock-names = "fck";
> > +	};
> > +};
> 
> Or is there something that depends on the board there? Or do we want
> to do it like this to be consistent with existing bindings?

This is SoC specific and should go into the omap34xx.dtsi and
omap36xx.dtsi files. See also PATCH 3/3.

-- Sebastian

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor
@ 2014-12-27 19:09       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:09 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:54, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the
> syscon area, which can be used to determine the SoCs temperature.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Pavel Machek <pavel@ucw.cz>

Driver binds and does something, so binding works ok.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor
@ 2014-12-27 19:09       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:09 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:54, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the
> syscon area, which can be used to determine the SoCs temperature.
> 
> Signed-off-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Tested-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>

Driver binds and does something, so binding works ok.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor
@ 2014-12-27 19:09       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-12-26 13:34:54, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the
> syscon area, which can be used to determine the SoCs temperature.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Pavel Machek <pavel@ucw.cz>

Driver binds and does something, so binding works ok.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor
@ 2014-12-27 19:09       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:09 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:54, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the
> syscon area, which can be used to determine the SoCs temperature.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Pavel Machek <pavel@ucw.cz>

Driver binds and does something, so binding works ok.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-27 19:09       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:09 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

Acked-by: Pavel Machek <pavel@ucw.cz>
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-27 19:09       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:09 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
> 
> Signed-off-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-27 19:09       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

Acked-by: Pavel Machek <pavel@ucw.cz>
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 1/3] DT Binding for omap3 temperature sensor
@ 2014-12-27 19:09       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:09 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

Acked-by: Pavel Machek <pavel@ucw.cz>
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-26 12:34     ` Sebastian Reichel
  (?)
@ 2014-12-27 19:24       ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:24 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

Hi!


> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

I did clk_enable -> clk_prepare_enable conversion, as described in
another email.

I got occasional error reading:

root@n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
20.0
root@n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
cat: /sys/class/hwmon/hwmon0/device/temp_input: Input/output error
root@n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
20.0

Nothing in dmesg. It takes few tries to reproduce..

On other attempt, it hung hard:

root@n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input ; cat
/sys/class/hwmon/hwmon0/device/temp_input  ;cat
/sys/class/hwmon/hwmon0/device/temp_input ; cat
/sys/class/hwmon/hwmon0/device/temp_input
17.0
17.0
^[[A



^Z


^C^C^C

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:24       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:24 UTC (permalink / raw)
  To: linux-arm-kernel

Hi!


> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

I did clk_enable -> clk_prepare_enable conversion, as described in
another email.

I got occasional error reading:

root at n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
20.0
root at n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
cat: /sys/class/hwmon/hwmon0/device/temp_input: Input/output error
root at n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
20.0

Nothing in dmesg. It takes few tries to reproduce..

On other attempt, it hung hard:

root at n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input ; cat
/sys/class/hwmon/hwmon0/device/temp_input  ;cat
/sys/class/hwmon/hwmon0/device/temp_input ; cat
/sys/class/hwmon/hwmon0/device/temp_input
17.0
17.0
^[[A



^Z


^C^C^C

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:24       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:24 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

Hi!


> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

I did clk_enable -> clk_prepare_enable conversion, as described in
another email.

I got occasional error reading:

root@n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
20.0
root@n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
cat: /sys/class/hwmon/hwmon0/device/temp_input: Input/output error
root@n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input
20.0

Nothing in dmesg. It takes few tries to reproduce..

On other attempt, it hung hard:

root@n900:~# cat /sys/class/hwmon/hwmon0/device/temp_input ; cat
/sys/class/hwmon/hwmon0/device/temp_input  ;cat
/sys/class/hwmon/hwmon0/device/temp_input ; cat
/sys/class/hwmon/hwmon0/device/temp_input
17.0
17.0
^[[A



^Z


^C^C^C

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-26 12:34     ` Sebastian Reichel
  (?)
@ 2014-12-27 19:40       ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:40 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

I'd suggest these cleanups... But I don't see why it would fail. (Aha,
and sorry for trailing whitespace, you'll probably need to delete it.)

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
index afe1b5a..8a69604 100644
--- a/drivers/hwmon/omap3-temp.c
+++ b/drivers/hwmon/omap3-temp.c
@@ -35,21 +35,29 @@
 /* 32.768Khz clock speed in nano seconds */
 #define CLOCK_32K_SPEED_NS 30518
 
-/* minimum delay for EOCZ rise after SOC rise is
- * 11 cycles of the 32.768Khz clock */
+/*
+ * minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock
+ */
 #define EOCZ_MIN_RISING_DELAY (11 * CLOCK_32K_SPEED_NS)
 
-/* From docs, maximum delay for EOCZ rise after SOC rise is
+/*
+ * From docs, maximum delay for EOCZ rise after SOC rise is
  * 14 cycles of the 32.768Khz clock. But after some experiments,
- * 24 cycles as maximum is safer. */
+ * 24 cycles as maximum is safer.
+ */
 #define EOCZ_MAX_RISING_DELAY (24 * CLOCK_32K_SPEED_NS)
 
-/* minimum delay for EOCZ falling is
- * 36 cycles of the 32.768Khz clock */
+/*
+ * minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock 
+ */
 #define EOCZ_MIN_FALLING_DELAY (36 * CLOCK_32K_SPEED_NS)
 
-/* maximum delay for EOCZ falling is
- * 40 cycles of the 32.768Khz clock */
+/*
+ * maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock 
+ */
 #define EOCZ_MAX_FALLING_DELAY (40 * CLOCK_32K_SPEED_NS)
 
 /* temperature register offset in the syscon register area */
@@ -116,8 +124,8 @@ struct omap3_temp_data {
 	bool valid;
 };
 
-static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
-				struct omap3_temp_data *data)
+static inline bool wait_for_eocz(struct omap3_temp_data *data,
+				 int min_delay, int max_delay, u32 level)
 {
 	ktime_t timeout, expire;
 	u32 temp_sensor_reg, eocz_mask;
@@ -133,10 +141,10 @@ static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
 	do {
 		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
 		if ((temp_sensor_reg & eocz_mask) == level)
-			break;
+			return true;
 	} while (ktime_us_delta(expire, ktime_get()) > 0);
 
-	return (temp_sensor_reg & eocz_mask) == level;
+	return false;
 }
 
 static int omap3_temp_update(struct omap3_temp_data *data)
@@ -153,16 +161,16 @@ static int omap3_temp_update(struct omap3_temp_data *data)
 		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
 				   soc_mask, soc_mask);
 
-		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
-		    EOCZ_MAX_RISING_DELAY, 1, data)) {
+		if (!wait_for_eocz(data, EOCZ_MIN_RISING_DELAY,
+		    EOCZ_MAX_RISING_DELAY, 1)) {
 			e = -EIO;
 			goto err;
 		}
 
 		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
 
-		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
-		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
+		if (!wait_for_eocz(data, EOCZ_MIN_FALLING_DELAY,
+		    EOCZ_MAX_FALLING_DELAY, 0)) {
 			e = -EIO;
 			goto err;
 		}


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:40       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:40 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

I'd suggest these cleanups... But I don't see why it would fail. (Aha,
and sorry for trailing whitespace, you'll probably need to delete it.)

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
index afe1b5a..8a69604 100644
--- a/drivers/hwmon/omap3-temp.c
+++ b/drivers/hwmon/omap3-temp.c
@@ -35,21 +35,29 @@
 /* 32.768Khz clock speed in nano seconds */
 #define CLOCK_32K_SPEED_NS 30518
 
-/* minimum delay for EOCZ rise after SOC rise is
- * 11 cycles of the 32.768Khz clock */
+/*
+ * minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock
+ */
 #define EOCZ_MIN_RISING_DELAY (11 * CLOCK_32K_SPEED_NS)
 
-/* From docs, maximum delay for EOCZ rise after SOC rise is
+/*
+ * From docs, maximum delay for EOCZ rise after SOC rise is
  * 14 cycles of the 32.768Khz clock. But after some experiments,
- * 24 cycles as maximum is safer. */
+ * 24 cycles as maximum is safer.
+ */
 #define EOCZ_MAX_RISING_DELAY (24 * CLOCK_32K_SPEED_NS)
 
-/* minimum delay for EOCZ falling is
- * 36 cycles of the 32.768Khz clock */
+/*
+ * minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock 
+ */
 #define EOCZ_MIN_FALLING_DELAY (36 * CLOCK_32K_SPEED_NS)
 
-/* maximum delay for EOCZ falling is
- * 40 cycles of the 32.768Khz clock */
+/*
+ * maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock 
+ */
 #define EOCZ_MAX_FALLING_DELAY (40 * CLOCK_32K_SPEED_NS)
 
 /* temperature register offset in the syscon register area */
@@ -116,8 +124,8 @@ struct omap3_temp_data {
 	bool valid;
 };
 
-static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
-				struct omap3_temp_data *data)
+static inline bool wait_for_eocz(struct omap3_temp_data *data,
+				 int min_delay, int max_delay, u32 level)
 {
 	ktime_t timeout, expire;
 	u32 temp_sensor_reg, eocz_mask;
@@ -133,10 +141,10 @@ static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
 	do {
 		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
 		if ((temp_sensor_reg & eocz_mask) == level)
-			break;
+			return true;
 	} while (ktime_us_delta(expire, ktime_get()) > 0);
 
-	return (temp_sensor_reg & eocz_mask) == level;
+	return false;
 }
 
 static int omap3_temp_update(struct omap3_temp_data *data)
@@ -153,16 +161,16 @@ static int omap3_temp_update(struct omap3_temp_data *data)
 		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
 				   soc_mask, soc_mask);
 
-		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
-		    EOCZ_MAX_RISING_DELAY, 1, data)) {
+		if (!wait_for_eocz(data, EOCZ_MIN_RISING_DELAY,
+		    EOCZ_MAX_RISING_DELAY, 1)) {
 			e = -EIO;
 			goto err;
 		}
 
 		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
 
-		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
-		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
+		if (!wait_for_eocz(data, EOCZ_MIN_FALLING_DELAY,
+		    EOCZ_MAX_FALLING_DELAY, 0)) {
 			e = -EIO;
 			goto err;
 		}


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:40       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:40 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

I'd suggest these cleanups... But I don't see why it would fail. (Aha,
and sorry for trailing whitespace, you'll probably need to delete it.)

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
index afe1b5a..8a69604 100644
--- a/drivers/hwmon/omap3-temp.c
+++ b/drivers/hwmon/omap3-temp.c
@@ -35,21 +35,29 @@
 /* 32.768Khz clock speed in nano seconds */
 #define CLOCK_32K_SPEED_NS 30518
 
-/* minimum delay for EOCZ rise after SOC rise is
- * 11 cycles of the 32.768Khz clock */
+/*
+ * minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock
+ */
 #define EOCZ_MIN_RISING_DELAY (11 * CLOCK_32K_SPEED_NS)
 
-/* From docs, maximum delay for EOCZ rise after SOC rise is
+/*
+ * From docs, maximum delay for EOCZ rise after SOC rise is
  * 14 cycles of the 32.768Khz clock. But after some experiments,
- * 24 cycles as maximum is safer. */
+ * 24 cycles as maximum is safer.
+ */
 #define EOCZ_MAX_RISING_DELAY (24 * CLOCK_32K_SPEED_NS)
 
-/* minimum delay for EOCZ falling is
- * 36 cycles of the 32.768Khz clock */
+/*
+ * minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock 
+ */
 #define EOCZ_MIN_FALLING_DELAY (36 * CLOCK_32K_SPEED_NS)
 
-/* maximum delay for EOCZ falling is
- * 40 cycles of the 32.768Khz clock */
+/*
+ * maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock 
+ */
 #define EOCZ_MAX_FALLING_DELAY (40 * CLOCK_32K_SPEED_NS)
 
 /* temperature register offset in the syscon register area */
@@ -116,8 +124,8 @@ struct omap3_temp_data {
 	bool valid;
 };
 
-static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
-				struct omap3_temp_data *data)
+static inline bool wait_for_eocz(struct omap3_temp_data *data,
+				 int min_delay, int max_delay, u32 level)
 {
 	ktime_t timeout, expire;
 	u32 temp_sensor_reg, eocz_mask;
@@ -133,10 +141,10 @@ static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level,
 	do {
 		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
 		if ((temp_sensor_reg & eocz_mask) = level)
-			break;
+			return true;
 	} while (ktime_us_delta(expire, ktime_get()) > 0);
 
-	return (temp_sensor_reg & eocz_mask) = level;
+	return false;
 }
 
 static int omap3_temp_update(struct omap3_temp_data *data)
@@ -153,16 +161,16 @@ static int omap3_temp_update(struct omap3_temp_data *data)
 		regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
 				   soc_mask, soc_mask);
 
-		if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
-		    EOCZ_MAX_RISING_DELAY, 1, data)) {
+		if (!wait_for_eocz(data, EOCZ_MIN_RISING_DELAY,
+		    EOCZ_MAX_RISING_DELAY, 1)) {
 			e = -EIO;
 			goto err;
 		}
 
 		regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
 
-		if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
-		    EOCZ_MAX_FALLING_DELAY, 0, data)) {
+		if (!wait_for_eocz(data, EOCZ_MIN_FALLING_DELAY,
+		    EOCZ_MAX_FALLING_DELAY, 0)) {
 			e = -EIO;
 			goto err;
 		}


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-26 12:34     ` Sebastian Reichel
  (?)
@ 2014-12-27 19:48       ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:48 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

When it hangs, it seems to hang here:

     	if (!wait_for_eocz(data, EOCZ_MIN_RISING_DELAY,
	                    EOCZ_MAX_RISING_DELAY, 1)) {
			                            e = -EIO;
								goto
	                    err;
			                    }

...so wait does not seem to reliably wait.
									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:48       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

When it hangs, it seems to hang here:

     	if (!wait_for_eocz(data, EOCZ_MIN_RISING_DELAY,
	                    EOCZ_MAX_RISING_DELAY, 1)) {
			                            e = -EIO;
								goto
	                    err;
			                    }

...so wait does not seem to reliably wait.
									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:48       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:48 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

When it hangs, it seems to hang here:

     	if (!wait_for_eocz(data, EOCZ_MIN_RISING_DELAY,
	                    EOCZ_MAX_RISING_DELAY, 1)) {
			                            e = -EIO;
								goto
	                    err;
			                    }

...so wait does not seem to reliably wait.
									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:58       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:58 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
>  drivers/hwmon/Kconfig      |   8 ++
>  drivers/hwmon/Makefile     |   1 +
>  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 316 insertions(+)
>  create mode 100644 drivers/hwmon/omap3-temp.c

When it hangs, it loops here:

do {
regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
if ((temp_sensor_reg & eocz_mask) == level)
   return true;
printk("=");
}
while (ktime_us_delta(expire, ktime_get()) > 0);

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:58       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:58 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>  drivers/hwmon/Kconfig      |   8 ++
>  drivers/hwmon/Makefile     |   1 +
>  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 316 insertions(+)
>  create mode 100644 drivers/hwmon/omap3-temp.c

When it hangs, it loops here:

do {
regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
if ((temp_sensor_reg & eocz_mask) == level)
   return true;
printk("=");
}
while (ktime_us_delta(expire, ktime_get()) > 0);

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:58       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
>  drivers/hwmon/Kconfig      |   8 ++
>  drivers/hwmon/Makefile     |   1 +
>  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 316 insertions(+)
>  create mode 100644 drivers/hwmon/omap3-temp.c

When it hangs, it loops here:

do {
regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
if ((temp_sensor_reg & eocz_mask) == level)
   return true;
printk("=");
}
while (ktime_us_delta(expire, ktime_get()) > 0);

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 19:58       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 19:58 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
>  drivers/hwmon/Kconfig      |   8 ++
>  drivers/hwmon/Makefile     |   1 +
>  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 316 insertions(+)
>  create mode 100644 drivers/hwmon/omap3-temp.c

When it hangs, it loops here:

do {
regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
if ((temp_sensor_reg & eocz_mask) = level)
   return true;
printk("=");
}
while (ktime_us_delta(expire, ktime_get()) > 0);

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-27 19:58       ` Pavel Machek
  (?)
@ 2014-12-27 22:35         ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 22:35 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > which can be used to determine the SoCs temperature. This patch provides
> > a DT based driver for the temperature sensor based on an older driver
> > written by Peter De Schrijver for the Nokia N900 and N9.
> > 
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
> >  drivers/hwmon/Kconfig      |   8 ++
> >  drivers/hwmon/Makefile     |   1 +
> >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 316 insertions(+)
> >  create mode 100644 drivers/hwmon/omap3-temp.c
> 
> When it hangs, it loops here:
> 
> do {
> regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> if ((temp_sensor_reg & eocz_mask) == level)
>    return true;
> printk("=");
> }
> while (ktime_us_delta(expire, ktime_get()) > 0);

And this fixes the hang, and makes level handling more readable.

Fix the timeout code, now it actually works. Driver still fails after
a while.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
index 8a69604..1b8c768 100644
--- a/drivers/hwmon/omap3-temp.c
+++ b/drivers/hwmon/omap3-temp.c
@@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
 	ktime_t timeout, expire;
 	u32 temp_sensor_reg, eocz_mask;
 
 	eocz_mask = BIT(data->hwdata->eocz_bit);
-	level &= 1;
-	level *= eocz_mask;
 
 	expire = ktime_add_ns(ktime_get(), max_delay);
 	timeout = ktime_set(0, min_delay);
@@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
 	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
 	do {
 		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
-		if ((temp_sensor_reg & eocz_mask) == level)
+		if (!!(temp_sensor_reg & eocz_mask) == level)
 			return true;
-	} while (ktime_us_delta(expire, ktime_get()) > 0);
+	} while (ktime_after(expire, ktime_get()));
 
 	return false;
 }

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 22:35         ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 22:35 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > which can be used to determine the SoCs temperature. This patch provides
> > a DT based driver for the temperature sensor based on an older driver
> > written by Peter De Schrijver for the Nokia N900 and N9.
> > 
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
> >  drivers/hwmon/Kconfig      |   8 ++
> >  drivers/hwmon/Makefile     |   1 +
> >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 316 insertions(+)
> >  create mode 100644 drivers/hwmon/omap3-temp.c
> 
> When it hangs, it loops here:
> 
> do {
> regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> if ((temp_sensor_reg & eocz_mask) == level)
>    return true;
> printk("=");
> }
> while (ktime_us_delta(expire, ktime_get()) > 0);

And this fixes the hang, and makes level handling more readable.

Fix the timeout code, now it actually works. Driver still fails after
a while.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
index 8a69604..1b8c768 100644
--- a/drivers/hwmon/omap3-temp.c
+++ b/drivers/hwmon/omap3-temp.c
@@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
 	ktime_t timeout, expire;
 	u32 temp_sensor_reg, eocz_mask;
 
 	eocz_mask = BIT(data->hwdata->eocz_bit);
-	level &= 1;
-	level *= eocz_mask;
 
 	expire = ktime_add_ns(ktime_get(), max_delay);
 	timeout = ktime_set(0, min_delay);
@@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
 	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
 	do {
 		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
-		if ((temp_sensor_reg & eocz_mask) == level)
+		if (!!(temp_sensor_reg & eocz_mask) == level)
 			return true;
-	} while (ktime_us_delta(expire, ktime_get()) > 0);
+	} while (ktime_after(expire, ktime_get()));
 
 	return false;
 }

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 22:35         ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 22:35 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > which can be used to determine the SoCs temperature. This patch provides
> > a DT based driver for the temperature sensor based on an older driver
> > written by Peter De Schrijver for the Nokia N900 and N9.
> > 
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
> >  drivers/hwmon/Kconfig      |   8 ++
> >  drivers/hwmon/Makefile     |   1 +
> >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 316 insertions(+)
> >  create mode 100644 drivers/hwmon/omap3-temp.c
> 
> When it hangs, it loops here:
> 
> do {
> regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> if ((temp_sensor_reg & eocz_mask) = level)
>    return true;
> printk("=");
> }
> while (ktime_us_delta(expire, ktime_get()) > 0);

And this fixes the hang, and makes level handling more readable.

Fix the timeout code, now it actually works. Driver still fails after
a while.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
index 8a69604..1b8c768 100644
--- a/drivers/hwmon/omap3-temp.c
+++ b/drivers/hwmon/omap3-temp.c
@@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
 	ktime_t timeout, expire;
 	u32 temp_sensor_reg, eocz_mask;
 
 	eocz_mask = BIT(data->hwdata->eocz_bit);
-	level &= 1;
-	level *= eocz_mask;
 
 	expire = ktime_add_ns(ktime_get(), max_delay);
 	timeout = ktime_set(0, min_delay);
@@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
 	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
 	do {
 		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
-		if ((temp_sensor_reg & eocz_mask) = level)
+		if (!!(temp_sensor_reg & eocz_mask) = level)
 			return true;
-	} while (ktime_us_delta(expire, ktime_get()) > 0);
+	} while (ktime_after(expire, ktime_get()));
 
 	return false;
 }

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-26 12:34     ` Sebastian Reichel
  (?)
@ 2014-12-27 23:26       ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 23:26 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

As I mentioned before, this version stops working after a
while. Version I originally posted seems to work ok under same load.

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 23:26       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 23:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

As I mentioned before, this version stops working after a
while. Version I originally posted seems to work ok under same load.

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-27 23:26       ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-27 23:26 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pali Rohar, Jean Delvare, Guenter Roeck, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>

As I mentioned before, this version stops working after a
while. Version I originally posted seems to work ok under same load.

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-27 22:35         ` Pavel Machek
  (?)
@ 2014-12-28  8:24           ` Guenter Roeck
  -1 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2014-12-28  8:24 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Sebastian Reichel, Pali Rohar, Jean Delvare, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Sat, Dec 27, 2014 at 11:35:16PM +0100, Pavel Machek wrote:
> On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> > On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > which can be used to determine the SoCs temperature. This patch provides
> > > a DT based driver for the temperature sensor based on an older driver
> > > written by Peter De Schrijver for the Nokia N900 and N9.
> > > 
> > > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > > ---
> > >  drivers/hwmon/Kconfig      |   8 ++
> > >  drivers/hwmon/Makefile     |   1 +
> > >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 316 insertions(+)
> > >  create mode 100644 drivers/hwmon/omap3-temp.c
> > 
> > When it hangs, it loops here:
> > 
> > do {
> > regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> > if ((temp_sensor_reg & eocz_mask) == level)
> >    return true;
> > printk("=");
> > }
> > while (ktime_us_delta(expire, ktime_get()) > 0);
> 
> And this fixes the hang, and makes level handling more readable.
> 
> Fix the timeout code, now it actually works. Driver still fails after
> a while.
> 
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
> index 8a69604..1b8c768 100644
> --- a/drivers/hwmon/omap3-temp.c
> +++ b/drivers/hwmon/omap3-temp.c
> @@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
>  	ktime_t timeout, expire;
>  	u32 temp_sensor_reg, eocz_mask;
>  
>  	eocz_mask = BIT(data->hwdata->eocz_bit);
> -	level &= 1;
> -	level *= eocz_mask;
>  
>  	expire = ktime_add_ns(ktime_get(), max_delay);
>  	timeout = ktime_set(0, min_delay);
> @@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
>  	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
>  	do {
>  		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> -		if ((temp_sensor_reg & eocz_mask) == level)
> +		if (!!(temp_sensor_reg & eocz_mask) == level)
>  			return true;
> -	} while (ktime_us_delta(expire, ktime_get()) > 0);
> +	} while (ktime_after(expire, ktime_get()));
>  
Does this have to be a hard loop, without sleep ? I am a bit concerned that it
may loop for more than a ms.

Other than that, I assume we'll see an updated version with the coding style
issues and hang-up problems fixed.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-28  8:24           ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2014-12-28  8:24 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, Dec 27, 2014 at 11:35:16PM +0100, Pavel Machek wrote:
> On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> > On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > which can be used to determine the SoCs temperature. This patch provides
> > > a DT based driver for the temperature sensor based on an older driver
> > > written by Peter De Schrijver for the Nokia N900 and N9.
> > > 
> > > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > > ---
> > >  drivers/hwmon/Kconfig      |   8 ++
> > >  drivers/hwmon/Makefile     |   1 +
> > >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 316 insertions(+)
> > >  create mode 100644 drivers/hwmon/omap3-temp.c
> > 
> > When it hangs, it loops here:
> > 
> > do {
> > regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> > if ((temp_sensor_reg & eocz_mask) == level)
> >    return true;
> > printk("=");
> > }
> > while (ktime_us_delta(expire, ktime_get()) > 0);
> 
> And this fixes the hang, and makes level handling more readable.
> 
> Fix the timeout code, now it actually works. Driver still fails after
> a while.
> 
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
> index 8a69604..1b8c768 100644
> --- a/drivers/hwmon/omap3-temp.c
> +++ b/drivers/hwmon/omap3-temp.c
> @@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
>  	ktime_t timeout, expire;
>  	u32 temp_sensor_reg, eocz_mask;
>  
>  	eocz_mask = BIT(data->hwdata->eocz_bit);
> -	level &= 1;
> -	level *= eocz_mask;
>  
>  	expire = ktime_add_ns(ktime_get(), max_delay);
>  	timeout = ktime_set(0, min_delay);
> @@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
>  	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
>  	do {
>  		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> -		if ((temp_sensor_reg & eocz_mask) == level)
> +		if (!!(temp_sensor_reg & eocz_mask) == level)
>  			return true;
> -	} while (ktime_us_delta(expire, ktime_get()) > 0);
> +	} while (ktime_after(expire, ktime_get()));
>  
Does this have to be a hard loop, without sleep ? I am a bit concerned that it
may loop for more than a ms.

Other than that, I assume we'll see an updated version with the coding style
issues and hang-up problems fixed.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-28  8:24           ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2014-12-28  8:24 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Sebastian Reichel, Pali Rohar, Jean Delvare, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

On Sat, Dec 27, 2014 at 11:35:16PM +0100, Pavel Machek wrote:
> On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> > On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > which can be used to determine the SoCs temperature. This patch provides
> > > a DT based driver for the temperature sensor based on an older driver
> > > written by Peter De Schrijver for the Nokia N900 and N9.
> > > 
> > > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > > ---
> > >  drivers/hwmon/Kconfig      |   8 ++
> > >  drivers/hwmon/Makefile     |   1 +
> > >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 316 insertions(+)
> > >  create mode 100644 drivers/hwmon/omap3-temp.c
> > 
> > When it hangs, it loops here:
> > 
> > do {
> > regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> > if ((temp_sensor_reg & eocz_mask) = level)
> >    return true;
> > printk("=");
> > }
> > while (ktime_us_delta(expire, ktime_get()) > 0);
> 
> And this fixes the hang, and makes level handling more readable.
> 
> Fix the timeout code, now it actually works. Driver still fails after
> a while.
> 
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
> index 8a69604..1b8c768 100644
> --- a/drivers/hwmon/omap3-temp.c
> +++ b/drivers/hwmon/omap3-temp.c
> @@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
>  	ktime_t timeout, expire;
>  	u32 temp_sensor_reg, eocz_mask;
>  
>  	eocz_mask = BIT(data->hwdata->eocz_bit);
> -	level &= 1;
> -	level *= eocz_mask;
>  
>  	expire = ktime_add_ns(ktime_get(), max_delay);
>  	timeout = ktime_set(0, min_delay);
> @@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
>  	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
>  	do {
>  		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> -		if ((temp_sensor_reg & eocz_mask) = level)
> +		if (!!(temp_sensor_reg & eocz_mask) = level)
>  			return true;
> -	} while (ktime_us_delta(expire, ktime_get()) > 0);
> +	} while (ktime_after(expire, ktime_get()));
>  
Does this have to be a hard loop, without sleep ? I am a bit concerned that it
may loop for more than a ms.

Other than that, I assume we'll see an updated version with the coding style
issues and hang-up problems fixed.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-28  8:24           ` Guenter Roeck
  (?)
  (?)
@ 2014-12-28 10:07             ` Sebastian Reichel
  -1 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-28 10:07 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Pavel Machek, Pali Rohar, Jean Delvare, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala

[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]

On Sun, Dec 28, 2014 at 12:24:47AM -0800, Guenter Roeck wrote:
> On Sat, Dec 27, 2014 at 11:35:16PM +0100, Pavel Machek wrote:
> > On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> > > On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > > > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > which can be used to determine the SoCs temperature. This patch provides
> > > > a DT based driver for the temperature sensor based on an older driver
> > > > written by Peter De Schrijver for the Nokia N900 and N9.
> > > > 
> > > > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > > > ---
> > > >  drivers/hwmon/Kconfig      |   8 ++
> > > >  drivers/hwmon/Makefile     |   1 +
> > > >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 316 insertions(+)
> > > >  create mode 100644 drivers/hwmon/omap3-temp.c
> > > 
> > > When it hangs, it loops here:
> > > 
> > > do {
> > > regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> > > if ((temp_sensor_reg & eocz_mask) == level)
> > >    return true;
> > > printk("=");
> > > }
> > > while (ktime_us_delta(expire, ktime_get()) > 0);
> > 
> > And this fixes the hang, and makes level handling more readable.
> > 
> > Fix the timeout code, now it actually works. Driver still fails after
> > a while.
> > 
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > 
> > diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
> > index 8a69604..1b8c768 100644
> > --- a/drivers/hwmon/omap3-temp.c
> > +++ b/drivers/hwmon/omap3-temp.c
> > @@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
> >  	ktime_t timeout, expire;
> >  	u32 temp_sensor_reg, eocz_mask;
> >  
> >  	eocz_mask = BIT(data->hwdata->eocz_bit);
> > -	level &= 1;
> > -	level *= eocz_mask;
> >  
> >  	expire = ktime_add_ns(ktime_get(), max_delay);
> >  	timeout = ktime_set(0, min_delay);
> > @@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
> >  	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
> >  	do {
> >  		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> > -		if ((temp_sensor_reg & eocz_mask) == level)
> > +		if (!!(temp_sensor_reg & eocz_mask) == level)
> >  			return true;
> > -	} while (ktime_us_delta(expire, ktime_get()) > 0);
> > +	} while (ktime_after(expire, ktime_get()));
> >  
> Does this have to be a hard loop, without sleep ? I am a bit concerned that it
> may loop for more than a ms.
> 
> Other than that, I assume we'll see an updated version with the coding style
> issues and hang-up problems fixed.

I will send a v2 patchset with Pavels change requests. It may take a
few days though, since I'm currently at a conference (31C3).

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-28 10:07             ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-28 10:07 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Mark Rutland, devicetree, Pavel Machek, Pawel Moll, Ian Campbell,
	Tony Lindgren, Kumar Gala, linux-kernel, lm-sensors, Rob Herring,
	linux-arm-kernel, Benoît Cousson, Pali Rohar, linux-omap,
	Jean Delvare


[-- Attachment #1.1: Type: text/plain, Size: 2839 bytes --]

On Sun, Dec 28, 2014 at 12:24:47AM -0800, Guenter Roeck wrote:
> On Sat, Dec 27, 2014 at 11:35:16PM +0100, Pavel Machek wrote:
> > On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> > > On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > > > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > which can be used to determine the SoCs temperature. This patch provides
> > > > a DT based driver for the temperature sensor based on an older driver
> > > > written by Peter De Schrijver for the Nokia N900 and N9.
> > > > 
> > > > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > > > ---
> > > >  drivers/hwmon/Kconfig      |   8 ++
> > > >  drivers/hwmon/Makefile     |   1 +
> > > >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 316 insertions(+)
> > > >  create mode 100644 drivers/hwmon/omap3-temp.c
> > > 
> > > When it hangs, it loops here:
> > > 
> > > do {
> > > regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> > > if ((temp_sensor_reg & eocz_mask) == level)
> > >    return true;
> > > printk("=");
> > > }
> > > while (ktime_us_delta(expire, ktime_get()) > 0);
> > 
> > And this fixes the hang, and makes level handling more readable.
> > 
> > Fix the timeout code, now it actually works. Driver still fails after
> > a while.
> > 
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > 
> > diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
> > index 8a69604..1b8c768 100644
> > --- a/drivers/hwmon/omap3-temp.c
> > +++ b/drivers/hwmon/omap3-temp.c
> > @@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
> >  	ktime_t timeout, expire;
> >  	u32 temp_sensor_reg, eocz_mask;
> >  
> >  	eocz_mask = BIT(data->hwdata->eocz_bit);
> > -	level &= 1;
> > -	level *= eocz_mask;
> >  
> >  	expire = ktime_add_ns(ktime_get(), max_delay);
> >  	timeout = ktime_set(0, min_delay);
> > @@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
> >  	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
> >  	do {
> >  		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> > -		if ((temp_sensor_reg & eocz_mask) == level)
> > +		if (!!(temp_sensor_reg & eocz_mask) == level)
> >  			return true;
> > -	} while (ktime_us_delta(expire, ktime_get()) > 0);
> > +	} while (ktime_after(expire, ktime_get()));
> >  
> Does this have to be a hard loop, without sleep ? I am a bit concerned that it
> may loop for more than a ms.
> 
> Other than that, I assume we'll see an updated version with the coding style
> issues and hang-up problems fixed.

I will send a v2 patchset with Pavels change requests. It may take a
few days though, since I'm currently at a conference (31C3).

-- Sebastian

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-28 10:07             ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-28 10:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Sun, Dec 28, 2014 at 12:24:47AM -0800, Guenter Roeck wrote:
> On Sat, Dec 27, 2014 at 11:35:16PM +0100, Pavel Machek wrote:
> > On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> > > On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > > > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > which can be used to determine the SoCs temperature. This patch provides
> > > > a DT based driver for the temperature sensor based on an older driver
> > > > written by Peter De Schrijver for the Nokia N900 and N9.
> > > > 
> > > > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > > > ---
> > > >  drivers/hwmon/Kconfig      |   8 ++
> > > >  drivers/hwmon/Makefile     |   1 +
> > > >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 316 insertions(+)
> > > >  create mode 100644 drivers/hwmon/omap3-temp.c
> > > 
> > > When it hangs, it loops here:
> > > 
> > > do {
> > > regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> > > if ((temp_sensor_reg & eocz_mask) == level)
> > >    return true;
> > > printk("=");
> > > }
> > > while (ktime_us_delta(expire, ktime_get()) > 0);
> > 
> > And this fixes the hang, and makes level handling more readable.
> > 
> > Fix the timeout code, now it actually works. Driver still fails after
> > a while.
> > 
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > 
> > diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
> > index 8a69604..1b8c768 100644
> > --- a/drivers/hwmon/omap3-temp.c
> > +++ b/drivers/hwmon/omap3-temp.c
> > @@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
> >  	ktime_t timeout, expire;
> >  	u32 temp_sensor_reg, eocz_mask;
> >  
> >  	eocz_mask = BIT(data->hwdata->eocz_bit);
> > -	level &= 1;
> > -	level *= eocz_mask;
> >  
> >  	expire = ktime_add_ns(ktime_get(), max_delay);
> >  	timeout = ktime_set(0, min_delay);
> > @@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
> >  	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
> >  	do {
> >  		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> > -		if ((temp_sensor_reg & eocz_mask) == level)
> > +		if (!!(temp_sensor_reg & eocz_mask) == level)
> >  			return true;
> > -	} while (ktime_us_delta(expire, ktime_get()) > 0);
> > +	} while (ktime_after(expire, ktime_get()));
> >  
> Does this have to be a hard loop, without sleep ? I am a bit concerned that it
> may loop for more than a ms.
> 
> Other than that, I assume we'll see an updated version with the coding style
> issues and hang-up problems fixed.

I will send a v2 patchset with Pavels change requests. It may take a
few days though, since I'm currently at a conference (31C3).

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141228/f8bac595/attachment.sig>

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-28 10:07             ` Sebastian Reichel
  0 siblings, 0 replies; 115+ messages in thread
From: Sebastian Reichel @ 2014-12-28 10:07 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Pavel Machek, Pali Rohar, Jean Delvare, Tony Lindgren,
	Benoît Cousson, linux-kernel, linux-arm-kernel, linux-omap,
	lm-sensors, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala


[-- Attachment #1.1: Type: text/plain, Size: 2839 bytes --]

On Sun, Dec 28, 2014 at 12:24:47AM -0800, Guenter Roeck wrote:
> On Sat, Dec 27, 2014 at 11:35:16PM +0100, Pavel Machek wrote:
> > On Sat 2014-12-27 20:58:25, Pavel Machek wrote:
> > > On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> > > > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > which can be used to determine the SoCs temperature. This patch provides
> > > > a DT based driver for the temperature sensor based on an older driver
> > > > written by Peter De Schrijver for the Nokia N900 and N9.
> > > > 
> > > > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > > > ---
> > > >  drivers/hwmon/Kconfig      |   8 ++
> > > >  drivers/hwmon/Makefile     |   1 +
> > > >  drivers/hwmon/omap3-temp.c | 307 +++++++++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 316 insertions(+)
> > > >  create mode 100644 drivers/hwmon/omap3-temp.c
> > > 
> > > When it hangs, it loops here:
> > > 
> > > do {
> > > regmap_read(data->syscon, SYSCON_TEMP_REG,&temp_sensor_reg);
> > > if ((temp_sensor_reg & eocz_mask) == level)
> > >    return true;
> > > printk("=");
> > > }
> > > while (ktime_us_delta(expire, ktime_get()) > 0);
> > 
> > And this fixes the hang, and makes level handling more readable.
> > 
> > Fix the timeout code, now it actually works. Driver still fails after
> > a while.
> > 
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > 
> > diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
> > index 8a69604..1b8c768 100644
> > --- a/drivers/hwmon/omap3-temp.c
> > +++ b/drivers/hwmon/omap3-temp.c
> > @@ -130,9 +130,7 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
> >  	ktime_t timeout, expire;
> >  	u32 temp_sensor_reg, eocz_mask;
> >  
> >  	eocz_mask = BIT(data->hwdata->eocz_bit);
> > -	level &= 1;
> > -	level *= eocz_mask;
> >  
> >  	expire = ktime_add_ns(ktime_get(), max_delay);
> >  	timeout = ktime_set(0, min_delay);
> > @@ -140,9 +141,9 @@ static inline bool wait_for_eocz(struct omap3_temp_data *data,
> >  	schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
> >  	do {
> >  		regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> > -		if ((temp_sensor_reg & eocz_mask) == level)
> > +		if (!!(temp_sensor_reg & eocz_mask) == level)
> >  			return true;
> > -	} while (ktime_us_delta(expire, ktime_get()) > 0);
> > +	} while (ktime_after(expire, ktime_get()));
> >  
> Does this have to be a hard loop, without sleep ? I am a bit concerned that it
> may loop for more than a ms.
> 
> Other than that, I assume we'll see an updated version with the coding style
> issues and hang-up problems fixed.

I will send a v2 patchset with Pavels change requests. It may take a
few days though, since I'm currently at a conference (31C3).

-- Sebastian

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 17:52       ` Grazvydas Ignotas
  0 siblings, 0 replies; 115+ messages in thread
From: Grazvydas Ignotas @ 2014-12-29 17:52 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pavel Machek, Pali Rohar, Jean Delvare, Guenter Roeck,
	Tony Lindgren, Benoît Cousson, Mark Rutland, devicetree,
	Pawel Moll, Ian Campbell, linux-kernel, lm-sensors, Rob Herring,
	Kumar Gala, linux-omap, linux-arm-kernel, Menon, Nishanth

On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.

The sensor looks like an earlier iteration of sensors used in newer
OMAPs, which are already supported by maybe
drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
that driver instead?

--
Grazvydas

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 17:52       ` Grazvydas Ignotas
  0 siblings, 0 replies; 115+ messages in thread
From: Grazvydas Ignotas @ 2014-12-29 17:52 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pavel Machek, Pali Rohar, Jean Delvare, Guenter Roeck,
	Tony Lindgren, Benoît Cousson, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Ian Campbell,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA, Rob Herring, Kumar Gala,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Menon,
	Nishanth

On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.

The sensor looks like an earlier iteration of sensors used in newer
OMAPs, which are already supported by maybe
drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
that driver instead?

--
Grazvydas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 17:52       ` Grazvydas Ignotas
  0 siblings, 0 replies; 115+ messages in thread
From: Grazvydas Ignotas @ 2014-12-29 17:52 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.

The sensor looks like an earlier iteration of sensors used in newer
OMAPs, which are already supported by maybe
drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
that driver instead?

--
Grazvydas

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 17:52       ` Grazvydas Ignotas
  0 siblings, 0 replies; 115+ messages in thread
From: Grazvydas Ignotas @ 2014-12-29 17:52 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pavel Machek, Pali Rohar, Jean Delvare, Guenter Roeck,
	Tony Lindgren, Benoît Cousson, Mark Rutland, devicetree,
	Pawel Moll, Ian Campbell, linux-kernel, lm-sensors, Rob Herring,
	Kumar Gala, linux-omap, linux-arm-kernel, Menon, Nishanth

On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.

The sensor looks like an earlier iteration of sensors used in newer
OMAPs, which are already supported by maybe
drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
that driver instead?

--
Grazvydas

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-29 17:52       ` Grazvydas Ignotas
  (?)
@ 2014-12-29 18:01         ` Nishanth Menon
  -1 siblings, 0 replies; 115+ messages in thread
From: Nishanth Menon @ 2014-12-29 18:01 UTC (permalink / raw)
  To: Grazvydas Ignotas
  Cc: Sebastian Reichel, Mark Rutland, dt list, Pavel Machek,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, Guenter Roeck,
	linux-arm-kernel

On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
>> which can be used to determine the SoCs temperature. This patch provides
>> a DT based driver for the temperature sensor based on an older driver
>> written by Peter De Schrijver for the Nokia N900 and N9.
>
> The sensor looks like an earlier iteration of sensors used in newer
> OMAPs, which are already supported by maybe
> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> that driver instead?

Just to be clear - OMAP4 is the first time that the sensors were
reliable enough to be used.

---
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 18:01         ` Nishanth Menon
  0 siblings, 0 replies; 115+ messages in thread
From: Nishanth Menon @ 2014-12-29 18:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
>> which can be used to determine the SoCs temperature. This patch provides
>> a DT based driver for the temperature sensor based on an older driver
>> written by Peter De Schrijver for the Nokia N900 and N9.
>
> The sensor looks like an earlier iteration of sensors used in newer
> OMAPs, which are already supported by maybe
> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> that driver instead?

Just to be clear - OMAP4 is the first time that the sensors were
reliable enough to be used.

---
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 18:01         ` Nishanth Menon
  0 siblings, 0 replies; 115+ messages in thread
From: Nishanth Menon @ 2014-12-29 18:01 UTC (permalink / raw)
  To: Grazvydas Ignotas
  Cc: Sebastian Reichel, Mark Rutland, dt list, Pavel Machek,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, Guenter Roeck,
	linux-arm-kernel

On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
>> which can be used to determine the SoCs temperature. This patch provides
>> a DT based driver for the temperature sensor based on an older driver
>> written by Peter De Schrijver for the Nokia N900 and N9.
>
> The sensor looks like an earlier iteration of sensors used in newer
> OMAPs, which are already supported by maybe
> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> that driver instead?

Just to be clear - OMAP4 is the first time that the sensors were
reliable enough to be used.

---
Regards,
Nishanth Menon

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 18:15           ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-29 18:15 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Grazvydas Ignotas, Sebastian Reichel, Mark Rutland, dt list,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, Guenter Roeck,
	linux-arm-kernel

On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> >> which can be used to determine the SoCs temperature. This patch provides
> >> a DT based driver for the temperature sensor based on an older driver
> >> written by Peter De Schrijver for the Nokia N900 and N9.
> >
> > The sensor looks like an earlier iteration of sensors used in newer
> > OMAPs, which are already supported by maybe
> > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > that driver instead?
> 
> Just to be clear - OMAP4 is the first time that the sensors were
> reliable enough to be used.

When testing initial version of the patch, they seem to work very well
in the omap3 case.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 18:15           ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-29 18:15 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Grazvydas Ignotas, Sebastian Reichel, Mark Rutland, dt list,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar,
	linux-omap-u79uwXL29TY76Z2rM5mHXA, Guenter Roeck,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> >> which can be used to determine the SoCs temperature. This patch provides
> >> a DT based driver for the temperature sensor based on an older driver
> >> written by Peter De Schrijver for the Nokia N900 and N9.
> >
> > The sensor looks like an earlier iteration of sensors used in newer
> > OMAPs, which are already supported by maybe
> > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > that driver instead?
> 
> Just to be clear - OMAP4 is the first time that the sensors were
> reliable enough to be used.

When testing initial version of the patch, they seem to work very well
in the omap3 case.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 18:15           ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> >> which can be used to determine the SoCs temperature. This patch provides
> >> a DT based driver for the temperature sensor based on an older driver
> >> written by Peter De Schrijver for the Nokia N900 and N9.
> >
> > The sensor looks like an earlier iteration of sensors used in newer
> > OMAPs, which are already supported by maybe
> > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > that driver instead?
> 
> Just to be clear - OMAP4 is the first time that the sensors were
> reliable enough to be used.

When testing initial version of the patch, they seem to work very well
in the omap3 case.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 18:15           ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-29 18:15 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Grazvydas Ignotas, Sebastian Reichel, Mark Rutland, dt list,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, Guenter Roeck,
	linux-arm-kernel

On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> >> which can be used to determine the SoCs temperature. This patch provides
> >> a DT based driver for the temperature sensor based on an older driver
> >> written by Peter De Schrijver for the Nokia N900 and N9.
> >
> > The sensor looks like an earlier iteration of sensors used in newer
> > OMAPs, which are already supported by maybe
> > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > that driver instead?
> 
> Just to be clear - OMAP4 is the first time that the sensors were
> reliable enough to be used.

When testing initial version of the patch, they seem to work very well
in the omap3 case.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-29 18:15           ` Pavel Machek
  (?)
  (?)
@ 2014-12-29 19:04             ` Guenter Roeck
  -1 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2014-12-29 19:04 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > >> which can be used to determine the SoCs temperature. This patch provides
> > >> a DT based driver for the temperature sensor based on an older driver
> > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > >
> > > The sensor looks like an earlier iteration of sensors used in newer
> > > OMAPs, which are already supported by maybe
> > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > that driver instead?
> > 
> > Just to be clear - OMAP4 is the first time that the sensors were
> > reliable enough to be used.
> 
> When testing initial version of the patch, they seem to work very well
> in the omap3 case.
> 
Pavel,

can you look into the omap4 thermal driver to see if it can be used ?

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 19:04             ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2014-12-29 19:04 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > >> which can be used to determine the SoCs temperature. This patch provides
> > >> a DT based driver for the temperature sensor based on an older driver
> > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > >
> > > The sensor looks like an earlier iteration of sensors used in newer
> > > OMAPs, which are already supported by maybe
> > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > that driver instead?
> > 
> > Just to be clear - OMAP4 is the first time that the sensors were
> > reliable enough to be used.
> 
> When testing initial version of the patch, they seem to work very well
> in the omap3 case.
> 
Pavel,

can you look into the omap4 thermal driver to see if it can be used ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 19:04             ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2014-12-29 19:04 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > >> which can be used to determine the SoCs temperature. This patch provides
> > >> a DT based driver for the temperature sensor based on an older driver
> > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > >
> > > The sensor looks like an earlier iteration of sensors used in newer
> > > OMAPs, which are already supported by maybe
> > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > that driver instead?
> > 
> > Just to be clear - OMAP4 is the first time that the sensors were
> > reliable enough to be used.
> 
> When testing initial version of the patch, they seem to work very well
> in the omap3 case.
> 
Pavel,

can you look into the omap4 thermal driver to see if it can be used ?

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 19:04             ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2014-12-29 19:04 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > >> which can be used to determine the SoCs temperature. This patch provides
> > >> a DT based driver for the temperature sensor based on an older driver
> > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > >
> > > The sensor looks like an earlier iteration of sensors used in newer
> > > OMAPs, which are already supported by maybe
> > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > that driver instead?
> > 
> > Just to be clear - OMAP4 is the first time that the sensors were
> > reliable enough to be used.
> 
> When testing initial version of the patch, they seem to work very well
> in the omap3 case.
> 
Pavel,

can you look into the omap4 thermal driver to see if it can be used ?

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-29 18:15           ` Pavel Machek
  (?)
  (?)
@ 2014-12-29 20:35             ` Nishanth Menon
  -1 siblings, 0 replies; 115+ messages in thread
From: Nishanth Menon @ 2014-12-29 20:35 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Grazvydas Ignotas, Sebastian Reichel, Mark Rutland, dt list,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, Guenter Roeck,
	linux-arm-kernel

On 12/29/2014 12:15 PM, Pavel Machek wrote:
> On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
>> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
>>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
>>>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
>>>> which can be used to determine the SoCs temperature. This patch provides
>>>> a DT based driver for the temperature sensor based on an older driver
>>>> written by Peter De Schrijver for the Nokia N900 and N9.
>>>
>>> The sensor looks like an earlier iteration of sensors used in newer
>>> OMAPs, which are already supported by maybe
>>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
>>> that driver instead?
>>
>> Just to be clear - OMAP4 is the first time that the sensors were
>> reliable enough to be used.
> 
> When testing initial version of the patch, they seem to work very well
> in the omap3 case.

Just be careful when you try to make thermal policy like decisions
based on this sensor. Placement of the sensor w.r.t the actual logic
generating heat has to be a factor as well. If you are just looking
for an approximation temperature (thermometerish kind), you might be
ok with this. I am not sure we'd find any TI data around this.. just a
heads up.

Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think
there were accuracy issues at certain values etc.. So remember to do a
off mode type PM tests as well before you consider requesting these to
be merged.

-- 
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 20:35             ` Nishanth Menon
  0 siblings, 0 replies; 115+ messages in thread
From: Nishanth Menon @ 2014-12-29 20:35 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Mark Rutland, dt list, linux-omap, Guenter Roeck, Pawel Moll,
	Ian Campbell, Tony Lindgren, Pali Rohar, Sebastian Reichel,
	linux-kernel, Rob Herring, Grazvydas Ignotas,
	Benoît Cousson, Kumar Gala, lm-sensors, Jean Delvare,
	linux-arm-kernel

On 12/29/2014 12:15 PM, Pavel Machek wrote:
> On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
>> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
>>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
>>>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
>>>> which can be used to determine the SoCs temperature. This patch provides
>>>> a DT based driver for the temperature sensor based on an older driver
>>>> written by Peter De Schrijver for the Nokia N900 and N9.
>>>
>>> The sensor looks like an earlier iteration of sensors used in newer
>>> OMAPs, which are already supported by maybe
>>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
>>> that driver instead?
>>
>> Just to be clear - OMAP4 is the first time that the sensors were
>> reliable enough to be used.
> 
> When testing initial version of the patch, they seem to work very well
> in the omap3 case.

Just be careful when you try to make thermal policy like decisions
based on this sensor. Placement of the sensor w.r.t the actual logic
generating heat has to be a factor as well. If you are just looking
for an approximation temperature (thermometerish kind), you might be
ok with this. I am not sure we'd find any TI data around this.. just a
heads up.

Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think
there were accuracy issues at certain values etc.. So remember to do a
off mode type PM tests as well before you consider requesting these to
be merged.

-- 
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 20:35             ` Nishanth Menon
  0 siblings, 0 replies; 115+ messages in thread
From: Nishanth Menon @ 2014-12-29 20:35 UTC (permalink / raw)
  To: linux-arm-kernel

On 12/29/2014 12:15 PM, Pavel Machek wrote:
> On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
>> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
>>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
>>>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
>>>> which can be used to determine the SoCs temperature. This patch provides
>>>> a DT based driver for the temperature sensor based on an older driver
>>>> written by Peter De Schrijver for the Nokia N900 and N9.
>>>
>>> The sensor looks like an earlier iteration of sensors used in newer
>>> OMAPs, which are already supported by maybe
>>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
>>> that driver instead?
>>
>> Just to be clear - OMAP4 is the first time that the sensors were
>> reliable enough to be used.
> 
> When testing initial version of the patch, they seem to work very well
> in the omap3 case.

Just be careful when you try to make thermal policy like decisions
based on this sensor. Placement of the sensor w.r.t the actual logic
generating heat has to be a factor as well. If you are just looking
for an approximation temperature (thermometerish kind), you might be
ok with this. I am not sure we'd find any TI data around this.. just a
heads up.

Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think
there were accuracy issues at certain values etc.. So remember to do a
off mode type PM tests as well before you consider requesting these to
be merged.

-- 
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-29 20:35             ` Nishanth Menon
  0 siblings, 0 replies; 115+ messages in thread
From: Nishanth Menon @ 2014-12-29 20:35 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Grazvydas Ignotas, Sebastian Reichel, Mark Rutland, dt list,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, Guenter Roeck,
	linux-arm-kernel

On 12/29/2014 12:15 PM, Pavel Machek wrote:
> On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
>> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
>>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
>>>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
>>>> which can be used to determine the SoCs temperature. This patch provides
>>>> a DT based driver for the temperature sensor based on an older driver
>>>> written by Peter De Schrijver for the Nokia N900 and N9.
>>>
>>> The sensor looks like an earlier iteration of sensors used in newer
>>> OMAPs, which are already supported by maybe
>>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
>>> that driver instead?
>>
>> Just to be clear - OMAP4 is the first time that the sensors were
>> reliable enough to be used.
> 
> When testing initial version of the patch, they seem to work very well
> in the omap3 case.

Just be careful when you try to make thermal policy like decisions
based on this sensor. Placement of the sensor w.r.t the actual logic
generating heat has to be a factor as well. If you are just looking
for an approximation temperature (thermometerish kind), you might be
ok with this. I am not sure we'd find any TI data around this.. just a
heads up.

Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think
there were accuracy issues at certain values etc.. So remember to do a
off mode type PM tests as well before you consider requesting these to
be merged.

-- 
Regards,
Nishanth Menon

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-30 18:00               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-30 18:00 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Grazvydas Ignotas, Sebastian Reichel, Mark Rutland, dt list,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, Guenter Roeck,
	linux-arm-kernel

On Mon 2014-12-29 14:35:55, Nishanth Menon wrote:
> On 12/29/2014 12:15 PM, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> >> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> >>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> >>>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> >>>> which can be used to determine the SoCs temperature. This patch provides
> >>>> a DT based driver for the temperature sensor based on an older driver
> >>>> written by Peter De Schrijver for the Nokia N900 and N9.
> >>>
> >>> The sensor looks like an earlier iteration of sensors used in newer
> >>> OMAPs, which are already supported by maybe
> >>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> >>> that driver instead?
> >>
> >> Just to be clear - OMAP4 is the first time that the sensors were
> >> reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> 
> Just be careful when you try to make thermal policy like decisions
> based on this sensor. Placement of the sensor w.r.t the actual logic

I guess we won't do that, certainly not anytime soon.

> Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
> 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think
> there were accuracy issues at certain values etc.. So remember to do a
> off mode type PM tests as well before you consider requesting these to
> be merged.

Thanks a lot for a pointer. 3x 100uA power draw when you enable
temperature sensor, because it also errorneously enables MMC. I wonder
how the solution would look in the device tree...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-30 18:00               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-30 18:00 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Grazvydas Ignotas, Sebastian Reichel, Mark Rutland, dt list,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar,
	linux-omap-u79uwXL29TY76Z2rM5mHXA, Guenter Roeck,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Mon 2014-12-29 14:35:55, Nishanth Menon wrote:
> On 12/29/2014 12:15 PM, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> >> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >>>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> >>>> which can be used to determine the SoCs temperature. This patch provides
> >>>> a DT based driver for the temperature sensor based on an older driver
> >>>> written by Peter De Schrijver for the Nokia N900 and N9.
> >>>
> >>> The sensor looks like an earlier iteration of sensors used in newer
> >>> OMAPs, which are already supported by maybe
> >>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> >>> that driver instead?
> >>
> >> Just to be clear - OMAP4 is the first time that the sensors were
> >> reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> 
> Just be careful when you try to make thermal policy like decisions
> based on this sensor. Placement of the sensor w.r.t the actual logic

I guess we won't do that, certainly not anytime soon.

> Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
> 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think
> there were accuracy issues at certain values etc.. So remember to do a
> off mode type PM tests as well before you consider requesting these to
> be merged.

Thanks a lot for a pointer. 3x 100uA power draw when you enable
temperature sensor, because it also errorneously enables MMC. I wonder
how the solution would look in the device tree...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-30 18:00               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-30 18:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon 2014-12-29 14:35:55, Nishanth Menon wrote:
> On 12/29/2014 12:15 PM, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> >> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> >>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> >>>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> >>>> which can be used to determine the SoCs temperature. This patch provides
> >>>> a DT based driver for the temperature sensor based on an older driver
> >>>> written by Peter De Schrijver for the Nokia N900 and N9.
> >>>
> >>> The sensor looks like an earlier iteration of sensors used in newer
> >>> OMAPs, which are already supported by maybe
> >>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> >>> that driver instead?
> >>
> >> Just to be clear - OMAP4 is the first time that the sensors were
> >> reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> 
> Just be careful when you try to make thermal policy like decisions
> based on this sensor. Placement of the sensor w.r.t the actual logic

I guess we won't do that, certainly not anytime soon.

> Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
> 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think
> there were accuracy issues at certain values etc.. So remember to do a
> off mode type PM tests as well before you consider requesting these to
> be merged.

Thanks a lot for a pointer. 3x 100uA power draw when you enable
temperature sensor, because it also errorneously enables MMC. I wonder
how the solution would look in the device tree...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-30 18:00               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-30 18:00 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Grazvydas Ignotas, Sebastian Reichel, Mark Rutland, dt list,
	Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala,
	linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, Guenter Roeck,
	linux-arm-kernel

On Mon 2014-12-29 14:35:55, Nishanth Menon wrote:
> On 12/29/2014 12:15 PM, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> >> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> >>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> >>>> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> >>>> which can be used to determine the SoCs temperature. This patch provides
> >>>> a DT based driver for the temperature sensor based on an older driver
> >>>> written by Peter De Schrijver for the Nokia N900 and N9.
> >>>
> >>> The sensor looks like an earlier iteration of sensors used in newer
> >>> OMAPs, which are already supported by maybe
> >>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> >>> that driver instead?
> >>
> >> Just to be clear - OMAP4 is the first time that the sensors were
> >> reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> 
> Just be careful when you try to make thermal policy like decisions
> based on this sensor. Placement of the sensor w.r.t the actual logic

I guess we won't do that, certainly not anytime soon.

> Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
> 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think
> there were accuracy issues at certain values etc.. So remember to do a
> off mode type PM tests as well before you consider requesting these to
> be merged.

Thanks a lot for a pointer. 3x 100uA power draw when you enable
temperature sensor, because it also errorneously enables MMC. I wonder
how the solution would look in the device tree...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-30 22:46               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-30 22:46 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel,
	eduardo.valentin

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

The hardware registers are named the same way...

Unfortunately, TI moves registers around with each release, and OMAP4
stuff is _way_ more complex and maze of ifdefs, too.

static struct temp_sensor_data omap4430_mpu_temp_sensor_data = {
        .min_freq = OMAP4430_MIN_FREQ,
 	.max_freq = OMAP4430_MAX_FREQ,
 	.max_temp = OMAP4430_MAX_TEMP,
	.min_temp = OMAP4430_MIN_TEMP,
 	.hyst_val = OMAP4430_HYST_VAL,
	};

and each define used just once. Would be easier to read and modify if
the ifdefs were removed...
	
Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-30 22:46               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-30 22:46 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	eduardo.valentin-l0cyMroinI0

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

The hardware registers are named the same way...

Unfortunately, TI moves registers around with each release, and OMAP4
stuff is _way_ more complex and maze of ifdefs, too.

static struct temp_sensor_data omap4430_mpu_temp_sensor_data = {
        .min_freq = OMAP4430_MIN_FREQ,
 	.max_freq = OMAP4430_MAX_FREQ,
 	.max_temp = OMAP4430_MAX_TEMP,
	.min_temp = OMAP4430_MIN_TEMP,
 	.hyst_val = OMAP4430_HYST_VAL,
	};

and each define used just once. Would be easier to read and modify if
the ifdefs were removed...
	
Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-30 22:46               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-30 22:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

The hardware registers are named the same way...

Unfortunately, TI moves registers around with each release, and OMAP4
stuff is _way_ more complex and maze of ifdefs, too.

static struct temp_sensor_data omap4430_mpu_temp_sensor_data = {
        .min_freq = OMAP4430_MIN_FREQ,
 	.max_freq = OMAP4430_MAX_FREQ,
 	.max_temp = OMAP4430_MAX_TEMP,
	.min_temp = OMAP4430_MIN_TEMP,
 	.hyst_val = OMAP4430_HYST_VAL,
	};

and each define used just once. Would be easier to read and modify if
the ifdefs were removed...
	
Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2014-12-30 22:46               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2014-12-30 22:46 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel,
	eduardo.valentin

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

The hardware registers are named the same way...

Unfortunately, TI moves registers around with each release, and OMAP4
stuff is _way_ more complex and maze of ifdefs, too.

static struct temp_sensor_data omap4430_mpu_temp_sensor_data = {
        .min_freq = OMAP4430_MIN_FREQ,
 	.max_freq = OMAP4430_MAX_FREQ,
 	.max_temp = OMAP4430_MAX_TEMP,
	.min_temp = OMAP4430_MIN_TEMP,
 	.hyst_val = OMAP4430_HYST_VAL,
	};

and each define used just once. Would be easier to read and modify if
the ifdefs were removed...
	
Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-29 19:04             ` Guenter Roeck
  (?)
@ 2015-01-01  9:11               ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-01  9:11 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

The hardware seems similar, but omap4 has a lot more
features... Here's a test patch. It compiles and boots, but I'm too
far away from my working userland at this moment.

Best regards,
								Pavel

commit 116612364f93b165b22166f0043117059eb3118f
Author: Pavel <pavel@ucw.cz>
Date:   Wed Dec 31 00:36:40 2014 +0100

    Configure ti-soc-thermal to handle n900's thermal sensor.

diff --git a/.config b/.config
index b031e7f..4a79672 100644
--- a/.config
+++ b/.config
@@ -1671,7 +1671,23 @@ CONFIG_SENSORS_TWL4030_MADC=y
 # CONFIG_SENSORS_W83L786NG is not set
 # CONFIG_SENSORS_W83627HF is not set
 # CONFIG_SENSORS_W83627EHF is not set
-# CONFIG_THERMAL is not set
+CONFIG_THERMAL=y
+CONFIG_THERMAL_HWMON=y
+CONFIG_THERMAL_OF=y
+CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
+# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
+# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
+# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
+CONFIG_THERMAL_GOV_STEP_WISE=y
+# CONFIG_THERMAL_GOV_BANG_BANG is not set
+# CONFIG_THERMAL_GOV_USER_SPACE is not set
+# CONFIG_CLOCK_THERMAL is not set
+# CONFIG_THERMAL_EMULATION is not set
+
+#
+# Texas Instruments thermal drivers
+#
+CONFIG_TI_SOC_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_WATCHDOG_CORE=y
 # CONFIG_WATCHDOG_NOWAYOUT is not set
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 55e4928..dcbcaa9 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -29,6 +29,13 @@
 		};
 	};
 
+	bandgap: bandgap {
+			reg = <0x4a002524 0x4>;
+			compatible = "ti,omap34xx-bandgap";
+
+			#thermal-sensor-cells = <0>;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 		heartbeat {
diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..27ff2ed 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
 ti-soc-thermal-y			:= ti-bandgap.o
 ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
 ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
+ti-soc-thermal-y			+= omap3-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 0000000..7e25ccd
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,94 @@
+/*
+ * OMAP4 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include "ti-thermal.h"
+#include "ti-bandgap.h"
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+	.temp_sensor_ctrl = 0,
+	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
+	.bgap_soc_mask = BIT(8),
+	.bgap_eocz_mask = BIT(7),
+	.bgap_dtemp_mask = 0x7f,
+
+	.bgap_mode_ctrl = 0,
+	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
+
+	.bgap_efuse = 0,
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+	.min_freq = 100000,
+	.max_freq = 1000000,
+	.max_temp = -99000,
+	.min_temp = 99000,
+	.hyst_val = 5000,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ * ADC code values from 530 to 923
+ */
+static const int
+omap34xx_adc_to_temp[] = {
+	-38000, -35000, -34000, -32000, -30000, -28000, -26000, -24000, -22000,
+	-20000, -18000, -17000, -15000, -13000, -12000, -10000, -8000, -6000,
+	-5000, -3000, -1000, 0, 2000, 3000, 5000, 6000, 8000, 10000, 12000,
+	13000, 15000, 17000, 19000, 21000, 23000, 25000, 27000, 28000, 30000,
+	32000, 33000, 35000, 37000, 38000, 40000, 42000, 43000, 45000, 47000,
+	48000, 50000, 52000, 53000, 55000, 57000, 58000, 60000, 62000, 64000,
+	66000, 68000, 70000, 71000, 73000, 75000, 77000, 78000, 80000, 82000,
+	83000, 85000, 87000, 88000, 90000, 92000, 93000, 95000, 97000, 98000,
+	100000, 102000, 103000, 105000, 107000, 109000, 111000, 113000, 115000,
+	117000, 118000, 120000, 122000, 123000,
+};
+
+/* OMAP34XX data */
+const struct ti_bandgap_data omap34xx_data = {
+	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
+	.fclock_name = "ts_fclk",
+	.div_ck_name = "ts_fclk",
+	.conv_table = omap34xx_adc_to_temp,
+	.adc_start_val = 0,
+	.adc_end_val = 127,
+	.expose_sensor = ti_thermal_expose_sensor,
+	.remove_sensor = ti_thermal_remove_sensor,
+
+	.sensors = {
+		{
+		.registers = &omap34xx_mpu_temp_sensor_registers,
+		.ts_data = &omap34xx_mpu_temp_sensor_data,
+		.domain = "cpu",
+		.slope = 0,
+		.constant = 20000,
+		.slope_pcb = 0,
+		.constant_pcb = 20000,
+		.register_cooling = NULL,
+		.unregister_cooling = NULL,
+		},
+	},
+	.sensor_count = 1,
+
+	.sensor_count = 0,
+};
+
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..2a72adc 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -856,7 +856,7 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
 	temp = ti_bandgap_read_temp(bgp, id);
 	spin_unlock(&bgp->lock);
 
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret)
 		return -EIO;
 
@@ -1509,6 +1509,10 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
 #endif
 
 static const struct of_device_id of_ti_bandgap_match[] = {
+	{
+		.compatible = "ti,omap34xx-bandgap",
+		.data = (void *)&omap34xx_data,
+	},
 #ifdef CONFIG_OMAP4_THERMAL
 	{
 		.compatible = "ti,omap4430-bandgap",
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b3adf72..3f05386 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
 void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
 int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
 
+extern const struct ti_bandgap_data omap34xx_data;
+
 #ifdef CONFIG_OMAP4_THERMAL
 extern const struct ti_bandgap_data omap4430_data;
 extern const struct ti_bandgap_data omap4460_data;


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-01  9:11               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-01  9:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

The hardware seems similar, but omap4 has a lot more
features... Here's a test patch. It compiles and boots, but I'm too
far away from my working userland at this moment.

Best regards,
								Pavel

commit 116612364f93b165b22166f0043117059eb3118f
Author: Pavel <pavel@ucw.cz>
Date:   Wed Dec 31 00:36:40 2014 +0100

    Configure ti-soc-thermal to handle n900's thermal sensor.

diff --git a/.config b/.config
index b031e7f..4a79672 100644
--- a/.config
+++ b/.config
@@ -1671,7 +1671,23 @@ CONFIG_SENSORS_TWL4030_MADC=y
 # CONFIG_SENSORS_W83L786NG is not set
 # CONFIG_SENSORS_W83627HF is not set
 # CONFIG_SENSORS_W83627EHF is not set
-# CONFIG_THERMAL is not set
+CONFIG_THERMAL=y
+CONFIG_THERMAL_HWMON=y
+CONFIG_THERMAL_OF=y
+CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
+# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
+# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
+# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
+CONFIG_THERMAL_GOV_STEP_WISE=y
+# CONFIG_THERMAL_GOV_BANG_BANG is not set
+# CONFIG_THERMAL_GOV_USER_SPACE is not set
+# CONFIG_CLOCK_THERMAL is not set
+# CONFIG_THERMAL_EMULATION is not set
+
+#
+# Texas Instruments thermal drivers
+#
+CONFIG_TI_SOC_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_WATCHDOG_CORE=y
 # CONFIG_WATCHDOG_NOWAYOUT is not set
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 55e4928..dcbcaa9 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -29,6 +29,13 @@
 		};
 	};
 
+	bandgap: bandgap {
+			reg = <0x4a002524 0x4>;
+			compatible = "ti,omap34xx-bandgap";
+
+			#thermal-sensor-cells = <0>;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 		heartbeat {
diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..27ff2ed 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
 ti-soc-thermal-y			:= ti-bandgap.o
 ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
 ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
+ti-soc-thermal-y			+= omap3-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 0000000..7e25ccd
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,94 @@
+/*
+ * OMAP4 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include "ti-thermal.h"
+#include "ti-bandgap.h"
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+	.temp_sensor_ctrl = 0,
+	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
+	.bgap_soc_mask = BIT(8),
+	.bgap_eocz_mask = BIT(7),
+	.bgap_dtemp_mask = 0x7f,
+
+	.bgap_mode_ctrl = 0,
+	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
+
+	.bgap_efuse = 0,
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+	.min_freq = 100000,
+	.max_freq = 1000000,
+	.max_temp = -99000,
+	.min_temp = 99000,
+	.hyst_val = 5000,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ * ADC code values from 530 to 923
+ */
+static const int
+omap34xx_adc_to_temp[] = {
+	-38000, -35000, -34000, -32000, -30000, -28000, -26000, -24000, -22000,
+	-20000, -18000, -17000, -15000, -13000, -12000, -10000, -8000, -6000,
+	-5000, -3000, -1000, 0, 2000, 3000, 5000, 6000, 8000, 10000, 12000,
+	13000, 15000, 17000, 19000, 21000, 23000, 25000, 27000, 28000, 30000,
+	32000, 33000, 35000, 37000, 38000, 40000, 42000, 43000, 45000, 47000,
+	48000, 50000, 52000, 53000, 55000, 57000, 58000, 60000, 62000, 64000,
+	66000, 68000, 70000, 71000, 73000, 75000, 77000, 78000, 80000, 82000,
+	83000, 85000, 87000, 88000, 90000, 92000, 93000, 95000, 97000, 98000,
+	100000, 102000, 103000, 105000, 107000, 109000, 111000, 113000, 115000,
+	117000, 118000, 120000, 122000, 123000,
+};
+
+/* OMAP34XX data */
+const struct ti_bandgap_data omap34xx_data = {
+	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
+	.fclock_name = "ts_fclk",
+	.div_ck_name = "ts_fclk",
+	.conv_table = omap34xx_adc_to_temp,
+	.adc_start_val = 0,
+	.adc_end_val = 127,
+	.expose_sensor = ti_thermal_expose_sensor,
+	.remove_sensor = ti_thermal_remove_sensor,
+
+	.sensors = {
+		{
+		.registers = &omap34xx_mpu_temp_sensor_registers,
+		.ts_data = &omap34xx_mpu_temp_sensor_data,
+		.domain = "cpu",
+		.slope = 0,
+		.constant = 20000,
+		.slope_pcb = 0,
+		.constant_pcb = 20000,
+		.register_cooling = NULL,
+		.unregister_cooling = NULL,
+		},
+	},
+	.sensor_count = 1,
+
+	.sensor_count = 0,
+};
+
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..2a72adc 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -856,7 +856,7 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
 	temp = ti_bandgap_read_temp(bgp, id);
 	spin_unlock(&bgp->lock);
 
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret)
 		return -EIO;
 
@@ -1509,6 +1509,10 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
 #endif
 
 static const struct of_device_id of_ti_bandgap_match[] = {
+	{
+		.compatible = "ti,omap34xx-bandgap",
+		.data = (void *)&omap34xx_data,
+	},
 #ifdef CONFIG_OMAP4_THERMAL
 	{
 		.compatible = "ti,omap4430-bandgap",
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b3adf72..3f05386 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
 void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
 int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
 
+extern const struct ti_bandgap_data omap34xx_data;
+
 #ifdef CONFIG_OMAP4_THERMAL
 extern const struct ti_bandgap_data omap4430_data;
 extern const struct ti_bandgap_data omap4460_data;


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-01  9:11               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-01  9:11 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

The hardware seems similar, but omap4 has a lot more
features... Here's a test patch. It compiles and boots, but I'm too
far away from my working userland at this moment.

Best regards,
								Pavel

commit 116612364f93b165b22166f0043117059eb3118f
Author: Pavel <pavel@ucw.cz>
Date:   Wed Dec 31 00:36:40 2014 +0100

    Configure ti-soc-thermal to handle n900's thermal sensor.

diff --git a/.config b/.config
index b031e7f..4a79672 100644
--- a/.config
+++ b/.config
@@ -1671,7 +1671,23 @@ CONFIG_SENSORS_TWL4030_MADC=y
 # CONFIG_SENSORS_W83L786NG is not set
 # CONFIG_SENSORS_W83627HF is not set
 # CONFIG_SENSORS_W83627EHF is not set
-# CONFIG_THERMAL is not set
+CONFIG_THERMAL=y
+CONFIG_THERMAL_HWMON=y
+CONFIG_THERMAL_OF=y
+CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
+# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
+# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
+# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
+CONFIG_THERMAL_GOV_STEP_WISE=y
+# CONFIG_THERMAL_GOV_BANG_BANG is not set
+# CONFIG_THERMAL_GOV_USER_SPACE is not set
+# CONFIG_CLOCK_THERMAL is not set
+# CONFIG_THERMAL_EMULATION is not set
+
+#
+# Texas Instruments thermal drivers
+#
+CONFIG_TI_SOC_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_WATCHDOG_CORE=y
 # CONFIG_WATCHDOG_NOWAYOUT is not set
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 55e4928..dcbcaa9 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -29,6 +29,13 @@
 		};
 	};
 
+	bandgap: bandgap {
+			reg = <0x4a002524 0x4>;
+			compatible = "ti,omap34xx-bandgap";
+
+			#thermal-sensor-cells = <0>;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 		heartbeat {
diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..27ff2ed 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
 ti-soc-thermal-y			:= ti-bandgap.o
 ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
 ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
+ti-soc-thermal-y			+= omap3-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 0000000..7e25ccd
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,94 @@
+/*
+ * OMAP4 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include "ti-thermal.h"
+#include "ti-bandgap.h"
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+	.temp_sensor_ctrl = 0,
+	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
+	.bgap_soc_mask = BIT(8),
+	.bgap_eocz_mask = BIT(7),
+	.bgap_dtemp_mask = 0x7f,
+
+	.bgap_mode_ctrl = 0,
+	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
+
+	.bgap_efuse = 0,
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+	.min_freq = 100000,
+	.max_freq = 1000000,
+	.max_temp = -99000,
+	.min_temp = 99000,
+	.hyst_val = 5000,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ * ADC code values from 530 to 923
+ */
+static const int
+omap34xx_adc_to_temp[] = {
+	-38000, -35000, -34000, -32000, -30000, -28000, -26000, -24000, -22000,
+	-20000, -18000, -17000, -15000, -13000, -12000, -10000, -8000, -6000,
+	-5000, -3000, -1000, 0, 2000, 3000, 5000, 6000, 8000, 10000, 12000,
+	13000, 15000, 17000, 19000, 21000, 23000, 25000, 27000, 28000, 30000,
+	32000, 33000, 35000, 37000, 38000, 40000, 42000, 43000, 45000, 47000,
+	48000, 50000, 52000, 53000, 55000, 57000, 58000, 60000, 62000, 64000,
+	66000, 68000, 70000, 71000, 73000, 75000, 77000, 78000, 80000, 82000,
+	83000, 85000, 87000, 88000, 90000, 92000, 93000, 95000, 97000, 98000,
+	100000, 102000, 103000, 105000, 107000, 109000, 111000, 113000, 115000,
+	117000, 118000, 120000, 122000, 123000,
+};
+
+/* OMAP34XX data */
+const struct ti_bandgap_data omap34xx_data = {
+	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
+	.fclock_name = "ts_fclk",
+	.div_ck_name = "ts_fclk",
+	.conv_table = omap34xx_adc_to_temp,
+	.adc_start_val = 0,
+	.adc_end_val = 127,
+	.expose_sensor = ti_thermal_expose_sensor,
+	.remove_sensor = ti_thermal_remove_sensor,
+
+	.sensors = {
+		{
+		.registers = &omap34xx_mpu_temp_sensor_registers,
+		.ts_data = &omap34xx_mpu_temp_sensor_data,
+		.domain = "cpu",
+		.slope = 0,
+		.constant = 20000,
+		.slope_pcb = 0,
+		.constant_pcb = 20000,
+		.register_cooling = NULL,
+		.unregister_cooling = NULL,
+		},
+	},
+	.sensor_count = 1,
+
+	.sensor_count = 0,
+};
+
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..2a72adc 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -856,7 +856,7 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
 	temp = ti_bandgap_read_temp(bgp, id);
 	spin_unlock(&bgp->lock);
 
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret)
 		return -EIO;
 
@@ -1509,6 +1509,10 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
 #endif
 
 static const struct of_device_id of_ti_bandgap_match[] = {
+	{
+		.compatible = "ti,omap34xx-bandgap",
+		.data = (void *)&omap34xx_data,
+	},
 #ifdef CONFIG_OMAP4_THERMAL
 	{
 		.compatible = "ti,omap4430-bandgap",
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b3adf72..3f05386 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
 void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
 int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
 
+extern const struct ti_bandgap_data omap34xx_data;
+
 #ifdef CONFIG_OMAP4_THERMAL
 extern const struct ti_bandgap_data omap4430_data;
 extern const struct ti_bandgap_data omap4460_data;


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2014-12-29 19:04             ` Guenter Roeck
  (?)
@ 2015-01-03  9:18               ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-03  9:18 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

After some fixes... yes, it seems to be same hardware.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig
index bd4c7be..a49495f 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -21,6 +21,15 @@ config TI_THERMAL
 	  This includes trip points definitions, extrapolation rules and
 	  CPU cooling device bindings.
 
+config OMAP3_THERMAL
+	bool "Texas Instruments OMAP3 thermal support"
+	depends on TI_SOC_THERMAL
+	depends on ARCH_OMAP3
+	help
+	  If you say yes here you get thermal support for the Texas Instruments
+	  OMAP3 SoC family. The current chip supported are:
+	   - OMAP3430
+
 config OMAP4_THERMAL
 	bool "Texas Instruments OMAP4 thermal support"
 	depends on TI_SOC_THERMAL
diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..2b5b220 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
 ti-soc-thermal-y			:= ti-bandgap.o
 ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
 ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
+ti-soc-thermal-$(CONFIG_OMAP3_THERMAL)  += omap3-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 0000000..a79ebf2
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,99 @@
+/*
+ * OMAP3 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include "ti-thermal.h"
+#include "ti-bandgap.h"
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+	.temp_sensor_ctrl = 0,
+	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
+	.bgap_soc_mask = BIT(8),
+	.bgap_eocz_mask = BIT(7),
+	.bgap_dtemp_mask = 0x7f,
+
+	.bgap_mode_ctrl = 0,
+	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
+
+	.bgap_efuse = 0,
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+	.min_freq = 32768,
+	.max_freq = 32768,
+	.max_temp = -99000,
+	.min_temp = 99000,
+	.hyst_val = 5000,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ * ADC code values from 530 to 923
+ */
+static const int
+omap34xx_adc_to_temp[] = {
+	-40000, -40000, -40000, -40000, -40000, -39000, -38000, -36000,
+	-34000, -32000, -31000,	-29000, -28000, -26000, -25000, -24000,
+	-22000, -21000, -19000, -18000, -17000, -15000,	-14000, -12000,
+	-11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, 0000,
+	1000, 3000, 4000, 5000, 7000, 8000, 10000, 11000, 13000, 14000,
+	15000, 17000, 18000, 20000, 21000, 22000, 24000, 25000, 27000,
+	28000, 30000, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
+	41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
+	53000, 55000, 56000, 58000, 59000, 60000, 62000, 63000, 65000,
+	66000, 67000, 69000, 70000, 72000, 73000, 74000, 76000, 77000,
+	79000, 80000, 81000, 83000, 84000, 85000, 87000, 88000, 89000,
+	91000, 92000, 94000, 95000, 96000, 98000, 99000, 100000,
+	102000, 103000, 105000, 106000, 107000, 109000, 110000, 111000,
+	113000, 114000, 116000, 117000, 118000, 120000, 121000, 122000,
+	124000, 124000, 125000, 125000, 125000, 125000,	125000
+};
+
+/* OMAP34XX data */
+const struct ti_bandgap_data omap34xx_data = {
+	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
+	.fclock_name = "ts_fck",
+	.div_ck_name = "ts_fck",
+	.conv_table = omap34xx_adc_to_temp,
+	.adc_start_val = 0,
+	.adc_end_val = 127,
+	.expose_sensor = ti_thermal_expose_sensor,
+	.remove_sensor = ti_thermal_remove_sensor,
+
+	.sensors = {
+		{
+		.registers = &omap34xx_mpu_temp_sensor_registers,
+		.ts_data = &omap34xx_mpu_temp_sensor_data,
+		.domain = "cpu",
+		.slope = 0,
+		.constant = 20000,
+		.slope_pcb = 0,
+		.constant_pcb = 20000,
+		.register_cooling = NULL,
+		.unregister_cooling = NULL,
+		},
+	},
+	.sensor_count = 1,
+
+//	.sensor_count = 0,
+};
+
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..a4180a5 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -40,6 +40,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_gpio.h>
 #include <linux/io.h>
+#include <linux/delay.h>
 
 #include "ti-bandgap.h"
 
@@ -103,19 +104,15 @@ do {								\
  */
 static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
 {
-	int i, ret = 0;
+	int i;
 
-	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH)) {
-		ret = -ENOTSUPP;
-		goto exit;
-	}
+	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH))
+		return -ENOTSUPP;
 
 	for (i = 0; i < bgp->conf->sensor_count; i++)
 		/* active on 0 */
 		RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -154,6 +151,7 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp, int id)
 	if (TI_BANDGAP_HAS(bgp, FREEZE_BIT))
 		RMW_BITS(bgp, id, bgap_mask_ctrl, mask_freeze_mask, 0);
 
+	printk("Bandgap: ADC is %d\n", temp);
 	return temp;
 }
 
@@ -263,18 +261,13 @@ static
 int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
 {
 	const struct ti_bandgap_data *conf = bgp->conf;
-	int ret = 0;
 
 	/* look up for temperature in the table and return the temperature */
-	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val) {
-		ret = -ERANGE;
-		goto exit;
-	}
+	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val)
+		return -ERANGE;
 
 	*t = bgp->conf->conv_table[adc_val - conf->adc_start_val];
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -295,16 +288,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
 {
 	const struct ti_bandgap_data *conf = bgp->conf;
 	const int *conv_table = bgp->conf->conv_table;
-	int high, low, mid, ret = 0;
+	int high, low, mid;
 
 	low = 0;
 	high = conf->adc_end_val - conf->adc_start_val;
 	mid = (high + low) / 2;
 
-	if (temp < conv_table[low] || temp > conv_table[high]) {
-		ret = -ERANGE;
-		goto exit;
-	}
+	if (temp < conv_table[low] || temp > conv_table[high])
+		return -ERANGE;
 
 	while (low < high) {
 		if (temp < conv_table[mid])
@@ -315,9 +306,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
 	}
 
 	*adc = conf->adc_start_val + low;
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -343,13 +332,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int adc_val, int hyst_val,
 	 */
 	ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, &temp);
 	if (ret < 0)
-		goto exit;
+		return ret;
 
 	temp += hyst_val;
 
 	ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
-
-exit:
 	return ret;
 }
 
@@ -468,22 +455,18 @@ exit:
  */
 static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
 {
-	int ret = 0;
-
 	if (!bgp || IS_ERR(bgp)) {
 		pr_err("%s: invalid bandgap pointer\n", __func__);
-		ret = -EINVAL;
-		goto exit;
+		return -EINVAL;
 	}
 
 	if ((id < 0) || (id >= bgp->conf->sensor_count)) {
 		dev_err(bgp->dev, "%s: sensor id out of range (%d)\n",
 			__func__, id);
-		ret = -ERANGE;
+		return -ERANGE;
 	}
 
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -511,12 +494,10 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
 
 	ret = ti_bandgap_validate(bgp, id);
 	if (ret)
-		goto exit;
+		return ret;
 
-	if (!TI_BANDGAP_HAS(bgp, TALERT)) {
-		ret = -ENOTSUPP;
-		goto exit;
-	}
+	if (!TI_BANDGAP_HAS(bgp, TALERT))
+		return -ENOTSUPP;
 
 	ts_data = bgp->conf->sensors[id].ts_data;
 	tsr = bgp->conf->sensors[id].registers;
@@ -529,17 +510,15 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
 	}
 
 	if (ret)
-		goto exit;
-
+		return ret;
+	
 	ret = ti_bandgap_mcelsius_to_adc(bgp, val, &adc_val);
 	if (ret < 0)
-		goto exit;
+		return ret;		
 
 	spin_lock(&bgp->lock);
 	ret = ti_bandgap_update_alert_threshold(bgp, id, adc_val, hot);
 	spin_unlock(&bgp->lock);
-
-exit:
 	return ret;
 }
 
@@ -582,7 +561,7 @@ static int _ti_bandgap_read_threshold(struct ti_bandgap *bgp, int id,
 
 	temp = ti_bandgap_readl(bgp, tsr->bgap_threshold);
 	temp = (temp & mask) >> __ffs(mask);
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret) {
 		dev_err(bgp->dev, "failed to read thot\n");
 		ret = -EIO;
@@ -856,10 +835,11 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
 	temp = ti_bandgap_read_temp(bgp, id);
 	spin_unlock(&bgp->lock);
 
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret)
 		return -EIO;
 
+	printk("Bandgap: temperature is %d\n", temp);
 	*temperature = temp;
 
 	return 0;
@@ -918,6 +898,7 @@ static int
 ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
 {
 	u32 temp = 0, counter = 1000;
+	struct temp_sensor_registers *tsr;
 
 	/* Select single conversion mode */
 	if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
@@ -925,16 +906,26 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
 
 	/* Start of Conversion = 1 */
 	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
-	/* Wait until DTEMP is updated */
-	temp = ti_bandgap_read_temp(bgp, id);
 
-	while ((temp == 0) && --counter)
-		temp = ti_bandgap_read_temp(bgp, id);
-	/* REVISIT: Check correct condition for end of conversion */
+	/* Wait for EOCZ going up */
+	tsr = bgp->conf->sensors[id].registers;
+	
+	while (--counter) {
+		if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask)
+			break;
+		printk("@");
+	}
 
 	/* Start of Conversion = 0 */
 	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
 
+	counter = 1000;
+	while (--counter) {
+		if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask))
+			break;
+		printk("#");
+	}
+
 	return 0;
 }
 
@@ -1196,6 +1187,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
 	struct ti_bandgap *bgp;
 	int clk_rate, ret = 0, i;
 
+	printk("ti_bandgap: probe\n");
+
 	bgp = ti_bandgap_build(pdev);
 	if (IS_ERR(bgp)) {
 		dev_err(&pdev->dev, "failed to fetch platform data\n");
@@ -1220,11 +1213,10 @@ int ti_bandgap_probe(struct platform_device *pdev)
 		goto free_irqs;
 	}
 
-	bgp->div_clk = clk_get(NULL,  bgp->conf->div_ck_name);
+	bgp->div_clk = clk_get(NULL, bgp->conf->div_ck_name);
 	ret = IS_ERR(bgp->div_clk);
 	if (ret) {
-		dev_err(&pdev->dev,
-			"failed to request div_ts_ck clock ref\n");
+		dev_err(&pdev->dev, "failed to request div_ts_ck clock ref\n");
 		ret = PTR_ERR(bgp->div_clk);
 		goto free_irqs;
 	}
@@ -1312,6 +1304,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
 	/* Every thing is good? Then expose the sensors */
 	for (i = 0; i < bgp->conf->sensor_count; i++) {
 		char *domain;
+		extern int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
+					     char *domain);
 
 		if (bgp->conf->sensors[i].register_cooling) {
 			ret = bgp->conf->sensors[i].register_cooling(bgp, i);
@@ -1319,12 +1313,29 @@ int ti_bandgap_probe(struct platform_device *pdev)
 				goto remove_sensors;
 		}
 
+		printk("bandgap: exposing sensor: %p\n", bgp->conf->expose_sensor);
+		
 		if (bgp->conf->expose_sensor) {
+			printk("bandgap: calling %p %p\n", bgp->conf->expose_sensor, ti_thermal_expose_sensor);
 			domain = bgp->conf->sensors[i].domain;
 			ret = bgp->conf->expose_sensor(bgp, i, domain);
+			printk("bandgap: done\n");
 			if (ret)
 				goto remove_last_cooling;
 		}
+
+		printk("bandgap: exposing sensor\n");
+		{
+			int t;
+
+			ti_bandgap_force_single_read(bgp, 0);
+
+			t = ti_bandgap_read_temp(bgp, 0);
+			printk("Temperature ADC: %d\n", t);			
+			ti_bandgap_read_temperature(bgp, 0, &t);
+			printk("Temperature: %d\n", t);
+			mdelay(1000);
+		}
 	}
 
 	/*
@@ -1365,6 +1376,8 @@ free_irqs:
 		free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
 		gpio_free(bgp->tshut_gpio);
 	}
+	printk("ti_bandgap: probe: something failed\n");
+	mdelay(10000);
 
 	return ret;
 }
@@ -1509,6 +1522,12 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
 #endif
 
 static const struct of_device_id of_ti_bandgap_match[] = {
+#ifdef CONFIG_OMAP3_THERMAL
+	{
+		.compatible = "ti,omap34xx-bandgap",
+		.data = (void *)&omap34xx_data,
+	},
+#endif
 #ifdef CONFIG_OMAP4_THERMAL
 	{
 		.compatible = "ti,omap4430-bandgap",
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b3adf72..3f05386 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
 void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
 int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
 
+extern const struct ti_bandgap_data omap34xx_data;
+
 #ifdef CONFIG_OMAP4_THERMAL
 extern const struct ti_bandgap_data omap4430_data;
 extern const struct ti_bandgap_data omap4460_data;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 5fd0386..f91655f 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -328,18 +328,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
 {
 	struct ti_thermal_data *data;
 
+	printk("expose_sensor\n");
+
 	data = ti_bandgap_get_sensor_data(bgp, id);
 
 	if (!data || IS_ERR(data))
 		data = ti_thermal_build_data(bgp, id);
 
-	if (!data)
+	if (!data) {
+		printk("no data\n");	
 		return -EINVAL;
+	}
 
 	/* in case this is specified by DT */
 	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
 					data, &ti_of_thermal_ops);
 	if (IS_ERR(data->ti_thermal)) {
+		printk("of_sensor_register failed\n");
 		/* Create thermal zone */
 		data->ti_thermal = thermal_zone_device_register(domain,
 				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-03  9:18               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-03  9:18 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

After some fixes... yes, it seems to be same hardware.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig
index bd4c7be..a49495f 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -21,6 +21,15 @@ config TI_THERMAL
 	  This includes trip points definitions, extrapolation rules and
 	  CPU cooling device bindings.
 
+config OMAP3_THERMAL
+	bool "Texas Instruments OMAP3 thermal support"
+	depends on TI_SOC_THERMAL
+	depends on ARCH_OMAP3
+	help
+	  If you say yes here you get thermal support for the Texas Instruments
+	  OMAP3 SoC family. The current chip supported are:
+	   - OMAP3430
+
 config OMAP4_THERMAL
 	bool "Texas Instruments OMAP4 thermal support"
 	depends on TI_SOC_THERMAL
diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..2b5b220 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
 ti-soc-thermal-y			:= ti-bandgap.o
 ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
 ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
+ti-soc-thermal-$(CONFIG_OMAP3_THERMAL)  += omap3-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 0000000..a79ebf2
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,99 @@
+/*
+ * OMAP3 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include "ti-thermal.h"
+#include "ti-bandgap.h"
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+	.temp_sensor_ctrl = 0,
+	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
+	.bgap_soc_mask = BIT(8),
+	.bgap_eocz_mask = BIT(7),
+	.bgap_dtemp_mask = 0x7f,
+
+	.bgap_mode_ctrl = 0,
+	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
+
+	.bgap_efuse = 0,
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+	.min_freq = 32768,
+	.max_freq = 32768,
+	.max_temp = -99000,
+	.min_temp = 99000,
+	.hyst_val = 5000,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ * ADC code values from 530 to 923
+ */
+static const int
+omap34xx_adc_to_temp[] = {
+	-40000, -40000, -40000, -40000, -40000, -39000, -38000, -36000,
+	-34000, -32000, -31000,	-29000, -28000, -26000, -25000, -24000,
+	-22000, -21000, -19000, -18000, -17000, -15000,	-14000, -12000,
+	-11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, 0000,
+	1000, 3000, 4000, 5000, 7000, 8000, 10000, 11000, 13000, 14000,
+	15000, 17000, 18000, 20000, 21000, 22000, 24000, 25000, 27000,
+	28000, 30000, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
+	41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
+	53000, 55000, 56000, 58000, 59000, 60000, 62000, 63000, 65000,
+	66000, 67000, 69000, 70000, 72000, 73000, 74000, 76000, 77000,
+	79000, 80000, 81000, 83000, 84000, 85000, 87000, 88000, 89000,
+	91000, 92000, 94000, 95000, 96000, 98000, 99000, 100000,
+	102000, 103000, 105000, 106000, 107000, 109000, 110000, 111000,
+	113000, 114000, 116000, 117000, 118000, 120000, 121000, 122000,
+	124000, 124000, 125000, 125000, 125000, 125000,	125000
+};
+
+/* OMAP34XX data */
+const struct ti_bandgap_data omap34xx_data = {
+	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
+	.fclock_name = "ts_fck",
+	.div_ck_name = "ts_fck",
+	.conv_table = omap34xx_adc_to_temp,
+	.adc_start_val = 0,
+	.adc_end_val = 127,
+	.expose_sensor = ti_thermal_expose_sensor,
+	.remove_sensor = ti_thermal_remove_sensor,
+
+	.sensors = {
+		{
+		.registers = &omap34xx_mpu_temp_sensor_registers,
+		.ts_data = &omap34xx_mpu_temp_sensor_data,
+		.domain = "cpu",
+		.slope = 0,
+		.constant = 20000,
+		.slope_pcb = 0,
+		.constant_pcb = 20000,
+		.register_cooling = NULL,
+		.unregister_cooling = NULL,
+		},
+	},
+	.sensor_count = 1,
+
+//	.sensor_count = 0,
+};
+
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..a4180a5 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -40,6 +40,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_gpio.h>
 #include <linux/io.h>
+#include <linux/delay.h>
 
 #include "ti-bandgap.h"
 
@@ -103,19 +104,15 @@ do {								\
  */
 static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
 {
-	int i, ret = 0;
+	int i;
 
-	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH)) {
-		ret = -ENOTSUPP;
-		goto exit;
-	}
+	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH))
+		return -ENOTSUPP;
 
 	for (i = 0; i < bgp->conf->sensor_count; i++)
 		/* active on 0 */
 		RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -154,6 +151,7 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp, int id)
 	if (TI_BANDGAP_HAS(bgp, FREEZE_BIT))
 		RMW_BITS(bgp, id, bgap_mask_ctrl, mask_freeze_mask, 0);
 
+	printk("Bandgap: ADC is %d\n", temp);
 	return temp;
 }
 
@@ -263,18 +261,13 @@ static
 int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
 {
 	const struct ti_bandgap_data *conf = bgp->conf;
-	int ret = 0;
 
 	/* look up for temperature in the table and return the temperature */
-	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val) {
-		ret = -ERANGE;
-		goto exit;
-	}
+	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val)
+		return -ERANGE;
 
 	*t = bgp->conf->conv_table[adc_val - conf->adc_start_val];
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -295,16 +288,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
 {
 	const struct ti_bandgap_data *conf = bgp->conf;
 	const int *conv_table = bgp->conf->conv_table;
-	int high, low, mid, ret = 0;
+	int high, low, mid;
 
 	low = 0;
 	high = conf->adc_end_val - conf->adc_start_val;
 	mid = (high + low) / 2;
 
-	if (temp < conv_table[low] || temp > conv_table[high]) {
-		ret = -ERANGE;
-		goto exit;
-	}
+	if (temp < conv_table[low] || temp > conv_table[high])
+		return -ERANGE;
 
 	while (low < high) {
 		if (temp < conv_table[mid])
@@ -315,9 +306,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
 	}
 
 	*adc = conf->adc_start_val + low;
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -343,13 +332,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int adc_val, int hyst_val,
 	 */
 	ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, &temp);
 	if (ret < 0)
-		goto exit;
+		return ret;
 
 	temp += hyst_val;
 
 	ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
-
-exit:
 	return ret;
 }
 
@@ -468,22 +455,18 @@ exit:
  */
 static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
 {
-	int ret = 0;
-
 	if (!bgp || IS_ERR(bgp)) {
 		pr_err("%s: invalid bandgap pointer\n", __func__);
-		ret = -EINVAL;
-		goto exit;
+		return -EINVAL;
 	}
 
 	if ((id < 0) || (id >= bgp->conf->sensor_count)) {
 		dev_err(bgp->dev, "%s: sensor id out of range (%d)\n",
 			__func__, id);
-		ret = -ERANGE;
+		return -ERANGE;
 	}
 
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -511,12 +494,10 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
 
 	ret = ti_bandgap_validate(bgp, id);
 	if (ret)
-		goto exit;
+		return ret;
 
-	if (!TI_BANDGAP_HAS(bgp, TALERT)) {
-		ret = -ENOTSUPP;
-		goto exit;
-	}
+	if (!TI_BANDGAP_HAS(bgp, TALERT))
+		return -ENOTSUPP;
 
 	ts_data = bgp->conf->sensors[id].ts_data;
 	tsr = bgp->conf->sensors[id].registers;
@@ -529,17 +510,15 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
 	}
 
 	if (ret)
-		goto exit;
-
+		return ret;
+	
 	ret = ti_bandgap_mcelsius_to_adc(bgp, val, &adc_val);
 	if (ret < 0)
-		goto exit;
+		return ret;		
 
 	spin_lock(&bgp->lock);
 	ret = ti_bandgap_update_alert_threshold(bgp, id, adc_val, hot);
 	spin_unlock(&bgp->lock);
-
-exit:
 	return ret;
 }
 
@@ -582,7 +561,7 @@ static int _ti_bandgap_read_threshold(struct ti_bandgap *bgp, int id,
 
 	temp = ti_bandgap_readl(bgp, tsr->bgap_threshold);
 	temp = (temp & mask) >> __ffs(mask);
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret) {
 		dev_err(bgp->dev, "failed to read thot\n");
 		ret = -EIO;
@@ -856,10 +835,11 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
 	temp = ti_bandgap_read_temp(bgp, id);
 	spin_unlock(&bgp->lock);
 
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret)
 		return -EIO;
 
+	printk("Bandgap: temperature is %d\n", temp);
 	*temperature = temp;
 
 	return 0;
@@ -918,6 +898,7 @@ static int
 ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
 {
 	u32 temp = 0, counter = 1000;
+	struct temp_sensor_registers *tsr;
 
 	/* Select single conversion mode */
 	if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
@@ -925,16 +906,26 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
 
 	/* Start of Conversion = 1 */
 	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
-	/* Wait until DTEMP is updated */
-	temp = ti_bandgap_read_temp(bgp, id);
 
-	while ((temp == 0) && --counter)
-		temp = ti_bandgap_read_temp(bgp, id);
-	/* REVISIT: Check correct condition for end of conversion */
+	/* Wait for EOCZ going up */
+	tsr = bgp->conf->sensors[id].registers;
+	
+	while (--counter) {
+		if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask)
+			break;
+		printk("@");
+	}
 
 	/* Start of Conversion = 0 */
 	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
 
+	counter = 1000;
+	while (--counter) {
+		if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask))
+			break;
+		printk("#");
+	}
+
 	return 0;
 }
 
@@ -1196,6 +1187,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
 	struct ti_bandgap *bgp;
 	int clk_rate, ret = 0, i;
 
+	printk("ti_bandgap: probe\n");
+
 	bgp = ti_bandgap_build(pdev);
 	if (IS_ERR(bgp)) {
 		dev_err(&pdev->dev, "failed to fetch platform data\n");
@@ -1220,11 +1213,10 @@ int ti_bandgap_probe(struct platform_device *pdev)
 		goto free_irqs;
 	}
 
-	bgp->div_clk = clk_get(NULL,  bgp->conf->div_ck_name);
+	bgp->div_clk = clk_get(NULL, bgp->conf->div_ck_name);
 	ret = IS_ERR(bgp->div_clk);
 	if (ret) {
-		dev_err(&pdev->dev,
-			"failed to request div_ts_ck clock ref\n");
+		dev_err(&pdev->dev, "failed to request div_ts_ck clock ref\n");
 		ret = PTR_ERR(bgp->div_clk);
 		goto free_irqs;
 	}
@@ -1312,6 +1304,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
 	/* Every thing is good? Then expose the sensors */
 	for (i = 0; i < bgp->conf->sensor_count; i++) {
 		char *domain;
+		extern int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
+					     char *domain);
 
 		if (bgp->conf->sensors[i].register_cooling) {
 			ret = bgp->conf->sensors[i].register_cooling(bgp, i);
@@ -1319,12 +1313,29 @@ int ti_bandgap_probe(struct platform_device *pdev)
 				goto remove_sensors;
 		}
 
+		printk("bandgap: exposing sensor: %p\n", bgp->conf->expose_sensor);
+		
 		if (bgp->conf->expose_sensor) {
+			printk("bandgap: calling %p %p\n", bgp->conf->expose_sensor, ti_thermal_expose_sensor);
 			domain = bgp->conf->sensors[i].domain;
 			ret = bgp->conf->expose_sensor(bgp, i, domain);
+			printk("bandgap: done\n");
 			if (ret)
 				goto remove_last_cooling;
 		}
+
+		printk("bandgap: exposing sensor\n");
+		{
+			int t;
+
+			ti_bandgap_force_single_read(bgp, 0);
+
+			t = ti_bandgap_read_temp(bgp, 0);
+			printk("Temperature ADC: %d\n", t);			
+			ti_bandgap_read_temperature(bgp, 0, &t);
+			printk("Temperature: %d\n", t);
+			mdelay(1000);
+		}
 	}
 
 	/*
@@ -1365,6 +1376,8 @@ free_irqs:
 		free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
 		gpio_free(bgp->tshut_gpio);
 	}
+	printk("ti_bandgap: probe: something failed\n");
+	mdelay(10000);
 
 	return ret;
 }
@@ -1509,6 +1522,12 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
 #endif
 
 static const struct of_device_id of_ti_bandgap_match[] = {
+#ifdef CONFIG_OMAP3_THERMAL
+	{
+		.compatible = "ti,omap34xx-bandgap",
+		.data = (void *)&omap34xx_data,
+	},
+#endif
 #ifdef CONFIG_OMAP4_THERMAL
 	{
 		.compatible = "ti,omap4430-bandgap",
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b3adf72..3f05386 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
 void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
 int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
 
+extern const struct ti_bandgap_data omap34xx_data;
+
 #ifdef CONFIG_OMAP4_THERMAL
 extern const struct ti_bandgap_data omap4430_data;
 extern const struct ti_bandgap_data omap4460_data;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 5fd0386..f91655f 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -328,18 +328,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
 {
 	struct ti_thermal_data *data;
 
+	printk("expose_sensor\n");
+
 	data = ti_bandgap_get_sensor_data(bgp, id);
 
 	if (!data || IS_ERR(data))
 		data = ti_thermal_build_data(bgp, id);
 
-	if (!data)
+	if (!data) {
+		printk("no data\n");	
 		return -EINVAL;
+	}
 
 	/* in case this is specified by DT */
 	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
 					data, &ti_of_thermal_ops);
 	if (IS_ERR(data->ti_thermal)) {
+		printk("of_sensor_register failed\n");
 		/* Create thermal zone */
 		data->ti_thermal = thermal_zone_device_register(domain,
 				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-03  9:18               ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-03  9:18 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > >> which can be used to determine the SoCs temperature. This patch provides
> > > >> a DT based driver for the temperature sensor based on an older driver
> > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > >
> > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > OMAPs, which are already supported by maybe
> > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > that driver instead?
> > > 
> > > Just to be clear - OMAP4 is the first time that the sensors were
> > > reliable enough to be used.
> > 
> > When testing initial version of the patch, they seem to work very well
> > in the omap3 case.
> > 
> Pavel,
> 
> can you look into the omap4 thermal driver to see if it can be used ?

After some fixes... yes, it seems to be same hardware.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig
index bd4c7be..a49495f 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -21,6 +21,15 @@ config TI_THERMAL
 	  This includes trip points definitions, extrapolation rules and
 	  CPU cooling device bindings.
 
+config OMAP3_THERMAL
+	bool "Texas Instruments OMAP3 thermal support"
+	depends on TI_SOC_THERMAL
+	depends on ARCH_OMAP3
+	help
+	  If you say yes here you get thermal support for the Texas Instruments
+	  OMAP3 SoC family. The current chip supported are:
+	   - OMAP3430
+
 config OMAP4_THERMAL
 	bool "Texas Instruments OMAP4 thermal support"
 	depends on TI_SOC_THERMAL
diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..2b5b220 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
 ti-soc-thermal-y			:= ti-bandgap.o
 ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
 ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
+ti-soc-thermal-$(CONFIG_OMAP3_THERMAL)  += omap3-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 0000000..a79ebf2
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,99 @@
+/*
+ * OMAP3 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include "ti-thermal.h"
+#include "ti-bandgap.h"
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+	.temp_sensor_ctrl = 0,
+	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
+	.bgap_soc_mask = BIT(8),
+	.bgap_eocz_mask = BIT(7),
+	.bgap_dtemp_mask = 0x7f,
+
+	.bgap_mode_ctrl = 0,
+	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
+
+	.bgap_efuse = 0,
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+	.min_freq = 32768,
+	.max_freq = 32768,
+	.max_temp = -99000,
+	.min_temp = 99000,
+	.hyst_val = 5000,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ * ADC code values from 530 to 923
+ */
+static const int
+omap34xx_adc_to_temp[] = {
+	-40000, -40000, -40000, -40000, -40000, -39000, -38000, -36000,
+	-34000, -32000, -31000,	-29000, -28000, -26000, -25000, -24000,
+	-22000, -21000, -19000, -18000, -17000, -15000,	-14000, -12000,
+	-11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, 0000,
+	1000, 3000, 4000, 5000, 7000, 8000, 10000, 11000, 13000, 14000,
+	15000, 17000, 18000, 20000, 21000, 22000, 24000, 25000, 27000,
+	28000, 30000, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
+	41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
+	53000, 55000, 56000, 58000, 59000, 60000, 62000, 63000, 65000,
+	66000, 67000, 69000, 70000, 72000, 73000, 74000, 76000, 77000,
+	79000, 80000, 81000, 83000, 84000, 85000, 87000, 88000, 89000,
+	91000, 92000, 94000, 95000, 96000, 98000, 99000, 100000,
+	102000, 103000, 105000, 106000, 107000, 109000, 110000, 111000,
+	113000, 114000, 116000, 117000, 118000, 120000, 121000, 122000,
+	124000, 124000, 125000, 125000, 125000, 125000,	125000
+};
+
+/* OMAP34XX data */
+const struct ti_bandgap_data omap34xx_data = {
+	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
+	.fclock_name = "ts_fck",
+	.div_ck_name = "ts_fck",
+	.conv_table = omap34xx_adc_to_temp,
+	.adc_start_val = 0,
+	.adc_end_val = 127,
+	.expose_sensor = ti_thermal_expose_sensor,
+	.remove_sensor = ti_thermal_remove_sensor,
+
+	.sensors = {
+		{
+		.registers = &omap34xx_mpu_temp_sensor_registers,
+		.ts_data = &omap34xx_mpu_temp_sensor_data,
+		.domain = "cpu",
+		.slope = 0,
+		.constant = 20000,
+		.slope_pcb = 0,
+		.constant_pcb = 20000,
+		.register_cooling = NULL,
+		.unregister_cooling = NULL,
+		},
+	},
+	.sensor_count = 1,
+
+//	.sensor_count = 0,
+};
+
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..a4180a5 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -40,6 +40,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_gpio.h>
 #include <linux/io.h>
+#include <linux/delay.h>
 
 #include "ti-bandgap.h"
 
@@ -103,19 +104,15 @@ do {								\
  */
 static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
 {
-	int i, ret = 0;
+	int i;
 
-	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH)) {
-		ret = -ENOTSUPP;
-		goto exit;
-	}
+	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH))
+		return -ENOTSUPP;
 
 	for (i = 0; i < bgp->conf->sensor_count; i++)
 		/* active on 0 */
 		RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -154,6 +151,7 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp, int id)
 	if (TI_BANDGAP_HAS(bgp, FREEZE_BIT))
 		RMW_BITS(bgp, id, bgap_mask_ctrl, mask_freeze_mask, 0);
 
+	printk("Bandgap: ADC is %d\n", temp);
 	return temp;
 }
 
@@ -263,18 +261,13 @@ static
 int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
 {
 	const struct ti_bandgap_data *conf = bgp->conf;
-	int ret = 0;
 
 	/* look up for temperature in the table and return the temperature */
-	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val) {
-		ret = -ERANGE;
-		goto exit;
-	}
+	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val)
+		return -ERANGE;
 
 	*t = bgp->conf->conv_table[adc_val - conf->adc_start_val];
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -295,16 +288,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
 {
 	const struct ti_bandgap_data *conf = bgp->conf;
 	const int *conv_table = bgp->conf->conv_table;
-	int high, low, mid, ret = 0;
+	int high, low, mid;
 
 	low = 0;
 	high = conf->adc_end_val - conf->adc_start_val;
 	mid = (high + low) / 2;
 
-	if (temp < conv_table[low] || temp > conv_table[high]) {
-		ret = -ERANGE;
-		goto exit;
-	}
+	if (temp < conv_table[low] || temp > conv_table[high])
+		return -ERANGE;
 
 	while (low < high) {
 		if (temp < conv_table[mid])
@@ -315,9 +306,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
 	}
 
 	*adc = conf->adc_start_val + low;
-
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -343,13 +332,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int adc_val, int hyst_val,
 	 */
 	ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, &temp);
 	if (ret < 0)
-		goto exit;
+		return ret;
 
 	temp += hyst_val;
 
 	ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
-
-exit:
 	return ret;
 }
 
@@ -468,22 +455,18 @@ exit:
  */
 static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
 {
-	int ret = 0;
-
 	if (!bgp || IS_ERR(bgp)) {
 		pr_err("%s: invalid bandgap pointer\n", __func__);
-		ret = -EINVAL;
-		goto exit;
+		return -EINVAL;
 	}
 
 	if ((id < 0) || (id >= bgp->conf->sensor_count)) {
 		dev_err(bgp->dev, "%s: sensor id out of range (%d)\n",
 			__func__, id);
-		ret = -ERANGE;
+		return -ERANGE;
 	}
 
-exit:
-	return ret;
+	return 0;
 }
 
 /**
@@ -511,12 +494,10 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
 
 	ret = ti_bandgap_validate(bgp, id);
 	if (ret)
-		goto exit;
+		return ret;
 
-	if (!TI_BANDGAP_HAS(bgp, TALERT)) {
-		ret = -ENOTSUPP;
-		goto exit;
-	}
+	if (!TI_BANDGAP_HAS(bgp, TALERT))
+		return -ENOTSUPP;
 
 	ts_data = bgp->conf->sensors[id].ts_data;
 	tsr = bgp->conf->sensors[id].registers;
@@ -529,17 +510,15 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
 	}
 
 	if (ret)
-		goto exit;
-
+		return ret;
+	
 	ret = ti_bandgap_mcelsius_to_adc(bgp, val, &adc_val);
 	if (ret < 0)
-		goto exit;
+		return ret;		
 
 	spin_lock(&bgp->lock);
 	ret = ti_bandgap_update_alert_threshold(bgp, id, adc_val, hot);
 	spin_unlock(&bgp->lock);
-
-exit:
 	return ret;
 }
 
@@ -582,7 +561,7 @@ static int _ti_bandgap_read_threshold(struct ti_bandgap *bgp, int id,
 
 	temp = ti_bandgap_readl(bgp, tsr->bgap_threshold);
 	temp = (temp & mask) >> __ffs(mask);
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret) {
 		dev_err(bgp->dev, "failed to read thot\n");
 		ret = -EIO;
@@ -856,10 +835,11 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
 	temp = ti_bandgap_read_temp(bgp, id);
 	spin_unlock(&bgp->lock);
 
-	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
+	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
 	if (ret)
 		return -EIO;
 
+	printk("Bandgap: temperature is %d\n", temp);
 	*temperature = temp;
 
 	return 0;
@@ -918,6 +898,7 @@ static int
 ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
 {
 	u32 temp = 0, counter = 1000;
+	struct temp_sensor_registers *tsr;
 
 	/* Select single conversion mode */
 	if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
@@ -925,16 +906,26 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
 
 	/* Start of Conversion = 1 */
 	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
-	/* Wait until DTEMP is updated */
-	temp = ti_bandgap_read_temp(bgp, id);
 
-	while ((temp = 0) && --counter)
-		temp = ti_bandgap_read_temp(bgp, id);
-	/* REVISIT: Check correct condition for end of conversion */
+	/* Wait for EOCZ going up */
+	tsr = bgp->conf->sensors[id].registers;
+	
+	while (--counter) {
+		if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask)
+			break;
+		printk("@");
+	}
 
 	/* Start of Conversion = 0 */
 	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
 
+	counter = 1000;
+	while (--counter) {
+		if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask))
+			break;
+		printk("#");
+	}
+
 	return 0;
 }
 
@@ -1196,6 +1187,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
 	struct ti_bandgap *bgp;
 	int clk_rate, ret = 0, i;
 
+	printk("ti_bandgap: probe\n");
+
 	bgp = ti_bandgap_build(pdev);
 	if (IS_ERR(bgp)) {
 		dev_err(&pdev->dev, "failed to fetch platform data\n");
@@ -1220,11 +1213,10 @@ int ti_bandgap_probe(struct platform_device *pdev)
 		goto free_irqs;
 	}
 
-	bgp->div_clk = clk_get(NULL,  bgp->conf->div_ck_name);
+	bgp->div_clk = clk_get(NULL, bgp->conf->div_ck_name);
 	ret = IS_ERR(bgp->div_clk);
 	if (ret) {
-		dev_err(&pdev->dev,
-			"failed to request div_ts_ck clock ref\n");
+		dev_err(&pdev->dev, "failed to request div_ts_ck clock ref\n");
 		ret = PTR_ERR(bgp->div_clk);
 		goto free_irqs;
 	}
@@ -1312,6 +1304,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
 	/* Every thing is good? Then expose the sensors */
 	for (i = 0; i < bgp->conf->sensor_count; i++) {
 		char *domain;
+		extern int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
+					     char *domain);
 
 		if (bgp->conf->sensors[i].register_cooling) {
 			ret = bgp->conf->sensors[i].register_cooling(bgp, i);
@@ -1319,12 +1313,29 @@ int ti_bandgap_probe(struct platform_device *pdev)
 				goto remove_sensors;
 		}
 
+		printk("bandgap: exposing sensor: %p\n", bgp->conf->expose_sensor);
+		
 		if (bgp->conf->expose_sensor) {
+			printk("bandgap: calling %p %p\n", bgp->conf->expose_sensor, ti_thermal_expose_sensor);
 			domain = bgp->conf->sensors[i].domain;
 			ret = bgp->conf->expose_sensor(bgp, i, domain);
+			printk("bandgap: done\n");
 			if (ret)
 				goto remove_last_cooling;
 		}
+
+		printk("bandgap: exposing sensor\n");
+		{
+			int t;
+
+			ti_bandgap_force_single_read(bgp, 0);
+
+			t = ti_bandgap_read_temp(bgp, 0);
+			printk("Temperature ADC: %d\n", t);			
+			ti_bandgap_read_temperature(bgp, 0, &t);
+			printk("Temperature: %d\n", t);
+			mdelay(1000);
+		}
 	}
 
 	/*
@@ -1365,6 +1376,8 @@ free_irqs:
 		free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
 		gpio_free(bgp->tshut_gpio);
 	}
+	printk("ti_bandgap: probe: something failed\n");
+	mdelay(10000);
 
 	return ret;
 }
@@ -1509,6 +1522,12 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
 #endif
 
 static const struct of_device_id of_ti_bandgap_match[] = {
+#ifdef CONFIG_OMAP3_THERMAL
+	{
+		.compatible = "ti,omap34xx-bandgap",
+		.data = (void *)&omap34xx_data,
+	},
+#endif
 #ifdef CONFIG_OMAP4_THERMAL
 	{
 		.compatible = "ti,omap4430-bandgap",
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b3adf72..3f05386 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
 void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
 int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
 
+extern const struct ti_bandgap_data omap34xx_data;
+
 #ifdef CONFIG_OMAP4_THERMAL
 extern const struct ti_bandgap_data omap4430_data;
 extern const struct ti_bandgap_data omap4460_data;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 5fd0386..f91655f 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -328,18 +328,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
 {
 	struct ti_thermal_data *data;
 
+	printk("expose_sensor\n");
+
 	data = ti_bandgap_get_sensor_data(bgp, id);
 
 	if (!data || IS_ERR(data))
 		data = ti_thermal_build_data(bgp, id);
 
-	if (!data)
+	if (!data) {
+		printk("no data\n");	
 		return -EINVAL;
+	}
 
 	/* in case this is specified by DT */
 	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
 					data, &ti_of_thermal_ops);
 	if (IS_ERR(data->ti_thermal)) {
+		printk("of_sensor_register failed\n");
 		/* Create thermal zone */
 		data->ti_thermal = thermal_zone_device_register(domain,
 				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2015-01-03  9:18               ` Pavel Machek
  (?)
@ 2015-01-07 16:19                 ` Guenter Roeck
  -1 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2015-01-07 16:19 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Sat, Jan 03, 2015 at 10:18:58AM +0100, Pavel Machek wrote:
> On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> > On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > >> which can be used to determine the SoCs temperature. This patch provides
> > > > >> a DT based driver for the temperature sensor based on an older driver
> > > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > > >
> > > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > > OMAPs, which are already supported by maybe
> > > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > > that driver instead?
> > > > 
> > > > Just to be clear - OMAP4 is the first time that the sensors were
> > > > reliable enough to be used.
> > > 
> > > When testing initial version of the patch, they seem to work very well
> > > in the omap3 case.
> > > 
> > Pavel,
> > 
> > can you look into the omap4 thermal driver to see if it can be used ?
> 
> After some fixes... yes, it seems to be same hardware.
> 
So this should be the way to go, but then we have others claim that
it should not be done because the OMAP3 sensors are too unreliable
to use for thermal decisions. Not really sure where that leaves us.
I am kind of opposed to have similar drivers for similar chips
in two different subsystems.

Is it possible to add the patch below to the omap thermal driver
and not use it for thermal decisions ?

Guenter

> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig
> index bd4c7be..a49495f 100644
> --- a/drivers/thermal/ti-soc-thermal/Kconfig
> +++ b/drivers/thermal/ti-soc-thermal/Kconfig
> @@ -21,6 +21,15 @@ config TI_THERMAL
>  	  This includes trip points definitions, extrapolation rules and
>  	  CPU cooling device bindings.
>  
> +config OMAP3_THERMAL
> +	bool "Texas Instruments OMAP3 thermal support"
> +	depends on TI_SOC_THERMAL
> +	depends on ARCH_OMAP3
> +	help
> +	  If you say yes here you get thermal support for the Texas Instruments
> +	  OMAP3 SoC family. The current chip supported are:
> +	   - OMAP3430
> +
>  config OMAP4_THERMAL
>  	bool "Texas Instruments OMAP4 thermal support"
>  	depends on TI_SOC_THERMAL
> diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
> index 1226b24..2b5b220 100644
> --- a/drivers/thermal/ti-soc-thermal/Makefile
> +++ b/drivers/thermal/ti-soc-thermal/Makefile
> @@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
>  ti-soc-thermal-y			:= ti-bandgap.o
>  ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
>  ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
> +ti-soc-thermal-$(CONFIG_OMAP3_THERMAL)  += omap3-thermal-data.o
>  ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
>  ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
> diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
> new file mode 100644
> index 0000000..a79ebf2
> --- /dev/null
> +++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
> @@ -0,0 +1,99 @@
> +/*
> + * OMAP3 thermal driver.
> + *
> + * Copyright (C) 2011-2012 Texas Instruments Inc.
> + * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + *
> + */
> +
> +#include "ti-thermal.h"
> +#include "ti-bandgap.h"
> +
> +/*
> + * OMAP34XX has one instance of thermal sensor for MPU
> + * need to describe the individual bit fields
> + */
> +static struct temp_sensor_registers
> +omap34xx_mpu_temp_sensor_registers = {
> +	.temp_sensor_ctrl = 0,
> +	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
> +	.bgap_soc_mask = BIT(8),
> +	.bgap_eocz_mask = BIT(7),
> +	.bgap_dtemp_mask = 0x7f,
> +
> +	.bgap_mode_ctrl = 0,
> +	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
> +
> +	.bgap_efuse = 0,
> +};
> +
> +/* Thresholds and limits for OMAP34XX MPU temperature sensor */
> +static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
> +	.min_freq = 32768,
> +	.max_freq = 32768,
> +	.max_temp = -99000,
> +	.min_temp = 99000,
> +	.hyst_val = 5000,
> +};
> +
> +/*
> + * Temperature values in milli degree celsius
> + * ADC code values from 530 to 923
> + */
> +static const int
> +omap34xx_adc_to_temp[] = {
> +	-40000, -40000, -40000, -40000, -40000, -39000, -38000, -36000,
> +	-34000, -32000, -31000,	-29000, -28000, -26000, -25000, -24000,
> +	-22000, -21000, -19000, -18000, -17000, -15000,	-14000, -12000,
> +	-11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, 0000,
> +	1000, 3000, 4000, 5000, 7000, 8000, 10000, 11000, 13000, 14000,
> +	15000, 17000, 18000, 20000, 21000, 22000, 24000, 25000, 27000,
> +	28000, 30000, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
> +	41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
> +	53000, 55000, 56000, 58000, 59000, 60000, 62000, 63000, 65000,
> +	66000, 67000, 69000, 70000, 72000, 73000, 74000, 76000, 77000,
> +	79000, 80000, 81000, 83000, 84000, 85000, 87000, 88000, 89000,
> +	91000, 92000, 94000, 95000, 96000, 98000, 99000, 100000,
> +	102000, 103000, 105000, 106000, 107000, 109000, 110000, 111000,
> +	113000, 114000, 116000, 117000, 118000, 120000, 121000, 122000,
> +	124000, 124000, 125000, 125000, 125000, 125000,	125000
> +};
> +
> +/* OMAP34XX data */
> +const struct ti_bandgap_data omap34xx_data = {
> +	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
> +	.fclock_name = "ts_fck",
> +	.div_ck_name = "ts_fck",
> +	.conv_table = omap34xx_adc_to_temp,
> +	.adc_start_val = 0,
> +	.adc_end_val = 127,
> +	.expose_sensor = ti_thermal_expose_sensor,
> +	.remove_sensor = ti_thermal_remove_sensor,
> +
> +	.sensors = {
> +		{
> +		.registers = &omap34xx_mpu_temp_sensor_registers,
> +		.ts_data = &omap34xx_mpu_temp_sensor_data,
> +		.domain = "cpu",
> +		.slope = 0,
> +		.constant = 20000,
> +		.slope_pcb = 0,
> +		.constant_pcb = 20000,
> +		.register_cooling = NULL,
> +		.unregister_cooling = NULL,
> +		},
> +	},
> +	.sensor_count = 1,
> +
> +//	.sensor_count = 0,
> +};
> +
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> index 634b6ce..a4180a5 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -40,6 +40,7 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_gpio.h>
>  #include <linux/io.h>
> +#include <linux/delay.h>
>  
>  #include "ti-bandgap.h"
>  
> @@ -103,19 +104,15 @@ do {								\
>   */
>  static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
>  {
> -	int i, ret = 0;
> +	int i;
>  
> -	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH)) {
> -		ret = -ENOTSUPP;
> -		goto exit;
> -	}
> +	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH))
> +		return -ENOTSUPP;
>  
>  	for (i = 0; i < bgp->conf->sensor_count; i++)
>  		/* active on 0 */
>  		RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -154,6 +151,7 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp, int id)
>  	if (TI_BANDGAP_HAS(bgp, FREEZE_BIT))
>  		RMW_BITS(bgp, id, bgap_mask_ctrl, mask_freeze_mask, 0);
>  
> +	printk("Bandgap: ADC is %d\n", temp);
>  	return temp;
>  }
>  
> @@ -263,18 +261,13 @@ static
>  int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
>  {
>  	const struct ti_bandgap_data *conf = bgp->conf;
> -	int ret = 0;
>  
>  	/* look up for temperature in the table and return the temperature */
> -	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val) {
> -		ret = -ERANGE;
> -		goto exit;
> -	}
> +	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val)
> +		return -ERANGE;
>  
>  	*t = bgp->conf->conv_table[adc_val - conf->adc_start_val];
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -295,16 +288,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
>  {
>  	const struct ti_bandgap_data *conf = bgp->conf;
>  	const int *conv_table = bgp->conf->conv_table;
> -	int high, low, mid, ret = 0;
> +	int high, low, mid;
>  
>  	low = 0;
>  	high = conf->adc_end_val - conf->adc_start_val;
>  	mid = (high + low) / 2;
>  
> -	if (temp < conv_table[low] || temp > conv_table[high]) {
> -		ret = -ERANGE;
> -		goto exit;
> -	}
> +	if (temp < conv_table[low] || temp > conv_table[high])
> +		return -ERANGE;
>  
>  	while (low < high) {
>  		if (temp < conv_table[mid])
> @@ -315,9 +306,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
>  	}
>  
>  	*adc = conf->adc_start_val + low;
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -343,13 +332,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int adc_val, int hyst_val,
>  	 */
>  	ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, &temp);
>  	if (ret < 0)
> -		goto exit;
> +		return ret;
>  
>  	temp += hyst_val;
>  
>  	ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
> -
> -exit:
>  	return ret;
>  }
>  
> @@ -468,22 +455,18 @@ exit:
>   */
>  static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
>  {
> -	int ret = 0;
> -
>  	if (!bgp || IS_ERR(bgp)) {
>  		pr_err("%s: invalid bandgap pointer\n", __func__);
> -		ret = -EINVAL;
> -		goto exit;
> +		return -EINVAL;
>  	}
>  
>  	if ((id < 0) || (id >= bgp->conf->sensor_count)) {
>  		dev_err(bgp->dev, "%s: sensor id out of range (%d)\n",
>  			__func__, id);
> -		ret = -ERANGE;
> +		return -ERANGE;
>  	}
>  
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -511,12 +494,10 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
>  
>  	ret = ti_bandgap_validate(bgp, id);
>  	if (ret)
> -		goto exit;
> +		return ret;
>  
> -	if (!TI_BANDGAP_HAS(bgp, TALERT)) {
> -		ret = -ENOTSUPP;
> -		goto exit;
> -	}
> +	if (!TI_BANDGAP_HAS(bgp, TALERT))
> +		return -ENOTSUPP;
>  
>  	ts_data = bgp->conf->sensors[id].ts_data;
>  	tsr = bgp->conf->sensors[id].registers;
> @@ -529,17 +510,15 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
>  	}
>  
>  	if (ret)
> -		goto exit;
> -
> +		return ret;
> +	
>  	ret = ti_bandgap_mcelsius_to_adc(bgp, val, &adc_val);
>  	if (ret < 0)
> -		goto exit;
> +		return ret;		
>  
>  	spin_lock(&bgp->lock);
>  	ret = ti_bandgap_update_alert_threshold(bgp, id, adc_val, hot);
>  	spin_unlock(&bgp->lock);
> -
> -exit:
>  	return ret;
>  }
>  
> @@ -582,7 +561,7 @@ static int _ti_bandgap_read_threshold(struct ti_bandgap *bgp, int id,
>  
>  	temp = ti_bandgap_readl(bgp, tsr->bgap_threshold);
>  	temp = (temp & mask) >> __ffs(mask);
> -	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
> +	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
>  	if (ret) {
>  		dev_err(bgp->dev, "failed to read thot\n");
>  		ret = -EIO;
> @@ -856,10 +835,11 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
>  	temp = ti_bandgap_read_temp(bgp, id);
>  	spin_unlock(&bgp->lock);
>  
> -	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
> +	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
>  	if (ret)
>  		return -EIO;
>  
> +	printk("Bandgap: temperature is %d\n", temp);
>  	*temperature = temp;
>  
>  	return 0;
> @@ -918,6 +898,7 @@ static int
>  ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
>  {
>  	u32 temp = 0, counter = 1000;
> +	struct temp_sensor_registers *tsr;
>  
>  	/* Select single conversion mode */
>  	if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
> @@ -925,16 +906,26 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
>  
>  	/* Start of Conversion = 1 */
>  	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
> -	/* Wait until DTEMP is updated */
> -	temp = ti_bandgap_read_temp(bgp, id);
>  
> -	while ((temp == 0) && --counter)
> -		temp = ti_bandgap_read_temp(bgp, id);
> -	/* REVISIT: Check correct condition for end of conversion */
> +	/* Wait for EOCZ going up */
> +	tsr = bgp->conf->sensors[id].registers;
> +	
> +	while (--counter) {
> +		if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask)
> +			break;
> +		printk("@");
> +	}
>  
>  	/* Start of Conversion = 0 */
>  	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
>  
> +	counter = 1000;
> +	while (--counter) {
> +		if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask))
> +			break;
> +		printk("#");
> +	}
> +
>  	return 0;
>  }
>  
> @@ -1196,6 +1187,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  	struct ti_bandgap *bgp;
>  	int clk_rate, ret = 0, i;
>  
> +	printk("ti_bandgap: probe\n");
> +
>  	bgp = ti_bandgap_build(pdev);
>  	if (IS_ERR(bgp)) {
>  		dev_err(&pdev->dev, "failed to fetch platform data\n");
> @@ -1220,11 +1213,10 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  		goto free_irqs;
>  	}
>  
> -	bgp->div_clk = clk_get(NULL,  bgp->conf->div_ck_name);
> +	bgp->div_clk = clk_get(NULL, bgp->conf->div_ck_name);
>  	ret = IS_ERR(bgp->div_clk);
>  	if (ret) {
> -		dev_err(&pdev->dev,
> -			"failed to request div_ts_ck clock ref\n");
> +		dev_err(&pdev->dev, "failed to request div_ts_ck clock ref\n");
>  		ret = PTR_ERR(bgp->div_clk);
>  		goto free_irqs;
>  	}
> @@ -1312,6 +1304,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  	/* Every thing is good? Then expose the sensors */
>  	for (i = 0; i < bgp->conf->sensor_count; i++) {
>  		char *domain;
> +		extern int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
> +					     char *domain);
>  
>  		if (bgp->conf->sensors[i].register_cooling) {
>  			ret = bgp->conf->sensors[i].register_cooling(bgp, i);
> @@ -1319,12 +1313,29 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  				goto remove_sensors;
>  		}
>  
> +		printk("bandgap: exposing sensor: %p\n", bgp->conf->expose_sensor);
> +		
>  		if (bgp->conf->expose_sensor) {
> +			printk("bandgap: calling %p %p\n", bgp->conf->expose_sensor, ti_thermal_expose_sensor);
>  			domain = bgp->conf->sensors[i].domain;
>  			ret = bgp->conf->expose_sensor(bgp, i, domain);
> +			printk("bandgap: done\n");
>  			if (ret)
>  				goto remove_last_cooling;
>  		}
> +
> +		printk("bandgap: exposing sensor\n");
> +		{
> +			int t;
> +
> +			ti_bandgap_force_single_read(bgp, 0);
> +
> +			t = ti_bandgap_read_temp(bgp, 0);
> +			printk("Temperature ADC: %d\n", t);			
> +			ti_bandgap_read_temperature(bgp, 0, &t);
> +			printk("Temperature: %d\n", t);
> +			mdelay(1000);
> +		}
>  	}
>  
>  	/*
> @@ -1365,6 +1376,8 @@ free_irqs:
>  		free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
>  		gpio_free(bgp->tshut_gpio);
>  	}
> +	printk("ti_bandgap: probe: something failed\n");
> +	mdelay(10000);
>  
>  	return ret;
>  }
> @@ -1509,6 +1522,12 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
>  #endif
>  
>  static const struct of_device_id of_ti_bandgap_match[] = {
> +#ifdef CONFIG_OMAP3_THERMAL
> +	{
> +		.compatible = "ti,omap34xx-bandgap",
> +		.data = (void *)&omap34xx_data,
> +	},
> +#endif
>  #ifdef CONFIG_OMAP4_THERMAL
>  	{
>  		.compatible = "ti,omap4430-bandgap",
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> index b3adf72..3f05386 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> @@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
>  void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
>  int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
>  
> +extern const struct ti_bandgap_data omap34xx_data;
> +
>  #ifdef CONFIG_OMAP4_THERMAL
>  extern const struct ti_bandgap_data omap4430_data;
>  extern const struct ti_bandgap_data omap4460_data;
> diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> index 5fd0386..f91655f 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> @@ -328,18 +328,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
>  {
>  	struct ti_thermal_data *data;
>  
> +	printk("expose_sensor\n");
> +
>  	data = ti_bandgap_get_sensor_data(bgp, id);
>  
>  	if (!data || IS_ERR(data))
>  		data = ti_thermal_build_data(bgp, id);
>  
> -	if (!data)
> +	if (!data) {
> +		printk("no data\n");	
>  		return -EINVAL;
> +	}
>  
>  	/* in case this is specified by DT */
>  	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
>  					data, &ti_of_thermal_ops);
>  	if (IS_ERR(data->ti_thermal)) {
> +		printk("of_sensor_register failed\n");
>  		/* Create thermal zone */
>  		data->ti_thermal = thermal_zone_device_register(domain,
>  				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,
> 
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-07 16:19                 ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2015-01-07 16:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, Jan 03, 2015 at 10:18:58AM +0100, Pavel Machek wrote:
> On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> > On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > >> which can be used to determine the SoCs temperature. This patch provides
> > > > >> a DT based driver for the temperature sensor based on an older driver
> > > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > > >
> > > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > > OMAPs, which are already supported by maybe
> > > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > > that driver instead?
> > > > 
> > > > Just to be clear - OMAP4 is the first time that the sensors were
> > > > reliable enough to be used.
> > > 
> > > When testing initial version of the patch, they seem to work very well
> > > in the omap3 case.
> > > 
> > Pavel,
> > 
> > can you look into the omap4 thermal driver to see if it can be used ?
> 
> After some fixes... yes, it seems to be same hardware.
> 
So this should be the way to go, but then we have others claim that
it should not be done because the OMAP3 sensors are too unreliable
to use for thermal decisions. Not really sure where that leaves us.
I am kind of opposed to have similar drivers for similar chips
in two different subsystems.

Is it possible to add the patch below to the omap thermal driver
and not use it for thermal decisions ?

Guenter

> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig
> index bd4c7be..a49495f 100644
> --- a/drivers/thermal/ti-soc-thermal/Kconfig
> +++ b/drivers/thermal/ti-soc-thermal/Kconfig
> @@ -21,6 +21,15 @@ config TI_THERMAL
>  	  This includes trip points definitions, extrapolation rules and
>  	  CPU cooling device bindings.
>  
> +config OMAP3_THERMAL
> +	bool "Texas Instruments OMAP3 thermal support"
> +	depends on TI_SOC_THERMAL
> +	depends on ARCH_OMAP3
> +	help
> +	  If you say yes here you get thermal support for the Texas Instruments
> +	  OMAP3 SoC family. The current chip supported are:
> +	   - OMAP3430
> +
>  config OMAP4_THERMAL
>  	bool "Texas Instruments OMAP4 thermal support"
>  	depends on TI_SOC_THERMAL
> diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
> index 1226b24..2b5b220 100644
> --- a/drivers/thermal/ti-soc-thermal/Makefile
> +++ b/drivers/thermal/ti-soc-thermal/Makefile
> @@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
>  ti-soc-thermal-y			:= ti-bandgap.o
>  ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
>  ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
> +ti-soc-thermal-$(CONFIG_OMAP3_THERMAL)  += omap3-thermal-data.o
>  ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
>  ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
> diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
> new file mode 100644
> index 0000000..a79ebf2
> --- /dev/null
> +++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
> @@ -0,0 +1,99 @@
> +/*
> + * OMAP3 thermal driver.
> + *
> + * Copyright (C) 2011-2012 Texas Instruments Inc.
> + * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + *
> + */
> +
> +#include "ti-thermal.h"
> +#include "ti-bandgap.h"
> +
> +/*
> + * OMAP34XX has one instance of thermal sensor for MPU
> + * need to describe the individual bit fields
> + */
> +static struct temp_sensor_registers
> +omap34xx_mpu_temp_sensor_registers = {
> +	.temp_sensor_ctrl = 0,
> +	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
> +	.bgap_soc_mask = BIT(8),
> +	.bgap_eocz_mask = BIT(7),
> +	.bgap_dtemp_mask = 0x7f,
> +
> +	.bgap_mode_ctrl = 0,
> +	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
> +
> +	.bgap_efuse = 0,
> +};
> +
> +/* Thresholds and limits for OMAP34XX MPU temperature sensor */
> +static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
> +	.min_freq = 32768,
> +	.max_freq = 32768,
> +	.max_temp = -99000,
> +	.min_temp = 99000,
> +	.hyst_val = 5000,
> +};
> +
> +/*
> + * Temperature values in milli degree celsius
> + * ADC code values from 530 to 923
> + */
> +static const int
> +omap34xx_adc_to_temp[] = {
> +	-40000, -40000, -40000, -40000, -40000, -39000, -38000, -36000,
> +	-34000, -32000, -31000,	-29000, -28000, -26000, -25000, -24000,
> +	-22000, -21000, -19000, -18000, -17000, -15000,	-14000, -12000,
> +	-11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, 0000,
> +	1000, 3000, 4000, 5000, 7000, 8000, 10000, 11000, 13000, 14000,
> +	15000, 17000, 18000, 20000, 21000, 22000, 24000, 25000, 27000,
> +	28000, 30000, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
> +	41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
> +	53000, 55000, 56000, 58000, 59000, 60000, 62000, 63000, 65000,
> +	66000, 67000, 69000, 70000, 72000, 73000, 74000, 76000, 77000,
> +	79000, 80000, 81000, 83000, 84000, 85000, 87000, 88000, 89000,
> +	91000, 92000, 94000, 95000, 96000, 98000, 99000, 100000,
> +	102000, 103000, 105000, 106000, 107000, 109000, 110000, 111000,
> +	113000, 114000, 116000, 117000, 118000, 120000, 121000, 122000,
> +	124000, 124000, 125000, 125000, 125000, 125000,	125000
> +};
> +
> +/* OMAP34XX data */
> +const struct ti_bandgap_data omap34xx_data = {
> +	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
> +	.fclock_name = "ts_fck",
> +	.div_ck_name = "ts_fck",
> +	.conv_table = omap34xx_adc_to_temp,
> +	.adc_start_val = 0,
> +	.adc_end_val = 127,
> +	.expose_sensor = ti_thermal_expose_sensor,
> +	.remove_sensor = ti_thermal_remove_sensor,
> +
> +	.sensors = {
> +		{
> +		.registers = &omap34xx_mpu_temp_sensor_registers,
> +		.ts_data = &omap34xx_mpu_temp_sensor_data,
> +		.domain = "cpu",
> +		.slope = 0,
> +		.constant = 20000,
> +		.slope_pcb = 0,
> +		.constant_pcb = 20000,
> +		.register_cooling = NULL,
> +		.unregister_cooling = NULL,
> +		},
> +	},
> +	.sensor_count = 1,
> +
> +//	.sensor_count = 0,
> +};
> +
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> index 634b6ce..a4180a5 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -40,6 +40,7 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_gpio.h>
>  #include <linux/io.h>
> +#include <linux/delay.h>
>  
>  #include "ti-bandgap.h"
>  
> @@ -103,19 +104,15 @@ do {								\
>   */
>  static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
>  {
> -	int i, ret = 0;
> +	int i;
>  
> -	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH)) {
> -		ret = -ENOTSUPP;
> -		goto exit;
> -	}
> +	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH))
> +		return -ENOTSUPP;
>  
>  	for (i = 0; i < bgp->conf->sensor_count; i++)
>  		/* active on 0 */
>  		RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -154,6 +151,7 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp, int id)
>  	if (TI_BANDGAP_HAS(bgp, FREEZE_BIT))
>  		RMW_BITS(bgp, id, bgap_mask_ctrl, mask_freeze_mask, 0);
>  
> +	printk("Bandgap: ADC is %d\n", temp);
>  	return temp;
>  }
>  
> @@ -263,18 +261,13 @@ static
>  int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
>  {
>  	const struct ti_bandgap_data *conf = bgp->conf;
> -	int ret = 0;
>  
>  	/* look up for temperature in the table and return the temperature */
> -	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val) {
> -		ret = -ERANGE;
> -		goto exit;
> -	}
> +	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val)
> +		return -ERANGE;
>  
>  	*t = bgp->conf->conv_table[adc_val - conf->adc_start_val];
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -295,16 +288,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
>  {
>  	const struct ti_bandgap_data *conf = bgp->conf;
>  	const int *conv_table = bgp->conf->conv_table;
> -	int high, low, mid, ret = 0;
> +	int high, low, mid;
>  
>  	low = 0;
>  	high = conf->adc_end_val - conf->adc_start_val;
>  	mid = (high + low) / 2;
>  
> -	if (temp < conv_table[low] || temp > conv_table[high]) {
> -		ret = -ERANGE;
> -		goto exit;
> -	}
> +	if (temp < conv_table[low] || temp > conv_table[high])
> +		return -ERANGE;
>  
>  	while (low < high) {
>  		if (temp < conv_table[mid])
> @@ -315,9 +306,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
>  	}
>  
>  	*adc = conf->adc_start_val + low;
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -343,13 +332,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int adc_val, int hyst_val,
>  	 */
>  	ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, &temp);
>  	if (ret < 0)
> -		goto exit;
> +		return ret;
>  
>  	temp += hyst_val;
>  
>  	ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
> -
> -exit:
>  	return ret;
>  }
>  
> @@ -468,22 +455,18 @@ exit:
>   */
>  static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
>  {
> -	int ret = 0;
> -
>  	if (!bgp || IS_ERR(bgp)) {
>  		pr_err("%s: invalid bandgap pointer\n", __func__);
> -		ret = -EINVAL;
> -		goto exit;
> +		return -EINVAL;
>  	}
>  
>  	if ((id < 0) || (id >= bgp->conf->sensor_count)) {
>  		dev_err(bgp->dev, "%s: sensor id out of range (%d)\n",
>  			__func__, id);
> -		ret = -ERANGE;
> +		return -ERANGE;
>  	}
>  
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -511,12 +494,10 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
>  
>  	ret = ti_bandgap_validate(bgp, id);
>  	if (ret)
> -		goto exit;
> +		return ret;
>  
> -	if (!TI_BANDGAP_HAS(bgp, TALERT)) {
> -		ret = -ENOTSUPP;
> -		goto exit;
> -	}
> +	if (!TI_BANDGAP_HAS(bgp, TALERT))
> +		return -ENOTSUPP;
>  
>  	ts_data = bgp->conf->sensors[id].ts_data;
>  	tsr = bgp->conf->sensors[id].registers;
> @@ -529,17 +510,15 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
>  	}
>  
>  	if (ret)
> -		goto exit;
> -
> +		return ret;
> +	
>  	ret = ti_bandgap_mcelsius_to_adc(bgp, val, &adc_val);
>  	if (ret < 0)
> -		goto exit;
> +		return ret;		
>  
>  	spin_lock(&bgp->lock);
>  	ret = ti_bandgap_update_alert_threshold(bgp, id, adc_val, hot);
>  	spin_unlock(&bgp->lock);
> -
> -exit:
>  	return ret;
>  }
>  
> @@ -582,7 +561,7 @@ static int _ti_bandgap_read_threshold(struct ti_bandgap *bgp, int id,
>  
>  	temp = ti_bandgap_readl(bgp, tsr->bgap_threshold);
>  	temp = (temp & mask) >> __ffs(mask);
> -	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
> +	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
>  	if (ret) {
>  		dev_err(bgp->dev, "failed to read thot\n");
>  		ret = -EIO;
> @@ -856,10 +835,11 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
>  	temp = ti_bandgap_read_temp(bgp, id);
>  	spin_unlock(&bgp->lock);
>  
> -	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
> +	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
>  	if (ret)
>  		return -EIO;
>  
> +	printk("Bandgap: temperature is %d\n", temp);
>  	*temperature = temp;
>  
>  	return 0;
> @@ -918,6 +898,7 @@ static int
>  ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
>  {
>  	u32 temp = 0, counter = 1000;
> +	struct temp_sensor_registers *tsr;
>  
>  	/* Select single conversion mode */
>  	if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
> @@ -925,16 +906,26 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
>  
>  	/* Start of Conversion = 1 */
>  	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
> -	/* Wait until DTEMP is updated */
> -	temp = ti_bandgap_read_temp(bgp, id);
>  
> -	while ((temp == 0) && --counter)
> -		temp = ti_bandgap_read_temp(bgp, id);
> -	/* REVISIT: Check correct condition for end of conversion */
> +	/* Wait for EOCZ going up */
> +	tsr = bgp->conf->sensors[id].registers;
> +	
> +	while (--counter) {
> +		if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask)
> +			break;
> +		printk("@");
> +	}
>  
>  	/* Start of Conversion = 0 */
>  	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
>  
> +	counter = 1000;
> +	while (--counter) {
> +		if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask))
> +			break;
> +		printk("#");
> +	}
> +
>  	return 0;
>  }
>  
> @@ -1196,6 +1187,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  	struct ti_bandgap *bgp;
>  	int clk_rate, ret = 0, i;
>  
> +	printk("ti_bandgap: probe\n");
> +
>  	bgp = ti_bandgap_build(pdev);
>  	if (IS_ERR(bgp)) {
>  		dev_err(&pdev->dev, "failed to fetch platform data\n");
> @@ -1220,11 +1213,10 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  		goto free_irqs;
>  	}
>  
> -	bgp->div_clk = clk_get(NULL,  bgp->conf->div_ck_name);
> +	bgp->div_clk = clk_get(NULL, bgp->conf->div_ck_name);
>  	ret = IS_ERR(bgp->div_clk);
>  	if (ret) {
> -		dev_err(&pdev->dev,
> -			"failed to request div_ts_ck clock ref\n");
> +		dev_err(&pdev->dev, "failed to request div_ts_ck clock ref\n");
>  		ret = PTR_ERR(bgp->div_clk);
>  		goto free_irqs;
>  	}
> @@ -1312,6 +1304,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  	/* Every thing is good? Then expose the sensors */
>  	for (i = 0; i < bgp->conf->sensor_count; i++) {
>  		char *domain;
> +		extern int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
> +					     char *domain);
>  
>  		if (bgp->conf->sensors[i].register_cooling) {
>  			ret = bgp->conf->sensors[i].register_cooling(bgp, i);
> @@ -1319,12 +1313,29 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  				goto remove_sensors;
>  		}
>  
> +		printk("bandgap: exposing sensor: %p\n", bgp->conf->expose_sensor);
> +		
>  		if (bgp->conf->expose_sensor) {
> +			printk("bandgap: calling %p %p\n", bgp->conf->expose_sensor, ti_thermal_expose_sensor);
>  			domain = bgp->conf->sensors[i].domain;
>  			ret = bgp->conf->expose_sensor(bgp, i, domain);
> +			printk("bandgap: done\n");
>  			if (ret)
>  				goto remove_last_cooling;
>  		}
> +
> +		printk("bandgap: exposing sensor\n");
> +		{
> +			int t;
> +
> +			ti_bandgap_force_single_read(bgp, 0);
> +
> +			t = ti_bandgap_read_temp(bgp, 0);
> +			printk("Temperature ADC: %d\n", t);			
> +			ti_bandgap_read_temperature(bgp, 0, &t);
> +			printk("Temperature: %d\n", t);
> +			mdelay(1000);
> +		}
>  	}
>  
>  	/*
> @@ -1365,6 +1376,8 @@ free_irqs:
>  		free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
>  		gpio_free(bgp->tshut_gpio);
>  	}
> +	printk("ti_bandgap: probe: something failed\n");
> +	mdelay(10000);
>  
>  	return ret;
>  }
> @@ -1509,6 +1522,12 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
>  #endif
>  
>  static const struct of_device_id of_ti_bandgap_match[] = {
> +#ifdef CONFIG_OMAP3_THERMAL
> +	{
> +		.compatible = "ti,omap34xx-bandgap",
> +		.data = (void *)&omap34xx_data,
> +	},
> +#endif
>  #ifdef CONFIG_OMAP4_THERMAL
>  	{
>  		.compatible = "ti,omap4430-bandgap",
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> index b3adf72..3f05386 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> @@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
>  void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
>  int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
>  
> +extern const struct ti_bandgap_data omap34xx_data;
> +
>  #ifdef CONFIG_OMAP4_THERMAL
>  extern const struct ti_bandgap_data omap4430_data;
>  extern const struct ti_bandgap_data omap4460_data;
> diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> index 5fd0386..f91655f 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> @@ -328,18 +328,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
>  {
>  	struct ti_thermal_data *data;
>  
> +	printk("expose_sensor\n");
> +
>  	data = ti_bandgap_get_sensor_data(bgp, id);
>  
>  	if (!data || IS_ERR(data))
>  		data = ti_thermal_build_data(bgp, id);
>  
> -	if (!data)
> +	if (!data) {
> +		printk("no data\n");	
>  		return -EINVAL;
> +	}
>  
>  	/* in case this is specified by DT */
>  	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
>  					data, &ti_of_thermal_ops);
>  	if (IS_ERR(data->ti_thermal)) {
> +		printk("of_sensor_register failed\n");
>  		/* Create thermal zone */
>  		data->ti_thermal = thermal_zone_device_register(domain,
>  				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,
> 
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-07 16:19                 ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2015-01-07 16:19 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Sat, Jan 03, 2015 at 10:18:58AM +0100, Pavel Machek wrote:
> On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> > On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > >> which can be used to determine the SoCs temperature. This patch provides
> > > > >> a DT based driver for the temperature sensor based on an older driver
> > > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > > >
> > > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > > OMAPs, which are already supported by maybe
> > > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > > that driver instead?
> > > > 
> > > > Just to be clear - OMAP4 is the first time that the sensors were
> > > > reliable enough to be used.
> > > 
> > > When testing initial version of the patch, they seem to work very well
> > > in the omap3 case.
> > > 
> > Pavel,
> > 
> > can you look into the omap4 thermal driver to see if it can be used ?
> 
> After some fixes... yes, it seems to be same hardware.
> 
So this should be the way to go, but then we have others claim that
it should not be done because the OMAP3 sensors are too unreliable
to use for thermal decisions. Not really sure where that leaves us.
I am kind of opposed to have similar drivers for similar chips
in two different subsystems.

Is it possible to add the patch below to the omap thermal driver
and not use it for thermal decisions ?

Guenter

> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig
> index bd4c7be..a49495f 100644
> --- a/drivers/thermal/ti-soc-thermal/Kconfig
> +++ b/drivers/thermal/ti-soc-thermal/Kconfig
> @@ -21,6 +21,15 @@ config TI_THERMAL
>  	  This includes trip points definitions, extrapolation rules and
>  	  CPU cooling device bindings.
>  
> +config OMAP3_THERMAL
> +	bool "Texas Instruments OMAP3 thermal support"
> +	depends on TI_SOC_THERMAL
> +	depends on ARCH_OMAP3
> +	help
> +	  If you say yes here you get thermal support for the Texas Instruments
> +	  OMAP3 SoC family. The current chip supported are:
> +	   - OMAP3430
> +
>  config OMAP4_THERMAL
>  	bool "Texas Instruments OMAP4 thermal support"
>  	depends on TI_SOC_THERMAL
> diff --git a/drivers/thermal/ti-soc-thermal/Makefile b/drivers/thermal/ti-soc-thermal/Makefile
> index 1226b24..2b5b220 100644
> --- a/drivers/thermal/ti-soc-thermal/Makefile
> +++ b/drivers/thermal/ti-soc-thermal/Makefile
> @@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)		+= ti-soc-thermal.o
>  ti-soc-thermal-y			:= ti-bandgap.o
>  ti-soc-thermal-$(CONFIG_TI_THERMAL)	+= ti-thermal-common.o
>  ti-soc-thermal-$(CONFIG_DRA752_THERMAL)	+= dra752-thermal-data.o
> +ti-soc-thermal-$(CONFIG_OMAP3_THERMAL)  += omap3-thermal-data.o
>  ti-soc-thermal-$(CONFIG_OMAP4_THERMAL)	+= omap4-thermal-data.o
>  ti-soc-thermal-$(CONFIG_OMAP5_THERMAL)	+= omap5-thermal-data.o
> diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
> new file mode 100644
> index 0000000..a79ebf2
> --- /dev/null
> +++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
> @@ -0,0 +1,99 @@
> +/*
> + * OMAP3 thermal driver.
> + *
> + * Copyright (C) 2011-2012 Texas Instruments Inc.
> + * Copyright (C) 2014 Pavel Machek <pavel@ucw.cz>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + *
> + */
> +
> +#include "ti-thermal.h"
> +#include "ti-bandgap.h"
> +
> +/*
> + * OMAP34XX has one instance of thermal sensor for MPU
> + * need to describe the individual bit fields
> + */
> +static struct temp_sensor_registers
> +omap34xx_mpu_temp_sensor_registers = {
> +	.temp_sensor_ctrl = 0,
> +	.bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
> +	.bgap_soc_mask = BIT(8),
> +	.bgap_eocz_mask = BIT(7),
> +	.bgap_dtemp_mask = 0x7f,
> +
> +	.bgap_mode_ctrl = 0,
> +	.mode_ctrl_mask = 0,	/* Unused, no MODE_CONFIG */
> +
> +	.bgap_efuse = 0,
> +};
> +
> +/* Thresholds and limits for OMAP34XX MPU temperature sensor */
> +static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
> +	.min_freq = 32768,
> +	.max_freq = 32768,
> +	.max_temp = -99000,
> +	.min_temp = 99000,
> +	.hyst_val = 5000,
> +};
> +
> +/*
> + * Temperature values in milli degree celsius
> + * ADC code values from 530 to 923
> + */
> +static const int
> +omap34xx_adc_to_temp[] = {
> +	-40000, -40000, -40000, -40000, -40000, -39000, -38000, -36000,
> +	-34000, -32000, -31000,	-29000, -28000, -26000, -25000, -24000,
> +	-22000, -21000, -19000, -18000, -17000, -15000,	-14000, -12000,
> +	-11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, 0000,
> +	1000, 3000, 4000, 5000, 7000, 8000, 10000, 11000, 13000, 14000,
> +	15000, 17000, 18000, 20000, 21000, 22000, 24000, 25000, 27000,
> +	28000, 30000, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
> +	41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
> +	53000, 55000, 56000, 58000, 59000, 60000, 62000, 63000, 65000,
> +	66000, 67000, 69000, 70000, 72000, 73000, 74000, 76000, 77000,
> +	79000, 80000, 81000, 83000, 84000, 85000, 87000, 88000, 89000,
> +	91000, 92000, 94000, 95000, 96000, 98000, 99000, 100000,
> +	102000, 103000, 105000, 106000, 107000, 109000, 110000, 111000,
> +	113000, 114000, 116000, 117000, 118000, 120000, 121000, 122000,
> +	124000, 124000, 125000, 125000, 125000, 125000,	125000
> +};
> +
> +/* OMAP34XX data */
> +const struct ti_bandgap_data omap34xx_data = {
> +	.features = TI_BANDGAP_FEATURE_CLK_CTRL,
> +	.fclock_name = "ts_fck",
> +	.div_ck_name = "ts_fck",
> +	.conv_table = omap34xx_adc_to_temp,
> +	.adc_start_val = 0,
> +	.adc_end_val = 127,
> +	.expose_sensor = ti_thermal_expose_sensor,
> +	.remove_sensor = ti_thermal_remove_sensor,
> +
> +	.sensors = {
> +		{
> +		.registers = &omap34xx_mpu_temp_sensor_registers,
> +		.ts_data = &omap34xx_mpu_temp_sensor_data,
> +		.domain = "cpu",
> +		.slope = 0,
> +		.constant = 20000,
> +		.slope_pcb = 0,
> +		.constant_pcb = 20000,
> +		.register_cooling = NULL,
> +		.unregister_cooling = NULL,
> +		},
> +	},
> +	.sensor_count = 1,
> +
> +//	.sensor_count = 0,
> +};
> +
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> index 634b6ce..a4180a5 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -40,6 +40,7 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_gpio.h>
>  #include <linux/io.h>
> +#include <linux/delay.h>
>  
>  #include "ti-bandgap.h"
>  
> @@ -103,19 +104,15 @@ do {								\
>   */
>  static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
>  {
> -	int i, ret = 0;
> +	int i;
>  
> -	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH)) {
> -		ret = -ENOTSUPP;
> -		goto exit;
> -	}
> +	if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH))
> +		return -ENOTSUPP;
>  
>  	for (i = 0; i < bgp->conf->sensor_count; i++)
>  		/* active on 0 */
>  		RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -154,6 +151,7 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp, int id)
>  	if (TI_BANDGAP_HAS(bgp, FREEZE_BIT))
>  		RMW_BITS(bgp, id, bgap_mask_ctrl, mask_freeze_mask, 0);
>  
> +	printk("Bandgap: ADC is %d\n", temp);
>  	return temp;
>  }
>  
> @@ -263,18 +261,13 @@ static
>  int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
>  {
>  	const struct ti_bandgap_data *conf = bgp->conf;
> -	int ret = 0;
>  
>  	/* look up for temperature in the table and return the temperature */
> -	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val) {
> -		ret = -ERANGE;
> -		goto exit;
> -	}
> +	if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val)
> +		return -ERANGE;
>  
>  	*t = bgp->conf->conv_table[adc_val - conf->adc_start_val];
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -295,16 +288,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
>  {
>  	const struct ti_bandgap_data *conf = bgp->conf;
>  	const int *conv_table = bgp->conf->conv_table;
> -	int high, low, mid, ret = 0;
> +	int high, low, mid;
>  
>  	low = 0;
>  	high = conf->adc_end_val - conf->adc_start_val;
>  	mid = (high + low) / 2;
>  
> -	if (temp < conv_table[low] || temp > conv_table[high]) {
> -		ret = -ERANGE;
> -		goto exit;
> -	}
> +	if (temp < conv_table[low] || temp > conv_table[high])
> +		return -ERANGE;
>  
>  	while (low < high) {
>  		if (temp < conv_table[mid])
> @@ -315,9 +306,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
>  	}
>  
>  	*adc = conf->adc_start_val + low;
> -
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -343,13 +332,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int adc_val, int hyst_val,
>  	 */
>  	ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, &temp);
>  	if (ret < 0)
> -		goto exit;
> +		return ret;
>  
>  	temp += hyst_val;
>  
>  	ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
> -
> -exit:
>  	return ret;
>  }
>  
> @@ -468,22 +455,18 @@ exit:
>   */
>  static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
>  {
> -	int ret = 0;
> -
>  	if (!bgp || IS_ERR(bgp)) {
>  		pr_err("%s: invalid bandgap pointer\n", __func__);
> -		ret = -EINVAL;
> -		goto exit;
> +		return -EINVAL;
>  	}
>  
>  	if ((id < 0) || (id >= bgp->conf->sensor_count)) {
>  		dev_err(bgp->dev, "%s: sensor id out of range (%d)\n",
>  			__func__, id);
> -		ret = -ERANGE;
> +		return -ERANGE;
>  	}
>  
> -exit:
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> @@ -511,12 +494,10 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
>  
>  	ret = ti_bandgap_validate(bgp, id);
>  	if (ret)
> -		goto exit;
> +		return ret;
>  
> -	if (!TI_BANDGAP_HAS(bgp, TALERT)) {
> -		ret = -ENOTSUPP;
> -		goto exit;
> -	}
> +	if (!TI_BANDGAP_HAS(bgp, TALERT))
> +		return -ENOTSUPP;
>  
>  	ts_data = bgp->conf->sensors[id].ts_data;
>  	tsr = bgp->conf->sensors[id].registers;
> @@ -529,17 +510,15 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
>  	}
>  
>  	if (ret)
> -		goto exit;
> -
> +		return ret;
> +	
>  	ret = ti_bandgap_mcelsius_to_adc(bgp, val, &adc_val);
>  	if (ret < 0)
> -		goto exit;
> +		return ret;		
>  
>  	spin_lock(&bgp->lock);
>  	ret = ti_bandgap_update_alert_threshold(bgp, id, adc_val, hot);
>  	spin_unlock(&bgp->lock);
> -
> -exit:
>  	return ret;
>  }
>  
> @@ -582,7 +561,7 @@ static int _ti_bandgap_read_threshold(struct ti_bandgap *bgp, int id,
>  
>  	temp = ti_bandgap_readl(bgp, tsr->bgap_threshold);
>  	temp = (temp & mask) >> __ffs(mask);
> -	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
> +	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
>  	if (ret) {
>  		dev_err(bgp->dev, "failed to read thot\n");
>  		ret = -EIO;
> @@ -856,10 +835,11 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id,
>  	temp = ti_bandgap_read_temp(bgp, id);
>  	spin_unlock(&bgp->lock);
>  
> -	ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
> +	ret = ti_bandgap_adc_to_mcelsius(bgp, temp, &temp);
>  	if (ret)
>  		return -EIO;
>  
> +	printk("Bandgap: temperature is %d\n", temp);
>  	*temperature = temp;
>  
>  	return 0;
> @@ -918,6 +898,7 @@ static int
>  ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
>  {
>  	u32 temp = 0, counter = 1000;
> +	struct temp_sensor_registers *tsr;
>  
>  	/* Select single conversion mode */
>  	if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
> @@ -925,16 +906,26 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
>  
>  	/* Start of Conversion = 1 */
>  	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
> -	/* Wait until DTEMP is updated */
> -	temp = ti_bandgap_read_temp(bgp, id);
>  
> -	while ((temp = 0) && --counter)
> -		temp = ti_bandgap_read_temp(bgp, id);
> -	/* REVISIT: Check correct condition for end of conversion */
> +	/* Wait for EOCZ going up */
> +	tsr = bgp->conf->sensors[id].registers;
> +	
> +	while (--counter) {
> +		if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask)
> +			break;
> +		printk("@");
> +	}
>  
>  	/* Start of Conversion = 0 */
>  	RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
>  
> +	counter = 1000;
> +	while (--counter) {
> +		if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask))
> +			break;
> +		printk("#");
> +	}
> +
>  	return 0;
>  }
>  
> @@ -1196,6 +1187,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  	struct ti_bandgap *bgp;
>  	int clk_rate, ret = 0, i;
>  
> +	printk("ti_bandgap: probe\n");
> +
>  	bgp = ti_bandgap_build(pdev);
>  	if (IS_ERR(bgp)) {
>  		dev_err(&pdev->dev, "failed to fetch platform data\n");
> @@ -1220,11 +1213,10 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  		goto free_irqs;
>  	}
>  
> -	bgp->div_clk = clk_get(NULL,  bgp->conf->div_ck_name);
> +	bgp->div_clk = clk_get(NULL, bgp->conf->div_ck_name);
>  	ret = IS_ERR(bgp->div_clk);
>  	if (ret) {
> -		dev_err(&pdev->dev,
> -			"failed to request div_ts_ck clock ref\n");
> +		dev_err(&pdev->dev, "failed to request div_ts_ck clock ref\n");
>  		ret = PTR_ERR(bgp->div_clk);
>  		goto free_irqs;
>  	}
> @@ -1312,6 +1304,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  	/* Every thing is good? Then expose the sensors */
>  	for (i = 0; i < bgp->conf->sensor_count; i++) {
>  		char *domain;
> +		extern int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
> +					     char *domain);
>  
>  		if (bgp->conf->sensors[i].register_cooling) {
>  			ret = bgp->conf->sensors[i].register_cooling(bgp, i);
> @@ -1319,12 +1313,29 @@ int ti_bandgap_probe(struct platform_device *pdev)
>  				goto remove_sensors;
>  		}
>  
> +		printk("bandgap: exposing sensor: %p\n", bgp->conf->expose_sensor);
> +		
>  		if (bgp->conf->expose_sensor) {
> +			printk("bandgap: calling %p %p\n", bgp->conf->expose_sensor, ti_thermal_expose_sensor);
>  			domain = bgp->conf->sensors[i].domain;
>  			ret = bgp->conf->expose_sensor(bgp, i, domain);
> +			printk("bandgap: done\n");
>  			if (ret)
>  				goto remove_last_cooling;
>  		}
> +
> +		printk("bandgap: exposing sensor\n");
> +		{
> +			int t;
> +
> +			ti_bandgap_force_single_read(bgp, 0);
> +
> +			t = ti_bandgap_read_temp(bgp, 0);
> +			printk("Temperature ADC: %d\n", t);			
> +			ti_bandgap_read_temperature(bgp, 0, &t);
> +			printk("Temperature: %d\n", t);
> +			mdelay(1000);
> +		}
>  	}
>  
>  	/*
> @@ -1365,6 +1376,8 @@ free_irqs:
>  		free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
>  		gpio_free(bgp->tshut_gpio);
>  	}
> +	printk("ti_bandgap: probe: something failed\n");
> +	mdelay(10000);
>  
>  	return ret;
>  }
> @@ -1509,6 +1522,12 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops, ti_bandgap_suspend,
>  #endif
>  
>  static const struct of_device_id of_ti_bandgap_match[] = {
> +#ifdef CONFIG_OMAP3_THERMAL
> +	{
> +		.compatible = "ti,omap34xx-bandgap",
> +		.data = (void *)&omap34xx_data,
> +	},
> +#endif
>  #ifdef CONFIG_OMAP4_THERMAL
>  	{
>  		.compatible = "ti,omap4430-bandgap",
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> index b3adf72..3f05386 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> @@ -384,6 +384,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data);
>  void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
>  int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
>  
> +extern const struct ti_bandgap_data omap34xx_data;
> +
>  #ifdef CONFIG_OMAP4_THERMAL
>  extern const struct ti_bandgap_data omap4430_data;
>  extern const struct ti_bandgap_data omap4460_data;
> diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> index 5fd0386..f91655f 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> @@ -328,18 +328,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
>  {
>  	struct ti_thermal_data *data;
>  
> +	printk("expose_sensor\n");
> +
>  	data = ti_bandgap_get_sensor_data(bgp, id);
>  
>  	if (!data || IS_ERR(data))
>  		data = ti_thermal_build_data(bgp, id);
>  
> -	if (!data)
> +	if (!data) {
> +		printk("no data\n");	
>  		return -EINVAL;
> +	}
>  
>  	/* in case this is specified by DT */
>  	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
>  					data, &ti_of_thermal_ops);
>  	if (IS_ERR(data->ti_thermal)) {
> +		printk("of_sensor_register failed\n");
>  		/* Create thermal zone */
>  		data->ti_thermal = thermal_zone_device_register(domain,
>  				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,
> 
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2015-01-07 16:19                 ` Guenter Roeck
  (?)
@ 2015-01-18 20:33                   ` Pavel Machek
  -1 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-18 20:33 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Wed 2015-01-07 08:19:44, Guenter Roeck wrote:
> On Sat, Jan 03, 2015 at 10:18:58AM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> > > On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > > > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > > >> which can be used to determine the SoCs temperature. This patch provides
> > > > > >> a DT based driver for the temperature sensor based on an older driver
> > > > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > > > >
> > > > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > > > OMAPs, which are already supported by maybe
> > > > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > > > that driver instead?
> > > > > 
> > > > > Just to be clear - OMAP4 is the first time that the sensors were
> > > > > reliable enough to be used.
> > > > 
> > > > When testing initial version of the patch, they seem to work very well
> > > > in the omap3 case.
> > > > 
> > > Pavel,
> > > 
> > > can you look into the omap4 thermal driver to see if it can be used ?
> > 
> > After some fixes... yes, it seems to be same hardware.
> > 
> So this should be the way to go, but then we have others claim that
> it should not be done because the OMAP3 sensors are too unreliable
> to use for thermal decisions. Not really sure where that leaves us.
> I am kind of opposed to have similar drivers for similar chips
> in two different subsystems.
> 
> Is it possible to add the patch below to the omap thermal driver
> and not use it for thermal decisions ?

Well... noone forces you to enable the driver, and I don't think it
will do any thermal decisions on N900 as it is ... so we should be ok.

Plus, it seems to work reasonably well (say +- 5 C), so situation does
not seem to be as bad as TI claims.

Nokia was actually using it in production.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-18 20:33                   ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-18 20:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed 2015-01-07 08:19:44, Guenter Roeck wrote:
> On Sat, Jan 03, 2015 at 10:18:58AM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> > > On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > > > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > > >> which can be used to determine the SoCs temperature. This patch provides
> > > > > >> a DT based driver for the temperature sensor based on an older driver
> > > > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > > > >
> > > > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > > > OMAPs, which are already supported by maybe
> > > > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > > > that driver instead?
> > > > > 
> > > > > Just to be clear - OMAP4 is the first time that the sensors were
> > > > > reliable enough to be used.
> > > > 
> > > > When testing initial version of the patch, they seem to work very well
> > > > in the omap3 case.
> > > > 
> > > Pavel,
> > > 
> > > can you look into the omap4 thermal driver to see if it can be used ?
> > 
> > After some fixes... yes, it seems to be same hardware.
> > 
> So this should be the way to go, but then we have others claim that
> it should not be done because the OMAP3 sensors are too unreliable
> to use for thermal decisions. Not really sure where that leaves us.
> I am kind of opposed to have similar drivers for similar chips
> in two different subsystems.
> 
> Is it possible to add the patch below to the omap thermal driver
> and not use it for thermal decisions ?

Well... noone forces you to enable the driver, and I don't think it
will do any thermal decisions on N900 as it is ... so we should be ok.

Plus, it seems to work reasonably well (say +- 5 C), so situation does
not seem to be as bad as TI claims.

Nokia was actually using it in production.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-18 20:33                   ` Pavel Machek
  0 siblings, 0 replies; 115+ messages in thread
From: Pavel Machek @ 2015-01-18 20:33 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On Wed 2015-01-07 08:19:44, Guenter Roeck wrote:
> On Sat, Jan 03, 2015 at 10:18:58AM +0100, Pavel Machek wrote:
> > On Mon 2014-12-29 11:04:48, Guenter Roeck wrote:
> > > On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote:
> > > > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote:
> > > > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > > > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > > > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > > > > >> which can be used to determine the SoCs temperature. This patch provides
> > > > > >> a DT based driver for the temperature sensor based on an older driver
> > > > > >> written by Peter De Schrijver for the Nokia N900 and N9.
> > > > > >
> > > > > > The sensor looks like an earlier iteration of sensors used in newer
> > > > > > OMAPs, which are already supported by maybe
> > > > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
> > > > > > that driver instead?
> > > > > 
> > > > > Just to be clear - OMAP4 is the first time that the sensors were
> > > > > reliable enough to be used.
> > > > 
> > > > When testing initial version of the patch, they seem to work very well
> > > > in the omap3 case.
> > > > 
> > > Pavel,
> > > 
> > > can you look into the omap4 thermal driver to see if it can be used ?
> > 
> > After some fixes... yes, it seems to be same hardware.
> > 
> So this should be the way to go, but then we have others claim that
> it should not be done because the OMAP3 sensors are too unreliable
> to use for thermal decisions. Not really sure where that leaves us.
> I am kind of opposed to have similar drivers for similar chips
> in two different subsystems.
> 
> Is it possible to add the patch below to the omap thermal driver
> and not use it for thermal decisions ?

Well... noone forces you to enable the driver, and I don't think it
will do any thermal decisions on N900 as it is ... so we should be ok.

Plus, it seems to work reasonably well (say +- 5 C), so situation does
not seem to be as bad as TI claims.

Nokia was actually using it in production.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
  2015-01-18 20:33                   ` Pavel Machek
  (?)
@ 2015-01-18 22:18                     ` Guenter Roeck
  -1 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2015-01-18 22:18 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On 01/18/2015 12:33 PM, Pavel Machek wrote:

>>>> Pavel,
>>>>
>>>> can you look into the omap4 thermal driver to see if it can be used ?
>>>
>>> After some fixes... yes, it seems to be same hardware.
>>>
>> So this should be the way to go, but then we have others claim that
>> it should not be done because the OMAP3 sensors are too unreliable
>> to use for thermal decisions. Not really sure where that leaves us.
>> I am kind of opposed to have similar drivers for similar chips
>> in two different subsystems.
>>
>> Is it possible to add the patch below to the omap thermal driver
>> and not use it for thermal decisions ?
>
> Well... noone forces you to enable the driver, and I don't think it
> will do any thermal decisions on N900 as it is ... so we should be ok.
>
> Plus, it seems to work reasonably well (say +- 5 C), so situation does
> not seem to be as bad as TI claims.
>
> Nokia was actually using it in production.
>
Ok, I'll assume that omap3 support will be added to the omap thermal driver.

Thanks,
Guenter


^ permalink raw reply	[flat|nested] 115+ messages in thread
* [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-18 22:18                     ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2015-01-18 22:18 UTC (permalink / raw)
  To: linux-arm-kernel

On 01/18/2015 12:33 PM, Pavel Machek wrote:

>>>> Pavel,
>>>>
>>>> can you look into the omap4 thermal driver to see if it can be used ?
>>>
>>> After some fixes... yes, it seems to be same hardware.
>>>
>> So this should be the way to go, but then we have others claim that
>> it should not be done because the OMAP3 sensors are too unreliable
>> to use for thermal decisions. Not really sure where that leaves us.
>> I am kind of opposed to have similar drivers for similar chips
>> in two different subsystems.
>>
>> Is it possible to add the patch below to the omap thermal driver
>> and not use it for thermal decisions ?
>
> Well... noone forces you to enable the driver, and I don't think it
> will do any thermal decisions on N900 as it is ... so we should be ok.
>
> Plus, it seems to work reasonably well (say +- 5 C), so situation does
> not seem to be as bad as TI claims.
>
> Nokia was actually using it in production.
>
Ok, I'll assume that omap3 support will be added to the omap thermal driver.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 115+ messages in thread
* Re: [lm-sensors] [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
@ 2015-01-18 22:18                     ` Guenter Roeck
  0 siblings, 0 replies; 115+ messages in thread
From: Guenter Roeck @ 2015-01-18 22:18 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Nishanth Menon, Grazvydas Ignotas, Sebastian Reichel,
	Mark Rutland, dt list, Pawel Moll, Ian Campbell, Tony Lindgren,
	Kumar Gala, linux-kernel, lm-sensors, Rob Herring, Jean Delvare,
	Benoît Cousson, Pali Rohar, linux-omap, linux-arm-kernel

On 01/18/2015 12:33 PM, Pavel Machek wrote:

>>>> Pavel,
>>>>
>>>> can you look into the omap4 thermal driver to see if it can be used ?
>>>
>>> After some fixes... yes, it seems to be same hardware.
>>>
>> So this should be the way to go, but then we have others claim that
>> it should not be done because the OMAP3 sensors are too unreliable
>> to use for thermal decisions. Not really sure where that leaves us.
>> I am kind of opposed to have similar drivers for similar chips
>> in two different subsystems.
>>
>> Is it possible to add the patch below to the omap thermal driver
>> and not use it for thermal decisions ?
>
> Well... noone forces you to enable the driver, and I don't think it
> will do any thermal decisions on N900 as it is ... so we should be ok.
>
> Plus, it seems to work reasonably well (say +- 5 C), so situation does
> not seem to be as bad as TI claims.
>
> Nokia was actually using it in production.
>
Ok, I'll assume that omap3 support will be added to the omap thermal driver.

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 115+ messages in thread
end of thread, other threads:[~2015-01-18 22:19 UTC | newest]

Thread overview: 115+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-26 10:29 [PATCH] add omap34xx temperature monitoring support Pavel Machek
2014-12-26 10:29 ` [lm-sensors] " Pavel Machek
2014-12-26 10:29 ` Pavel Machek
2014-12-26 12:34 ` [PATCH 0/3] OMAP3 temperature sensor Sebastian Reichel
2014-12-26 12:34   ` [lm-sensors] " Sebastian Reichel
2014-12-26 12:34   ` Sebastian Reichel
2014-12-26 12:34   ` Sebastian Reichel
2014-12-26 12:34   ` [PATCH 1/3] DT Binding for omap3 " Sebastian Reichel
2014-12-26 12:34     ` [lm-sensors] " Sebastian Reichel
2014-12-26 12:34     ` Sebastian Reichel
2014-12-26 17:19     ` Pavel Machek
2014-12-26 17:19       ` [lm-sensors] " Pavel Machek
2014-12-26 17:19       ` Pavel Machek
2014-12-26 17:19       ` Pavel Machek
2014-12-26 23:50       ` Sebastian Reichel
2014-12-26 23:50         ` [lm-sensors] " Sebastian Reichel
2014-12-26 23:50         ` Sebastian Reichel
2014-12-26 23:50         ` Sebastian Reichel
2014-12-27 19:09     ` Pavel Machek
2014-12-27 19:09       ` [lm-sensors] " Pavel Machek
2014-12-27 19:09       ` Pavel Machek
2014-12-27 19:09       ` Pavel Machek
2014-12-26 12:34   ` [PATCH 2/3] hwmon: Driver for OMAP3 " Sebastian Reichel
2014-12-26 12:34     ` [lm-sensors] " Sebastian Reichel
2014-12-26 12:34     ` Sebastian Reichel
2014-12-26 17:26     ` Pavel Machek
2014-12-26 17:26       ` [lm-sensors] " Pavel Machek
2014-12-26 17:26       ` Pavel Machek
2014-12-27 19:24     ` Pavel Machek
2014-12-27 19:24       ` [lm-sensors] " Pavel Machek
2014-12-27 19:24       ` Pavel Machek
2014-12-27 19:40     ` Pavel Machek
2014-12-27 19:40       ` [lm-sensors] " Pavel Machek
2014-12-27 19:40       ` Pavel Machek
2014-12-27 19:48     ` Pavel Machek
2014-12-27 19:48       ` [lm-sensors] " Pavel Machek
2014-12-27 19:48       ` Pavel Machek
2014-12-27 19:58     ` Pavel Machek
2014-12-27 19:58       ` [lm-sensors] " Pavel Machek
2014-12-27 19:58       ` Pavel Machek
2014-12-27 19:58       ` Pavel Machek
2014-12-27 22:35       ` Pavel Machek
2014-12-27 22:35         ` [lm-sensors] " Pavel Machek
2014-12-27 22:35         ` Pavel Machek
2014-12-28  8:24         ` Guenter Roeck
2014-12-28  8:24           ` [lm-sensors] " Guenter Roeck
2014-12-28  8:24           ` Guenter Roeck
2014-12-28 10:07           ` Sebastian Reichel
2014-12-28 10:07             ` [lm-sensors] " Sebastian Reichel
2014-12-28 10:07             ` Sebastian Reichel
2014-12-28 10:07             ` Sebastian Reichel
2014-12-27 23:26     ` Pavel Machek
2014-12-27 23:26       ` [lm-sensors] " Pavel Machek
2014-12-27 23:26       ` Pavel Machek
2014-12-29 17:52     ` Grazvydas Ignotas
2014-12-29 17:52       ` [lm-sensors] " Grazvydas Ignotas
2014-12-29 17:52       ` Grazvydas Ignotas
2014-12-29 17:52       ` Grazvydas Ignotas
2014-12-29 18:01       ` Nishanth Menon
2014-12-29 18:01         ` [lm-sensors] " Nishanth Menon
2014-12-29 18:01         ` Nishanth Menon
2014-12-29 18:15         ` Pavel Machek
2014-12-29 18:15           ` [lm-sensors] " Pavel Machek
2014-12-29 18:15           ` Pavel Machek
2014-12-29 18:15           ` Pavel Machek
2014-12-29 19:04           ` Guenter Roeck
2014-12-29 19:04             ` [lm-sensors] " Guenter Roeck
2014-12-29 19:04             ` Guenter Roeck
2014-12-29 19:04             ` Guenter Roeck
2014-12-30 22:46             ` Pavel Machek
2014-12-30 22:46               ` [lm-sensors] " Pavel Machek
2014-12-30 22:46               ` Pavel Machek
2014-12-30 22:46               ` Pavel Machek
2015-01-01  9:11             ` Pavel Machek
2015-01-01  9:11               ` [lm-sensors] " Pavel Machek
2015-01-01  9:11               ` Pavel Machek
2015-01-03  9:18             ` Pavel Machek
2015-01-03  9:18               ` [lm-sensors] " Pavel Machek
2015-01-03  9:18               ` Pavel Machek
2015-01-07 16:19               ` Guenter Roeck
2015-01-07 16:19                 ` [lm-sensors] " Guenter Roeck
2015-01-07 16:19                 ` Guenter Roeck
2015-01-18 20:33                 ` Pavel Machek
2015-01-18 20:33                   ` [lm-sensors] " Pavel Machek
2015-01-18 20:33                   ` Pavel Machek
2015-01-18 22:18                   ` Guenter Roeck
2015-01-18 22:18                     ` [lm-sensors] " Guenter Roeck
2015-01-18 22:18                     ` Guenter Roeck
2014-12-29 20:35           ` Nishanth Menon
2014-12-29 20:35             ` [lm-sensors] " Nishanth Menon
2014-12-29 20:35             ` Nishanth Menon
2014-12-29 20:35             ` Nishanth Menon
2014-12-30 18:00             ` Pavel Machek
2014-12-30 18:00               ` [lm-sensors] " Pavel Machek
2014-12-30 18:00               ` Pavel Machek
2014-12-30 18:00               ` Pavel Machek
2014-12-26 12:34   ` [PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add " Sebastian Reichel
2014-12-26 12:34     ` [lm-sensors] " Sebastian Reichel
2014-12-26 12:34     ` Sebastian Reichel
2014-12-27 19:09     ` Pavel Machek
2014-12-27 19:09       ` [lm-sensors] " Pavel Machek
2014-12-27 19:09       ` Pavel Machek
2014-12-27 19:09       ` Pavel Machek
2014-12-26 15:54 ` [PATCH] add omap34xx temperature monitoring support Tony Lindgren
2014-12-26 15:54   ` [lm-sensors] " Tony Lindgren
2014-12-26 15:54   ` Tony Lindgren
2014-12-26 16:17   ` Tony Lindgren
2014-12-26 16:17     ` [lm-sensors] " Tony Lindgren
2014-12-26 16:17     ` Tony Lindgren
2014-12-26 16:26     ` Pali Rohár
2014-12-26 16:26       ` [lm-sensors] " Pali Rohár
2014-12-26 16:26       ` Pali Rohár
2014-12-26 16:31       ` Tony Lindgren
2014-12-26 16:31         ` [lm-sensors] " Tony Lindgren
2014-12-26 16:31         ` Tony Lindgren

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.