* [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
@ 2011-09-07 9:49 Donggeun Kim
2011-09-07 16:06 ` Guenter Roeck
2011-11-15 20:34 ` Paul Bolle
0 siblings, 2 replies; 10+ messages in thread
From: Donggeun Kim @ 2011-09-07 9:49 UTC (permalink / raw)
To: lm-sensors
This patch allows to read temperature
from TMU(Thermal Management Unit) of SAMSUNG EXYNOS4 series of SoC.
Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
Changes for v7
- removed sysfs_notify function call
- changed kobject_uevent_env to kobject_uevent
- cleaned up documentation
Changes for v6
- changed type of a variable in read function
- cleaned up code
Changes for v5
- added checking range of temp and temp code
- cleaned up code
Changes for v4
- added comment for unit of threshold and trigger_levels
- cleaned up code
Changes for v3
- cleaned up redundant code
- added mutex
- changed error codes
Changes for v2
- added six attributes for alarms
- changed error code of EAGAIN
- changed initialize function to return error code
Documentation/hwmon/exynos4_tmu | 81 +++++
drivers/hwmon/Kconfig | 10 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/exynos4_tmu.c | 524 +++++++++++++++++++++++++++++
include/linux/platform_data/exynos4_tmu.h | 83 +++++
5 files changed, 699 insertions(+), 0 deletions(-)
create mode 100644 Documentation/hwmon/exynos4_tmu
create mode 100644 drivers/hwmon/exynos4_tmu.c
create mode 100644 include/linux/platform_data/exynos4_tmu.h
diff --git a/Documentation/hwmon/exynos4_tmu b/Documentation/hwmon/exynos4_tmu
new file mode 100644
index 0000000..c3c6b41
--- /dev/null
+++ b/Documentation/hwmon/exynos4_tmu
@@ -0,0 +1,81 @@
+Kernel driver exynos4_tmu
+========+
+Supported chips:
+* ARM SAMSUNG EXYNOS4 series of SoC
+ Prefix: 'exynos4-tmu'
+ Datasheet: Not publicly available
+
+Authors: Donggeun Kim <dg77.kim@samsung.com>
+
+Description
+-----------
+
+This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC.
+
+The chip only exposes the measured 8-bit temperature code value
+through a register.
+Temperature can be taken from the temperature code.
+There are three equations converting from temperature to temperature code.
+
+The three equations are:
+ 1. Two point trimming
+ Tc = (T - 25) * (TI2 - TI1) / (85 - 25) + TI1
+
+ 2. One point trimming
+ Tc = T + TI1 - 25
+
+ 3. No trimming
+ Tc = T + 50
+
+ Tc: Temperature code, T: Temperature,
+ TI1: Trimming info for 25 degree Celsius (stored at TRIMINFO register)
+ Temperature code measured at 25 degree Celsius which is unchanged
+ TI2: Trimming info for 85 degree Celsius (stored at TRIMINFO register)
+ Temperature code measured at 85 degree Celsius which is unchanged
+
+TMU(Thermal Management Unit) in EXYNOS4 generates interrupt
+when temperature exceeds pre-defined levels.
+The maximum number of configurable threshold is four.
+The threshold levels are defined as follows:
+ Level_0: current temperature > trigger_level_0 + threshold
+ Level_1: current temperature > trigger_level_1 + threshold
+ Level_2: current temperature > trigger_level_2 + threshold
+ Level_3: current temperature > trigger_level_3 + threshold
+
+ The threshold and each trigger_level are set
+ through the corresponding registers.
+
+When an interrupt occurs, this driver notify user space of
+one of four threshold levels for the interrupt
+through kobject_uevent_env and sysfs_notify functions.
+Although an interrupt condition for level_0 can be set,
+it is not notified to user space through sysfs_notify function.
+
+Sysfs Interface
+---------------
+name name of the temperature sensor
+ RO
+
+temp1_input temperature
+ RO
+
+temp1_max temperature for level_1 interrupt
+ RO
+
+temp1_crit temperature for level_2 interrupt
+ RO
+
+temp1_emergency temperature for level_3 interrupt
+ RO
+
+temp1_max_alarm alarm for level_1 interrupt
+ RO
+
+temp1_crit_alarm
+ alarm for level_2 interrupt
+ RO
+
+temp1_emergency_alarm
+ alarm for level_3 interrupt
+ RO
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 0b62c3c..c6fb761 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -303,6 +303,16 @@ config SENSORS_DS1621
This driver can also be built as a module. If so, the module
will be called ds1621.
+config SENSORS_EXYNOS4_TMU
+ tristate "Temperature sensor on Samsung EXYNOS4"
+ depends on EXYNOS4_DEV_TMU
+ help
+ If you say yes here you get support for TMU (Thermal Managment
+ Unit) on SAMSUNG EXYNOS4 series of SoC.
+
+ This driver can also be built as a module. If so, the module
+ will be called exynos4-tmu.
+
config SENSORS_I5K_AMB
tristate "FB-DIMM AMB temperature sensor on Intel 5000 series chipsets"
depends on PCI && EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 3c9ccef..dbd8963 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o
obj-$(CONFIG_SENSORS_EMC2103) += emc2103.o
obj-$(CONFIG_SENSORS_EMC6W201) += emc6w201.o
+obj-$(CONFIG_SENSORS_EXYNOS4_TMU) += exynos4_tmu.o
obj-$(CONFIG_SENSORS_F71805F) += f71805f.o
obj-$(CONFIG_SENSORS_F71882FG) += f71882fg.o
obj-$(CONFIG_SENSORS_F75375S) += f75375s.o
diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
new file mode 100644
index 0000000..0170c90
--- /dev/null
+++ b/drivers/hwmon/exynos4_tmu.c
@@ -0,0 +1,524 @@
+/*
+ * exynos4_tmu.c - Samsung EXYNOS4 TMU (Thermal Management Unit)
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ * Donggeun Kim <dg77.kim@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/clk.h>
+#include <linux/workqueue.h>
+#include <linux/sysfs.h>
+#include <linux/kobject.h>
+#include <linux/io.h>
+#include <linux/mutex.h>
+
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+
+#include <linux/platform_data/exynos4_tmu.h>
+
+#define EXYNOS4_TMU_REG_TRIMINFO 0x0
+#define EXYNOS4_TMU_REG_CONTROL 0x20
+#define EXYNOS4_TMU_REG_STATUS 0x28
+#define EXYNOS4_TMU_REG_CURRENT_TEMP 0x40
+#define EXYNOS4_TMU_REG_THRESHOLD_TEMP 0x44
+#define EXYNOS4_TMU_REG_TRIG_LEVEL0 0x50
+#define EXYNOS4_TMU_REG_TRIG_LEVEL1 0x54
+#define EXYNOS4_TMU_REG_TRIG_LEVEL2 0x58
+#define EXYNOS4_TMU_REG_TRIG_LEVEL3 0x5C
+#define EXYNOS4_TMU_REG_PAST_TEMP0 0x60
+#define EXYNOS4_TMU_REG_PAST_TEMP1 0x64
+#define EXYNOS4_TMU_REG_PAST_TEMP2 0x68
+#define EXYNOS4_TMU_REG_PAST_TEMP3 0x6C
+#define EXYNOS4_TMU_REG_INTEN 0x70
+#define EXYNOS4_TMU_REG_INTSTAT 0x74
+#define EXYNOS4_TMU_REG_INTCLEAR 0x78
+
+#define EXYNOS4_TMU_GAIN_SHIFT 8
+#define EXYNOS4_TMU_REF_VOLTAGE_SHIFT 24
+
+#define EXYNOS4_TMU_TRIM_TEMP_MASK 0xff
+#define EXYNOS4_TMU_CORE_ON 3
+#define EXYNOS4_TMU_CORE_OFF 2
+#define EXYNOS4_TMU_DEF_CODE_TO_TEMP_OFFSET 50
+#define EXYNOS4_TMU_TRIG_LEVEL0_MASK 0x1
+#define EXYNOS4_TMU_TRIG_LEVEL1_MASK 0x10
+#define EXYNOS4_TMU_TRIG_LEVEL2_MASK 0x100
+#define EXYNOS4_TMU_TRIG_LEVEL3_MASK 0x1000
+#define EXYNOS4_TMU_INTCLEAR_VAL 0x1111
+
+struct exynos4_tmu_data {
+ struct exynos4_tmu_platform_data *pdata;
+ struct device *hwmon_dev;
+ struct resource *mem;
+ void __iomem *base;
+ int irq;
+ struct work_struct irq_work;
+ struct mutex lock;
+ struct clk *clk;
+ u8 temp_error1, temp_error2;
+};
+
+/*
+ * TMU treats temperature as a mapped temperature code.
+ * The temperature is converted differently depending on the calibration type.
+ */
+static int temp_to_code(struct exynos4_tmu_data *data, u8 temp)
+{
+ struct exynos4_tmu_platform_data *pdata = data->pdata;
+ int temp_code;
+
+ /* temp should range between 25 and 125 */
+ if (temp < 25 || temp > 125) {
+ temp_code = -EINVAL;
+ goto out;
+ }
+
+ switch (pdata->cal_type) {
+ case TYPE_TWO_POINT_TRIMMING:
+ temp_code = (temp - 25) *
+ (data->temp_error2 - data->temp_error1) /
+ (85 - 25) + data->temp_error1;
+ break;
+ case TYPE_ONE_POINT_TRIMMING:
+ temp_code = temp + data->temp_error1 - 25;
+ break;
+ default:
+ temp_code = temp + EXYNOS4_TMU_DEF_CODE_TO_TEMP_OFFSET;
+ break;
+ }
+out:
+ return temp_code;
+}
+
+/*
+ * Calculate a temperature value from a temperature code.
+ * The unit of the temperature is degree Celsius.
+ */
+static int code_to_temp(struct exynos4_tmu_data *data, u8 temp_code)
+{
+ struct exynos4_tmu_platform_data *pdata = data->pdata;
+ int temp;
+
+ /* temp_code should range between 75 and 175 */
+ if (temp_code < 75 || temp_code > 175) {
+ temp = -ENODATA;
+ goto out;
+ }
+
+ switch (pdata->cal_type) {
+ case TYPE_TWO_POINT_TRIMMING:
+ temp = (temp_code - data->temp_error1) * (85 - 25) /
+ (data->temp_error2 - data->temp_error1) + 25;
+ break;
+ case TYPE_ONE_POINT_TRIMMING:
+ temp = temp_code - data->temp_error1 + 25;
+ break;
+ default:
+ temp = temp_code - EXYNOS4_TMU_DEF_CODE_TO_TEMP_OFFSET;
+ break;
+ }
+out:
+ return temp;
+}
+
+static int exynos4_tmu_initialize(struct platform_device *pdev)
+{
+ struct exynos4_tmu_data *data = platform_get_drvdata(pdev);
+ struct exynos4_tmu_platform_data *pdata = data->pdata;
+ unsigned int status, trim_info;
+ int ret = 0, threshold_code;
+
+ mutex_lock(&data->lock);
+ clk_enable(data->clk);
+
+ status = readb(data->base + EXYNOS4_TMU_REG_STATUS);
+ if (!status) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ /* Save trimming info in order to perform calibration */
+ trim_info = readl(data->base + EXYNOS4_TMU_REG_TRIMINFO);
+ data->temp_error1 = trim_info & EXYNOS4_TMU_TRIM_TEMP_MASK;
+ data->temp_error2 = ((trim_info >> 8) & EXYNOS4_TMU_TRIM_TEMP_MASK);
+
+ /* Write temperature code for threshold */
+ threshold_code = temp_to_code(data, pdata->threshold);
+ if (threshold_code < 0) {
+ ret = threshold_code;
+ goto out;
+ }
+ writeb(threshold_code,
+ data->base + EXYNOS4_TMU_REG_THRESHOLD_TEMP);
+
+ writeb(pdata->trigger_levels[0],
+ data->base + EXYNOS4_TMU_REG_TRIG_LEVEL0);
+ writeb(pdata->trigger_levels[1],
+ data->base + EXYNOS4_TMU_REG_TRIG_LEVEL1);
+ writeb(pdata->trigger_levels[2],
+ data->base + EXYNOS4_TMU_REG_TRIG_LEVEL2);
+ writeb(pdata->trigger_levels[3],
+ data->base + EXYNOS4_TMU_REG_TRIG_LEVEL3);
+
+ writel(EXYNOS4_TMU_INTCLEAR_VAL,
+ data->base + EXYNOS4_TMU_REG_INTCLEAR);
+out:
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static void exynos4_tmu_control(struct platform_device *pdev, bool on)
+{
+ struct exynos4_tmu_data *data = platform_get_drvdata(pdev);
+ struct exynos4_tmu_platform_data *pdata = data->pdata;
+ unsigned int con, interrupt_en;
+
+ mutex_lock(&data->lock);
+ clk_enable(data->clk);
+
+ con = pdata->reference_voltage << EXYNOS4_TMU_REF_VOLTAGE_SHIFT |
+ pdata->gain << EXYNOS4_TMU_GAIN_SHIFT;
+ if (on) {
+ con |= EXYNOS4_TMU_CORE_ON;
+ interrupt_en = pdata->trigger_level3_en << 12 |
+ pdata->trigger_level2_en << 8 |
+ pdata->trigger_level1_en << 4 |
+ pdata->trigger_level0_en;
+ } else {
+ con |= EXYNOS4_TMU_CORE_OFF;
+ interrupt_en = 0; /* Disable all interrupts */
+ }
+ writel(interrupt_en, data->base + EXYNOS4_TMU_REG_INTEN);
+ writel(con, data->base + EXYNOS4_TMU_REG_CONTROL);
+
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+}
+
+static int exynos4_tmu_read(struct exynos4_tmu_data *data)
+{
+ u8 temp_code;
+ int temp;
+
+ mutex_lock(&data->lock);
+ clk_enable(data->clk);
+
+ temp_code = readb(data->base + EXYNOS4_TMU_REG_CURRENT_TEMP);
+ temp = code_to_temp(data, temp_code);
+
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+
+ return temp;
+}
+
+static void exynos4_tmu_work(struct work_struct *work)
+{
+ struct exynos4_tmu_data *data = container_of(work,
+ struct exynos4_tmu_data, irq_work);
+
+ mutex_lock(&data->lock);
+ clk_enable(data->clk);
+
+ writel(EXYNOS4_TMU_INTCLEAR_VAL, data->base + EXYNOS4_TMU_REG_INTCLEAR);
+
+ kobject_uevent(&data->hwmon_dev->kobj, KOBJ_CHANGE);
+
+ enable_irq(data->irq);
+
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+}
+
+static irqreturn_t exynos4_tmu_irq(int irq, void *id)
+{
+ struct exynos4_tmu_data *data = id;
+
+ disable_irq_nosync(irq);
+ schedule_work(&data->irq_work);
+
+ return IRQ_HANDLED;
+}
+
+static ssize_t exynos4_tmu_show_name(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "exynos4-tmu\n");
+}
+
+static ssize_t exynos4_tmu_show_temp(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct exynos4_tmu_data *data = dev_get_drvdata(dev);
+ int ret;
+
+ ret = exynos4_tmu_read(data);
+ if (ret < 0)
+ return ret;
+
+ /* convert from degree Celsius to millidegree Celsius */
+ return sprintf(buf, "%d\n", ret * 1000);
+}
+
+static ssize_t exynos4_tmu_show_alarm(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct exynos4_tmu_data *data = dev_get_drvdata(dev);
+ struct exynos4_tmu_platform_data *pdata = data->pdata;
+ int temp;
+ unsigned int trigger_level;
+
+ temp = exynos4_tmu_read(data);
+ if (temp < 0)
+ return temp;
+
+ trigger_level = pdata->threshold + pdata->trigger_levels[attr->index];
+
+ return sprintf(buf, "%d\n", !!(temp > trigger_level));
+}
+
+static ssize_t exynos4_tmu_show_level(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct exynos4_tmu_data *data = dev_get_drvdata(dev);
+ struct exynos4_tmu_platform_data *pdata = data->pdata;
+ unsigned int temp = pdata->threshold +
+ pdata->trigger_levels[attr->index];
+
+ return sprintf(buf, "%u\n", temp * 1000);
+}
+
+static DEVICE_ATTR(name, S_IRUGO, exynos4_tmu_show_name, NULL);
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, exynos4_tmu_show_temp, NULL, 0);
+
+static SENSOR_DEVICE_ATTR(temp1_max_alarm, S_IRUGO,
+ exynos4_tmu_show_alarm, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp1_crit_alarm, S_IRUGO,
+ exynos4_tmu_show_alarm, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp1_emergency_alarm, S_IRUGO,
+ exynos4_tmu_show_alarm, NULL, 3);
+
+static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO, exynos4_tmu_show_level, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp1_crit, S_IRUGO, exynos4_tmu_show_level, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp1_emergency, S_IRUGO,
+ exynos4_tmu_show_level, NULL, 3);
+
+static struct attribute *exynos4_tmu_attributes[] = {
+ &dev_attr_name.attr,
+ &sensor_dev_attr_temp1_input.dev_attr.attr,
+ &sensor_dev_attr_temp1_max_alarm.dev_attr.attr,
+ &sensor_dev_attr_temp1_crit_alarm.dev_attr.attr,
+ &sensor_dev_attr_temp1_emergency_alarm.dev_attr.attr,
+ &sensor_dev_attr_temp1_max.dev_attr.attr,
+ &sensor_dev_attr_temp1_crit.dev_attr.attr,
+ &sensor_dev_attr_temp1_emergency.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group exynos4_tmu_attr_group = {
+ .attrs = exynos4_tmu_attributes,
+};
+
+static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
+{
+ struct exynos4_tmu_data *data;
+ struct exynos4_tmu_platform_data *pdata = pdev->dev.platform_data;
+ int ret;
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "No platform init data supplied.\n");
+ return -ENODEV;
+ }
+
+ data = kzalloc(sizeof(struct exynos4_tmu_data), GFP_KERNEL);
+ if (!data) {
+ dev_err(&pdev->dev, "Failed to allocate driver structure\n");
+ return -ENOMEM;
+ }
+
+ data->irq = platform_get_irq(pdev, 0);
+ if (data->irq < 0) {
+ ret = data->irq;
+ dev_err(&pdev->dev, "Failed to get platform irq\n");
+ goto err_free;
+ }
+
+ INIT_WORK(&data->irq_work, exynos4_tmu_work);
+
+ data->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!data->mem) {
+ ret = -ENOENT;
+ dev_err(&pdev->dev, "Failed to get platform resource\n");
+ goto err_free;
+ }
+
+ data->mem = request_mem_region(data->mem->start,
+ resource_size(data->mem), pdev->name);
+ if (!data->mem) {
+ ret = -ENODEV;
+ dev_err(&pdev->dev, "Failed to request memory region\n");
+ goto err_free;
+ }
+
+ data->base = ioremap(data->mem->start, resource_size(data->mem));
+ if (!data->base) {
+ ret = -ENODEV;
+ dev_err(&pdev->dev, "Failed to ioremap memory\n");
+ goto err_mem_region;
+ }
+
+ ret = request_irq(data->irq, exynos4_tmu_irq,
+ IRQF_DISABLED | IRQF_TRIGGER_RISING,
+ "exynos4-tmu", data);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request irq: %d\n", data->irq);
+ goto err_io_remap;
+ }
+
+ data->clk = clk_get(NULL, "tmu_apbif");
+ if (IS_ERR(data->clk)) {
+ ret = PTR_ERR(data->clk);
+ dev_err(&pdev->dev, "Failed to get clock\n");
+ goto err_irq;
+ }
+
+ data->pdata = pdata;
+ platform_set_drvdata(pdev, data);
+ mutex_init(&data->lock);
+
+ ret = exynos4_tmu_initialize(pdev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to initialize TMU\n");
+ goto err_clk;
+ }
+
+ ret = sysfs_create_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to create sysfs group\n");
+ goto err_clk;
+ }
+
+ data->hwmon_dev = hwmon_device_register(&pdev->dev);
+ if (IS_ERR(data->hwmon_dev)) {
+ ret = PTR_ERR(data->hwmon_dev);
+ dev_err(&pdev->dev, "Failed to register hwmon device\n");
+ goto err_create_group;
+ }
+
+ exynos4_tmu_control(pdev, true);
+
+ return 0;
+
+err_create_group:
+ sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
+err_clk:
+ platform_set_drvdata(pdev, NULL);
+ clk_put(data->clk);
+err_irq:
+ free_irq(data->irq, data);
+err_io_remap:
+ iounmap(data->base);
+err_mem_region:
+ release_mem_region(data->mem->start, resource_size(data->mem));
+err_free:
+ kfree(data);
+
+ return ret;
+}
+
+static int __devexit exynos4_tmu_remove(struct platform_device *pdev)
+{
+ struct exynos4_tmu_data *data = platform_get_drvdata(pdev);
+
+ exynos4_tmu_control(pdev, false);
+
+ hwmon_device_unregister(data->hwmon_dev);
+ sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
+
+ clk_put(data->clk);
+
+ free_irq(data->irq, data);
+
+ iounmap(data->base);
+ release_mem_region(data->mem->start, resource_size(data->mem));
+
+ platform_set_drvdata(pdev, NULL);
+
+ kfree(data);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int exynos4_tmu_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ exynos4_tmu_control(pdev, false);
+
+ return 0;
+}
+
+static int exynos4_tmu_resume(struct platform_device *pdev)
+{
+ exynos4_tmu_initialize(pdev);
+ exynos4_tmu_control(pdev, true);
+
+ return 0;
+}
+#else
+#define exynos4_tmu_suspend NULL
+#define exynos4_tmu_resume NULL
+#endif
+
+static struct platform_driver exynos4_tmu_driver = {
+ .driver = {
+ .name = "exynos4-tmu",
+ .owner = THIS_MODULE,
+ },
+ .probe = exynos4_tmu_probe,
+ .remove = __devexit_p(exynos4_tmu_remove),
+ .suspend = exynos4_tmu_suspend,
+ .resume = exynos4_tmu_resume,
+};
+
+static int __init exynos4_tmu_driver_init(void)
+{
+ return platform_driver_register(&exynos4_tmu_driver);
+}
+module_init(exynos4_tmu_driver_init);
+
+static void __exit exynos4_tmu_driver_exit(void)
+{
+ platform_driver_unregister(&exynos4_tmu_driver);
+}
+module_exit(exynos4_tmu_driver_exit);
+
+MODULE_DESCRIPTION("EXYNOS4 TMU Driver");
+MODULE_AUTHOR("Donggeun Kim <dg77.kim@samsung.com>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:exynos4-tmu");
diff --git a/include/linux/platform_data/exynos4_tmu.h b/include/linux/platform_data/exynos4_tmu.h
new file mode 100644
index 0000000..39e038c
--- /dev/null
+++ b/include/linux/platform_data/exynos4_tmu.h
@@ -0,0 +1,83 @@
+/*
+ * exynos4_tmu.h - Samsung EXYNOS4 TMU (Thermal Management Unit)
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ * Donggeun Kim <dg77.kim@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef _LINUX_EXYNOS4_TMU_H
+#define _LINUX_EXYNOS4_TMU_H
+
+enum calibration_type {
+ TYPE_ONE_POINT_TRIMMING,
+ TYPE_TWO_POINT_TRIMMING,
+ TYPE_NONE,
+};
+
+/**
+ * struct exynos4_tmu_platform_data
+ * @threshold: basic temperature for generating interrupt
+ * 25 <= threshold <= 125 [unit: degree Celsius]
+ * @trigger_levels: array for each interrupt levels
+ * [unit: degree Celsius]
+ * 0: temperature for trigger_level0 interrupt
+ * condition for trigger_level0 interrupt:
+ * current temperature > threshold + trigger_levels[0]
+ * 1: temperature for trigger_level1 interrupt
+ * condition for trigger_level1 interrupt:
+ * current temperature > threshold + trigger_levels[1]
+ * 2: temperature for trigger_level2 interrupt
+ * condition for trigger_level2 interrupt:
+ * current temperature > threshold + trigger_levels[2]
+ * 3: temperature for trigger_level3 interrupt
+ * condition for trigger_level3 interrupt:
+ * current temperature > threshold + trigger_levels[3]
+ * @trigger_level0_en:
+ * 1 = enable trigger_level0 interrupt,
+ * 0 = disable trigger_level0 interrupt
+ * @trigger_level1_en:
+ * 1 = enable trigger_level1 interrupt,
+ * 0 = disable trigger_level1 interrupt
+ * @trigger_level2_en:
+ * 1 = enable trigger_level2 interrupt,
+ * 0 = disable trigger_level2 interrupt
+ * @trigger_level3_en:
+ * 1 = enable trigger_level3 interrupt,
+ * 0 = disable trigger_level3 interrupt
+ * @gain: gain of amplifier in the positive-TC generator block
+ * 0 <= gain <= 15
+ * @reference_voltage: reference voltage of amplifier
+ * in the positive-TC generator block
+ * 0 <= reference_voltage <= 31
+ * @cal_type: calibration type for temperature
+ *
+ * This structure is required for configuration of exynos4_tmu driver.
+ */
+struct exynos4_tmu_platform_data {
+ u8 threshold;
+ u8 trigger_levels[4];
+ bool trigger_level0_en;
+ bool trigger_level1_en;
+ bool trigger_level2_en;
+ bool trigger_level3_en;
+
+ u8 gain;
+ u8 reference_voltage;
+
+ enum calibration_type cal_type;
+};
+#endif /* _LINUX_EXYNOS4_TMU_H */
--
1.7.4.1
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
2011-09-07 9:49 [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU Donggeun Kim
@ 2011-09-07 16:06 ` Guenter Roeck
2011-11-15 20:34 ` Paul Bolle
1 sibling, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2011-09-07 16:06 UTC (permalink / raw)
To: lm-sensors
On Wed, 2011-09-07 at 05:49 -0400, Donggeun Kim wrote:
> This patch allows to read temperature
> from TMU(Thermal Management Unit) of SAMSUNG EXYNOS4 series of SoC.
>
> Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> Changes for v7
> - removed sysfs_notify function call
> - changed kobject_uevent_env to kobject_uevent
> - cleaned up documentation
Thanks, applied.
FYI, I requested access to the chip datasheet - if I get it, I'll see if
there is a way to get interrupts for 1->0 transitions.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
2011-09-07 9:49 [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU Donggeun Kim
@ 2011-11-15 20:34 ` Paul Bolle
2011-11-15 20:34 ` Paul Bolle
1 sibling, 0 replies; 10+ messages in thread
From: Paul Bolle @ 2011-11-15 20:34 UTC (permalink / raw)
To: Donggeun Kim
Cc: lm-sensors, linux-doc, kyungmin.park, myungjoo.ham, Guenter Roeck,
linux-kernel
(This is an attempt to do a bit of review after the fact. See, this
appears to be to the patch that ended up as commit
9d97e5c81e15afaef65d00f077f863c94f750839 in the mainline tree. Since
that tree is at v3.2-rc2 now this might be in time for v3.2. If my
comments have merit, that is.)
On Wed, 2011-09-07 at 18:49 +0900, Donggeun Kim wrote:
> This patch allows to read temperature
> from TMU(Thermal Management Unit) of SAMSUNG EXYNOS4 series of SoC.
[...]
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 0b62c3c..c6fb761 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -303,6 +303,16 @@ config SENSORS_DS1621
> This driver can also be built as a module. If so, the module
> will be called ds1621.
>
> +config SENSORS_EXYNOS4_TMU
> + tristate "Temperature sensor on Samsung EXYNOS4"
> + depends on EXYNOS4_DEV_TMU
It doesn't look like that Kconfig symbol is part of the tree just yet.
That means people will not be able to build this driver from the
mainline tree. Why is this dependency needed? In a (rather quick) scan
of the code of this driver I couldn't spot anything not yet available in
the tree.
> + help
> + If you say yes here you get support for TMU (Thermal Managment
> + Unit) on SAMSUNG EXYNOS4 series of SoC.
> +
> + This driver can also be built as a module. If so, the module
> + will be called exynos4-tmu.
> +
> config SENSORS_I5K_AMB
> tristate "FB-DIMM AMB temperature sensor on Intel 5000 series chipsets"
> depends on PCI && EXPERIMENTAL
[...]
> diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
> new file mode 100644
> index 0000000..0170c90
> --- /dev/null
> +++ b/drivers/hwmon/exynos4_tmu.c
[...]
> +#ifdef CONFIG_PM
> +static int exynos4_tmu_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> + exynos4_tmu_control(pdev, false);
> +
> + return 0;
> +}
> +
> +static int exynos4_tmu_resume(struct platform_device *pdev)
> +{
> + exynos4_tmu_initialize(pdev);
> + exynos4_tmu_control(pdev, true);
> +
> + return 0;
> +}
> +#else
> +#define exynos4_tmu_suspend NULL
> +#define exynos4_tmu_resume NULL
> +#endif
> +
> +static struct platform_driver exynos4_tmu_driver = {
> + .driver = {
> + .name = "exynos4-tmu",
> + .owner = THIS_MODULE,
> + },
> + .probe = exynos4_tmu_probe,
> + .remove = __devexit_p(exynos4_tmu_remove),
> + .suspend = exynos4_tmu_suspend,
> + .resume = exynos4_tmu_resume,
> +};
A common idiom seems to be (I'm speaking from memory here) to
wrap .suspend and .resume inside an "#ifdef CONFIG_PM" / "#endif" pair.
That would allow to drop both "#define exynos4_tmu_suspend NULL" and
"#define exynos4_tmu_resume NULL" above. Would that work here too?
Paul Bolle
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
@ 2011-11-15 20:34 ` Paul Bolle
0 siblings, 0 replies; 10+ messages in thread
From: Paul Bolle @ 2011-11-15 20:34 UTC (permalink / raw)
To: Donggeun Kim
Cc: lm-sensors, linux-doc, kyungmin.park, myungjoo.ham, Guenter Roeck,
linux-kernel
(This is an attempt to do a bit of review after the fact. See, this
appears to be to the patch that ended up as commit
9d97e5c81e15afaef65d00f077f863c94f750839 in the mainline tree. Since
that tree is at v3.2-rc2 now this might be in time for v3.2. If my
comments have merit, that is.)
On Wed, 2011-09-07 at 18:49 +0900, Donggeun Kim wrote:
> This patch allows to read temperature
> from TMU(Thermal Management Unit) of SAMSUNG EXYNOS4 series of SoC.
[...]
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 0b62c3c..c6fb761 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -303,6 +303,16 @@ config SENSORS_DS1621
> This driver can also be built as a module. If so, the module
> will be called ds1621.
>
> +config SENSORS_EXYNOS4_TMU
> + tristate "Temperature sensor on Samsung EXYNOS4"
> + depends on EXYNOS4_DEV_TMU
It doesn't look like that Kconfig symbol is part of the tree just yet.
That means people will not be able to build this driver from the
mainline tree. Why is this dependency needed? In a (rather quick) scan
of the code of this driver I couldn't spot anything not yet available in
the tree.
> + help
> + If you say yes here you get support for TMU (Thermal Managment
> + Unit) on SAMSUNG EXYNOS4 series of SoC.
> +
> + This driver can also be built as a module. If so, the module
> + will be called exynos4-tmu.
> +
> config SENSORS_I5K_AMB
> tristate "FB-DIMM AMB temperature sensor on Intel 5000 series chipsets"
> depends on PCI && EXPERIMENTAL
[...]
> diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
> new file mode 100644
> index 0000000..0170c90
> --- /dev/null
> +++ b/drivers/hwmon/exynos4_tmu.c
[...]
> +#ifdef CONFIG_PM
> +static int exynos4_tmu_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> + exynos4_tmu_control(pdev, false);
> +
> + return 0;
> +}
> +
> +static int exynos4_tmu_resume(struct platform_device *pdev)
> +{
> + exynos4_tmu_initialize(pdev);
> + exynos4_tmu_control(pdev, true);
> +
> + return 0;
> +}
> +#else
> +#define exynos4_tmu_suspend NULL
> +#define exynos4_tmu_resume NULL
> +#endif
> +
> +static struct platform_driver exynos4_tmu_driver = {
> + .driver = {
> + .name = "exynos4-tmu",
> + .owner = THIS_MODULE,
> + },
> + .probe = exynos4_tmu_probe,
> + .remove = __devexit_p(exynos4_tmu_remove),
> + .suspend = exynos4_tmu_suspend,
> + .resume = exynos4_tmu_resume,
> +};
A common idiom seems to be (I'm speaking from memory here) to
wrap .suspend and .resume inside an "#ifdef CONFIG_PM" / "#endif" pair.
That would allow to drop both "#define exynos4_tmu_suspend NULL" and
"#define exynos4_tmu_resume NULL" above. Would that work here too?
Paul Bolle
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
2011-11-15 20:34 ` Paul Bolle
@ 2011-11-15 21:24 ` Guenter Roeck
-1 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2011-11-15 21:24 UTC (permalink / raw)
To: Paul Bolle
Cc: Donggeun Kim, lm-sensors@lm-sensors.org,
linux-doc@vger.kernel.org, kyungmin.park@samsung.com,
myungjoo.ham@samsung.com, linux-kernel@vger.kernel.org
On Tue, 2011-11-15 at 15:34 -0500, Paul Bolle wrote:
> (This is an attempt to do a bit of review after the fact. See, this
> appears to be to the patch that ended up as commit
> 9d97e5c81e15afaef65d00f077f863c94f750839 in the mainline tree. Since
> that tree is at v3.2-rc2 now this might be in time for v3.2. If my
> comments have merit, that is.)
>
> On Wed, 2011-09-07 at 18:49 +0900, Donggeun Kim wrote:
> > This patch allows to read temperature
> > from TMU(Thermal Management Unit) of SAMSUNG EXYNOS4 series of SoC.
> [...]
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 0b62c3c..c6fb761 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -303,6 +303,16 @@ config SENSORS_DS1621
> > This driver can also be built as a module. If so, the module
> > will be called ds1621.
> >
> > +config SENSORS_EXYNOS4_TMU
> > + tristate "Temperature sensor on Samsung EXYNOS4"
> > + depends on EXYNOS4_DEV_TMU
>
> It doesn't look like that Kconfig symbol is part of the tree just yet.
> That means people will not be able to build this driver from the
> mainline tree. Why is this dependency needed? In a (rather quick) scan
> of the code of this driver I couldn't spot anything not yet available in
> the tree.
>
I have to defer to the driver author for that. Maybe the dependency was
renamed at some point, or removed altogether.
> > + help
> > + If you say yes here you get support for TMU (Thermal Managment
> > + Unit) on SAMSUNG EXYNOS4 series of SoC.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called exynos4-tmu.
> > +
> > config SENSORS_I5K_AMB
> > tristate "FB-DIMM AMB temperature sensor on Intel 5000 series chipsets"
> > depends on PCI && EXPERIMENTAL
> [...]
> > diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
> > new file mode 100644
> > index 0000000..0170c90
> > --- /dev/null
> > +++ b/drivers/hwmon/exynos4_tmu.c
> [...]
> > +#ifdef CONFIG_PM
> > +static int exynos4_tmu_suspend(struct platform_device *pdev, pm_message_t state)
> > +{
> > + exynos4_tmu_control(pdev, false);
> > +
> > + return 0;
> > +}
> > +
> > +static int exynos4_tmu_resume(struct platform_device *pdev)
> > +{
> > + exynos4_tmu_initialize(pdev);
> > + exynos4_tmu_control(pdev, true);
> > +
> > + return 0;
> > +}
> > +#else
> > +#define exynos4_tmu_suspend NULL
> > +#define exynos4_tmu_resume NULL
> > +#endif
> > +
> > +static struct platform_driver exynos4_tmu_driver = {
> > + .driver = {
> > + .name = "exynos4-tmu",
> > + .owner = THIS_MODULE,
> > + },
> > + .probe = exynos4_tmu_probe,
> > + .remove = __devexit_p(exynos4_tmu_remove),
> > + .suspend = exynos4_tmu_suspend,
> > + .resume = exynos4_tmu_resume,
> > +};
>
> A common idiom seems to be (I'm speaking from memory here) to
> wrap .suspend and .resume inside an "#ifdef CONFIG_PM" / "#endif" pair.
> That would allow to drop both "#define exynos4_tmu_suspend NULL" and
> "#define exynos4_tmu_resume NULL" above. Would that work here too?
>
Seems to be a matter of opinion. I personally don't care one way or the
other, but I was told some time ago that the above method would be
preferred over using a second #ifdef.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
@ 2011-11-15 21:24 ` Guenter Roeck
0 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2011-11-15 21:24 UTC (permalink / raw)
To: Paul Bolle
Cc: Donggeun Kim, lm-sensors@lm-sensors.org,
linux-doc@vger.kernel.org, kyungmin.park@samsung.com,
myungjoo.ham@samsung.com, linux-kernel@vger.kernel.org
On Tue, 2011-11-15 at 15:34 -0500, Paul Bolle wrote:
> (This is an attempt to do a bit of review after the fact. See, this
> appears to be to the patch that ended up as commit
> 9d97e5c81e15afaef65d00f077f863c94f750839 in the mainline tree. Since
> that tree is at v3.2-rc2 now this might be in time for v3.2. If my
> comments have merit, that is.)
>
> On Wed, 2011-09-07 at 18:49 +0900, Donggeun Kim wrote:
> > This patch allows to read temperature
> > from TMU(Thermal Management Unit) of SAMSUNG EXYNOS4 series of SoC.
> [...]
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 0b62c3c..c6fb761 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -303,6 +303,16 @@ config SENSORS_DS1621
> > This driver can also be built as a module. If so, the module
> > will be called ds1621.
> >
> > +config SENSORS_EXYNOS4_TMU
> > + tristate "Temperature sensor on Samsung EXYNOS4"
> > + depends on EXYNOS4_DEV_TMU
>
> It doesn't look like that Kconfig symbol is part of the tree just yet.
> That means people will not be able to build this driver from the
> mainline tree. Why is this dependency needed? In a (rather quick) scan
> of the code of this driver I couldn't spot anything not yet available in
> the tree.
>
I have to defer to the driver author for that. Maybe the dependency was
renamed at some point, or removed altogether.
> > + help
> > + If you say yes here you get support for TMU (Thermal Managment
> > + Unit) on SAMSUNG EXYNOS4 series of SoC.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called exynos4-tmu.
> > +
> > config SENSORS_I5K_AMB
> > tristate "FB-DIMM AMB temperature sensor on Intel 5000 series chipsets"
> > depends on PCI && EXPERIMENTAL
> [...]
> > diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
> > new file mode 100644
> > index 0000000..0170c90
> > --- /dev/null
> > +++ b/drivers/hwmon/exynos4_tmu.c
> [...]
> > +#ifdef CONFIG_PM
> > +static int exynos4_tmu_suspend(struct platform_device *pdev, pm_message_t state)
> > +{
> > + exynos4_tmu_control(pdev, false);
> > +
> > + return 0;
> > +}
> > +
> > +static int exynos4_tmu_resume(struct platform_device *pdev)
> > +{
> > + exynos4_tmu_initialize(pdev);
> > + exynos4_tmu_control(pdev, true);
> > +
> > + return 0;
> > +}
> > +#else
> > +#define exynos4_tmu_suspend NULL
> > +#define exynos4_tmu_resume NULL
> > +#endif
> > +
> > +static struct platform_driver exynos4_tmu_driver = {
> > + .driver = {
> > + .name = "exynos4-tmu",
> > + .owner = THIS_MODULE,
> > + },
> > + .probe = exynos4_tmu_probe,
> > + .remove = __devexit_p(exynos4_tmu_remove),
> > + .suspend = exynos4_tmu_suspend,
> > + .resume = exynos4_tmu_resume,
> > +};
>
> A common idiom seems to be (I'm speaking from memory here) to
> wrap .suspend and .resume inside an "#ifdef CONFIG_PM" / "#endif" pair.
> That would allow to drop both "#define exynos4_tmu_suspend NULL" and
> "#define exynos4_tmu_resume NULL" above. Would that work here too?
>
Seems to be a matter of opinion. I personally don't care one way or the
other, but I was told some time ago that the above method would be
preferred over using a second #ifdef.
Guenter
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
2011-11-15 21:24 ` Guenter Roeck
@ 2011-11-17 5:20 ` Donggeun Kim
-1 siblings, 0 replies; 10+ messages in thread
From: Donggeun Kim @ 2011-11-17 5:20 UTC (permalink / raw)
To: guenter.roeck
Cc: Paul Bolle, lm-sensors@lm-sensors.org, linux-doc@vger.kernel.org,
kyungmin.park@samsung.com, myungjoo.ham@samsung.com,
linux-kernel@vger.kernel.org
T24gMjAxMeuFhCAxMeyblCAxNuydvCAwNjoyNCwgR3VlbnRlciBSb2VjayB3cm90ZToKPiBPbiBU
dWUsIDIwMTEtMTEtMTUgYXQgMTU6MzQgLTA1MDAsIFBhdWwgQm9sbGUgd3JvdGU6Cj4+IChUaGlz
IGlzIGFuIGF0dGVtcHQgdG8gZG8gYSBiaXQgb2YgcmV2aWV3IGFmdGVyIHRoZSBmYWN0LiBTZWUs
IHRoaXMKPj4gYXBwZWFycyB0byBiZSB0byB0aGUgcGF0Y2ggdGhhdCBlbmRlZCB1cCBhcyBjb21t
aXQKPj4gOWQ5N2U1YzgxZTE1YWZhZWY2NWQwMGYwNzdmODYzYzk0Zjc1MDgzOSBpbiB0aGUgbWFp
bmxpbmUgdHJlZS4gU2luY2UKPj4gdGhhdCB0cmVlIGlzIGF0IHYzLjItcmMyIG5vdyB0aGlzIG1p
Z2h0IGJlIGluIHRpbWUgZm9yIHYzLjIuIElmIG15Cj4+IGNvbW1lbnRzIGhhdmUgbWVyaXQsIHRo
YXQgaXMuKQo+Pgo+PiBPbiBXZWQsIDIwMTEtMDktMDcgYXQgMTg6NDkgKzA5MDAsIERvbmdnZXVu
IEtpbSB3cm90ZToKPj4+IFRoaXMgcGF0Y2ggYWxsb3dzIHRvIHJlYWQgdGVtcGVyYXR1cmUKPj4+
IGZyb20gVE1VKFRoZXJtYWwgTWFuYWdlbWVudCBVbml0KSBvZiBTQU1TVU5HIEVYWU5PUzQgc2Vy
aWVzIG9mIFNvQy4KPj4gWy4uLl0KPj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2h3bW9uL0tjb25m
aWcgYi9kcml2ZXJzL2h3bW9uL0tjb25maWcKPj4+IGluZGV4IDBiNjJjM2MuLmM2ZmI3NjEgMTAw
NjQ0Cj4+PiAtLS0gYS9kcml2ZXJzL2h3bW9uL0tjb25maWcKPj4+ICsrKyBiL2RyaXZlcnMvaHdt
b24vS2NvbmZpZwo+Pj4gQEAgLTMwMyw2ICszMDMsMTYgQEAgY29uZmlnIFNFTlNPUlNfRFMxNjIx
Cj4+PiAgCSAgVGhpcyBkcml2ZXIgY2FuIGFsc28gYmUgYnVpbHQgYXMgYSBtb2R1bGUuICBJZiBz
bywgdGhlIG1vZHVsZQo+Pj4gIAkgIHdpbGwgYmUgY2FsbGVkIGRzMTYyMS4KPj4+ICAKPj4+ICtj
b25maWcgU0VOU09SU19FWFlOT1M0X1RNVQo+Pj4gKwl0cmlzdGF0ZSAiVGVtcGVyYXR1cmUgc2Vu
c29yIG9uIFNhbXN1bmcgRVhZTk9TNCIKPj4+ICsJZGVwZW5kcyBvbiBFWFlOT1M0X0RFVl9UTVUK
Pj4KPj4gSXQgZG9lc24ndCBsb29rIGxpa2UgdGhhdCBLY29uZmlnIHN5bWJvbCBpcyBwYXJ0IG9m
IHRoZSB0cmVlIGp1c3QgeWV0Lgo+PiBUaGF0IG1lYW5zIHBlb3BsZSB3aWxsIG5vdCBiZSBhYmxl
IHRvIGJ1aWxkIHRoaXMgZHJpdmVyIGZyb20gdGhlCj4+IG1haW5saW5lIHRyZWUuIFdoeSBpcyB0
aGlzIGRlcGVuZGVuY3kgbmVlZGVkPyBJbiBhIChyYXRoZXIgcXVpY2spIHNjYW4KPj4gb2YgdGhl
IGNvZGUgb2YgdGhpcyBkcml2ZXIgSSBjb3VsZG4ndCBzcG90IGFueXRoaW5nIG5vdCB5ZXQgYXZh
aWxhYmxlIGluCj4+IHRoZSB0cmVlLgo+Pgo+IEkgaGF2ZSB0byBkZWZlciB0byB0aGUgZHJpdmVy
IGF1dGhvciBmb3IgdGhhdC4gTWF5YmUgdGhlIGRlcGVuZGVuY3kgd2FzCj4gcmVuYW1lZCBhdCBz
b21lIHBvaW50LCBvciByZW1vdmVkIGFsdG9nZXRoZXIuCj4gClRoZSBkZXBlbmRlbmN5IHdpbGwg
YmUgcmVuYW1lZCB0byAnQVJDSF9FWFlOT1M0Jy4KClRoYW5rcywKRG9uZ2dldW4KCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWls
aW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29y
cy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
@ 2011-11-17 5:20 ` Donggeun Kim
0 siblings, 0 replies; 10+ messages in thread
From: Donggeun Kim @ 2011-11-17 5:20 UTC (permalink / raw)
To: guenter.roeck
Cc: Paul Bolle, lm-sensors@lm-sensors.org, linux-doc@vger.kernel.org,
kyungmin.park@samsung.com, myungjoo.ham@samsung.com,
linux-kernel@vger.kernel.org
On 2011년 11월 16일 06:24, Guenter Roeck wrote:
> On Tue, 2011-11-15 at 15:34 -0500, Paul Bolle wrote:
>> (This is an attempt to do a bit of review after the fact. See, this
>> appears to be to the patch that ended up as commit
>> 9d97e5c81e15afaef65d00f077f863c94f750839 in the mainline tree. Since
>> that tree is at v3.2-rc2 now this might be in time for v3.2. If my
>> comments have merit, that is.)
>>
>> On Wed, 2011-09-07 at 18:49 +0900, Donggeun Kim wrote:
>>> This patch allows to read temperature
>>> from TMU(Thermal Management Unit) of SAMSUNG EXYNOS4 series of SoC.
>> [...]
>>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>>> index 0b62c3c..c6fb761 100644
>>> --- a/drivers/hwmon/Kconfig
>>> +++ b/drivers/hwmon/Kconfig
>>> @@ -303,6 +303,16 @@ config SENSORS_DS1621
>>> This driver can also be built as a module. If so, the module
>>> will be called ds1621.
>>>
>>> +config SENSORS_EXYNOS4_TMU
>>> + tristate "Temperature sensor on Samsung EXYNOS4"
>>> + depends on EXYNOS4_DEV_TMU
>>
>> It doesn't look like that Kconfig symbol is part of the tree just yet.
>> That means people will not be able to build this driver from the
>> mainline tree. Why is this dependency needed? In a (rather quick) scan
>> of the code of this driver I couldn't spot anything not yet available in
>> the tree.
>>
> I have to defer to the driver author for that. Maybe the dependency was
> renamed at some point, or removed altogether.
>
The dependency will be renamed to 'ARCH_EXYNOS4'.
Thanks,
Donggeun
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
2011-11-17 5:20 ` Donggeun Kim
@ 2011-11-17 9:50 ` Guenter Roeck
-1 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2011-11-17 9:50 UTC (permalink / raw)
To: Donggeun Kim
Cc: Paul Bolle, lm-sensors@lm-sensors.org, linux-doc@vger.kernel.org,
kyungmin.park@samsung.com, myungjoo.ham@samsung.com,
linux-kernel@vger.kernel.org
On Thu, Nov 17, 2011 at 12:20:31AM -0500, Donggeun Kim wrote:
[ ... ]
> >>>
> >>> +config SENSORS_EXYNOS4_TMU
> >>> + tristate "Temperature sensor on Samsung EXYNOS4"
> >>> + depends on EXYNOS4_DEV_TMU
> >>
> >> It doesn't look like that Kconfig symbol is part of the tree just yet.
> >> That means people will not be able to build this driver from the
> >> mainline tree. Why is this dependency needed? In a (rather quick) scan
> >> of the code of this driver I couldn't spot anything not yet available in
> >> the tree.
> >>
> > I have to defer to the driver author for that. Maybe the dependency was
> > renamed at some point, or removed altogether.
> >
> The dependency will be renamed to 'ARCH_EXYNOS4'.
>
Please submit a patch.
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] 10+ messages in thread
* Re: [PATCH v7] hwmon: Add driver for EXYNOS4 TMU
@ 2011-11-17 9:50 ` Guenter Roeck
0 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2011-11-17 9:50 UTC (permalink / raw)
To: Donggeun Kim
Cc: Paul Bolle, lm-sensors@lm-sensors.org, linux-doc@vger.kernel.org,
kyungmin.park@samsung.com, myungjoo.ham@samsung.com,
linux-kernel@vger.kernel.org
On Thu, Nov 17, 2011 at 12:20:31AM -0500, Donggeun Kim wrote:
[ ... ]
> >>>
> >>> +config SENSORS_EXYNOS4_TMU
> >>> + tristate "Temperature sensor on Samsung EXYNOS4"
> >>> + depends on EXYNOS4_DEV_TMU
> >>
> >> It doesn't look like that Kconfig symbol is part of the tree just yet.
> >> That means people will not be able to build this driver from the
> >> mainline tree. Why is this dependency needed? In a (rather quick) scan
> >> of the code of this driver I couldn't spot anything not yet available in
> >> the tree.
> >>
> > I have to defer to the driver author for that. Maybe the dependency was
> > renamed at some point, or removed altogether.
> >
> The dependency will be renamed to 'ARCH_EXYNOS4'.
>
Please submit a patch.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-11-17 9:52 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-07 9:49 [lm-sensors] [PATCH v7] hwmon: Add driver for EXYNOS4 TMU Donggeun Kim
2011-09-07 16:06 ` Guenter Roeck
2011-11-15 20:34 ` Paul Bolle
2011-11-15 20:34 ` Paul Bolle
2011-11-15 21:24 ` [lm-sensors] " Guenter Roeck
2011-11-15 21:24 ` Guenter Roeck
2011-11-17 5:20 ` [lm-sensors] " Donggeun Kim
2011-11-17 5:20 ` Donggeun Kim
2011-11-17 9:50 ` [lm-sensors] " Guenter Roeck
2011-11-17 9:50 ` Guenter Roeck
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.