Re: [RFC, 2/5] Thermal: thermal framework registration failure case cleanup
On 26-03-2013 12:26, Zhang Rui wrote:
Signed-off-by: Zhang Rui rui.zh...@intel.com
Could you please describe why these resource releases are not required
anymore? Even on thermal_exit.
---
drivers/thermal/thermal_core.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 5b7863a..845ed6e 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1863,13 +1863,9 @@ static int __init thermal_init(void)
int result = 0;
result = class_register(thermal_class);
- if (result) {
- idr_destroy(thermal_tz_idr);
- idr_destroy(thermal_cdev_idr);
- mutex_destroy(thermal_idr_lock);
- mutex_destroy(thermal_list_lock);
+ if (result)
return result;
- }
+
result = genetlink_init();
return result;
}
@@ -1877,10 +1873,6 @@ static int __init thermal_init(void)
static void __exit thermal_exit(void)
{
class_unregister(thermal_class);
- idr_destroy(thermal_tz_idr);
- idr_destroy(thermal_cdev_idr);
- mutex_destroy(thermal_idr_lock);
- mutex_destroy(thermal_list_lock);
genetlink_exit();
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,3/5] Thermal: build thermal governors into thermal_sys module
Hi Rui,
On 26-03-2013 12:26, Zhang Rui wrote:
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/Makefile |6 +++---
drivers/thermal/fair_share.c | 15 ++-
drivers/thermal/step_wise.c| 16 ++--
drivers/thermal/thermal_core.c | 36 ++--
drivers/thermal/thermal_core.h | 25 +
drivers/thermal/user_space.c | 15 ++-
include/linux/thermal.h|1 -
7 files changed, 68 insertions(+), 46 deletions(-)
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index b2009bd..b7fffc7 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -6,9 +6,9 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
thermal_sys-y += thermal_core.o
# governors
-obj-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
-obj-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
-obj-$(CONFIG_THERMAL_GOV_USER_SPACE) += user_space.o
+thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
+thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
+thermal_sys-$(CONFIG_THERMAL_GOV_USER_SPACE) += user_space.o
# cpufreq cooling
obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
diff --git a/drivers/thermal/fair_share.c b/drivers/thermal/fair_share.c
index 792479f..944ba2f 100644
--- a/drivers/thermal/fair_share.c
+++ b/drivers/thermal/fair_share.c
@@ -22,9 +22,6 @@
* ~~
*/
-#define pr_fmt(fmt) KBUILD_MODNAME : fmt
-
-#include linux/module.h
#include linux/thermal.h
#include thermal_core.h
@@ -111,23 +108,15 @@ static int fair_share_throttle(struct thermal_zone_device
*tz, int trip)
static struct thermal_governor thermal_gov_fair_share = {
.name = fair_share,
.throttle = fair_share_throttle,
- .owner = THIS_MODULE,
};
-static int __init thermal_gov_fair_share_init(void)
+int thermal_gov_fair_share_register(void)
{
return thermal_register_governor(thermal_gov_fair_share);
}
-static void __exit thermal_gov_fair_share_exit(void)
+void thermal_gov_fair_share_unregister(void)
{
thermal_unregister_governor(thermal_gov_fair_share);
}
-/* This should load after thermal framework */
-fs_initcall(thermal_gov_fair_share_init);
-module_exit(thermal_gov_fair_share_exit);
-
-MODULE_AUTHOR(Durgadoss R);
-MODULE_DESCRIPTION(A simple weight based thermal throttling governor);
-MODULE_LICENSE(GPL);
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 407cde3..a6c9666 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -22,9 +22,6 @@
* ~~
*/
-#define pr_fmt(fmt) KBUILD_MODNAME : fmt
-
-#include linux/module.h
#include linux/thermal.h
#include thermal_core.h
@@ -180,23 +177,14 @@ static int step_wise_throttle(struct thermal_zone_device
*tz, int trip)
static struct thermal_governor thermal_gov_step_wise = {
.name = step_wise,
.throttle = step_wise_throttle,
- .owner = THIS_MODULE,
};
-static int __init thermal_gov_step_wise_init(void)
+int thermal_gov_step_wise_register(void)
{
return thermal_register_governor(thermal_gov_step_wise);
}
-static void __exit thermal_gov_step_wise_exit(void)
+void thermal_gov_step_wise_unregister(void)
{
thermal_unregister_governor(thermal_gov_step_wise);
}
-
-/* This should load after thermal framework */
-fs_initcall(thermal_gov_step_wise_init);
-module_exit(thermal_gov_step_wise_exit);
-
-MODULE_AUTHOR(Durgadoss R);
-MODULE_DESCRIPTION(A step-by-step thermal throttling governor);
-MODULE_LICENSE(GPL);
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 845ed6e..eac9745 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1858,22 +1858,54 @@ static inline int genetlink_init(void) { return 0; }
static inline void genetlink_exit(void) {}
#endif /* !CONFIG_NET */
+static int __init thermal_register_governors(void)
+{
+ int result;
+
+ result = thermal_gov_step_wise_register();
+ if (result)
+ return result;
+
+ result = thermal_gov_fair_share_register();
+ if (result)
+ return result;
+
+ result = thermal_gov_user_space_register();
+
+ return result;
Just do a
+ return thermal_gov_user_space_register();
Or better, add err messages in the fail path.
+}
+
+static void __exit thermal_unregister_governors(void)
+{
+ thermal_gov_step_wise_unregister();
+ thermal_gov_fair_share_unregister();
+ thermal_gov_user_space_unregister();
+}
+
static int __init thermal_init(void)
{
- int result = 0;
+ int result;
+
+ result = thermal_register_governors();
+ if (result)
+
Re: [RFC,4/5] Thermal: governor API cleanup
On 26-03-2013 12:26, Zhang Rui wrote:
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/thermal_core.c |2 --
drivers/thermal/thermal_core.h |2 ++
include/linux/thermal.h|3 ---
Please also clean Documentation/thermal/sysfs_api.txt
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index eac9745..f645757 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -99,7 +99,6 @@ int thermal_register_governor(struct thermal_governor
*governor)
return err;
}
-EXPORT_SYMBOL_GPL(thermal_register_governor);
void thermal_unregister_governor(struct thermal_governor *governor)
{
@@ -127,7 +126,6 @@ void thermal_unregister_governor(struct thermal_governor
*governor)
mutex_unlock(thermal_governor_lock);
return;
}
-EXPORT_SYMBOL_GPL(thermal_unregister_governor);
static int get_idr(struct idr *idr, struct mutex *lock, int *id)
{
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index f84ea0f..a1f8278 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -50,6 +50,8 @@ struct thermal_instance {
struct list_head cdev_node; /* node in cdev-thermal_instances */
};
+extern int thermal_register_governor(struct thermal_governor *);
+extern void thermal_unregister_governor(struct thermal_governor *);
Does this really need to be extern?
#ifdef CONFIG_THERMAL_GOV_STEP_WISE
extern int thermal_gov_step_wise_register(void);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 2eeec01..af03ea6 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -243,9 +243,6 @@ struct thermal_instance *get_thermal_instance(struct
thermal_zone_device *,
void thermal_cdev_update(struct thermal_cooling_device *);
void notify_thermal_framework(struct thermal_zone_device *, int);
-int thermal_register_governor(struct thermal_governor *);
-void thermal_unregister_governor(struct thermal_governor *);
-
#ifdef CONFIG_NET
extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
enum events event);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/15] staging: omap-thermal fixes and ports
Hello Greg, Several compilation fixes and a couple of debugging prints added. This time I am also preparing the driver to receive fixes and patches from omapzoom. So, this series starts to port patches from omapzoom to staging area. Most of this changes are related to OMAP5 support. All these are based on linux-2.6/master. Patches are also available here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/omap-thermal-fixes https://git.gitorious.org/thermal-framework/thermal-framework.git thermal_work/omap/omap-thermal-fixes Cheers, Eduardo Valentin (12): staging: omap-thermal: standardize register nomenclature to use 'GPU' staging: omap-thermal: remove from register map soc and mode on OMAP5 staging: omap-thermal: introduce new features of OMAP54xx staging: omap-thermal: update OMAP54xx clock sources staging: omap-thermal: update feature bitfield for OMAP54xx staging: omap-thermal: remove dedicated counter register for OMAP5 staging: omap-thermal: introduze FREEZE_BIT feature staging: omap-thermal: update DT entry documentation staging: omap-thermal: add DT example for OMAP54xx devices staging: omap-thermal: Remove double conv_table reference staging: omap-thermal: name data files accordingly staging: omap-thermal: update clock prepare count Radhesh Fadnis (2): staging: omap-thermal: introduce clock feature flag staging: omap-thermal: update OMAP54xx conv_table Ruslan Ruslichenko (1): staging: omap-thermal: Add print when TSHUT temperature reached drivers/staging/omap-thermal/Makefile |4 +- drivers/staging/omap-thermal/omap-bandgap.c | 89 -- drivers/staging/omap-thermal/omap-bandgap.h | 94 +- drivers/staging/omap-thermal/omap4-thermal-data.c | 262 +++ drivers/staging/omap-thermal/omap4-thermal.c | 259 --- drivers/staging/omap-thermal/omap5-thermal-data.c | 357 + drivers/staging/omap-thermal/omap5-thermal.c | 297 - drivers/staging/omap-thermal/omap_bandgap.txt | 36 ++- 8 files changed, 794 insertions(+), 604 deletions(-) create mode 100644 drivers/staging/omap-thermal/omap4-thermal-data.c delete mode 100644 drivers/staging/omap-thermal/omap4-thermal.c create mode 100644 drivers/staging/omap-thermal/omap5-thermal-data.c delete mode 100644 drivers/staging/omap-thermal/omap5-thermal.c -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/15] staging: omap-thermal: Add print when TSHUT temperature reached
From: Ruslan Ruslichenko x0191...@ti.com
To indicate that board was shut down due to TSHUT temperature reached
it is good to print some information message before shutting down.
Signed-off-by: Ruslan Ruslichenko x0191...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index dcc1448..35b9915 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -133,6 +133,9 @@ static irqreturn_t talert_irq_handler(int irq, void *data)
/* This is the Tshut handler. Call it only if HAS(TSHUT) is set */
static irqreturn_t omap_bandgap_tshut_irq_handler(int irq, void *data)
{
+ pr_emerg(%s: TSHUT temperature reached. Needs shut down...\n,
+__func__);
+
orderly_poweroff(true);
return IRQ_HANDLED;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/15] staging: omap-thermal: introduce clock feature flag
From: Radhesh Fadnis radhesh.fad...@ti.com
The clock to Bandgap module is SW controlled on some version of
OMAP silicon (OMAP44xx). But on OMAP54xx ES2.0
onwards this is HW-Auto controlled. Hence introduce a feature flag
to use/not-to-use SW enable/disable of BG clock.
Signed-off-by: Radhesh Fadnis radhesh.fad...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 18 +-
drivers/staging/omap-thermal/omap-bandgap.h |1 +
drivers/staging/omap-thermal/omap4-thermal.c |3 +++
drivers/staging/omap-thermal/omap5-thermal.c |3 ++-
4 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 35b9915..80384ed 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -914,7 +914,9 @@ int omap_bandgap_probe(struct platform_device *pdev)
dev_err(pdev-dev, Cannot re-set clock rate. Continuing\n);
bg_ptr-clk_rate = clk_rate;
- clk_enable(bg_ptr-fclock);
+ if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL))
+ clk_enable(bg_ptr-fclock);
+
mutex_init(bg_ptr-bg_mutex);
bg_ptr-dev = pdev-dev;
@@ -982,7 +984,8 @@ int omap_bandgap_probe(struct platform_device *pdev)
return 0;
disable_clk:
- clk_disable(bg_ptr-fclock);
+ if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL))
+ clk_disable(bg_ptr-fclock);
put_clks:
clk_put(bg_ptr-fclock);
clk_put(bg_ptr-div_clk);
@@ -1012,7 +1015,8 @@ int omap_bandgap_remove(struct platform_device *pdev)
omap_bandgap_power(bg_ptr, false);
- clk_disable(bg_ptr-fclock);
+ if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL))
+ clk_disable(bg_ptr-fclock);
clk_put(bg_ptr-fclock);
clk_put(bg_ptr-div_clk);
@@ -1109,7 +1113,9 @@ static int omap_bandgap_suspend(struct device *dev)
err = omap_bandgap_save_ctxt(bg_ptr);
omap_bandgap_power(bg_ptr, false);
- clk_disable(bg_ptr-fclock);
+
+ if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL))
+ clk_disable(bg_ptr-fclock);
return err;
}
@@ -1118,7 +1124,9 @@ static int omap_bandgap_resume(struct device *dev)
{
struct omap_bandgap *bg_ptr = dev_get_drvdata(dev);
- clk_enable(bg_ptr-fclock);
+ if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL))
+ clk_enable(bg_ptr-fclock);
+
omap_bandgap_power(bg_ptr, true);
return omap_bandgap_restore_ctxt(bg_ptr);
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 2bb14bd..85e1a2f 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -384,6 +384,7 @@ struct omap_bandgap_data {
#define OMAP_BANDGAP_FEATURE_MODE_CONFIG (1 3)
#define OMAP_BANDGAP_FEATURE_COUNTER (1 4)
#define OMAP_BANDGAP_FEATURE_POWER_SWITCH (1 5)
+#define OMAP_BANDGAP_FEATURE_CLK_CTRL (1 6)
#define OMAP_BANDGAP_HAS(b, f) \
((b)-conf-features OMAP_BANDGAP_FEATURE_ ## f)
unsigned intfeatures;
diff --git a/drivers/staging/omap-thermal/omap4-thermal.c
b/drivers/staging/omap-thermal/omap4-thermal.c
index 04c02b6..732c853 100644
--- a/drivers/staging/omap-thermal/omap4-thermal.c
+++ b/drivers/staging/omap-thermal/omap4-thermal.c
@@ -69,6 +69,7 @@ omap4430_adc_to_temp[OMAP4430_ADC_END_VALUE -
OMAP4430_ADC_START_VALUE + 1] = {
/* OMAP4430 data */
const struct omap_bandgap_data omap4430_data = {
.features = OMAP_BANDGAP_FEATURE_MODE_CONFIG |
+ OMAP_BANDGAP_FEATURE_CLK_CTRL |
OMAP_BANDGAP_FEATURE_POWER_SWITCH,
.fclock_name = bandgap_fclk,
.div_ck_name = bandgap_fclk,
@@ -207,6 +208,7 @@ const struct omap_bandgap_data omap4460_data = {
OMAP_BANDGAP_FEATURE_TALERT |
OMAP_BANDGAP_FEATURE_MODE_CONFIG |
OMAP_BANDGAP_FEATURE_POWER_SWITCH |
+ OMAP_BANDGAP_FEATURE_CLK_CTRL |
OMAP_BANDGAP_FEATURE_COUNTER,
.fclock_name = bandgap_ts_fclk,
.div_ck_name = div_ts_ck,
@@ -236,6 +238,7 @@ const struct omap_bandgap_data omap4470_data = {
OMAP_BANDGAP_FEATURE_TALERT |
OMAP_BANDGAP_FEATURE_MODE_CONFIG |
OMAP_BANDGAP_FEATURE_POWER_SWITCH |
+ OMAP_BANDGAP_FEATURE_CLK_CTRL |
OMAP_BANDGAP_FEATURE_COUNTER,
.fclock_name = bandgap_ts_fclk,
.div_ck_name = div_ts_ck,
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index 2f3a498..8fca21b 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap
[PATCH 03/15] staging: omap-thermal: update OMAP54xx conv_table
From: Radhesh Fadnis radhesh.fad...@ti.com
This patch updates the ADC conversion table for OMAP5430 ES2.0 devices.
Signed-off-by: Radhesh Fadnis radhesh.fad...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.h |5 +-
drivers/staging/omap-thermal/omap5-thermal.c | 170 --
2 files changed, 105 insertions(+), 70 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 85e1a2f..a13e43a 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -210,9 +210,8 @@
#define OMAP5430_MPU_MIN_TEMP -4
#define OMAP5430_MPU_MAX_TEMP 125000
#define OMAP5430_MPU_HYST_VAL 5000
-#define OMAP5430_ADC_START_VALUE 532
-#define OMAP5430_ADC_END_VALUE 934
-
+#define OMAP5430_ADC_START_VALUE 540
+#define OMAP5430_ADC_END_VALUE 945
#define OMAP5430_GPU_TSHUT_HOT 915
#define OMAP5430_GPU_TSHUT_COLD900
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index 8fca21b..dfa0350 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -187,73 +187,109 @@ static struct temp_sensor_data
omap5430_core_temp_sensor_data = {
.update_int2 = 2000,
};
-static const int
-omap5430_adc_to_temp[OMAP5430_ADC_END_VALUE - OMAP5430_ADC_START_VALUE + 1] = {
- -4, -4, -4, -4, -39800, -39400, -39000, -38600,
- -38200, -37800, -37300, -36800,
- -36400, -36000, -35600, -35200, -34800, -34300, -33800, -33400, -33000,
- -32600,
- -32200, -31800, -31300, -30800, -30400, -3, -29600, -29200, -28700,
- -28200, -27800, -27400, -27000, -26600, -26200, -25700, -25200, -24800,
- -24400, -24000, -23600, -23200, -22700, -22200, -21800, -21400, -21000,
- -20600, -20200, -19700, -19200, -9300, -18400, -18000, -17600, -17200,
- -16700, -16200, -15800, -15400, -15000, -14600, -14200, -13700, -13200,
- -12800, -12400, -12000, -11600, -11200, -10700, -10200, -9800, -9400,
- -9000,
- -8600, -8200, -7700, -7200, -6800, -6400, -6000, -5600, -5200, -4800,
- -4300,
- -3800, -3400, -3000, -2600, -2200, -1800, -1300, -800, -400, 0, 400,
- 800,
- 1200, 1600, 2100, 2600, 3000, 3400, 3800, 4200, 4600, 5100, 5600, 6000,
- 6400, 6800, 7200, 7600, 8000, 8500, 9000, 9400, 9800, 10200, 10800,
- 11100,
- 11400, 11900, 12400, 12800, 13200, 13600, 14000, 14400, 14800, 15300,
- 15800,
- 16200, 16600, 17000, 17400, 17800, 18200, 18700, 19200, 19600, 2,
- 20400,
- 20800, 21200, 21600, 22100, 22600, 23000, 23400, 23800, 24200, 24600,
- 25000,
- 25400, 25900, 26400, 26800, 27200, 27600, 28000, 28400, 28800, 29300,
- 29800,
- 30200, 30600, 31000, 31400, 31800, 32200, 32600, 33100, 33600, 34000,
- 34400,
- 34800, 35200, 35600, 36000, 36400, 36800, 37300, 37800, 38200, 38600,
- 39000,
- 39400, 39800, 40200, 40600, 41100, 41600, 42000, 42400, 42800, 43200,
- 43600,
- 44000, 44400, 44800, 45300, 45800, 46200, 46600, 47000, 47400, 47800,
- 48200,
- 48600, 49000, 49500, 5, 50400, 50800, 51200, 51600, 52000, 52400,
- 52800,
- 53200, 53700, 54200, 54600, 55000, 55400, 55800, 56200, 56600, 57000,
- 57400,
- 57800, 58200, 58700, 59200, 59600, 6, 60400, 60800, 61200, 61600,
- 62000,
- 62400, 62800, 63300, 63800, 64200, 64600, 65000, 65400, 65800, 66200,
- 66600,
- 67000, 67400, 67800, 68200, 68700, 69200, 69600, 7, 70400, 70800,
- 71200,
- 71600, 72000, 72400, 72800, 73200, 73600, 74100, 74600, 75000, 75400,
- 75800,
- 76200, 76600, 77000, 77400, 77800, 78200, 78600, 79000, 79400, 79800,
- 80300,
- 80800, 81200, 81600, 82000, 82400, 82800, 83200, 83600, 84000, 84400,
- 84800,
- 85200, 85600, 86000, 86400, 86800, 87300, 87800, 88200, 88600, 89000,
- 89400,
- 89800, 90200, 90600, 91000, 91400, 91800, 92200, 92600, 93000, 93400,
- 93800,
- 94200, 94600, 95000, 95500, 96000, 96400, 96800, 97200, 97600, 98000,
- 98400,
- 98800, 99200, 99600, 10, 100400, 100800, 101200, 101600, 102000,
- 102400,
- 102800, 103200, 103600, 104000, 104400, 104800, 105200, 105600, 106100,
- 106600, 107000, 107400, 107800, 108200, 108600, 109000, 109400, 109800,
- 110200, 110600, 111000, 111400, 111800, 112200, 112600, 113000, 113400,
- 113800, 114200, 114600, 115000, 115400, 115800, 116200, 116600, 117000,
- 117400, 117800, 118200, 118600, 119000, 119400, 119800, 120200
[PATCH 04/15] staging: omap-thermal: standardize register nomenclature to use 'GPU'
In order to keep same nomenclature across the register definition,
this change will make all 'MM' suffixes to be named 'GPU'.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.h | 16
drivers/staging/omap-thermal/omap5-thermal.c |8
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index a13e43a..ef342d8 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -110,10 +110,10 @@
#define OMAP5430_MASK_HOT_CORE_MASK(1 5)
#define OMAP5430_MASK_COLD_CORE_SHIFT 4
#define OMAP5430_MASK_COLD_CORE_MASK (1 4)
-#define OMAP5430_MASK_HOT_MM_SHIFT 3
-#define OMAP5430_MASK_HOT_MM_MASK (1 3)
-#define OMAP5430_MASK_COLD_MM_SHIFT2
-#define OMAP5430_MASK_COLD_MM_MASK (1 2)
+#define OMAP5430_MASK_HOT_GPU_SHIFT3
+#define OMAP5430_MASK_HOT_GPU_MASK (1 3)
+#define OMAP5430_MASK_COLD_GPU_SHIFT 2
+#define OMAP5430_MASK_COLD_GPU_MASK(1 2)
#define OMAP5430_MASK_HOT_MPU_SHIFT1
#define OMAP5430_MASK_HOT_MPU_MASK (1 1)
#define OMAP5430_MASK_COLD_MPU_SHIFT 0
@@ -144,10 +144,10 @@
#define OMAP5430_HOT_CORE_FLAG_MASK(1 5)
#define OMAP5430_COLD_CORE_FLAG_SHIFT 4
#define OMAP5430_COLD_CORE_FLAG_MASK (1 4)
-#define OMAP5430_HOT_MM_FLAG_SHIFT 3
-#define OMAP5430_HOT_MM_FLAG_MASK (1 3)
-#define OMAP5430_COLD_MM_FLAG_SHIFT2
-#define OMAP5430_COLD_MM_FLAG_MASK (1 2)
+#define OMAP5430_HOT_GPU_FLAG_SHIFT3
+#define OMAP5430_HOT_GPU_FLAG_MASK (1 3)
+#define OMAP5430_COLD_GPU_FLAG_SHIFT 2
+#define OMAP5430_COLD_GPU_FLAG_MASK(1 2)
#define OMAP5430_HOT_MPU_FLAG_SHIFT1
#define OMAP5430_HOT_MPU_FLAG_MASK (1 1)
#define OMAP5430_COLD_MPU_FLAG_SHIFT 0
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index dfa0350..4965556 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -71,8 +71,8 @@ omap5430_gpu_temp_sensor_registers = {
.bgap_dtemp_mask = OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK,
.bgap_mask_ctrl = OMAP5430_BGAP_CTRL_OFFSET,
- .mask_hot_mask = OMAP5430_MASK_HOT_MM_MASK,
- .mask_cold_mask = OMAP5430_MASK_COLD_MM_MASK,
+ .mask_hot_mask = OMAP5430_MASK_HOT_GPU_MASK,
+ .mask_cold_mask = OMAP5430_MASK_COLD_GPU_MASK,
.bgap_mode_ctrl = OMAP5430_BGAP_COUNTER_GPU_OFFSET,
.mode_ctrl_mask = OMAP5430_REPEAT_MODE_MASK,
@@ -91,8 +91,8 @@ omap5430_gpu_temp_sensor_registers = {
.bgap_status = OMAP5430_BGAP_STATUS_OFFSET,
.status_clean_stop_mask = 0x0,
.status_bgap_alert_mask = OMAP5430_BGAP_ALERT_MASK,
- .status_hot_mask = OMAP5430_HOT_MM_FLAG_MASK,
- .status_cold_mask = OMAP5430_COLD_MM_FLAG_MASK,
+ .status_hot_mask = OMAP5430_HOT_GPU_FLAG_MASK,
+ .status_cold_mask = OMAP5430_COLD_GPU_FLAG_MASK,
.bgap_efuse = OMAP5430_FUSE_OPP_BGAP_GPU,
};
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/15] staging: omap-thermal: remove from register map soc and mode on OMAP5
On OMAP54xx ES2.0 there is no single read and only one mode: continuous
mode. For this reason, there is no point in defining register fields
for these operations.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap5-thermal.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index 4965556..32d3f878 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -27,7 +27,6 @@ static struct temp_sensor_registers
omap5430_mpu_temp_sensor_registers = {
.temp_sensor_ctrl = OMAP5430_TEMP_SENSOR_MPU_OFFSET,
.bgap_tempsoff_mask = OMAP5430_BGAP_TEMPSOFF_MASK,
- .bgap_soc_mask = OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK,
.bgap_eocz_mask = OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK,
.bgap_dtemp_mask = OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK,
@@ -35,8 +34,6 @@ omap5430_mpu_temp_sensor_registers = {
.mask_hot_mask = OMAP5430_MASK_HOT_MPU_MASK,
.mask_cold_mask = OMAP5430_MASK_COLD_MPU_MASK,
- .bgap_mode_ctrl = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
- .mode_ctrl_mask = OMAP5430_REPEAT_MODE_MASK,
.bgap_counter = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
.counter_mask = OMAP5430_COUNTER_MASK,
@@ -66,7 +63,6 @@ static struct temp_sensor_registers
omap5430_gpu_temp_sensor_registers = {
.temp_sensor_ctrl = OMAP5430_TEMP_SENSOR_GPU_OFFSET,
.bgap_tempsoff_mask = OMAP5430_BGAP_TEMPSOFF_MASK,
- .bgap_soc_mask = OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK,
.bgap_eocz_mask = OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK,
.bgap_dtemp_mask = OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK,
@@ -74,9 +70,6 @@ omap5430_gpu_temp_sensor_registers = {
.mask_hot_mask = OMAP5430_MASK_HOT_GPU_MASK,
.mask_cold_mask = OMAP5430_MASK_COLD_GPU_MASK,
- .bgap_mode_ctrl = OMAP5430_BGAP_COUNTER_GPU_OFFSET,
- .mode_ctrl_mask = OMAP5430_REPEAT_MODE_MASK,
-
.bgap_counter = OMAP5430_BGAP_COUNTER_GPU_OFFSET,
.counter_mask = OMAP5430_COUNTER_MASK,
@@ -105,7 +98,6 @@ static struct temp_sensor_registers
omap5430_core_temp_sensor_registers = {
.temp_sensor_ctrl = OMAP5430_TEMP_SENSOR_CORE_OFFSET,
.bgap_tempsoff_mask = OMAP5430_BGAP_TEMPSOFF_MASK,
- .bgap_soc_mask = OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK,
.bgap_eocz_mask = OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK,
.bgap_dtemp_mask = OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK,
@@ -113,9 +105,6 @@ omap5430_core_temp_sensor_registers = {
.mask_hot_mask = OMAP5430_MASK_HOT_CORE_MASK,
.mask_cold_mask = OMAP5430_MASK_COLD_CORE_MASK,
- .bgap_mode_ctrl = OMAP5430_BGAP_COUNTER_CORE_OFFSET,
- .mode_ctrl_mask = OMAP5430_REPEAT_MODE_MASK,
-
.bgap_counter = OMAP5430_BGAP_COUNTER_CORE_OFFSET,
.counter_mask = OMAP5430_COUNTER_MASK,
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/15] staging: omap-thermal: introduce new features of OMAP54xx
On OMAP54xx ES2.0 there are new features inside the bandgap device. This patch introduces the registers definition to access these features and adapts the data structures to map these new registers. The new features are: . SIDLE mode . Cumulative register . History buffer. . Buffer freeze bit . Buffer clear bit Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.h | 65 +- drivers/staging/omap-thermal/omap5-thermal.c | 48 +-- 2 files changed, 106 insertions(+), 7 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.h b/drivers/staging/omap-thermal/omap-bandgap.h index ef342d8..5994ebb 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.h +++ b/drivers/staging/omap-thermal/omap-bandgap.h @@ -118,6 +118,26 @@ #define OMAP5430_MASK_HOT_MPU_MASK (1 1) #define OMAP5430_MASK_COLD_MPU_SHIFT 0 #define OMAP5430_MASK_COLD_MPU_MASK(1 0) +#define OMAP5430_MASK_SIDLEMODE_SHIFT 30 +#define OMAP5430_MASK_SIDLEMODE_MASK (0x3 30) +#define OMAP5430_MASK_FREEZE_CORE_SHIFT23 +#define OMAP5430_MASK_FREEZE_CORE_MASK (1 23) +#define OMAP5430_MASK_FREEZE_GPU_SHIFT 22 +#define OMAP5430_MASK_FREEZE_GPU_MASK (1 22) +#define OMAP5430_MASK_FREEZE_MPU_SHIFT 21 +#define OMAP5430_MASK_FREEZE_MPU_MASK (1 21) +#define OMAP5430_MASK_CLEAR_CORE_SHIFT 20 +#define OMAP5430_MASK_CLEAR_CORE_MASK (1 20) +#define OMAP5430_MASK_CLEAR_GPU_SHIFT 19 +#define OMAP5430_MASK_CLEAR_GPU_MASK (1 19) +#define OMAP5430_MASK_CLEAR_MPU_SHIFT 18 +#define OMAP5430_MASK_CLEAR_MPU_MASK (1 18) +#define OMAP5430_MASK_CLEAR_ACCUM_CORE_SHIFT 17 +#define OMAP5430_MASK_CLEAR_ACCUM_CORE_MASK(1 17) +#define OMAP5430_MASK_CLEAR_ACCUM_GPU_SHIFT16 +#define OMAP5430_MASK_CLEAR_ACCUM_GPU_MASK (1 16) +#define OMAP5430_MASK_CLEAR_ACCUM_MPU_SHIFT15 +#define OMAP5430_MASK_CLEAR_ACCUM_MPU_MASK (1 15) /* BANDGAP_COUNTER */ #define OMAP5430_REPEAT_MODE_SHIFT 31 @@ -137,6 +157,18 @@ #define OMAP5430_TSHUT_COLD_SHIFT 0 #define OMAP5430_TSHUT_COLD_MASK (0x3ff 0) +/* BANDGAP_CUMUL_DTEMP_MPU */ +#define OMAP5430_CUMUL_DTEMP_MPU_SHIFT 0 +#define OMAP5430_CUMUL_DTEMP_MPU_MASK (0x 0) + +/* BANDGAP_CUMUL_DTEMP_GPU */ +#define OMAP5430_CUMUL_DTEMP_GPU_SHIFT 0 +#define OMAP5430_CUMUL_DTEMP_GPU_MASK (0x 0) + +/* BANDGAP_CUMUL_DTEMP_CORE */ +#define OMAP5430_CUMUL_DTEMP_CORE_SHIFT0 +#define OMAP5430_CUMUL_DTEMP_CORE_MASK (0x 0) + /* BANDGAP_STATUS */ #define OMAP5430_BGAP_ALERT_SHIFT 31 #define OMAP5430_BGAP_ALERT_MASK (1 31) @@ -174,6 +206,12 @@ #define OMAP5430_BGAP_COUNTER_GPU_OFFSET 0x1C0 #define OMAP5430_BGAP_THRESHOLD_GPU_OFFSET 0x1A8 #define OMAP5430_BGAP_TSHUT_GPU_OFFSET 0x1B4 +#define OMAP5430_BGAP_CUMUL_DTEMP_GPU_OFFSET 0x1C0 +#define OMAP5430_BGAP_DTEMP_GPU_0_OFFSET 0x1F4 +#define OMAP5430_BGAP_DTEMP_GPU_1_OFFSET 0x1F8 +#define OMAP5430_BGAP_DTEMP_GPU_2_OFFSET 0x1FC +#define OMAP5430_BGAP_DTEMP_GPU_3_OFFSET 0x200 +#define OMAP5430_BGAP_DTEMP_GPU_4_OFFSET 0x204 #define OMAP5430_FUSE_OPP_BGAP_MPU 0x4 #define OMAP5430_TEMP_SENSOR_MPU_OFFSET0x14C @@ -181,13 +219,26 @@ #define OMAP5430_BGAP_COUNTER_MPU_OFFSET 0x1BC #define OMAP5430_BGAP_THRESHOLD_MPU_OFFSET 0x1A4 #define OMAP5430_BGAP_TSHUT_MPU_OFFSET 0x1B0 -#define OMAP5430_BGAP_STATUS_OFFSET0x1C8 +#define OMAP5430_BGAP_CUMUL_DTEMP_MPU_OFFSET 0x1BC +#define OMAP5430_BGAP_DTEMP_MPU_0_OFFSET 0x1E0 +#define OMAP5430_BGAP_DTEMP_MPU_1_OFFSET 0x1E4 +#define OMAP5430_BGAP_DTEMP_MPU_2_OFFSET 0x1E8 +#define OMAP5430_BGAP_DTEMP_MPU_3_OFFSET 0x1EC +#define OMAP5430_BGAP_DTEMP_MPU_4_OFFSET 0x1F0 #define OMAP5430_FUSE_OPP_BGAP_CORE0x8 #define OMAP5430_TEMP_SENSOR_CORE_OFFSET 0x154 #define OMAP5430_BGAP_COUNTER_CORE_OFFSET 0x1C4 #define OMAP5430_BGAP_THRESHOLD_CORE_OFFSET0x1AC #define OMAP5430_BGAP_TSHUT_CORE_OFFSET0x1B8 +#define OMAP5430_BGAP_CUMUL_DTEMP_CORE_OFFSET 0x1C4 +#define OMAP5430_BGAP_DTEMP_CORE_0_OFFSET 0x208 +#define OMAP5430_BGAP_DTEMP_CORE_1_OFFSET 0x20C
[PATCH 07/15] staging: omap-thermal: update OMAP54xx clock sources
This patch updates the OMAP54xx data structure to use
the right clock source name for ES2.0.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap5-thermal.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index 91618fd..c8c3e6e 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -323,8 +323,8 @@ const struct omap_bandgap_data omap5430_data = {
OMAP_BANDGAP_FEATURE_MODE_CONFIG |
OMAP_BANDGAP_FEATURE_COUNTER |
OMAP_BANDGAP_FEATURE_CLK_CTRL,
- .fclock_name = ts_clk_div_ck,
- .div_ck_name = ts_clk_div_ck,
+ .fclock_name = l3instr_ts_gclk_div,
+ .div_ck_name = l3instr_ts_gclk_div,
.conv_table = omap5430_adc_to_temp,
.expose_sensor = omap_thermal_expose_sensor,
.remove_sensor = omap_thermal_remove_sensor,
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/15] staging: omap-thermal: remove dedicated counter register for OMAP5
On OMAP54xx there is only one counter register. For this reason,
each domain must use the same counter register. This patch changes
the data definition to coupe with this.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.h |5 -
drivers/staging/omap-thermal/omap5-thermal.c |6 +++---
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 5994ebb..ef5503d 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -140,8 +140,6 @@
#define OMAP5430_MASK_CLEAR_ACCUM_MPU_MASK (1 15)
/* BANDGAP_COUNTER */
-#define OMAP5430_REPEAT_MODE_SHIFT 31
-#define OMAP5430_REPEAT_MODE_MASK (1 31)
#define OMAP5430_COUNTER_SHIFT 0
#define OMAP5430_COUNTER_MASK (0xff 0)
@@ -203,7 +201,6 @@
/* 5430 - All goes relative to OPP_BGAP_GPU */
#define OMAP5430_FUSE_OPP_BGAP_GPU 0x0
#define OMAP5430_TEMP_SENSOR_GPU_OFFSET0x150
-#define OMAP5430_BGAP_COUNTER_GPU_OFFSET 0x1C0
#define OMAP5430_BGAP_THRESHOLD_GPU_OFFSET 0x1A8
#define OMAP5430_BGAP_TSHUT_GPU_OFFSET 0x1B4
#define OMAP5430_BGAP_CUMUL_DTEMP_GPU_OFFSET 0x1C0
@@ -216,7 +213,6 @@
#define OMAP5430_FUSE_OPP_BGAP_MPU 0x4
#define OMAP5430_TEMP_SENSOR_MPU_OFFSET0x14C
#define OMAP5430_BGAP_CTRL_OFFSET 0x1A0
-#define OMAP5430_BGAP_COUNTER_MPU_OFFSET 0x1BC
#define OMAP5430_BGAP_THRESHOLD_MPU_OFFSET 0x1A4
#define OMAP5430_BGAP_TSHUT_MPU_OFFSET 0x1B0
#define OMAP5430_BGAP_CUMUL_DTEMP_MPU_OFFSET 0x1BC
@@ -228,7 +224,6 @@
#define OMAP5430_FUSE_OPP_BGAP_CORE0x8
#define OMAP5430_TEMP_SENSOR_CORE_OFFSET 0x154
-#define OMAP5430_BGAP_COUNTER_CORE_OFFSET 0x1C4
#define OMAP5430_BGAP_THRESHOLD_CORE_OFFSET0x1AC
#define OMAP5430_BGAP_TSHUT_CORE_OFFSET0x1B8
#define OMAP5430_BGAP_CUMUL_DTEMP_CORE_OFFSET 0x1C4
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index 6306360..c2bfc65 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -43,7 +43,7 @@ omap5430_mpu_temp_sensor_registers = {
.mask_clear_accum_mask = OMAP5430_MASK_CLEAR_ACCUM_MPU_MASK,
- .bgap_counter = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
+ .bgap_counter = OMAP5430_BGAP_CTRL_OFFSET,
.counter_mask = OMAP5430_COUNTER_MASK,
.bgap_threshold = OMAP5430_BGAP_THRESHOLD_MPU_OFFSET,
@@ -87,7 +87,7 @@ omap5430_gpu_temp_sensor_registers = {
.mask_clear_mask = OMAP5430_MASK_CLEAR_GPU_MASK,
.mask_clear_accum_mask = OMAP5430_MASK_CLEAR_ACCUM_GPU_MASK,
- .bgap_counter = OMAP5430_BGAP_COUNTER_GPU_OFFSET,
+ .bgap_counter = OMAP5430_BGAP_CTRL_OFFSET,
.counter_mask = OMAP5430_COUNTER_MASK,
.bgap_threshold = OMAP5430_BGAP_THRESHOLD_GPU_OFFSET,
@@ -132,7 +132,7 @@ omap5430_core_temp_sensor_registers = {
.mask_clear_mask = OMAP5430_MASK_CLEAR_CORE_MASK,
.mask_clear_accum_mask = OMAP5430_MASK_CLEAR_ACCUM_CORE_MASK,
- .bgap_counter = OMAP5430_BGAP_COUNTER_CORE_OFFSET,
+ .bgap_counter = OMAP5430_BGAP_CTRL_OFFSET,
.counter_mask = OMAP5430_COUNTER_MASK,
.bgap_threshold = OMAP5430_BGAP_THRESHOLD_CORE_OFFSET,
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/15] staging: omap-thermal: introduze FREEZE_BIT feature
For ES2.0 devices, it is not guaranteed that current DTEMP
or DTEMP0 from the history buffer are going to contain
correct values, due to desynchronization between BG clk
and OCP clk.
For this reason, this patch changes the driver to first:
a. consider a feature flag, FREEZE_BIT, in order to check
it is possible to freeze the history buffer or not.
b. whenever reading the temperature, it will fetch from
DTEMP1 instead of DTEMP or DTEMP0.
This WA is applicable only for OMAP5430 ES2.0.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 60 +++---
drivers/staging/omap-thermal/omap-bandgap.h |1 +
drivers/staging/omap-thermal/omap5-thermal.c |1 +
3 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 80384ed..82ad5db 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -75,12 +75,44 @@ static int omap_bandgap_power(struct omap_bandgap *bg_ptr,
bool on)
return 0;
}
+static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id)
+{
+ struct temp_sensor_registers *tsr;
+ u32 temp, ctrl, reg;
+
+ tsr = bg_ptr-conf-sensors[id].registers;
+ reg = tsr-temp_sensor_ctrl;
+
+ if (OMAP_BANDGAP_HAS(bg_ptr, FREEZE_BIT)) {
+ ctrl = omap_bandgap_readl(bg_ptr, tsr-bgap_mask_ctrl);
+ ctrl |= tsr-mask_freeze_mask;
+ omap_bandgap_writel(bg_ptr, ctrl, tsr-bgap_mask_ctrl);
+ /*
+* In case we cannot read from cur_dtemp / dtemp_0,
+* then we read from the last valid temp read
+*/
+ reg = tsr-ctrl_dtemp_1;
+ }
+
+ /* read temperature */
+ temp = omap_bandgap_readl(bg_ptr, reg);
+ temp = tsr-bgap_dtemp_mask;
+
+ if (OMAP_BANDGAP_HAS(bg_ptr, FREEZE_BIT)) {
+ ctrl = omap_bandgap_readl(bg_ptr, tsr-bgap_mask_ctrl);
+ ctrl = ~tsr-mask_freeze_mask;
+ omap_bandgap_writel(bg_ptr, ctrl, tsr-bgap_mask_ctrl);
+ }
+
+ return temp;
+}
+
/* This is the Talert handler. Call it only if HAS(TALERT) is set */
static irqreturn_t talert_irq_handler(int irq, void *data)
{
struct omap_bandgap *bg_ptr = data;
struct temp_sensor_registers *tsr;
- u32 t_hot = 0, t_cold = 0, temp, ctrl;
+ u32 t_hot = 0, t_cold = 0, ctrl;
int i;
bg_ptr = data;
@@ -118,10 +150,6 @@ static irqreturn_t talert_irq_handler(int irq, void *data)
__func__, bg_ptr-conf-sensors[i].domain,
t_hot, t_cold);
- /* read temperature */
- temp = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
- temp = tsr-bgap_dtemp_mask;
-
/* report temperature to whom may concern */
if (bg_ptr-conf-report_temperature)
bg_ptr-conf-report_temperature(bg_ptr, i);
@@ -190,11 +218,11 @@ static int temp_sensor_unmask_interrupts(struct
omap_bandgap *bg_ptr, int id,
u32 temp, reg_val;
/* Read the current on die temperature */
- tsr = bg_ptr-conf-sensors[id].registers;
- temp = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
- temp = tsr-bgap_dtemp_mask;
+ temp = omap_bandgap_read_temp(bg_ptr, id);
+ tsr = bg_ptr-conf-sensors[id].registers;
reg_val = omap_bandgap_readl(bg_ptr, tsr-bgap_mask_ctrl);
+
if (temp t_hot)
reg_val |= tsr-mask_hot_mask;
else
@@ -625,8 +653,9 @@ int omap_bandgap_read_temperature(struct omap_bandgap
*bg_ptr, int id,
return ret;
tsr = bg_ptr-conf-sensors[id].registers;
- temp = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
- temp = tsr-bgap_dtemp_mask;
+ mutex_lock(bg_ptr-bg_mutex);
+ temp = omap_bandgap_read_temp(bg_ptr, id);
+ mutex_unlock(bg_ptr-bg_mutex);
ret |= adc_to_temp_conversion(bg_ptr, id, temp, temp);
if (ret)
@@ -694,12 +723,11 @@ omap_bandgap_force_single_read(struct omap_bandgap
*bg_ptr, int id)
temp |= 1 __ffs(tsr-bgap_soc_mask);
omap_bandgap_writel(bg_ptr, temp, tsr-temp_sensor_ctrl);
/* Wait until DTEMP is updated */
- temp = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
- temp = (tsr-bgap_dtemp_mask);
- while ((temp == 0) --counter) {
- temp = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
- temp = (tsr-bgap_dtemp_mask);
- }
+ temp = omap_bandgap_read_temp(bg_ptr, id);
+
+ while ((temp == 0) --counter)
+ temp = omap_bandgap_read_temp(bg_ptr, id);
+
/* Start of Conversion = 0 */
temp = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
temp = ~(1 __ffs(tsr-bgap_soc_mask));
diff
[PATCH 08/15] staging: omap-thermal: update feature bitfield for OMAP54xx
This patch removes from OMAP54xx the features:
. CLK_CTRL
. COUNTER
. MODE_CONFIG
Because these features are not present in OMAP54xx ES2.0
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap5-thermal.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index c8c3e6e..6306360 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -319,10 +319,7 @@ omap5430_adc_to_temp[
/* TODO : Need to update the slope/constant for ES2.0 silicon */
const struct omap_bandgap_data omap5430_data = {
.features = OMAP_BANDGAP_FEATURE_TSHUT_CONFIG |
- OMAP_BANDGAP_FEATURE_TALERT |
- OMAP_BANDGAP_FEATURE_MODE_CONFIG |
- OMAP_BANDGAP_FEATURE_COUNTER |
- OMAP_BANDGAP_FEATURE_CLK_CTRL,
+ OMAP_BANDGAP_FEATURE_TALERT,
.fclock_name = l3instr_ts_gclk_div,
.div_ck_name = l3instr_ts_gclk_div,
.conv_table = omap5430_adc_to_temp,
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/15] staging: omap-thermal: update DT entry documentation
Simple update on documentation file for DT. This patch
also adds an example for OMAP4430 and 0MAP4470, and also updated
OMAP4460's example.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap_bandgap.txt | 27 ++--
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap_bandgap.txt
b/drivers/staging/omap-thermal/omap_bandgap.txt
index 6008a14..e30dc1c 100644
--- a/drivers/staging/omap-thermal/omap_bandgap.txt
+++ b/drivers/staging/omap-thermal/omap_bandgap.txt
@@ -10,21 +10,42 @@ to the silicon temperature.
Required properties:
- compatible : Should be:
- - ti,omap4460-control-bandgap : for OMAP4460 bandgap
- - ti,omap5430-control-bandgap : for OMAP5430 bandgap
+ - ti,omap4430-bandgap : for OMAP4430 bandgap
+ - ti,omap4460-bandgap : for OMAP4460 bandgap
+ - ti,omap4470-bandgap : for OMAP4470 bandgap
+ - ti,omap5430-bandgap : for OMAP5430 bandgap
- interrupts : this entry should indicate which interrupt line
the talert signal is routed to;
Specific:
- ti,tshut-gpio : this entry should be used to inform which GPIO
line the tshut signal is routed to;
+- regs : this entry must also be specified and it is specific
+to each bandgap version, because the mapping may change from
+soc to soc, apart of depending on available features.
Example:
+OMAP4430:
+bandgap {
+ reg = 0x4a002260 0x4 0x4a00232C 0x4;
+ compatible = ti,omap4430-bandgap;
+};
+
+OMAP4460:
+bandgap {
+ reg = 0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18;
+ compatible = ti,omap4460-bandgap;
+ interrupts = 0 126 4; /* talert */
+ ti,tshut-gpio = 86;
+};
+OMAP4470:
bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4
0x4a002378 0x18;
- compatible = ti,omap4460-control-bandgap;
+ compatible = ti,omap4470-bandgap;
interrupts = 0 126 4; /* talert */
ti,tshut-gpio = 86;
};
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/15] staging: omap-thermal: add DT example for OMAP54xx devices
Update documentation with DT example for OMAP54xx devices.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap_bandgap.txt |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap_bandgap.txt
b/drivers/staging/omap-thermal/omap_bandgap.txt
index e30dc1c..a4a33d1 100644
--- a/drivers/staging/omap-thermal/omap_bandgap.txt
+++ b/drivers/staging/omap-thermal/omap_bandgap.txt
@@ -49,3 +49,12 @@ bandgap {
interrupts = 0 126 4; /* talert */
ti,tshut-gpio = 86;
};
+
+OMAP5430:
+bandgap {
+ reg = 0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c;
+ compatible = ti,omap5430-bandgap;
+};
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/15] staging: omap-thermal: Remove double conv_table reference
This patch removes from data structure the double reference of
the conversion table. It keeps the reference coming from bandgap
data definition. The patch also adapts the code accordingly.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |8
drivers/staging/omap-thermal/omap-bandgap.h |1 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 82ad5db..83f74f4 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -179,7 +179,7 @@ int adc_to_temp_conversion(struct omap_bandgap *bg_ptr, int
id, int adc_val,
if (adc_val ts_data-adc_start_val || adc_val ts_data-adc_end_val)
return -ERANGE;
- *t = bg_ptr-conv_table[adc_val - ts_data-adc_start_val];
+ *t = bg_ptr-conf-conv_table[adc_val - ts_data-adc_start_val];
return 0;
}
@@ -188,17 +188,18 @@ static int temp_to_adc_conversion(long temp, struct
omap_bandgap *bg_ptr, int i,
int *adc)
{
struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[i].ts_data;
+ const int *conv_table = bg_ptr-conf-conv_table;
int high, low, mid;
low = 0;
high = ts_data-adc_end_val - ts_data-adc_start_val;
mid = (high + low) / 2;
- if (temp bg_ptr-conv_table[low] || temp bg_ptr-conv_table[high])
+ if (temp conv_table[low] || temp conv_table[high])
return -EINVAL;
while (low high) {
- if (temp bg_ptr-conv_table[mid])
+ if (temp conv_table[mid])
high = mid - 1;
else
low = mid + 1;
@@ -911,7 +912,6 @@ int omap_bandgap_probe(struct platform_device *pdev)
goto free_irqs;
}
- bg_ptr-conv_table = bg_ptr-conf-conv_table;
for (i = 0; i bg_ptr-conf-sensor_count; i++) {
struct temp_sensor_registers *tsr;
u32 val;
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 59c9ba2..3e9072c 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -369,7 +369,6 @@ struct omap_bandgap {
struct omap_bandgap_data*conf;
struct clk *fclock;
struct clk *div_clk;
- const int *conv_table;
struct mutexbg_mutex; /* Mutex for irq and PM */
int irq;
int tshut_gpio;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/15] staging: omap-thermal: name data files accordingly
This patch simply changes the name of files containing data structure
definition.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Makefile |4 +-
drivers/staging/omap-thermal/omap4-thermal-data.c | 262 +++
drivers/staging/omap-thermal/omap4-thermal.c | 262 ---
drivers/staging/omap-thermal/omap5-thermal-data.c | 357 +
drivers/staging/omap-thermal/omap5-thermal.c | 357 -
5 files changed, 621 insertions(+), 621 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap4-thermal-data.c
delete mode 100644 drivers/staging/omap-thermal/omap4-thermal.c
create mode 100644 drivers/staging/omap-thermal/omap5-thermal-data.c
delete mode 100644 drivers/staging/omap-thermal/omap5-thermal.c
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index 091c4d2..fbd14d1 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
-omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
-omap-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal.o
+omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal-data.o
+omap-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal-data.o
diff --git a/drivers/staging/omap-thermal/omap4-thermal-data.c
b/drivers/staging/omap-thermal/omap4-thermal-data.c
new file mode 100644
index 000..732c853
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap4-thermal-data.c
@@ -0,0 +1,262 @@
+/*
+ * OMAP4 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include omap-thermal.h
+#include omap-bandgap.h
+
+/*
+ * OMAP4430 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap4430_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP4430_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4430_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask = OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mode_ctrl = OMAP4430_TEMP_SENSOR_CTRL_OFFSET,
+ .mode_ctrl_mask = OMAP4430_SINGLE_MODE_MASK,
+
+ .bgap_efuse = OMAP4430_FUSE_OPP_BGAP,
+};
+
+/* Thresholds and limits for OMAP4430 MPU temperature sensor */
+static struct temp_sensor_data omap4430_mpu_temp_sensor_data = {
+ .min_freq = OMAP4430_MIN_FREQ,
+ .max_freq = OMAP4430_MAX_FREQ,
+ .max_temp = OMAP4430_MAX_TEMP,
+ .min_temp = OMAP4430_MIN_TEMP,
+ .hyst_val = OMAP4430_HYST_VAL,
+ .adc_start_val = OMAP4430_ADC_START_VALUE,
+ .adc_end_val = OMAP4430_ADC_END_VALUE,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ * ADC code values from 530 to 923
+ */
+static const int
+omap4430_adc_to_temp[OMAP4430_ADC_END_VALUE - OMAP4430_ADC_START_VALUE + 1] = {
+ -38000, -35000, -34000, -32000, -3, -28000, -26000, -24000, -22000,
+ -2, -18000, -17000, -15000, -13000, -12000, -1, -8000, -6000,
+ -5000, -3000, -1000, 0, 2000, 3000, 5000, 6000, 8000, 1, 12000,
+ 13000, 15000, 17000, 19000, 21000, 23000, 25000, 27000, 28000, 3,
+ 32000, 33000, 35000, 37000, 38000, 4, 42000, 43000, 45000, 47000,
+ 48000, 5, 52000, 53000, 55000, 57000, 58000, 6, 62000, 64000,
+ 66000, 68000, 7, 71000, 73000, 75000, 77000, 78000, 8, 82000,
+ 83000, 85000, 87000, 88000, 9, 92000, 93000, 95000, 97000, 98000,
+ 10, 102000, 103000, 105000, 107000, 109000, 111000, 113000, 115000,
+ 117000, 118000, 12, 122000, 123000,
+};
+
+/* OMAP4430 data */
+const struct omap_bandgap_data omap4430_data = {
+ .features = OMAP_BANDGAP_FEATURE_MODE_CONFIG |
+ OMAP_BANDGAP_FEATURE_CLK_CTRL |
+ OMAP_BANDGAP_FEATURE_POWER_SWITCH,
+ .fclock_name = bandgap_fclk,
+ .div_ck_name = bandgap_fclk,
+ .conv_table = omap4430_adc_to_temp,
+ .expose_sensor = omap_thermal_expose_sensor,
+ .remove_sensor = omap_thermal_remove_sensor,
+ .sensors = {
+ {
+ .registers
[PATCH 15/15] staging: omap-thermal: update clock prepare count
This patch changes the clock management code to also update the clock prepare counter, this way we won't skip the enable/disable operation due to prepare dependencies. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index 83f74f4..d4a3788 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -943,7 +943,7 @@ int omap_bandgap_probe(struct platform_device *pdev) bg_ptr-clk_rate = clk_rate; if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_enable(bg_ptr-fclock); + clk_prepare_enable(bg_ptr-fclock); mutex_init(bg_ptr-bg_mutex); @@ -1013,7 +1013,7 @@ int omap_bandgap_probe(struct platform_device *pdev) disable_clk: if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_disable(bg_ptr-fclock); + clk_disable_unprepare(bg_ptr-fclock); put_clks: clk_put(bg_ptr-fclock); clk_put(bg_ptr-div_clk); @@ -1044,7 +1044,7 @@ int omap_bandgap_remove(struct platform_device *pdev) omap_bandgap_power(bg_ptr, false); if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_disable(bg_ptr-fclock); + clk_disable_unprepare(bg_ptr-fclock); clk_put(bg_ptr-fclock); clk_put(bg_ptr-div_clk); @@ -1143,7 +1143,7 @@ static int omap_bandgap_suspend(struct device *dev) omap_bandgap_power(bg_ptr, false); if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_disable(bg_ptr-fclock); + clk_disable_unprepare(bg_ptr-fclock); return err; } @@ -1153,7 +1153,7 @@ static int omap_bandgap_resume(struct device *dev) struct omap_bandgap *bg_ptr = dev_get_drvdata(dev); if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_enable(bg_ptr-fclock); + clk_prepare_enable(bg_ptr-fclock); omap_bandgap_power(bg_ptr, true); -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/15] staging: omap-thermal: update clock prepare count
Mike, On 27-02-2013 01:35, Mike Turquette wrote: Quoting Eduardo Valentin (2013-02-26 14:53:38) This patch changes the clock management code to also update the clock prepare counter, this way we won't skip the enable/disable operation due to prepare dependencies. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Hi Eduardo, I didn't look through the other patches in this series (or even the existing driver that is merged). With that said, I have a question: does this driver aggressively call clk_enable/clk_disable in call sites other than those listed in this patch? Not really, no. The only places it calls clk_enable/disable are those listed below. Idea is that we want to keep the sensor running all the time. There should come another patch to cover for core idle, which in that case, this driver must idle the sensor, and therefor gate the clock, otherwise core won't idle, on some OMAP versions. If so it might be a good idea to call clk_prepare_enable and clk_disable_unprepare in those location. Of course only call it if the context can sleep (e.g. not an interrupt handler). Ok. For now at least it is not the case. If the driver doesn't aggressively call enable/disable elsewhere than you can disregard my message ;-) hheeh, alright:-) thanks for your comment. Regards, Mike --- drivers/staging/omap-thermal/omap-bandgap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index 83f74f4..d4a3788 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -943,7 +943,7 @@ int omap_bandgap_probe(struct platform_device *pdev) bg_ptr-clk_rate = clk_rate; if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_enable(bg_ptr-fclock); + clk_prepare_enable(bg_ptr-fclock); mutex_init(bg_ptr-bg_mutex); @@ -1013,7 +1013,7 @@ int omap_bandgap_probe(struct platform_device *pdev) disable_clk: if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_disable(bg_ptr-fclock); + clk_disable_unprepare(bg_ptr-fclock); put_clks: clk_put(bg_ptr-fclock); clk_put(bg_ptr-div_clk); @@ -1044,7 +1044,7 @@ int omap_bandgap_remove(struct platform_device *pdev) omap_bandgap_power(bg_ptr, false); if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_disable(bg_ptr-fclock); + clk_disable_unprepare(bg_ptr-fclock); clk_put(bg_ptr-fclock); clk_put(bg_ptr-div_clk); @@ -1143,7 +1143,7 @@ static int omap_bandgap_suspend(struct device *dev) omap_bandgap_power(bg_ptr, false); if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_disable(bg_ptr-fclock); + clk_disable_unprepare(bg_ptr-fclock); return err; } @@ -1153,7 +1153,7 @@ static int omap_bandgap_resume(struct device *dev) struct omap_bandgap *bg_ptr = dev_get_drvdata(dev); if (OMAP_BANDGAP_HAS(bg_ptr, CLK_CTRL)) - clk_enable(bg_ptr-fclock); + clk_prepare_enable(bg_ptr-fclock); omap_bandgap_power(bg_ptr, true); -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] documentation: clk: fix couple of misspelling
Correcting misspelling inside the clk.txt. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- Documentation/clk.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 1943fae..4274a54 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -174,9 +174,9 @@ int clk_foo_enable(struct clk_hw *hw) }; Below is a matrix detailing which clk_ops are mandatory based upon the -hardware capbilities of that clock. A cell marked as y means +hardware capabilities of that clock. A cell marked as y means mandatory, a cell marked as n implies that either including that -callback is invalid or otherwise uneccesary. Empty cells are either +callback is invalid or otherwise unnecessary. Empty cells are either optional or must be evaluated on a case-by-case basis. clock hardware characteristics -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Thermal: Create sensor level APIs
Durga,
On 05-02-2013 06:46, Durgadoss R wrote:
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.
At first glance, patch seams reasonable. But I have one major concern as
follows inline, apart from several minor comments.
Signed-off-by: Durgadoss R durgados...@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 0a1bf6b..cb94497 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -44,13 +44,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)
@@ -423,6 +426,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);
For security reasons:
s/sprintf/snprintf
+}
+
+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);
ditto.
+}
+
+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))
I'd rather check if it returns 1.
+ return -EINVAL;
+
+ ret = ts-ops-get_hyst(ts, indx, val);
From your probe, you won't check for devices registered with
ops.get_hyst == NULL. This may lead to a NULL pointer access above.
+
+ return ret ? ret : sprintf(buf, %ld\n, val);
snprintf.
+}
+
+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);
From your probe, you won't check for devices registered with
ops.set_hyst == NULL. This may lead to a NULL pointer access above.
+
+ 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);
From your probe, you won't check for devices registered with
ops.get_threshold == NULL. This may lead to a NULL pointer access above.
+
+ 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;
+}
+
One may be careful with the above functions. Userland having control on
these properties may lead to spurious events, depending on
Re: [PATCH 2/8] Thermal: Create zone level APIs
On 05-02-2013 06:46, Durgadoss R wrote:
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 durgados...@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 cb94497..838d4fb 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -43,19 +43,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) \
Why do you need type? You seam to be using it only for sensors. It
becomes a bit cryptic :-)
+({ \
+ 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;
@@ -421,15 +448,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);
snprintf
+}
+
+static ssize_t
sensor_name_show(struct device *dev, struct device_attribute *attr, char *buf)
{
struct thermal_sensor *ts = to_thermal_sensor(dev);
@@ -811,6 +867,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)
@@ -1656,6 +1714,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);
devm_ helpers
+ if
Re: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone structure
Durga,
On 05-02-2013 06:46, Durgadoss R wrote:
This patch creates new APIs to add/remove a
cdev to/from a zone. This patch does not change
the old cooling device implementation.
Same comments on patch 02/08 I want to rise here:
- Consider using linked list
- You may have contention on your index/cdevs array
- overflow on your buffer (carefully check your implementation)
- zone removal condition. can we remove zones with cdevs registered?
- get_by_name, why do we need it? (at least not on this patch)
- Minors on strlcpy, snprintf, devm_ helpers
- documentation in the code for these helper functions and also better
naming..
Signed-off-by: Durgadoss R durgados...@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 838d4fb..bf703b1 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -57,6 +57,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) \
@@ -83,6 +84,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;
@@ -466,6 +470,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) \
@@ -1462,6 +1484,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)
@@ -1499,6 +1522,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);
@@ -1794,6 +1824,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;
@@ -1844,6 +1891,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 2194519..c841414 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@
Re: [PATCH 4/8] Thermal: Add trip point sysfs nodes for sensor
Durga,
Same comments on patch 02/08 I want to rise here:
- Minors on strlcpy, snprintf, devm_ helpers
- documentation in the code for these helper functions and also better
naming..
On 05-02-2013 06:46, Durgadoss R wrote:
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 durgados...@intel.com
---
drivers/thermal/thermal_sys.c | 225 -
include/linux/thermal.h | 38 ++-
2 files changed, 260 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index bf703b1..69a60a4 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -452,6 +452,37 @@ 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 inline __remove_trip_attr(struct thermal_zone *tz, int indx)
I believe the preferred format would be:
static inline void __remove_trip_attr(struct thermal_zone *tz, int indx)
+{
+ int i;
+ struct thermal_trip_attr *attr = tz-trip_attr[indx];
+
+ if (!attr)
+ return;
+
+ for (i = 0; i NUM_TRIP_TYPES; i++)
+ device_remove_file(tz-device, attr-attrs[i].attr);
+
+ kfree(tz-trip_attr[indx]);
+ tz-trip_attr[indx] = NULL;
+}
+
static void remove_sensor_from_zone(struct thermal_zone *tz,
struct thermal_sensor *ts)
{
@@ -463,9 +494,15 @@ 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 */
+ __remove_trip_attr(tz, indx);
+
/* 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--;
}
@@ -879,6 +916,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;
+}
+
I believe the above function violates sysfs rules, no? Each and every
file must contain only 1 value..
+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;
+}
ditto.
+
+static ssize_t
+hot_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+
Re: [PATCH 5/8] Thermal: Create Thermal map sysfs attributes for a zone
Durga,
On 05-02-2013 06:46, Durgadoss R wrote:
This patch creates a thermal map sysfs node under
/sys/class/thermal/zoneX/. This contains
entries named mapY_trip_type, mapY_sensor_name,
mapY_cdev_name, mapY_trip_mask, mapY_weights.
Some of the previous comments apply here as well, specially wrt to
devm_, snprintf and strlcpy. Also the documentation for the exported
functions are welcome.
Signed-off-by: Durgadoss R durgados...@intel.com
---
drivers/thermal/thermal_sys.c | 221 -
include/linux/thermal.h | 25 +
2 files changed, 244 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 69a60a4..e284b67 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -525,6 +525,44 @@ static void remove_cdev_from_zone(struct thermal_zone *tz,
tz-cdev_indx--;
}
+static inline void __remove_map_entry(struct thermal_zone *tz, int indx)
+{
+ int i;
+ struct thermal_map_attr *attr = tz-map_attr[indx];
+
+ for (i = 0; i NUM_MAP_ATTRS; i++)
+ device_remove_file(tz-device, attr-attrs[i].attr);
+
+ kfree(tz-map_attr[indx]);
+ tz-map[indx] = 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)) {
+ __remove_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)) {
+ __remove_map_entry(tz, i);
+ }
+ }
+}
+
/* sys I/F for thermal zone */
#define to_thermal_zone(_dev) \
@@ -917,6 +955,107 @@ policy_show(struct device *dev, struct device_attribute
*devattr, char *buf)
}
static ssize_t
+map_ttype_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ char *trip;
+ int indx;
+ struct thermal_zone *tz = to_zone(dev);
+
+ if (!sscanf(attr-attr.name, map%d_trip_type, indx))
+ return -EINVAL;
+
+ if (indx 0 || indx = MAX_MAPS_PER_ZONE)
+ return -EINVAL;
+
+ if (!tz-map[indx])
+ return sprintf(buf, Unavailable\n);
Is this condition possible? If yes, we probably need to change the code
so that if the map is not present, the sysfs files are also removed.
+
+ trip = (tz-map[indx]-trip_type == THERMAL_TRIP_ACTIVE) ?
+ active : passive;
+ return sprintf(buf, %s\n, trip);
+}
+
+static ssize_t map_ts_name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int indx;
+ struct thermal_zone *tz = to_zone(dev);
+
+ if (!sscanf(attr-attr.name, map%d_sensor_name, indx))
+ return -EINVAL;
+
+ if (indx 0 || indx = MAX_MAPS_PER_ZONE)
+ return -EINVAL;
+
+ if (!tz-map[indx])
+ return sprintf(buf, Unavailable\n);
ditto
+
+ return sprintf(buf, %s\n, tz-map[indx]-sensor_name);
+}
+
+static ssize_t map_cdev_name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int indx;
+ struct thermal_zone *tz = to_zone(dev);
+
+ if (!sscanf(attr-attr.name, map%d_cdev_name, indx))
+ return -EINVAL;
+
+ if (indx 0 || indx = MAX_MAPS_PER_ZONE)
+ return -EINVAL;
+
+ if (!tz-map[indx])
+ return sprintf(buf, Unavailable\n);
ditto
+
+ return sprintf(buf, %s\n, tz-map[indx]-cdev_name);
+}
+
+static ssize_t map_trip_mask_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int indx;
+ struct thermal_zone *tz = to_zone(dev);
+
+ if (!sscanf(attr-attr.name, map%d_trip_mask, indx))
+ return -EINVAL;
+
+ if (indx 0 || indx = MAX_MAPS_PER_ZONE)
+ return -EINVAL;
+
+ if (!tz-map[indx])
+ return sprintf(buf, Unavailable\n);
ditto
+
+ return sprintf(buf, 0x%x\n, tz-map[indx]-trip_mask);
+}
+
+static ssize_t map_weights_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int i, indx, ret = 0;
+ struct thermal_map *map;
+ struct thermal_zone *tz = to_zone(dev);
+
+ if (!sscanf(attr-attr.name, map%d_weights, indx))
+ return -EINVAL;
+
+ if (indx 0
Re: [PATCHv3 0/8] Thermal Framework Enhancements
Durga, On 05-02-2013 06:46, Durgadoss R wrote: This patch set is a v3 of the previous versions submitted here: [v2]: http://lwn.net/Articles/531720/ [v1]: https://lkml.org/lkml/2012/12/18/108 [RFC]:https://patchwork.kernel.org/patch/1758921/ On this version I have some implementation details which applies mostly for the series. So, I am replying to patch 0 to summarize: - Consider using linked list - You may have contention on your indexes and arrays - overflow on your buffer (carefully check your implementation) - zone removal condition. can we remove zones with sensors/cdevs/maps registered? - Minors on strlcpy, snprintf, devm_ helpers - documentation in the code for these helper functions and also better naming.. This patch set is based on Rui's -next tree, and is tested on a Core-i5 and an Atom netbook. Changes since v2: * Reworked the map sysfs attributes in patch [5/8] * Dropped configuration for maximum sensors and cooling devices, through Kconfig. * Added __remove_trip_attr method * Renamed __clean_map_entry to __remove_map_entry for consistency in naming. 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 8 patches: Patch 1/8: Creates new sensor level APIs Patch 2/8: Creates new zone level APIs. The existing tzd structure is kept as such for clarity and compatibility purposes. Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The existing tcd structure need not be modified. Patch 4/8: 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/8: Adds mapY_* sysfs node. These attributes represent the binding relationship between a sensor and a cdev, within a zone. Patch 6/8: 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/8: Add ABI documentation for sysfs interfaces introduced in this patch. Patch 8/8: A dummy driver that can be used for testing. This is not for merge. Durgadoss R (8): 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 Thermal map sysfs attributes for a zone Thermal: Add Documentation to new APIs Thermal: Add ABI Documentation for sysfs interfaces Thermal: Dummy driver used for testing Documentation/ABI/testing/sysfs-class-thermal | 137 Documentation/thermal/sysfs-api2.txt | 247 ++ drivers/thermal/Kconfig |5 + drivers/thermal/Makefile |2 + drivers/thermal/thermal_sys.c | 994 + drivers/thermal/thermal_test.c| 324 include/linux/thermal.h | 123 ++- 7 files changed, 1831 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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] staging: omap-thermal: bandgap: fix setting of alert thresholds
From: Radhesh Fadnis radhesh.fad...@ti.com
There was an error in check for the valid temperature in
function temp_to_adc_conversion. The temperature value was
compared with higher limit for less than condition as well,
resulting in returning -EINVAL. Corrected the check condition
to properly check for lower and higher temperature limits.
Signed-off-by: Radhesh Fadnis radhesh.fad...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index ff93c15..368a2e1 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -157,7 +157,7 @@ static int temp_to_adc_conversion(long temp, struct
omap_bandgap *bg_ptr, int i,
high = ts_data-adc_end_val - ts_data-adc_start_val;
mid = (high + low) / 2;
- if (temp bg_ptr-conv_table[high] || temp bg_ptr-conv_table[high])
+ if (temp bg_ptr-conv_table[low] || temp bg_ptr-conv_table[high])
return -EINVAL;
while (low high) {
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] staging: omap-thermal: Correct checkpatch.pl warnings
From: J Keerthy j-keer...@ti.com
Removes checkpatch warnings on omap-bandgap.c.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index c556abb..9ef44ea 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1037,20 +1037,20 @@ static int omap_bandgap_save_ctxt(struct omap_bandgap
*bg_ptr)
if (OMAP_BANDGAP_HAS(bg_ptr, MODE_CONFIG))
rval-bg_mode_ctrl = omap_bandgap_readl(bg_ptr,
-
tsr-bgap_mode_ctrl);
+ tsr-bgap_mode_ctrl);
if (OMAP_BANDGAP_HAS(bg_ptr, COUNTER))
rval-bg_counter = omap_bandgap_readl(bg_ptr,
-
tsr-bgap_counter);
+ tsr-bgap_counter);
if (OMAP_BANDGAP_HAS(bg_ptr, TALERT)) {
rval-bg_threshold = omap_bandgap_readl(bg_ptr,
-
tsr-bgap_threshold);
+ tsr-bgap_threshold);
rval-bg_ctrl = omap_bandgap_readl(bg_ptr,
- tsr-bgap_mask_ctrl);
+ tsr-bgap_mask_ctrl);
}
if (OMAP_BANDGAP_HAS(bg_ptr, TSHUT_CONFIG))
rval-tshut_threshold = omap_bandgap_readl(bg_ptr,
-
tsr-tshut_threshold);
+ tsr-tshut_threshold);
}
return 0;
@@ -1074,8 +1074,9 @@ static int omap_bandgap_restore_ctxt(struct omap_bandgap
*bg_ptr)
if (val == 0) {
if (OMAP_BANDGAP_HAS(bg_ptr, TSHUT_CONFIG))
- omap_bandgap_writel(bg_ptr,
rval-tshut_threshold,
-
tsr-tshut_threshold);
+ omap_bandgap_writel(bg_ptr,
+ rval-tshut_threshold,
+ tsr-tshut_threshold);
/* Force immediate temperature measurement and update
* of the DTEMP field
*/
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] staging: omap-thermal: clean-ups and fixes
Hello Greg, Here are some patches to clean the omap-thermal driver code a bit. There are 2 fixes as well related to registration to thermal fw. These patches are based on staging-next tree. They are also available here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/omap-thermal-fixes All best, Eduardo Valentin (3): staging: omap-thermal: remove checkpatch.pl warnings on data files staging: omap-thermal: fix polling period settings staging: omap-thermal: improve conf data handling and initialization J Keerthy (1): staging: omap-thermal: Correct checkpatch.pl warnings drivers/staging/omap-thermal/omap-bandgap.c| 21 drivers/staging/omap-thermal/omap-thermal-common.c | 42 +-- drivers/staging/omap-thermal/omap4-thermal.c | 54 ++-- drivers/staging/omap-thermal/omap5-thermal.c | 38 +++--- 4 files changed, 93 insertions(+), 62 deletions(-) -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] staging: omap-thermal: improve conf data handling and initialization
While registering the thermal zone, it is required to have the cooling
devices already setup, so that the .bind callback can succeed.
Due to that, the driver code needs to be reorganized so that we first
setup the cooling devices then the zones. This way we cope with the
right thermal framework initialization sequence.
This patch changes the order of the thermal zone initialization,
so that we create it only when the cooling devices are available.
It also adds some defensive checks for the config data, so that
the callbacks are ready for calls when the data is still not
initialized.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c|6 ++--
drivers/staging/omap-thermal/omap-thermal-common.c | 38 +---
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 9ef44ea..ff93c15 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -953,12 +953,12 @@ int __devinit omap_bandgap_probe(struct platform_device
*pdev)
for (i = 0; i bg_ptr-conf-sensor_count; i++) {
char *domain;
+ if (bg_ptr-conf-sensors[i].register_cooling)
+ bg_ptr-conf-sensors[i].register_cooling(bg_ptr, i);
+
domain = bg_ptr-conf-sensors[i].domain;
if (bg_ptr-conf-expose_sensor)
bg_ptr-conf-expose_sensor(bg_ptr, i, domain);
-
- if (bg_ptr-conf-sensors[i].register_cooling)
- bg_ptr-conf-sensors[i].register_cooling(bg_ptr, i);
}
/*
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
index d156424..46ee0a9 100644
--- a/drivers/staging/omap-thermal/omap-thermal-common.c
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -77,10 +77,16 @@ static inline int omap_thermal_get_temp(struct
thermal_zone_device *thermal,
unsigned long *temp)
{
struct omap_thermal_data *data = thermal-devdata;
- struct omap_bandgap *bg_ptr = data-bg_ptr;
- struct omap_temp_sensor *s = bg_ptr-conf-sensors[data-sensor_id];
+ struct omap_bandgap *bg_ptr;
+ struct omap_temp_sensor *s;
int ret, tmp, pcb_temp, slope, constant;
+ if (!data)
+ return 0;
+
+ bg_ptr = data-bg_ptr;
+ s = bg_ptr-conf-sensors[data-sensor_id];
+
ret = omap_bandgap_read_temperature(bg_ptr, data-sensor_id, tmp);
if (ret)
return ret;
@@ -227,21 +233,37 @@ static struct thermal_zone_device_ops omap_thermal_ops = {
.get_crit_temp = omap_thermal_get_crit_temp,
};
-int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
- char *domain)
+static struct omap_thermal_data
+*omap_thermal_build_data(struct omap_bandgap *bg_ptr, int id)
{
struct omap_thermal_data *data;
data = devm_kzalloc(bg_ptr-dev, sizeof(*data), GFP_KERNEL);
if (!data) {
dev_err(bg_ptr-dev, kzalloc fail\n);
- return -ENOMEM;
+ return NULL;
}
data-sensor_id = id;
data-bg_ptr = bg_ptr;
data-mode = THERMAL_DEVICE_ENABLED;
INIT_WORK(data-thermal_wq, omap_thermal_work);
+ return data;
+}
+
+int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain)
+{
+ struct omap_thermal_pdata pdata;
+
+ data = omap_bandgap_get_sensor_data(bg_ptr, id);
+
+ if (!data)
+ data = omap_thermal_build_pdata(bg_ptr, id);
+
+ if (!data)
+ return -EINVAL;
+
/* TODO: remove TC1 TC2 */
/* Create thermal zone */
data-omap_thermal = thermal_zone_device_register(domain,
@@ -335,6 +357,11 @@ int omap_thermal_register_cpu_cooling(struct omap_bandgap
*bg_ptr, int id)
int tab_size, ret;
data = omap_bandgap_get_sensor_data(bg_ptr, id);
+ if (!data)
+ data = omap_thermal_build_pdata(bg_ptr, id);
+
+ if (!data)
+ return -EINVAL;
ret = omap_thermal_build_cpufreq_clip(bg_ptr, tab_ptr, tab_size);
if (ret 0) {
@@ -351,6 +378,7 @@ int omap_thermal_register_cpu_cooling(struct omap_bandgap
*bg_ptr, int id)
return PTR_ERR(data-cool_dev);
}
bg_ptr-conf-sensors[id].cooling_data.freq_clip_count = tab_size;
+ omap_bandgap_set_sensor_data(bg_ptr, id, data);
return 0;
}
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] staging: omap-thermal: fix polling period settings
While registering the omap thermal zones we need to
properly specify TC1 and TC2, as long as the proper
passive polling period and monitor period.
This patch fixes the parameters passed while registering
the thermal zone.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-thermal-common.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
index 0675a5e..d156424 100644
--- a/drivers/staging/omap-thermal/omap-thermal-common.c
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -246,7 +246,9 @@ int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr,
int id,
/* Create thermal zone */
data-omap_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, omap_thermal_ops,
- 0, FAST_TEMP_MONITORING_RATE, 0, 0);
+ 1, 2, /*TODO: remove this when FW allows */
+ FAST_TEMP_MONITORING_RATE,
+ FAST_TEMP_MONITORING_RATE);
if (IS_ERR_OR_NULL(data-omap_thermal)) {
dev_err(bg_ptr-dev, thermal zone device is NULL\n);
return PTR_ERR(data-omap_thermal);
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] staging: omap-thermal: remove checkpatch.pl warnings on data files
Simple checkpatch.pl clean ups.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap4-thermal.c | 54 +-
drivers/staging/omap-thermal/omap5-thermal.c | 38 +-
2 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap4-thermal.c
b/drivers/staging/omap-thermal/omap4-thermal.c
index fa9dbcd..04c02b6 100644
--- a/drivers/staging/omap-thermal/omap4-thermal.c
+++ b/drivers/staging/omap-thermal/omap4-thermal.c
@@ -77,15 +77,15 @@ const struct omap_bandgap_data omap4430_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = omap4430_mpu_temp_sensor_registers,
- .ts_data = omap4430_mpu_temp_sensor_data,
- .domain = cpu,
- .slope = 0,
- .constant = 2,
- .slope_pcb = 0,
- .constant_pcb = 2,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = omap4430_mpu_temp_sensor_registers,
+ .ts_data = omap4430_mpu_temp_sensor_data,
+ .domain = cpu,
+ .slope = 0,
+ .constant = 2,
+ .slope_pcb = 0,
+ .constant_pcb = 2,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
@@ -215,15 +215,15 @@ const struct omap_bandgap_data omap4460_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = omap4460_mpu_temp_sensor_registers,
- .ts_data = omap4460_mpu_temp_sensor_data,
- .domain = cpu,
- .slope = OMAP_GRADIENT_SLOPE_4460,
- .constant = OMAP_GRADIENT_CONST_4460,
- .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4460,
- .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4460,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = omap4460_mpu_temp_sensor_registers,
+ .ts_data = omap4460_mpu_temp_sensor_data,
+ .domain = cpu,
+ .slope = OMAP_GRADIENT_SLOPE_4460,
+ .constant = OMAP_GRADIENT_CONST_4460,
+ .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4460,
+ .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4460,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
@@ -244,15 +244,15 @@ const struct omap_bandgap_data omap4470_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = omap4460_mpu_temp_sensor_registers,
- .ts_data = omap4460_mpu_temp_sensor_data,
- .domain = cpu,
- .slope = OMAP_GRADIENT_SLOPE_4470,
- .constant = OMAP_GRADIENT_CONST_4470,
- .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4470,
- .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4470,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = omap4460_mpu_temp_sensor_registers,
+ .ts_data = omap4460_mpu_temp_sensor_data,
+ .domain = cpu,
+ .slope = OMAP_GRADIENT_SLOPE_4470,
+ .constant = OMAP_GRADIENT_CONST_4470,
+ .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4470,
+ .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4470,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index 0658af2..2f3a498 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -268,29 +268,29 @@ const struct omap_bandgap_data omap5430_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = omap5430_mpu_temp_sensor_registers,
- .ts_data = omap5430_mpu_temp_sensor_data,
- .domain = cpu
[PATCHv2 0/4] staging: adding OMAP bandgap driver
Greg, Here is the reworked series with the omap bangap driver and minimalist thermal framework support. Diff from v1 is simple that now it won't break compilation. Only change is between patch 1 and patch 2, I have added the missing and needed Makefile and Kconfig entries in patch 1, for omap-bandgap.c. Cheers, Eduardo Valentin (4): staging: OMAP4+: thermal: introduce bandgap temperature sensor staging: omap-thermal: common code to expose driver to thermal framework staging: omap-thermal: add OMAP4 data structures staging: omap-thermal: add OMAP5 data structures drivers/staging/Kconfig|2 + drivers/staging/Makefile |1 + drivers/staging/omap-thermal/Kconfig | 45 + drivers/staging/omap-thermal/Makefile |5 + drivers/staging/omap-thermal/TODO | 27 + drivers/staging/omap-thermal/omap-bandgap.c| 1186 drivers/staging/omap-thermal/omap-bandgap.h| 441 drivers/staging/omap-thermal/omap-thermal-common.c | 397 +++ drivers/staging/omap-thermal/omap-thermal.h| 108 ++ drivers/staging/omap-thermal/omap4-thermal.c | 259 + drivers/staging/omap-thermal/omap5-thermal.c | 297 + drivers/staging/omap-thermal/omap_bandgap.txt | 30 + 12 files changed, 2798 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/omap-thermal/Kconfig create mode 100644 drivers/staging/omap-thermal/Makefile create mode 100644 drivers/staging/omap-thermal/TODO create mode 100644 drivers/staging/omap-thermal/omap-bandgap.c create mode 100644 drivers/staging/omap-thermal/omap-bandgap.h create mode 100644 drivers/staging/omap-thermal/omap-thermal-common.c create mode 100644 drivers/staging/omap-thermal/omap-thermal.h create mode 100644 drivers/staging/omap-thermal/omap4-thermal.c create mode 100644 drivers/staging/omap-thermal/omap5-thermal.c create mode 100644 drivers/staging/omap-thermal/omap_bandgap.txt -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 2/4] staging: omap-thermal: common code to expose driver to thermal framework
This patch has the common thermal framework support for OMAP
bandgap driver. It includes the zone registration and unregistration,
the cpu cooling and the trip definitions.
The trips definition is essentially one trip for passive cooling
using the generic cpu cooling device and another one for thermal
shutdown. The cpu cooling device is built based on the existing
cpu freq table. The build should be agnostic to omap version,
but relies that cpufreq is up and running by the time the driver
registers the cpu cooling, as it relies on the table walk api
from cpufreq.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig |8 +
drivers/staging/omap-thermal/Makefile |1 +
drivers/staging/omap-thermal/omap-thermal-common.c | 397
drivers/staging/omap-thermal/omap-thermal.h| 108 ++
4 files changed, 514 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap-thermal-common.c
create mode 100644 drivers/staging/omap-thermal/omap-thermal.h
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index f3fd2ea..b3996cc 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -9,3 +9,11 @@ config OMAP_BANDGAP
This includes alert interrupts generation and also the TSHUT
support.
+config OMAP_THERMAL
+ bool Texas Instruments OMAP4+ thermal framework support
+ depends on OMAP_BANDGAP
+ depends on CPU_THERMAL
+ help
+ If you say yes here you want to get support for generic thermal
+ framework for the Texas Instruments OMAP4460+ on die bandgap
+ temperature sensor.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index c92a854..fcdf773 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
+omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
new file mode 100644
index 000..a52caa4
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -0,0 +1,397 @@
+/*
+ * OMAP thermal driver interface
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/mutex.h
+#include linux/gfp.h
+#include linux/kernel.h
+#include linux/workqueue.h
+#include linux/thermal.h
+#include linux/cpufreq.h
+#include linux/cpu_cooling.h
+
+#include omap-thermal.h
+#include omap-bandgap.h
+
+/* common data structures */
+struct omap_thermal_data {
+ struct thermal_zone_device *omap_thermal;
+ struct thermal_cooling_device *cool_dev;
+ struct omap_bandgap *bg_ptr;
+ enum thermal_device_mode mode;
+ struct work_struct thermal_wq;
+ int sensor_id;
+};
+
+static void omap_thermal_work(struct work_struct *work)
+{
+ struct omap_thermal_data *data = container_of(work,
+ struct omap_thermal_data, thermal_wq);
+
+ thermal_zone_device_update(data-omap_thermal);
+
+ dev_dbg(data-omap_thermal-device, updated thermal zone %s\n,
+ data-omap_thermal-type);
+}
+
+/**
+ * omap_thermal_hotspot_temperature - returns sensor extrapolated temperature
+ * @t: omap sensor temperature
+ * @s: omap sensor slope value
+ * @c: omap sensor const value
+ */
+static inline int omap_thermal_hotspot_temperature(int t, int s, int c)
+{
+ int delta = t * s / 1000 + c;
+
+ if (delta 0)
+ delta = 0;
+
+ return t + delta;
+}
+
+/* thermal zone ops */
+/* Get temperature callback function for thermal zone*/
+static inline int omap_thermal_get_temp(struct thermal_zone_device *thermal,
+unsigned long *temp)
+{
+ struct omap_thermal_data *data = thermal-devdata;
+ struct omap_bandgap *bg_ptr = data-bg_ptr;
+ struct omap_temp_sensor *s = bg_ptr-conf-sensors[data
[PATCHv2 3/4] staging: omap-thermal: add OMAP4 data structures
This patch adds the data structures needed for proper registration
of OMAP4 chips. This patch includes definitions for these chip versions:
. OMAP4430
. OMAP4460
. OMAP4470
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig | 14 ++
drivers/staging/omap-thermal/Makefile|1 +
drivers/staging/omap-thermal/omap-bandgap.c | 14 ++
drivers/staging/omap-thermal/omap-bandgap.h | 10 +
drivers/staging/omap-thermal/omap4-thermal.c | 259 ++
5 files changed, 298 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap4-thermal.c
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index b3996cc..e16f0bc 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -17,3 +17,17 @@ config OMAP_THERMAL
If you say yes here you want to get support for generic thermal
framework for the Texas Instruments OMAP4460+ on die bandgap
temperature sensor.
+
+config OMAP4_THERMAL
+ bool Texas Instruments OMAP4 thermal support
+ depends on OMAP_BANDGAP
+ depends on ARCH_OMAP4
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP4 SoC family. The current chip supported are:
+ - OMAP4430
+ - OMAP4460
+ - OMAP4470
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index fcdf773..76f9c19 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
+omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 3b2cd87..cc0869a 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1143,6 +1143,20 @@ static const struct dev_pm_ops omap_bandgap_dev_pm_ops =
{
#endif
static const struct of_device_id of_omap_bandgap_match[] = {
+#ifdef CONFIG_OMAP4_THERMAL
+ {
+ .compatible = ti,omap4430-bandgap,
+ .data = (void *)omap4430_data,
+ },
+ {
+ .compatible = ti,omap4460-bandgap,
+ .data = (void *)omap4460_data,
+ },
+ {
+ .compatible = ti,omap4470-bandgap,
+ .data = (void *)omap4470_data,
+ },
+#endif
/* Sentinel */
{ },
};
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 8b9883d..6d442fe 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -422,4 +422,14 @@ int omap_bandgap_set_sensor_data(struct omap_bandgap
*bg_ptr, int id,
void *data);
void *omap_bandgap_get_sensor_data(struct omap_bandgap *bg_ptr, int id);
+#ifdef CONFIG_OMAP4_THERMAL
+extern const struct omap_bandgap_data omap4430_data;
+extern const struct omap_bandgap_data omap4460_data;
+extern const struct omap_bandgap_data omap4470_data;
+#else
+#define omap4430_data NULL
+#define omap4460_data NULL
+#define omap4470_data NULL
+#endif
+
#endif
diff --git a/drivers/staging/omap-thermal/omap4-thermal.c
b/drivers/staging/omap-thermal/omap4-thermal.c
new file mode 100644
index 000..fa9dbcd
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap4-thermal.c
@@ -0,0 +1,259 @@
+/*
+ * OMAP4 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include omap-thermal.h
+#include omap-bandgap.h
+
+/*
+ * OMAP4430 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap4430_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP4430_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4430_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK
[PATCHv2 4/4] staging: omap-thermal: add OMAP5 data structures
This patch adds the data structures needed for proper registration
of OMAP5 chips. This patch includes definitions for these chip versions:
. OMAP5430
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig | 12 +
drivers/staging/omap-thermal/Makefile|1 +
drivers/staging/omap-thermal/omap-bandgap.c |6 +
drivers/staging/omap-thermal/omap-bandgap.h |6 +
drivers/staging/omap-thermal/omap5-thermal.c | 297 ++
5 files changed, 322 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap5-thermal.c
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index e16f0bc..02130e1 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -31,3 +31,15 @@ config OMAP4_THERMAL
This includes alert interrupts generation and also the TSHUT
support.
+
+config OMAP5_THERMAL
+ bool Texas Instruments OMAP5 thermal support
+ depends on OMAP_BANDGAP
+ depends on SOC_OMAP5
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP5 SoC family. The current chip supported are:
+ - OMAP5430
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index 76f9c19..091c4d2 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
+omap-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal.o
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index cc0869a..55f3f5d 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1157,6 +1157,12 @@ static const struct of_device_id of_omap_bandgap_match[]
= {
.data = (void *)omap4470_data,
},
#endif
+#ifdef CONFIG_OMAP5_THERMAL
+ {
+ .compatible = ti,omap5430-bandgap,
+ .data = (void *)omap5430_data,
+ },
+#endif
/* Sentinel */
{ },
};
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 6d442fe..78aed75 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -432,4 +432,10 @@ extern const struct omap_bandgap_data omap4470_data;
#define omap4470_data NULL
#endif
+#ifdef CONFIG_OMAP5_THERMAL
+extern const struct omap_bandgap_data omap5430_data;
+#else
+#define omap5430_data NULL
+#endif
+
#endif
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
new file mode 100644
index 000..0658af2
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -0,0 +1,297 @@
+/*
+ * OMAP5 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include omap-bandgap.h
+#include omap-thermal.h
+
+/*
+ * omap5430 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap5430_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP5430_TEMP_SENSOR_MPU_OFFSET,
+ .bgap_tempsoff_mask = OMAP5430_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask = OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP5430_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP5430_MASK_HOT_MPU_MASK,
+ .mask_cold_mask = OMAP5430_MASK_COLD_MPU_MASK,
+
+ .bgap_mode_ctrl = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
+ .mode_ctrl_mask = OMAP5430_REPEAT_MODE_MASK,
+
+ .bgap_counter = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
+ .counter_mask = OMAP5430_COUNTER_MASK,
+
+ .bgap_threshold = OMAP5430_BGAP_THRESHOLD_MPU_OFFSET,
+ .threshold_thot_mask = OMAP5430_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP5430_T_COLD_MASK
[PATCHv2 1/4] staging: OMAP4+: thermal: introduce bandgap temperature sensor
In the System Control Module, OMAP supplies a voltage reference and a temperature sensor feature that are gathered in the band gap voltage and temperature sensor (VBGAPTS) module. The band gap provides current and voltage reference for its internal circuits and other analog IP blocks. The analog-to-digital converter (ADC) produces an output value that is proportional to the silicon temperature. This patch provides a platform driver which expose this feature. It is moduled as a MFD child of the System Control Module core MFD driver. This driver provides only APIs to access the device properties, like temperature, thresholds and update rate. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Keerthy j-keer...@ti.com --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/omap-thermal/Kconfig | 11 + drivers/staging/omap-thermal/Makefile |2 + drivers/staging/omap-thermal/TODO | 27 + drivers/staging/omap-thermal/omap-bandgap.c | 1166 + drivers/staging/omap-thermal/omap-bandgap.h | 425 + drivers/staging/omap-thermal/omap_bandgap.txt | 30 + 8 files changed, 1664 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/omap-thermal/Kconfig create mode 100644 drivers/staging/omap-thermal/Makefile create mode 100644 drivers/staging/omap-thermal/TODO create mode 100644 drivers/staging/omap-thermal/omap-bandgap.c create mode 100644 drivers/staging/omap-thermal/omap-bandgap.h create mode 100644 drivers/staging/omap-thermal/omap_bandgap.txt diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index d3934d7..e3402d5 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -134,4 +134,6 @@ source drivers/staging/gdm72xx/Kconfig source drivers/staging/csr/Kconfig +source drivers/staging/omap-thermal/Kconfig + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 5b2219a..dbbdbbc 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -59,3 +59,4 @@ obj-$(CONFIG_USB_WPAN_HCD)+= ozwpan/ obj-$(CONFIG_USB_G_CCG)+= ccg/ obj-$(CONFIG_WIMAX_GDM72XX)+= gdm72xx/ obj-$(CONFIG_CSR_WIFI) += csr/ +obj-y += omap-thermal/ diff --git a/drivers/staging/omap-thermal/Kconfig b/drivers/staging/omap-thermal/Kconfig new file mode 100644 index 000..f3fd2ea --- /dev/null +++ b/drivers/staging/omap-thermal/Kconfig @@ -0,0 +1,11 @@ +config OMAP_BANDGAP + tristate Texas Instruments OMAP4+ temperature sensor driver + depends on THERMAL + help + If you say yes here you get support for the Texas Instruments + OMAP4460+ on die bandgap temperature sensor support. The register + set is part of system control module. + + This includes alert interrupts generation and also the TSHUT + support. + diff --git a/drivers/staging/omap-thermal/Makefile b/drivers/staging/omap-thermal/Makefile new file mode 100644 index 000..c92a854 --- /dev/null +++ b/drivers/staging/omap-thermal/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o +omap-thermal-y := omap-bandgap.o diff --git a/drivers/staging/omap-thermal/TODO b/drivers/staging/omap-thermal/TODO new file mode 100644 index 000..77b761b --- /dev/null +++ b/drivers/staging/omap-thermal/TODO @@ -0,0 +1,27 @@ +List of TODOs (by Eduardo Valentin) + +on omap-bandgap.c: +- Rework locking +- Improve driver code by adding usage of regmap-mmio +- Test every exposed API to userland +- Add support to hwmon +- Review and revisit all API exposed +- Revisit PM support +- Revisit data structures and simplify them +- Once SCM-core api settles, update this driver accordingly + +on omap-thermal-common.c/omap-thermal.h: +- Revisit extrapolation constants for O4/O5 +- Revisit need for locking +- Revisit trips and its definitions +- Revisit trending + +on omap5-thermal.c +- Add support for GPU cooling + +generally: +- make checkpatch.pl and sparse happy +- make sure this code works on OMAP4430, OMAP4460 and OMAP5430 +- update documentation + +Copy patches to Eduardo Valentin eduardo.valen...@ti.com diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c new file mode 100644 index 000..3b2cd87 --- /dev/null +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -0,0 +1,1166 @@ +/* + * OMAP4 Bandgap temperature sensor driver + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * Author: J Keerthy j-keer...@ti.com + * Author: Moiz Sonasath m-sonas...@ti.com + * Couple of fixes, DT and MFD adaptation: + * Eduardo Valentin eduardo.valen...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free
[PATCHv3 0/4] staging: adding OMAP bandgap driver
Greg, On top of the compilation fix, now Keerthy's SOB is just like in the files' copyright notice. I also changed patch 01 so that it does not add an empty line in the end of the Kconfig, so patches 01 and 02 are different from V2. That's why I sent the complete series with v3 mark. Cheers, Eduardo Valentin (4): staging: OMAP4+: thermal: introduce bandgap temperature sensor staging: omap-thermal: common code to expose driver to thermal framework staging: omap-thermal: add OMAP4 data structures staging: omap-thermal: add OMAP5 data structures drivers/staging/Kconfig|2 + drivers/staging/Makefile |1 + drivers/staging/omap-thermal/Kconfig | 45 + drivers/staging/omap-thermal/Makefile |5 + drivers/staging/omap-thermal/TODO | 27 + drivers/staging/omap-thermal/omap-bandgap.c| 1186 drivers/staging/omap-thermal/omap-bandgap.h| 441 drivers/staging/omap-thermal/omap-thermal-common.c | 397 +++ drivers/staging/omap-thermal/omap-thermal.h| 108 ++ drivers/staging/omap-thermal/omap4-thermal.c | 259 + drivers/staging/omap-thermal/omap5-thermal.c | 297 + drivers/staging/omap-thermal/omap_bandgap.txt | 30 + 12 files changed, 2798 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/omap-thermal/Kconfig create mode 100644 drivers/staging/omap-thermal/Makefile create mode 100644 drivers/staging/omap-thermal/TODO create mode 100644 drivers/staging/omap-thermal/omap-bandgap.c create mode 100644 drivers/staging/omap-thermal/omap-bandgap.h create mode 100644 drivers/staging/omap-thermal/omap-thermal-common.c create mode 100644 drivers/staging/omap-thermal/omap-thermal.h create mode 100644 drivers/staging/omap-thermal/omap4-thermal.c create mode 100644 drivers/staging/omap-thermal/omap5-thermal.c create mode 100644 drivers/staging/omap-thermal/omap_bandgap.txt -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 1/4] staging: OMAP4+: thermal: introduce bandgap temperature sensor
In the System Control Module, OMAP supplies a voltage reference and a temperature sensor feature that are gathered in the band gap voltage and temperature sensor (VBGAPTS) module. The band gap provides current and voltage reference for its internal circuits and other analog IP blocks. The analog-to-digital converter (ADC) produces an output value that is proportional to the silicon temperature. This patch provides a platform driver which expose this feature. It is moduled as a MFD child of the System Control Module core MFD driver. This driver provides only APIs to access the device properties, like temperature, thresholds and update rate. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/omap-thermal/Kconfig | 10 + drivers/staging/omap-thermal/Makefile |2 + drivers/staging/omap-thermal/TODO | 27 + drivers/staging/omap-thermal/omap-bandgap.c | 1166 + drivers/staging/omap-thermal/omap-bandgap.h | 425 + drivers/staging/omap-thermal/omap_bandgap.txt | 30 + 8 files changed, 1663 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/omap-thermal/Kconfig create mode 100644 drivers/staging/omap-thermal/Makefile create mode 100644 drivers/staging/omap-thermal/TODO create mode 100644 drivers/staging/omap-thermal/omap-bandgap.c create mode 100644 drivers/staging/omap-thermal/omap-bandgap.h create mode 100644 drivers/staging/omap-thermal/omap_bandgap.txt Patch changelog: Change from V1 to V2: - Compilation fixes on Kconfig and Makefiles under drivers/staging Change from V2 to V3: - Removed empty line from end of Kconfig file, so git is happy while applying - Keerthy's SOB now matches Copyright notice found in files diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index d3934d7..e3402d5 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -134,4 +134,6 @@ source drivers/staging/gdm72xx/Kconfig source drivers/staging/csr/Kconfig +source drivers/staging/omap-thermal/Kconfig + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 5b2219a..dbbdbbc 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -59,3 +59,4 @@ obj-$(CONFIG_USB_WPAN_HCD)+= ozwpan/ obj-$(CONFIG_USB_G_CCG)+= ccg/ obj-$(CONFIG_WIMAX_GDM72XX)+= gdm72xx/ obj-$(CONFIG_CSR_WIFI) += csr/ +obj-y += omap-thermal/ diff --git a/drivers/staging/omap-thermal/Kconfig b/drivers/staging/omap-thermal/Kconfig new file mode 100644 index 000..8096250 --- /dev/null +++ b/drivers/staging/omap-thermal/Kconfig @@ -0,0 +1,10 @@ +config OMAP_BANDGAP + tristate Texas Instruments OMAP4+ temperature sensor driver + depends on THERMAL + help + If you say yes here you get support for the Texas Instruments + OMAP4460+ on die bandgap temperature sensor support. The register + set is part of system control module. + + This includes alert interrupts generation and also the TSHUT + support. diff --git a/drivers/staging/omap-thermal/Makefile b/drivers/staging/omap-thermal/Makefile new file mode 100644 index 000..c92a854 --- /dev/null +++ b/drivers/staging/omap-thermal/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o +omap-thermal-y := omap-bandgap.o diff --git a/drivers/staging/omap-thermal/TODO b/drivers/staging/omap-thermal/TODO new file mode 100644 index 000..77b761b --- /dev/null +++ b/drivers/staging/omap-thermal/TODO @@ -0,0 +1,27 @@ +List of TODOs (by Eduardo Valentin) + +on omap-bandgap.c: +- Rework locking +- Improve driver code by adding usage of regmap-mmio +- Test every exposed API to userland +- Add support to hwmon +- Review and revisit all API exposed +- Revisit PM support +- Revisit data structures and simplify them +- Once SCM-core api settles, update this driver accordingly + +on omap-thermal-common.c/omap-thermal.h: +- Revisit extrapolation constants for O4/O5 +- Revisit need for locking +- Revisit trips and its definitions +- Revisit trending + +on omap5-thermal.c +- Add support for GPU cooling + +generally: +- make checkpatch.pl and sparse happy +- make sure this code works on OMAP4430, OMAP4460 and OMAP5430 +- update documentation + +Copy patches to Eduardo Valentin eduardo.valen...@ti.com diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c new file mode 100644 index 000..3b2cd87 --- /dev/null +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -0,0 +1,1166 @@ +/* + * OMAP4 Bandgap temperature sensor driver + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * Author: J Keerthy j-keer...@ti.com + * Author: Moiz Sonasath m-sonas...@ti.com
[PATCHv3 2/4] staging: omap-thermal: common code to expose driver to thermal framework
This patch has the common thermal framework support for OMAP
bandgap driver. It includes the zone registration and unregistration,
the cpu cooling and the trip definitions.
The trips definition is essentially one trip for passive cooling
using the generic cpu cooling device and another one for thermal
shutdown. The cpu cooling device is built based on the existing
cpu freq table. The build should be agnostic to omap version,
but relies that cpufreq is up and running by the time the driver
registers the cpu cooling, as it relies on the table walk api
from cpufreq.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig |9 +
drivers/staging/omap-thermal/Makefile |1 +
drivers/staging/omap-thermal/omap-thermal-common.c | 397
drivers/staging/omap-thermal/omap-thermal.h| 108 ++
4 files changed, 515 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap-thermal-common.c
create mode 100644 drivers/staging/omap-thermal/omap-thermal.h
Patch changelog:
Change from V1 to V2/3: Compilation fixes on Kconfig and Makefiles under
drivers/staging
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index 8096250..b3996cc 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -8,3 +8,12 @@ config OMAP_BANDGAP
This includes alert interrupts generation and also the TSHUT
support.
+
+config OMAP_THERMAL
+ bool Texas Instruments OMAP4+ thermal framework support
+ depends on OMAP_BANDGAP
+ depends on CPU_THERMAL
+ help
+ If you say yes here you want to get support for generic thermal
+ framework for the Texas Instruments OMAP4460+ on die bandgap
+ temperature sensor.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index c92a854..fcdf773 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
+omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
new file mode 100644
index 000..a52caa4
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -0,0 +1,397 @@
+/*
+ * OMAP thermal driver interface
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/mutex.h
+#include linux/gfp.h
+#include linux/kernel.h
+#include linux/workqueue.h
+#include linux/thermal.h
+#include linux/cpufreq.h
+#include linux/cpu_cooling.h
+
+#include omap-thermal.h
+#include omap-bandgap.h
+
+/* common data structures */
+struct omap_thermal_data {
+ struct thermal_zone_device *omap_thermal;
+ struct thermal_cooling_device *cool_dev;
+ struct omap_bandgap *bg_ptr;
+ enum thermal_device_mode mode;
+ struct work_struct thermal_wq;
+ int sensor_id;
+};
+
+static void omap_thermal_work(struct work_struct *work)
+{
+ struct omap_thermal_data *data = container_of(work,
+ struct omap_thermal_data, thermal_wq);
+
+ thermal_zone_device_update(data-omap_thermal);
+
+ dev_dbg(data-omap_thermal-device, updated thermal zone %s\n,
+ data-omap_thermal-type);
+}
+
+/**
+ * omap_thermal_hotspot_temperature - returns sensor extrapolated temperature
+ * @t: omap sensor temperature
+ * @s: omap sensor slope value
+ * @c: omap sensor const value
+ */
+static inline int omap_thermal_hotspot_temperature(int t, int s, int c)
+{
+ int delta = t * s / 1000 + c;
+
+ if (delta 0)
+ delta = 0;
+
+ return t + delta;
+}
+
+/* thermal zone ops */
+/* Get temperature callback function for thermal zone*/
+static inline int omap_thermal_get_temp(struct thermal_zone_device *thermal,
+unsigned long *temp)
+{
+ struct omap_thermal_data *data = thermal-devdata
[PATCHv3 3/4] staging: omap-thermal: add OMAP4 data structures
This patch adds the data structures needed for proper registration
of OMAP4 chips. This patch includes definitions for these chip versions:
. OMAP4430
. OMAP4460
. OMAP4470
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig | 14 ++
drivers/staging/omap-thermal/Makefile|1 +
drivers/staging/omap-thermal/omap-bandgap.c | 14 ++
drivers/staging/omap-thermal/omap-bandgap.h | 10 +
drivers/staging/omap-thermal/omap4-thermal.c | 259 ++
5 files changed, 298 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap4-thermal.c
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index b3996cc..e16f0bc 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -17,3 +17,17 @@ config OMAP_THERMAL
If you say yes here you want to get support for generic thermal
framework for the Texas Instruments OMAP4460+ on die bandgap
temperature sensor.
+
+config OMAP4_THERMAL
+ bool Texas Instruments OMAP4 thermal support
+ depends on OMAP_BANDGAP
+ depends on ARCH_OMAP4
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP4 SoC family. The current chip supported are:
+ - OMAP4430
+ - OMAP4460
+ - OMAP4470
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index fcdf773..76f9c19 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
+omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 3b2cd87..cc0869a 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1143,6 +1143,20 @@ static const struct dev_pm_ops omap_bandgap_dev_pm_ops =
{
#endif
static const struct of_device_id of_omap_bandgap_match[] = {
+#ifdef CONFIG_OMAP4_THERMAL
+ {
+ .compatible = ti,omap4430-bandgap,
+ .data = (void *)omap4430_data,
+ },
+ {
+ .compatible = ti,omap4460-bandgap,
+ .data = (void *)omap4460_data,
+ },
+ {
+ .compatible = ti,omap4470-bandgap,
+ .data = (void *)omap4470_data,
+ },
+#endif
/* Sentinel */
{ },
};
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 8b9883d..6d442fe 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -422,4 +422,14 @@ int omap_bandgap_set_sensor_data(struct omap_bandgap
*bg_ptr, int id,
void *data);
void *omap_bandgap_get_sensor_data(struct omap_bandgap *bg_ptr, int id);
+#ifdef CONFIG_OMAP4_THERMAL
+extern const struct omap_bandgap_data omap4430_data;
+extern const struct omap_bandgap_data omap4460_data;
+extern const struct omap_bandgap_data omap4470_data;
+#else
+#define omap4430_data NULL
+#define omap4460_data NULL
+#define omap4470_data NULL
+#endif
+
#endif
diff --git a/drivers/staging/omap-thermal/omap4-thermal.c
b/drivers/staging/omap-thermal/omap4-thermal.c
new file mode 100644
index 000..fa9dbcd
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap4-thermal.c
@@ -0,0 +1,259 @@
+/*
+ * OMAP4 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include omap-thermal.h
+#include omap-bandgap.h
+
+/*
+ * OMAP4430 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap4430_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP4430_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4430_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK
[PATCHv3 4/4] staging: omap-thermal: add OMAP5 data structures
This patch adds the data structures needed for proper registration
of OMAP5 chips. This patch includes definitions for these chip versions:
. OMAP5430
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig | 12 +
drivers/staging/omap-thermal/Makefile|1 +
drivers/staging/omap-thermal/omap-bandgap.c |6 +
drivers/staging/omap-thermal/omap-bandgap.h |6 +
drivers/staging/omap-thermal/omap5-thermal.c | 297 ++
5 files changed, 322 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap5-thermal.c
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index e16f0bc..02130e1 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -31,3 +31,15 @@ config OMAP4_THERMAL
This includes alert interrupts generation and also the TSHUT
support.
+
+config OMAP5_THERMAL
+ bool Texas Instruments OMAP5 thermal support
+ depends on OMAP_BANDGAP
+ depends on SOC_OMAP5
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP5 SoC family. The current chip supported are:
+ - OMAP5430
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index 76f9c19..091c4d2 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
+omap-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal.o
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index cc0869a..55f3f5d 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1157,6 +1157,12 @@ static const struct of_device_id of_omap_bandgap_match[]
= {
.data = (void *)omap4470_data,
},
#endif
+#ifdef CONFIG_OMAP5_THERMAL
+ {
+ .compatible = ti,omap5430-bandgap,
+ .data = (void *)omap5430_data,
+ },
+#endif
/* Sentinel */
{ },
};
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 6d442fe..78aed75 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -432,4 +432,10 @@ extern const struct omap_bandgap_data omap4470_data;
#define omap4470_data NULL
#endif
+#ifdef CONFIG_OMAP5_THERMAL
+extern const struct omap_bandgap_data omap5430_data;
+#else
+#define omap5430_data NULL
+#endif
+
#endif
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
new file mode 100644
index 000..0658af2
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -0,0 +1,297 @@
+/*
+ * OMAP5 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include omap-bandgap.h
+#include omap-thermal.h
+
+/*
+ * omap5430 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap5430_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP5430_TEMP_SENSOR_MPU_OFFSET,
+ .bgap_tempsoff_mask = OMAP5430_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask = OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP5430_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP5430_MASK_HOT_MPU_MASK,
+ .mask_cold_mask = OMAP5430_MASK_COLD_MPU_MASK,
+
+ .bgap_mode_ctrl = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
+ .mode_ctrl_mask = OMAP5430_REPEAT_MODE_MASK,
+
+ .bgap_counter = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
+ .counter_mask = OMAP5430_COUNTER_MASK,
+
+ .bgap_threshold = OMAP5430_BGAP_THRESHOLD_MPU_OFFSET,
+ .threshold_thot_mask = OMAP5430_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP5430_T_COLD_MASK
[PATCHv4 0/4] staging: adding OMAP bandgap driver
Greg, Here is again the OMAP BG driver, under staging area. I fixed the compilation issue I didn't see, wrt implicit function declarations. As I mentioned on other thread, my compilation test didn't see it, that's why I thought it was fine to send it. I also limited the driver compilation to OMAP4/5. Cheers, Eduardo Valentin (4): staging: OMAP4+: thermal: introduce bandgap temperature sensor staging: omap-thermal: common code to expose driver to thermal framework staging: omap-thermal: add OMAP4 data structures staging: omap-thermal: add OMAP5 data structures drivers/staging/Kconfig|2 + drivers/staging/Makefile |1 + drivers/staging/omap-thermal/Kconfig | 46 + drivers/staging/omap-thermal/Makefile |5 + drivers/staging/omap-thermal/TODO | 28 + drivers/staging/omap-thermal/omap-bandgap.c| 1187 drivers/staging/omap-thermal/omap-bandgap.h| 441 drivers/staging/omap-thermal/omap-thermal-common.c | 364 ++ drivers/staging/omap-thermal/omap-thermal.h| 108 ++ drivers/staging/omap-thermal/omap4-thermal.c | 259 + drivers/staging/omap-thermal/omap5-thermal.c | 297 + drivers/staging/omap-thermal/omap_bandgap.txt | 30 + 12 files changed, 2768 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/omap-thermal/Kconfig create mode 100644 drivers/staging/omap-thermal/Makefile create mode 100644 drivers/staging/omap-thermal/TODO create mode 100644 drivers/staging/omap-thermal/omap-bandgap.c create mode 100644 drivers/staging/omap-thermal/omap-bandgap.h create mode 100644 drivers/staging/omap-thermal/omap-thermal-common.c create mode 100644 drivers/staging/omap-thermal/omap-thermal.h create mode 100644 drivers/staging/omap-thermal/omap4-thermal.c create mode 100644 drivers/staging/omap-thermal/omap5-thermal.c create mode 100644 drivers/staging/omap-thermal/omap_bandgap.txt -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 1/4] staging: OMAP4+: thermal: introduce bandgap temperature sensor
In the System Control Module, OMAP supplies a voltage reference and a temperature sensor feature that are gathered in the band gap voltage and temperature sensor (VBGAPTS) module. The band gap provides current and voltage reference for its internal circuits and other analog IP blocks. The analog-to-digital converter (ADC) produces an output value that is proportional to the silicon temperature. This patch provides a platform driver which expose this feature. It is moduled as a MFD child of the System Control Module core MFD driver. This driver provides only APIs to access the device properties, like temperature, thresholds and update rate. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/omap-thermal/Kconfig | 11 + drivers/staging/omap-thermal/Makefile |2 + drivers/staging/omap-thermal/TODO | 28 + drivers/staging/omap-thermal/omap-bandgap.c | 1167 + drivers/staging/omap-thermal/omap-bandgap.h | 425 + drivers/staging/omap-thermal/omap_bandgap.txt | 30 + 8 files changed, 1666 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/omap-thermal/Kconfig create mode 100644 drivers/staging/omap-thermal/Makefile create mode 100644 drivers/staging/omap-thermal/TODO create mode 100644 drivers/staging/omap-thermal/omap-bandgap.c create mode 100644 drivers/staging/omap-thermal/omap-bandgap.h create mode 100644 drivers/staging/omap-thermal/omap_bandgap.txt Patch changelog: Change from V1 to V2: - Compilation fixes on Kconfig and Makefiles under drivers/staging Change from V2 to V3: - Removed empty line from end of Kconfig file, so git is happy while applying - Keerthy's SOB now matches Copyright notice found in files Change from V3 to V4: - Fixed -Werror-implicit-function-declaration compilation issues. - Limited driver compilation to OMAP4/5 diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index d3934d7..e3402d5 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -134,4 +134,6 @@ source drivers/staging/gdm72xx/Kconfig source drivers/staging/csr/Kconfig +source drivers/staging/omap-thermal/Kconfig + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 5b2219a..dbbdbbc 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -59,3 +59,4 @@ obj-$(CONFIG_USB_WPAN_HCD)+= ozwpan/ obj-$(CONFIG_USB_G_CCG)+= ccg/ obj-$(CONFIG_WIMAX_GDM72XX)+= gdm72xx/ obj-$(CONFIG_CSR_WIFI) += csr/ +obj-y += omap-thermal/ diff --git a/drivers/staging/omap-thermal/Kconfig b/drivers/staging/omap-thermal/Kconfig new file mode 100644 index 000..8c9979d --- /dev/null +++ b/drivers/staging/omap-thermal/Kconfig @@ -0,0 +1,11 @@ +config OMAP_BANDGAP + tristate Texas Instruments OMAP4+ temperature sensor driver + depends on THERMAL + depends on ARCH_OMAP4 || SOC_OMAP5 + help + If you say yes here you get support for the Texas Instruments + OMAP4460+ on die bandgap temperature sensor support. The register + set is part of system control module. + + This includes alert interrupts generation and also the TSHUT + support. diff --git a/drivers/staging/omap-thermal/Makefile b/drivers/staging/omap-thermal/Makefile new file mode 100644 index 000..c92a854 --- /dev/null +++ b/drivers/staging/omap-thermal/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o +omap-thermal-y := omap-bandgap.o diff --git a/drivers/staging/omap-thermal/TODO b/drivers/staging/omap-thermal/TODO new file mode 100644 index 000..9e23cc4 --- /dev/null +++ b/drivers/staging/omap-thermal/TODO @@ -0,0 +1,28 @@ +List of TODOs (by Eduardo Valentin) + +on omap-bandgap.c: +- Rework locking +- Improve driver code by adding usage of regmap-mmio +- Test every exposed API to userland +- Add support to hwmon +- Review and revisit all API exposed +- Revisit PM support +- Revisit data structures and simplify them +- Once SCM-core api settles, update this driver accordingly + +on omap-thermal-common.c/omap-thermal.h: +- Revisit extrapolation constants for O4/O5 +- Revisit need for locking +- Revisit trips and its definitions +- Revisit trending + +on omap5-thermal.c +- Add support for GPU cooling + +generally: +- write Kconfig dependencies so that omap variants are covered +- make checkpatch.pl and sparse happy +- make sure this code works on OMAP4430, OMAP4460 and OMAP5430 +- update documentation + +Copy patches to Eduardo Valentin eduardo.valen...@ti.com diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c new file mode 100644 index 000..8ea6264 --- /dev/null +++ b/drivers/staging/omap-thermal/omap-bandgap.c
[PATCHv4 3/4] staging: omap-thermal: add OMAP4 data structures
This patch adds the data structures needed for proper registration
of OMAP4 chips. This patch includes definitions for these chip versions:
. OMAP4430
. OMAP4460
. OMAP4470
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig | 14 ++
drivers/staging/omap-thermal/Makefile|1 +
drivers/staging/omap-thermal/omap-bandgap.c | 14 ++
drivers/staging/omap-thermal/omap-bandgap.h | 10 +
drivers/staging/omap-thermal/omap4-thermal.c | 259 ++
5 files changed, 298 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap4-thermal.c
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index f44228c..b0105d2 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -18,3 +18,17 @@ config OMAP_THERMAL
If you say yes here you want to get support for generic thermal
framework for the Texas Instruments OMAP4460+ on die bandgap
temperature sensor.
+
+config OMAP4_THERMAL
+ bool Texas Instruments OMAP4 thermal support
+ depends on OMAP_BANDGAP
+ depends on ARCH_OMAP4
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP4 SoC family. The current chip supported are:
+ - OMAP4430
+ - OMAP4460
+ - OMAP4470
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index fcdf773..76f9c19 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
+omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 8ea6264..5158aa8 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1144,6 +1144,20 @@ static const struct dev_pm_ops omap_bandgap_dev_pm_ops =
{
#endif
static const struct of_device_id of_omap_bandgap_match[] = {
+#ifdef CONFIG_OMAP4_THERMAL
+ {
+ .compatible = ti,omap4430-bandgap,
+ .data = (void *)omap4430_data,
+ },
+ {
+ .compatible = ti,omap4460-bandgap,
+ .data = (void *)omap4460_data,
+ },
+ {
+ .compatible = ti,omap4470-bandgap,
+ .data = (void *)omap4470_data,
+ },
+#endif
/* Sentinel */
{ },
};
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 8b9883d..6d442fe 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -422,4 +422,14 @@ int omap_bandgap_set_sensor_data(struct omap_bandgap
*bg_ptr, int id,
void *data);
void *omap_bandgap_get_sensor_data(struct omap_bandgap *bg_ptr, int id);
+#ifdef CONFIG_OMAP4_THERMAL
+extern const struct omap_bandgap_data omap4430_data;
+extern const struct omap_bandgap_data omap4460_data;
+extern const struct omap_bandgap_data omap4470_data;
+#else
+#define omap4430_data NULL
+#define omap4460_data NULL
+#define omap4470_data NULL
+#endif
+
#endif
diff --git a/drivers/staging/omap-thermal/omap4-thermal.c
b/drivers/staging/omap-thermal/omap4-thermal.c
new file mode 100644
index 000..fa9dbcd
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap4-thermal.c
@@ -0,0 +1,259 @@
+/*
+ * OMAP4 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include omap-thermal.h
+#include omap-bandgap.h
+
+/*
+ * OMAP4430 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap4430_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP4430_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4430_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK
[PATCHv4 4/4] staging: omap-thermal: add OMAP5 data structures
This patch adds the data structures needed for proper registration
of OMAP5 chips. This patch includes definitions for these chip versions:
. OMAP5430
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig | 12 +
drivers/staging/omap-thermal/Makefile|1 +
drivers/staging/omap-thermal/omap-bandgap.c |6 +
drivers/staging/omap-thermal/omap-bandgap.h |6 +
drivers/staging/omap-thermal/omap5-thermal.c | 297 ++
5 files changed, 322 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap5-thermal.c
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index b0105d2..30cbc3b 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -32,3 +32,15 @@ config OMAP4_THERMAL
This includes alert interrupts generation and also the TSHUT
support.
+
+config OMAP5_THERMAL
+ bool Texas Instruments OMAP5 thermal support
+ depends on OMAP_BANDGAP
+ depends on SOC_OMAP5
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP5 SoC family. The current chip supported are:
+ - OMAP5430
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index 76f9c19..091c4d2 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
+omap-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal.o
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 5158aa8..c556abb 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1158,6 +1158,12 @@ static const struct of_device_id of_omap_bandgap_match[]
= {
.data = (void *)omap4470_data,
},
#endif
+#ifdef CONFIG_OMAP5_THERMAL
+ {
+ .compatible = ti,omap5430-bandgap,
+ .data = (void *)omap5430_data,
+ },
+#endif
/* Sentinel */
{ },
};
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 6d442fe..78aed75 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -432,4 +432,10 @@ extern const struct omap_bandgap_data omap4470_data;
#define omap4470_data NULL
#endif
+#ifdef CONFIG_OMAP5_THERMAL
+extern const struct omap_bandgap_data omap5430_data;
+#else
+#define omap5430_data NULL
+#endif
+
#endif
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
new file mode 100644
index 000..0658af2
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -0,0 +1,297 @@
+/*
+ * OMAP5 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include omap-bandgap.h
+#include omap-thermal.h
+
+/*
+ * omap5430 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap5430_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP5430_TEMP_SENSOR_MPU_OFFSET,
+ .bgap_tempsoff_mask = OMAP5430_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask = OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP5430_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP5430_MASK_HOT_MPU_MASK,
+ .mask_cold_mask = OMAP5430_MASK_COLD_MPU_MASK,
+
+ .bgap_mode_ctrl = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
+ .mode_ctrl_mask = OMAP5430_REPEAT_MODE_MASK,
+
+ .bgap_counter = OMAP5430_BGAP_COUNTER_MPU_OFFSET,
+ .counter_mask = OMAP5430_COUNTER_MASK,
+
+ .bgap_threshold = OMAP5430_BGAP_THRESHOLD_MPU_OFFSET,
+ .threshold_thot_mask = OMAP5430_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP5430_T_COLD_MASK
[PATCHv4 2/4] staging: omap-thermal: common code to expose driver to thermal framework
This patch has the common thermal framework support for OMAP
bandgap driver. It includes the zone registration and unregistration,
the cpu cooling and the trip definitions.
The trips definition is essentially one trip for passive cooling
using the generic cpu cooling device and another one for thermal
shutdown. The cpu cooling device is built based on the existing
cpu freq table. The build should be agnostic to omap version,
but relies that cpufreq is up and running by the time the driver
registers the cpu cooling, as it relies on the table walk api
from cpufreq.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/Kconfig |9 +
drivers/staging/omap-thermal/Makefile |1 +
drivers/staging/omap-thermal/omap-thermal-common.c | 364
drivers/staging/omap-thermal/omap-thermal.h| 108 ++
4 files changed, 482 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/omap-thermal/omap-thermal-common.c
create mode 100644 drivers/staging/omap-thermal/omap-thermal.h
Patch changelog:
Change from V1 to V2/3: Compilation fixes on Kconfig and Makefiles under
drivers/staging
Change from V3 to V4: removed code that is dependent on thermal framework
upgraded code
(will upgrade this driver once Rui send new API changes). This way, once
CPU_THERMAL gets
merged, it wont generate compilation issues.
diff --git a/drivers/staging/omap-thermal/Kconfig
b/drivers/staging/omap-thermal/Kconfig
index 8c9979d..f44228c 100644
--- a/drivers/staging/omap-thermal/Kconfig
+++ b/drivers/staging/omap-thermal/Kconfig
@@ -9,3 +9,12 @@ config OMAP_BANDGAP
This includes alert interrupts generation and also the TSHUT
support.
+
+config OMAP_THERMAL
+ bool Texas Instruments OMAP4+ thermal framework support
+ depends on OMAP_BANDGAP
+ depends on CPU_THERMAL
+ help
+ If you say yes here you want to get support for generic thermal
+ framework for the Texas Instruments OMAP4460+ on die bandgap
+ temperature sensor.
diff --git a/drivers/staging/omap-thermal/Makefile
b/drivers/staging/omap-thermal/Makefile
index c92a854..fcdf773 100644
--- a/drivers/staging/omap-thermal/Makefile
+++ b/drivers/staging/omap-thermal/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
+omap-thermal-$(CONFIG_OMAP_THERMAL)+= omap-thermal-common.o
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
new file mode 100644
index 000..0675a5e
--- /dev/null
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -0,0 +1,364 @@
+/*
+ * OMAP thermal driver interface
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/mutex.h
+#include linux/gfp.h
+#include linux/kernel.h
+#include linux/workqueue.h
+#include linux/thermal.h
+#include linux/cpufreq.h
+#include linux/cpu_cooling.h
+
+#include omap-thermal.h
+#include omap-bandgap.h
+
+/* common data structures */
+struct omap_thermal_data {
+ struct thermal_zone_device *omap_thermal;
+ struct thermal_cooling_device *cool_dev;
+ struct omap_bandgap *bg_ptr;
+ enum thermal_device_mode mode;
+ struct work_struct thermal_wq;
+ int sensor_id;
+};
+
+static void omap_thermal_work(struct work_struct *work)
+{
+ struct omap_thermal_data *data = container_of(work,
+ struct omap_thermal_data, thermal_wq);
+
+ thermal_zone_device_update(data-omap_thermal);
+
+ dev_dbg(data-omap_thermal-device, updated thermal zone %s\n,
+ data-omap_thermal-type);
+}
+
+/**
+ * omap_thermal_hotspot_temperature - returns sensor extrapolated temperature
+ * @t: omap sensor temperature
+ * @s: omap sensor slope value
+ * @c: omap sensor const value
+ */
+static inline int omap_thermal_hotspot_temperature(int t, int s, int c)
+{
+ int delta = t * s / 1000 + c;
+
+ if (delta 0)
+ delta = 0;
+
+ return t + delta;
+}
+
+/* thermal zone ops */
+/* Get temperature callback function
Re: [PATCH 1/5] staging: omap-thermal: fix error check in omap_thermal_expose_sensor() and in omap_thermal_register_cpu_cooling().
On 12-12-2012 02:24, Cyril Roelandt wrote: The omap_bandgap_get_sensor_data() function returns ERR_PTR(), so we need to use IS_ERR() rather than a NULL check. Signed-off-by: Cyril Roelandt tipec...@gmail.com Acked-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-thermal-common.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c b/drivers/staging/omap-thermal/omap-thermal-common.c index 61f1070..79a55aa 100644 --- a/drivers/staging/omap-thermal/omap-thermal-common.c +++ b/drivers/staging/omap-thermal/omap-thermal-common.c @@ -260,7 +260,7 @@ int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id, data = omap_bandgap_get_sensor_data(bg_ptr, id); - if (!data) + if (IS_ERR(data)) data = omap_thermal_build_data(bg_ptr, id); if (!data) @@ -309,7 +309,7 @@ int omap_thermal_register_cpu_cooling(struct omap_bandgap *bg_ptr, int id) struct omap_thermal_data *data; data = omap_bandgap_get_sensor_data(bg_ptr, id); - if (!data) + if (IS_ERR(data)) data = omap_thermal_build_data(bg_ptr, id); if (!data) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: device thermal limits represented in device tree nodes
Pawel, all,
On 06-08-2013 07:14, Pawel Moll wrote:
Apologies about the delay, I was otherwise engaged for a week...
I do also excuse for my delay, as I was also engaged for a week or so.
I hope you haven't lost all motivation to work on this subject, as it's
really worth the while!
Not really! quite the opposite. Although I was looking at some other
stuff, I got this series also tested on different boards and wrote down
a couple of improvements I will be working in the coming days. Indeed,
it is worth moving forward with this work.
On Fri, 2013-07-26 at 20:55 +0100, Eduardo Valentin wrote:
On 25-07-2013 13:33, Pawel Moll wrote:
On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
thermal_zone {
type = CPU;
So what does this exactly mean? What is so special about CPU? What other
types you've got there? (Am I just lazy not looking at the numerous
links you provided? ;-)
Hehehe. OK. Type is supposed to describe what your zone is representing.
As in a name? So, for example The board, PSU? What I meant to ask
was: does the string carry any meaning?
You haven't commended on this...
The string is supposed to carry meaning, yes. Couple of common used:
CPU, GPU, PCB, LCD
trips {
alert@10{
temperature = 10; /* milliCelsius
hysteresis = 2000; /* milliCelsius */
type = THERMAL_TRIP_PASSIVE;
};
crit@125000{
temperature = 125000; /* milliCelsius
hysteresis = 2000; /* milliCelsius */
type = THERMAL_TRIP_CRITICAL;
};
};
bind_params {
action@0{
cooling_device = thermal-cpufreq;
Why is it a string? It seems very Linux-y... (cpufreq) Is there any
particular reason not to have phandles to the fans that have any impact
on the zone?
Because fans are not the only way to cool your system, specially those
systems that don't feature fans. Managing the speed of your CPU is one
example of lowering temperature without fans. Managing the load on your
system is another way. These are obviously, virtual concepts. And
because we have physical ways and logical ways to cool the zone, then I
didnt put a phandle to a device there.
virtual concepts... This is where my problem lies... It's not hardware
so it doesn't seem to belong in the tree at the first sight. Shouldn't
Yeah, in fact, this is exactly the point that creates most of the
disagreement. You may check Guenter's arguments against this proposal
(in my original RFC email, there is a link to it).
Well, if one don't want to see this as a 'virtual concept' it could say
the cooling device is the cpu itself:
cooling_device = cpu0;
Would this create any particular problem at the driver/framework side?
In this case, I believe CPUfreq driver must be thermal aware in this
case. And we need to cook a way to, whenever there is such link, the
cpufreq driver instantiates the cooling mechanism. But I need to think a
little bit more on this, will come back on this point soon.
it focus on physical data instead? As in: point at devices that have
some impact on the conditions? For example, you can say please, do the
right thing to cool your environment down to both CPU and fan, can't
you? The cooling driver for the CPU would know that it has to slow
down, while a driver for the fan would know that it has to speed up ;-)
What I'm trying to say is that in my opinion the tree should simply link
the object, the sensor and the actuator. Nothing more, nothing less.
OK. I think it would be a little unfair to have only links, without
describing what this link is supposed to be or how it is supposed to be
used. In previous discussions, I have mentioned two similar examples
already existing in DT. Here are they: regulator bindings, one does not
describe only which device connects to which regulator, but also needs
to describe, voltage limits, current limits, offsets, and other
properties. And an existing 'virtual concept' would be predefined CPU
OPPs, that feed the opp layer. Those are configurations of the hardware
that define a 'virtual' concept of operating point.
So, saying we need to describe only physical connections or touchable
things would be a little unfair, IMO. Besides, thermal is still physical
:-).
Believe me, I'm trying to be as fair as possible :-) and I see a lot of
value in describing the thermal properties of the platforms in the tree.
It's just that we really want to focus on describing the hardware, not
policies. And as you have already spent so much time on the matter, you
are in the best position to find the best set of *physical* properties
that would allow to make the right decision in the code. Could you,
please, try to make one step back and have another look
Re: RFC: device thermal limits represented in device tree nodes
On 25-07-2013 12:15, Pawel Moll wrote:
On Wed, 2013-07-24 at 16:04 +0100, Eduardo Valentin wrote:
1. As you have pointed out, the thermal limits are related to the
*device being monitored*, not the sensor itself.
Yeah, thinking of it now, this original proposal, it lacks a stronger
relationship mapping between monitored and monitoring devices. But it
does have it..
2. Therefore the tree should express relation between those two; a
sensor mode should be connected (via phandle most likely) to the device
.. this is done, more or less, by means of the 'type' property (see
original RFC binding).
I'm not sure what do you mean (regarding type), but I think I got what
I wanted with the monitoring_device phandles (shouldn't it be
_device*s* then? ;-).
yes. it is supposed to be devices.
For example:
cpu0: cpu@0 {
/* ... cpu needed bindings */
thermal_zone {
type = CPU;
So what does this exactly mean? What is so special about CPU? What other
types you've got there? (Am I just lazy not looking at the numerous
links you provided? ;-)
Hehehe. OK. Type is supposed to describe what your zone is representing.
monitoring_device = sensor@
sensor@;
mask = 0x03; /* trips writability */
passive_delay = 250; /* milliseconds */
polling_delay = 1000; /* milliseconds */
policy = step_wise;
The word policy doesn't sound to me like a hardware feature,
wouldn't you agree?
Agreed. As I mentioned in other email, we can leave this to OS decide
what to use, by default, for instance.
trips {
alert@10{
temperature = 10; /* milliCelsius
hysteresis = 2000; /* milliCelsius */
type = THERMAL_TRIP_PASSIVE;
};
crit@125000{
temperature = 125000; /* milliCelsius
hysteresis = 2000; /* milliCelsius */
type = THERMAL_TRIP_CRITICAL;
};
};
bind_params {
action@0{
cooling_device = thermal-cpufreq;
Why is it a string? It seems very Linux-y... (cpufreq) Is there any
particular reason not to have phandles to the fans that have any impact
on the zone?
Because fans are not the only way to cool your system, specially those
systems that don't feature fans. Managing the speed of your CPU is one
example of lowering temperature without fans. Managing the load on your
system is another way. These are obviously, virtual concepts. And
because we have physical ways and logical ways to cool the zone, then I
didnt put a phandle to a device there.
weight = 100; /* percentage */
Does this mean: how successful will be the particular fan?
Another way, as I mentioned in the original RFC, an option would be to
have the thermal_zone node not embedded in any device node. But them, we
would need to firmly link it to other device nodes, to describe what is
monitored and what is used for monitoring.
You mean the zone nodes would live at the top level of the tree? To my
mind the root represents the device (the board, whatever you call it),
which, I guess, may be what you want, if the zone covers the whole
device? (as in: one fan and one sensor somewhere in the box and the only
thing you may do is to check the ambient temperature and start the fan
if it's to high)
Yes, for cases that we want to map zones at board level, they could be
not embedded to a specific device node.
With the above I believe we could have dts(i) files describing only
thermal, for instance.
You can include a dtsi inside the device node, no problem with that:
/dts-v1/;
/ {
smb {
compatible = simple-bus;
/include/ vexpress-v2m-rs1.dtsi
};
};
OK. got your point. What I was trying to highlight is that we could have
zones not inside device nodes, then we could write them in a thermal
dtsi. And in that case, you probably dont want to include the complete
file inside a device node.
Pawel
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: RFC: device thermal limits represented in device tree nodes
On 25-07-2013 12:38, Pawel Moll wrote: On Thu, 2013-07-25 at 17:15 +0100, Pawel Moll wrote: Another way, as I mentioned in the original RFC, an option would be to have the thermal_zone node not embedded in any device node. But them, we would need to firmly link it to other device nodes, to describe what is monitored and what is used for monitoring. You mean the zone nodes would live at the top level of the tree? To my mind the root represents the device (the board, whatever you call it), What I wanted to say was: ... so the zone would still be embedded in a device node :-) ahh ok.. I see. Pawel -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [RESEND PATCH V1 1/9] cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling'
On 25-07-2013 19:28, Rafael J. Wysocki wrote:
On Wednesday, July 17, 2013 11:17:20 AM Eduardo Valentin wrote:
This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
it can be flagged at the cpu0 device tree node, with the boolean
property 'needs-cooling'.
In case this boolean is present, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.
Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.
Cc: Rafael J. Wysocki r...@sisk.pl
FWIW, this change is fine by me, but I guess it should be handled along with
the entire series.
Raphael, thanks for your review.
Yeah, this change must be handled along with the other changes in this
series. There is still ongoing discussion in DT mailing list with
respect to thermal bindings. Thus, for now, this patch is on hold.
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 3 +++
drivers/cpufreq/cpufreq-cpu0.c | 8
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..e8ff916 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,8 @@ Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- needs-cooling: The generic cpu cooling (freq clipping) is loaded by the
+generic cpufreq-cpu0 driver in case the device tree node has this boolean.
Examples:
@@ -33,6 +35,7 @@ cpus {
198000 85
;
clock-latency = 61036; /* two CLK32 periods */
+needs-cooling;
};
cpu@1 {
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..4a8747a 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -20,6 +20,9 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/slab.h
+#include linux/thermal.h
+#include linux/cpu_cooling.h
+#include linux/cpumask.h
static unsigned int transition_latency;
static unsigned int voltage_tolerance; /* in percentage */
@@ -28,6 +31,7 @@ static struct device *cpu_dev;
static struct clk *cpu_clk;
static struct regulator *cpu_reg;
static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
static int cpu0_verify_speed(struct cpufreq_policy *policy)
{
@@ -268,6 +272,9 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
goto out_free_table;
}
+if (of_property_read_bool(np, needs-cooling))
+cdev = cpufreq_cooling_register(cpu_present_mask);
+
of_node_put(np);
of_node_put(parent);
return 0;
@@ -283,6 +290,7 @@ out_put_parent:
static int cpu0_cpufreq_remove(struct platform_device *pdev)
{
+cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(cpu0_cpufreq_driver);
opp_free_cpufreq_table(cpu_dev, freq_table);
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 27/27] thermal: ti-bandgap: cleanup resource allocation
On 23-07-2013 14:02, Wolfram Sang wrote:
When cleaning up usage of devm_ioremap_resource, I found that resource
allocation in this driver is ugly and buggy. If resource[0] is not
found, bgp-base will end up NULL, so OOPS. All other resources get
ioremapped, but their pointers are discarded, so why bother. So, let's
keep things simple. Just remap resource[0] and pass the error, if any.
Compile tested only, due to no hardware.
Nack, this will actually break the driver. This device has several
sections of registers, and not a single io region. Check
Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt for examples.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Please apply via the subsystem-tree.
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 9dfd471..416be5d 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1130,7 +1130,6 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
const struct of_device_id *of_id;
struct ti_bandgap *bgp;
struct resource *res;
- int i;
/* just for the sake */
if (!node) {
@@ -1156,21 +1155,10 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
return ERR_PTR(-ENOMEM);
}
- i = 0;
- do {
- void __iomem *chunk;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, i);
- if (!res)
- break;
- chunk = devm_ioremap_resource(pdev-dev, res);
- if (i == 0)
- bgp-base = chunk;
- if (IS_ERR(chunk))
- return ERR_CAST(chunk);
In case resource 0 is not found, the error will be repassed.
-
- i++;
- } while (res);
And yes, other IORESOURCE_MEM resources are required, depending on chip
version.
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ bgp-base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(bgp-base))
+ return bgp-base;
if (TI_BANDGAP_HAS(bgp, TSHUT)) {
bgp-tshut_gpio = of_get_gpio(node, 0);
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: RFC: device thermal limits represented in device tree nodes
On 25-07-2013 13:33, Pawel Moll wrote:
On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
thermal_zone {
type = CPU;
So what does this exactly mean? What is so special about CPU? What other
types you've got there? (Am I just lazy not looking at the numerous
links you provided? ;-)
Hehehe. OK. Type is supposed to describe what your zone is representing.
As in a name? So, for example The board, PSU? What I meant to ask
was: does the string carry any meaning?
monitoring_device = sensor@
sensor@;
mask = 0x03; /* trips writability */
passive_delay = 250; /* milliseconds */
polling_delay = 1000; /* milliseconds */
policy = step_wise;
The word policy doesn't sound to me like a hardware feature,
wouldn't you agree?
Agreed. As I mentioned in other email, we can leave this to OS decide
what to use, by default, for instance.
Cool, I believe it is the right thing to do.
trips {
alert@10{
temperature = 10; /* milliCelsius
hysteresis = 2000; /* milliCelsius */
type = THERMAL_TRIP_PASSIVE;
};
crit@125000{
temperature = 125000; /* milliCelsius
hysteresis = 2000; /* milliCelsius */
type = THERMAL_TRIP_CRITICAL;
};
};
bind_params {
action@0{
cooling_device = thermal-cpufreq;
Why is it a string? It seems very Linux-y... (cpufreq) Is there any
particular reason not to have phandles to the fans that have any impact
on the zone?
Because fans are not the only way to cool your system, specially those
systems that don't feature fans. Managing the speed of your CPU is one
example of lowering temperature without fans. Managing the load on your
system is another way. These are obviously, virtual concepts. And
because we have physical ways and logical ways to cool the zone, then I
didnt put a phandle to a device there.
virtual concepts... This is where my problem lies... It's not hardware
so it doesn't seem to belong in the tree at the first sight. Shouldn't
Yeah, in fact, this is exactly the point that creates most of the
disagreement. You may check Guenter's arguments against this proposal
(in my original RFC email, there is a link to it).
Well, if one don't want to see this as a 'virtual concept' it could say
the cooling device is the cpu itself:
cooling_device = cpu0;
it focus on physical data instead? As in: point at devices that have
some impact on the conditions? For example, you can say please, do the
right thing to cool your environment down to both CPU and fan, can't
you? The cooling driver for the CPU would know that it has to slow
down, while a driver for the fan would know that it has to speed up ;-)
What I'm trying to say is that in my opinion the tree should simply link
the object, the sensor and the actuator. Nothing more, nothing less.
OK. I think it would be a little unfair to have only links, without
describing what this link is supposed to be or how it is supposed to be
used. In previous discussions, I have mentioned two similar examples
already existing in DT. Here are they: regulator bindings, one does not
describe only which device connects to which regulator, but also needs
to describe, voltage limits, current limits, offsets, and other
properties. And an existing 'virtual concept' would be predefined CPU
OPPs, that feed the opp layer. Those are configurations of the hardware
that define a 'virtual' concept of operating point.
So, saying we need to describe only physical connections or touchable
things would be a little unfair, IMO. Besides, thermal is still physical
:-).
Thanks for your time!
Thanks for the input!
Pawel
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
[PATCH 0/5] drivers: thermal: several fixes
Hello all, This is simple patch set with fixes on core thermal framework. These fixes are a set of changes that I find needed that I found during the process of attempting to describe thermal data using device tree. These patches touch several drivers, as there is an API change. I have only compiled tested on other drivers. I have done a runtime test on OMAP and DRA devices though. Please feel free to perform your own test and report issues if you find some. All best, Eduardo Valentin (5): thermal: hwmon: move hwmon support to single file drivers: thermal: parent virtual hwmon with thermal zone drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional thermal: thermal_core: allow binding with limits on bind_params drivers: thermal: add check when unregistering cpu cooling Documentation/thermal/sysfs-api.txt| 11 +- drivers/acpi/thermal.c | 6 +- drivers/platform/x86/acerhdf.c | 3 +- drivers/platform/x86/intel_mid_thermal.c | 2 +- drivers/power/power_supply_core.c | 2 +- drivers/thermal/Kconfig| 9 + drivers/thermal/Makefile | 3 + drivers/thermal/armada_thermal.c | 2 +- drivers/thermal/cpu_cooling.c | 6 +- drivers/thermal/db8500_thermal.c | 2 +- drivers/thermal/dove_thermal.c | 2 +- drivers/thermal/exynos_thermal.c | 2 +- drivers/thermal/kirkwood_thermal.c | 2 +- drivers/thermal/rcar_thermal.c | 2 +- drivers/thermal/spear_thermal.c| 2 +- drivers/thermal/thermal_core.c | 287 ++--- drivers/thermal/thermal_hwmon.c| 269 +++ drivers/thermal/thermal_hwmon.h| 49 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +- drivers/thermal/x86_pkg_temp_thermal.c | 2 +- include/linux/thermal.h| 12 +- 21 files changed, 398 insertions(+), 279 deletions(-) create mode 100644 drivers/thermal/thermal_hwmon.c create mode 100644 drivers/thermal/thermal_hwmon.h -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] thermal: hwmon: move hwmon support to single file
In order to improve code organization, this patch
moves the hwmon sysfs support to a file named
thermal_hwmon. This helps to add extra support
for hwmon without scrambling the code.
In order to do this move, the hwmon list head is now
using its own locking. Before, the list used
the global thermal locking. Also, some minor changes
in the code were required, as recommended by checkpatch.pl.
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Durgadoss R durgados...@intel.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/Kconfig | 9 ++
drivers/thermal/Makefile| 3 +
drivers/thermal/thermal_core.c | 255 +
drivers/thermal/thermal_hwmon.c | 269
drivers/thermal/thermal_hwmon.h | 49
5 files changed, 331 insertions(+), 254 deletions(-)
create mode 100644 drivers/thermal/thermal_hwmon.c
create mode 100644 drivers/thermal/thermal_hwmon.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e988c81..7fb16bc 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -17,8 +17,17 @@ if THERMAL
config THERMAL_HWMON
bool
+ prompt Expose thermal sensors as hwmon device
depends on HWMON=y || HWMON=THERMAL
default y
+ help
+ In case a sensor is registered with the thermal
+ framework, this option will also register it
+ as a hwmon. The sensor will then have the common
+ hwmon sysfs interface.
+
+ Say 'Y' here if you want all thermal sensors to
+ have hwmon sysfs interface too.
choice
prompt Default Thermal governor
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 67184a2..24cb894 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -5,6 +5,9 @@
obj-$(CONFIG_THERMAL) += thermal_sys.o
thermal_sys-y += thermal_core.o
+# interface to/from other layers providing sensors
+thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
+
# governors
thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 1f02e8e..247528b 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -38,6 +38,7 @@
#include net/genetlink.h
#include thermal_core.h
+#include thermal_hwmon.h
MODULE_AUTHOR(Zhang Rui);
MODULE_DESCRIPTION(Generic thermal management sysfs support);
@@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device *dev,
/* Device management */
-#if defined(CONFIG_THERMAL_HWMON)
-
-/* hwmon sys I/F */
-#include linux/hwmon.h
-
-/* thermal zone devices with the same type share one hwmon device */
-struct thermal_hwmon_device {
- char type[THERMAL_NAME_LENGTH];
- struct device *device;
- int count;
- struct list_head tz_list;
- struct list_head node;
-};
-
-struct thermal_hwmon_attr {
- struct device_attribute attr;
- char name[16];
-};
-
-/* one temperature input for each thermal zone */
-struct thermal_hwmon_temp {
- struct list_head hwmon_node;
- struct thermal_zone_device *tz;
- struct thermal_hwmon_attr temp_input; /* hwmon sys attr */
- struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
-};
-
-static LIST_HEAD(thermal_hwmon_list);
-
-static ssize_t
-name_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
- struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
- return sprintf(buf, %s\n, hwmon-type);
-}
-static DEVICE_ATTR(name, 0444, name_show, NULL);
-
-static ssize_t
-temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
- long temperature;
- int ret;
- struct thermal_hwmon_attr *hwmon_attr
- = container_of(attr, struct thermal_hwmon_attr, attr);
- struct thermal_hwmon_temp *temp
- = container_of(hwmon_attr, struct thermal_hwmon_temp,
- temp_input);
- struct thermal_zone_device *tz = temp-tz;
-
- ret = thermal_zone_get_temp(tz, temperature);
-
- if (ret)
- return ret;
-
- return sprintf(buf, %ld\n, temperature);
-}
-
-static ssize_t
-temp_crit_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct thermal_hwmon_attr *hwmon_attr
- = container_of(attr, struct thermal_hwmon_attr, attr);
- struct thermal_hwmon_temp *temp
- = container_of(hwmon_attr, struct thermal_hwmon_temp,
- temp_crit);
- struct thermal_zone_device *tz = temp-tz;
- long temperature;
- int ret;
-
- ret = tz-ops-get_trip_temp(tz, 0
[PATCH 5/5] drivers: thermal: add check when unregistering cpu cooling
This patch avoids NULL pointer accesses while unregistering
cpu cooling devices, in case a NULL pointer is received.
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/cpu_cooling.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 82e15db..429a98c 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -496,8 +496,12 @@ EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
*/
void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
{
- struct cpufreq_cooling_device *cpufreq_dev = cdev-devdata;
+ struct cpufreq_cooling_device *cpufreq_dev;
+ if (!cdev)
+ return;
+
+ cpufreq_dev = cdev-devdata;
mutex_lock(cooling_cpufreq_lock);
cpufreq_dev_count--;
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] thermal: thermal_core: allow binding with limits on bind_params
When registering a thermal zone device using platform information
via bind_params, the thermal framework will always perform the
cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).
This patch changes the data structures so that it is possible
to inform what are the desired limits for each trip point
inside a bind_param. The way the binding is performed is also
changed so that it uses the new data structure.
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/thermal/sysfs-api.txt | 7 +++
drivers/thermal/thermal_core.c | 19 +++
include/linux/thermal.h | 10 ++
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index 4b4a052..86e75a6 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -136,6 +136,13 @@ temperature) and throttle appropriate devices.
this thermal zone and cdev, for a particular trip point.
If nth bit is set, then the cdev and thermal zone are bound
for trip point n.
+.limits: This is an array of cooling state limits. Must have exactly
+ 2 * thermal_zone.number_of_trip_points. It is an array consisting
+ of tuples lower-state upper-state of state limits. Each trip
+ will be associated with one state limit tuple when binding.
+ A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
+ on all trips. These limits are used when binding a cdev to a
+ trip point.
.match: This call back returns success(0) if the 'tz and cdev' need to
be bound, as per platform data.
1.4.2 struct thermal_zone_params
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index d949ab0..e9545a7 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -202,14 +202,23 @@ static void print_bind_err_msg(struct thermal_zone_device
*tz,
}
static void __bind(struct thermal_zone_device *tz, int mask,
- struct thermal_cooling_device *cdev)
+ struct thermal_cooling_device *cdev,
+ unsigned long *limits)
{
int i, ret;
for (i = 0; i tz-trips; i++) {
if (mask (1 i)) {
+ unsigned long upper, lower;
+
+ upper = THERMAL_NO_LIMIT;
+ lower = THERMAL_NO_LIMIT;
+ if (limits) {
+ lower = limits[i * 2];
+ upper = limits[i * 2 + 1];
+ }
ret = thermal_zone_bind_cooling_device(tz, i, cdev,
- THERMAL_NO_LIMIT, THERMAL_NO_LIMIT);
+ upper, lower);
if (ret)
print_bind_err_msg(tz, cdev, ret);
}
@@ -254,7 +263,8 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
if (tzp-tbp[i].match(pos, cdev))
continue;
tzp-tbp[i].cdev = cdev;
- __bind(pos, tzp-tbp[i].trip_mask, cdev);
+ __bind(pos, tzp-tbp[i].trip_mask, cdev,
+ tzp-tbp[i].binding_limits);
}
}
@@ -292,7 +302,8 @@ static void bind_tz(struct thermal_zone_device *tz)
if (tzp-tbp[i].match(tz, pos))
continue;
tzp-tbp[i].cdev = pos;
- __bind(tz, tzp-tbp[i].trip_mask, pos);
+ __bind(tz, tzp-tbp[i].trip_mask, pos,
+ tzp-tbp[i].binding_limits);
}
}
exit:
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 88148b9..7c2769c 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -207,6 +207,16 @@ struct thermal_bind_params {
* See Documentation/thermal/sysfs-api.txt for more information.
*/
int trip_mask;
+
+ /*
+* This is an array of cooling state limits. Must have exactly
+* 2 * thermal_zone.number_of_trip_points. It is an array consisting
+* of tuples lower-state upper-state of state limits. Each trip
+* will be associated with one state limit tuple when binding.
+* A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
+* on all trips.
+*/
+ unsigned long *binding_limits;
int (*match) (struct thermal_zone_device *tz,
struct thermal_cooling_device *cdev);
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux
[PATCH 2/5] drivers: thermal: parent virtual hwmon with thermal zone
When creating virtual hwmon devices based out of thermal
zone devices, the virtual devices won't have parents.
This patch changes the code so that the parent of virtual
hwmon devices is the thermal zone device that they are
based of.
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index fdb0719..eeef0e2 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -159,7 +159,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
INIT_LIST_HEAD(hwmon-tz_list);
strlcpy(hwmon-type, tz-type, THERMAL_NAME_LENGTH);
- hwmon-device = hwmon_device_register(NULL);
+ hwmon-device = hwmon_device_register(tz-device);
if (IS_ERR(hwmon-device)) {
result = PTR_ERR(hwmon-device);
goto free_mem;
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional
When registering a new thermal_device, the thermal framework will always add a hwmon sysfs interface. This patch adds a flag to make this behavior optional. Now when registering a new thermal device, the caller needs to say if the hwmon interface is required. In order to keep same behavior as of today, all current calls will by default create the hwmon interface. Cc: Anton Vorontsov an...@enomsg.org Cc: David Woodhouse dw...@infradead.org Cc: devicet...@vger.kernel.org Cc: Grant Likely grant.lik...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Len Brown l...@kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-samsung-...@vger.kernel.org Cc: Matthew Garrett matthew.garr...@nebula.com Cc: Peter Feuerer pe...@piie.net Cc: platform-driver-...@vger.kernel.org Cc: Rafael J. Wysocki r...@sisk.pl Cc: Rob Herring rob.herr...@calxeda.com Cc: Zhang Rui rui.zh...@intel.com Suggested-by: Wei Ni w...@nvidia.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- Documentation/thermal/sysfs-api.txt| 4 +++- drivers/acpi/thermal.c | 6 -- drivers/platform/x86/acerhdf.c | 3 ++- drivers/platform/x86/intel_mid_thermal.c | 2 +- drivers/power/power_supply_core.c | 2 +- drivers/thermal/armada_thermal.c | 2 +- drivers/thermal/db8500_thermal.c | 2 +- drivers/thermal/dove_thermal.c | 2 +- drivers/thermal/exynos_thermal.c | 2 +- drivers/thermal/kirkwood_thermal.c | 2 +- drivers/thermal/rcar_thermal.c | 2 +- drivers/thermal/spear_thermal.c| 2 +- drivers/thermal/thermal_core.c | 13 + drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +- drivers/thermal/x86_pkg_temp_thermal.c | 2 +- include/linux/thermal.h| 2 +- 16 files changed, 30 insertions(+), 20 deletions(-) diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index a71bd5b..4b4a052 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -64,7 +64,9 @@ temperature) and throttle appropriate devices. performing passive cooling. polling_delay: number of milliseconds to wait between polls when checking whether trip points have been crossed (0 for interrupt driven systems). - +add_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface + is required. When add_hwmon == true, a hwmon sysfs interface + will be created. When add_hwmon == false, nothing will be done 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz) diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c index a33821c..4d542b4 100644 --- a/drivers/acpi/thermal.c +++ b/drivers/acpi/thermal.c @@ -916,12 +916,14 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz) thermal_zone_device_register(acpitz, trips, 0, tz, acpi_thermal_zone_ops, NULL, tz-trips.passive.tsp*100, -tz-polling_frequency*100); +tz-polling_frequency*100, +true); else tz-thermal_zone = thermal_zone_device_register(acpitz, trips, 0, tz, acpi_thermal_zone_ops, NULL, - 0, tz-polling_frequency*100); + 0, tz-polling_frequency*100, + true); if (IS_ERR(tz-thermal_zone)) return -ENODEV; diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c index f94467c..004d9ba0 100644 --- a/drivers/platform/x86/acerhdf.c +++ b/drivers/platform/x86/acerhdf.c @@ -663,7 +663,8 @@ static int acerhdf_register_thermal(void) thz_dev = thermal_zone_device_register(acerhdf, 1, 0, NULL, acerhdf_dev_ops, NULL, 0, - (kernelmode) ? interval*1000 : 0); + (kernelmode) ? interval*1000 : 0, + true); if (IS_ERR(thz_dev)) return -EINVAL; diff --git a/drivers/platform/x86/intel_mid_thermal.c b/drivers/platform/x86/intel_mid_thermal.c index 81c491e..efea0bf 100644 --- a/drivers/platform/x86/intel_mid_thermal.c +++ b/drivers/platform/x86/intel_mid_thermal.c @@ -502,7 +502,7 @@ static int mid_thermal_probe(struct
[RFC PATCH 03/14] hwmon: lm75: expose to thermal fw via DT nodes
This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/hwmon/lm75.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..dc55908 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
#include linux/hwmon-sysfs.h
#include linux/err.h
#include linux/mutex.h
+#include linux/thermal.h
+#include linux/of.h
#include lm75.h
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
/* Each client has this additional data */
struct lm75_data {
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct mutexupdate_lock;
u8 orig_conf;
u8 resolution; /* In bits, between 9 and 12 */
@@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device
*dev);
/* sysfs attributes for hwmon */
+static int lm75_read_temp(void *dev, unsigned long *temp)
+{
+ struct lm75_data *data = lm75_update_device(dev);
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ *temp = ((data-temp[0] (16 - data-resolution)) * 1000)
+ (data-resolution - 8);
+
+ return 0;
+}
+
static ssize_t show_temp(struct device *dev, struct device_attribute *da,
char *buf)
{
@@ -271,11 +287,25 @@ lm75_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto exit_remove;
}
+ if (of_find_property(client-dev.of_node, monitored-zones, NULL)) {
+ data-tz = thermal_zone_of_device_register(client-dev,
+ 0,
+ false, /* -hwmon */
+ client-dev,
+ lm75_read_temp);
+ if (IS_ERR(data-tz)) {
+ status = PTR_ERR(data-tz);
+ goto exit_hwmon;
+ }
+ }
+
dev_info(client-dev, %s: sensor '%s'\n,
dev_name(data-hwmon_dev), client-name);
return 0;
+exit_hwmon:
+ hwmon_device_unregister(data-hwmon_dev);
exit_remove:
sysfs_remove_group(client-dev.kobj, lm75_group);
return status;
@@ -285,6 +315,7 @@ static int lm75_remove(struct i2c_client *client)
{
struct lm75_data *data = i2c_get_clientdata(client);
+ thermal_zone_device_unregister(data-tz);
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(client-dev.kobj, lm75_group);
lm75_write_value(client, LM75_REG_CONF, data-orig_conf);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 01/14] cpufreq: cpufreq-cpu0: add dt node parsing for 'cooling-zones'
This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
it can be flagged at the cpu0 device tree node, with the list
of zones property 'cooling-zones'.
In case this list of zones is present, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.
Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 4
drivers/cpufreq/cpufreq-cpu0.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..add50f7 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,9 @@ Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- cooling-zones: A list of thermal zones phandles. The generic cpu
+ cooling (freq clipping) is loaded by the generic cpufreq-cpu0 driver
+ in case the device tree node has this list.
Examples:
@@ -33,6 +36,7 @@ cpus {
198000 85
;
clock-latency = 61036; /* two CLK32 periods */
+ cooling-zones = cpu_thermal;
};
cpu@1 {
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..ede6487 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -20,6 +20,9 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/slab.h
+#include linux/thermal.h
+#include linux/cpu_cooling.h
+#include linux/cpumask.h
static unsigned int transition_latency;
static unsigned int voltage_tolerance; /* in percentage */
@@ -28,6 +31,7 @@ static struct device *cpu_dev;
static struct clk *cpu_clk;
static struct regulator *cpu_reg;
static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
static int cpu0_verify_speed(struct cpufreq_policy *policy)
{
@@ -268,6 +272,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_free_table;
}
+ /*
+* For now, just loading the cooling device;
+* thermal DT code takes care of matching them.
+*/
+ if (of_find_property(np, cooling-zones, NULL))
+ cdev = cpufreq_cooling_register(cpu_present_mask);
+
of_node_put(np);
of_node_put(parent);
return 0;
@@ -283,6 +294,7 @@ out_put_parent:
static int cpu0_cpufreq_remove(struct platform_device *pdev)
{
+ cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(cpu0_cpufreq_driver);
opp_free_cpufreq_table(cpu_dev, freq_table);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 00/14] RFCv2: device thermal limits represented in device tree nodes
Hello all, First of all, apologize for the very late answer. But I am resuming this work. This RFC is about describing hardware thermal limits using device tree. Based on the discussion on the first RFC: http://lkml.org/lkml/2013/7/22/319 I have changed the code and the device tree bindings as follows: 1. Now bindings may have several thermal zones per device (req. by Wei Ni) 2. The constants used are now using C preprocessor macros (as per Stephen suggestion) 3. Improved the bindings to have a better representation of links between involved entities (thermal zone, cooling devices, sensors), as suggested by Pawel and Mark. 4. Couple of changes in code, as per previous reviews. 5. Removed policies from DT bindings. In summary, based on the discussion of the first RFC, now the idea is to have thermal zones nodes describing the thermal zones and the hardware limits. Then sensor devices nodes will point to thermal zones via phandles and cooling device will also point to thermal zone via phandles. So, I am also posting the patch series to dt mailing list as requested. Please refer to patch 02/14 to a documentation of what I am proposing. This patch series includes: a. Required changes in cpufreq-cpu0 driver so that it loads cooling device when requested. b. The thermal zone builder based on thermal bindings c. Changes in sensor drivers (as examples) d. Changes in device tree DTS files (as examples) This patch series depends on the fixes I sent to linux-pm: http://lkml.org/lkml/2013/8/23/572 In the above link you will find also the request to have a flag to determine if virtual hwmon device will be created, based on thermal device. All best, Eduardo Valentin (14): cpufreq: cpufreq-cpu0: add dt node parsing for 'cooling-zones' drivers: thermal: introduce device tree parser hwmon: lm75: expose to thermal fw via DT nodes hwmon: tmp102: expose to thermal fw via DT nodes thermal: ti-soc-thermal: use thermal DT infrastructure arm: dts: add omap4 CPU thermal data arm: dts: add omap4430 thermal data arm: dts: add omap4460 thermal data arm: dts: point to cooling-zones on omap4430 cpu node arm: dts: point to cooling-zones on omap4460 cpu node arm: dts: add omap5 GPU thermal data arm: dts: add omap5 CORE thermal data arm: dts: add omap5 thermal data arm: dts: point to cooling-zones on omap5 cpu node .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 4 + .../devicetree/bindings/thermal/thermal.txt| 160 +++ arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 40 ++ arch/arm/boot/dts/omap443x.dtsi| 6 + arch/arm/boot/dts/omap4460.dtsi| 6 + arch/arm/boot/dts/omap5-core-thermal.dtsi | 27 ++ arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 27 ++ arch/arm/boot/dts/omap5.dtsi | 10 + drivers/cpufreq/cpufreq-cpu0.c | 12 + drivers/hwmon/lm75.c | 31 ++ drivers/hwmon/tmp102.c | 26 ++ drivers/thermal/Kconfig| 13 + drivers/thermal/Makefile | 1 + drivers/thermal/thermal_dt.c | 473 + drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 52 ++- include/dt-bindings/thermal/thermal.h | 27 ++ include/linux/thermal.h| 3 + 17 files changed, 907 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi create mode 100644 drivers/thermal/thermal_dt.c create mode 100644 include/dt-bindings/thermal/thermal.h -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 04/14] hwmon: tmp102: expose to thermal fw via DT nodes
This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/hwmon/tmp102.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..0f1e44a 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
#include linux/mutex.h
#include linux/device.h
#include linux/jiffies.h
+#include linux/thermal.h
+#include linux/of.h
#defineDRIVER_NAME tmp102
@@ -50,6 +52,7 @@
struct tmp102 {
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct mutex lock;
u16 config_orig;
unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client
*client)
return tmp102;
}
+static int tmp102_read_temp(void *dev, unsigned long *temp)
+{
+ struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+ *temp = tmp102-temp[0];
+
+ return 0;
+}
+
static ssize_t tmp102_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -204,10 +216,23 @@ static int tmp102_probe(struct i2c_client *client,
goto fail_remove_sysfs;
}
+ if (of_find_property(client-dev.of_node, monitored-zones, NULL)) {
+ tmp102-tz = thermal_zone_of_device_register(client-dev, 0,
+false, /* -hwmon */
+client-dev,
+tmp102_read_temp);
+ if (IS_ERR(tmp102-tz)) {
+ status = PTR_ERR(tmp102-tz);
+ goto exit_hwmon;
+ }
+ }
+
dev_info(client-dev, initialized\n);
return 0;
+exit_hwmon:
+ hwmon_device_unregister(tmp102-hwmon_dev);
fail_remove_sysfs:
sysfs_remove_group(client-dev.kobj, tmp102_attr_group);
fail_restore_config:
@@ -220,6 +245,7 @@ static int tmp102_remove(struct i2c_client *client)
{
struct tmp102 *tmp102 = i2c_get_clientdata(client);
+ thermal_zone_device_unregister(tmp102-tz);
hwmon_device_unregister(tmp102-hwmon_dev);
sysfs_remove_group(client-dev.kobj, tmp102_attr_group);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 02/14] drivers: thermal: introduce device tree parser
In order to be able to build thermal policies
based on generic sensors, like I2C device, that
can be places in different points on different boards,
there is a need to have a way to feed board dependent
data into the thermal framework.
This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.
This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../devicetree/bindings/thermal/thermal.txt| 160 +++
drivers/thermal/Kconfig| 13 +
drivers/thermal/Makefile | 1 +
drivers/thermal/thermal_dt.c | 473 +
include/dt-bindings/thermal/thermal.h | 27 ++
include/linux/thermal.h| 3 +
6 files changed, 677 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
create mode 100644 drivers/thermal/thermal_dt.c
create mode 100644 include/dt-bindings/thermal/thermal.h
diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..af20ab0
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,160 @@
+
+Thermal Framework Device Tree descriptor
+
+
+This file describes how to define a thermal structure using device tree.
+A thermal structure includes thermal zones and their components, such
+as name, trip points, polling intervals and cooling devices binding
+descriptors. A binding descriptor may contain information on how to
+react, with a cooling stepped action or a weight on a fair share.
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must take place. It follows a description of each
+type of device tree node.
+
+
+trip
+
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+A node describing a trip must contain:
+- temperature: the trip temperature level, in milliCelsius.
+- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative
+value, in milliCelsius.
+- type: the trip type. Here is the type mapping:
+ THERMAL_TRIP_ACTIVE
+ THERMAL_TRIP_PASSIVE
+ THERMAL_TRIP_HOT
+ THERMAL_TRIP_CRITICAL
+
+**
+bind_param
+**
+
+The bind_param node is a node to describe how cooling devices get assigned
+to trip points of the zone. The cooling devices are expected to be loaded
+in the target system.
+
+A node describing a bind_param must contain:
+- cooling_device: A string with the cooling device name.
+- weight: The 'influence' of a particular cooling device on this zone.
+ This is on a percentage scale. The sum of all these weights
+ (for a particular zone) cannot exceed 100.
+- trip_mask: This is a bit mask that gives the binding relation between
+ this thermal zone and cdev, for a particular trip point.
+ If nth bit is set, then the cdev and thermal zone are bound
+ for trip point n.
+- limits: An array integers consisting of 2-tuples items, and each item means
+ lower and upper state limits, like min-state max-state.
+
+**
+temperature sensor devices
+**
+
+Temperature sensor devices have to be linked to a specific thermal zone.
+This is done by means of the 'monitored-zones' list.
+- monitored-zones: A list of thermal zones phandles, identifying which
+thermal zones the temperature sensor device is used to monitor.
+
+
+thermal_zone
+
+
+The thermal_zone node is the node containing all the required info
+for describing a thermal zone, including its cdev bindings. The thermal_zone
+node must contain, apart from its own properties, one node containing
+trip nodes and one node containing all the zone bind parameters.
+
+Required properties:
+- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
+
+- passive_delay: number of milliseconds to wait between polls when
+ performing passive cooling.
+
+- polling_delay: number of milliseconds to wait between polls when checking.
+
+- #thermal-cells: An integer that is used to specify how many cells compose
+ sensor ids.
+
+Below is an example:
+cpu_thermal: thermal_zone {
+#thermal-cells = 1;
+mask = 0x03; /* trips writability */
+passive_delay = 250; /* milliseconds
[RFC PATCH 08/14] arm: dts: add omap4460 thermal data
This patch changes the dtsi entry on omap4460 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson b-cous...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..9855f29 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -30,6 +30,10 @@
ti,hwmods = debugss;
};
+ thermal_zones{
+ #include omap4-cpu-thermal.dtsi
+ };
+
bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4
@@ -37,5 +41,6 @@
compatible = ti,omap4460-bandgap;
interrupts = 0 126 IRQ_TYPE_LEVEL_HIGH; /* talert */
gpios = gpio3 22 0; /* tshut */
+ monitored-zones = cpu_thermal 0;
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 10/14] arm: dts: point to cooling-zones on omap4460 cpu node
OMAP4460 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch links the cpu node to its thermal-zone so that cpufreq-cpu0 driver loads the cooling device. Cc: Benoît Cousson b-cous...@linaro.org Cc: Tony Lindgren t...@atomide.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Ian Campbell ian.campb...@citrix.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-o...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/boot/dts/omap4460.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi index 9855f29..991bd1b 100644 --- a/arch/arm/boot/dts/omap4460.dtsi +++ b/arch/arm/boot/dts/omap4460.dtsi @@ -20,6 +20,7 @@ 92 1313000 ; clock-latency = 30; /* From legacy driver */ + cooling-zones = cpu_thermal; }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 07/14] arm: dts: add omap4430 thermal data
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..91a3a5d 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -25,9 +25,14 @@
};
};
+ thermal_zones{
+ #include omap4-cpu-thermal.dtsi
+ };
+
bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+ monitored-zones = cpu_thermal 0;
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 05/14] thermal: ti-soc-thermal: use thermal DT infrastructure
This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.
The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.
In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 52 +-
1 file changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 5ab613a..6aac72c 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
#include linux/cpufreq.h
#include linux/cpumask.h
#include linux/cpu_cooling.h
+#include linux/of.h
#include ti-thermal.h
#include ti-bandgap.h
@@ -75,11 +76,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int
s, int c)
/* thermal zone ops */
/* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, unsigned long *temp)
{
struct thermal_zone_device *pcb_tz = NULL;
- struct ti_thermal_data *data = thermal-devdata;
+ struct ti_thermal_data *data = devdata;
struct ti_bandgap *bgp;
const struct ti_temp_sensor *s;
int ret, tmp, slope, constant;
@@ -117,6 +117,14 @@ static inline int ti_thermal_get_temp(struct
thermal_zone_device *thermal,
return ret;
}
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+ struct ti_thermal_data *data = thermal-devdata;
+
+ return __ti_thermal_get_temp(data, temp);
+}
+
/* Bind callback functions for thermal zone */
static int ti_thermal_bind(struct thermal_zone_device *thermal,
struct thermal_cooling_device *cdev)
@@ -293,6 +301,7 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
char *domain)
{
struct ti_thermal_data *data;
+ struct device_node *np;
data = ti_bandgap_get_sensor_data(bgp, id);
@@ -302,16 +311,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int
id,
if (!data)
return -EINVAL;
- /* Create thermal zone */
- data-ti_thermal = thermal_zone_device_register(domain,
+ /* in case this is specified by DT */
+ np = bgp-dev-of_node;
+ data-ti_thermal = thermal_zone_of_device_register(bgp-dev, id,
+ true, /* +hwmon */
+ data, __ti_thermal_get_temp);
+ if (IS_ERR(data-ti_thermal)) {
+ /* Create thermal zone */
+ data-ti_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, ti_thermal_ops,
NULL, FAST_TEMP_MONITORING_RATE,
FAST_TEMP_MONITORING_RATE, true);
- if (IS_ERR(data-ti_thermal)) {
- dev_err(bgp-dev, thermal zone device is NULL\n);
- return PTR_ERR(data-ti_thermal);
+ if (IS_ERR(data-ti_thermal)) {
+ dev_err(bgp-dev, thermal zone device is NULL\n);
+ return PTR_ERR(data-ti_thermal);
+ }
+ data-ti_thermal-polling_delay = FAST_TEMP_MONITORING_RATE;
}
- data-ti_thermal-polling_delay = FAST_TEMP_MONITORING_RATE;
ti_bandgap_set_sensor_data(bgp, id, data);
return 0;
@@ -323,7 +339,8 @@ int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id)
data = ti_bandgap_get_sensor_data(bgp, id);
- thermal_zone_device_unregister(data-ti_thermal);
+ if (data data-ti_thermal)
+ thermal_zone_device_unregister(data-ti_thermal);
return 0;
}
@@ -342,6 +359,17 @@ int ti_thermal_report_sensor_temperature(struct ti_bandgap
*bgp, int id)
int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
{
struct ti_thermal_data *data;
+ struct device_node *np = bgp-dev-of_node;
+
+ /*
+* We are assuming here that if one deploys the zone
[RFC PATCH 09/14] arm: dts: point to cooling-zones on omap4430 cpu node
OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch links the cpu node to its thermal-zone so that cpufreq-cpu0 driver loads the cooling device. Cc: Benoît Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-o...@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/boot/dts/omap443x.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index 91a3a5d..e4eea43 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,7 @@ 1008000 1375000 ; clock-latency = 30; /* From legacy driver */ + cooling-zones = cpu_thermal; }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 14/14] arm: dts: point to cooling-zones on omap5 cpu node
OMAP5 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.
This patch links the cpu node to its thermal-zone
so that cpufreq-cpu0 driver loads the cooling device.
Cc: Benoît Cousson b-cous...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4a33fe0..335fcea 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -37,6 +37,7 @@
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0x0;
+ cooling-zones = cpu_thermal;
};
cpu@1 {
device_type = cpu;
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 11/14] arm: dts: add omap5 GPU thermal data
This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson b-cous...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 000..f421492
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,27 @@
+
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+gpu_thermal: gpu_thermal {
+ #thermal-cells = 1;
+ mask = 0x01; /* trips writability */
+ passive_delay = 250; /* milliseconds */
+ polling_delay = 1000; /* milliseconds */
+ trips {
+ crit@125000{
+ temperature = 125000; /* milliCelsius */
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 13/14] arm: dts: add omap5 thermal data
This patch changes the dtsi entry on omap5 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C. The
system will do a thermal shutdown at 125C whenever
any of its sensors sees this level.
Cc: Benoît Cousson b-cous...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..4a33fe0 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -45,6 +45,12 @@
};
};
+ thermal_zones {
+ #include omap4-cpu-thermal.dtsi
+ #include omap5-gpu-thermal.dtsi
+ #include omap5-core-thermal.dtsi
+ };
+
timer {
compatible = arm,armv7-timer;
/* PPI secure/nonsecure IRQ */
@@ -711,6 +717,9 @@
0x4a0023C0 0x3c;
interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
compatible = ti,omap5430-bandgap;
+ monitored-zones = cpu_thermal 0,
+ gpu_thermal 1,
+ core_thermal 2;
};
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 12/14] arm: dts: add omap5 CORE thermal data
This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap5-core-thermal.dtsi | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi
b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 000..3d9fa09
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,27 @@
+
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+core_thermal: core_thermal {
+ #thermal-cells = 1;
+ mask = 0x01; /* trips writability */
+ passive_delay = 250; /* milliseconds */
+ polling_delay = 1000; /* milliseconds */
+ trips {
+ crit@125000{
+ temperature = 125000; /* milliCelsius */
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 06/14] arm: dts: add omap4 CPU thermal data
This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson b-cous...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 40
1 file changed, 40 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 000..d74c565
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,40 @@
+
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+cpu_thermal: cpu_thermal {
+ #thermal-cells = 1;
+ mask = 0x03; /* trips writability */
+ passive_delay = 250; /* milliseconds */
+ polling_delay = 1000; /* milliseconds */
+ trips {
+ alert@10{
+ temperature = 10; /* milliCelsius */
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_PASSIVE;
+ };
+ crit@125000{
+ temperature = 125000; /* milliCelsius */
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+ bind_params {
+ action@0{
+ cooling_device = thermal-cpufreq;
+ weight = 100; /* percentage */
+ mask = 0x01;
+ /* no limits, using defaults */
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 03/14] hwmon: lm75: expose to thermal fw via DT nodes
On 23-08-2013 19:39, Guenter Roeck wrote:
On Fri, Aug 23, 2013 at 07:15:44PM -0400, Eduardo Valentin wrote:
This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/hwmon/lm75.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..dc55908 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
#include linux/hwmon-sysfs.h
#include linux/err.h
#include linux/mutex.h
+#include linux/thermal.h
+#include linux/of.h
#include lm75.h
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
/* Each client has this additional data */
struct lm75_data {
struct device *hwmon_dev;
+struct thermal_zone_device *tz;
struct mutexupdate_lock;
u8 orig_conf;
u8 resolution; /* In bits, between 9 and 12 */
@@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device
*dev);
/* sysfs attributes for hwmon */
+static int lm75_read_temp(void *dev, unsigned long *temp)
+{
+struct lm75_data *data = lm75_update_device(dev);
+
+if (IS_ERR(data))
+return PTR_ERR(data);
+
+*temp = ((data-temp[0] (16 - data-resolution)) * 1000)
+(data-resolution - 8);
+
+return 0;
+}
+
static ssize_t show_temp(struct device *dev, struct device_attribute *da,
char *buf)
{
@@ -271,11 +287,25 @@ lm75_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto exit_remove;
}
+if (of_find_property(client-dev.of_node, monitored-zones, NULL)) {
+data-tz = thermal_zone_of_device_register(client-dev,
+ 0,
+ false, /* -hwmon */
+ client-dev,
+ lm75_read_temp);
+if (IS_ERR(data-tz)) {
+status = PTR_ERR(data-tz);
+goto exit_hwmon;
+}
+}
+
I don't think it should be fatal if thermal_zone_of_device_register fails.
hwmon itself still works fine, and should not be penaltized for a thermal
subsystem failure. Better display a warning if that happens and don't bail
out.
The same comment applies to all patches affecting the hwmon subsystem.
OK. Sounds reasonable to me. I am going to simply attempt to parse the
DT node, and in case it fails, will log it and continue, as you suggest:
+ data-tz = thermal_zone_of_device_register(client-dev,
+ 0,
+ false, /* -hwmon */
+ client-dev,
+ lm75_read_temp);
+ if (IS_ERR(data-tz))
+ dev_warn(client-dev, Could not parse device tree thermal
data\n);
dev_info(client-dev, %s: sensor '%s'\n,
dev_name(data-hwmon_dev), client-name);
return 0;
+exit_hwmon:
+hwmon_device_unregister(data-hwmon_dev);
exit_remove:
sysfs_remove_group(client-dev.kobj, lm75_group);
return status;
@@ -285,6 +315,7 @@ static int lm75_remove(struct i2c_client *client)
{
struct lm75_data *data = i2c_get_clientdata(client);
+thermal_zone_device_unregister(data-tz);
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(client-dev.kobj, lm75_group);
lm75_write_value(client, LM75_REG_CONF, data-orig_conf);
--
1.8.2.1.342.gfa7285d
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 01/14] cpufreq: cpufreq-cpu0: add dt node parsing for 'cooling-zones'
On 26-08-2013 00:42, Viresh Kumar wrote: On 24 August 2013 04:45, Eduardo Valentin eduardo.valen...@ti.com wrote: diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index ad1fde2..ede6487 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -20,6 +20,9 @@ #include linux/platform_device.h #include linux/regulator/consumer.h #include linux/slab.h +#include linux/thermal.h +#include linux/cpu_cooling.h +#include linux/cpumask.h In alphabetical order please.. OK. @@ -268,6 +272,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev) goto out_free_table; } + /* +* For now, just loading the cooling device; +* thermal DT code takes care of matching them. +*/ + if (of_find_property(np, cooling-zones, NULL)) + cdev = cpufreq_cooling_register(cpu_present_mask); Should we check if it passed or failed? And if failed Atleast flag an appropriate message? Yes, we need error checking code. I will add in next version. Thanks Kumar. -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 03/14] hwmon: lm75: expose to thermal fw via DT nodes
On 23-08-2013 19:50, Guenter Roeck wrote:
On Fri, Aug 23, 2013 at 07:15:44PM -0400, Eduardo Valentin wrote:
This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/hwmon/lm75.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..dc55908 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
#include linux/hwmon-sysfs.h
#include linux/err.h
#include linux/mutex.h
+#include linux/thermal.h
+#include linux/of.h
#include lm75.h
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
/* Each client has this additional data */
struct lm75_data {
struct device *hwmon_dev;
+struct thermal_zone_device *tz;
struct mutexupdate_lock;
u8 orig_conf;
u8 resolution; /* In bits, between 9 and 12 */
@@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device
*dev);
/* sysfs attributes for hwmon */
+static int lm75_read_temp(void *dev, unsigned long *temp)
+{
+struct lm75_data *data = lm75_update_device(dev);
+
+if (IS_ERR(data))
+return PTR_ERR(data);
+
+*temp = ((data-temp[0] (16 - data-resolution)) * 1000)
+(data-resolution - 8);
+
The reported temperature can be negative, which would result in reporting a
very
high temperature (note this applies to the tmp102 driver patch as well).
Good point.
The computation is quite complex and matches the computation done in
show_temp().
Given that, it would make sense to declare an inline function to convert the
register value to the temperature. This function can take the register value
and the resolution as argument.
Sounds reasonable. Modifying accordingly in next version.
Guenter
+return 0;
+}
+
static ssize_t show_temp(struct device *dev, struct device_attribute *da,
char *buf)
{
@@ -271,11 +287,25 @@ lm75_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto exit_remove;
}
+if (of_find_property(client-dev.of_node, monitored-zones, NULL)) {
+data-tz = thermal_zone_of_device_register(client-dev,
+ 0,
+ false, /* -hwmon */
+ client-dev,
+ lm75_read_temp);
+if (IS_ERR(data-tz)) {
+status = PTR_ERR(data-tz);
+goto exit_hwmon;
+}
+}
+
dev_info(client-dev, %s: sensor '%s'\n,
dev_name(data-hwmon_dev), client-name);
return 0;
+exit_hwmon:
+hwmon_device_unregister(data-hwmon_dev);
exit_remove:
sysfs_remove_group(client-dev.kobj, lm75_group);
return status;
@@ -285,6 +315,7 @@ static int lm75_remove(struct i2c_client *client)
{
struct lm75_data *data = i2c_get_clientdata(client);
+thermal_zone_device_unregister(data-tz);
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(client-dev.kobj, lm75_group);
lm75_write_value(client, LM75_REG_CONF, data-orig_conf);
--
1.8.2.1.342.gfa7285d
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 01/14] cpufreq: cpufreq-cpu0: add dt node parsing for 'cooling-zones'
Hey Mark,
On 27-08-2013 05:29, Mark Rutland wrote:
On Sat, Aug 24, 2013 at 12:15:42AM +0100, Eduardo Valentin wrote:
This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
it can be flagged at the cpu0 device tree node, with the list
of zones property 'cooling-zones'.
In case this list of zones is present, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.
Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 4
drivers/cpufreq/cpufreq-cpu0.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..add50f7 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,9 @@ Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- cooling-zones: A list of thermal zones phandles. The generic cpu
+ cooling (freq clipping) is loaded by the generic cpufreq-cpu0 driver
+ in case the device tree node has this list.
Bindings should not describe the behaviour of any kernel (and for that
reason I'm not very keen on the current cpufreq-cpu0 binding document).
Right.
Bindings should simply describe the hardware. This addition could
instead be:
- cooling-zones: a list of thermal zone phandles.
OK. This works for me.
However, as the thermal zone binding doesn't seem to have appeared by
this patch, it should get moved later anyway...
Yeah, I will reorder them.
Thanks,
Mark.
Examples:
@@ -33,6 +36,7 @@ cpus {
198000 85
;
clock-latency = 61036; /* two CLK32 periods */
+cooling-zones = cpu_thermal;
};
cpu@1 {
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..ede6487 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -20,6 +20,9 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/slab.h
+#include linux/thermal.h
+#include linux/cpu_cooling.h
+#include linux/cpumask.h
static unsigned int transition_latency;
static unsigned int voltage_tolerance; /* in percentage */
@@ -28,6 +31,7 @@ static struct device *cpu_dev;
static struct clk *cpu_clk;
static struct regulator *cpu_reg;
static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
static int cpu0_verify_speed(struct cpufreq_policy *policy)
{
@@ -268,6 +272,13 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
goto out_free_table;
}
+/*
+ * For now, just loading the cooling device;
+ * thermal DT code takes care of matching them.
+ */
+if (of_find_property(np, cooling-zones, NULL))
+cdev = cpufreq_cooling_register(cpu_present_mask);
+
of_node_put(np);
of_node_put(parent);
return 0;
@@ -283,6 +294,7 @@ out_put_parent:
static int cpu0_cpufreq_remove(struct platform_device *pdev)
{
+cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(cpu0_cpufreq_driver);
opp_free_cpufreq_table(cpu_dev, freq_table);
--
1.8.2.1.342.gfa7285d
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 02/14] drivers: thermal: introduce device tree parser
Hello Mark, First of all, thanks for taking the time to review in such level of detail. Lets try to align and have a common understanding. Answers go inline. Please let me know if I missed something or if I made it more confusing :-) On 27-08-2013 06:22, Mark Rutland wrote: Hi, On Sat, Aug 24, 2013 at 12:15:43AM +0100, Eduardo Valentin wrote: In order to be able to build thermal policies based on generic sensors, like I2C device, that can be places in different points on different boards, there is a need to have a way to feed board dependent data into the thermal framework. This patch introduces a thermal data parser for device tree. The parsed data is used to build thermal zones and thermal binding parameters. The output data can then be used to deploy thermal policies. This patch adds also documentation regarding this API and how to define tree nodes to use this infrastructure. Cc: Zhang Rui rui.zh...@intel.com Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- .../devicetree/bindings/thermal/thermal.txt| 160 +++ drivers/thermal/Kconfig| 13 + drivers/thermal/Makefile | 1 + drivers/thermal/thermal_dt.c | 473 + include/dt-bindings/thermal/thermal.h | 27 ++ include/linux/thermal.h| 3 + 6 files changed, 677 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt create mode 100644 drivers/thermal/thermal_dt.c create mode 100644 include/dt-bindings/thermal/thermal.h General question on device tree documentation. Assuming there is such an effort to make it Linux independent, is there other places out of Linux tree that these binding must be documented? diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt new file mode 100644 index 000..af20ab0 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/thermal.txt @@ -0,0 +1,160 @@ + +Thermal Framework Device Tree descriptor + + +This file describes how to define a thermal structure using device tree. +A thermal structure includes thermal zones and their components, such +as name, trip points, polling intervals and cooling devices binding +descriptors. A binding descriptor may contain information on how to +react, with a cooling stepped action or a weight on a fair share. +The target of device tree thermal descriptors is to describe only +the hardware thermal aspects, not how the system must control or which +algorithm or policy must take place. It follows a description of each +type of device tree node. + + +trip + + +The trip node is a node to describe a point in the temperature domain +in which the system takes an action. This node describes just the point, +not the action. + +A node describing a trip must contain: +- temperature: the trip temperature level, in milliCelsius. +- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative +value, in milliCelsius. Presumably this is a single (u32) cell? Yes, both of them above are a single u32. +- type: the trip type. Here is the type mapping: + THERMAL_TRIP_ACTIVE + THERMAL_TRIP_PASSIVE + THERMAL_TRIP_HOT + THERMAL_TRIP_CRITICAL What type is this property? What are these values? Do you need to refer to a header somewhere? There is a header, introduced in this patch. include/dt-bindings/thermal/thermal.h Symbolic constants should have an associated value for an ABI. OK. Sounds reasonable to me. Shall we be descriptive and enlist the values in this doc too or just pointing to header is fine? + +** +bind_param +** + +The bind_param node is a node to describe how cooling devices get assigned +to trip points of the zone. The cooling devices are expected to be loaded +in the target system. + +A node describing a bind_param must contain: +- cooling_device: A string with the cooling device name. Please use '-' rather than '_' in bindings. That's the normal devicetree convention, and there's no point gonig against it and causing more confusion. Agreed. What are valid values of this string, and what do they mean? These are the name of the cooling devices to match to. Why not a phandle + cells binding to cooling devices? Yeah, this could work too. I am going to check how that would look like and come back to you. +- weight: The 'influence' of a particular cooling device on this zone. + This is on a percentage scale. The sum of all these weights + (for a particular zone) cannot exceed 100. This is a bit fuzzy, and certainly needs more guidance. OK. This property is used to describe
Re: [RFC PATCH 02/14] drivers: thermal: introduce device tree parser
On 27-08-2013 12:23, Mark Rutland wrote: On Tue, Aug 27, 2013 at 02:44:40PM +0100, Eduardo Valentin wrote: Hello Mark, First of all, thanks for taking the time to review in such level of detail. Lets try to align and have a common understanding. Answers go inline. Please let me know if I missed something or if I made it more confusing :-) On 27-08-2013 06:22, Mark Rutland wrote: Hi, On Sat, Aug 24, 2013 at 12:15:43AM +0100, Eduardo Valentin wrote: In order to be able to build thermal policies based on generic sensors, like I2C device, that can be places in different points on different boards, there is a need to have a way to feed board dependent data into the thermal framework. This patch introduces a thermal data parser for device tree. The parsed data is used to build thermal zones and thermal binding parameters. The output data can then be used to deploy thermal policies. This patch adds also documentation regarding this API and how to define tree nodes to use this infrastructure. Cc: Zhang Rui rui.zh...@intel.com Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- .../devicetree/bindings/thermal/thermal.txt| 160 +++ drivers/thermal/Kconfig| 13 + drivers/thermal/Makefile | 1 + drivers/thermal/thermal_dt.c | 473 + include/dt-bindings/thermal/thermal.h | 27 ++ include/linux/thermal.h| 3 + 6 files changed, 677 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt create mode 100644 drivers/thermal/thermal_dt.c create mode 100644 include/dt-bindings/thermal/thermal.h General question on device tree documentation. Assuming there is such an effort to make it Linux independent, is there other places out of Linux tree that these binding must be documented? At present, no. There is a plan to move the documentation out of the kernel, but I'm not sure on how that's currently progressing. Some general cleanup needs to occur before we can actually do that. OK. diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt new file mode 100644 index 000..af20ab0 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/thermal.txt @@ -0,0 +1,160 @@ + +Thermal Framework Device Tree descriptor + + +This file describes how to define a thermal structure using device tree. +A thermal structure includes thermal zones and their components, such +as name, trip points, polling intervals and cooling devices binding +descriptors. A binding descriptor may contain information on how to +react, with a cooling stepped action or a weight on a fair share. +The target of device tree thermal descriptors is to describe only +the hardware thermal aspects, not how the system must control or which +algorithm or policy must take place. It follows a description of each +type of device tree node. + + +trip + + +The trip node is a node to describe a point in the temperature domain +in which the system takes an action. This node describes just the point, +not the action. + +A node describing a trip must contain: +- temperature: the trip temperature level, in milliCelsius. +- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative +value, in milliCelsius. Presumably this is a single (u32) cell? Yes, both of them above are a single u32. Ok. This seems to be the default assumption in many bindings, so I shan't argue against it here, but in general we should be as precise as possible as to the format of the devicetree. Yeah, I followed the default assumption. It does not hurt to be descriptive though. +- type: the trip type. Here is the type mapping: + THERMAL_TRIP_ACTIVE + THERMAL_TRIP_PASSIVE + THERMAL_TRIP_HOT + THERMAL_TRIP_CRITICAL What type is this property? What are these values? Do you need to refer to a header somewhere? There is a header, introduced in this patch. include/dt-bindings/thermal/thermal.h Symbolic constants should have an associated value for an ABI. OK. Sounds reasonable to me. Shall we be descriptive and enlist the values in this doc too or just pointing to header is fine? I believe that referring to the header is fine, though personally I'd prefer if we were explicit in binding docs. I'll leave Stephen to comment on what the preferred way of handling header constants with binding documents is. OK. I will do both. + +** +bind_param +** + +The bind_param node is a node to describe how cooling devices get assigned +to trip points of the zone. The cooling devices are expected to be loaded +in the target
Re: [PATCH 3/5] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional
On 23-08-2013 19:08, Rafael J. Wysocki wrote:
On Friday, August 23, 2013 06:03:14 PM Eduardo Valentin wrote:
When registering a new thermal_device, the thermal framework
will always add a hwmon sysfs interface.
This patch adds a flag to make this behavior optional. Now
when registering a new thermal device, the caller needs
to say if the hwmon interface is required.
In order to keep same behavior as of today, all current
calls will by default create the hwmon interface.
Well, instead of modifying all of the callers this way, why don't
you add new versions taking the additional argument as, for example,
thermal_zone_device_register_full()
and redefine the old ones as static inline wrappers, for example
static inline struct thermal_zone_device *thermal_zone_device_register(args)
{
return thermal_zone_device_register_full(args, true);
}
?
Yeah, that is another way to go and I thought of doing it like that. I
just could not come out with a good API naming:
thermal_zone_device_register_full(all args)
thermal_zone_device_register(args) /* on hwmon == true */
thermal_zone_device_register_no_hwmon(args) /* on hwmon == false */
Would this sound reasonable naming?
That'd reduce the size of this patch a bit I suppose (and the number of
subsystems involved at the same time).
I see your point.
Thanks,
Rafael
Cc: Anton Vorontsov an...@enomsg.org
Cc: David Woodhouse dw...@infradead.org
Cc: devicet...@vger.kernel.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Len Brown l...@kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: Matthew Garrett matthew.garr...@nebula.com
Cc: Peter Feuerer pe...@piie.net
Cc: platform-driver-...@vger.kernel.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Zhang Rui rui.zh...@intel.com
Suggested-by: Wei Ni w...@nvidia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/thermal/sysfs-api.txt| 4 +++-
drivers/acpi/thermal.c | 6 --
drivers/platform/x86/acerhdf.c | 3 ++-
drivers/platform/x86/intel_mid_thermal.c | 2 +-
drivers/power/power_supply_core.c | 2 +-
drivers/thermal/armada_thermal.c | 2 +-
drivers/thermal/db8500_thermal.c | 2 +-
drivers/thermal/dove_thermal.c | 2 +-
drivers/thermal/exynos_thermal.c | 2 +-
drivers/thermal/kirkwood_thermal.c | 2 +-
drivers/thermal/rcar_thermal.c | 2 +-
drivers/thermal/spear_thermal.c| 2 +-
drivers/thermal/thermal_core.c | 13 +
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +-
drivers/thermal/x86_pkg_temp_thermal.c | 2 +-
include/linux/thermal.h| 2 +-
16 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index a71bd5b..4b4a052 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -64,7 +64,9 @@ temperature) and throttle appropriate devices.
performing passive cooling.
polling_delay: number of milliseconds to wait between polls when
checking
whether trip points have been crossed (0 for interrupt driven systems).
-
+add_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface
+is required. When add_hwmon == true, a hwmon sysfs interface
+will be created. When add_hwmon == false, nothing will be done
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index a33821c..4d542b4 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -916,12 +916,14 @@ static int acpi_thermal_register_thermal_zone(struct
acpi_thermal *tz)
thermal_zone_device_register(acpitz, trips, 0, tz,
acpi_thermal_zone_ops, NULL,
tz-trips.passive.tsp*100,
- tz-polling_frequency*100);
+ tz-polling_frequency*100,
+ true);
else
tz-thermal_zone =
thermal_zone_device_register(acpitz, trips, 0, tz,
acpi_thermal_zone_ops, NULL,
-0, tz-polling_frequency*100);
+0, tz-polling_frequency*100
Re: [PATCH 3/5] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional
On 27-08-2013 20:13, Zhang Rui wrote:
On 二, 2013-08-27 at 23:17 +0200, Rafael J. Wysocki wrote:
On Tuesday, August 27, 2013 02:26:41 PM Eduardo Valentin wrote:
On 23-08-2013 19:08, Rafael J. Wysocki wrote:
On Friday, August 23, 2013 06:03:14 PM Eduardo Valentin wrote:
When registering a new thermal_device, the thermal framework
will always add a hwmon sysfs interface.
This patch adds a flag to make this behavior optional. Now
when registering a new thermal device, the caller needs
to say if the hwmon interface is required.
In order to keep same behavior as of today, all current
calls will by default create the hwmon interface.
Well, instead of modifying all of the callers this way, why don't
you add new versions taking the additional argument as, for example,
thermal_zone_device_register_full()
and redefine the old ones as static inline wrappers, for example
static inline struct thermal_zone_device
*thermal_zone_device_register(args)
{
return thermal_zone_device_register_full(args, true);
}
?
Yeah, that is another way to go and I thought of doing it like that. I
just could not come out with a good API naming:
thermal_zone_device_register_full(all args)
thermal_zone_device_register(args) /* on hwmon == true */
thermal_zone_device_register_no_hwmon(args) /* on hwmon == false */
Would this sound reasonable naming?
Yeah, sounds good to me.
Well, actually, Tianyu is working on a patch set to move all the
thermal_zone_device_register() parameters to struct thermal_zone_params.
But with that patch set done, what you need to do next is just to
introduce a new field in struct thermal_zone_params and make sure 0
means registering hwmon sysfs I/F.
Rui,
Do you have a pointer to his patch?
thanks,
rui
Thanks,
Rafael
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 2/4] thermal: introduce device tree parser
On 10-07-2013 02:48, Wei Ni wrote:
On 07/09/2013 10:00 PM, Eduardo Valentin wrote:
In order to be able to build thermal policies
based on generic sensors, like I2C device, that
can be places in different points on different boards,
there is a need to have a way to feed board dependent
data into the thermal framework.
This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.
This patch adds also documentation regarding this
API and how to define define tree nodes to use
this infrastructure.
It looks good, with this infrastructure, we can add generic sensor
driver into the thermal fw easily.
+
+Below is an example:
+thermal_zone {
+type = CPU;
+mask = 0x03; /* trips writability */
+passive_delay = 250; /* milliseconds */
+polling_delay = 1000; /* milliseconds */
+governor = step_wise;
+trips {
+alert@10{
+temperature = 10; /* milliCelsius */
+hysteresis = 0; /* milliCelsius */
+type = 1;
how about to use the trip type name directly, such as named as
passive-trip;, I think it's more readable. for example:
trip0 {
passive-trip;
}
trip1 {
active-trip;
}
+};
+crit@125000{
+temperature = 125000; /* milliCelsius */
+hysteresis = 0; /* milliCelsius */
+type = 3;
+};
+};
+bind_params {
+action@0{
+cooling_device = thermal-cpufreq;
+weight = 100; /* percentage */
+mask = 0x01;
+};
+};
+};
as we know, thermal_zone_bind_cooling_device() will set the upper/lower
in the thermal_instance. In the default .bind function, it just set to
THERMAL_NO_LIMIT, but for some platform, it need to set these
upper/lower values for different cooling device and trips, how to pass
these values in DT? how about to set:
action@0 {
...
mask = 0x03; //or you can remove this property;
Well, this has been added accordingly to current API needs.
trip0 = alert 1 2; //1 is lower value, 2 is upper value;
trip1 = crit 3 4;
I suppose the first item in you 3-tuple is the trip point.
}
Yeah, I also noticed that I was missing the upper and lower limits. But
unfortunately this is a limitation on the thermal FW API too!
If one passes a bind params, the structure which represents platform
info, then it won't be able to pass the upper and lower limits. But by
passing a .bind callback, then you have the opportunity to match it
using these two values.
I believe we would need to change the data structures and the API to
support upper and lower limits via platform representation. We could
simply use the .bind callback of the dt thermal zone, but I believe that
would abusing the API, assuming that .match is for platform binding.
Durga, what do you think?
Thanks.
Wei.
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 2/4] thermal: introduce device tree parser
On 10-07-2013 11:16, Stephen Warren wrote:
On 07/10/2013 12:48 AM, Wei Ni wrote:
On 07/09/2013 10:00 PM, Eduardo Valentin wrote:
In order to be able to build thermal policies
based on generic sensors, like I2C device, that
can be places in different points on different boards,
there is a need to have a way to feed board dependent
data into the thermal framework.
This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.
This patch adds also documentation regarding this
API and how to define define tree nodes to use
this infrastructure.
It looks good, with this infrastructure, we can add generic sensor
driver into the thermal fw easily.
+
+Below is an example:
+thermal_zone {
+type = CPU;
+mask = 0x03; /* trips writability */
+passive_delay = 250; /* milliseconds */
+polling_delay = 1000; /* milliseconds */
+governor = step_wise;
+trips {
+alert@10{
+temperature = 10; /* milliCelsius */
+hysteresis = 0; /* milliCelsius */
+type = 1;
how about to use the trip type name directly, such as named as
passive-trip;, I think it's more readable. for example:
trip0 {
passive-trip;
}
trip1 {
active-trip;
}
You can always use the C pre-processor in DT now to define named constants:
include/dt-bindings//h
#define THERMAL_PASSIVE_TRIP 0
#define THERMAL_ACTIVE_TRIP 1
*.dts:
type = THERMAL_PASSIVE_TRIP;
Having a single 'property = value;' rather than n different Boolean
property names seems better, irrespective of whether value is an integer
or string; parsing and error-checking will be simpler.
agreed here. I will amend with the above suggestions. makes the dt file
much more readable. thanks Stephen and Wei.
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 2/4] thermal: introduce device tree parser
On 15-07-2013 13:03, R, Durgadoss wrote:
-Original Message-
From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
Sent: Monday, July 15, 2013 5:25 PM
To: Wei Ni
Cc: Eduardo Valentin; linux...@vger.kernel.org; R, Durgadoss;
amit.dan...@samsung.com; Zhang, Rui; linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/4] thermal: introduce device tree parser
On 10-07-2013 02:48, Wei Ni wrote:
On 07/09/2013 10:00 PM, Eduardo Valentin wrote:
In order to be able to build thermal policies
based on generic sensors, like I2C device, that
can be places in different points on different boards,
there is a need to have a way to feed board dependent
data into the thermal framework.
This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.
This patch adds also documentation regarding this
API and how to define define tree nodes to use
this infrastructure.
It looks good, with this infrastructure, we can add generic sensor
driver into the thermal fw easily.
+
+Below is an example:
+thermal_zone {
+type = CPU;
+mask = 0x03; /* trips writability */
+passive_delay = 250; /* milliseconds */
+polling_delay = 1000; /* milliseconds */
+governor = step_wise;
+trips {
+alert@10{
+temperature = 10; /* milliCelsius */
+hysteresis = 0; /* milliCelsius */
+type = 1;
how about to use the trip type name directly, such as named as
passive-trip;, I think it's more readable. for example:
trip0 {
passive-trip;
}
trip1 {
active-trip;
}
+};
+crit@125000{
+temperature = 125000; /* milliCelsius */
+hysteresis = 0; /* milliCelsius */
+type = 3;
+};
+};
+bind_params {
+action@0{
+cooling_device = thermal-cpufreq;
+weight = 100; /* percentage */
+mask = 0x01;
+};
+};
+};
as we know, thermal_zone_bind_cooling_device() will set the upper/lower
in the thermal_instance. In the default .bind function, it just set to
THERMAL_NO_LIMIT, but for some platform, it need to set these
upper/lower values for different cooling device and trips, how to pass
these values in DT? how about to set:
action@0 {
...
mask = 0x03; //or you can remove this property;
Well, this has been added accordingly to current API needs.
trip0 = alert 1 2; //1 is lower value, 2 is upper value;
trip1 = crit 3 4;
I suppose the first item in you 3-tuple is the trip point.
}
Yeah, I also noticed that I was missing the upper and lower limits. But
unfortunately this is a limitation on the thermal FW API too!
If one passes a bind params, the structure which represents platform
info, then it won't be able to pass the upper and lower limits. But by
passing a .bind callback, then you have the opportunity to match it
using these two values.
I believe we would need to change the data structures and the API to
support upper and lower limits via platform representation. We could
simply use the .bind callback of the dt thermal zone, but I believe that
would abusing the API, assuming that .match is for platform binding.
Durga, what do you think?
okay, I see.. Two approaches I could think of:
1. Introduce two arrays (size = number of trips in the tz) named
upper/lower_limits[size] in the 'thermal_bind_params' structure.
This way we don't need any API change. We can slightly change the
implementation inside '__bind' function in thermal_core.c to get this
working.
2. Pass 3 more parameters in the .match function:
.match(tz, cdev, trip, lower, upper). The platform layer
then determines whether there is a match; and if so,
provides sane values for lower and upper variables.
At this point of time, I think I prefer method 1 ;)
Let me know your thoughts.
Yeah, I agree that (1) is likely to scale. I will cook something with it
for next version.
Thanks,
Durga
Thanks.
Wei.
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv3 3/6] arm: dts: add bandgap entry for OMAP443x devices
Benoit,
On 07-06-2013 16:46, Eduardo Valentin wrote:
This patch add the bandgap entry for OMAP4430 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Could you please have a look on this one?
---
arch/arm/boot/dts/omap443x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..8d6c968 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -24,4 +24,8 @@
clock-latency = 30; /* From legacy driver */
};
};
+ bandgap {
+ reg = 0x4a002260 0x4 0x4a00232C 0x4;
+ compatible = ti,omap4430-bandgap;
+ };
};
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv3 4/6] arm: dts: add bandgap entry for OMAP4460 devices
Benoit
On 07-06-2013 16:46, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Could you please have a look on patch 3 and 4 of this series? I have
changed this one accordingly to your recommendation on v2. If nothing
else, please let me know if they can still be queued for 3.11.
I would need to rebase patch 01 to refresh on top of the thermal tree.
Thanks.
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..ea97201 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
0 55 0x4;
ti,hwmods = debugss;
};
+
+ bandgap {
+ reg = 0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18;
+ compatible = ti,omap4460-bandgap;
+ interrupts = 0 126 4; /* talert */
+ gpios = gpio3 22 0; /* tshut */
+ };
};
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv3 2/6] arm: introduce config HAS_BANDGAP
On 12-06-2013 13:07, Tony Lindgren wrote: * Eduardo Valentin eduardo.valen...@ti.com [130607 13:53]: Bandgap is a device used to measure temperature on electronic equipments. It is widely used in digital integrated circuits. It is based on the dependency between silicon voltage and temperature. This patch introduce HAS_BANDGAP config entry. This config is a boolean value so that arch code can flag if they feature a bandgap device. This config entry follows the same idea behind ARCH_HAS_CPUFREQ. I suggest you add this to Russell's patch system: Acked-by: Tony Lindgren t...@atomide.com Thanks! I have add it to Russell's patch system and it has been accepted and applied. Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-o...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Fabio Stevam feste...@gmail.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/Kconfig| 3 +++ arch/arm/mach-omap2/Kconfig | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d423d58..bcbdec9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -174,6 +174,9 @@ config ARCH_HAS_CPUFREQ and that the relevant menu configurations are displayed for it. +config ARCH_HAS_BANDGAP +bool + config GENERIC_HWEIGHT bool default y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..8620ab5 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -4,6 +4,7 @@ config ARCH_OMAP config ARCH_OMAP2PLUS bool TI OMAP2/3/4/5 SoCs with device tree support if (ARCH_MULTI_V6 || ARCH_MULTI_V7) select ARCH_HAS_CPUFREQ +select ARCH_HAS_BANDGAP select ARCH_HAS_HOLES_MEMORYMODEL select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB -- 1.8.2.1.342.gfa7285d -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [PATCHv3 5/6] arm: omap2plus_defconfig: enable TI bandgap driver
Tony, On 07-06-2013 16:46, Eduardo Valentin wrote: Enable the bandgap driver for TI SoCs thermal support. Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk Cc: AnilKumar Ch anilku...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Is it possible for you to queue this one and patch 6 for 3.11? Cheers, --- arch/arm/configs/omap2plus_defconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c1ef64b..6e6c494 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -151,6 +151,13 @@ CONFIG_W1=y CONFIG_POWER_SUPPLY=y CONFIG_SENSORS_LM75=m CONFIG_WATCHDOG=y +CONFIG_THERMAL=y +CONFIG_THERMAL_HWMON=y +CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y +CONFIG_THERMAL_GOV_FAIR_SHARE=y +CONFIG_THERMAL_GOV_STEP_WISE=y +CONFIG_THERMAL_GOV_USER_SPACE=y +CONFIG_CPU_THERMAL=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_TPS65217=y @@ -237,6 +244,10 @@ CONFIG_RTC_DRV_TWL4030=y CONFIG_RTC_DRV_OMAP=y CONFIG_DMADEVICES=y CONFIG_DMA_OMAP=y +CONFIG_TI_SOC_THERMAL=y +CONFIG_TI_THERMAL=y +CONFIG_OMAP4_THERMAL=y +CONFIG_OMAP5_THERMAL=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
[PATCHv4 1/6] thermal: ti-soc-thermal: use standard GPIO DT bindings
This change updates the ti-soc-thermal driver to use
standard GPIO DT bindings to read the GPIO number associated
to thermal shutdown IRQ, in case the device features it.
Previously, the code was using a specific DT bindings.
As now OMAP supports the standard way to model GPIOs,
there is no point in having a ti specific binding.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt | 9 +
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 8 ++--
2 files changed, 7 insertions(+), 10 deletions(-)
---
Rui,
This is the rebased version of patch 01. It has been rebased on
your thermal/next. Please send it for 3.11. All remaining patches
on this series have been applied to respective for_3.11 branches
on corresponding trees.
diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
index 1953b33..0c9222d 100644
--- a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
@@ -17,8 +17,9 @@ Required properties:
- interrupts : this entry should indicate which interrupt line
the talert signal is routed to;
Specific:
-- ti,tshut-gpio : this entry should be used to inform which GPIO
-line the tshut signal is routed to;
+- gpios : this entry should be used to inform which GPIO
+line the tshut signal is routed to. The informed GPIO will
+be treated as an IRQ;
- regs : this entry must also be specified and it is specific
to each bandgap version, because the mapping may change from
soc to soc, apart of depending on available features.
@@ -37,7 +38,7 @@ bandgap {
0x4a002378 0x18;
compatible = ti,omap4460-bandgap;
interrupts = 0 126 4; /* talert */
- ti,tshut-gpio = 86;
+ gpios = gpio3 22 0; /* tshut */
};
OMAP4470:
@@ -47,7 +48,7 @@ bandgap {
0x4a002378 0x18;
compatible = ti,omap4470-bandgap;
interrupts = 0 126 4; /* talert */
- ti,tshut-gpio = 86;
+ gpios = gpio3 22 0; /* tshut */
};
OMAP5430:
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 7c0b3eb..9dfd471 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -38,6 +38,7 @@
#include linux/of_device.h
#include linux/of_platform.h
#include linux/of_irq.h
+#include linux/of_gpio.h
#include linux/io.h
#include ti-bandgap.h
@@ -1129,7 +1130,6 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
const struct of_device_id *of_id;
struct ti_bandgap *bgp;
struct resource *res;
- u32 prop;
int i;
/* just for the sake */
@@ -1173,11 +1173,7 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
} while (res);
if (TI_BANDGAP_HAS(bgp, TSHUT)) {
- if (of_property_read_u32(node, ti,tshut-gpio, prop) 0) {
- dev_err(pdev-dev, missing tshut gpio in device
tree\n);
- return ERR_PTR(-EINVAL);
- }
- bgp-tshut_gpio = prop;
+ bgp-tshut_gpio = of_get_gpio(node, 0);
if (!gpio_is_valid(bgp-tshut_gpio)) {
dev_err(pdev-dev, invalid gpio for tshut (%d)\n,
bgp-tshut_gpio);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] arm: add bandgap DT entry for OMAP5
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 8
1 file changed, 8 insertions(+)
---
Benoit,
Sorry for this very late request, but can you please consider
these patches for 3.11 still?
I completely forgot to send these on my Enable TI SoC thermal driver series.
All best,
Eduardo
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2ad63c4..5ede6e1 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -615,5 +615,13 @@
interrupts = 0 80 0x4;
ti,hwmods = wd_timer2;
};
+ bandgap {
+ reg = 0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c;
+ interrupts = 0 126 4; /* talert */
+ compatible = ti,omap5430-bandgap;
+ };
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] arm: add bandgap DT entry for OMAP5
On 19-06-2013 06:36, Benoit Cousson wrote:
Hi Eduardo,
On 06/18/2013 09:36 PM, Eduardo Valentin wrote:
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 8
1 file changed, 8 insertions(+)
---
Benoit,
Sorry for this very late request, but can you please consider
these patches for 3.11 still?
I completely forgot to send these on my Enable TI SoC thermal driver
series.
All best,
Eduardo
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2ad63c4..5ede6e1 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -615,5 +615,13 @@
interrupts = 0 80 0x4;
ti,hwmods = wd_timer2;
};
missing blank line
+bandgap {
You must use the first address in that case. Otherwise DT will affect a
random number and provide a non-standard device name. That does not really
matter in theory, but it will looks ugly in the /sys/devices list.
+reg = 0x4a0021e0 0xc
+0x4a00232c 0xc
+0x4a002380 0x2c
+0x4a0023C0 0x3c;
+interrupts = 0 126 4; /* talert */
Not well aligned and should use the macros.
+compatible = ti,omap5430-bandgap;
+};
};
};
I did the update for you :-)
Here is the version I've just applied.
Benoit
From f0160bb93467e22f2f8bc77591dcd7e35cdee999 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin eduardo.valen...@ti.com
Date: Tue, 18 Jun 2013 22:36:38 -0400
Subject: [PATCH] ARM: dts: Add bandgap DT entry for OMAP5
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Benoit Cousson benoit.cous...@linaro.org
---
arch/arm/boot/dts/omap5.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index accab62..47693c9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -696,5 +696,14 @@
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
};
};
+
+ bandgap@4a0021e0 {
+ reg = 0x4a0021e0 0xc
+0x4a00232c 0xc
+0x4a002380 0x2c
+0x4a0023C0 0x3c;
+ interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
+ compatible = ti,omap5430-bandgap;
+ };
};
};
Looks good to me.
Tks Benoit!
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 08/15] thermal: cpu_cooling: fix stub function
Arnd,
On 31-05-2013 18:22, Arnd Bergmann wrote:
The function stub for cpufreq_cooling_get_level introduced
in 57df81069 Thermal: exynos: fix cooling state translation
is not syntactically correct C and needs to be fixed to avoid
this error:
In file included from drivers/thermal/db8500_thermal.c:20:0:
include/linux/cpu_cooling.h: In function 'cpufreq_cooling_get_level':
include/linux/cpu_cooling.h:57:1:
error: parameter name omitted unsigned long
cpufreq_cooling_get_level(unsigned int, unsigned int) ^
include/linux/cpu_cooling.h:57:1: error: parameter name omitted
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Eduardo Valentin eduardo.valen...@ti.com
What is the status of this patch?
I believe Rui is supposed to queue this one right?
Cc: Eduardo Valentin eduardo.valen...@ti.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: Amit Daniel kachhap amit.dan...@samsung.com
---
include/linux/cpu_cooling.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index 282e270..a5d52ee 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -41,7 +41,7 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus);
*/
void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev);
-unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int);
+unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq);
#else /* !CONFIG_CPU_THERMAL */
static inline struct thermal_cooling_device *
cpufreq_cooling_register(const struct cpumask *clip_cpus)
@@ -54,7 +54,7 @@ void cpufreq_cooling_unregister(struct
thermal_cooling_device *cdev)
return;
}
static inline
-unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)
+unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq)
{
return THERMAL_CSTATE_INVALID;
}
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V6 02/30] thermal: exynos: Use ARCH_HAS_BANDGAP config to know the supported soc's
On 17-06-2013 02:46, Amit Daniel Kachhap wrote: This patch uses the recently added config sybmol ARCH_HAS_BANDGAP to enable the TMU driver. This will allow adding support for new soc easily as now it is the platform responsibility to enable this config symbol for a particular soc. Acked-by: Kukjin Kim kgene@samsung.com Acked-by: Jonghwa Lee jonghwa3@samsung.com Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Acked-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/thermal/samsung/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig index 2d3d9dc..883a8a8 100644 --- a/drivers/thermal/samsung/Kconfig +++ b/drivers/thermal/samsung/Kconfig @@ -1,6 +1,6 @@ config EXYNOS_THERMAL tristate Temperature sensor on Samsung EXYNOS - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) + depends on ARCH_HAS_BANDGAP depends on CPU_THERMAL help If you say yes here you get support for TMU (Thermal Management -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 04/30] thermal: exynos: Bifurcate exynos thermal common and tmu controller code
(Exynos: Kernel Thermal management registered\n);
+
+ return 0;
+
+err_unregister:
+ exynos_unregister_thermal();
+ return ret;
+}
+
+/* Un-Register with the in-kernel thermal management */
+void exynos_unregister_thermal(void)
+{
+ int i;
+
+ if (!th_zone)
+ return;
+
+ if (th_zone-therm_dev)
+ thermal_zone_device_unregister(th_zone-therm_dev);
+
+ for (i = 0; i th_zone-cool_dev_size; i++) {
+ if (th_zone-cool_dev[i])
+ cpufreq_cooling_unregister(th_zone-cool_dev[i]);
+ }
+
+ kfree(th_zone);
+ pr_info(Exynos: Kernel Thermal management unregistered\n);
+}
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
b/drivers/thermal/samsung/exynos_thermal_common.h
new file mode 100644
index 000..8df1848
--- /dev/null
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -0,0 +1,83 @@
+/*
+ * exynos_thermal_common.h - Samsung EXYNOS common header file
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Amit Daniel Kachhap amit.dan...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef _EXYNOS_THERMAL_COMMON_H
+#define _EXYNOS_THERMAL_COMMON_H
+
+/* In-kernel thermal framework related macros definations */
+#define SENSOR_NAME_LEN 16
+#define MAX_TRIP_COUNT 8
+#define MAX_COOLING_DEVICE 4
+#define MAX_THRESHOLD_LEVS 4
+
+#define ACTIVE_INTERVAL 500
+#define IDLE_INTERVAL 1
+#define MCELSIUS 1000
+
+/* CPU Zone information */
+#define PANIC_ZONE 4
+#define WARN_ZONE 3
+#define MONITOR_ZONE2
+#define SAFE_ZONE 1
+
+#define GET_ZONE(trip) (trip + 2)
+#define GET_TRIP(zone) (zone - 2)
+
+#define EXYNOS_ZONE_COUNT3
+
+struct thermal_trip_point_conf {
+ int trip_val[MAX_TRIP_COUNT];
+ int trip_count;
+ unsigned char trigger_falling;
+};
+
+struct thermal_cooling_conf {
+ struct freq_clip_table freq_data[MAX_TRIP_COUNT];
+ int freq_clip_count;
+};
+
+struct thermal_sensor_conf {
+ char name[SENSOR_NAME_LEN];
+ int (*read_temperature)(void *data);
+ int (*write_emul_temp)(void *drv_data, unsigned long temp);
+ struct thermal_trip_point_conf trip_data;
+ struct thermal_cooling_conf cooling_data;
+ void *private_data;
+};
+
+/*Functions used exynos based thermal sensor driver*/
+#ifdef CONFIG_EXYNOS_THERMAL_CORE
+void exynos_unregister_thermal(void);
+int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
+void exynos_report_trigger(void);
+#else
+static inline void
+exynos_unregister_thermal(void) { return; }
+
+static inline int
+exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return 0;
}
+
+static inline void
+exynos_report_trigger(void) { return; }
+
+#endif /* CONFIG_EXYNOS_THERMAL_CORE */
+#endif /* _EXYNOS_THERMAL_COMMON_H */
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V6 30/30] arm: exynos: enable ARCH_HAS_BANDGAP
On 17-06-2013 02:46, Amit Daniel Kachhap wrote: This patch enables ARCH_HAS_BANDGAP config for exynos4210, 4212, 4412, 5250 and 5440 SOC. This config symbol is recently added to allow the platforms to enable bandgap based temperature sensor. Acked-by: Jonghwa Lee jonghwa3@samsung.com Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Acked-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/mach-exynos/Kconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index d19edff..d3cb5c7 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -33,6 +33,7 @@ config CPU_EXYNOS4210 bool SAMSUNG EXYNOS4210 default y depends on ARCH_EXYNOS4 + select ARCH_HAS_BANDGAP select ARM_CPU_SUSPEND if PM select PM_GENERIC_DOMAINS select S5P_PM if PM @@ -45,6 +46,7 @@ config SOC_EXYNOS4212 bool SAMSUNG EXYNOS4212 default y depends on ARCH_EXYNOS4 + select ARCH_HAS_BANDGAP select S5P_PM if PM select S5P_SLEEP if PM select SAMSUNG_DMADEV @@ -55,6 +57,7 @@ config SOC_EXYNOS4412 bool SAMSUNG EXYNOS4412 default y depends on ARCH_EXYNOS4 + select ARCH_HAS_BANDGAP select SAMSUNG_DMADEV help Enable EXYNOS4412 SoC support @@ -63,6 +66,7 @@ config SOC_EXYNOS5250 bool SAMSUNG EXYNOS5250 default y depends on ARCH_EXYNOS5 + select ARCH_HAS_BANDGAP select PM_GENERIC_DOMAINS if PM select S5P_PM if PM select S5P_SLEEP if PM @@ -76,6 +80,7 @@ config SOC_EXYNOS5440 default y depends on ARCH_EXYNOS5 select ARCH_HAS_OPP + select ARCH_HAS_BANDGAP select ARM_ARCH_TIMER select AUTO_ZRELADDR select PINCTRL -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 03/30] thermal: exynos: Remove un-necessary CPU_THERMAL dependency
On 17-06-2013 02:46, Amit Daniel Kachhap wrote: This patch removes the dependency on CPU_THERMAL for compiling TMU driver. This is useful for cases when only TMU controller needs to be initialised without cpu cooling action. Acked-by: Kukjin Kim kgene@samsung.com Acked-by: Jonghwa Lee jonghwa3@samsung.com Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Acked-by: Eduardo Valentin eduardo.valen...@ti.com Please have a look on my comment on your patch 04. You may want to have this dependency still on your core part. --- drivers/thermal/samsung/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig index 883a8a8..2cf31ad 100644 --- a/drivers/thermal/samsung/Kconfig +++ b/drivers/thermal/samsung/Kconfig @@ -1,7 +1,6 @@ config EXYNOS_THERMAL tristate Temperature sensor on Samsung EXYNOS depends on ARCH_HAS_BANDGAP - depends on CPU_THERMAL help If you say yes here you get support for TMU (Thermal Management Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 01/30] thermal: exynos: Moving exynos thermal files into samsung directory
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
This movement of files is done for easy maintenance and adding more
new sensor's support for exynos platform easily . This will also help in
bifurcating exynos common, sensor driver and sensor data related parts.
Acked-by: Kukjin Kim kgene@samsung.com
Acked-by: Jonghwa Lee jonghwa3@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Acked-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/Kconfig| 13 +
drivers/thermal/Makefile |2 +-
drivers/thermal/samsung/Kconfig|9 +
drivers/thermal/samsung/Makefile |4
drivers/thermal/{ = samsung}/exynos_thermal.c |0
5 files changed, 19 insertions(+), 9 deletions(-)
create mode 100644 drivers/thermal/samsung/Kconfig
create mode 100644 drivers/thermal/samsung/Makefile
rename drivers/thermal/{ = samsung}/exynos_thermal.c (100%)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b13c2bc..ef10cf2 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -114,14 +114,6 @@ config KIRKWOOD_THERMAL
Support for the Kirkwood thermal sensor driver into the Linux thermal
framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
-config EXYNOS_THERMAL
- tristate Temperature sensor on Samsung EXYNOS
- depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
- depends on CPU_THERMAL
- help
- If you say yes here you get support for TMU (Thermal Management
- Unit) on SAMSUNG EXYNOS series of SoC.
-
config DOVE_THERMAL
tristate Temperature sensor on Marvell Dove SoCs
depends on ARCH_DOVE
@@ -185,4 +177,9 @@ menu Texas Instruments thermal drivers
source drivers/thermal/ti-soc-thermal/Kconfig
endmenu
+menu Samsung thermal drivers
+depends on PLAT_SAMSUNG
+source drivers/thermal/samsung/Kconfig
+endmenu
+
endif
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 67184a2..1f27ada 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -17,7 +17,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
-obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
+obj-y+= samsung/
obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
new file mode 100644
index 000..2d3d9dc
--- /dev/null
+++ b/drivers/thermal/samsung/Kconfig
@@ -0,0 +1,9 @@
+config EXYNOS_THERMAL
+ tristate Temperature sensor on Samsung EXYNOS
+ depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
+ depends on CPU_THERMAL
+ help
+ If you say yes here you get support for TMU (Thermal Management
+ Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
+ the exynos thermal driver with the core thermal layer and cpu
+ cooling API's.
diff --git a/drivers/thermal/samsung/Makefile
b/drivers/thermal/samsung/Makefile
new file mode 100644
index 000..1fe6d93
--- /dev/null
+++ b/drivers/thermal/samsung/Makefile
@@ -0,0 +1,4 @@
+#
+# Samsung thermal specific Makefile
+#
+obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/samsung/exynos_thermal.c
similarity index 100%
rename from drivers/thermal/exynos_thermal.c
rename to drivers/thermal/samsung/exynos_thermal.c
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
