[PATCHv2 0/9] Thermal Framework Enhancements

[PATCHv2 0/9] Thermal Framework Enhancements

[Durgadoss R]

This patch set is a v2 of the previous versions submitted here:
[v1]:  https://lkml.org/lkml/2012/12/18/108 
[RFC]: https://patchwork.kernel.org/patch/1758921/

This patch set is based on Rui's -thermal tree, and is
tested on a Core-i5 and an Atom netbook.

Changes Since v1:
 * Removed kobject creation for thermal_trip and thermal_map
   nodes as per Greg-KH's comments.
 * Added ABI Documentation under 'testing'.
 * Modified the GET_INDEX macro to be more linux-like, thanks
   to Joe Perches.
 * Added get_[sensor/cdev]_by_name APIs to thermal.h

This series contains 9 patches:
Patch 1/9: Creates new sensor level APIs
Patch 2/9: Creates new zone level APIs. The existing tzd structure is
           kept as such for clarity and compatibility purposes.
Patch 3/9: Creates functions to add/remove a cdev to/from a zone. The
           existing tcd structure need not be modified.
Patch 4/9: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
	   under /sys/class/thermal/zoneY/. This exposes various trip
           points for sensorX present in zoneY.
Patch 5/9: Adds mapX sysfs node. It is a compact representation
           of the binding relationship between a sensor and a cdev,
           within a zone.
Patch 6/9: Creates Documentation for the new APIs. A new file is
           created for clarity. Final goal is to merge with the existing
           file or refactor the files, as whatever seems appropriate.
Patch 7/9: Make PER ZONE values configurable through Kconfig
Patch 8/9: Add ABI documentation for sysfs interfaces introduced in this patch.
Patch 9/9: A dummy driver that can be used for testing. This is not for merge.

Thanks to Greg-KH, Hongbo Zhang and Joe Perches for their comments on v1.

Durgadoss R (9):
  Thermal: Create sensor level APIs
  Thermal: Create zone level APIs
  Thermal: Add APIs to bind cdev to new zone structure
  Thermal: Add trip point sysfs nodes for sensor
  Thermal: Create 'mapX' sysfs node for a zone
  Thermal: Add Documentation to new APIs
  Thermal: Make PER_ZONE values configurable
  Thermal: Add ABI Documentation for sysfs interfaces
  Thermal: Dummy driver used for testing

 Documentation/ABI/testing/sysfs-class-thermal |   93 +++
 Documentation/thermal/sysfs-api2.txt          |  248 +++++++
 drivers/thermal/Kconfig                       |   19 +
 drivers/thermal/Makefile                      |    3 +
 drivers/thermal/thermal_sys.c                 |  881 +++++++++++++++++++++++++
 drivers/thermal/thermal_test.c                |  315 +++++++++
 include/linux/thermal.h                       |  117 +++-
 7 files changed, 1675 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
 create mode 100644 Documentation/thermal/sysfs-api2.txt
 create mode 100644 drivers/thermal/thermal_test.c

-- 
1.7.9.5

[PATCH 1/9] Thermal: Create sensor level APIs

[Durgadoss R]

This patch creates sensor level APIs, in the
generic thermal framework.

A Thermal sensor is a piece of hardware that can report
temperature of the spot in which it is placed. A thermal
sensor driver reads the temperature from this sensor
and reports it out. This kind of driver can be in
any subsystem. If the sensor needs to participate
in platform thermal management, the corresponding
driver can use the APIs introduced in this patch, to
register(or unregister) with the thermal framework.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/thermal/thermal_sys.c |  280 +++++++++++++++++++++++++++++++++++++++++
 include/linux/thermal.h       |   29 +++++
 2 files changed, 309 insertions(+)

diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 8f0f37b..b2becb9 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -45,13 +45,16 @@ MODULE_LICENSE("GPL");
 
 static DEFINE_IDR(thermal_tz_idr);
 static DEFINE_IDR(thermal_cdev_idr);
+static DEFINE_IDR(thermal_sensor_idr);
 static DEFINE_MUTEX(thermal_idr_lock);
 
 static LIST_HEAD(thermal_tz_list);
+static LIST_HEAD(thermal_sensor_list);
 static LIST_HEAD(thermal_cdev_list);
 static LIST_HEAD(thermal_governor_list);
 
 static DEFINE_MUTEX(thermal_list_lock);
+static DEFINE_MUTEX(sensor_list_lock);
 static DEFINE_MUTEX(thermal_governor_lock);
 
 static struct thermal_governor *__find_governor(const char *name)
@@ -421,6 +424,103 @@ static void thermal_zone_device_check(struct work_struct *work)
 #define to_thermal_zone(_dev) \
 	container_of(_dev, struct thermal_zone_device, device)
 
+#define to_thermal_sensor(_dev) \
+	container_of(_dev, struct thermal_sensor, device)
+
+static ssize_t
+sensor_name_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct thermal_sensor *ts = to_thermal_sensor(dev);
+
+	return sprintf(buf, "%s\n", ts->name);
+}
+
+static ssize_t
+sensor_temp_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	int ret;
+	long val;
+	struct thermal_sensor *ts = to_thermal_sensor(dev);
+
+	ret = ts->ops->get_temp(ts, &val);
+
+	return ret ? ret : sprintf(buf, "%ld\n", val);
+}
+
+static ssize_t
+hyst_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	int indx, ret;
+	long val;
+	struct thermal_sensor *ts = to_thermal_sensor(dev);
+
+	if (!sscanf(attr->attr.name, "threshold%d_hyst", &indx))
+		return -EINVAL;
+
+	ret = ts->ops->get_hyst(ts, indx, &val);
+
+	return ret ? ret : sprintf(buf, "%ld\n", val);
+}
+
+static ssize_t
+hyst_store(struct device *dev, struct device_attribute *attr,
+				   const char *buf, size_t count)
+{
+	int indx, ret;
+	long val;
+	struct thermal_sensor *ts = to_thermal_sensor(dev);
+
+	if (!ts->ops->set_hyst)
+		return -EPERM;
+
+	if (!sscanf(attr->attr.name, "threshold%d_hyst", &indx))
+		return -EINVAL;
+
+	if (kstrtol(buf, 10, &val))
+		return -EINVAL;
+
+	ret = ts->ops->set_hyst(ts, indx, val);
+
+	return ret ? ret : count;
+}
+
+static ssize_t
+threshold_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	int indx, ret;
+	long val;
+	struct thermal_sensor *ts = to_thermal_sensor(dev);
+
+	if (!sscanf(attr->attr.name, "threshold%d", &indx))
+		return -EINVAL;
+
+	ret = ts->ops->get_threshold(ts, indx, &val);
+
+	return ret ? ret : sprintf(buf, "%ld\n", val);
+}
+
+static ssize_t
+threshold_store(struct device *dev, struct device_attribute *attr,
+				   const char *buf, size_t count)
+{
+	int indx, ret;
+	long val;
+	struct thermal_sensor *ts = to_thermal_sensor(dev);
+
+	if (!ts->ops->set_threshold)
+		return -EPERM;
+
+	if (!sscanf(attr->attr.name, "threshold%d", &indx))
+		return -EINVAL;
+
+	if (kstrtol(buf, 10, &val))
+		return -EINVAL;
+
+	ret = ts->ops->set_threshold(ts, indx, val);
+
+	return ret ? ret : count;
+}
+
 static ssize_t
 type_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
@@ -705,6 +805,10 @@ static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
 static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
 static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
 
+/* Thermal sensor attributes */
+static DEVICE_ATTR(sensor_name, 0444, sensor_name_show, NULL);
+static DEVICE_ATTR(temp_input, 0444, sensor_temp_show, NULL);
+
 /* sys I/F for cooling device */
 #define to_cooling_device(_dev)	\
 	container_of(_dev, struct thermal_cooling_device, device)
@@ -1491,6 +1595,182 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
 }
 
 /**
+ * enable_sensor_thresholds - create sysfs nodes for thresholdX
+ * @ts:		the thermal sensor
+ * @count:	Number of thresholds supported by sensor hardware
+ *
+ * 'Thresholds' are temperatures programmed into the sensor hardware,
+ * on crossing which the sensor generates an interrupt. 'Trip points'
+ * are temperatures which the thermal manager/governor thinks, some
+ * action should be taken when the sensor reaches the value.
+ */
+static int enable_sensor_thresholds(struct thermal_sensor *ts, int count)
+{
+	int i;
+	int size = sizeof(struct thermal_attr) * count;
+
+	ts->thresh_attrs = kzalloc(size, GFP_KERNEL);
+	if (!ts->thresh_attrs)
+		return -ENOMEM;
+
+	if (ts->ops->get_hyst) {
+		ts->hyst_attrs = kzalloc(size, GFP_KERNEL);
+		if (!ts->hyst_attrs) {
+			kfree(ts->thresh_attrs);
+			return -ENOMEM;
+		}
+	}
+
+	ts->thresholds = count;
+
+	/* Create threshold attributes */
+	for (i = 0; i < count; i++) {
+		snprintf(ts->thresh_attrs[i].name, THERMAL_NAME_LENGTH,
+						 "threshold%d", i);
+
+		sysfs_attr_init(&ts->thresh_attrs[i].attr.attr);
+		ts->thresh_attrs[i].attr.attr.name = ts->thresh_attrs[i].name;
+		ts->thresh_attrs[i].attr.attr.mode = S_IRUGO | S_IWUSR;
+		ts->thresh_attrs[i].attr.show = threshold_show;
+		ts->thresh_attrs[i].attr.store = threshold_store;
+
+		device_create_file(&ts->device, &ts->thresh_attrs[i].attr);
+
+		/* Create threshold_hyst attributes */
+		if (!ts->ops->get_hyst)
+			continue;
+
+		snprintf(ts->hyst_attrs[i].name, THERMAL_NAME_LENGTH,
+						 "threshold%d_hyst", i);
+
+		sysfs_attr_init(&ts->hyst_attrs[i].attr.attr);
+		ts->hyst_attrs[i].attr.attr.name = ts->hyst_attrs[i].name;
+		ts->hyst_attrs[i].attr.attr.mode = S_IRUGO | S_IWUSR;
+		ts->hyst_attrs[i].attr.show = hyst_show;
+		ts->hyst_attrs[i].attr.store = hyst_store;
+
+		device_create_file(&ts->device, &ts->hyst_attrs[i].attr);
+	}
+	return 0;
+}
+
+/**
+ * thermal_sensor_register - register a new thermal sensor
+ * @name:	name of the thermal sensor
+ * @count:	Number of thresholds supported by hardware
+ * @ops:	standard thermal sensor callbacks
+ * @devdata:	private device data
+ */
+struct thermal_sensor *thermal_sensor_register(const char *name, int count,
+			struct thermal_sensor_ops *ops, void *devdata)
+{
+	struct thermal_sensor *ts;
+	int ret;
+
+	if (!name || (name && strlen(name) >= THERMAL_NAME_LENGTH))
+		return ERR_PTR(-EINVAL);
+
+	if (!ops || !ops->get_temp)
+		return ERR_PTR(-EINVAL);
+
+	ts = kzalloc(sizeof(*ts), GFP_KERNEL);
+	if (!ts)
+		return ERR_PTR(-ENOMEM);
+
+	idr_init(&ts->idr);
+	ret = get_idr(&thermal_sensor_idr, &thermal_idr_lock, &ts->id);
+	if (ret)
+		goto exit_free;
+
+	strcpy(ts->name, name);
+	ts->ops = ops;
+	ts->devdata = devdata;
+	ts->device.class = &thermal_class;
+
+	dev_set_name(&ts->device, "sensor%d", ts->id);
+	ret = device_register(&ts->device);
+	if (ret)
+		goto exit_idr;
+
+	ret = device_create_file(&ts->device, &dev_attr_sensor_name);
+	if (ret)
+		goto exit_unregister;
+
+	ret = device_create_file(&ts->device, &dev_attr_temp_input);
+	if (ret)
+		goto exit_name;
+
+	if (count > 0 && ts->ops->get_threshold) {
+		ret = enable_sensor_thresholds(ts, count);
+		if (ret)
+			goto exit_temp;
+	}
+
+	/* Add this sensor to the global list of sensors */
+	mutex_lock(&sensor_list_lock);
+	list_add_tail(&ts->node, &thermal_sensor_list);
+	mutex_unlock(&sensor_list_lock);
+
+	return ts;
+
+exit_temp:
+	device_remove_file(&ts->device, &dev_attr_temp_input);
+exit_name:
+	device_remove_file(&ts->device, &dev_attr_sensor_name);
+exit_unregister:
+	device_unregister(&ts->device);
+exit_idr:
+	release_idr(&thermal_sensor_idr, &thermal_idr_lock, ts->id);
+exit_free:
+	kfree(ts);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(thermal_sensor_register);
+
+void thermal_sensor_unregister(struct thermal_sensor *ts)
+{
+	int i;
+	struct thermal_sensor *pos, *next;
+	bool found = false;
+
+	if (!ts)
+		return;
+
+	mutex_lock(&sensor_list_lock);
+	list_for_each_entry_safe(pos, next, &thermal_sensor_list, node) {
+		if (pos == ts) {
+			list_del(&ts->node);
+			found = true;
+			break;
+		}
+	}
+	mutex_unlock(&sensor_list_lock);
+
+	if (!found)
+		return;
+
+	for (i = 0; i < ts->thresholds; i++) {
+		device_remove_file(&ts->device, &ts->thresh_attrs[i].attr);
+		if (ts->ops->get_hyst) {
+			device_remove_file(&ts->device,
+					&ts->hyst_attrs[i].attr);
+		}
+	}
+
+	device_remove_file(&ts->device, &dev_attr_sensor_name);
+	device_remove_file(&ts->device, &dev_attr_temp_input);
+
+	release_idr(&thermal_sensor_idr, &thermal_idr_lock, ts->id);
+	idr_destroy(&ts->idr);
+
+	device_unregister(&ts->device);
+
+	kfree(ts);
+	return;
+}
+EXPORT_SYMBOL(thermal_sensor_unregister);
+
+/**
  * thermal_zone_device_register - register a new thermal zone device
  * @type:	the thermal zone device type
  * @trips:	the number of trip points the thermal zone support
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..a49cb38 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -49,6 +49,7 @@
 /* Default Thermal Governor: Does Linear Throttling */
 #define DEFAULT_THERMAL_GOVERNOR	"step_wise"
 
+struct thermal_sensor;
 struct thermal_zone_device;
 struct thermal_cooling_device;
 
@@ -127,6 +128,15 @@ struct thermal_cooling_device_ops {
 	int (*set_cur_state) (struct thermal_cooling_device *, unsigned long);
 };
 
+struct thermal_sensor_ops {
+	int (*get_temp) (struct thermal_sensor *, long *);
+	int (*get_trend) (struct thermal_sensor *, int, enum thermal_trend *);
+	int (*set_threshold) (struct thermal_sensor *, int, long);
+	int (*get_threshold) (struct thermal_sensor *, int, long *);
+	int (*set_hyst) (struct thermal_sensor *, int, long);
+	int (*get_hyst) (struct thermal_sensor *, int, long *);
+};
+
 struct thermal_cooling_device {
 	int id;
 	char type[THERMAL_NAME_LENGTH];
@@ -144,6 +154,21 @@ struct thermal_attr {
 	char name[THERMAL_NAME_LENGTH];
 };
 
+struct thermal_sensor {
+	char name[THERMAL_NAME_LENGTH];
+	int id;
+	int temp;
+	int prev_temp;
+	int thresholds;
+	void *devdata;
+	struct idr idr;
+	struct device device;
+	struct list_head node;
+	struct thermal_sensor_ops *ops;
+	struct thermal_attr *thresh_attrs;
+	struct thermal_attr *hyst_attrs;
+};
+
 struct thermal_zone_device {
 	int id;
 	char type[THERMAL_NAME_LENGTH];
@@ -237,6 +262,10 @@ void notify_thermal_framework(struct thermal_zone_device *, int);
 int thermal_register_governor(struct thermal_governor *);
 void thermal_unregister_governor(struct thermal_governor *);
 
+struct thermal_sensor *thermal_sensor_register(const char *, int,
+				struct thermal_sensor_ops *, void *);
+void thermal_sensor_unregister(struct thermal_sensor *);
+
 #ifdef CONFIG_NET
 extern int thermal_generate_netlink_event(u32 orig, enum events event);
 #else
-- 
1.7.9.5

[PATCH 2/9] Thermal: Create zone level APIs

[Durgadoss R]

This patch adds a new thermal_zone structure to
thermal.h. Also, adds zone level APIs to the thermal
framework.

A thermal zone is a hot spot on the platform, which
can have one or more sensors and cooling devices attached
to it. These sensors can be mapped to a set of cooling
devices, which when throttled, can help to bring down
the temperature of the hot spot.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/thermal/thermal_sys.c |  196 +++++++++++++++++++++++++++++++++++++++++
 include/linux/thermal.h       |   22 +++++
 2 files changed, 218 insertions(+)

diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index b2becb9..513b0fc 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -44,19 +44,46 @@ MODULE_DESCRIPTION("Generic thermal management sysfs support");
 MODULE_LICENSE("GPL");
 
 static DEFINE_IDR(thermal_tz_idr);
+static DEFINE_IDR(thermal_zone_idr);
 static DEFINE_IDR(thermal_cdev_idr);
 static DEFINE_IDR(thermal_sensor_idr);
 static DEFINE_MUTEX(thermal_idr_lock);
 
 static LIST_HEAD(thermal_tz_list);
 static LIST_HEAD(thermal_sensor_list);
+static LIST_HEAD(thermal_zone_list);
 static LIST_HEAD(thermal_cdev_list);
 static LIST_HEAD(thermal_governor_list);
 
 static DEFINE_MUTEX(thermal_list_lock);
 static DEFINE_MUTEX(sensor_list_lock);
+static DEFINE_MUTEX(zone_list_lock);
 static DEFINE_MUTEX(thermal_governor_lock);
 
+#define for_each_thermal_sensor(pos) \
+	list_for_each_entry(pos, &thermal_sensor_list, node)
+
+#define for_each_thermal_zone(pos) \
+	list_for_each_entry(pos, &thermal_zone_list, node)
+
+#define GET_INDEX(tz, ptr, type)			\
+({							\
+	int i, ret = -EINVAL;				\
+	do {						\
+		if (!tz || !ptr)			\
+			break;				\
+		mutex_lock(&type##_list_lock);		\
+		for (i = 0; i < tz->type##_indx; i++) {	\
+			if (tz->type##s[i] == ptr) {	\
+				ret = i;		\
+				break;			\
+			}				\
+		}					\
+		mutex_unlock(&type##_list_lock);	\
+	} while (0);					\
+	ret;						\
+})
+
 static struct thermal_governor *__find_governor(const char *name)
 {
 	struct thermal_governor *pos;
@@ -419,15 +446,44 @@ static void thermal_zone_device_check(struct work_struct *work)
 	thermal_zone_device_update(tz);
 }
 
+static void remove_sensor_from_zone(struct thermal_zone *tz,
+				struct thermal_sensor *ts)
+{
+	int j, indx;
+
+	indx = GET_INDEX(tz, ts, sensor);
+	if (indx < 0)
+		return;
+
+	sysfs_remove_link(&tz->device.kobj, kobject_name(&ts->device.kobj));
+
+	/* Shift the entries in the tz->sensors array */
+	for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
+		tz->sensors[j] = tz->sensors[j + 1];
+
+	tz->sensor_indx--;
+}
+
 /* sys I/F for thermal zone */
 
 #define to_thermal_zone(_dev) \
 	container_of(_dev, struct thermal_zone_device, device)
 
+#define to_zone(_dev) \
+	container_of(_dev, struct thermal_zone, device)
+
 #define to_thermal_sensor(_dev) \
 	container_of(_dev, struct thermal_sensor, device)
 
 static ssize_t
+zone_name_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct thermal_zone *tz = to_zone(dev);
+
+	return sprintf(buf, "%s\n", tz->name);
+}
+
+static ssize_t
 sensor_name_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
 	struct thermal_sensor *ts = to_thermal_sensor(dev);
@@ -809,6 +865,8 @@ static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
 static DEVICE_ATTR(sensor_name, 0444, sensor_name_show, NULL);
 static DEVICE_ATTR(temp_input, 0444, sensor_temp_show, NULL);
 
+static DEVICE_ATTR(zone_name, 0444, zone_name_show, NULL);
+
 /* sys I/F for cooling device */
 #define to_cooling_device(_dev)	\
 	container_of(_dev, struct thermal_cooling_device, device)
@@ -1654,6 +1712,136 @@ static int enable_sensor_thresholds(struct thermal_sensor *ts, int count)
 	return 0;
 }
 
+struct thermal_zone *create_thermal_zone(const char *name, void *devdata)
+{
+	struct thermal_zone *tz;
+	int ret;
+
+	if (!name || (name && strlen(name) >= THERMAL_NAME_LENGTH))
+		return ERR_PTR(-EINVAL);
+
+	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
+	if (!tz)
+		return ERR_PTR(-ENOMEM);
+
+	idr_init(&tz->idr);
+	ret = get_idr(&thermal_zone_idr, &thermal_idr_lock, &tz->id);
+	if (ret)
+		goto exit_free;
+
+	strcpy(tz->name, name);
+	tz->devdata = devdata;
+	tz->device.class = &thermal_class;
+
+	dev_set_name(&tz->device, "zone%d", tz->id);
+	ret = device_register(&tz->device);
+	if (ret)
+		goto exit_idr;
+
+	ret = device_create_file(&tz->device, &dev_attr_zone_name);
+	if (ret)
+		goto exit_unregister;
+
+	/* Add this zone to the global list of thermal zones */
+	mutex_lock(&zone_list_lock);
+	list_add_tail(&tz->node, &thermal_zone_list);
+	mutex_unlock(&zone_list_lock);
+	return tz;
+
+exit_unregister:
+	device_unregister(&tz->device);
+exit_idr:
+	release_idr(&thermal_zone_idr, &thermal_idr_lock, tz->id);
+exit_free:
+	kfree(tz);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(create_thermal_zone);
+
+void remove_thermal_zone(struct thermal_zone *tz)
+{
+	struct thermal_zone *pos, *next;
+	bool found = false;
+
+	if (!tz)
+		return;
+
+	mutex_lock(&zone_list_lock);
+
+	list_for_each_entry_safe(pos, next, &thermal_zone_list, node) {
+		if (pos == tz) {
+			list_del(&tz->node);
+			found = true;
+			break;
+		}
+	}
+
+	if (!found)
+		goto exit;
+
+	device_remove_file(&tz->device, &dev_attr_zone_name);
+
+	release_idr(&thermal_zone_idr, &thermal_idr_lock, tz->id);
+	idr_destroy(&tz->idr);
+
+	device_unregister(&tz->device);
+	kfree(tz);
+exit:
+	mutex_unlock(&zone_list_lock);
+	return;
+}
+EXPORT_SYMBOL(remove_thermal_zone);
+
+struct thermal_sensor *get_sensor_by_name(const char *name)
+{
+	struct thermal_sensor *pos;
+	struct thermal_sensor *ts = NULL;
+
+	mutex_lock(&sensor_list_lock);
+	for_each_thermal_sensor(pos) {
+		if (!strnicmp(pos->name, name, THERMAL_NAME_LENGTH)) {
+			ts = pos;
+			break;
+		}
+	}
+	mutex_unlock(&sensor_list_lock);
+	return ts;
+}
+EXPORT_SYMBOL(get_sensor_by_name);
+
+int add_sensor_to_zone(struct thermal_zone *tz, struct thermal_sensor *ts)
+{
+	int ret;
+
+	if (!tz || !ts)
+		return -EINVAL;
+
+	mutex_lock(&zone_list_lock);
+
+	/* Ensure we are not adding the same sensor again!! */
+	ret = GET_INDEX(tz, ts, sensor);
+	if (ret >= 0) {
+		ret = -EEXIST;
+		goto exit_zone;
+	}
+
+	mutex_lock(&sensor_list_lock);
+
+	ret = sysfs_create_link(&tz->device.kobj, &ts->device.kobj,
+				kobject_name(&ts->device.kobj));
+	if (ret)
+		goto exit_sensor;
+
+	tz->sensors[tz->sensor_indx++] = ts;
+
+exit_sensor:
+	mutex_unlock(&sensor_list_lock);
+exit_zone:
+	mutex_unlock(&zone_list_lock);
+	return ret;
+}
+EXPORT_SYMBOL(add_sensor_to_zone);
+
 /**
  * thermal_sensor_register - register a new thermal sensor
  * @name:	name of the thermal sensor
@@ -1730,6 +1918,7 @@ EXPORT_SYMBOL(thermal_sensor_register);
 void thermal_sensor_unregister(struct thermal_sensor *ts)
 {
 	int i;
+	struct thermal_zone *tz;
 	struct thermal_sensor *pos, *next;
 	bool found = false;
 
@@ -1749,6 +1938,13 @@ void thermal_sensor_unregister(struct thermal_sensor *ts)
 	if (!found)
 		return;
 
+	mutex_lock(&zone_list_lock);
+
+	for_each_thermal_zone(tz)
+		remove_sensor_from_zone(tz, ts);
+
+	mutex_unlock(&zone_list_lock);
+
 	for (i = 0; i < ts->thresholds; i++) {
 		device_remove_file(&ts->device, &ts->thresh_attrs[i].attr);
 		if (ts->ops->get_hyst) {
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index a49cb38..f5b9540 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -49,6 +49,8 @@
 /* Default Thermal Governor: Does Linear Throttling */
 #define DEFAULT_THERMAL_GOVERNOR	"step_wise"
 
+#define MAX_SENSORS_PER_ZONE		5
+
 struct thermal_sensor;
 struct thermal_zone_device;
 struct thermal_cooling_device;
@@ -194,6 +196,21 @@ struct thermal_zone_device {
 	struct delayed_work poll_queue;
 };
 
+struct thermal_zone {
+	char name[THERMAL_NAME_LENGTH];
+	int id;
+	void *devdata;
+	struct thermal_zone *ops;
+	struct thermal_governor *governor;
+	struct idr idr;
+	struct device device;
+	struct list_head node;
+
+	/* Sensor level information */
+	int sensor_indx; /* index into 'sensors' array */
+	struct thermal_sensor *sensors[MAX_SENSORS_PER_ZONE];
+};
+
 /* Structure that holds thermal governor information */
 struct thermal_governor {
 	char name[THERMAL_NAME_LENGTH];
@@ -266,6 +283,11 @@ struct thermal_sensor *thermal_sensor_register(const char *, int,
 				struct thermal_sensor_ops *, void *);
 void thermal_sensor_unregister(struct thermal_sensor *);
 
+struct thermal_zone *create_thermal_zone(const char *, void *);
+void remove_thermal_zone(struct thermal_zone *);
+int add_sensor_to_zone(struct thermal_zone *, struct thermal_sensor *);
+struct thermal_sensor *get_sensor_by_name(const char *);
+
 #ifdef CONFIG_NET
 extern int thermal_generate_netlink_event(u32 orig, enum events event);
 #else
-- 
1.7.9.5

[PATCH 3/9] Thermal: Add APIs to bind cdev to new zone structure

[Durgadoss R]

This patch creates new APIs to add/remove a
cdev to/from a zone. This patch does not change
the old cooling device implementation.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/thermal/thermal_sys.c |   80 +++++++++++++++++++++++++++++++++++++++++
 include/linux/thermal.h       |    9 +++++
 2 files changed, 89 insertions(+)

diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 513b0fc..332bd61 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -58,6 +58,7 @@ static LIST_HEAD(thermal_governor_list);
 static DEFINE_MUTEX(thermal_list_lock);
 static DEFINE_MUTEX(sensor_list_lock);
 static DEFINE_MUTEX(zone_list_lock);
+static DEFINE_MUTEX(cdev_list_lock);
 static DEFINE_MUTEX(thermal_governor_lock);
 
 #define for_each_thermal_sensor(pos) \
@@ -84,6 +85,9 @@ static DEFINE_MUTEX(thermal_governor_lock);
 	ret;						\
 })
 
+#define for_each_cdev(pos) \
+	list_for_each_entry(pos, &thermal_cdev_list, node)
+
 static struct thermal_governor *__find_governor(const char *name)
 {
 	struct thermal_governor *pos;
@@ -464,6 +468,24 @@ static void remove_sensor_from_zone(struct thermal_zone *tz,
 	tz->sensor_indx--;
 }
 
+static void remove_cdev_from_zone(struct thermal_zone *tz,
+				struct thermal_cooling_device *cdev)
+{
+	int j, indx;
+
+	indx = GET_INDEX(tz, cdev, cdev);
+	if (indx < 0)
+		return;
+
+	sysfs_remove_link(&tz->device.kobj, kobject_name(&cdev->device.kobj));
+
+	/* Shift the entries in the tz->cdevs array */
+	for (j = indx; j < MAX_CDEVS_PER_ZONE - 1; j++)
+		tz->cdevs[j] = tz->cdevs[j + 1];
+
+	tz->cdev_indx--;
+}
+
 /* sys I/F for thermal zone */
 
 #define to_thermal_zone(_dev) \
@@ -1460,6 +1482,7 @@ void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
 	int i;
 	const struct thermal_zone_params *tzp;
 	struct thermal_zone_device *tz;
+	struct thermal_zone *tmp_tz;
 	struct thermal_cooling_device *pos = NULL;
 
 	if (!cdev)
@@ -1497,6 +1520,13 @@ void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
 
 	mutex_unlock(&thermal_list_lock);
 
+	mutex_lock(&zone_list_lock);
+
+	for_each_thermal_zone(tmp_tz)
+		remove_cdev_from_zone(tmp_tz, cdev);
+
+	mutex_unlock(&zone_list_lock);
+
 	if (cdev->type[0])
 		device_remove_file(&cdev->device, &dev_attr_cdev_type);
 	device_remove_file(&cdev->device, &dev_attr_max_state);
@@ -1792,6 +1822,23 @@ exit:
 }
 EXPORT_SYMBOL(remove_thermal_zone);
 
+struct thermal_cooling_device *get_cdev_by_name(const char *name)
+{
+	struct thermal_cooling_device *pos;
+	struct thermal_cooling_device *cdev = NULL;
+
+	mutex_lock(&cdev_list_lock);
+	for_each_cdev(pos) {
+		if (!strnicmp(pos->type, name, THERMAL_NAME_LENGTH)) {
+			cdev = pos;
+			break;
+		}
+	}
+	mutex_unlock(&cdev_list_lock);
+	return cdev;
+}
+EXPORT_SYMBOL(get_cdev_by_name);
+
 struct thermal_sensor *get_sensor_by_name(const char *name)
 {
 	struct thermal_sensor *pos;
@@ -1842,6 +1889,39 @@ exit_zone:
 }
 EXPORT_SYMBOL(add_sensor_to_zone);
 
+int add_cdev_to_zone(struct thermal_zone *tz,
+			struct thermal_cooling_device *cdev)
+{
+	int ret;
+
+	if (!tz || !cdev)
+		return -EINVAL;
+
+	mutex_lock(&zone_list_lock);
+
+	/* Ensure we are not adding the same cdev again!! */
+	ret = GET_INDEX(tz, cdev, cdev);
+	if (ret >= 0) {
+		ret = -EEXIST;
+		goto exit_zone;
+	}
+
+	mutex_lock(&cdev_list_lock);
+	ret = sysfs_create_link(&tz->device.kobj, &cdev->device.kobj,
+				kobject_name(&cdev->device.kobj));
+	if (ret)
+		goto exit_cdev;
+
+	tz->cdevs[tz->cdev_indx++] = cdev;
+
+exit_cdev:
+	mutex_unlock(&cdev_list_lock);
+exit_zone:
+	mutex_unlock(&zone_list_lock);
+	return ret;
+}
+EXPORT_SYMBOL(add_cdev_to_zone);
+
 /**
  * thermal_sensor_register - register a new thermal sensor
  * @name:	name of the thermal sensor
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index f5b9540..12cc953 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -51,6 +51,8 @@
 
 #define MAX_SENSORS_PER_ZONE		5
 
+#define MAX_CDEVS_PER_ZONE		5
+
 struct thermal_sensor;
 struct thermal_zone_device;
 struct thermal_cooling_device;
@@ -209,6 +211,10 @@ struct thermal_zone {
 	/* Sensor level information */
 	int sensor_indx; /* index into 'sensors' array */
 	struct thermal_sensor *sensors[MAX_SENSORS_PER_ZONE];
+
+	/* cdev level information */
+	int cdev_indx; /* index into 'cdevs' array */
+	struct thermal_cooling_device *cdevs[MAX_CDEVS_PER_ZONE];
 };
 
 /* Structure that holds thermal governor information */
@@ -288,6 +294,9 @@ void remove_thermal_zone(struct thermal_zone *);
 int add_sensor_to_zone(struct thermal_zone *, struct thermal_sensor *);
 struct thermal_sensor *get_sensor_by_name(const char *);
 
+int add_cdev_to_zone(struct thermal_zone *, struct thermal_cooling_device *);
+struct thermal_cooling_device *get_cdev_by_name(const char *);
+
 #ifdef CONFIG_NET
 extern int thermal_generate_netlink_event(u32 orig, enum events event);
 #else
-- 
1.7.9.5

Re: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone structure

[Greg KH]

On Mon, Jan 07, 2013 at 12:43:20PM +0530, Durgadoss R wrote:
> +struct thermal_cooling_device *get_cdev_by_name(const char *name)
> +{
> +	struct thermal_cooling_device *pos;
> +	struct thermal_cooling_device *cdev = NULL;
> +
> +	mutex_lock(&cdev_list_lock);
> +	for_each_cdev(pos) {
> +		if (!strnicmp(pos->type, name, THERMAL_NAME_LENGTH)) {
> +			cdev = pos;
> +			break;
> +		}
> +	}
> +	mutex_unlock(&cdev_list_lock);
> +	return cdev;
> +}
> +EXPORT_SYMBOL(get_cdev_by_name);

EXPORT_SYMBOL_GPL?

You also forgot to increment the reference count, which is required for
all reference counted objects.

thanks,

greg k-h

RE: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone structure

[R, Durgadoss]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Tuesday, January 08, 2013 12:56 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> Subject: Re: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone
> structure
> 
> On Mon, Jan 07, 2013 at 12:43:20PM +0530, Durgadoss R wrote:
> > +struct thermal_cooling_device *get_cdev_by_name(const char *name)
> > +{
> > +	struct thermal_cooling_device *pos;
> > +	struct thermal_cooling_device *cdev = NULL;
> > +
> > +	mutex_lock(&cdev_list_lock);
> > +	for_each_cdev(pos) {
> > +		if (!strnicmp(pos->type, name, THERMAL_NAME_LENGTH)) {
> > +			cdev = pos;
> > +			break;
> > +		}
> > +	}
> > +	mutex_unlock(&cdev_list_lock);
> > +	return cdev;
> > +}
> > +EXPORT_SYMBOL(get_cdev_by_name);
> 
> EXPORT_SYMBOL_GPL?

We have all other exports as EXPORT_SYMBOL in this file(thermal_sys.c)
If _GPL is required, the we will do a single patch changing all of them to
EXPORT_SYMBOL_GPL.

> 
> You also forgot to increment the reference count, which is required for
> all reference counted objects.

Sorry, I could not get what you are saying here.

Thanks,
Durga

Re: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone structure

[Greg KH]

On Wed, Jan 09, 2013 at 09:21:23AM +0000, R, Durgadoss wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Tuesday, January 08, 2013 12:56 AM
> > To: R, Durgadoss
> > Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> > Subject: Re: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone
> > structure
> > 
> > On Mon, Jan 07, 2013 at 12:43:20PM +0530, Durgadoss R wrote:
> > > +struct thermal_cooling_device *get_cdev_by_name(const char *name)
> > > +{
> > > +	struct thermal_cooling_device *pos;
> > > +	struct thermal_cooling_device *cdev = NULL;
> > > +
> > > +	mutex_lock(&cdev_list_lock);
> > > +	for_each_cdev(pos) {
> > > +		if (!strnicmp(pos->type, name, THERMAL_NAME_LENGTH)) {
> > > +			cdev = pos;
> > > +			break;
> > > +		}
> > > +	}
> > > +	mutex_unlock(&cdev_list_lock);
> > > +	return cdev;
> > > +}
> > > +EXPORT_SYMBOL(get_cdev_by_name);
> > 
> > EXPORT_SYMBOL_GPL?
> 
> We have all other exports as EXPORT_SYMBOL in this file(thermal_sys.c)
> If _GPL is required, the we will do a single patch changing all of them to
> EXPORT_SYMBOL_GPL.

Fair enough.

> > You also forgot to increment the reference count, which is required for
> > all reference counted objects.
> 
> Sorry, I could not get what you are saying here.

You are doing a "get" call, yet you are failing to increment a reference
count on the object.  That isn't allowed and can cause bad problems.
Please use proper reference counting for your structures.

greg k-h

[PATCH 4/9] Thermal: Add trip point sysfs nodes for sensor

[Durgadoss R]

This patch adds a trip point related sysfs nodes
for each sensor under a zone in /sys/class/thermal/zoneX/.
The nodes will be named, sensorX_trip_active,
sensorX_trip_passive, sensorX_trip_hot, sensorX_trip_critical
for active, passive, hot and critical trip points
respectively for sensorX.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/thermal/thermal_sys.c |  211 ++++++++++++++++++++++++++++++++++++++++-
 include/linux/thermal.h       |   38 +++++++-
 2 files changed, 246 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 332bd61..1958bb8 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -450,6 +450,22 @@ static void thermal_zone_device_check(struct work_struct *work)
 	thermal_zone_device_update(tz);
 }
 
+static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char *name)
+{
+	int i, indx = -EINVAL;
+
+	mutex_lock(&sensor_list_lock);
+	for (i = 0; i < tz->sensor_indx; i++) {
+		if (!strnicmp(name, kobject_name(&tz->sensors[i]->device.kobj),
+					THERMAL_NAME_LENGTH)) {
+			indx = i;
+			break;
+		}
+	}
+	mutex_unlock(&sensor_list_lock);
+	return indx;
+}
+
 static void remove_sensor_from_zone(struct thermal_zone *tz,
 				struct thermal_sensor *ts)
 {
@@ -461,9 +477,16 @@ static void remove_sensor_from_zone(struct thermal_zone *tz,
 
 	sysfs_remove_link(&tz->device.kobj, kobject_name(&ts->device.kobj));
 
+	/* Remove trip point attributes associated with this sensor */
+	kfree(tz->trip_attr[indx]);
+	tz->trip_attr[indx] = NULL;
+
 	/* Shift the entries in the tz->sensors array */
-	for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
+	for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++) {
 		tz->sensors[j] = tz->sensors[j + 1];
+		tz->sensor_trip[j] = tz->sensor_trip[j + 1];
+		tz->trip_attr[j] = tz->trip_attr[j + 1];
+	}
 
 	tz->sensor_indx--;
 }
@@ -877,6 +900,99 @@ policy_show(struct device *dev, struct device_attribute *devattr, char *buf)
 	return sprintf(buf, "%s\n", tz->governor->name);
 }
 
+static ssize_t
+active_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	int i, indx, ret = 0;
+	char kobj_name[THERMAL_NAME_LENGTH];
+	struct thermal_zone *tz = to_zone(dev);
+
+	if (!sscanf(attr->attr.name, "sensor%d_trip_active", &i))
+		return -EINVAL;
+
+	snprintf(kobj_name, THERMAL_NAME_LENGTH, "sensor%d", i);
+	indx = get_sensor_indx_by_kobj(tz, kobj_name);
+	if (indx < 0)
+		return indx;
+
+	if (tz->sensor_trip[indx]->num_active_trips <= 0)
+		return sprintf(buf, "<Not available>\n");
+
+	ret += sprintf(buf, "0x%x", tz->sensor_trip[indx]->active_trip_mask);
+	for (i = 0; i < tz->sensor_trip[indx]->num_active_trips; i++) {
+		ret += sprintf(buf + ret, " %d",
+			tz->sensor_trip[indx]->active_trips[i]);
+	}
+
+	ret += sprintf(buf + ret, "\n");
+	return ret;
+}
+
+static ssize_t
+ptrip_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	int i, indx, ret = 0;
+	char kobj_name[THERMAL_NAME_LENGTH];
+	struct thermal_zone *tz = to_zone(dev);
+
+	if (!sscanf(attr->attr.name, "sensor%d_trip_passive", &i))
+		return -EINVAL;
+
+	snprintf(kobj_name, THERMAL_NAME_LENGTH, "sensor%d", i);
+	indx = get_sensor_indx_by_kobj(tz, kobj_name);
+	if (indx < 0)
+		return indx;
+
+	if (tz->sensor_trip[indx]->num_passive_trips <= 0)
+		return sprintf(buf, "<Not available>\n");
+
+	for (i = 0; i < tz->sensor_trip[indx]->num_passive_trips; i++) {
+		ret += sprintf(buf + ret, "%d ",
+			tz->sensor_trip[indx]->passive_trips[i]);
+	}
+
+	ret += sprintf(buf + ret, "\n");
+	return ret;
+}
+
+static ssize_t
+hot_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	int indx;
+	char kobj_name[THERMAL_NAME_LENGTH];
+	struct thermal_zone *tz = to_zone(dev);
+
+	if (!sscanf(attr->attr.name, "sensor%d_trip_hot", &indx))
+		return -EINVAL;
+
+	snprintf(kobj_name, THERMAL_NAME_LENGTH, "sensor%d", indx);
+
+	indx = get_sensor_indx_by_kobj(tz, kobj_name);
+	if (indx < 0)
+		return indx;
+
+	return sprintf(buf, "%d\n", tz->sensor_trip[indx]->hot);
+}
+
+static ssize_t
+critical_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	int indx;
+	char kobj_name[THERMAL_NAME_LENGTH];
+	struct thermal_zone *tz = to_zone(dev);
+
+	if (!sscanf(attr->attr.name, "sensor%d_trip_hot", &indx))
+		return -EINVAL;
+
+	snprintf(kobj_name, THERMAL_NAME_LENGTH, "sensor%d", indx);
+
+	indx = get_sensor_indx_by_kobj(tz, kobj_name);
+	if (indx < 0)
+		return indx;
+
+	return sprintf(buf, "%d\n", tz->sensor_trip[indx]->crit);
+}
+
 static DEVICE_ATTR(type, 0444, type_show, NULL);
 static DEVICE_ATTR(temp, 0444, temp_show, NULL);
 static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
@@ -887,7 +1003,8 @@ static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
 static DEVICE_ATTR(sensor_name, 0444, sensor_name_show, NULL);
 static DEVICE_ATTR(temp_input, 0444, sensor_temp_show, NULL);
 
-static DEVICE_ATTR(zone_name, 0444, zone_name_show, NULL);
+/* Thermal zone attributes */
+static DEVICE_ATTR(zone_name, S_IRUGO, zone_name_show, NULL);
 
 /* sys I/F for cooling device */
 #define to_cooling_device(_dev)	\
@@ -1742,6 +1859,38 @@ static int enable_sensor_thresholds(struct thermal_sensor *ts, int count)
 	return 0;
 }
 
+static int create_sensor_trip_attrs(struct thermal_zone *tz,
+				struct thermal_trip_attr *attr, int indx)
+{
+	int i, ret;
+	static const char *const names[NUM_TRIP_TYPES] = {
+				"sensor%d_trip_active",
+				"sensor%d_trip_passive",
+				"sensor%d_trip_hot",
+				"sensor%d_trip_critical",
+				};
+	static ssize_t (*const rd_ptr[NUM_TRIP_TYPES]) (struct device *dev,
+			struct device_attribute *devattr, char *buf) = {
+			active_show, ptrip_show, hot_show, critical_show};
+
+	for (i = 0; i < NUM_TRIP_TYPES; i++) {
+		snprintf(attr->attrs[i].name, THERMAL_NAME_LENGTH, names[i],
+			indx);
+		sysfs_attr_init(&attr->attrs[i].attr.attr);
+		attr->attrs[i].attr.attr.name = attr->attrs[i].name;
+		attr->attrs[i].attr.attr.mode = S_IRUGO;
+		attr->attrs[i].attr.show = rd_ptr[i];
+		ret = device_create_file(&tz->device, &attr->attrs[i].attr);
+		if (ret)
+			goto exit;
+	}
+	return 0;
+exit:
+	while (--i >= 0)
+		device_remove_file(&tz->device, &attr->attrs[i].attr);
+	return ret;
+}
+
 struct thermal_zone *create_thermal_zone(const char *name, void *devdata)
 {
 	struct thermal_zone *tz;
@@ -1791,6 +1940,7 @@ EXPORT_SYMBOL(create_thermal_zone);
 void remove_thermal_zone(struct thermal_zone *tz)
 {
 	struct thermal_zone *pos, *next;
+	int i;
 	bool found = false;
 
 	if (!tz)
@@ -1811,6 +1961,23 @@ void remove_thermal_zone(struct thermal_zone *tz)
 
 	device_remove_file(&tz->device, &dev_attr_zone_name);
 
+	/* Just for ease of usage */
+	i = tz->sensor_indx;
+	while (--i >= 0) {
+		/* Remove /sys/class/thermal/zoneX/sensorY */
+		sysfs_remove_link(&tz->device.kobj,
+				kobject_name(&tz->sensors[i]->device.kobj));
+		kfree(tz->trip_attr[i]);
+	}
+
+	/* Release the cdevs attached to this zone */
+	i = tz->cdev_indx;
+	while (--i >= 0) {
+		/* Remove /sys/class/thermal/zoneX/cooling_deviceY */
+		sysfs_remove_link(&tz->device.kobj,
+				kobject_name(&tz->cdevs[i]->device.kobj));
+	}
+
 	release_idr(&thermal_zone_idr, &thermal_idr_lock, tz->id);
 	idr_destroy(&tz->idr);
 
@@ -1922,6 +2089,46 @@ exit_zone:
 }
 EXPORT_SYMBOL(add_cdev_to_zone);
 
+int add_sensor_trip_info(struct thermal_zone *tz, struct thermal_sensor *ts,
+			struct thermal_trip_point *trip)
+{
+	int ret, indx, kobj_indx;
+
+	if (!tz || !ts || !trip)
+		return -EINVAL;
+
+	if (!sscanf(kobject_name(&ts->device.kobj), "sensor%d", &kobj_indx))
+		return -EINVAL;
+
+	mutex_lock(&zone_list_lock);
+
+	indx = GET_INDEX(tz, ts, sensor);
+	if (indx < 0) {
+		ret = -EINVAL;
+		goto exit;
+	}
+
+	tz->trip_attr[indx] = kzalloc(sizeof(struct thermal_trip_attr),
+					GFP_KERNEL);
+	if (!tz->trip_attr[indx]) {
+		ret = -ENOMEM;
+		goto exit;
+	}
+
+	ret = create_sensor_trip_attrs(tz, tz->trip_attr[indx], kobj_indx);
+	if (ret) {
+		kfree(tz->trip_attr[indx]);
+		goto exit;
+	}
+
+	tz->sensor_trip[indx] = trip;
+
+exit:
+	mutex_unlock(&zone_list_lock);
+	return ret;
+}
+EXPORT_SYMBOL(add_sensor_trip_info);
+
 /**
  * thermal_sensor_register - register a new thermal sensor
  * @name:	name of the thermal sensor
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 12cc953..474547d 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -31,7 +31,8 @@
 
 #define THERMAL_TRIPS_NONE	-1
 #define THERMAL_MAX_TRIPS	12
-#define THERMAL_NAME_LENGTH	20
+#define THERMAL_NAME_LENGTH	22
+#define NUM_TRIP_TYPES		4
 
 /* No upper/lower limit requirement */
 #define THERMAL_NO_LIMIT	-1UL
@@ -158,6 +159,34 @@ struct thermal_attr {
 	char name[THERMAL_NAME_LENGTH];
 };
 
+/*
+ * This structure defines the trip points for a sensor.
+ * The actual values for these trip points come from
+ * platform characterization. The thermal governors
+ * (either kernel or user space) may take appropriate
+ * actions when the sensors reach these trip points.
+ * See Documentation/thermal/sysfs-api2.txt for more details.
+ *
+ * As of now, For a particular sensor, we support:
+ * a) 1 hot trip point
+ * b) 1 critical trip point
+ * c) 'n' passive trip points
+ * d) 'm' active trip points
+ */
+struct thermal_trip_point {
+	int hot;
+	int crit;
+	int num_passive_trips;
+	int *passive_trips;
+	int num_active_trips;
+	int *active_trips;
+	int active_trip_mask;
+};
+
+struct thermal_trip_attr {
+	struct thermal_attr attrs[NUM_TRIP_TYPES];
+};
+
 struct thermal_sensor {
 	char name[THERMAL_NAME_LENGTH];
 	int id;
@@ -215,6 +244,10 @@ struct thermal_zone {
 	/* cdev level information */
 	int cdev_indx; /* index into 'cdevs' array */
 	struct thermal_cooling_device *cdevs[MAX_CDEVS_PER_ZONE];
+
+	/* Thermal sensors trip information */
+	struct thermal_trip_point *sensor_trip[MAX_SENSORS_PER_ZONE];
+	struct thermal_trip_attr *trip_attr[MAX_SENSORS_PER_ZONE];
 };
 
 /* Structure that holds thermal governor information */
@@ -297,6 +330,9 @@ struct thermal_sensor *get_sensor_by_name(const char *);
 int add_cdev_to_zone(struct thermal_zone *, struct thermal_cooling_device *);
 struct thermal_cooling_device *get_cdev_by_name(const char *);
 
+int add_sensor_trip_info(struct thermal_zone *, struct thermal_sensor *,
+			struct thermal_trip_point *);
+
 #ifdef CONFIG_NET
 extern int thermal_generate_netlink_event(u32 orig, enum events event);
 #else
-- 
1.7.9.5

[PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone

[Durgadoss R]

This patch creates a thermal map sysfs node under
/sys/class/thermal/zoneX/. This contains
entries named map0, map1 .. mapN. Each map has the
following space separated values:
trip_type sensor_name cdev_name trip_mask weights

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/thermal/thermal_sys.c |  122 ++++++++++++++++++++++++++++++++++++++++-
 include/linux/thermal.h       |   19 +++++++
 2 files changed, 139 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 1958bb8..5f806d1 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -509,6 +509,39 @@ static void remove_cdev_from_zone(struct thermal_zone *tz,
 	tz->cdev_indx--;
 }
 
+static inline void __clean_map_entry(struct thermal_zone *tz, int i)
+{
+	device_remove_file(&tz->device, &tz->map_attr[i]->attr);
+	kfree(tz->map_attr[i]);
+	tz->map[i] = NULL;
+}
+
+static void remove_sensor_map_entry(struct thermal_zone *tz,
+				struct thermal_sensor *ts)
+{
+	int i;
+
+	for (i = 0; i < MAX_MAPS_PER_ZONE; i++) {
+		if (tz->map[i] && !strnicmp(ts->name, tz->map[i]->sensor_name,
+						THERMAL_NAME_LENGTH)) {
+			__clean_map_entry(tz, i);
+		}
+	}
+}
+
+static void remove_cdev_map_entry(struct thermal_zone *tz,
+				struct thermal_cooling_device *cdev)
+{
+	int i;
+
+	for (i = 0; i < MAX_MAPS_PER_ZONE; i++) {
+		if (tz->map[i] && !strnicmp(cdev->type, tz->map[i]->cdev_name,
+						THERMAL_NAME_LENGTH)) {
+			__clean_map_entry(tz, i);
+		}
+	}
+}
+
 /* sys I/F for thermal zone */
 
 #define to_thermal_zone(_dev) \
@@ -901,6 +934,39 @@ policy_show(struct device *dev, struct device_attribute *devattr, char *buf)
 }
 
 static ssize_t
+map_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	char *trip;
+	int i, indx, ret = 0;
+	struct thermal_map *map;
+	struct thermal_zone *tz = to_zone(dev);
+
+	if (!sscanf(attr->attr.name, "map%d", &indx))
+		return -EINVAL;
+
+	if (indx < 0 || indx >= MAX_MAPS_PER_ZONE)
+		return -EINVAL;
+
+	if (!tz->map[indx])
+		return sprintf(buf, "<Unavailable>\n");
+
+	map = tz->map[indx];
+
+	trip = (map->trip_type == THERMAL_TRIP_ACTIVE) ?
+					"active" : "passive";
+	ret += sprintf(buf, "%s", trip);
+	ret += sprintf(buf + ret, " %s", map->sensor_name);
+	ret += sprintf(buf + ret, " %s", map->cdev_name);
+	ret += sprintf(buf + ret, " 0x%x", map->trip_mask);
+
+	for (i = 0; i < map->num_weights; i++)
+		ret += sprintf(buf + ret, " %d", map->weights[i]);
+
+	ret += sprintf(buf + ret, "\n");
+	return ret;
+}
+
+static ssize_t
 active_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
 	int i, indx, ret = 0;
@@ -1639,8 +1705,10 @@ void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
 
 	mutex_lock(&zone_list_lock);
 
-	for_each_thermal_zone(tmp_tz)
+	for_each_thermal_zone(tmp_tz) {
 		remove_cdev_from_zone(tmp_tz, cdev);
+		remove_cdev_map_entry(tmp_tz, cdev);
+	}
 
 	mutex_unlock(&zone_list_lock);
 
@@ -1978,6 +2046,9 @@ void remove_thermal_zone(struct thermal_zone *tz)
 				kobject_name(&tz->cdevs[i]->device.kobj));
 	}
 
+	for (i = 0; i < MAX_MAPS_PER_ZONE; i++)
+		__clean_map_entry(tz, i);
+
 	release_idr(&thermal_zone_idr, &thermal_idr_lock, tz->id);
 	idr_destroy(&tz->idr);
 
@@ -2023,6 +2094,51 @@ struct thermal_sensor *get_sensor_by_name(const char *name)
 }
 EXPORT_SYMBOL(get_sensor_by_name);
 
+int add_map_entry(struct thermal_zone *tz, struct thermal_map *map)
+{
+	int ret, indx;
+
+	if (!tz || !map)
+		return -EINVAL;
+
+	mutex_lock(&zone_list_lock);
+
+	for (indx = 0; indx < MAX_MAPS_PER_ZONE; indx++) {
+		if (tz->map[indx] == NULL)
+			break;
+	}
+
+	if (indx >= MAX_MAPS_PER_ZONE) {
+		ret = -EINVAL;
+		goto exit;
+	}
+
+	tz->map_attr[indx] = kzalloc(sizeof(struct thermal_attr), GFP_KERNEL);
+	if (!tz->map_attr[indx]) {
+		ret = -ENOMEM;
+		goto exit;
+	}
+
+	sprintf(tz->map_attr[indx]->name, "map%d", indx);
+
+	tz->map_attr[indx]->attr.attr.name = tz->map_attr[indx]->name;
+	tz->map_attr[indx]->attr.attr.mode = S_IRUGO;
+	tz->map_attr[indx]->attr.show = map_show;
+
+	sysfs_attr_init(&tz->map_attr[indx]->attr.attr);
+	ret = device_create_file(&tz->device, &tz->map_attr[indx]->attr);
+	if (ret) {
+		kfree(tz->map_attr[indx]);
+		goto exit;
+	}
+
+	tz->map[indx] = map;
+exit:
+	mutex_unlock(&zone_list_lock);
+	return ret;
+}
+EXPORT_SYMBOL(add_map_entry);
+
 int add_sensor_to_zone(struct thermal_zone *tz, struct thermal_sensor *ts)
 {
 	int ret;
@@ -2227,8 +2343,10 @@ void thermal_sensor_unregister(struct thermal_sensor *ts)
 
 	mutex_lock(&zone_list_lock);
 
-	for_each_thermal_zone(tz)
+	for_each_thermal_zone(tz) {
 		remove_sensor_from_zone(tz, ts);
+		remove_sensor_map_entry(tz, ts);
+	}
 
 	mutex_unlock(&zone_list_lock);
 
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 474547d..187fadb 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -54,6 +54,9 @@
 
 #define MAX_CDEVS_PER_ZONE		5
 
+/* If we map each sensor with every possible cdev for a zone */
+#define MAX_MAPS_PER_ZONE	(MAX_SENSORS_PER_ZONE * MAX_CDEVS_PER_ZONE)
+
 struct thermal_sensor;
 struct thermal_zone_device;
 struct thermal_cooling_device;
@@ -159,6 +162,16 @@ struct thermal_attr {
 	char name[THERMAL_NAME_LENGTH];
 };
 
+struct thermal_map {
+	enum thermal_trip_type trip_type;
+	char cdev_name[THERMAL_NAME_LENGTH];
+	char sensor_name[THERMAL_NAME_LENGTH];
+
+	int trip_mask;
+	int num_weights;
+	int *weights;
+};
+
 /*
  * This structure defines the trip points for a sensor.
  * The actual values for these trip points come from
@@ -248,6 +261,10 @@ struct thermal_zone {
 	/* Thermal sensors trip information */
 	struct thermal_trip_point *sensor_trip[MAX_SENSORS_PER_ZONE];
 	struct thermal_trip_attr *trip_attr[MAX_SENSORS_PER_ZONE];
+
+	/* Thermal map information */
+	struct thermal_map *map[MAX_MAPS_PER_ZONE];
+	struct thermal_attr *map_attr[MAX_MAPS_PER_ZONE];
 };
 
 /* Structure that holds thermal governor information */
@@ -333,6 +350,8 @@ struct thermal_cooling_device *get_cdev_by_name(const char *);
 int add_sensor_trip_info(struct thermal_zone *, struct thermal_sensor *,
 			struct thermal_trip_point *);
 
+int add_map_entry(struct thermal_zone *, struct thermal_map *);
+
 #ifdef CONFIG_NET
 extern int thermal_generate_netlink_event(u32 orig, enum events event);
 #else
-- 
1.7.9.5

Re: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone

[Greg KH]

On Mon, Jan 07, 2013 at 12:43:22PM +0530, Durgadoss R wrote:
> This patch creates a thermal map sysfs node under
> /sys/class/thermal/zoneX/. This contains
> entries named map0, map1 .. mapN. Each map has the
> following space separated values:
> trip_type sensor_name cdev_name trip_mask weights

sysfs file are always "one value per file".  This seems to violate that
rule, so please rework this.

thanks,

greg k-h

RE: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone

[R, Durgadoss]

> -----Original Message-----
> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> owner@vger.kernel.org] On Behalf Of Greg KH
> Sent: Tuesday, January 08, 2013 12:51 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> Subject: Re: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone
> 
> On Mon, Jan 07, 2013 at 12:43:22PM +0530, Durgadoss R wrote:
> > This patch creates a thermal map sysfs node under
> > /sys/class/thermal/zoneX/. This contains
> > entries named map0, map1 .. mapN. Each map has the
> > following space separated values:
> > trip_type sensor_name cdev_name trip_mask weights
> 
> sysfs file are always "one value per file".  This seems to violate that
> rule, so please rework this.

These values together represent the binding information of
sensors and cooling devices in a zone. That's why we put
them in a single file.

>From our previous discussion, I understand we can support
a lot of nodes in sysfs. So, I will work with Rui to see how we can
split this in a meaningful way.

Something like:
map0_trip_type
map0_sensor_name
map0_cdev_name
map0_mask
etc..

Rui, What do you think ?

Thanks,
Durga

Re: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone

[Greg KH]

On Thu, Jan 10, 2013 at 12:50:20PM +0000, R, Durgadoss wrote:
> > -----Original Message-----
> > From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> > owner@vger.kernel.org] On Behalf Of Greg KH
> > Sent: Tuesday, January 08, 2013 12:51 AM
> > To: R, Durgadoss
> > Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> > Subject: Re: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone
> > 
> > On Mon, Jan 07, 2013 at 12:43:22PM +0530, Durgadoss R wrote:
> > > This patch creates a thermal map sysfs node under
> > > /sys/class/thermal/zoneX/. This contains
> > > entries named map0, map1 .. mapN. Each map has the
> > > following space separated values:
> > > trip_type sensor_name cdev_name trip_mask weights
> > 
> > sysfs file are always "one value per file".  This seems to violate that
> > rule, so please rework this.
> 
> These values together represent the binding information of
> sensors and cooling devices in a zone. That's why we put
> them in a single file.

That doesn't matter, it's still multiple values in a single file that
has to be parsed now.

> >From our previous discussion, I understand we can support
> a lot of nodes in sysfs. So, I will work with Rui to see how we can
> split this in a meaningful way.
> 
> Something like:
> map0_trip_type
> map0_sensor_name
> map0_cdev_name
> map0_mask
> etc..

That would be much better.

thanks,

greg k-h

[PATCH 6/9] Thermal: Add Documentation to new APIs

[Durgadoss R]

This patch adds Documentation for the new APIs
introduced in this patch set. The documentation
also has a model sysfs structure for reference.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 Documentation/thermal/sysfs-api2.txt |  248 ++++++++++++++++++++++++++++++++++
 1 file changed, 248 insertions(+)
 create mode 100644 Documentation/thermal/sysfs-api2.txt

diff --git a/Documentation/thermal/sysfs-api2.txt b/Documentation/thermal/sysfs-api2.txt
new file mode 100644
index 0000000..ffd0402
--- /dev/null
+++ b/Documentation/thermal/sysfs-api2.txt
@@ -0,0 +1,248 @@
+Thermal Framework
+-----------------
+
+Written by Durgadoss R <durgadoss.r@intel.com>
+Copyright (c) 2012 Intel Corporation
+
+Created on: 4 November 2012
+Updated on: 18 December 2012
+
+0. Introduction
+---------------
+The Linux thermal framework provides a set of interfaces for thermal
+sensors and thermal cooling devices (fan, processor...) to register
+with the thermal management solution and to be a part of it.
+
+This document focuses on how to enable new thermal sensors and cooling
+devices to participate in thermal management. This solution is intended
+to be 'light-weight' and platform/architecture independent. Any thermal
+sensor/cooling device should be able to use the infrastructure easily.
+
+The goal of thermal framework is to expose the thermal sensor/zone and
+cooling device attributes in a consistent way. This will help the
+thermal governors to make use of the information to manage platform
+thermals efficiently.
+
+The thermal sensor source file can be generic (can be any sensor driver,
+in any subsystem). This driver will use the sensor APIs and register with
+thermal framework to participate in platform Thermal management. This
+does not (and should not) know about which zone it belongs to, or any
+other information about platform thermals. A sensor driver is a standalone
+piece of code, which can optionally register with thermal framework.
+
+However, for any platform, there should be a platformX_thermal.c file,
+which will know about the platform thermal characteristics (like how many
+sensors, zones, cooling devices, etc.. And how they are related to each other
+i.e the mapping information). Only in this file, the zone level APIs should
+be used, in which case the file will have all information required to attach
+various sensors to a particular zone.
+
+This way, we can have one platform level thermal file, which can support
+multiple platforms (may be)using the same set of sensors (but)binded in
+a different way. This file can get the platform thermal information
+through Firmware, ACPI tables, device tree etc.
+
+Unfortunately, today we don't have many drivers that can be clearly
+differentiated as 'sensor_file.c' and 'platform_thermal_file.c'.
+But very soon we will need/have. The reason I am saying this is because
+we are seeing a lot of chip drivers, starting to use thermal framework,
+and we should keep it really light-weight for them to do so.
+
+An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver
+In one platform this sensor can belong to 'ZoneA' and in another the
+same can belong to 'ZoneB'. But, emc1403.c does not really care about
+where does it belong. It just reports temperature.
+
+1. Terminology
+--------------
+This section describes the terminology used in the rest of this
+document as well as the thermal framework code.
+
+thermal_sensor: Hardware that can report temperature of a particular
+		spot in the platform, where it is placed. The temperature
+		reported by the sensor is the 'real' temperature reported
+		by the hardware.
+thermal_zone:	A virtual area on the device, that gets heated up. It may
+		have one or more thermal sensors attached to it.
+cooling_device:	Any component that can help in reducing the temperature of
+		a 'hot spot' either by reducing its performance (passive
+		cooling) or by other means(Active cooling E.g. Fan)
+
+trip_points:	Various temperature levels for each sensor. As of now, we
+		have four levels namely active, passive, hot and critical.
+		Hot and critical trip point support only one value whereas
+		active and passive can have any number of values. These
+		temperature values can come from platform data, and are
+		exposed through sysfs in a consistent manner. Stand-alone
+		thermal sensor drivers are not expected to know these values.
+		These values are RO.
+thresholds:	These are programmable temperature limits, on reaching which
+		the thermal sensor generates an interrupt. The framework is
+		notified about this interrupt to take appropriate action.
+		There can be as many number of thresholds as that of the
+		hardware supports. These values are RW.
+
+thermal_map:	This provides the mapping (aka binding) information between
+		various sensors and cooling devices in a particular zone.
+		Typically, this also comes from platform data; Stand-alone
+		sensor drivers or cooling device drivers are not expected
+		to know these mapping information.
+
+2. Thermal framework APIs
+-------------------------
+2.1: For Thermal Sensors
+2.1.1 thermal_sensor_register:
+	This function creates a new sensor directory under /sys/class/thermal/
+	as sensor[0-*]. This API is expected to be called by thermal sensor
+	drivers. These drivers may or may not be in thermal subsystem. This
+	function returns a thermal_sensor structure on success and appropriate
+	error on failure.
+
+	name: Name of the sensor
+	count: Number of programmable thresholds associated with this sensor
+	devdata: Device private data
+	ops: Thermal sensor callbacks
+		.get_temp: obtain the current temperature of the sensor
+		.get_trend: obtain the trend of the sensor
+		.get_threshold: get a particular threshold temperature
+		.set_threshold: set a particular threshold temperature
+		.get_hyst: get hysteresis value associated with a threshold
+		.set_hyst: set hysteresis value associated with a threshold
+
+2.1.2 thermal_sensor_unregister:
+	This function deletes the sensor directory under /sys/class/thermal/
+	for the given sensor. Thermal sensor drivers may call this API
+	during the driver's 'exit' routine.
+
+	ts: Thermal sensor that has to be unregistered
+
+2.1.3 enable_sensor_thresholds:
+	This function creates 'threshold[0-*]' attributes under a particular
+	sensorX directory. These values are RW. This function is called by
+	the sensr driver only if the sensor supports interrupt mechanism.
+
+	ts: Thermal sensor for which thresholds have to be enabled
+	num_thresholds: Number of thresholds supported by the sensor
+
+2.2: For Cooling Devices
+2.2.1 thermal_cooling_device_register:
+	This function adds a new thermal cooling device (fan/processor/...)
+	to /sys/class/thermal/ folder as cooling_device[0-*]. This function
+	is expected to be called by cooling device drivers that may be
+	present in other subsystems also.
+
+	name: the cooling device name
+	devdata: device private data
+	ops: thermal cooling devices callbacks
+	.get_max_state: get the Maximum throttle state of the cooling device
+	.get_cur_state: get the Current throttle state of the cooling device
+	.set_cur_state: set the Current throttle state of the cooling device
+
+2.2.2 thermal_cooling_device_unregister:
+	This function deletes the given cdev entry form /sys/class/thermal;
+	and also cleans all the symlinks referred from various zones.
+
+	cdev: Cooling device to be unregistered
+
+2.3: For Thermal Zones
+2.3.1 create_thermal_zone:
+	This function adds a new 'zone' under /sys/class/thermal/
+	directory as zone[0-*]. This zone has at least one thermal
+	sensor and at most MAX_SENSORS_PER_ZONE number of sensors
+	attached to it. Similarly, this zone has at least one cdev
+	and at most MAX_CDEVS_PER_ZONE number of cdevs attached to it.
+	Both the MAX_*_PER_ZONE values are configurable, through
+	Kconfig option(during 'menuconfig').
+
+	name: Name of the thermal zone
+	devdata: Device private data
+
+2.3.2 add_sensor_to_zone
+	This function adds a 'sensorX' entry under /sys/class/thermal/
+	zoneY/ directory. This 'sensorX' is a symlink to the actual
+	sensor entry under /sys/class/thermal/. Correspondingly, the
+	method remove_sensor_from_zone deletes the symlink.
+
+	tz: thermal zone structure
+	ts: thermal sensor structure
+
+2.3.3 add_cdev_to_zone
+	This function adds a 'cdevX' entry under /sys/class/thermal/
+	zoneY/ directory. This 'cdevX' is a symlink to the actual
+	cdev entry under /sys/class/thermal/. Correspondingly, the
+	method remove_cdev_from_zone deletes the symlink.
+
+	tz: thermal zone structure
+	cdev: thermal cooling device structure
+
+2.4 For Thermal Trip
+2.4.1 add_sensor_trip_info
+	This function adds trip point information for the given sensor,
+	(under a given zone) under /sys/class/thermal/zoneX/thermal_trip/
+	This API creates 4 sysfs attributes namely active, passive, hot,
+	and critical. Each of these hold one or more trip point temperature
+	values, as provided from platform data.
+
+	tz: thermal zone structure
+	ts: thermal sensor to which the trip points are attached
+	trip: trip point structure. Usually obtained from platform data
+
+2.5 For Thermal Map
+2.5.1 add_map_entry
+	This function adds a 'map[0-*]' sysfs attribute under
+	/sys/class/thermal/zoneX/thermal_map/. Each map holds a space
+	separated list of values, that specify the binding relationship
+	between a sensor and a cdev in the given zone. The map structure
+	is typically obtained as platform data. For example, through
+	ACPI tables, SFI tables, Device tree etc.
+
+	tz: thermal zone to which a 'map' is being added
+	map: thermal_map structure
+
+3. Sysfs attributes structure
+-----------------------------
+Thermal sysfs attributes will be represented under /sys/class/thermal.
+
+3.1: For Thermal Sensors
+	/sys/class/thermal/sensor[0-*]:
+		|---type:		Name of the thermal sensor
+		|---temp_input:		Current temperature in mC
+		|---threshold[0-*]:	Threshold temperature in mC
+		|---threshold[0-*]_hyst:Optional hysteresis value in mC
+
+3.2: For Thermal Cooling Devices
+	/sys/class/thermal/cooling_device[0-*]:
+		|---type:		Type of the cooling device
+		|---max_state:		Maximum throttle state of the cdev
+		|---cur_state:		Current throttle state of the cdev
+
+3.3: For Thermal Zones
+	/sys/class/thermal/zone[0-*]:
+		|---name:		Name of the thermal
+		|---sensorX:		Symlink to ../sensorX
+		|---cdevY:		Symlink to ../cdevY
+		|---thermal_trip:	trip point values for sensors
+		|---thermal_map:	mapping info between sensors and cdevs
+
+3.4: For Thermal Trip
+	This attribute represents the trip point values for all sensors
+	present in the thermal zone. All values are in mC.
+	/sys/class/thermal/zoneX/thermal_trip/sensorY:
+		|---hot:		hot trip point value
+		|---critical:		critical trip point value
+		|---passive:		list of passive trip point values
+		|---active:		list of active trip point values
+
+3.5: For Thermal Map
+	Each attribute represents the mapping/binding information between
+	a sensor and a cdev, together with a trip type.
+	/sys/class/thermal/zoneX/thermal_map/:
+		|---mapX:		mapping information
+	A typical map entry is like below:
+
+	trip_type  sensor  cdev  trip_mask  weight(s)
+	passive    cpu     proc  0x03       50 30
+	active     cpu     fan0  0x03       50 70
+
+	The trip mask is a bit string; if 'n' th bit is set, then for
+	trip point 'n' this cdev is throttled with the given weight[n].
-- 
1.7.9.5

Re: [PATCH 6/9] Thermal: Add Documentation to new APIs

[Wei Ni]

On 01/07/2013 03:13 PM, Durgadoss R wrote:
> This patch adds Documentation for the new APIs
> introduced in this patch set. The documentation
> also has a model sysfs structure for reference.
> 
> Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
> ---
>  Documentation/thermal/sysfs-api2.txt |  248 ++++++++++++++++++++++++++++++++++
>  1 file changed, 248 insertions(+)
>  create mode 100644 Documentation/thermal/sysfs-api2.txt
> 
> diff --git a/Documentation/thermal/sysfs-api2.txt b/Documentation/thermal/sysfs-api2.txt
> new file mode 100644
> index 0000000..ffd0402
> --- /dev/null
> +++ b/Documentation/thermal/sysfs-api2.txt
> @@ -0,0 +1,248 @@
> +Thermal Framework
> +-----------------
> +
> +Written by Durgadoss R <durgadoss.r@intel.com>
> +Copyright (c) 2012 Intel Corporation
> +
> +Created on: 4 November 2012
> +Updated on: 18 December 2012
> +
> +0. Introduction
> +---------------
> +The Linux thermal framework provides a set of interfaces for thermal
> +sensors and thermal cooling devices (fan, processor...) to register
> +with the thermal management solution and to be a part of it.
> +
> +This document focuses on how to enable new thermal sensors and cooling
> +devices to participate in thermal management. This solution is intended
> +to be 'light-weight' and platform/architecture independent. Any thermal
> +sensor/cooling device should be able to use the infrastructure easily.
> +
> +The goal of thermal framework is to expose the thermal sensor/zone and
> +cooling device attributes in a consistent way. This will help the
> +thermal governors to make use of the information to manage platform
> +thermals efficiently.
> +
> +The thermal sensor source file can be generic (can be any sensor driver,
> +in any subsystem). This driver will use the sensor APIs and register with
> +thermal framework to participate in platform Thermal management. This
> +does not (and should not) know about which zone it belongs to, or any
> +other information about platform thermals. A sensor driver is a standalone
> +piece of code, which can optionally register with thermal framework.
> +
> +However, for any platform, there should be a platformX_thermal.c file,
> +which will know about the platform thermal characteristics (like how many
> +sensors, zones, cooling devices, etc.. And how they are related to each other
> +i.e the mapping information). Only in this file, the zone level APIs should
> +be used, in which case the file will have all information required to attach
> +various sensors to a particular zone.
> +
> +This way, we can have one platform level thermal file, which can support
> +multiple platforms (may be)using the same set of sensors (but)binded in
> +a different way. This file can get the platform thermal information
> +through Firmware, ACPI tables, device tree etc.
> +
> +Unfortunately, today we don't have many drivers that can be clearly
> +differentiated as 'sensor_file.c' and 'platform_thermal_file.c'.
> +But very soon we will need/have. The reason I am saying this is because
> +we are seeing a lot of chip drivers, starting to use thermal framework,
> +and we should keep it really light-weight for them to do so.
> +
> +An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver
> +In one platform this sensor can belong to 'ZoneA' and in another the
> +same can belong to 'ZoneB'. But, emc1403.c does not really care about
> +where does it belong. It just reports temperature.
> +
> +1. Terminology
> +--------------
> +This section describes the terminology used in the rest of this
> +document as well as the thermal framework code.
> +
> +thermal_sensor: Hardware that can report temperature of a particular
> +               spot in the platform, where it is placed. The temperature
> +               reported by the sensor is the 'real' temperature reported
> +               by the hardware.
> +thermal_zone:  A virtual area on the device, that gets heated up. It may
> +               have one or more thermal sensors attached to it.
> +cooling_device:        Any component that can help in reducing the temperature of
> +               a 'hot spot' either by reducing its performance (passive
> +               cooling) or by other means(Active cooling E.g. Fan)
> +
> +trip_points:   Various temperature levels for each sensor. As of now, we
> +               have four levels namely active, passive, hot and critical.
> +               Hot and critical trip point support only one value whereas
> +               active and passive can have any number of values. These
> +               temperature values can come from platform data, and are
> +               exposed through sysfs in a consistent manner. Stand-alone
> +               thermal sensor drivers are not expected to know these values.
> +               These values are RO.
> +thresholds:    These are programmable temperature limits, on reaching which
> +               the thermal sensor generates an interrupt. The framework is
> +               notified about this interrupt to take appropriate action.
> +               There can be as many number of thresholds as that of the
> +               hardware supports. These values are RW.

Hi,
When generate interrupt, we could call something like
notify_thermal_framework(), is it right? but it just notify the
framework, how to notify the platform driver? I think the platform
driver will wish to update the limited values when interrupt occur.
Will we have a thermal zone fops like ops.notify()?
I noticed there have "struct thermal_zone *ops" in the thermal_zone
structure, will it be used for callback?

Thanks.
Wei.

> +
> +thermal_map:   This provides the mapping (aka binding) information between
> +               various sensors and cooling devices in a particular zone.
> +               Typically, this also comes from platform data; Stand-alone
> +               sensor drivers or cooling device drivers are not expected
> +               to know these mapping information.
> +
> +2. Thermal framework APIs
> +-------------------------
> +2.1: For Thermal Sensors
> +2.1.1 thermal_sensor_register:
> +       This function creates a new sensor directory under /sys/class/thermal/
> +       as sensor[0-*]. This API is expected to be called by thermal sensor
> +       drivers. These drivers may or may not be in thermal subsystem. This
> +       function returns a thermal_sensor structure on success and appropriate
> +       error on failure.
> +
> +       name: Name of the sensor
> +       count: Number of programmable thresholds associated with this sensor
> +       devdata: Device private data
> +       ops: Thermal sensor callbacks
> +               .get_temp: obtain the current temperature of the sensor
> +               .get_trend: obtain the trend of the sensor
> +               .get_threshold: get a particular threshold temperature
> +               .set_threshold: set a particular threshold temperature
> +               .get_hyst: get hysteresis value associated with a threshold
> +               .set_hyst: set hysteresis value associated with a threshold
> +
> +2.1.2 thermal_sensor_unregister:
> +       This function deletes the sensor directory under /sys/class/thermal/
> +       for the given sensor. Thermal sensor drivers may call this API
> +       during the driver's 'exit' routine.
> +
> +       ts: Thermal sensor that has to be unregistered
> +
> +2.1.3 enable_sensor_thresholds:
> +       This function creates 'threshold[0-*]' attributes under a particular
> +       sensorX directory. These values are RW. This function is called by
> +       the sensr driver only if the sensor supports interrupt mechanism.
> +
> +       ts: Thermal sensor for which thresholds have to be enabled
> +       num_thresholds: Number of thresholds supported by the sensor
> +
> +2.2: For Cooling Devices
> +2.2.1 thermal_cooling_device_register:
> +       This function adds a new thermal cooling device (fan/processor/...)
> +       to /sys/class/thermal/ folder as cooling_device[0-*]. This function
> +       is expected to be called by cooling device drivers that may be
> +       present in other subsystems also.
> +
> +       name: the cooling device name
> +       devdata: device private data
> +       ops: thermal cooling devices callbacks
> +       .get_max_state: get the Maximum throttle state of the cooling device
> +       .get_cur_state: get the Current throttle state of the cooling device
> +       .set_cur_state: set the Current throttle state of the cooling device
> +
> +2.2.2 thermal_cooling_device_unregister:
> +       This function deletes the given cdev entry form /sys/class/thermal;
> +       and also cleans all the symlinks referred from various zones.
> +
> +       cdev: Cooling device to be unregistered
> +
> +2.3: For Thermal Zones
> +2.3.1 create_thermal_zone:
> +       This function adds a new 'zone' under /sys/class/thermal/
> +       directory as zone[0-*]. This zone has at least one thermal
> +       sensor and at most MAX_SENSORS_PER_ZONE number of sensors
> +       attached to it. Similarly, this zone has at least one cdev
> +       and at most MAX_CDEVS_PER_ZONE number of cdevs attached to it.
> +       Both the MAX_*_PER_ZONE values are configurable, through
> +       Kconfig option(during 'menuconfig').
> +
> +       name: Name of the thermal zone
> +       devdata: Device private data
> +
> +2.3.2 add_sensor_to_zone
> +       This function adds a 'sensorX' entry under /sys/class/thermal/
> +       zoneY/ directory. This 'sensorX' is a symlink to the actual
> +       sensor entry under /sys/class/thermal/. Correspondingly, the
> +       method remove_sensor_from_zone deletes the symlink.
> +
> +       tz: thermal zone structure
> +       ts: thermal sensor structure
> +
> +2.3.3 add_cdev_to_zone
> +       This function adds a 'cdevX' entry under /sys/class/thermal/
> +       zoneY/ directory. This 'cdevX' is a symlink to the actual
> +       cdev entry under /sys/class/thermal/. Correspondingly, the
> +       method remove_cdev_from_zone deletes the symlink.
> +
> +       tz: thermal zone structure
> +       cdev: thermal cooling device structure
> +
> +2.4 For Thermal Trip
> +2.4.1 add_sensor_trip_info
> +       This function adds trip point information for the given sensor,
> +       (under a given zone) under /sys/class/thermal/zoneX/thermal_trip/
> +       This API creates 4 sysfs attributes namely active, passive, hot,
> +       and critical. Each of these hold one or more trip point temperature
> +       values, as provided from platform data.
> +
> +       tz: thermal zone structure
> +       ts: thermal sensor to which the trip points are attached
> +       trip: trip point structure. Usually obtained from platform data
> +
> +2.5 For Thermal Map
> +2.5.1 add_map_entry
> +       This function adds a 'map[0-*]' sysfs attribute under
> +       /sys/class/thermal/zoneX/thermal_map/. Each map holds a space
> +       separated list of values, that specify the binding relationship
> +       between a sensor and a cdev in the given zone. The map structure
> +       is typically obtained as platform data. For example, through
> +       ACPI tables, SFI tables, Device tree etc.
> +
> +       tz: thermal zone to which a 'map' is being added
> +       map: thermal_map structure
> +
> +3. Sysfs attributes structure
> +-----------------------------
> +Thermal sysfs attributes will be represented under /sys/class/thermal.
> +
> +3.1: For Thermal Sensors
> +       /sys/class/thermal/sensor[0-*]:
> +               |---type:               Name of the thermal sensor
> +               |---temp_input:         Current temperature in mC
> +               |---threshold[0-*]:     Threshold temperature in mC
> +               |---threshold[0-*]_hyst:Optional hysteresis value in mC
> +
> +3.2: For Thermal Cooling Devices
> +       /sys/class/thermal/cooling_device[0-*]:
> +               |---type:               Type of the cooling device
> +               |---max_state:          Maximum throttle state of the cdev
> +               |---cur_state:          Current throttle state of the cdev
> +
> +3.3: For Thermal Zones
> +       /sys/class/thermal/zone[0-*]:
> +               |---name:               Name of the thermal
> +               |---sensorX:            Symlink to ../sensorX
> +               |---cdevY:              Symlink to ../cdevY
> +               |---thermal_trip:       trip point values for sensors
> +               |---thermal_map:        mapping info between sensors and cdevs
> +
> +3.4: For Thermal Trip
> +       This attribute represents the trip point values for all sensors
> +       present in the thermal zone. All values are in mC.
> +       /sys/class/thermal/zoneX/thermal_trip/sensorY:
> +               |---hot:                hot trip point value
> +               |---critical:           critical trip point value
> +               |---passive:            list of passive trip point values
> +               |---active:             list of active trip point values
> +
> +3.5: For Thermal Map
> +       Each attribute represents the mapping/binding information between
> +       a sensor and a cdev, together with a trip type.
> +       /sys/class/thermal/zoneX/thermal_map/:
> +               |---mapX:               mapping information
> +       A typical map entry is like below:
> +
> +       trip_type  sensor  cdev  trip_mask  weight(s)
> +       passive    cpu     proc  0x03       50 30
> +       active     cpu     fan0  0x03       50 70
> +
> +       The trip mask is a bit string; if 'n' th bit is set, then for
> +       trip point 'n' this cdev is throttled with the given weight[n].
> --
> 1.7.9.5
> 

RE: [PATCH 6/9] Thermal: Add Documentation to new APIs

[R, Durgadoss]

> -----Original Message-----
> From: Wei Ni [mailto:wni@nvidia.com]
> Sent: Monday, January 07, 2013 2:10 PM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valentin@ti.com; hongbo.zhang@linaro.org
> Subject: Re: [PATCH 6/9] Thermal: Add Documentation to new APIs
> 
> On 01/07/2013 03:13 PM, Durgadoss R wrote:
> > This patch adds Documentation for the new APIs
> > introduced in this patch set. The documentation
> > also has a model sysfs structure for reference.
> >
> > Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
> > ---
> >  Documentation/thermal/sysfs-api2.txt |  248
> ++++++++++++++++++++++++++++++++++
> >  1 file changed, 248 insertions(+)
> >  create mode 100644 Documentation/thermal/sysfs-api2.txt
> >
> > diff --git a/Documentation/thermal/sysfs-api2.txt
> b/Documentation/thermal/sysfs-api2.txt
> > new file mode 100644
> > index 0000000..ffd0402
> > --- /dev/null
> > +++ b/Documentation/thermal/sysfs-api2.txt
> > @@ -0,0 +1,248 @@
> > +Thermal Framework
> > +-----------------
> > +
> > +Written by Durgadoss R <durgadoss.r@intel.com>
> > +Copyright (c) 2012 Intel Corporation
> > +
> > +Created on: 4 November 2012
> > +Updated on: 18 December 2012
> > +
> > +0. Introduction
> > +---------------
> > +The Linux thermal framework provides a set of interfaces for thermal
> > +sensors and thermal cooling devices (fan, processor...) to register
> > +with the thermal management solution and to be a part of it.
> > +
> > +This document focuses on how to enable new thermal sensors and
> cooling
> > +devices to participate in thermal management. This solution is intended
> > +to be 'light-weight' and platform/architecture independent. Any thermal
> > +sensor/cooling device should be able to use the infrastructure easily.
> > +
> > +The goal of thermal framework is to expose the thermal sensor/zone and
> > +cooling device attributes in a consistent way. This will help the
> > +thermal governors to make use of the information to manage platform
> > +thermals efficiently.
> > +
> > +The thermal sensor source file can be generic (can be any sensor driver,
> > +in any subsystem). This driver will use the sensor APIs and register with
> > +thermal framework to participate in platform Thermal management. This
> > +does not (and should not) know about which zone it belongs to, or any
> > +other information about platform thermals. A sensor driver is a
> standalone
> > +piece of code, which can optionally register with thermal framework.
> > +
> > +However, for any platform, there should be a platformX_thermal.c file,
> > +which will know about the platform thermal characteristics (like how many
> > +sensors, zones, cooling devices, etc.. And how they are related to each
> other
> > +i.e the mapping information). Only in this file, the zone level APIs should
> > +be used, in which case the file will have all information required to attach
> > +various sensors to a particular zone.
> > +
> > +This way, we can have one platform level thermal file, which can support
> > +multiple platforms (may be)using the same set of sensors (but)binded in
> > +a different way. This file can get the platform thermal information
> > +through Firmware, ACPI tables, device tree etc.
> > +
> > +Unfortunately, today we don't have many drivers that can be clearly
> > +differentiated as 'sensor_file.c' and 'platform_thermal_file.c'.
> > +But very soon we will need/have. The reason I am saying this is because
> > +we are seeing a lot of chip drivers, starting to use thermal framework,
> > +and we should keep it really light-weight for them to do so.
> > +
> > +An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver
> > +In one platform this sensor can belong to 'ZoneA' and in another the
> > +same can belong to 'ZoneB'. But, emc1403.c does not really care about
> > +where does it belong. It just reports temperature.
> > +
> > +1. Terminology
> > +--------------
> > +This section describes the terminology used in the rest of this
> > +document as well as the thermal framework code.
> > +
> > +thermal_sensor: Hardware that can report temperature of a particular
> > +               spot in the platform, where it is placed. The temperature
> > +               reported by the sensor is the 'real' temperature reported
> > +               by the hardware.
> > +thermal_zone:  A virtual area on the device, that gets heated up. It may
> > +               have one or more thermal sensors attached to it.
> > +cooling_device:        Any component that can help in reducing the
> temperature of
> > +               a 'hot spot' either by reducing its performance (passive
> > +               cooling) or by other means(Active cooling E.g. Fan)
> > +
> > +trip_points:   Various temperature levels for each sensor. As of now, we
> > +               have four levels namely active, passive, hot and critical.
> > +               Hot and critical trip point support only one value whereas
> > +               active and passive can have any number of values. These
> > +               temperature values can come from platform data, and are
> > +               exposed through sysfs in a consistent manner. Stand-alone
> > +               thermal sensor drivers are not expected to know these values.
> > +               These values are RO.
> > +thresholds:    These are programmable temperature limits, on reaching
> which
> > +               the thermal sensor generates an interrupt. The framework is
> > +               notified about this interrupt to take appropriate action.
> > +               There can be as many number of thresholds as that of the
> > +               hardware supports. These values are RW.
> 
> Hi,
> When generate interrupt, we could call something like
> notify_thermal_framework(), is it right? but it just notify the
> framework, how to notify the platform driver? I think the platform
> driver will wish to update the limited values when interrupt occur.
> Will we have a thermal zone fops like ops.notify()?
> I noticed there have "struct thermal_zone *ops" in the thermal_zone
> structure, will it be used for callback?

Yes, you are right. I missed adding a .notify() call back to thermal_zone ops.
I will wait to see if we get more comments on this version of the patches.
If so, will fix this in v3. Otherwise, will submit a patch, once these
patches make it to Rui's tree. Hope this works for you :-)

Thanks,
Durga

Re: [PATCH 6/9] Thermal: Add Documentation to new APIs

[Wei Ni]

On 01/07/2013 04:53 PM, R, Durgadoss wrote:
>> -----Original Message-----
>> From: Wei Ni [mailto:wni@nvidia.com]
>> Sent: Monday, January 07, 2013 2:10 PM
>> To: R, Durgadoss
>> Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
>> eduardo.valentin@ti.com; hongbo.zhang@linaro.org
>> Subject: Re: [PATCH 6/9] Thermal: Add Documentation to new APIs
>>
>> On 01/07/2013 03:13 PM, Durgadoss R wrote:
>>> This patch adds Documentation for the new APIs
>>> introduced in this patch set. The documentation
>>> also has a model sysfs structure for reference.
>>>
>>> Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
>>> ---
>>>  Documentation/thermal/sysfs-api2.txt |  248
>> ++++++++++++++++++++++++++++++++++
>>>  1 file changed, 248 insertions(+)
>>>  create mode 100644 Documentation/thermal/sysfs-api2.txt
>>>
>>> diff --git a/Documentation/thermal/sysfs-api2.txt
>> b/Documentation/thermal/sysfs-api2.txt
>>> new file mode 100644
>>> index 0000000..ffd0402
>>> --- /dev/null
>>> +++ b/Documentation/thermal/sysfs-api2.txt
>>> @@ -0,0 +1,248 @@
>>> +Thermal Framework
>>> +-----------------
>>> +
>>> +Written by Durgadoss R <durgadoss.r@intel.com>
>>> +Copyright (c) 2012 Intel Corporation
>>> +
>>> +Created on: 4 November 2012
>>> +Updated on: 18 December 2012
>>> +
>>> +0. Introduction
>>> +---------------
>>> +The Linux thermal framework provides a set of interfaces for thermal
>>> +sensors and thermal cooling devices (fan, processor...) to register
>>> +with the thermal management solution and to be a part of it.
>>> +
>>> +This document focuses on how to enable new thermal sensors and
>> cooling
>>> +devices to participate in thermal management. This solution is intended
>>> +to be 'light-weight' and platform/architecture independent. Any thermal
>>> +sensor/cooling device should be able to use the infrastructure easily.
>>> +
>>> +The goal of thermal framework is to expose the thermal sensor/zone and
>>> +cooling device attributes in a consistent way. This will help the
>>> +thermal governors to make use of the information to manage platform
>>> +thermals efficiently.
>>> +
>>> +The thermal sensor source file can be generic (can be any sensor driver,
>>> +in any subsystem). This driver will use the sensor APIs and register with
>>> +thermal framework to participate in platform Thermal management. This
>>> +does not (and should not) know about which zone it belongs to, or any
>>> +other information about platform thermals. A sensor driver is a
>> standalone
>>> +piece of code, which can optionally register with thermal framework.
>>> +
>>> +However, for any platform, there should be a platformX_thermal.c file,
>>> +which will know about the platform thermal characteristics (like how many
>>> +sensors, zones, cooling devices, etc.. And how they are related to each
>> other
>>> +i.e the mapping information). Only in this file, the zone level APIs should
>>> +be used, in which case the file will have all information required to attach
>>> +various sensors to a particular zone.
>>> +
>>> +This way, we can have one platform level thermal file, which can support
>>> +multiple platforms (may be)using the same set of sensors (but)binded in
>>> +a different way. This file can get the platform thermal information
>>> +through Firmware, ACPI tables, device tree etc.
>>> +
>>> +Unfortunately, today we don't have many drivers that can be clearly
>>> +differentiated as 'sensor_file.c' and 'platform_thermal_file.c'.
>>> +But very soon we will need/have. The reason I am saying this is because
>>> +we are seeing a lot of chip drivers, starting to use thermal framework,
>>> +and we should keep it really light-weight for them to do so.
>>> +
>>> +An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver
>>> +In one platform this sensor can belong to 'ZoneA' and in another the
>>> +same can belong to 'ZoneB'. But, emc1403.c does not really care about
>>> +where does it belong. It just reports temperature.
>>> +
>>> +1. Terminology
>>> +--------------
>>> +This section describes the terminology used in the rest of this
>>> +document as well as the thermal framework code.
>>> +
>>> +thermal_sensor: Hardware that can report temperature of a particular
>>> +               spot in the platform, where it is placed. The temperature
>>> +               reported by the sensor is the 'real' temperature reported
>>> +               by the hardware.
>>> +thermal_zone:  A virtual area on the device, that gets heated up. It may
>>> +               have one or more thermal sensors attached to it.
>>> +cooling_device:        Any component that can help in reducing the
>> temperature of
>>> +               a 'hot spot' either by reducing its performance (passive
>>> +               cooling) or by other means(Active cooling E.g. Fan)
>>> +
>>> +trip_points:   Various temperature levels for each sensor. As of now, we
>>> +               have four levels namely active, passive, hot and critical.
>>> +               Hot and critical trip point support only one value whereas
>>> +               active and passive can have any number of values. These
>>> +               temperature values can come from platform data, and are
>>> +               exposed through sysfs in a consistent manner. Stand-alone
>>> +               thermal sensor drivers are not expected to know these values.
>>> +               These values are RO.
>>> +thresholds:    These are programmable temperature limits, on reaching
>> which
>>> +               the thermal sensor generates an interrupt. The framework is
>>> +               notified about this interrupt to take appropriate action.
>>> +               There can be as many number of thresholds as that of the
>>> +               hardware supports. These values are RW.
>>
>> Hi,
>> When generate interrupt, we could call something like
>> notify_thermal_framework(), is it right? but it just notify the
>> framework, how to notify the platform driver? I think the platform
>> driver will wish to update the limited values when interrupt occur.
>> Will we have a thermal zone fops like ops.notify()?
>> I noticed there have "struct thermal_zone *ops" in the thermal_zone
>> structure, will it be used for callback?
> 
> Yes, you are right. I missed adding a .notify() call back to thermal_zone ops.
> I will wait to see if we get more comments on this version of the patches.
> If so, will fix this in v3. Otherwise, will submit a patch, once these
> patches make it to Rui's tree. Hope this works for you :-)

Got it, thanks :)

Wei.

RE: [PATCH 6/9] Thermal: Add Documentation to new APIs

[Mattias NILSSON1]

Hi Durgadoss, Rui, all,

Please see some questions inline below from a user space thermal control loop point of view. I should maybe have tagged this as QUESTIONS but relates pretty well to the sysfs documentation so I hope you excuse me for addressing the topic in this thread.

Btw, let me introduce myself as this is my first appearance on the list: I work on ST-Ericsson with thermal SW architecture in our mobile platform projects.

Best regards
Mattias Nilsson

> -----Original Message-----
> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> owner@vger.kernel.org] On Behalf Of Durgadoss R
> Sent: den 7 januari 2013 08:13
> To: rui.zhang@intel.com; linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; eduardo.valentin@ti.com;
> hongbo.zhang@linaro.org; wni@nvidia.com; Durgadoss R
> Subject: [PATCH 6/9] Thermal: Add Documentation to new APIs
>
> This patch adds Documentation for the new APIs introduced in this patch set.
> The documentation also has a model sysfs structure for reference.
>
> Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
> ---
>  Documentation/thermal/sysfs-api2.txt |  248
> ++++++++++++++++++++++++++++++++++
>  1 file changed, 248 insertions(+)
>  create mode 100644 Documentation/thermal/sysfs-api2.txt
>
> diff --git a/Documentation/thermal/sysfs-api2.txt
> b/Documentation/thermal/sysfs-api2.txt
> new file mode 100644
> index 0000000..ffd0402
> --- /dev/null
> +++ b/Documentation/thermal/sysfs-api2.txt
> @@ -0,0 +1,248 @@
> +Thermal Framework
> +-----------------
> +
> +Written by Durgadoss R <durgadoss.r@intel.com> Copyright (c) 2012 Intel
> +Corporation
> +
> +Created on: 4 November 2012
> +Updated on: 18 December 2012
> +
> +0. Introduction
> +---------------
> +The Linux thermal framework provides a set of interfaces for thermal
> +sensors and thermal cooling devices (fan, processor...) to register
> +with the thermal management solution and to be a part of it.
> +
> +This document focuses on how to enable new thermal sensors and cooling
> +devices to participate in thermal management. This solution is intended
> +to be 'light-weight' and platform/architecture independent. Any thermal
> +sensor/cooling device should be able to use the infrastructure easily.
> +
> +The goal of thermal framework is to expose the thermal sensor/zone and
> +cooling device attributes in a consistent way. This will help the
> +thermal governors to make use of the information to manage platform
> +thermals efficiently.
> +
> +The thermal sensor source file can be generic (can be any sensor
> +driver, in any subsystem). This driver will use the sensor APIs and
> +register with thermal framework to participate in platform Thermal
> +management. This does not (and should not) know about which zone it
> +belongs to, or any other information about platform thermals. A sensor
> +driver is a standalone piece of code, which can optionally register with
> thermal framework.
> +
> +However, for any platform, there should be a platformX_thermal.c file,
> +which will know about the platform thermal characteristics (like how
> +many sensors, zones, cooling devices, etc.. And how they are related to
> +each other i.e the mapping information). Only in this file, the zone
> +level APIs should be used, in which case the file will have all
> +information required to attach various sensors to a particular zone.
> +
> +This way, we can have one platform level thermal file, which can
> +support multiple platforms (may be)using the same set of sensors
> +(but)binded in a different way. This file can get the platform thermal
> +information through Firmware, ACPI tables, device tree etc.
> +
> +Unfortunately, today we don't have many drivers that can be clearly
> +differentiated as 'sensor_file.c' and 'platform_thermal_file.c'.
> +But very soon we will need/have. The reason I am saying this is because
> +we are seeing a lot of chip drivers, starting to use thermal framework,
> +and we should keep it really light-weight for them to do so.
> +
> +An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver In
> +one platform this sensor can belong to 'ZoneA' and in another the same
> +can belong to 'ZoneB'. But, emc1403.c does not really care about where
> +does it belong. It just reports temperature.

I miss some information on not just the API but how the user space control is intended to work. To my understanding user space control is based around the use of the user space governor for notifications on kernel defined trip points (active or passive types only), or will that change by your current work?

The governor is an attribute of the zone rather than the trip points so for me that means that for a sensor that is shared between a kernel control zone and a user space zone, we need two zones defined. Is that correctly understood?

Is it an active decision to have the governor on zone level rather than on a per trip level (also see my below questions)?


> +
> +1. Terminology
> +--------------
> +This section describes the terminology used in the rest of this
> +document as well as the thermal framework code.
> +
> +thermal_sensor: Hardware that can report temperature of a particular
> +             spot in the platform, where it is placed. The
> temperature
> +             reported by the sensor is the 'real' temperature
> reported
> +             by the hardware.
> +thermal_zone:        A virtual area on the device, that gets heated
> up. It may
> +             have one or more thermal sensors attached to
> it.
> +cooling_device:      Any component that can help in reducing the
> temperature of
> +             a 'hot spot' either by reducing its performance
> (passive
> +             cooling) or by other means(Active cooling E.g.
> Fan)
> +
> +trip_points: Various temperature levels for each sensor. As of now, we
> +             have four levels namely active, passive, hot and
> critical.
> +             Hot and critical trip point support only one value
> whereas
> +             active and passive can have any number of
> values. These
> +             temperature values can come from platform
> data, and are
> +             exposed through sysfs in a consistent manner.
> Stand-alone
> +             thermal sensor drivers are not expected to
> know these values.
> +             These values are RO.
> +thresholds:  These are programmable temperature limits, on reaching
> which
> +             the thermal sensor generates an interrupt. The
> framework is
> +             notified about this interrupt to take appropriate
> action.
> +             There can be as many number of thresholds as
> that of the
> +             hardware supports. These values are RW.
> +
> +thermal_map: This provides the mapping (aka binding)
> information between
> +             various sensors and cooling devices in a
> particular zone.
> +             Typically, this also comes from platform data;
> Stand-alone
> +             sensor drivers or cooling device drivers are not
> expected
> +             to know these mapping information.
> +
> +2. Thermal framework APIs
> +-------------------------
> +2.1: For Thermal Sensors
> +2.1.1 thermal_sensor_register:
> +     This function creates a new sensor directory under
> /sys/class/thermal/
> +     as sensor[0-*]. This API is expected to be called by thermal
> sensor
> +     drivers. These drivers may or may not be in thermal
> subsystem. This
> +     function returns a thermal_sensor structure on success and
> appropriate
> +     error on failure.
> +
> +     name: Name of the sensor
> +     count: Number of programmable thresholds associated with
> this sensor
> +     devdata: Device private data
> +     ops: Thermal sensor callbacks
> +             .get_temp: obtain the current temperature of
> the sensor
> +             .get_trend: obtain the trend of the sensor
> +             .get_threshold: get a particular threshold
> temperature
> +             .set_threshold: set a particular threshold
> temperature
> +             .get_hyst: get hysteresis value associated with a
> threshold
> +             .set_hyst: set hysteresis value associated with a
> threshold
> +
> +2.1.2 thermal_sensor_unregister:
> +     This function deletes the sensor directory under
> /sys/class/thermal/
> +     for the given sensor. Thermal sensor drivers may call this API
> +     during the driver's 'exit' routine.
> +
> +     ts: Thermal sensor that has to be unregistered
> +
> +2.1.3 enable_sensor_thresholds:
> +     This function creates 'threshold[0-*]' attributes under a
> particular
> +     sensorX directory. These values are RW. This function is called
> by
> +     the sensr driver only if the sensor supports interrupt
> mechanism.
> +
> +     ts: Thermal sensor for which thresholds have to be enabled
> +     num_thresholds: Number of thresholds supported by the
> sensor
> +
> +2.2: For Cooling Devices
> +2.2.1 thermal_cooling_device_register:
> +     This function adds a new thermal cooling device
> (fan/processor/...)
> +     to /sys/class/thermal/ folder as cooling_device[0-*]. This
> function
> +     is expected to be called by cooling device drivers that may be
> +     present in other subsystems also.
> +
> +     name: the cooling device name
> +     devdata: device private data
> +     ops: thermal cooling devices callbacks
> +     .get_max_state: get the Maximum throttle state of the cooling
> device
> +     .get_cur_state: get the Current throttle state of the cooling
> device
> +     .set_cur_state: set the Current throttle state of the cooling
> device
> +
> +2.2.2 thermal_cooling_device_unregister:
> +     This function deletes the given cdev entry form
> /sys/class/thermal;
> +     and also cleans all the symlinks referred from various zones.
> +
> +     cdev: Cooling device to be unregistered
> +
> +2.3: For Thermal Zones
> +2.3.1 create_thermal_zone:
> +     This function adds a new 'zone' under /sys/class/thermal/
> +     directory as zone[0-*]. This zone has at least one thermal
> +     sensor and at most MAX_SENSORS_PER_ZONE number of
> sensors
> +     attached to it. Similarly, this zone has at least one cdev
> +     and at most MAX_CDEVS_PER_ZONE number of cdevs
> attached to it.
> +     Both the MAX_*_PER_ZONE values are configurable, through
> +     Kconfig option(during 'menuconfig').
> +
> +     name: Name of the thermal zone
> +     devdata: Device private data
> +
> +2.3.2 add_sensor_to_zone
> +     This function adds a 'sensorX' entry under /sys/class/thermal/
> +     zoneY/ directory. This 'sensorX' is a symlink to the actual
> +     sensor entry under /sys/class/thermal/. Correspondingly, the
> +     method remove_sensor_from_zone deletes the symlink.
> +
> +     tz: thermal zone structure
> +     ts: thermal sensor structure
> +
> +2.3.3 add_cdev_to_zone
> +     This function adds a 'cdevX' entry under /sys/class/thermal/
> +     zoneY/ directory. This 'cdevX' is a symlink to the actual
> +     cdev entry under /sys/class/thermal/. Correspondingly, the
> +     method remove_cdev_from_zone deletes the symlink.
> +
> +     tz: thermal zone structure
> +     cdev: thermal cooling device structure
> +
> +2.4 For Thermal Trip
> +2.4.1 add_sensor_trip_info
> +     This function adds trip point information for the given sensor,
> +     (under a given zone) under
> /sys/class/thermal/zoneX/thermal_trip/
> +     This API creates 4 sysfs attributes namely active, passive, hot,
> +     and critical. Each of these hold one or more trip point
> temperature
> +     values, as provided from platform data.
> +
> +     tz: thermal zone structure
> +     ts: thermal sensor to which the trip points are attached
> +     trip: trip point structure. Usually obtained from platform data
> +
> +2.5 For Thermal Map
> +2.5.1 add_map_entry
> +     This function adds a 'map[0-*]' sysfs attribute under
> +     /sys/class/thermal/zoneX/thermal_map/. Each map holds a
> space
> +     separated list of values, that specify the binding relationship
> +     between a sensor and a cdev in the given zone. The map
> structure
> +     is typically obtained as platform data. For example, through
> +     ACPI tables, SFI tables, Device tree etc.
> +
> +     tz: thermal zone to which a 'map' is being added
> +     map: thermal_map structure
> +
> +3. Sysfs attributes structure
> +-----------------------------
> +Thermal sysfs attributes will be represented under /sys/class/thermal.


Adding the access information here too as in the previous documentation (RO/RW).


> +
> +3.1: For Thermal Sensors
> +     /sys/class/thermal/sensor[0-*]:
> +             |---type:               Name of the
> thermal sensor
> +             |---temp_input:
>       Current temperature in mC
> +             |---threshold[0-*]:     Threshold
> temperature in mC
> +             |---threshold[0-*]_hyst:Optional hysteresis
> value in mC
> +
> +3.2: For Thermal Cooling Devices
> +     /sys/class/thermal/cooling_device[0-*]:
> +             |---type:               Type of the cooling
> device
> +             |---max_state:
>       Maximum throttle state of the cdev
> +             |---cur_state:          Current throttle
> state of the cdev
> +
> +3.3: For Thermal Zones

With the below, how do user space know which thermal zones that are governed by the user space governor and that may be ok to manipulate trip point temps for (vs potentially kernel managed thermal zones with trip points with RW access on the temp node)?

> +     /sys/class/thermal/zone[0-*]:
> +             |---name:               Name of the
> thermal
> +             |---sensorX:            Symlink to
> ../sensorX
> +             |---cdevY:              Symlink to ../cdevY
> +             |---thermal_trip:       trip point values for
> sensors
> +             |---thermal_map:        mapping info
> between sensors and cdevs
> +


> +3.4: For Thermal Trip
> +     This attribute represents the trip point values for all sensors
> +     present in the thermal zone. All values are in mC.

How do these trip point types relate to user space management (only active/passive really relevant as the user space governor only act on those)? Actually, what is the reason for having a separate management of hot/critical compared to the active/passive governed setup? Couldn't the trip type be encapsulated in the governors (if that is moved to a per trip level and not per zone)? As a newcomer I feel I may have missed something essential here...

Also, I don't see any nodes indicating status ("trip point is active"). So how is user space intended to make use of the notification from the user space governor? Poll all the zones for temp at each notification? Any reason for not implementing something like the alarm nodes in hwmon also in the thermal framework?

> +     /sys/class/thermal/zoneX/thermal_trip/sensorY:
> +             |---hot:                hot trip point value
> +             |---critical:           critical trip point
> value
> +             |---passive:            list of passive trip
> point values
> +             |---active:             list of active trip
> point values
> +
> +3.5: For Thermal Map
> +     Each attribute represents the mapping/binding information
> between
> +     a sensor and a cdev, together with a trip type.
> +     /sys/class/thermal/zoneX/thermal_map/:
> +             |---mapX:               mapping
> information
> +     A typical map entry is like below:
> +
> +     trip_type  sensor  cdev  trip_mask  weight(s)
> +     passive    cpu     proc  0x03       50 30
> +     active     cpu     fan0  0x03       50 70
> +
> +     The trip mask is a bit string; if 'n' th bit is set, then for
> +     trip point 'n' this cdev is throttled with the given weight[n].
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

[PATCH 7/9] Thermal: Make PER_ZONE values configurable

[Durgadoss R]

This patch makes MAX_SENSORS_PER_ZONE and
MAX_CDEVS_PER_ZONE values configurable. The
default value is 1, and range is 1-12.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/thermal/Kconfig |   14 ++++++++++++++
 include/linux/thermal.h |    6 +++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index d96da07..c5ba3340 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -15,6 +15,20 @@ menuconfig THERMAL
 
 if THERMAL
 
+config THERMAL_MAX_SENSORS_PER_ZONE
+	int "Maximum number of sensors allowed per thermal zone"
+	default 1
+	range 1 12
+	---help---
+	  Specify the number of sensors allowed per zone
+
+config THERMAL_MAX_CDEVS_PER_ZONE
+	int "Maximum number of cooling devices allowed per thermal zone"
+	default 1
+	range 1 12
+	---help---
+	  Specify the number of cooling devices allowed per zone
+
 config THERMAL_HWMON
 	bool
 	depends on HWMON=y || HWMON=THERMAL
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 187fadb..cf19fba 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -50,9 +50,9 @@
 /* Default Thermal Governor: Does Linear Throttling */
 #define DEFAULT_THERMAL_GOVERNOR	"step_wise"
 
-#define MAX_SENSORS_PER_ZONE		5
-
-#define MAX_CDEVS_PER_ZONE		5
+/* Maximum number of sensors/cdevs per zone, defined through Kconfig */
+#define MAX_SENSORS_PER_ZONE	CONFIG_THERMAL_MAX_SENSORS_PER_ZONE
+#define MAX_CDEVS_PER_ZONE	CONFIG_THERMAL_MAX_CDEVS_PER_ZONE
 
 /* If we map each sensor with every possible cdev for a zone */
 #define MAX_MAPS_PER_ZONE	(MAX_SENSORS_PER_ZONE * MAX_CDEVS_PER_ZONE)
-- 
1.7.9.5

Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[Greg KH]

On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
> This patch makes MAX_SENSORS_PER_ZONE and
> MAX_CDEVS_PER_ZONE values configurable. The
> default value is 1, and range is 1-12.

Why would we ever want to change this?  Why make this configurable at
all, how is a distro supposed to set this value?

Shouldn't it be specified from the driver itself?

thanks,

greg k-h

RE: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[R, Durgadoss]

Hi Greg,

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Tuesday, January 08, 2013 12:54 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> 
> On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
> > This patch makes MAX_SENSORS_PER_ZONE and
> > MAX_CDEVS_PER_ZONE values configurable. The
> > default value is 1, and range is 1-12.
> 
> Why would we ever want to change this?  Why make this configurable at
> all, how is a distro supposed to set this value?
> 
> Shouldn't it be specified from the driver itself?

These are platform level parameters, that can differ for various platforms.
(Mostly due to board design and thermistor layouts). Stand-alone thermal
sensor drivers are not (need not be) aware of these values.
That's why these values are made configurable.

Thanks,
Durga

Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[Greg KH]

On Wed, Jan 09, 2013 at 09:12:29AM +0000, R, Durgadoss wrote:
> Hi Greg,
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Tuesday, January 08, 2013 12:54 AM
> > To: R, Durgadoss
> > Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> > Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> > 
> > On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
> > > This patch makes MAX_SENSORS_PER_ZONE and
> > > MAX_CDEVS_PER_ZONE values configurable. The
> > > default value is 1, and range is 1-12.
> > 
> > Why would we ever want to change this?  Why make this configurable at
> > all, how is a distro supposed to set this value?
> > 
> > Shouldn't it be specified from the driver itself?
> 
> These are platform level parameters, that can differ for various platforms.
> (Mostly due to board design and thermistor layouts). Stand-alone thermal
> sensor drivers are not (need not be) aware of these values.

Ok, and how does anyone know how to set them properly?

> That's why these values are made configurable.

Pushing work onto other people, without telling them what they need to
do, isn't nice.  Please, either make it auto-configurable, or don't make
it configurable at all.  As it is, this is useless for a distro, or any
"normal" user, right?

If these are platform specific things, shouldn't they be defined in the
platform data for the hardware?

thanks,

greg k-h

RE: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[R, Durgadoss]

Hi Greg,

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Wednesday, January 09, 2013 10:30 PM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> 
> On Wed, Jan 09, 2013 at 09:12:29AM +0000, R, Durgadoss wrote:
> > Hi Greg,
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Tuesday, January 08, 2013 12:54 AM
> > > To: R, Durgadoss
> > > Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> > > Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> > >
> > > On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
> > > > This patch makes MAX_SENSORS_PER_ZONE and
> > > > MAX_CDEVS_PER_ZONE values configurable. The
> > > > default value is 1, and range is 1-12.
> > >
> > > Why would we ever want to change this?  Why make this configurable at
> > > all, how is a distro supposed to set this value?
> > >
> > > Shouldn't it be specified from the driver itself?
> >
> > These are platform level parameters, that can differ for various platforms.
> > (Mostly due to board design and thermistor layouts). Stand-alone thermal
> > sensor drivers are not (need not be) aware of these values.
> 
> Ok, and how does anyone know how to set them properly?
> 
> > That's why these values are made configurable.
> 
> Pushing work onto other people, without telling them what they need to
> do, isn't nice.  Please, either make it auto-configurable, or don't make
> it configurable at all.  As it is, this is useless for a distro, or any
> "normal" user, right?

These values are for OEM's to configure according to their platform design.
So, not making them configurable won't be good IMHO.

But, as you said, for normal users, it does not matter; so they can
leave it as it is, which will set it to the default value (i.e 1).

Thanks,
Durga

Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[Greg KH]

On Thu, Jan 10, 2013 at 12:43:16PM +0000, R, Durgadoss wrote:
> Hi Greg,
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Wednesday, January 09, 2013 10:30 PM
> > To: R, Durgadoss
> > Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> > Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> > 
> > On Wed, Jan 09, 2013 at 09:12:29AM +0000, R, Durgadoss wrote:
> > > Hi Greg,
> > >
> > > > -----Original Message-----
> > > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > > Sent: Tuesday, January 08, 2013 12:54 AM
> > > > To: R, Durgadoss
> > > > Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > eduardo.valentin@ti.com; hongbo.zhang@linaro.org; wni@nvidia.com
> > > > Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> > > >
> > > > On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
> > > > > This patch makes MAX_SENSORS_PER_ZONE and
> > > > > MAX_CDEVS_PER_ZONE values configurable. The
> > > > > default value is 1, and range is 1-12.
> > > >
> > > > Why would we ever want to change this?  Why make this configurable at
> > > > all, how is a distro supposed to set this value?
> > > >
> > > > Shouldn't it be specified from the driver itself?
> > >
> > > These are platform level parameters, that can differ for various platforms.
> > > (Mostly due to board design and thermistor layouts). Stand-alone thermal
> > > sensor drivers are not (need not be) aware of these values.
> > 
> > Ok, and how does anyone know how to set them properly?
> > 
> > > That's why these values are made configurable.
> > 
> > Pushing work onto other people, without telling them what they need to
> > do, isn't nice.  Please, either make it auto-configurable, or don't make
> > it configurable at all.  As it is, this is useless for a distro, or any
> > "normal" user, right?
> 
> These values are for OEM's to configure according to their platform design.
> So, not making them configurable won't be good IMHO.

Ok, but you are guaranteeing that the same kernel can not work on
multiple platforms, which is something that people have been working
very hard to solve.

So again, please make this a platform data field, or autoconfigurable,
and not a kernel build time configuration option, that isn't acceptable
anymore.

thanks,

greg k-h

[PATCH 8/9] Thermal: Add ABI Documentation for sysfs interfaces

[Durgadoss R]

This patch adds Documentation for ABI's introduced
for thermal subsystem (under /sys/class/thermal/).

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 Documentation/ABI/testing/sysfs-class-thermal |   93 +++++++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-thermal

diff --git a/Documentation/ABI/testing/sysfs-class-thermal b/Documentation/ABI/testing/sysfs-class-thermal
new file mode 100644
index 0000000..d1a450e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-thermal
@@ -0,0 +1,93 @@
+What:		/sys/class/thermal/sensorX/temp
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Exposes 'temperature' of a thermal sensor in mC
+Users:		Kernel/User space thermal governors
+
+What:		/sys/class/thermal/sensorX/name
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Name of the thermal sensor
+Users:		Kernel/User space thermal governors
+
+What:		/sys/class/thermal/sensorX/thresholdY
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Programmable threshold (in terms of mC). On reaching
+		this, the thermal governors may take action to control
+		temperature.
+Users:		Kernel/User space thermal governors
+
+What:		/sys/class/thermal/zoneX/name
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Name of the thermal zone.
+Users:		Kernel/User space thermal governors
+
+What:		/sys/class/thermal/zoneX/sensorY
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Symlink to a sensor associated with this zone.
+Users:		User space thermal governors or applications
+
+What:		/sys/class/thermal/zoneX/cooling_deviceY
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Symlink to a cooling device associated with this zone.
+Users:		User space thermal governors or applications
+
+What:		/sys/class/thermal/zoneX/sensorY_trip_active
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Space separated list of active trip points for 'sensorY'
+		in 'zoneX' (in mC).
+Users:		Kernel/User space thermal governors
+
+What:		/sys/class/thermal/zoneX/sensorY_trip_passive
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Space separated list of passive trip points for 'sensorY'
+		in 'zoneX' (in mC).
+Users:		Kernel/User space thermal governors
+
+What:		/sys/class/thermal/zoneX/sensorY_trip_hot
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Hot trip point for 'sensorY' in 'zoneX' (in mC).
+Users:		Kernel/User space thermal governors
+
+What:		/sys/class/thermal/zoneX/sensorY_trip_critical
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Critical trip point for 'sensorY' in 'zoneX' (in mC).
+Users:		Kernel/User space thermal governors
+
+What:		/sys/class/thermal/zoneX/mapY
+Date:		January 2013
+KernelVersion:	3.8
+Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
+Description:
+		Mapping information between a sensor and a cooling device
+		in 'zoneX'. See Documentation/thermal/sysfs-api2.txt for more
+		information on this interface.
+Users:		Kernel/User space thermal governors
-- 
1.7.9.5

Re: [PATCH 8/9] Thermal: Add ABI Documentation for sysfs interfaces

[Pavel Machek]

On Mon 2013-01-07 12:43:25, Durgadoss R wrote:
> This patch adds Documentation for ABI's introduced
> for thermal subsystem (under /sys/class/thermal/).

So... we have deciCelsius and deciKelvin in ACPI (IIRC) and miliCelsius here.

Perhaps using deciCelsius to be consistent with ACPI would be nice?

What do lm_sensors use?
									Pavel
> index 0000000..d1a450e
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-thermal
> @@ -0,0 +1,93 @@
> +What:		/sys/class/thermal/sensorX/temp
> +Date:		January 2013
> +KernelVersion:	3.8
> +Contact:	Linux PM Mailing list <linux-pm@vger.kernel.org>
> +Description:
> +		Exposes 'temperature' of a thermal sensor in mC
> +Users:		Kernel/User space thermal governors
> +

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

[PATCH 9/9] Thermal: Dummy driver used for testing

[Durgadoss R]

This patch has a dummy driver that can be used for
testing purposes. This patch is not for merge.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/thermal/Kconfig        |    5 +
 drivers/thermal/Makefile       |    3 +
 drivers/thermal/thermal_test.c |  329 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 337 insertions(+)
 create mode 100644 drivers/thermal/thermal_test.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index c5ba3340..3b92a76 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -136,4 +136,9 @@ config DB8500_CPUFREQ_COOLING
 	  bound cpufreq cooling device turns active to set CPU frequency low to
 	  cool down the CPU.
 
+config THERMAL_TEST
+	tristate "test driver"
+	help
+	  Enable this to test the thermal framework.
+
 endif
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index d8da683..02c3edb 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -18,3 +18,6 @@ obj-$(CONFIG_RCAR_THERMAL)	+= rcar_thermal.o
 obj-$(CONFIG_EXYNOS_THERMAL)	+= exynos_thermal.o
 obj-$(CONFIG_DB8500_THERMAL)	+= db8500_thermal.o
 obj-$(CONFIG_DB8500_CPUFREQ_COOLING)	+= db8500_cpufreq_cooling.o
+
+# dummy driver for testing
+obj-$(CONFIG_THERMAL_TEST)	+= thermal_test.o
diff --git a/drivers/thermal/thermal_test.c b/drivers/thermal/thermal_test.c
new file mode 100644
index 0000000..137b562
--- /dev/null
+++ b/drivers/thermal/thermal_test.c
@@ -0,0 +1,329 @@
+/*
+ * thermal_test.c - This driver can be used to test Thermal
+ *			   Framework changes. Not specific to any
+ *			   platform. Fills the log buffer generously ;)
+ *
+ * Copyright (C) 2012 Intel Corporation
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * 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; version 2 of the License.
+ *
+ * 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.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * Author: Durgadoss R <durgadoss.r@intel.com>
+ */
+
+#define pr_fmt(fmt)  "thermal_test: " fmt
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/param.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/pm.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+#define MAX_THERMAL_ZONES	2
+#define MAX_THERMAL_SENSORS	2
+#define MAX_COOLING_DEVS	4
+#define NUM_THRESHOLDS		3
+
+static struct ts_data {
+	int curr_temp;
+	int flag;
+} ts_data;
+
+int active_trips[10] = {100, 90, 80, 70, 60, 50, 40, 30, 20, 10};
+int passive_trips[5] = {100, 90, 60, 50, 40};
+int wts[5] = {50, 50, 50, 50, 40};
+
+static struct platform_device *pdev;
+static unsigned long cur_cdev_state = 2;
+static struct thermal_sensor *ts, *ts1;
+static struct thermal_zone *tz;
+static struct thermal_cooling_device *cdev;
+
+static long thermal_thresholds[NUM_THRESHOLDS] = {30000, 40000, 50000};
+
+static struct thermal_trip_point trip = {
+	.hot = 90,
+	.crit = 100,
+	.num_passive_trips = 5,
+	.passive_trips = passive_trips,
+	.num_active_trips = 10,
+	.active_trips = active_trips,
+	.active_trip_mask = 0xCFF,
+};
+
+static struct thermal_trip_point trip1 = {
+	.hot = 95,
+	.crit = 125,
+	.num_passive_trips = 0,
+	.passive_trips = passive_trips,
+	.num_active_trips = 6,
+	.active_trips = active_trips,
+	.active_trip_mask = 0xFF,
+};
+
+static struct thermal_map map = {
+	.trip_type = THERMAL_TRIP_PASSIVE,
+	.sensor_name = "ts",
+	.cdev_name = "cdev",
+	.num_weights = 5,
+	.trip_mask = 0x0F,
+	.weights = wts,
+};
+
+static int read_cur_state(struct thermal_cooling_device *cdev,
+			unsigned long *state)
+{
+	*state = cur_cdev_state;
+	return 0;
+}
+
+static int write_cur_state(struct thermal_cooling_device *cdev,
+			unsigned long state)
+{
+	cur_cdev_state = state;
+	return 0;
+}
+
+static int read_max_state(struct thermal_cooling_device *cdev,
+			unsigned long *state)
+{
+	*state = 5;
+	return 0;
+}
+
+static int read_curr_temp(struct thermal_sensor *ts, long *temp)
+{
+	*temp = ts_data.curr_temp;
+	return 0;
+}
+
+static ssize_t
+flag_show(struct device *dev, struct device_attribute *devattr, char *buf)
+{
+	return sprintf(buf, "%d\n", ts_data.flag);
+}
+
+static ssize_t
+flag_store(struct device *dev, struct device_attribute *attr,
+		    const char *buf, size_t count)
+{
+	long flag;
+
+	if (kstrtol(buf, 10, &flag))
+		return -EINVAL;
+
+	ts_data.flag = flag;
+
+	if (flag == 0) {
+		thermal_sensor_unregister(ts);
+		ts = NULL;
+		pr_err("thermal_sensor_unregister (ts) done\n");
+	} else if (flag == 1) {
+		thermal_sensor_unregister(ts1);
+		ts1 = NULL;
+		pr_err("thermal_sensor_unregister (ts1) done\n");
+	} else if (flag == 2) {
+		thermal_cooling_device_unregister(cdev);
+		cdev = NULL;
+		pr_err("cdev unregister (cdev) done\n");
+	} else if (flag == 3) {
+		if (tz)
+			remove_thermal_zone(tz);
+		tz = NULL;
+		pr_err("removed thermal zone\n");
+	}
+
+	return count;
+}
+
+static ssize_t
+temp_show(struct device *dev, struct device_attribute *devattr, char *buf)
+{
+	return sprintf(buf, "%d\n", ts_data.curr_temp);
+}
+
+static int read_threshold(struct thermal_sensor *ts, int indx, long *val)
+{
+	if (indx < 0 || indx >= NUM_THRESHOLDS)
+		return -EINVAL;
+
+	*val = thermal_thresholds[indx];
+	return 0;
+}
+
+static int write_threshold(struct thermal_sensor *ts, int indx, long val)
+{
+	if (indx < 0 || indx >= NUM_THRESHOLDS)
+		return -EINVAL;
+
+	thermal_thresholds[indx] = val;
+	return 0;
+}
+
+static ssize_t
+temp_store(struct device *dev, struct device_attribute *attr,
+		    const char *buf, size_t count)
+{
+	long temp;
+
+	if (kstrtol(buf, 10, &temp))
+		return -EINVAL;
+
+	ts_data.curr_temp = temp;
+	return count;
+}
+
+static struct thermal_sensor_ops ts_ops = {
+	.get_temp = read_curr_temp,
+	.get_threshold = read_threshold,
+	.set_threshold = write_threshold,
+};
+
+static struct thermal_sensor_ops ts1_ops = {
+	.get_temp = read_curr_temp,
+	.get_threshold = read_threshold,
+	.set_threshold = write_threshold,
+};
+
+static struct thermal_cooling_device_ops cdev_ops = {
+	.get_cur_state = read_cur_state,
+	.set_cur_state = write_cur_state,
+	.get_max_state = read_max_state,
+};
+
+static DEVICE_ATTR(test_temp, S_IRUGO | S_IWUSR, temp_show, temp_store);
+static DEVICE_ATTR(sensor_enable, S_IRUGO | S_IWUSR, flag_show, flag_store);
+
+static int thermal_test_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	ts_data.curr_temp = 30000;
+	ts_data.flag = 1;
+
+	ts = thermal_sensor_register("ts", NUM_THRESHOLDS, &ts_ops, &ts_data);
+	if (!ts) {
+		pr_err("thermal_sensor_register failed:\n");
+		return -EINVAL;
+	}
+
+	ts1 = thermal_sensor_register("ts1", NUM_THRESHOLDS, &ts1_ops, NULL);
+
+	cdev = thermal_cooling_device_register("cdev", NULL, &cdev_ops);
+	if (!cdev) {
+		pr_err("cdev_register failed:\n");
+		return -EINVAL;
+	}
+
+	device_create_file(&pdev->dev, &dev_attr_test_temp);
+	device_create_file(&pdev->dev, &dev_attr_sensor_enable);
+
+	/* Create a zone */
+	tz = create_thermal_zone("myZone", NULL);
+	if (!tz) {
+		pr_err("create_thermal_zone failed:\n");
+		return -EINVAL;
+	}
+
+	pr_err("Zone created successfully..\n");
+
+	ret = add_sensor_to_zone(tz, ts);
+	if (ret) {
+		pr_err("add_sensor_to_zone failed:%d\n", ret);
+		return ret;
+	}
+
+	ret = add_sensor_to_zone(tz, ts1);
+	pr_err("add_sensor (ts1) ret_val: %d\n", ret);
+
+	ret = add_cdev_to_zone(tz, cdev);
+	pr_err("add_cdev_to_zone (cdev) ret_val: %d\n", ret);
+
+	ret = add_sensor_trip_info(tz, ts, &trip);
+	ret = add_sensor_trip_info(tz, ts1, &trip1);
+	pr_err("add_sensor_trip_info (ts) ret_val: %d\n", ret);
+
+	ret = add_map_entry(tz, &map);
+	pr_err("add_map_entry (ts) ret_val: %d\n", ret);
+
+	return 0;
+}
+
+static int thermal_test_remove(struct platform_device *pdev)
+{
+	device_remove_file(&pdev->dev, &dev_attr_test_temp);
+	device_remove_file(&pdev->dev, &dev_attr_sensor_enable);
+
+	return 0;
+}
+
+/*********************************************************************
+ *		Driver initialization and finalization
+ *********************************************************************/
+
+#define DRIVER_NAME "thermal_test"
+
+static const struct platform_device_id therm_id_table[] = {
+	{ DRIVER_NAME, 1 },
+};
+
+static struct platform_driver thermal_test_driver = {
+	.driver = {
+		.name = DRIVER_NAME,
+		.owner = THIS_MODULE,
+	},
+	.probe = thermal_test_probe,
+	.remove = __devexit_p(thermal_test_remove),
+	.id_table = therm_id_table,
+};
+
+static int __init thermal_test_init(void)
+{
+	int ret;
+
+	ret = platform_driver_register(&thermal_test_driver);
+	if (ret) {
+		pr_err("platform driver register failed:%d\n", ret);
+		return ret;
+	}
+
+	pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
+	if (IS_ERR(pdev)) {
+		ret = PTR_ERR(pdev);
+		pr_err("platform device register failed:%d\n", ret);
+		platform_driver_unregister(&thermal_test_driver);
+	}
+
+	return ret;
+}
+
+static void __exit thermal_test_exit(void)
+{
+	pr_err("in thermal_test_exit\n");
+	platform_device_unregister(pdev);
+	platform_driver_unregister(&thermal_test_driver);
+}
+
+module_init(thermal_test_init);
+module_exit(thermal_test_exit);
+
+MODULE_AUTHOR("Durgadoss R <durgadoss.r@intel.com>");
+MODULE_DESCRIPTION("A dummy driver to test Thermal Framework");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

Re: [PATCH 9/9] Thermal: Dummy driver used for testing

[Greg KH]

On Mon, Jan 07, 2013 at 12:43:26PM +0530, Durgadoss R wrote:
> + * 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.

Unless you wish to track the office movements of the FSF for the next
40+ years, never include this in the code, it's useless.

thanks,

greg k-h

Re: [PATCHv2 0/9] Thermal Framework Enhancements

[Wei Ni]

On 01/07/2013 03:13 PM, Durgadoss R wrote:
> This patch set is a v2 of the previous versions submitted here:
> [v1]:  https://lkml.org/lkml/2012/12/18/108 
> [RFC]: https://patchwork.kernel.org/patch/1758921/
> 
> This patch set is based on Rui's -thermal tree, and is
> tested on a Core-i5 and an Atom netbook.
> 
> Changes Since v1:
>  * Removed kobject creation for thermal_trip and thermal_map
>    nodes as per Greg-KH's comments.
>  * Added ABI Documentation under 'testing'.
>  * Modified the GET_INDEX macro to be more linux-like, thanks
>    to Joe Perches.
>  * Added get_[sensor/cdev]_by_name APIs to thermal.h
> 
> This series contains 9 patches:
> Patch 1/9: Creates new sensor level APIs
> Patch 2/9: Creates new zone level APIs. The existing tzd structure is
>            kept as such for clarity and compatibility purposes.
> Patch 3/9: Creates functions to add/remove a cdev to/from a zone. The
>            existing tcd structure need not be modified.
> Patch 4/9: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
> 	   under /sys/class/thermal/zoneY/. This exposes various trip
>            points for sensorX present in zoneY.
> Patch 5/9: Adds mapX sysfs node. It is a compact representation
>            of the binding relationship between a sensor and a cdev,
>            within a zone.
> Patch 6/9: Creates Documentation for the new APIs. A new file is
>            created for clarity. Final goal is to merge with the existing
>            file or refactor the files, as whatever seems appropriate.
> Patch 7/9: Make PER ZONE values configurable through Kconfig
> Patch 8/9: Add ABI documentation for sysfs interfaces introduced in this patch.
> Patch 9/9: A dummy driver that can be used for testing. This is not for merge.
> 
> Thanks to Greg-KH, Hongbo Zhang and Joe Perches for their comments on v1.
> 
> Durgadoss R (9):
>   Thermal: Create sensor level APIs
>   Thermal: Create zone level APIs
>   Thermal: Add APIs to bind cdev to new zone structure
>   Thermal: Add trip point sysfs nodes for sensor
>   Thermal: Create 'mapX' sysfs node for a zone
>   Thermal: Add Documentation to new APIs
>   Thermal: Make PER_ZONE values configurable
>   Thermal: Add ABI Documentation for sysfs interfaces
>   Thermal: Dummy driver used for testing
> 
>  Documentation/ABI/testing/sysfs-class-thermal |   93 +++
>  Documentation/thermal/sysfs-api2.txt          |  248 +++++++
>  drivers/thermal/Kconfig                       |   19 +
>  drivers/thermal/Makefile                      |    3 +
>  drivers/thermal/thermal_sys.c                 |  881 +++++++++++++++++++++++++
>  drivers/thermal/thermal_test.c                |  315 +++++++++
>  include/linux/thermal.h                       |  117 +++-
>  7 files changed, 1675 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
>  create mode 100644 Documentation/thermal/sysfs-api2.txt
>  create mode 100644 drivers/thermal/thermal_test.c

Hi, Durgadoss
Did you think about how to use this framework for the device tree.
for example, we add a dt node for the lm90 sensor:
lm90: lm90@4c {
    compatible = "lm90";
    ......;
};
This sensor driver can register two sensors to the thermal framework,
which are named as "lm90_remote" and "lm90_local". If we want to add the
"lm90_remote" in the thermal zone, we could add nodes like this:
xxx-thermal {
    compatible = "xxxx";
    sensor-name = "lm90_remote";
    ......;
}
then the xxx-thermal driver can read the sensor-name and use
get_sensor_by_name() to get the snesor.

But this is not the canonical DT way. We think it's better to use
pandle+args to get that sensor, something like this
lm90: lm90@4c {
    compatible = "lm90";
    #sensor-cells = <1>;
    ......;
};
xxx-thermal {
    compatible = "xxxx";
    sensors = <&lm90 0>;
    ......;
}
If we want to use this way, we need to add new APIs to decode it.

Do you have any idea for this issue?

Thanks.
Wei.
> 

Re: [PATCHv2 0/9] Thermal Framework Enhancements

[Wei Ni]

On 01/07/2013 03:13 PM, Durgadoss R wrote:
> This patch set is a v2 of the previous versions submitted here:
> [v1]:  https://lkml.org/lkml/2012/12/18/108 
> [RFC]: https://patchwork.kernel.org/patch/1758921/
> 
> This patch set is based on Rui's -thermal tree, and is
> tested on a Core-i5 and an Atom netbook.
> 
> Changes Since v1:
>  * Removed kobject creation for thermal_trip and thermal_map
>    nodes as per Greg-KH's comments.
>  * Added ABI Documentation under 'testing'.
>  * Modified the GET_INDEX macro to be more linux-like, thanks
>    to Joe Perches.
>  * Added get_[sensor/cdev]_by_name APIs to thermal.h

Hi, Durgadoss and Rui
Will these patches be merged to next branch? or will you send out next
version?
I wish to use this new framework, could I send out patches for RFC based
on this serial patches?

Thanks.
Wei.

> 
> This series contains 9 patches:
> Patch 1/9: Creates new sensor level APIs
> Patch 2/9: Creates new zone level APIs. The existing tzd structure is
>            kept as such for clarity and compatibility purposes.
> Patch 3/9: Creates functions to add/remove a cdev to/from a zone. The
>            existing tcd structure need not be modified.
> Patch 4/9: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
> 	   under /sys/class/thermal/zoneY/. This exposes various trip
>            points for sensorX present in zoneY.
> Patch 5/9: Adds mapX sysfs node. It is a compact representation
>            of the binding relationship between a sensor and a cdev,
>            within a zone.
> Patch 6/9: Creates Documentation for the new APIs. A new file is
>            created for clarity. Final goal is to merge with the existing
>            file or refactor the files, as whatever seems appropriate.
> Patch 7/9: Make PER ZONE values configurable through Kconfig
> Patch 8/9: Add ABI documentation for sysfs interfaces introduced in this patch.
> Patch 9/9: A dummy driver that can be used for testing. This is not for merge.
> 
> Thanks to Greg-KH, Hongbo Zhang and Joe Perches for their comments on v1.
> 
> Durgadoss R (9):
>   Thermal: Create sensor level APIs
>   Thermal: Create zone level APIs
>   Thermal: Add APIs to bind cdev to new zone structure
>   Thermal: Add trip point sysfs nodes for sensor
>   Thermal: Create 'mapX' sysfs node for a zone
>   Thermal: Add Documentation to new APIs
>   Thermal: Make PER_ZONE values configurable
>   Thermal: Add ABI Documentation for sysfs interfaces
>   Thermal: Dummy driver used for testing
> 
>  Documentation/ABI/testing/sysfs-class-thermal |   93 +++
>  Documentation/thermal/sysfs-api2.txt          |  248 +++++++
>  drivers/thermal/Kconfig                       |   19 +
>  drivers/thermal/Makefile                      |    3 +
>  drivers/thermal/thermal_sys.c                 |  881 +++++++++++++++++++++++++
>  drivers/thermal/thermal_test.c                |  315 +++++++++
>  include/linux/thermal.h                       |  117 +++-
>  7 files changed, 1675 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
>  create mode 100644 Documentation/thermal/sysfs-api2.txt
>  create mode 100644 drivers/thermal/thermal_test.c
> 

RE: [PATCHv2 0/9] Thermal Framework Enhancements

[R, Durgadoss]

Hi Wei,

> -----Original Message-----
> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> owner@vger.kernel.org] On Behalf Of Wei Ni
> Sent: Monday, February 04, 2013 11:10 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valentin@ti.com; hongbo.zhang@linaro.org
> Subject: Re: [PATCHv2 0/9] Thermal Framework Enhancements
> 
> On 01/07/2013 03:13 PM, Durgadoss R wrote:
> > This patch set is a v2 of the previous versions submitted here:
> > [v1]:  https://lkml.org/lkml/2012/12/18/108
> > [RFC]: https://patchwork.kernel.org/patch/1758921/
> >
> > This patch set is based on Rui's -thermal tree, and is
> > tested on a Core-i5 and an Atom netbook.
> >
> > Changes Since v1:
> >  * Removed kobject creation for thermal_trip and thermal_map
> >    nodes as per Greg-KH's comments.
> >  * Added ABI Documentation under 'testing'.
> >  * Modified the GET_INDEX macro to be more linux-like, thanks
> >    to Joe Perches.
> >  * Added get_[sensor/cdev]_by_name APIs to thermal.h
> 
> Hi, Durgadoss and Rui
> Will these patches be merged to next branch? or will you send out next
> version?

Yes, I have to send the v3, with some small changes on the patch 5/9
(map sysfs node..) and others won't have any changes.

> I wish to use this new framework, could I send out patches for RFC based
> on this serial patches?

So, if your patch set does not need 5/9, you can send your RFC.

Thanks,
Durga

> 
> Thanks.
> Wei.
> 
> >
> > This series contains 9 patches:
> > Patch 1/9: Creates new sensor level APIs
> > Patch 2/9: Creates new zone level APIs. The existing tzd structure is
> >            kept as such for clarity and compatibility purposes.
> > Patch 3/9: Creates functions to add/remove a cdev to/from a zone. The
> >            existing tcd structure need not be modified.
> > Patch 4/9: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
> > 	   under /sys/class/thermal/zoneY/. This exposes various trip
> >            points for sensorX present in zoneY.
> > Patch 5/9: Adds mapX sysfs node. It is a compact representation
> >            of the binding relationship between a sensor and a cdev,
> >            within a zone.
> > Patch 6/9: Creates Documentation for the new APIs. A new file is
> >            created for clarity. Final goal is to merge with the existing
> >            file or refactor the files, as whatever seems appropriate.
> > Patch 7/9: Make PER ZONE values configurable through Kconfig
> > Patch 8/9: Add ABI documentation for sysfs interfaces introduced in this
> patch.
> > Patch 9/9: A dummy driver that can be used for testing. This is not for
> merge.
> >
> > Thanks to Greg-KH, Hongbo Zhang and Joe Perches for their comments on
> v1.
> >
> > Durgadoss R (9):
> >   Thermal: Create sensor level APIs
> >   Thermal: Create zone level APIs
> >   Thermal: Add APIs to bind cdev to new zone structure
> >   Thermal: Add trip point sysfs nodes for sensor
> >   Thermal: Create 'mapX' sysfs node for a zone
> >   Thermal: Add Documentation to new APIs
> >   Thermal: Make PER_ZONE values configurable
> >   Thermal: Add ABI Documentation for sysfs interfaces
> >   Thermal: Dummy driver used for testing
> >
> >  Documentation/ABI/testing/sysfs-class-thermal |   93 +++
> >  Documentation/thermal/sysfs-api2.txt          |  248 +++++++
> >  drivers/thermal/Kconfig                       |   19 +
> >  drivers/thermal/Makefile                      |    3 +
> >  drivers/thermal/thermal_sys.c                 |  881
> +++++++++++++++++++++++++
> >  drivers/thermal/thermal_test.c                |  315 +++++++++
> >  include/linux/thermal.h                       |  117 +++-
> >  7 files changed, 1675 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
> >  create mode 100644 Documentation/thermal/sysfs-api2.txt
> >  create mode 100644 drivers/thermal/thermal_test.c
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html