Re: [PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
On Wed, Jul 9, 2014 at 8:30 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
On 07/01/2014 09:33 AM, Chanwoo Choi wrote:
This patch add registers, bit fields and compatible strings for Exynos3250
TMU
(Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
a target speed of 1.0 GHz.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
[Add MUX address setting bits by Jonghwa Lee]
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Changes look fine to me.
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
---
.../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
drivers/thermal/samsung/exynos_tmu.c | 7 +-
drivers/thermal/samsung/exynos_tmu.h | 3 +-
drivers/thermal/samsung/exynos_tmu_data.c | 89
++
drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
5 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index c949092..ae738f5 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -3,6 +3,7 @@
** Required properties:
- compatible : One of the following:
+samsung,exynos3250-tmu
samsung,exynos4412-tmu
samsung,exynos4210-tmu
samsung,exynos5250-tmu
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 2412090..97ebc1e 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -501,6 +501,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static const struct of_device_id exynos_tmu_match[] = {
{
+ .compatible = samsung,exynos3250-tmu,
+ .data = (void *)EXYNOS3250_TMU_DRV_DATA,
+ },
+ {
.compatible = samsung,exynos4210-tmu,
.data = (void *)EXYNOS4210_TMU_DRV_DATA,
},
@@ -675,7 +679,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
goto err_clk_sec;
}
- if (pdata-type == SOC_ARCH_EXYNOS4210 ||
+ if (pdata-type == SOC_ARCH_EXYNOS3250 ||
+ pdata-type == SOC_ARCH_EXYNOS4210 ||
pdata-type == SOC_ARCH_EXYNOS4412 ||
pdata-type == SOC_ARCH_EXYNOS5250 ||
pdata-type == SOC_ARCH_EXYNOS5260 ||
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index edd08cf..1b4a644 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -40,7 +40,8 @@ enum calibration_mode {
};
enum soc_type {
- SOC_ARCH_EXYNOS4210 = 1,
+ SOC_ARCH_EXYNOS3250 = 1,
+ SOC_ARCH_EXYNOS4210,
SOC_ARCH_EXYNOS4412,
SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5260,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index c1d81dc..aa8e0de 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
exynos4210_default_tmu_data = {
};
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+static const struct exynos_tmu_registers exynos3250_tmu_registers = {
+ .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
+ .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
+ .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
+ .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
+ .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
+ .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
+ .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
+ .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
+ .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
+ .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
+ .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
+ .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
+ .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
+ .tmu_status = EXYNOS_TMU_REG_STATUS,
+ .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
+ .threshold_th0 = EXYNOS_THD_TEMP_RISE,
+ .threshold_th1 = EXYNOS_THD_TEMP_FALL,
+ .tmu_inten = EXYNOS_TMU_REG_INTEN,
+ .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
+ .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
+ .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
+ .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
+ .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
+ .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
+ .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
+ .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
+ .intclr_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
+ .emul_con = EXYNOS_EMUL_CON,
+ .emul_temp_shift =
Re: [PATCH 09/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_control()
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
pdata-reference_voltage and pdata-gain are always defined
to non-zero values so remove the redundant checks from
exynos_tmu_control().
I prefer to have these checks for the same reason that new soc support
should not add these same code again.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index a8d9524..45d7c6f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -215,15 +215,11 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (pdata-test_mux)
con |= (pdata-test_mux reg-test_mux_addr_shift);
- if (pdata-reference_voltage) {
- con = ~(reg-buf_vref_sel_mask reg-buf_vref_sel_shift);
- con |= pdata-reference_voltage reg-buf_vref_sel_shift;
- }
+ con = ~(reg-buf_vref_sel_mask reg-buf_vref_sel_shift);
+ con |= pdata-reference_voltage reg-buf_vref_sel_shift;
- if (pdata-gain) {
- con = ~(reg-buf_slope_sel_mask reg-buf_slope_sel_shift);
- con |= (pdata-gain reg-buf_slope_sel_shift);
- }
+ con = ~(reg-buf_slope_sel_mask reg-buf_slope_sel_shift);
+ con |= (pdata-gain reg-buf_slope_sel_shift);
if (pdata-noise_cancel_mode) {
con = ~(reg-therm_trip_mode_mask
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-pm 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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] thermal: exynos: remove identical values from exynos*_tmu_registers structures
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
There is no need for abstracting configuration for registers that
are identical on all SoC types.
Changes look fine and also that shift and masks may not change in
future socs also.
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 12 ++--
drivers/thermal/samsung/exynos_tmu.h | 11 ---
drivers/thermal/samsung/exynos_tmu_data.c | 15 ---
3 files changed, 6 insertions(+), 32 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 45d7c6f..d37e755 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -215,11 +215,11 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (pdata-test_mux)
con |= (pdata-test_mux reg-test_mux_addr_shift);
- con = ~(reg-buf_vref_sel_mask reg-buf_vref_sel_shift);
- con |= pdata-reference_voltage reg-buf_vref_sel_shift;
+ con = ~(EXYNOS_TMU_REF_VOLTAGE_MASK EXYNOS_TMU_REF_VOLTAGE_SHIFT);
+ con |= pdata-reference_voltage EXYNOS_TMU_REF_VOLTAGE_SHIFT;
- con = ~(reg-buf_slope_sel_mask reg-buf_slope_sel_shift);
- con |= (pdata-gain reg-buf_slope_sel_shift);
+ con = ~(EXYNOS_TMU_BUF_SLOPE_SEL_MASK
EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT);
+ con |= (pdata-gain EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT);
if (pdata-noise_cancel_mode) {
con = ~(reg-therm_trip_mode_mask
@@ -228,7 +228,7 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
}
if (on) {
- con |= (1 reg-core_en_shift);
+ con |= (1 EXYNOS_TMU_CORE_EN_SHIFT);
interrupt_en =
pdata-trigger_enable[3] reg-inten_rise3_shift |
pdata-trigger_enable[2] reg-inten_rise2_shift |
@@ -238,7 +238,7 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
interrupt_en |=
interrupt_en reg-inten_fall0_shift;
} else {
- con = ~(1 reg-core_en_shift);
+ con = ~(1 EXYNOS_TMU_CORE_EN_SHIFT);
interrupt_en = 0; /* Disable all interrupts */
}
writel(interrupt_en, data-base + reg-tmu_inten);
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 4845171..5c25a4b 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -69,15 +69,9 @@ enum soc_type {
* @triminfo_ctrl: trim info controller register.
* @tmu_ctrl: TMU main controller register.
* @test_mux_addr_shift: shift bits of test mux address.
- * @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl
register.
- * @buf_vref_sel_mask: mask bits of reference voltage in tmu_ctrl
register.
* @therm_trip_mode_shift: shift bits of tripping mode in tmu_ctrl
register.
* @therm_trip_mode_mask: mask bits of tripping mode in tmu_ctrl register.
* @therm_trip_en_shift: shift bits of tripping enable in tmu_ctrl
register.
- * @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
- register.
- * @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl
register.
- * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
* @tmu_status: register drescribing the TMU status.
* @tmu_cur_temp: register containing the current temperature of the TMU.
* @threshold_temp: register containing the base threshold level.
@@ -111,14 +105,9 @@ struct exynos_tmu_registers {
u32 tmu_ctrl;
u32 test_mux_addr_shift;
- u32 buf_vref_sel_shift;
- u32 buf_vref_sel_mask;
u32 therm_trip_mode_shift;
u32 therm_trip_mode_mask;
u32 therm_trip_en_shift;
- u32 buf_slope_sel_shift;
- u32 buf_slope_sel_mask;
- u32 core_en_shift;
u32 tmu_status;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index ef7f186..32530dc 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -28,11 +28,6 @@
static const struct exynos_tmu_registers exynos4210_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
- .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
- .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
- .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
- .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
- .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
.tmu_status = EXYNOS_TMU_REG_STATUS,
.tmu_cur_temp =
Re: [PATCH 00/10] thermal: exynos: various cleanups
On 5/15/14, Zhang Rui rui.zh...@intel.com wrote: On 一, 2014-05-05 at 13:15 +0200, Bartlomiej Zolnierkiewicz wrote: Hi, This patch series contains various cleanups for EXYNOS thermal driver. Overall it decreases driver's LOC by 13%. It is based on next-20140428 kernel. It should not cause any functionality changes. Amit, what do you think of this patch set? thanks, rui I agreed to many of the cleanups in the patch but tmu controller features should be retained as they will allow adding quick soc support and also avoid unnecessary churning of code in the future. Thanks, Amit Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (10): thermal: exynos: remove unused struct exynos_tmu_registers entries thermal: exynos: remove unused defines thermal: exynos: remove dead code for HW_MODE calibration thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize() thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize() thermal: exynos: simplify temp_to_code() and code_to_temp() thermal: exynos: cache non_hw_trigger_levels in pdata thermal: exynos: remove redundant pdata checks from exynos_tmu_control() thermal: exynos: remove identical values from exynos*_tmu_registers structures drivers/thermal/samsung/exynos_thermal_common.h | 1 - drivers/thermal/samsung/exynos_tmu.c| 181 drivers/thermal/samsung/exynos_tmu.h| 86 +-- drivers/thermal/samsung/exynos_tmu_data.c | 40 +- drivers/thermal/samsung/exynos_tmu_data.h | 32 + 5 files changed, 37 insertions(+), 303 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-pm 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] thermal: exynos: remove unused struct exynos_tmu_registers entries
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.h | 40
---
drivers/thermal/samsung/exynos_tmu_data.c | 2 --
drivers/thermal/samsung/exynos_tmu_data.h | 1 -
3 files changed, 43 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..80dc899 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -82,8 +82,6 @@ enum soc_type {
* @triminfo_25_shift: shift bit of the 25 C trim value in triminfo_data
reg.
* @triminfo_85_shift: shift bit of the 85 C trim value in triminfo_data
reg.
* @triminfo_ctrl: trim info controller register.
- * @triminfo_reload_shift: shift of triminfo reload enable bit in
triminfo_ctrl
- reg.
* @tmu_ctrl: TMU main controller register.
* @test_mux_addr_shift: shift bits of test mux address.
* @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl
register.
@@ -98,27 +96,13 @@ enum soc_type {
register.
* @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
register.
- * @therm_trip_tq_en_shift: shift bits of thermal trip enable by TQ pin in
- tmu_ctrl register.
* @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
* @tmu_status: register drescribing the TMU status.
* @tmu_cur_temp: register containing the current temperature of the TMU.
- * @tmu_cur_temp_shift: shift bits of current temp value in tmu_cur_temp
- register.
* @threshold_temp: register containing the base threshold level.
* @threshold_th0: Register containing first set of rising levels.
- * @threshold_th0_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th0_l1_shift: shift bits of level1 threshold temperature.
- * @threshold_th0_l2_shift: shift bits of level2 threshold temperature.
- * @threshold_th0_l3_shift: shift bits of level3 threshold temperature.
* @threshold_th1: Register containing second set of rising levels.
- * @threshold_th1_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th1_l1_shift: shift bits of level1 threshold temperature.
- * @threshold_th1_l2_shift: shift bits of level2 threshold temperature.
- * @threshold_th1_l3_shift: shift bits of level3 threshold temperature.
* @threshold_th2: Register containing third set of rising levels.
- * @threshold_th2_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th3: Register containing fourth set of rising levels.
* @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
* @tmu_inten: register containing the different threshold interrupt
enable bits.
@@ -131,15 +115,11 @@ enum soc_type {
* @inten_rise2_shift: shift bits of rising 2 interrupt bits.
* @inten_rise3_shift: shift bits of rising 3 interrupt bits.
* @inten_fall0_shift: shift bits of falling 0 interrupt bits.
- * @inten_fall1_shift: shift bits of falling 1 interrupt bits.
- * @inten_fall2_shift: shift bits of falling 2 interrupt bits.
- * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
- * @emul_time_mask: mask bits of emulation time.
* @tmu_irqstatus: register to find which TMU generated interrupts.
* @tmu_pmin: register to get/set the Pmin value.
I prefer to have these register description as they describe the h/w
and are used for capturing those parameters. My argument here is that
adding new soc should have minimum changes. However some unused macros
removed below makes sense.
*/
@@ -149,7 +129,6 @@ struct exynos_tmu_registers {
u32 triminfo_85_shift;
u32 triminfo_ctrl;
- u32 triminfo_reload_shift;
u32 tmu_ctrl;
u32 test_mux_addr_shift;
@@ -162,32 +141,17 @@ struct exynos_tmu_registers {
u32 buf_slope_sel_mask;
u32 calib_mode_shift;
u32 calib_mode_mask;
- u32 therm_trip_tq_en_shift;
u32 core_en_shift;
u32 tmu_status;
u32 tmu_cur_temp;
- u32 tmu_cur_temp_shift;
u32 threshold_temp;
u32 threshold_th0;
- u32 threshold_th0_l0_shift;
- u32 threshold_th0_l1_shift;
- u32 threshold_th0_l2_shift;
- u32 threshold_th0_l3_shift;
-
u32 threshold_th1;
- u32 threshold_th1_l0_shift;
- u32 threshold_th1_l1_shift;
- u32 threshold_th1_l2_shift;
- u32 threshold_th1_l3_shift;
-
Re: [PATCH 02/10] thermal: exynos: remove unused defines
Hi Bartlomiej, On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- drivers/thermal/samsung/exynos_tmu_data.h | 27 +-- 1 file changed, 1 insertion(+), 26 deletions(-) diff --git a/drivers/thermal/samsung/exynos_tmu_data.h b/drivers/thermal/samsung/exynos_tmu_data.h index 06c4345..d4eeddb 100644 --- a/drivers/thermal/samsung/exynos_tmu_data.h +++ b/drivers/thermal/samsung/exynos_tmu_data.h @@ -42,20 +42,8 @@ /* Exynos4210 specific registers */ #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP0x44 #define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL1 0x54 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL2 0x58 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL3 0x5C -#define EXYNOS4210_TMU_REG_PAST_TEMP00x60 -#define EXYNOS4210_TMU_REG_PAST_TEMP10x64 -#define EXYNOS4210_TMU_REG_PAST_TEMP20x68 -#define EXYNOS4210_TMU_REG_PAST_TEMP30x6C - This removal looks fine as 4210 is an old soc. -#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK 0x1 -#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK 0x10 -#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK 0x100 -#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK 0x1000 + #define EXYNOS4210_TMU_TRIG_LEVEL_MASK 0x -#define EXYNOS4210_TMU_INTCLEAR_VAL 0x /* Exynos5250 and Exynos4412 specific registers */ #define EXYNOS_TMU_TRIMINFO_CON 0x14 @@ -69,8 +57,6 @@ #define EXYNOS_TMU_RISE_INT_SHIFT0 #define EXYNOS_TMU_FALL_INT_MASK 0x111 #define EXYNOS_TMU_FALL_INT_SHIFT12 -#define EXYNOS_TMU_CLEAR_RISE_INT0x111 -#define EXYNOS_TMU_CLEAR_FALL_INT(0x111 12) #define EXYNOS_TMU_TRIP_MODE_SHIFT 13 #define EXYNOS_TMU_TRIP_MODE_MASK0x7 #define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12 @@ -82,8 +68,6 @@ #define EXYNOS_TMU_INTEN_RISE2_SHIFT 8 #define EXYNOS_TMU_INTEN_RISE3_SHIFT 12 #define EXYNOS_TMU_INTEN_FALL0_SHIFT 16 -#define EXYNOS_TMU_INTEN_FALL1_SHIFT 20 -#define EXYNOS_TMU_INTEN_FALL2_SHIFT 24 I suggest to retain this generic soc macros as they might be used in future. #define EXYNOS_EMUL_TIME 0x57F0 #define EXYNOS_EMUL_TIME_MASK0x @@ -107,13 +91,11 @@ #define EXYNOS5440_TMU_S0_7_TH0 0x110 #define EXYNOS5440_TMU_S0_7_TH1 0x130 #define EXYNOS5440_TMU_S0_7_TH2 0x150 -#define EXYNOS5440_TMU_S0_7_EVTEN0x1F0 #define EXYNOS5440_TMU_S0_7_IRQEN0x210 #define EXYNOS5440_TMU_S0_7_IRQ 0x230 /* exynos5440 common registers */ #define EXYNOS5440_TMU_IRQ_STATUS0x000 #define EXYNOS5440_TMU_PMIN 0x004 -#define EXYNOS5440_TMU_TEMP 0x008 #define EXYNOS5440_TMU_RISE_INT_MASK 0xf #define EXYNOS5440_TMU_RISE_INT_SHIFT0 @@ -124,13 +106,6 @@ #define EXYNOS5440_TMU_INTEN_RISE2_SHIFT 2 #define EXYNOS5440_TMU_INTEN_RISE3_SHIFT 3 #define EXYNOS5440_TMU_INTEN_FALL0_SHIFT 4 -#define EXYNOS5440_TMU_INTEN_FALL1_SHIFT 5 -#define EXYNOS5440_TMU_INTEN_FALL2_SHIFT 6 -#define EXYNOS5440_TMU_INTEN_FALL3_SHIFT 7 -#define EXYNOS5440_TMU_TH_RISE0_SHIFT0 -#define EXYNOS5440_TMU_TH_RISE1_SHIFT8 -#define EXYNOS5440_TMU_TH_RISE2_SHIFT16 -#define EXYNOS5440_TMU_TH_RISE3_SHIFT24 5440 is an old soc so can be removed. #define EXYNOS5440_TMU_TH_RISE4_SHIFT24 #define EXYNOS5440_EFUSE_SWAP_OFFSET 8 -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-pm 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] thermal: exynos: remove dead code for HW_MODE calibration
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 33
+--
drivers/thermal/samsung/exynos_tmu.h | 13
drivers/thermal/samsung/exynos_tmu_data.c | 3 ---
drivers/thermal/samsung/exynos_tmu_data.h | 2 --
4 files changed, 1 insertion(+), 50 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 0d96a51..9f2a5ee 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -76,9 +76,6 @@ static int temp_to_code(struct exynos_tmu_data *data, u8
temp)
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp_code;
- if (pdata-cal_mode == HW_MODE)
- return temp;
-
I suggest to retain the hw mode generic feature as it is provided by
the TMU controller. However below unused defines for 5440 might be
removed as the h/w mode relevant values were wrongly fused.
if (data-soc == SOC_ARCH_EXYNOS4210)
/* temp should range between 25 and 125 */
if (temp 25 || temp 125) {
@@ -113,9 +110,6 @@ static int code_to_temp(struct exynos_tmu_data *data, u8
temp_code)
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp;
- if (pdata-cal_mode == HW_MODE)
- return temp_code;
-
if (data-soc == SOC_ARCH_EXYNOS4210)
/* temp_code should range between 75 and 175 */
if (temp_code 75 || temp_code 175) {
@@ -164,9 +158,6 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
__raw_writel(1, data-base + reg-triminfo_ctrl);
- if (pdata-cal_mode == HW_MODE)
- goto skip_calib_data;
-
/* Save trimming info in order to perform calibration */
if (data-soc == SOC_ARCH_EXYNOS5440) {
/*
@@ -202,7 +193,6 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
(pdata-efuse_value reg-triminfo_85_shift)
EXYNOS_TMU_TEMP_MASK;
-skip_calib_data:
if (pdata-max_trigger_level MAX_THRESHOLD_LEVS) {
dev_err(pdev-dev, Invalid max trigger level\n);
ret = -EINVAL;
@@ -311,7 +301,7 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
struct exynos_tmu_platform_data *pdata = data-pdata;
const struct exynos_tmu_registers *reg = pdata-registers;
- unsigned int con, interrupt_en, cal_val;
+ unsigned int con, interrupt_en;
mutex_lock(data-lock);
clk_enable(data-clk);
@@ -337,27 +327,6 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
con |= (pdata-noise_cancel_mode reg-therm_trip_mode_shift);
}
- if (pdata-cal_mode == HW_MODE) {
- con = ~(reg-calib_mode_mask reg-calib_mode_shift);
- cal_val = 0;
- switch (pdata-cal_type) {
- case TYPE_TWO_POINT_TRIMMING:
- cal_val = 3;
- break;
- case TYPE_ONE_POINT_TRIMMING_85:
- cal_val = 2;
- break;
- case TYPE_ONE_POINT_TRIMMING_25:
- cal_val = 1;
- break;
- case TYPE_NONE:
- break;
- default:
- dev_err(pdev-dev, Invalid calibration type, using
none\n);
- }
- con |= cal_val reg-calib_mode_shift;
- }
-
if (on) {
con |= (1 reg-core_en_shift);
interrupt_en =
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 80dc899..e417af8 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -34,11 +34,6 @@ enum calibration_type {
TYPE_NONE,
};
-enum calibration_mode {
- SW_MODE,
- HW_MODE,
-};
-
enum soc_type {
SOC_ARCH_EXYNOS4210 = 1,
SOC_ARCH_EXYNOS4412,
@@ -92,10 +87,6 @@ enum soc_type {
* @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
register.
* @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl
register.
- * @calib_mode_shift: shift bits of calibration mode value in tmu_ctrl
- register.
- * @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
- register.
* @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
* @tmu_status: register drescribing the TMU status.
* @tmu_cur_temp: register containing the current temperature of the TMU.
@@ -139,8 +130,6 @@ struct
Re: [PATCH 04/10] thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Only TYPE_ONE_POINT_TRIMMING calibration is used so remove
the dead code for TYPE_TWO_POINT_TRIMMING calibration.
I prefer to retain this feature as it is provided by the TMU
controller. This will avoid unnecessary churning of code when some new
soc wants to use it. 2 point trimming should ideally give best
compensated thermal values.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 55
++-
drivers/thermal/samsung/exynos_tmu.h | 20 +--
drivers/thermal/samsung/exynos_tmu_data.c | 17 +-
drivers/thermal/samsung/exynos_tmu_data.h | 2 --
4 files changed, 12 insertions(+), 82 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 9f2a5ee..903566f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -47,8 +47,7 @@
* @irq_work: pointer to the irq work structure.
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
- * @temp_error1: fused value of the first point trim.
- * @temp_error2: fused value of the second point trim.
+ * @temp_error: fused value of the first point trim.
* @regulator: pointer to the TMU regulator structure.
* @reg_conf: pointer to structure to register with core thermal.
*/
@@ -62,14 +61,13 @@ struct exynos_tmu_data {
struct work_struct irq_work;
struct mutex lock;
struct clk *clk;
- u8 temp_error1, temp_error2;
+ u8 temp_error;
struct regulator *regulator;
struct thermal_sensor_conf *reg_conf;
};
/*
* TMU treats temperature as a mapped temperature code.
- * The temperature is converted differently depending on the calibration
type.
*/
static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
{
@@ -83,20 +81,7 @@ static int temp_to_code(struct exynos_tmu_data *data, u8
temp)
goto out;
}
- switch (pdata-cal_type) {
- case TYPE_TWO_POINT_TRIMMING:
- temp_code = (temp - pdata-first_point_trim) *
- (data-temp_error2 - data-temp_error1) /
- (pdata-second_point_trim - pdata-first_point_trim) +
- data-temp_error1;
- break;
- case TYPE_ONE_POINT_TRIMMING:
- temp_code = temp + data-temp_error1 - pdata-first_point_trim;
- break;
- default:
- temp_code = temp + pdata-default_temp_offset;
- break;
- }
+ temp_code = temp + data-temp_error - pdata-first_point_trim;
out:
return temp_code;
}
@@ -117,20 +102,7 @@ static int code_to_temp(struct exynos_tmu_data *data,
u8 temp_code)
goto out;
}
- switch (pdata-cal_type) {
- case TYPE_TWO_POINT_TRIMMING:
- temp = (temp_code - data-temp_error1) *
- (pdata-second_point_trim - pdata-first_point_trim) /
- (data-temp_error2 - data-temp_error1) +
- pdata-first_point_trim;
- break;
- case TYPE_ONE_POINT_TRIMMING:
- temp = temp_code - data-temp_error1 + pdata-first_point_trim;
- break;
- default:
- temp = temp_code - pdata-default_temp_offset;
- break;
- }
+ temp = temp_code - data-temp_error + pdata-first_point_trim;
out:
return temp;
}
@@ -179,19 +151,12 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
} else {
trim_info = readl(data-base + reg-triminfo_data);
}
- data-temp_error1 = trim_info EXYNOS_TMU_TEMP_MASK;
- data-temp_error2 = ((trim_info reg-triminfo_85_shift)
- EXYNOS_TMU_TEMP_MASK);
-
- if (!data-temp_error1 ||
- (pdata-min_efuse_value data-temp_error1) ||
- (data-temp_error1 pdata-max_efuse_value))
- data-temp_error1 = pdata-efuse_value EXYNOS_TMU_TEMP_MASK;
-
- if (!data-temp_error2)
- data-temp_error2 =
- (pdata-efuse_value reg-triminfo_85_shift)
- EXYNOS_TMU_TEMP_MASK;
+ data-temp_error = trim_info EXYNOS_TMU_TEMP_MASK;
+
+ if (!data-temp_error ||
+ pdata-min_efuse_value data-temp_error ||
+ data-temp_error pdata-max_efuse_value)
+ data-temp_error = pdata-efuse_value EXYNOS_TMU_TEMP_MASK;
if (pdata-max_trigger_level MAX_THRESHOLD_LEVS) {
dev_err(pdev-dev, Invalid max trigger level\n);
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index e417af8..186e39e 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++
Re: [PATCH 05/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize()
On 5/15/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
On Thursday, May 15, 2014 10:47:40 AM Eduardo Valentin wrote:
Hello Bartlomiej,
Hi,
On Mon, May 05, 2014 at 01:15:34PM +0200, Bartlomiej Zolnierkiewicz
wrote:
Remove runtime checks for pdata sanity from exynos_tmu_initialize().
The current values hardcoded in pdata will never trigger the checks
and for the new code potential mistakes should be caught during
development/review phases.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_thermal_common.h | 1 -
drivers/thermal/samsung/exynos_tmu.c| 13 -
2 files changed, 14 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..cd44719 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -27,7 +27,6 @@
#define SENSOR_NAME_LEN 16
#define MAX_TRIP_COUNT8
#define MAX_COOLING_DEVICE 4
-#define MAX_THRESHOLD_LEVS 5
#define ACTIVE_INTERVAL 500
#define IDLE_INTERVAL 1
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 903566f..789d745 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -158,23 +158,10 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
data-temp_error pdata-max_efuse_value)
data-temp_error = pdata-efuse_value EXYNOS_TMU_TEMP_MASK;
- if (pdata-max_trigger_level MAX_THRESHOLD_LEVS) {
- dev_err(pdev-dev, Invalid max trigger level\n);
- ret = -EINVAL;
- goto out;
- }
-
for (i = 0; i pdata-max_trigger_level; i++) {
if (!pdata-trigger_levels[i])
continue;
- if ((pdata-trigger_type[i] == HW_TRIP)
- (!pdata-trigger_levels[pdata-max_trigger_level - 1])) {
- dev_err(pdev-dev, Invalid hw trigger level\n);
- ret = -EINVAL;
- goto out;
- }
-
Does it mean no new pdata are going to be written? i.e., no new soc is
going to be supported by this driver that needs proper pdata checking?
This is not a proper checking. The checks in question are done at runtime
in a production code for data that is hardcoded inside driver during
development time and later it doesn't change. Such data should be verified
during development and review time (i.e. by a script parsing relevant data
from exynos_tmu_data.c, one can also argue that verification to be done is
so simple that the review by a maintainer should be enough).
Agreed to your arguments. These changes looks fine.
/* Count trigger levels except the HW trip*/
if (!(pdata-trigger_type[i] == HW_TRIP))
trigger_levs++;
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize()
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Remove runtime checks for negative return values of temp_to_code()
from exynos_tmu_initialize(). The current level temperature data
hardcoded in pdata will never cause a negative temp_to_code()
return values and for the new code potential mistakes should be
caught during development/review phases.
Your arguments looks fine.
Theres should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 789d745..a415829 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -170,10 +170,6 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
- if (threshold_code 0) {
- ret = threshold_code;
- goto out;
- }
writeb(threshold_code,
data-base + reg-threshold_temp);
for (i = 0; i trigger_levs; i++)
@@ -187,18 +183,12 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
i trigger_levs i EXYNOS_MAX_TRIGGER_PER_REG; i++) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
- if (threshold_code 0) {
- ret = threshold_code;
- goto out;
- }
rising_threshold |= threshold_code 8 * i;
if (pdata-threshold_falling) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i] -
pdata-threshold_falling);
- if (threshold_code 0)
- falling_threshold |=
- threshold_code 8 * i;
+ falling_threshold |= threshold_code 8 * i;
}
}
@@ -217,10 +207,6 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
(pdata-trigger_type[i] == HW_TRIP)) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
- if (threshold_code 0) {
- ret = threshold_code;
- goto out;
- }
if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
/* 1-4 level to be assigned in th0 reg */
rising_threshold |= threshold_code 8 * i;
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-pm 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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] thermal: exynos: simplify temp_to_code() and code_to_temp()
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
* Remove dead temp check from temp_to_code() (this function users
in exynos_tmu_initialize() always pass correct temperatures and
exynos_tmu_set_emulation() returns early for EXYNOS4210 because
TMU_SUPPORT_EMULATION flag is not set on this SoC).
* Move temp_code check from code_to_temp() to exynos_tmu_read()
(code_to_temp() only user).
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Changes looks fine.
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 38
+++-
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index a415829..20379eb 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -71,19 +71,7 @@ struct exynos_tmu_data {
*/
static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
{
- struct exynos_tmu_platform_data *pdata = data-pdata;
- int temp_code;
-
- if (data-soc == SOC_ARCH_EXYNOS4210)
- /* temp should range between 25 and 125 */
- if (temp 25 || temp 125) {
- temp_code = -EINVAL;
- goto out;
- }
-
- temp_code = temp + data-temp_error - pdata-first_point_trim;
-out:
- return temp_code;
+ return temp + data-temp_error - data-pdata-first_point_trim;
}
/*
@@ -92,19 +80,7 @@ out:
*/
static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
{
- struct exynos_tmu_platform_data *pdata = data-pdata;
- int temp;
-
- if (data-soc == SOC_ARCH_EXYNOS4210)
- /* temp_code should range between 75 and 175 */
- if (temp_code 75 || temp_code 175) {
- temp = -ENODATA;
- goto out;
- }
-
- temp = temp_code - data-temp_error + pdata-first_point_trim;
-out:
- return temp;
+ return temp_code - data-temp_error + data-pdata-first_point_trim;
}
static int exynos_tmu_initialize(struct platform_device *pdev)
@@ -297,8 +273,16 @@ static int exynos_tmu_read(struct exynos_tmu_data
*data)
clk_enable(data-clk);
temp_code = readb(data-base + reg-tmu_cur_temp);
- temp = code_to_temp(data, temp_code);
+ if (data-soc == SOC_ARCH_EXYNOS4210)
+ /* temp_code should range between 75 and 175 */
+ if (temp_code 75 || temp_code 175) {
+ temp = -ENODATA;
+ goto out;
+ }
+
+ temp = code_to_temp(data, temp_code);
+out:
clk_disable(data-clk);
mutex_unlock(data-lock);
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] thermal: exynos: cache non_hw_trigger_levels in pdata
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Cache number of non-hardware trigger levels in a new pdata field
(non_hw_trigger_levels) and convert code in exynos_tmu_initialize()
accordingly.
Changes looks fine,
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 16 +++-
drivers/thermal/samsung/exynos_tmu.h | 2 ++
drivers/thermal/samsung/exynos_tmu_data.c | 3 +++
3 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 20379eb..a8d9524 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -90,7 +90,7 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
const struct exynos_tmu_registers *reg = pdata-registers;
unsigned int status, trim_info = 0, con;
unsigned int rising_threshold = 0, falling_threshold = 0;
- int ret = 0, threshold_code, i, trigger_levs = 0;
+ int ret = 0, threshold_code, i;
mutex_lock(data-lock);
clk_enable(data-clk);
@@ -134,29 +134,19 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
data-temp_error pdata-max_efuse_value)
data-temp_error = pdata-efuse_value EXYNOS_TMU_TEMP_MASK;
- for (i = 0; i pdata-max_trigger_level; i++) {
- if (!pdata-trigger_levels[i])
- continue;
-
- /* Count trigger levels except the HW trip*/
- if (!(pdata-trigger_type[i] == HW_TRIP))
- trigger_levs++;
- }
-
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
writeb(threshold_code,
data-base + reg-threshold_temp);
- for (i = 0; i trigger_levs; i++)
+ for (i = 0; i pdata-non_hw_trigger_levels; i++)
writeb(pdata-trigger_levels[i], data-base +
reg-threshold_th0 + i * sizeof(reg-threshold_th0));
writel(reg-inten_rise_mask, data-base + reg-tmu_intclear);
} else {
/* Write temperature code for rising and falling threshold */
- for (i = 0;
- i trigger_levs i EXYNOS_MAX_TRIGGER_PER_REG; i++) {
+ for (i = 0; i pdata-non_hw_trigger_levels; i++) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
rising_threshold |= threshold_code 8 * i;
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 186e39e..4845171 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -183,6 +183,7 @@ struct exynos_tmu_registers {
* 1 = enable trigger_level[] interrupt,
* 0 = disable trigger_level[] interrupt
* @max_trigger_level: max trigger level supported by the TMU
+ * @non_hw_trigger_levels: number of defined non-hardware trigger levels
* @gain: gain of amplifier in the positive-TC generator block
* 0 = gain = 15
* @reference_voltage: reference voltage of amplifier
@@ -213,6 +214,7 @@ struct exynos_tmu_platform_data {
enum trigger_type trigger_type[MAX_TRIP_COUNT];
bool trigger_enable[MAX_TRIP_COUNT];
u8 max_trigger_level;
+ u8 non_hw_trigger_levels;
u8 gain;
u8 reference_voltage;
u8 noise_cancel_mode;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index c32d186..ef7f186 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -62,6 +62,7 @@ struct exynos_tmu_init_data const
exynos4210_default_tmu_data = {
.trigger_type[1] = THROTTLE_ACTIVE,
.trigger_type[2] = SW_TRIP,
.max_trigger_level = 4,
+ .non_hw_trigger_levels = 3,
.gain = 15,
.reference_voltage = 7,
.min_efuse_value = 40,
@@ -135,6 +136,7 @@ static const struct exynos_tmu_registers
exynos4412_tmu_registers = {
.trigger_type[2] = SW_TRIP, \
.trigger_type[3] = HW_TRIP, \
.max_trigger_level = 4, \
+ .non_hw_trigger_levels = 3, \
.gain = 8, \
.reference_voltage = 16, \
.noise_cancel_mode = 4, \
@@ -225,6 +227,7 @@ static const struct exynos_tmu_registers
exynos5440_tmu_registers = {
.trigger_type[0] = SW_TRIP, \
.trigger_type[4] = HW_TRIP, \
.max_trigger_level = 5, \
+ .non_hw_trigger_levels = 1, \
.gain = 5, \
.reference_voltage = 16, \
Re: [PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
On 10/4/13, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Menu for Samsung thermal support is visible on all Samsung platforms while thermal drivers are currently available only for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency with ARCH_EXYNOS one. Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Looks good, so Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index a709c63..05cf95c 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -198,7 +198,7 @@ source drivers/thermal/ti-soc-thermal/Kconfig endmenu menu Samsung thermal drivers -depends on PLAT_SAMSUNG +depends on ARCH_EXYNOS source drivers/thermal/samsung/Kconfig endmenu -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: EXYNOS: always register TMU driver with core thermal framework
On 11/25/13, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Hi,
Could you please also apply this patch?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
On Friday, October 04, 2013 02:38:25 PM Bartlomiej Zolnierkiewicz wrote:
There is little sense in having separate config option for
registering EXYNOS TMU driver with the core thermal framework.
Fix it by integrating EXYNOS_THERMAL_CORE config option with
EXYNOS_THERMAL one.
Sorry for the late reply but this patch is not needed as in my opinion
as it is just decreasing the flexibility when only sensor hardware
needs to be initialised and all cooling is hw controlled.
Thanks,
Amit D
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/thermal/samsung/Kconfig | 14 +++---
drivers/thermal/samsung/Makefile| 2 +-
drivers/thermal/samsung/exynos_thermal_common.h | 12
3 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/thermal/samsung/Kconfig
b/drivers/thermal/samsung/Kconfig
index f760389..04eabee 100644
--- a/drivers/thermal/samsung/Kconfig
+++ b/drivers/thermal/samsung/Kconfig
@@ -5,14 +5,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for the TMU (Thermal Management
Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver
initialises
the TMU, reports temperature and handles cooling action if defined.
- This driver uses the Exynos core thermal APIs and TMU configuration
- data from the supported SoCs.
-
-config EXYNOS_THERMAL_CORE
-bool Core thermal framework support for EXYNOS SOCs
-depends on EXYNOS_THERMAL
-help
- If you say yes here you get support for EXYNOS TMU
- (Thermal Management Unit) common registration/unregistration
- functions to the core thermal layer and also to use the generic
- CPU cooling APIs.
+ This driver uses the Exynos core thermal APIs, TMU configuration data
+ from the supported SoCs, common registration/unregistration functions
+ to the core thermal layer and also the generic CPU cooling APIs.
diff --git a/drivers/thermal/samsung/Makefile
b/drivers/thermal/samsung/Makefile
index c09d830..a829107 100644
--- a/drivers/thermal/samsung/Makefile
+++ b/drivers/thermal/samsung/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_EXYNOS_THERMAL)+= exynos_thermal.o
exynos_thermal-y:= exynos_tmu.o
exynos_thermal-y+= exynos_tmu_data.o
-exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)+=
exynos_thermal_common.o
+exynos_thermal-y+= exynos_thermal_common.o
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..8681679 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -88,20 +88,8 @@ struct thermal_sensor_conf {
struct device *dev;
};
-/*Functions used exynos based thermal sensor driver*/
-#ifdef CONFIG_EXYNOS_THERMAL_CORE
void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
-#else
-static inline void
-exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) {
return; }
-static inline int
-exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return
0; }
-
-static inline void
-exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return;
}
-
-#endif /* CONFIG_EXYNOS_THERMAL_CORE */
#endif /* _EXYNOS_THERMAL_COMMON_H */
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/3] ARM: EXYNOS: Move arm core power down clock to exynos5250 common clock
Hi Bartlomeij, Yes these patches have missed 2 merge windows and still not merged. Mike: I am re-basing these patches on linux-next. Please merge them. Regards, Amit On Wed, Oct 9, 2013 at 3:18 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Hi, Mike: Could you please apply this patch? It is few months overdue.. Amit: This patch no longer applies to -next. Could you please refresh and resend it? You can add: Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com while at it. Thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics On Friday, August 16, 2013 10:22:44 AM amit daniel kachhap wrote: Hi Mike, Please merge this patch as it is pending since last merge window. Thanks, Amit On Thu, Jun 13, 2013 at 5:56 PM, Kukjin Kim kgene@samsung.com wrote: Amit Daniel Kachhap wrote: Now with common clock support added for exynos5250 it is necessary to move this code to exynos5250 common clock driver as clock registers should be handled there. This change is tested in exynos5250 based arndale platform. Cc: Abhilash Kesavan a.kesa...@samsung.com Cc: Thomas Abraham thomas.abra...@linaro.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Hmm...I'm not sure it's better to handle the ARM core power down clock in common clock but the clock registers should be handled in one part, clock. Acked-by: Kukjin Kim kgene@samsugn.com Mike, the mach-exynos/cpuidle.c is not touched in samsung tree at this moment, so this patch will not create any conflict between samsung and clk. Thanks, - Kukjin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel On Wed, Oct 9, 2013 at 3:18 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Hi, Mike: Could you please apply this patch? It is few months overdue.. Amit: This patch no longer applies to -next. Could you please refresh and resend it? You can add: Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com while at it. Thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics On Friday, August 16, 2013 10:22:44 AM amit daniel kachhap wrote: Hi Mike, Please merge this patch as it is pending since last merge window. Thanks, Amit On Thu, Jun 13, 2013 at 5:56 PM, Kukjin Kim kgene@samsung.com wrote: Amit Daniel Kachhap wrote: Now with common clock support added for exynos5250 it is necessary to move this code to exynos5250 common clock driver as clock registers should be handled there. This change is tested in exynos5250 based arndale platform. Cc: Abhilash Kesavan a.kesa...@samsung.com Cc: Thomas Abraham thomas.abra...@linaro.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Hmm...I'm not sure it's better to handle the ARM core power down clock in common clock but the clock registers should be handled in one part, clock. Acked-by: Kukjin Kim kgene@samsugn.com Mike, the mach-exynos/cpuidle.c is not touched in samsung tree at this moment, so this patch will not create any conflict between samsung and clk. Thanks, - Kukjin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] thermal:exynos4: Enable support for Exynos4412 SoCs
Hi,
I have one suggestion,
On Fri, Apr 19, 2013 at 10:08 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Enable TMU support for Exynos4412 based target with device tree.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/thermal/exynos_thermal.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index e922fa4..f54066d 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -819,6 +819,10 @@ static const struct of_device_id exynos_tmu_match[] = {
.data = (void *)EXYNOS4210_TMU_DRV_DATA,
},
{
+ .compatible = samsung,exynos4412-tmu,
+ .data = (void *)EXYNOS_TMU_DRV_DATA,
+ },
Instead of adding a new compatible string, exynos5250-tmu name can
be re-used in the 4412 DT node file as 4412 and 5250 TMU controller
are same.
Thanks,
Amit Daniel
+ {
.compatible = samsung,exynos5250-tmu,
.data = (void *)EXYNOS_TMU_DRV_DATA,
},
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/9] thermal: exynos: Adapt to temperature emulation core thermal framework
Hi Eduardo,
Thanks for your review comments.
On Fri, Apr 12, 2013 at 1:03 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
Hello Amit,
Couple of comments inline.
On 26-03-2013 07:33, Amit Daniel Kachhap wrote:
This removes the driver specific sysfs support of the temperature
emulation and uses the newly added core thermal framework for thermal
emulation. An exynos platform specific handler is added to support this.
In this patch, the exynos senor(tmu) related code and exynos framework
related (thermal zone, cooling devices) code are intentionally kept
separate.
So an emulated function pointer is passed from sensor to framework. This
is
beneficial in adding more sensor support using the same framework code
which is an ongoing work. The goal is to finally split them totally. Even
the existing read_temperature also follows the same execution method.
Acked-by: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Documentation/thermal/exynos_thermal_emulation |8 +-
drivers/thermal/Kconfig|9 --
drivers/thermal/exynos_thermal.c | 158
++--
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/Documentation/thermal/exynos_thermal_emulation
b/Documentation/thermal/exynos_thermal_emulation
index b73bbfb..36a3e79 100644
--- a/Documentation/thermal/exynos_thermal_emulation
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for
TMU's operation. User can set
manually with software code and TMU will read current temperature from
user value not from
sensor's value.
-Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
available.
-When it's enabled, sysfs node will be created under
-/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
+Enabling CONFIG_THERMAL_EMULATION option will make this support
available.
+When it's enabled, sysfs node will be created as
+/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
-The sysfs node, 'emulation', will contain value 0 for the initial state.
When you input any
+The sysfs node, 'emul_node', will contain value 0 for the initial state.
When you input any
temperature you want to update to sysfs node, it automatically enable
emulation mode and
current temperature will be changed into it.
(Exynos also supports user changable delay time which would be used to
delay of
not part of this patch but:
s/changable/changeable
Ok
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index a764f16..da4c19e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -117,15 +117,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for TMU (Thermal Management
Unit) on SAMSUNG EXYNOS series of SoC.
-config EXYNOS_THERMAL_EMUL
- bool EXYNOS TMU emulation mode support
- depends on EXYNOS_THERMAL
- help
- Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
- Enable this option will be make sysfs node in exynos thermal
platform
- device directory to support emulation mode. With emulation mode
sysfs
- node, you can manually input temperature to TMU for simulation
purpose.
-
config DOVE_THERMAL
tristate Temperature sensor on Marvell Dove SoCs
depends on ARCH_DOVE
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 46568c0..1cd7837 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -100,13 +100,13 @@
#define IDLE_INTERVAL 1
#define MCELSIUS 1000
-#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+#ifdef CONFIG_THERMAL_EMULATION
#define EXYNOS_EMUL_TIME 0x57F0
#define EXYNOS_EMUL_TIME_SHIFT16
#define EXYNOS_EMUL_DATA_SHIFT8
#define EXYNOS_EMUL_DATA_MASK 0xFF
#define EXYNOS_EMUL_ENABLE0x1
-#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
+#endif /* CONFIG_THERMAL_EMULATION */
As the above is only used in one single function, I suggest moving it to
same ifdef where the function belongs below. It reduces your ifdefery and
also makes your code cleaner.
Right makes sense.
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -145,6 +145,7 @@ struct thermal_cooling_conf {
struct thermal_sensor_conf {
char name[SENSOR_NAME_LEN];
int (*read_temperature)(void *data);
+ int (*write_emul_temp)(void *drv_data, unsigned long temp);
I dont get why you need a private callback to do this, assuming you have
only one sensor_conf for exynos.
Actually It is done in this way to keep sensor related stuffs and
common thermal zone related parts. With this it is easy to split this
file in later patches.
struct thermal_trip_point_conf trip_data;
struct thermal_cooling_conf cooling_data;
Re: [2/9] thermal: exynos: Add support for instance based register/unregister
Hi Eduardo,
On Fri, Apr 12, 2013 at 1:39 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
Hey Amit,
On 26-03-2013 07:33, Amit Daniel Kachhap wrote:
This code modifies the thermal driver to have multiple thermal zone
support by replacing the global thermal zone varibale with device data
s/varibale/variable
ok type mistake :)
member of thermal_zone_device.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
I understand the idea of your patch but I also see that you do at least to
major changes. One is to set the thermal_device.devdata. The second is to
split your internal reference private_data into driver_data and pzone_data.
Is it possible to split this patch into two, one per modification? So it is
easier to review your changes?
yes agreed..the kind of patch restructuring suggested by you makes sense.
---
drivers/thermal/exynos_thermal.c | 65
++---
1 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 1cd7837..dc9b91b 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -148,7 +148,8 @@ struct thermal_sensor_conf {
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;
+ void *driver_data;
+ void *pzone_data;
};
struct exynos_thermal_zone {
@@ -161,14 +162,14 @@ struct exynos_thermal_zone {
bool bind;
};
-static struct exynos_thermal_zone *th_zone;
-static void exynos_unregister_thermal(void);
+static void exynos_unregister_thermal(struct thermal_sensor_conf
*sensor_conf);
static int exynos_register_thermal(struct thermal_sensor_conf
*sensor_conf);
/* Get mode callback functions for thermal zone */
static int exynos_get_mode(struct thermal_zone_device *thermal,
enum thermal_device_mode *mode)
{
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
if (th_zone)
*mode = th_zone-mode;
return 0;
@@ -178,25 +179,26 @@ static int exynos_get_mode(struct
thermal_zone_device *thermal,
static int exynos_set_mode(struct thermal_zone_device *thermal,
enum thermal_device_mode mode)
{
- if (!th_zone-therm_dev) {
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
+ if (!th_zone) {
pr_notice(thermal zone not registered\n);
return 0;
}
- mutex_lock(th_zone-therm_dev-lock);
+ mutex_lock(thermal-lock);
if (mode == THERMAL_DEVICE_ENABLED
!th_zone-sensor_conf-trip_data.trigger_falling)
- th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
+ thermal-polling_delay = IDLE_INTERVAL;
else
- th_zone-therm_dev-polling_delay = 0;
+ thermal-polling_delay = 0;
- mutex_unlock(th_zone-therm_dev-lock);
+ mutex_unlock(thermal-lock);
th_zone-mode = mode;
- thermal_zone_device_update(th_zone-therm_dev);
+ thermal_zone_device_update(thermal);
pr_info(thermal polling set for duration=%d msec\n,
- th_zone-therm_dev-polling_delay);
+ thermal-polling_delay);
return 0;
}
@@ -223,6 +225,8 @@ static int exynos_get_trip_type(struct
thermal_zone_device *thermal, int trip,
static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int
trip,
unsigned long *temp)
{
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
+
if (trip GET_TRIP(MONITOR_ZONE) || trip GET_TRIP(PANIC_ZONE))
return -EINVAL;
@@ -269,6 +273,7 @@ static int exynos_bind(struct thermal_zone_device
*thermal,
{
int ret = 0, i, tab_size, level;
struct freq_clip_table *tab_ptr, *clip_data;
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
struct thermal_sensor_conf *data = th_zone-sensor_conf;
tab_ptr = (struct freq_clip_table *)data-cooling_data.freq_data;
@@ -315,6 +320,7 @@ static int exynos_unbind(struct thermal_zone_device
*thermal,
struct thermal_cooling_device *cdev)
{
int ret = 0, i, tab_size;
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
struct thermal_sensor_conf *data = th_zone-sensor_conf;
if (th_zone-bind == false)
@@ -357,13 +363,14 @@ static int exynos_unbind(struct thermal_zone_device
*thermal,
static int exynos_get_temp(struct thermal_zone_device *thermal,
unsigned long *temp)
{
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
void *data;
if (!th_zone-sensor_conf) {
Re: [PATCH V4 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
On Tue, Mar 12, 2013 at 4:19 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
This is what Russell told me a long time back:
Don't use Adding, Fixing, etc words as this work is not something, which is
already done.
So your subject should have been: cpufreq: exynos: Add cpufreq driver
for exynos5440
ok right.
Fix it if you need another version, which i believe you do :)
yes no escape now :)
On Tue, Mar 12, 2013 at 5:58 PM, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they scale at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notfication for
s/notfication/notification
ok
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/cpufreq/cpufreq-exynos5440.txt| 29 ++
drivers/cpufreq/Kconfig.arm|9 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 466
4 files changed, 505 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git
a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..a0dbe0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,29 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be
transitioned into,
+ in the decreasing order. Frequency should be in KHZ units and voltage
s/KHZ/KHz
ok
+ should be in microvolts.
probably s/microvolts/micro-volts ??
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ operating-points =
+ 100 975000
+ 80 925000;
+ clock-latency = 10;
+ };
+
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
+static void exynos_enable_dvfs(void)
+{
+ /* Set initial performance index */
+ for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
+ if (freq_table[i].frequency == dvfs_info-cur_frequency)
+ break;
+
+ if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
+ dev_crit(dvfs_info-dev, Boot up frequency not
supported\n);
+ /* Assign the highest frequency */
+ i = 0;
+ dvfs_info-cur_frequency = freq_table[i].frequency;
What about:
dvfs_info-cur_frequency = freq_table[0].frequency;
as i don't see i being used again?
No It is used below for frequency setting.
+ }
+}
+static int exynos_target(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ if (cpufreq_frequency_table_target(policy, freq_table,
+ target_freq, relation, index)) {
+ ret = -EINVAL;
Use the error value returned by called functions, probably i gave this
comment last time too?
yes my mistake.
+ goto out;
+ }
+}
+static void exynos_sort_descend_freq_table(void)
+{
+ struct cpufreq_frequency_table *freq_tbl = dvfs_info-freq_table;
+ int i = 0, index;
+ unsigned int tmp_freq;
+
+ /*
+* Freq table is already in ascending order as it is created from
+* OPP library, so just swap the elements to make it descending.
why??
I explained this requirement in the patch commit. Will explain it here again.
+*/
+ for (i = 0; i dvfs_info-freq_count / 2; i++) {
+ index = dvfs_info-freq_count - i - 1;
+ tmp_freq = freq_tbl[i].frequency;
+ freq_tbl[i].frequency = freq_tbl[index].frequency;
+
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Sylwester,
Thanks for the review. Will update with your suggestion in the next version,
Thanks,
Amit D
On Thu, Mar 7, 2013 at 8:58 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
+/* Register definations */
s/definations/definitions
ok
+#define XMU_DVFS_CTRL0x0060
+#define XMU_PMU_P0_7 0x0064
+#define XMU_C0_3_PSTATE 0x0090
+#define XMU_P_LIMIT 0x00A0
+#define XMU_P_STATUS 0x00A4
+#define XMU_PMUEVTEN 0x00D0
+#define XMU_PMUIRQEN 0x00D4
+#define XMU_PMUIRQ 0x00D8
Keeping all hex numbers lower case might be a good idea.
Ok
+
+/* PMU mask and shift definations */
+#define P_VALUE_MASK 0x7
+
+#define XMU_DVFS_CTRL_EN_SHIFT 0
+
+#define P0_7_CPUCLKDEV_SHIFT 21
+#define P0_7_CPUCLKDEV_MASK 0x7
+#define P0_7_ATBCLKDEV_SHIFT 18
+#define P0_7_ATBCLKDEV_MASK 0x7
+#define P0_7_CSCLKDEV_SHIFT 15
+#define P0_7_CSCLKDEV_MASK 0x7
+#define P0_7_CPUEMA_SHIFT28
+#define P0_7_CPUEMA_MASK 0xf
+#define P0_7_L2EMA_SHIFT 24
+#define P0_7_L2EMA_MASK 0xf
...
+static int exynos_cpufreq_probe(struct platform_device *pdev)
+{
+ int ret = -EINVAL;
+ struct device_node *np;
+ struct resource res;
+
+ np = of_find_compatible_node(NULL, NULL,
samsung,exynos5440-cpufreq);
+ if (!np)
+ return -ENODEV;
+
+ dvfs_info = devm_kzalloc(pdev-dev, sizeof(*dvfs_info), GFP_KERNEL);
+ if (!dvfs_info) {
+ ret = -ENOMEM;
+ goto err_put_node;
+ }
+
+ dvfs_info-dev = pdev-dev;
+ dvfs_info-dev-of_node = np;
+
+ ret = of_address_to_resource(np, 0, res);
+ if (ret)
+ goto err_put_node;
+
+ dvfs_info-base = devm_ioremap(dvfs_info-dev, res.start,
There is a devm_ioremap_resource() function that has been introduced
recently. It could simplify this code a bit and is preferred over
devm_ioremap().
yes right. I somehow missed this api.
+ resource_size(res));
+ if (!dvfs_info-base) {
+ pr_err(No cpufreq memory map found\n);
+ ret = -ENODEV;
+ goto err_put_node;
+ }
+
+ dvfs_info-irq = irq_of_parse_and_map(np, 0);
+ if (dvfs_info-irq == 0) {
+ pr_err(No cpufreq irq found\n);
Wouldn't dev_err() be more appropriate here ?
Ok
+ ret = -ENODEV;
+ goto err_put_node;
+ }
+
+ ret = of_init_opp_table(dvfs_info-dev);
+ if (ret) {
+ pr_err(failed to init OPP table: %d\n, ret);
+ goto err_put_node;
+ }
+
+ ret = opp_init_cpufreq_table(dvfs_info-dev, dvfs_info-freq_table);
+ if (ret) {
+ pr_err(failed to init cpufreq table: %d\n, ret);
+ goto err_put_node;
+ }
+ dvfs_info-freq_count = opp_get_opp_count(dvfs_info-dev);
+ exynos_sort_descend_freq_table();
+
+ if (of_property_read_u32(np, clock-latency, dvfs_info-latency))
+ dvfs_info-latency = DEF_TRANS_LATENCY;
+
+ dvfs_info-cpu_clk = devm_clk_get(dvfs_info-dev, armclk);
+ if (IS_ERR_OR_NULL(dvfs_info-cpu_clk)) {
devm_clk_get() return value needs to be checked with IS_ERR(),
not IS_ERR_OR_NULL().
ok
+ pr_err(Failed to get cpu clock\n);
+ ret = PTR_ERR(dvfs_info-cpu_clk);
+ goto err_free_table;
+ }
+
+ dvfs_info-cur_frequency = clk_get_rate(dvfs_info-cpu_clk);
+ if (!dvfs_info-cur_frequency) {
+ pr_err(Failed to get clock rate\n);
+ ret = -EINVAL;
+ goto err_free_table;
+ }
+ dvfs_info-cur_frequency /= 1000;
+
+ INIT_WORK(dvfs_info-irq_work, exynos_cpufreq_work);
+ if (devm_request_irq(dvfs_info-dev, dvfs_info-irq,
exynos_cpufreq_irq,
+ IRQF_TRIGGER_NONE, CPUFREQ_NAME, dvfs_info)) {
+ pr_err(Failed to register IRQ\n);
+ ret = -ENODEV;
+ goto err_free_table;
+ }
+
+ ret = init_div_table();
+ if (ret) {
+ pr_err(Failed to initialise div table\n);
+ goto err_free_table;
+ }
+
+ exynos_enable_dvfs();
+ ret = cpufreq_register_driver(exynos_driver);
+ if (ret) {
+ pr_err(%s: failed to register cpufreq driver\n, __func__);
+ goto err_free_table;
+ }
+
+ of_node_put(np);
+ dvfs_info-dvfs_enable = true;
+ pr_info(exynos5440 DVFS initialized.\n);
dev_info() ?
+ return 0;
+
+err_free_table:
+ opp_free_cpufreq_table(dvfs_info-dev, dvfs_info-freq_table);
+err_put_node:
+ of_node_put(np);
+ pr_err(%s: failed initialization\n, __func__);
Is this really needed ? This failure will be logged by the driver core
anyway.
+ return ret;
+
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Russell,
On Thu, Mar 7, 2013 at 9:07 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Mar 07, 2013 at 04:28:00PM +0100, Sylwester Nawrocki wrote:
On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
+ dvfs_info-cpu_clk = devm_clk_get(dvfs_info-dev, armclk);
+ if (IS_ERR_OR_NULL(dvfs_info-cpu_clk)) {
devm_clk_get() return value needs to be checked with IS_ERR(),
not IS_ERR_OR_NULL().
+ pr_err(Failed to get cpu clock\n);
+ ret = PTR_ERR(dvfs_info-cpu_clk);
+ goto err_free_table;
Amit, to illustrate why this is wrong, consider this:
1. Set cpu_clk to NULL.
2. Realise IS_ERR_OR_NULL(NULL) is true.
3. What is the value of PTR_ERR(NULL) ?
4. What effect does that have when you jump to err_free_table ?
5. What value is returned from this function in that case ?
6. What does that return value mean to the driver core ?
Thanks for the detailed explaination. Usage of IS_ERR_OR_NULL is not
suitable here.
Thanks,
Amit D
--
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/
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
On Sat, Mar 9, 2013 at 4:17 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 7 March 2013 12:13, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
+struct exynos_dvfs_data {
+ void __iomem *base;
+ struct resource *mem;
+ int irq;
+ struct clk *cpu_clk;
+ unsigned int cur_frequency;
+ unsigned int latency;
+ struct cpufreq_frequency_table *freq_table;
+ unsigned int freq_count;
+ struct device *dev;
+ bool dvfs_enable;
s/enable/enabled?
Ok
+static int exynos_cpufreq_probe(struct platform_device *pdev)
+ dvfs_info-cpu_clk = devm_clk_get(dvfs_info-dev, armclk);
+ if (IS_ERR_OR_NULL(dvfs_info-cpu_clk)) {
s/IS_ERR_OR_NULL/IS_ERR
Ok.
+ if (devm_request_irq(dvfs_info-dev, dvfs_info-irq,
exynos_cpufreq_irq,
+ IRQF_TRIGGER_NONE, CPUFREQ_NAME, dvfs_info))
{
+ pr_err(Failed to register IRQ\n);
+ ret = -ENODEV;
use the value returned from this function rather than creating your
own.. true for all
other calls too, unless they return NULL on error.
Will integrate your suggestions in the next version.
Thanks,
Amit D
+}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
Again thanks for your review comments.
On Tue, Mar 5, 2013 at 6:48 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 2 March 2013 15:04, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they run at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notfication for
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Changes in V2:
* Added OPP library support to parse DT parameters.
* Removed a hack to handle interrupts in bootup.
* Added many review comments from Viresh and Inder.
Added? Thanks :)
typo error :)
All these patches are dependent on Thomas Abraham common clock patches.
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html
.../bindings/cpufreq/cpufreq-exynos5440.txt| 32 ++
drivers/cpufreq/Kconfig.arm|9 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 450
4 files changed, 492 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git
a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..caa3f8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,32 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be
transitioned into,
+ in the decreasing order. Frequency should be in KHZ units and voltage
+ should be in microvolts.
+- clocks: phandle of the clock from common clock binding. More description
can
+ be found in
Documentation/devicetree/bindings/clock/clock-bindings.txt.
+
+Optional properties:
+- clock-latency: Clock transition latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ operating-points =
+ 100 975000
+ 80 925000;
+ clocks = clock 2;
+ clock-latency = 10;
+ };
+
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 030ddf6..7ed9c4a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -77,6 +77,15 @@ config ARM_EXYNOS5250_CPUFREQ
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+config ARM_EXYNOS5440_CPUFREQ
+ def_bool SOC_EXYNOS5440
+ depends on HAVE_CLK PM_OPP OF
+ help
+ This adds the CPUFreq driver for Samsung EXYNOS5440
+ SoC. The nature of exynos5440 clock controller is
+ different than previous exynos controllers so not using
+ the common exynos framework.
+
config ARM_KIRKWOOD_CPUFREQ
def_bool ARCH_KIRKWOOD OF
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 863fd18..c841438 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 000..2dc43b1
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,450 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Amit Daniel Kachhap amit.dan...@samsung.com
+ *
+ * EXYNOS5440 -
Re: [PATCH 3/3] dts: Add cpufreq controller node for Exynos5440 SoC
On Fri, Feb 8, 2013 at 8:49 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 8 February 2013 00:03, amit kachhap amit.kach...@gmail.com wrote:
On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com
wrote:
Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 024269d..b20b517 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,15 @@
};
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ cpufreq_tbl = 120 1025000
+ 100 975000
+ 80 925000 ;
+ };
+
I think cpufreq_tbl should be part of the cpu node as it's the
property of the cpu.
Please refer cpufreq-cpu0 and spear-cpufreq.
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15364.
In this thread same discussion followed. I am not sure what is the
correct way but looks like Kukjin concluded this with a timer node
separate from the CPU code.
I am only talking about cpufreq_tbl and its nothing but operating
points for the cpus. It seems its agreed upon to add operating-points
to cpu node as being done by all other platforms like imx6q, am33xx,
cpufreq-cpu0 and spear.
Even timer, GIC, cpufreq tbl, pmu etc are all cpu properties. But the
problem is whether to put them in cpu0 or repeat same information in
all cpu nodes as it is common to all cpu's and not just cpu0. So as
Kukjin kim has put the timer node outside the cpu node so i also
followed the same convention.
Mr Kim,
Any issue in this approach?
Thanks,
Amit Daniel
Thanks,
Inder
Thanks,
Amit Daniel
serial@B {
compatible = samsung,exynos4210-uart;
reg = 0xB 0x1000;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe
linux-samsung-soc 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-samsung-soc 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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] dts: Add cpufreq controller node for Exynos5440 SoC
On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 024269d..b20b517 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,15 @@
};
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ cpufreq_tbl = 120 1025000
+ 100 975000
+ 80 925000 ;
+ };
+
I think cpufreq_tbl should be part of the cpu node as it's the
property of the cpu.
Please refer cpufreq-cpu0 and spear-cpufreq.
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15364.
In this thread same discussion followed. I am not sure what is the
correct way but looks like Kukjin concluded this with a timer node
separate from the CPU code.
Thanks,
Amit Daniel
serial@B {
compatible = samsung,exynos4210-uart;
reg = 0xB 0x1000;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
Thanks for the detailed review. Will try to handle them in the next version,
On Thu, Feb 7, 2013 at 3:17 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. The nature of exynos5440
clock controller is different from previous exynos controllers so not using
the common exynos cpufreq framework. Also, the device tree parsing is added
to get different parameters like frequency, voltage etc.
Some information about platform cpu configuration would be helpful.. cpus,
type,
clock lines for cpus - shared/separate?
Ok.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/cpufreq/cpufreq-exynos5440.txt| 24 ++
drivers/cpufreq/Kconfig.arm|8 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 448
4 files changed, 481 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git
a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..96cb0ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,24 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- cpufreq_tbl: Table of frequencies and voltage CPU could be transitioned
into,
This has to be operating-points as in cpufreq-cpu0 driver.
Yes I will check if opp table is beneficial. In my case it is just one
time parsing of cpufreq table and those values(freq, volt) are not
used later so did not use opp libraries.
+ in the decreasing order. Frequency should be in KHZ units and voltage
+ should be in microvolts.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ cpufreq_tbl = 120 1025000
+ 100 975000
+ 80 925000 ;
+ };
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 000..41d39e2
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,448 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Amit Daniel Kachhap amit.dan...@samsung.com
+ *
+ * EXYNOS5440 - CPU frequency scaling support
+ *
+ * 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.
+*/
+
+#include linux/clk.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/slab.h
+
+/*Register definations*/
+#define XMU_DVFS_CTRL 0x0060
+#define XMU_PMU_P0_7 0x0064
+#define XMU_C0_3_PSTATE0x0090
+#define XMU_P_LIMIT0x00A0
+#define XMU_P_STATUS 0x00A4
+#define XMU_PMUEVTEN 0x00D0
+#define XMU_PMUIRQEN 0x00D4
+#define XMU_PMUIRQ 0x00D8
+
+/*PMU mask and shift definations*/
+#define P_VALUE_MASK 0x7
+
+#define XMU_DVFS_CTRL_EN_SHIFT 0
+
+#define P0_7_CPUCLKDEV_SHIFT 21
+#define P0_7_CPUCLKDEV_MASK0x7
+#define P0_7_ATBCLKDEV_SHIFT 18
+#define P0_7_ATBCLKDEV_MASK0x7
+#define P0_7_CSCLKDEV_SHIFT15
+#define P0_7_CSCLKDEV_MASK 0x7
+#define P0_7_CPUEMA_SHIFT 28
+#define P0_7_CPUEMA_MASK 0xf
+#define P0_7_L2EMA_SHIFT 24
+#define P0_7_L2EMA_MASK0xf
+#define P0_7_VDD_SHIFT 8
+#define P0_7_VDD_MASK 0x7f
+#define P0_7_FREQ_SHIFT0
+#define P0_7_FREQ_MASK 0xff
+
+#define C0_3_PSTATE_VALID_SHIFT8
+#define C0_3_PSTATE_CURR_SHIFT 4
+#define C0_3_PSTATE_NEW_SHIFT 0
+
+#define PSTATE_CHANGED_EVTEN_SHIFT 0
+
+#define PSTATE_CHANGED_IRQEN_SHIFT 0
+
+#define PSTATE_CHANGED_SHIFT 0
+
+/*some constant values for clock divider calculation*/
+#define CPU_DIV_FREQ_MAX 500
+#define CPU_DBG_FREQ_MAX 375
+#define CPU_ATB_FREQ_MAX 500
+
+#define PMIC_LOW_VOLT 0x30
+#define PMIC_HIGH_VOLT 0x28
+
+#define CPUEMA_HIGH0x2
+#define CPUEMA_MID 0x4
+#define CPUEMA_LOW 0x7
+
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
Hi Rui,
Please merge this patch also. The 1st series of this patchset is
already accepted by you. This is just a adaptation of the earlier one
and does code cleanup.
Thanks,
Amit Daniel
On Sun, Feb 3, 2013 at 6:14 PM, Zhang Rui rui.zh...@intel.com wrote:
On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
This removes the driver specific sysfs support of the temperature
emulation and uses the newly added core thermal framework for thermal
emulation. A platform specific handler is added to support this.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
Changes in V2:
* Added config option CONFIG_THERMAL_EMULATION instead of
CONFIG_EXYNOS_THERMAL_EMUL
This patchset is based on thermal maintainer next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
Documentation/thermal/exynos_thermal_emulation |8 +-
drivers/thermal/Kconfig|9 --
drivers/thermal/exynos_thermal.c | 158
++--
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/Documentation/thermal/exynos_thermal_emulation
b/Documentation/thermal/exynos_thermal_emulation
index b73bbfb..36a3e79 100644
--- a/Documentation/thermal/exynos_thermal_emulation
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for TMU's
operation. User can set
manually with software code and TMU will read current temperature from user
value not from
sensor's value.
-Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
available.
-When it's enabled, sysfs node will be created under
-/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
+Enabling CONFIG_THERMAL_EMULATION option will make this support available.
+When it's enabled, sysfs node will be created as
+/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
-The sysfs node, 'emulation', will contain value 0 for the initial state.
When you input any
+The sysfs node, 'emul_node', will contain value 0 for the initial state.
When you input any
temperature you want to update to sysfs node, it automatically enable
emulation mode and
current temperature will be changed into it.
(Exynos also supports user changable delay time which would be used to
delay of
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e4cf7fb..2a79510 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -109,15 +109,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for TMU (Thermal Management
Unit) on SAMSUNG EXYNOS series of SoC.
-config EXYNOS_THERMAL_EMUL
- bool EXYNOS TMU emulation mode support
- depends on EXYNOS_THERMAL
- help
- Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
- Enable this option will be make sysfs node in exynos thermal platform
- device directory to support emulation mode. With emulation mode sysfs
- node, you can manually input temperature to TMU for simulation
purpose.
-
config DB8500_THERMAL
bool DB8500 thermal management
depends on ARCH_U8500
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 327102a..afe9c2a 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -99,13 +99,13 @@
#define IDLE_INTERVAL 1
#define MCELSIUS 1000
-#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+#ifdef CONFIG_THERMAL_EMULATION
#define EXYNOS_EMUL_TIME 0x57F0
#define EXYNOS_EMUL_TIME_SHIFT 16
#define EXYNOS_EMUL_DATA_SHIFT 8
#define EXYNOS_EMUL_DATA_MASK0xFF
#define EXYNOS_EMUL_ENABLE 0x1
-#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
+#endif /* CONFIG_THERMAL_EMULATION */
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -143,6 +143,7 @@ structthermal_cooling_conf {
struct thermal_sensor_conf {
char name[SENSOR_NAME_LEN];
int (*read_temperature)(void *data);
+ int (*write_emul_temp)(void *data, unsigned long temp);
struct thermal_trip_point_conf trip_data;
struct thermal_cooling_conf cooling_data;
void *private_data;
@@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device
*thermal,
return 0;
}
+/* Get temperature callback functions for thermal zone */
+static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
+ unsigned long temp)
+{
+ void *data;
+ int ret = -EINVAL;
+
+ if (!th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ return -EINVAL;
+ }
+ data = th_zone-sensor_conf-private_data;
+ if (th_zone-sensor_conf-write_emul_temp)
+ ret = th_zone-sensor_conf-write_emul_temp(data, temp);
+ return ret;
+}
+
/* Get
Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440
On Thu, Feb 7, 2013 at 6:42 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 8 February 2013 00:38, amit kachhap amit.kach...@gmail.com wrote:
Hi Viresh,
Thanks for the detailed review. Will try to handle them in the next version,
np. I haven't seen reply to few questions, you missed them or accept them.
Many of your comments were apt so I agreed to most of them :)
General tip: Leave a blank line before and after your comment, it makes it
more
readable. :)
On Thu, Feb 7, 2013 at 3:17 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- cpufreq_tbl: Table of frequencies and voltage CPU could be transitioned
into,
This has to be operating-points as in cpufreq-cpu0 driver.
Yes I will check if opp table is beneficial. In my case it is just one
time parsing of cpufreq table and those values(freq, volt) are not
used later so did not use opp libraries.
Its one time parsing for everybody, nobody do it twice :)
By every time I mean like using the opp table and getting voltage from
there and then doing set_voltage. For me if I use opp table it is just
once during initializations so i didn't use it.
+ for (old_index = 0;
+ freq_table[old_index].frequency != CPUFREQ_TABLE_END;
+ old_index++)
+ if (freq_table[old_index].frequency == freqs.old)
+ break;
+
+ if (freq_table[old_index].frequency == CPUFREQ_TABLE_END) {
How can this be true?
This is error scenario
We have given cpufreq core a valid table and it has to set frequency from
this table only. How can cpu have any other freq here ? And you have done
something similar in your init() too, where you check if cpu has freq from the
table or not.
Yes agreed this is repetition.
+ dvfs_info = kzalloc(sizeof(struct exynos_dvfs_data), GFP_KERNEL);
sizeof(*dvfs_info) ?? why don't make it static too, as you have other
stuff too.. ?
The better option for single image solution to allocate everything
dynamically, so that
unused drivers don't occupy any space.
?
+ if ((len == 0) || (len / 2 CPUFREQ_LEVEL_END)) {
I really didn't like this limit you have put at the number of dvfs
points. Better
would be to use:
+ dvfs_info-dvfs_init = true;
why do you need this ?
This is added to synchronize the interrupts.
How? You are setting it once in init() and not touching it afterwards. :)
Yes but during init also if interrupts starts arriving before complete
initialization so to protect that case it is there. I suppose there
are other ways. Will check them
Thanks,
Amit Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
On Thu, Feb 7, 2013 at 7:04 PM, Zhang Rui rui.zh...@intel.com wrote:
On Mon, 2013-02-04 at 10:14 +0800, Zhang Rui wrote:
On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
This removes the driver specific sysfs support of the temperature
emulation and uses the newly added core thermal framework for thermal
emulation. A platform specific handler is added to support this.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
Changes in V2:
* Added config option CONFIG_THERMAL_EMULATION instead of
CONFIG_EXYNOS_THERMAL_EMUL
This patchset is based on thermal maintainer next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
Documentation/thermal/exynos_thermal_emulation |8 +-
drivers/thermal/Kconfig|9 --
drivers/thermal/exynos_thermal.c | 158
++--
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/Documentation/thermal/exynos_thermal_emulation
b/Documentation/thermal/exynos_thermal_emulation
index b73bbfb..36a3e79 100644
--- a/Documentation/thermal/exynos_thermal_emulation
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for
TMU's operation. User can set
manually with software code and TMU will read current temperature from
user value not from
sensor's value.
-Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
available.
-When it's enabled, sysfs node will be created under
-/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
+Enabling CONFIG_THERMAL_EMULATION option will make this support available.
+When it's enabled, sysfs node will be created as
+/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
-The sysfs node, 'emulation', will contain value 0 for the initial state.
When you input any
+The sysfs node, 'emul_node', will contain value 0 for the initial state.
When you input any
temperature you want to update to sysfs node, it automatically enable
emulation mode and
current temperature will be changed into it.
(Exynos also supports user changable delay time which would be used to
delay of
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e4cf7fb..2a79510 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -109,15 +109,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for TMU (Thermal Management
Unit) on SAMSUNG EXYNOS series of SoC.
-config EXYNOS_THERMAL_EMUL
- bool EXYNOS TMU emulation mode support
- depends on EXYNOS_THERMAL
- help
- Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
- Enable this option will be make sysfs node in exynos thermal platform
- device directory to support emulation mode. With emulation mode sysfs
- node, you can manually input temperature to TMU for simulation
purpose.
-
config DB8500_THERMAL
bool DB8500 thermal management
depends on ARCH_U8500
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 327102a..afe9c2a 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -99,13 +99,13 @@
#define IDLE_INTERVAL 1
#define MCELSIUS 1000
-#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+#ifdef CONFIG_THERMAL_EMULATION
#define EXYNOS_EMUL_TIME 0x57F0
#define EXYNOS_EMUL_TIME_SHIFT 16
#define EXYNOS_EMUL_DATA_SHIFT 8
#define EXYNOS_EMUL_DATA_MASK 0xFF
#define EXYNOS_EMUL_ENABLE 0x1
-#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
+#endif /* CONFIG_THERMAL_EMULATION */
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -143,6 +143,7 @@ struct thermal_cooling_conf {
struct thermal_sensor_conf {
char name[SENSOR_NAME_LEN];
int (*read_temperature)(void *data);
+ int (*write_emul_temp)(void *data, unsigned long temp);
struct thermal_trip_point_conf trip_data;
struct thermal_cooling_conf cooling_data;
void *private_data;
@@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device
*thermal,
return 0;
}
+/* Get temperature callback functions for thermal zone */
+static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
+ unsigned long temp)
+{
+ void *data;
+ int ret = -EINVAL;
+
+ if (!th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ return -EINVAL;
+ }
+ data = th_zone-sensor_conf-private_data;
+ if (th_zone-sensor_conf-write_emul_temp)
+ ret = th_zone-sensor_conf-write_emul_temp(data, temp);
+ return ret;
+}
+
/* Get the temperature trend */
static int exynos_get_trend(struct thermal_zone_device
Re: [PATCH V2 1/2] thermal: sysfs: Add a new sysfs node emul_temp for thermal emulation
On Fri, Feb 1, 2013 at 12:27 AM, Zhang Rui rui.zh...@intel.com wrote:
On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
This patch adds support to set the emulated temperature method in
thermal zone (sensor). After setting this feature thermal zone may
report this temperature and not the actual temperature. The emulation
implementation may be based on sensor capability through platform
specific handler or pure software emulation if no platform handler defined.
This is useful in debugging different temperature threshold and its
associated cooling action. Critical threshold's cannot be emulated.
Writing 0 on this node should disable emulation.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
Changes in V2:
* Added config option for enabling emulation support.
* Added s/w emulation if no platform handler registered.
* skip the critical trip point emulation
This patchset is based on thermal maintainer next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
Documentation/thermal/sysfs-api.txt | 13 ++
drivers/thermal/Kconfig |8 +++
drivers/thermal/thermal_sys.c | 82
++-
include/linux/thermal.h |2 +
4 files changed, 94 insertions(+), 11 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index 526d4b9..6859661 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
.get_trip_type: get the type of certain trip point.
.get_trip_temp: get the temperature above which the certain trip point
will be fired.
+ .set_emul_temp: set the emulation temperature which helps in debugging
+ different threshold temperature points.
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
@@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's
registered:
|---trip_point_[0-*]_temp: Trip point temperature
|---trip_point_[0-*]_type: Trip point type
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
+|---emul_temp: Emulated temperature set node
Thermal cooling device sys I/F, created once it's registered:
/sys/class/thermal/cooling_device[0-*]:
@@ -252,6 +255,16 @@ passive
Valid values: 0 (disabled) or greater than 1000
RW, Optional
+emul_temp
+ Interface to set the emulated temperature method in thermal zone
+ (sensor). After setting this temperature, the thermal zone may pass
+ this temperature to platform emulation function if registered or
+ cache it locally. This is useful in debugging different temperature
+ threshold and its associated cooling action. This is write only node
+ and writing 0 on this node should disable emulation.
+ Unit: millidegree Celsius
+ WO, Optional
+
*
* Cooling device attributes *
*
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index faf38c5..e4cf7fb 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -78,6 +78,14 @@ config CPU_THERMAL
and not the ACPI interface.
If you want this support, you should say Y here.
+config THERMAL_EMULATION
+ bool Thermal emulation mode support
+ help
+ Enable this option to make a emul_temp sysfs node in thermal zone
+ directory to support temperature emulation. With emulation sysfs
node,
+ user can manually input temperature and test the different trip
+ threshold behaviour for simulation purpose.
+
config SPEAR_THERMAL
bool SPEAr thermal sensor driver
depends on PLAT_SPEAR
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 0a1bf6b..59ba709 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -378,24 +378,57 @@ static void handle_thermal_trip(struct
thermal_zone_device *tz, int trip)
monitor_thermal_zone(tz);
}
+static int thermal_zone_get_temp(struct thermal_zone_device *tz,
+ unsigned long *temp)
+{
+ int ret = 0, count;
+ unsigned long crit_temp = -1UL;
+ enum thermal_trip_type type;
+
+ mutex_lock(tz-lock);
+
+ if (tz-ops-get_temp)
+ ret = tz-ops-get_temp(tz, temp);
we do not need to do this check, .get_temp() should always be available.
#ifdef CONFIG_THERMAL_EMUL
+ else
+ ret = -EPERM;
+
+ if (!tz-emul_temperature)
+ goto skip_emul;
+
+ for (count = 0; count tz-trips; count++) {
+ ret = tz-ops-get_trip_type(tz, count, type);
+ if (!ret type == THERMAL_TRIP_CRITICAL) {
+ ret =
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
On Mon, Jan 21, 2013 at 7:20 PM, Zhang Rui rui.zh...@intel.com wrote: On Wed, 2013-01-16 at 11:30 -0800, amit kachhap wrote: Hi Rui, Thanks for the review comments, On Tue, Jan 15, 2013 at 11:33 PM, Zhang Rui rui.zh...@intel.com wrote: Hi, Amit, On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote: This patch adds support to set the emulated temperature method in thermal zone (sensor). After setting this feature thermal zone must report this temperature and not the actual temperature. The actual implementation of this emulated temperature is based on sensor capability or platform specific. This is useful in debugging different temperature threshold and its associated cooling action. Writing 0 on this node should disable emulation. Question: will this bring hardware issue? Say, critical temperature reached while in emulation mode? No emulation does cause any h/w issue. As this is for debug purpose, I'd prefer to have a seperate Kconfig option for this feature. Yes agreed. Will re-submit with kconfig option. Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/thermal/sysfs-api.txt | 14 ++ drivers/thermal/thermal_sys.c | 26 ++ include/linux/thermal.h |1 + 3 files changed, 41 insertions(+), 0 deletions(-) diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index 88c0233..e8f2ee4 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices. .get_trip_type: get the type of certain trip point. .get_trip_temp: get the temperature above which the certain trip point will be fired. + .set_emul_temp: set the emulation temperature which helps in debugging + different threshold temperature points. 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz) @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's registered: |---trip_point_[0-*]_temp: Trip point temperature |---trip_point_[0-*]_type: Trip point type |---trip_point_[0-*]_hyst: Hysteresis value for this trip point +|---emul_temp: Emulated temperature set node Thermal cooling device sys I/F, created once it's registered: /sys/class/thermal/cooling_device[0-*]: @@ -252,6 +255,17 @@ passive Valid values: 0 (disabled) or greater than 1000 RW, Optional +emul_temp + Interface to set the emulated temperature method in thermal zone + (sensor). After setting this feature thermal zone must report + this temperature and not the actual temperature. The actual + implementation of this emulated temperature is platform specific. can we have a pure software temperature emulation method? say, the generic thermal layer caches the emulated temperature value, and hook it in update_temperature()? This is also useful for testing in polling mode, and it does not require platform specific callback support. I mean thermal_ops-set_emul_temp is optional, but thermal emulation is always available for all platforms. Yes It makes sense and we can have pure software emulation and use the cached temperature when no platform call is registered. In my case I needed this in h/w so to have the same sensor trigger interrupts behaviour. So the code flow can be like this, #ifdef CONFIG_THERMAL_EMULATION if (thermal_ops-set_emul_temp) then pass emul_temp to platform and use the normal platform thermal_ops-get_temp else Store it locally and use emul_temp instead of calling platform thermal_ops-get_temp #endif No. We should not support emulation is CONFIG_THERMAL_EMULATION is cleared. And further more, for pure software emulation, we should check if the real temperature reaches critical trip point. Yes agreed. Submitted the V2 version with your suggestion. Thanks, Amit Daniel thanks, rui I will re-submit with this change. Thanks, Amit thanks, rui + This is useful in debugging different temperature threshold and its + associated cooling action. Writing 0 on this node should disable + emulation. + Unit: millidegree Celsius + WO, Optional + * * Cooling device attributes * * diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 8c8ce80..ecdfc7d 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -700,11 +700,31 @@ policy_show(struct device *dev, struct device_attribute *devattr, char *buf) return sprintf(buf, %s\n, tz-governor-name); } +static ssize_t +emul_temp_store(struct device *dev, struct device_attribute *attr, + const char *buf, size_t
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
Hi Rui,
Thanks for the review comments,
On Tue, Jan 15, 2013 at 11:33 PM, Zhang Rui rui.zh...@intel.com wrote:
Hi, Amit,
On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote:
This patch adds support to set the emulated temperature method in
thermal zone (sensor). After setting this feature thermal zone must
report this temperature and not the actual temperature. The actual
implementation of this emulated temperature is based on sensor
capability or platform specific. This is useful in debugging different
temperature threshold and its associated cooling action. Writing 0 on
this node should disable emulation.
Question:
will this bring hardware issue? Say, critical temperature reached while
in emulation mode?
No emulation does cause any h/w issue.
As this is for debug purpose, I'd prefer to have a seperate Kconfig
option for this feature.
Yes agreed. Will re-submit with kconfig option.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Documentation/thermal/sysfs-api.txt | 14 ++
drivers/thermal/thermal_sys.c | 26 ++
include/linux/thermal.h |1 +
3 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index 88c0233..e8f2ee4 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
.get_trip_type: get the type of certain trip point.
.get_trip_temp: get the temperature above which the certain trip point
will be fired.
+ .set_emul_temp: set the emulation temperature which helps in debugging
+ different threshold temperature points.
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
@@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's
registered:
|---trip_point_[0-*]_temp: Trip point temperature
|---trip_point_[0-*]_type: Trip point type
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
+|---emul_temp: Emulated temperature set node
Thermal cooling device sys I/F, created once it's registered:
/sys/class/thermal/cooling_device[0-*]:
@@ -252,6 +255,17 @@ passive
Valid values: 0 (disabled) or greater than 1000
RW, Optional
+emul_temp
+ Interface to set the emulated temperature method in thermal zone
+ (sensor). After setting this feature thermal zone must report
+ this temperature and not the actual temperature. The actual
+ implementation of this emulated temperature is platform specific.
can we have a pure software temperature emulation method?
say, the generic thermal layer caches the emulated temperature value,
and hook it in update_temperature()?
This is also useful for testing in polling mode, and it does not require
platform specific callback support. I mean thermal_ops-set_emul_temp is
optional, but thermal emulation is always available for all platforms.
Yes It makes sense and we can have pure software emulation and use the
cached temperature when no platform call is registered. In my case I
needed this in h/w so to have the same sensor trigger interrupts
behaviour.
So the code flow can be like this,
#ifdef CONFIG_THERMAL_EMULATION
if (thermal_ops-set_emul_temp)
then pass emul_temp to platform and use the normal platform
thermal_ops-get_temp
else
Store it locally and use emul_temp instead of calling platform
thermal_ops-get_temp
#endif
I will re-submit with this change.
Thanks,
Amit
thanks,
rui
+ This is useful in debugging different temperature threshold and its
+ associated cooling action. Writing 0 on this node should disable
+ emulation.
+ Unit: millidegree Celsius
+ WO, Optional
+
*
* Cooling device attributes *
*
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 8c8ce80..ecdfc7d 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -700,11 +700,31 @@ policy_show(struct device *dev, struct
device_attribute *devattr, char *buf)
return sprintf(buf, %s\n, tz-governor-name);
}
+static ssize_t
+emul_temp_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct thermal_zone_device *tz = to_thermal_zone(dev);
+ int ret;
+ unsigned long temperature;
+
+ if (!tz-ops-set_emul_temp)
+ return -EPERM;
+
+ if (kstrtoul(buf, 10, temperature))
+ return -EINVAL;
+
+ ret = tz-ops-set_emul_temp(tz, temperature);
+
+ return ret ? ret : count;
+}
+
static DEVICE_ATTR(type, 0444, type_show, NULL);
static DEVICE_ATTR(temp, 0444, temp_show, NULL);
static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
static
Re: [PATCH 2/5 RESEND] thermal: exynos: Miscellaneous fixes to support falling threshold interrupt
Hi Joe,
Thanks for the review. Will re-post with your suggestion,
On Sun, Jan 6, 2013 at 3:55 PM, Joe Perches j...@perches.com wrote:
On Sun, 2013-01-06 at 15:50 -0800, Amit Daniel Kachhap wrote:
Below fixes are done to support falling threshold interrupt,
* Falling interrupt status macro corrected according to exynos5 data sheet.
* The get trend function modified to calculate trip temperature correctly.
* The clearing of interrupt status in the isr is now done after handling
the event that caused the interrupt.
[]
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
[]
@@ -373,12 +373,19 @@ static int exynos_get_temp(struct thermal_zone_device
*thermal,
static int exynos_get_trend(struct thermal_zone_device *thermal,
int trip, enum thermal_trend *trend)
{
- if (thermal-temperature = trip)
+ int ret = 0;
Yes agreed. Will modify it.
Unnecessary initialization
+ unsigned long trip_temp;
+
+ ret = exynos_get_trip_temp(thermal, trip, trip_temp);
+ if (ret 0)
+ return ret;
+
+ if (thermal-temperature = trip_temp)
*trend = THERMAL_TREND_RAISING;
else
*trend = THERMAL_TREND_DROPPING;
THERMAL_TREND_STABLE ?
Only 2 trend is sufficient. It is stable for some time as the falling
threshold interrupt is some units below the trip temp.
- return 0;
+ return ret;
Ok agreed
return 0 is clearer.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH] cpufreq: exynos: Show list of available frequencies
On Tue, Jan 8, 2013 at 2:50 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
Add freq_attr attribute to show list of available frequencies.
Signed-off-by: Donggeun Kim dg77@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: KyungMin Park kyungmin.p...@samsung.com
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/cpufreq/exynos-cpufreq.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 7012ea8..bc1e833 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -244,13 +244,26 @@ static int exynos_cpufreq_cpu_init(struct
cpufreq_policy *policy)
return cpufreq_frequency_table_cpuinfo(policy,
exynos_info-freq_table);
}
+static int exynos_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+ cpufreq_frequency_table_put_attr(policy-cpu);
+ return 0;
+}
+
+static struct freq_attr *exynos_cpufreq_attr[] = {
+ cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
This change looks fine. I guess this was posted before also but could
not go mainline.
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
Thanks,
Amit Daniel
static struct cpufreq_driver exynos_driver = {
.flags = CPUFREQ_STICKY,
.verify = exynos_verify_speed,
.target = exynos_target,
.get= exynos_getspeed,
.init = exynos_cpufreq_cpu_init,
+ .exit = exynos_cpufreq_cpu_exit,
.name = exynos_cpufreq,
+ .attr = exynos_cpufreq_attr,
#ifdef CONFIG_PM
.suspend= exynos_cpufreq_suspend,
.resume = exynos_cpufreq_resume,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
Thanks,
Amit Daniel
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 13:42, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device
*tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
agree.
patches have been refreshed, please review.
Thanks Rui, Your patches looks nice. I will re-base my patches against
your implementation and submit them shortly.
Thanks,
Amit D
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-Resend] thermal: Exynos: Add missing dependency
On 15 November 2012 12:09, Sachin Kamat sachin.ka...@linaro.org wrote: CPU_FREQ_TABLE depends on CPU_FREQ. Selecting CPU_FREQ_TABLE without checking for dependencies gives the following compilation warnings: warning: (ARCH_TEGRA_2x_SOC ARCH_TEGRA_3x_SOC UX500_SOC_DB8500 CPU_THERMAL EXYNOS_THERMAL) selects CPU_FREQ_TABLE which has unmet direct dependencies (ARCH_HAS_CPUFREQ CPU_FREQ) Cc: Amit Daniel Kachhap amit.kach...@linaro.org Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/thermal/Kconfig |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 266c15e..6124c4b 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -50,8 +50,7 @@ config RCAR_THERMAL config EXYNOS_THERMAL tristate Temperature sensor on Samsung EXYNOS - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) THERMAL - select CPU_FREQ_TABLE Hi Sachin/Rui, select CPU_FREQ_TABLE should be there even if CONFIG_CPU_FREQ is enabled. Only some governors enable it. See drivers/cpufreq/Kconfig Also depends THERMAL should be there otherwise menuconfig parent/child relationship is broken. Thanks, Amit Daniel + depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) CPU_THERMAL help If you say yes here you get support for TMU (Thermal Managment Unit) on SAMSUNG EXYNOS series of SoC. -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-Resend] thermal: Exynos: Add missing dependency
On 15 November 2012 12:34, Zhang Rui rui.zh...@intel.com wrote: On Thu, 2012-11-15 at 12:31 +0530, Amit Kachhap wrote: On 15 November 2012 12:09, Sachin Kamat sachin.ka...@linaro.org wrote: CPU_FREQ_TABLE depends on CPU_FREQ. Selecting CPU_FREQ_TABLE without checking for dependencies gives the following compilation warnings: warning: (ARCH_TEGRA_2x_SOC ARCH_TEGRA_3x_SOC UX500_SOC_DB8500 CPU_THERMAL EXYNOS_THERMAL) selects CPU_FREQ_TABLE which has unmet direct dependencies (ARCH_HAS_CPUFREQ CPU_FREQ) Cc: Amit Daniel Kachhap amit.kach...@linaro.org Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/thermal/Kconfig |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 266c15e..6124c4b 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -50,8 +50,7 @@ config RCAR_THERMAL config EXYNOS_THERMAL tristate Temperature sensor on Samsung EXYNOS - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) THERMAL - select CPU_FREQ_TABLE Hi Sachin/Rui, select CPU_FREQ_TABLE should be there even if CONFIG_CPU_FREQ is enabled. Only some governors enable it. But CPU_THERMAL will select it, right? Ohh yes correct. Thanks See drivers/cpufreq/Kconfig Also depends THERMAL should be there otherwise menuconfig parent/child relationship is broken. this should be solved by my patch 1/2. :) thanks, rui Thanks, Amit Daniel + depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) CPU_THERMAL help If you say yes here you get support for TMU (Thermal Managment Unit) on SAMSUNG EXYNOS series of SoC. -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 9 November 2012 09:21, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
No actually I was thinking of having a simple governor with a feature
like it only sets to upper level and lower level. Also since the
temperature sensor is capable of interrupting for both increase in
threshold(say 100C) and fall in threshold (say 90C), so polling or
step increments is not needed at all.
Currently stepwise governor governor does that so we might change the
macro name as,
THERMAL_TREND_RAISE_STEP,
THERMAL_TREND_DROP_STEP,
THERMAL_TREND_RAISE_MAX,
THERMAL_TREND_DROP_MAX,
and file step_wise.c can be named as state_wise.c or trend_wise.c.
I am not sure if it is the best way . How do you feel ?
what do you think?
thanks,
rui
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device
*tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+ THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+ THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
};
/* Events supported by Thermal Netlink */
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH RESEND] thermal: add generic cpufreq cooling implementation
On Mon, Sep 10, 2012 at 3:25 PM, Zhang Rui rui.zh...@intel.com wrote: Refreshed to remove the notifier mechanism as we do not have a real user of it. if there is no problem, I'll apply the whole patch set to thermal next tree. The removal of notification API looks fine. Thanks for refreshing this. Thanks, Amit Daniel From: Amit Daniel Kachhap amit.kach...@linaro.org Date: Thu, 16 Aug 2012 17:11:40 +0530 This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Zhang Rui rui.zh...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/thermal/cpu-cooling-api.txt | 33 ++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 450 + include/linux/cpu_cooling.h | 58 5 files changed, 553 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..6fe9cdb --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,33 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple
Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
On 17 August 2012 12:54, Zhang Rui rui.zh...@intel.com wrote: On 四, 2012-08-16 at 17:11 +0530, Amit Daniel Kachhap wrote: This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/thermal/cpu-cooling-api.txt | 52 +++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 512 + include/linux/cpu_cooling.h | 79 + 5 files changed, 655 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..a1f2a6b --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,52 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + + clip_cpus: cpumask of cpus where the frequency constraints will happen. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface
Re: [RESEND PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
This is repost containing the changes suggested by Zhang Rui. Now the cpufreq current state will be calculated each time instead of earlier way of returning the cached value. Thanks, Amit Daniel On 17 August 2012 18:59, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) * Omap platforms in drivers/staging/omap-thermal/ There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale and omap platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- About this patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/thermal/cpu-cooling-api.txt | 52 +++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 586 + include/linux/cpu_cooling.h | 79 5 files changed, 729 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..a1f2a6b --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,52 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling
Re: [linux-pm] [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
On 16 August 2012 20:22, Valentin, Eduardo eduardo.valen...@ti.com wrote: Amit, Thanks again for keeping this up. On Thu, Aug 16, 2012 at 2:41 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) FYI, the OMAP code is under drivers/staging/omap-thermal/. The file omap-thermal-common.c is the one which is using your generic cooling device. But it needs to be updated accordingly to the API change you mention. There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com Thanks Eduardo . --- Documentation/thermal/cpu-cooling-api.txt | 52 +++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 512 + include/linux/cpu_cooling.h | 79 + 5 files changed, 655 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..a1f2a6b --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,52 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq
Re: [PATCH 0/2] ARM: exynos: Enable TMU support in exynos platforms
On Fri, Jul 13, 2012 at 4:58 PM, Kukjin Kim kgene@samsung.com wrote: Amit Daniel Kachhap wrote: These TMU enablement patches are needed for exynos4 and exynos5 TMU driver patches sent earlier. The link for those are http://www.spinics.net/lists/lm-sensors/msg35858.html. How was going on above patches? I can't see them you said in linux-next now, it means if I apply this series in my tree, problem will be happened :( Well, the above patches were accepted by Len for 3.5 merge but could not done because of some last minute pull issue. I hope it will go through in this merge window. I thought it is better to get the enablement patches also in mainline together. Note1: I've seen Rafael's updating exynos4_tmu patch which is using struct dev_pm_ops for pm and applied by Guenter. I have rebased the V5 with hwmon-next changes. So this change is already included. Note2: would be helpful if you could do adding me in Cc of exynos tmu patches... Yes sure. Also patch 1 depends on combiner dt node patch sent by Thomas Abraham. (http://www.spinics.net/lists/arm-kernel/msg184129.html) Already in my tree. This patchset is based Samsung Maintainer's tree, git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for- next OK. Amit Daniel Kachhap (2): ARM: exynos4: Add devicetree node for TMU driver ARM: exynos5: Add devicetree node for TMU driver arch/arm/boot/dts/exynos4210.dtsi|7 +++ arch/arm/boot/dts/exynos5250.dtsi|6 ++ arch/arm/mach-exynos/clock-exynos4.c |5 + arch/arm/mach-exynos/clock-exynos5.c |5 + arch/arm/mach-exynos/include/mach/irqs.h |3 +++ arch/arm/mach-exynos/include/mach/map.h |3 +++ arch/arm/mach-exynos/mach-exynos4-dt.c |2 ++ arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++ 8 files changed, 33 insertions(+), 0 deletions(-) Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: exynos: Enable TMU support in exynos platforms
On Fri, Jul 13, 2012 at 8:11 PM, Guenter Roeck li...@roeck-us.net wrote: On Fri, Jul 13, 2012 at 08:28:18PM +0900, Kukjin Kim wrote: Amit Daniel Kachhap wrote: These TMU enablement patches are needed for exynos4 and exynos5 TMU driver patches sent earlier. The link for those are http://www.spinics.net/lists/lm-sensors/msg35858.html. How was going on above patches? I can't see them you said in linux-next now, it means if I apply this series in my tree, problem will be happened :( Note1: I've seen Rafael's updating exynos4_tmu patch which is using struct dev_pm_ops for pm and applied by Guenter. If that is in the way, I can drop it, to be applied after the move. Let me know. There is now another patch pending, to convert the driver to use devm_ functions. Please let me know what you want me to do with it. Hi Guenter, I rebased my V5 patch series with hwmon-next branch so Rafael's pm changes are already included. Regarding the devm_ patch by sachin please hold it. Thanks, Amit D Note2: would be helpful if you could do adding me in Cc of exynos tmu patches... If you want to be copied, it might make sense to add yourself as maintainer for this file. Otherwise you can not expect people to know. Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RESEND PATCH v4 1/5] thermal: add generic cpufreq cooling implementation
On Thu, Jul 12, 2012 at 8:40 PM, Valentin, Eduardo eduardo.valen...@ti.com wrote: Amit, On Thu, Jul 12, 2012 at 4:41 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal) FYI, I have rewriten the OMAP BG driver and currently trying to push it to staging area. It should now support more omap versions. I will readapt the cpu cooling based on this patch. I am keeping the reworked driver here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/bandgap_staging Yes Eduardo, The link I have given here is slightly old. After your implementation is done maybe this link can be updated. Thanks, Amit D * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for OMAP and Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This codes is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) . But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct freq_clip_table *tab_ptr, unsigned int tab_size) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Donggeun Kim dg77@samsung.com Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping, cpuhotplug etc) provides +registration/unregistration APIs to the caller. The binding of the cooling +devices to the trip point is left for the user. The registration APIs returns +the cooling
Re: [linux-pm] [RESEND PATCH v4 1/5] thermal: add generic cpufreq cooling implementation
On Fri, Jul 13, 2012 at 4:34 AM, Andrew Morton a...@linux-foundation.org wrote: On Thu, 12 Jul 2012 19:11:04 +0530 Amit Daniel Kachhap amit.kach...@linaro.org wrote: [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Donggeun Kim dg77@samsung.com Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Signed-off-by: Andrew Morton a...@linux-foundation.org Something strange appears to have happened here? At a guess it seems that the patches were in my tree, I sent them to someone (Len?), then they were merged into linux-next by someone and then they fell out of linux-next again? If so, they will hopefully come back soon. If not, something failed fairly seriously. Hi Andrew, Yes you are right that this patches first came into your tree and then Len applied into his next tree for 3.5 merge. so they got into linux-next tree. After some last minute pull issues they could not be merged in 3.5 and Len dropped this series from his -next branch. I hope to get it accepted in 3.6 merge. I am aware that some work is going on for thermal framework improvement but that will have minimal changes on cpufreq cooling APIs and I hope to fix them as bug fix patches. I took a look at re-merging these patches into my tree, but there are significant conflicts with other work which has gone into linux-next. Its my fault that I didn't check the hwmon-next branch. I will repost them after merging with hwmon-next branch. Thanks, Amit Daniel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
On Fri, Jul 13, 2012 at 3:39 PM, Hongbo Zhang hongbo.zh...@linaro.org wrote: On 12 May 2012 17:40, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping, cpuhotplug etc) provides +registration/unregistration APIs to the caller. The binding of the cooling +devices to the trip point is left for the user. The registration APIs returns +the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_clip_table *tab_ptr, unsigned int tab_size) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + +tab_ptr: The table containing the maximum value of frequency to be clipped +for each cooling state. + .freq_clip_max: Value of frequency to be clipped for each allowed +cpus. + .temp_level: Temperature level at which the frequency clamping will + happen. + .mask_val: cpumask of the allowed cpu's +tab_size: the total number of cpufreq cooling states. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the thermal-cpufreq-%x cooling device. + +cdev: Cooling device pointer which has to be unregistered. + + +1.2 CPU cooling action notifier register/unregister interface +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP + +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 514a691..d9c529f 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -19,6 +19,17 @@ config THERMAL_HWMON depends on HWMON=y || HWMON=THERMAL default y +config CPU_THERMAL + bool generic cpu cooling support + depends on THERMAL CPU_FREQ + help + This implements the generic cpu cooling mechanism through frequency + reduction, cpu hotplug and any other ways of reducing temperature. An + ACPI version of this already exists(drivers/acpi/processor_thermal.c). + This will be useful for platforms using the generic thermal interface + and not the ACPI interface. + If you want this support, you should say Y or M here. No M value for bool item, should be N ? Yes I will include this change. + config SPEAR_THERMAL bool SPEAr thermal sensor driver depends on THERMAL diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index a9fff0b..30c456c 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,4 +3,5 @@ # obj-$(CONFIG_THERMAL) +=
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
On Tue, Jul 10, 2012 at 12:31 PM, Hongbo Zhang hongbo.zh...@linaro.org wrote: On 12 May 2012 17:40, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping, cpuhotplug etc) provides +registration/unregistration APIs to the caller. The binding of the cooling +devices to the trip point is left for the user. The registration APIs returns +the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_clip_table *tab_ptr, unsigned int tab_size) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + +tab_ptr: The table containing the maximum value of frequency to be clipped +for each cooling state. + .freq_clip_max: Value of frequency to be clipped for each allowed +cpus. + .temp_level: Temperature level at which the frequency clamping will + happen. + .mask_val: cpumask of the allowed cpu's +tab_size: the total number of cpufreq cooling states. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the thermal-cpufreq-%x cooling device. + +cdev: Cooling device pointer which has to be unregistered. + + +1.2 CPU cooling action notifier register/unregister interface +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP + +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 514a691..d9c529f 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -19,6 +19,17 @@ config THERMAL_HWMON depends on HWMON=y || HWMON=THERMAL default y +config CPU_THERMAL + bool generic cpu cooling support + depends on THERMAL CPU_FREQ + help + This implements the generic cpu cooling mechanism through frequency + reduction, cpu hotplug and any other ways of reducing temperature. An + ACPI version of this already exists(drivers/acpi/processor_thermal.c). + This will be useful for platforms using the generic thermal interface + and not the ACPI interface. + If you want this support, you should say Y or M here. + config SPEAR_THERMAL bool SPEAr thermal sensor driver depends on THERMAL diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index a9fff0b..30c456c 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,4 +3,5 @@ # obj-$(CONFIG_THERMAL) += thermal_sys.o -obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
Hi Rob/Eduardo, As these patches have still not made into mainline. I will rebase the whole set along with your suggestion and send them shortly. Sorry for late reply. Thanks, Amit Daniel On Tue, Jun 26, 2012 at 1:12 PM, Valentin, Eduardo eduardo.valen...@ti.com wrote: Hey Rob and Amit, On Tue, Jun 26, 2012 at 6:12 AM, Rob Lee rob@linaro.org wrote: Hey Amit, I was just re-organizing the imx thermal driver that uses this cpu cooling interface and noticed a couple of small issues here. If While rewriting the OMAP BG driver on top of this series I noticed similar issues. Apart from those pointed by Rob, I have another minor fix. these suggestions are agreed upon and if it's too late for these issues be changed with this patchset, I can submit them separately unless you'd prefer to. On Sat, May 12, 2012 at 4:40 AM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping, cpuhotplug etc) provides +registration/unregistration APIs to the caller. The binding of the cooling +devices to the trip point is left for the user. The registration APIs returns +the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_clip_table *tab_ptr, unsigned int tab_size) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + +tab_ptr: The table containing the maximum value of frequency to be clipped +for each cooling state. + .freq_clip_max: Value of frequency to be clipped for each allowed +cpus. + .temp_level: Temperature level at which the frequency clamping will + happen. + .mask_val: cpumask of the allowed cpu's +tab_size: the total number of cpufreq cooling states. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the thermal-cpufreq-%x cooling device. + +cdev: Cooling device pointer which has to be unregistered. + + +1.2 CPU cooling action notifier register/unregister interface +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP + +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 514a691..d9c529f 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -19,6 +19,17 @@ config THERMAL_HWMON depends on HWMON=y || HWMON=THERMAL default y +config CPU_THERMAL Perhaps the name CPU_COOLING or CPUFREQ_COOLING would more accurately describe this functionality? I like the latter since now this mechanism only supports
Re: [PATCH v3 2/6] thermal: Add generic cpufreq cooling implementation
On 9 May 2012 01:46, Andrew Morton a...@linux-foundation.org wrote:
On Tue, 8 May 2012 21:48:14 +0530
Amit Daniel Kachhap amit.kach...@linaro.org wrote:
This patch adds support for generic cpu thermal cooling low level
implementations using frequency scaling up/down based on the registration
parameters. Different cpu related cooling devices can be registered by the
user and the binding of these cooling devices to the corresponding
trip points can be easily done as the registration APIs return the
cooling device pointer. The user of these APIs are responsible for
passing clipping frequency . The drivers can also register to recieve
notification about any cooling action called. Even the driver can effect
the cooling action by modifying the default data such as freq_clip_max if
needed.
...
+struct cpufreq_cooling_device {
+ int id;
+ struct thermal_cooling_device *cool_dev;
+ struct freq_clip_table *tab_ptr;
+ unsigned int tab_size;
+ unsigned int cpufreq_state;
+ const struct cpumask *allowed_cpus;
+ struct list_head node;
+};
It would be nice to document the fields. Especially id, tab_size,
cpufreq_state and node. For `node' we should describe the locking for
the list, and describe which list_head anchors this list.
Thanks Andrew for the detailed review. I will add more documentation
and post the next version shortly.
+static LIST_HEAD(cooling_cpufreq_list);
+static DEFINE_MUTEX(cooling_cpufreq_lock);
+static DEFINE_IDR(cpufreq_idr);
+static DEFINE_PER_CPU(unsigned int, max_policy_freq);
+static struct freq_clip_table *notify_table;
+static int notify_state;
+static BLOCKING_NOTIFIER_HEAD(cputherm_state_notifier_list);
+
+static int get_idr(struct idr *idr, struct mutex *lock, int *id)
+{
+ int err;
+again:
+ if (unlikely(idr_pre_get(idr, GFP_KERNEL) == 0))
+ return -ENOMEM;
+
+ if (lock)
+ mutex_lock(lock);
The test for NULL `lock' is unneeded. In fact the `lock' argument
could be removed altogether - just use cooling_cpufreq_lock directly.
Agreed
+ err = idr_get_new(idr, NULL, id);
+ if (lock)
+ mutex_unlock(lock);
+ if (unlikely(err == -EAGAIN))
+ goto again;
+ else if (unlikely(err))
+ return err;
+
+ *id = *id MAX_ID_MASK;
+ return 0;
+}
+
+static void release_idr(struct idr *idr, struct mutex *lock, int id)
+{
+ if (lock)
+ mutex_lock(lock);
Ditto.
+ idr_remove(idr, id);
+ if (lock)
+ mutex_unlock(lock);
+}
+
...
+
+/*Below codes defines functions to be used for cpufreq as cooling device*/
+static bool is_cpufreq_valid(int cpu)
+{
+ struct cpufreq_policy policy;
+ return !cpufreq_get_policy(policy, cpu) ? true : false;
Can use
Ok
return !cpufreq_get_policy(policy, cpu);
+}
+
+static int cpufreq_apply_cooling(struct cpufreq_cooling_device
*cpufreq_device,
+ unsigned long cooling_state)
+{
+ unsigned int event, cpuid;
+ struct freq_clip_table *th_table;
+
+ if (cooling_state cpufreq_device-tab_size)
+ return -EINVAL;
+
+ cpufreq_device-cpufreq_state = cooling_state;
+
+ /*cpufreq thermal notifier uses this cpufreq device pointer*/
This code looks like it was written by two people.
/* One who does this */
/*And one who does this*/
The first one was right. Please go through all the comments in all the
patches and get the layout consistent?
Sure will add more details.
+ notify_state = cooling_state;
+
+ if (notify_state 0) {
+ th_table = (cpufreq_device-tab_ptr[cooling_state - 1]);
+ memcpy(notify_table, th_table, sizeof(struct freq_clip_table));
+ event = CPUFREQ_COOLING_TYPE;
+ blocking_notifier_call_chain(cputherm_state_notifier_list,
+ event, notify_table);
+ }
+
+ for_each_cpu(cpuid, cpufreq_device-allowed_cpus) {
+ if (is_cpufreq_valid(cpuid))
+ cpufreq_update_policy(cpuid);
+ }
+
+ notify_state = -1;
+
+ return 0;
+}
+
+static int cpufreq_thermal_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct cpufreq_policy *policy = data;
+ unsigned long max_freq = 0;
+
+ if ((event != CPUFREQ_ADJUST) || (notify_state == -1))
Please document `notify_state', at its definition site. This reader
doesn't know what notify_state == -1 *means*.
+ return 0;
+
+ if (notify_state 0) {
+ max_freq = notify_table-freq_clip_max;
+
+ if (per_cpu(max_policy_freq, policy-cpu) == 0)
+ per_cpu(max_policy_freq, policy-cpu) = policy-max;
+ } else {
+ if (per_cpu(max_policy_freq, policy-cpu) != 0) {
+
Re: [PATCH v3 5/6] thermal: exynos: Register the tmu sensor with the kernel thermal layer
On 9 May 2012 01:46, Andrew Morton a...@linux-foundation.org wrote:
On Tue, 8 May 2012 21:48:17 +0530
Amit Daniel Kachhap amit.kach...@linaro.org wrote:
This code added creates a link between temperature sensors, linux thermal
framework and cooling devices for samsung exynos platform. This layer
monitors the temperature from the sensor and informs the generic thermal
layer to take the necessary cooling action.
...
+static void exynos_report_trigger(void)
+{
+ unsigned int i;
+ char data[2];
+ char *envp[] = { data, NULL };
+
+ if (!th_zone || !th_zone-therm_dev)
+ return;
+
+ thermal_zone_device_update(th_zone-therm_dev);
+
+ mutex_lock(th_zone-therm_dev-lock);
+ /* Find the level for which trip happened */
+ for (i = 0; i th_zone-sensor_conf-trip_data.trip_count; i++) {
+ if (th_zone-therm_dev-last_temperature
+ th_zone-sensor_conf-trip_data.trip_val[i] * 1000)
+ break;
+ }
+
+ if (th_zone-mode == THERMAL_DEVICE_ENABLED) {
+ if (i 0)
+ th_zone-therm_dev-polling_delay = ACTIVE_INTERVAL;
+ else
+ th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
+ }
+
+ sprintf(data, %u, i);
yikes, if `i' exceeds 9, we have a stack scribble. Please review this
and at least use snprintf(... sizeof(data)) to prevent accidents.
Ok
+ kobject_uevent_env(th_zone-therm_dev-device.kobj, KOBJ_CHANGE,
envp);
+ mutex_unlock(th_zone-therm_dev-lock);
+}
+
...
+/* Get trip temperature callback functions for thermal zone */
+static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int
trip,
+ unsigned long *temp)
+{
+ if (trip 0 || trip 2)
I don't know what `trip' does and I don't know the meaning of the
values 0, 1 and 2. Documentation, please.
Agreed will put their description.
+ return -EINVAL;
+
+ *temp = th_zone-sensor_conf-trip_data.trip_val[trip];
+ /* convert the temperature into millicelsius */
+ *temp = *temp * 1000;
+
+ return 0;
+}
+
...
+/* Bind callback functions for thermal zone */
+static int exynos_bind(struct thermal_zone_device *thermal,
+ struct thermal_cooling_device *cdev)
+{
+ int ret = 0;
+
+ /* if the cooling device is the one from exynos4 bind it */
+ if (cdev != th_zone-cool_dev[0])
+ return 0;
+
+ if (thermal_zone_bind_cooling_device(thermal, 0, cdev)) {
+ pr_err(error binding cooling dev inst 0\n);
+ return -EINVAL;
+ }
+ if (thermal_zone_bind_cooling_device(thermal, 1, cdev)) {
+ pr_err(error binding cooling dev inst 1\n);
+ ret = -EINVAL;
+ goto error_bind1;
+ }
There can never be more than two instances?
As of now it is fixed as we register only 2 zones
+ return ret;
+error_bind1:
+ thermal_zone_unbind_cooling_device(thermal, 0, cdev);
+ return ret;
+}
+
...
+/* Get temperature callback functions for thermal zone */
+static int exynos_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+ void *data;
+
+ if (!th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ return -EINVAL;
+ }
+ data = th_zone-sensor_conf-private_data;
+ *temp = th_zone-sensor_conf-read_temperature(data);
+ /* convert the temperature into millicelsius */
+ *temp = *temp * 1000;
+ return 0;
+}
+
+/* Operation callback functions for thermal zone */
+static struct thermal_zone_device_ops exynos_dev_ops = {
Can it be const? That sometimes saves space, as the table doesn't need
to be moved into writeable storage at runtime.
Yes it can be made const
+ .bind = exynos_bind,
+ .unbind = exynos_unbind,
+ .get_temp = exynos_get_temp,
+ .get_mode = exynos_get_mode,
+ .set_mode = exynos_set_mode,
+ .get_trip_type = exynos_get_trip_type,
+ .get_trip_temp = exynos_get_trip_temp,
+ .get_crit_temp = exynos_get_crit_temp,
+};
+
+/* Register with the in-kernel thermal management */
+static int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf)
+{
+ int ret, count, tab_size;
+ struct freq_clip_table *tab_ptr;
+
+ if (!sensor_conf || !sensor_conf-read_temperature) {
+ pr_err(Temperature sensor not initialised\n);
+ return -EINVAL;
+ }
+
+ th_zone = kzalloc(sizeof(struct exynos_thermal_zone), GFP_KERNEL);
+ if (!th_zone) {
+ ret = -ENOMEM;
+ goto err_unregister;
This seems wrong? If we need to call exynos_unregister_thermal() on
this error path then we needed to call it on the predecing one?
Perhaps?
ok my fault.
+ }
+
+ th_zone-sensor_conf = sensor_conf;
+
+
Re: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 9 May 2012 01:36, Zhang, Rui rui.zh...@intel.com wrote:
Hi, Amit,
Sorry for the late response as I'm in a travel recently.
I think the generic cpufreq cooling patches are good.
But about the THERMAL_TRIP_STATE_INSTANCE patch, what I'd like to see is that
1. from thermal zone point of view, when the temperature is higher than a
trip point, either ACTIVE or PASSIVE, what we should do is to set device
cooling state to cur_state+1, right?
The only difference is that if we should take passive cooling actions or
active cooling actions based on the policy.
So my question would be if it is possible to combine these two kind of trip
points together. Maybe something like this:
In thermal_zone_device_update(),
...
case THERMAL_TRIP_PASSIVE:
if (passive cooling not allowed)
continue;
if (tc1)
thermal_zone_device_passive();
else
thermal_set_cooling_state();
break;
case THERMAL_TRIP_ACTIVE:
if (active cooling not allowed)
continue;
thermal_set_cooling_state();
break;
...
and thermal_set_cooling_state() {
list_for_each_entry(instance, tz-cooling_devices, node) {
if (instance-trip != count)
continue;
cdev = instance-cdev;
if (temp = trip_temp)
cdev-ops-set_cur_state(cdev, 1);
else
cdev-ops-set_cur_state(cdev, 0);
}
}
2. use only one cooling_device instance for a thermal_zone, and introduce
cdev-trips which shows the trip points this cooling device is bind to.
And we may use multiple cooling devices states for one active trip point.
Then, thermal_set_cooling_state() would be look like
list_for_each_entry(instance, tz-cooling_devices, node) {
cdev = instance-cdev;
/* check whether this cooling device is bind to the trip point */
if (!(cdev-trips 1count))
continue;
cdev-ops-get_max_state(cdev, max_state);
cdev-ops-get_cur_state(cdev, cur_state);
if (temp = trip_temp) {
if (cur_state++ = max_state))
cdev-ops-set_cur_state(cdev, cur_state);
} else if ((temp trip_temp) (cur_state-- = 0))
cdev-ops-set_cur_state(cdev, cur_state);
}
}
Hi Rui,
The above implementation also cools instance based cooling devices
like passive trip type. I need some changes on top of your
implementation such as,
thermal_set_cooling_state() {
list_for_each_entry(instance, tz-cooling_devices,
node) {
cdev = instance-cdev;
if (!cdev-trips 1count)
continue;
inst_id = 0;
for_each_bit_set(i, cdev-trips, count)
inst_id++;
cdev-ops-get_max_state(cdev, max_state);
if ((temp = trip_temp) (inst_id = max_state))
cdev-ops-set_cur_state(cdev, inst_id);
else if ((temp trip_temp) (--inst_id = 0))
cdev-ops-set_cur_state(cdev, inst_id);
}
}
I agree with you that the instance based trip types violates the
concept like reading the cur_state and do cur_state++/cur_state--
depending upon threshold increase or decrease because it needs the
state_id/inst_id.
I am actually thinking of dropping this new trip type and use the
existing THERMAL_TRIP_ACTIVE because there is so much logic in
calculating the state_id. The only flip side of using TRIP_ACTIVE is
that I need to create so many cooling devices.
Thanks,
Amit D
With these two things, I think the WARN_ZONE AND MONITOR_ZONE can be
registered as two PASSIVE trip points in the generic thermal layer, right?
Actually, this is one thing in my TODO list. And I'd glad to make it high
priority if this solves the problem you have.
Thanks,
rui
-Original Message-
From: linux-acpi-ow...@vger.kernel.org
[mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Amit Daniel Kachhap
Sent: Tuesday, May 08, 2012 9:18 AM
To: a...@linux-foundation.org; linux...@lists.linux-foundation.org
Cc: R, Durgadoss; linux-a...@vger.kernel.org; l...@kernel.org; Zhang, Rui;
amit.kach...@linaro.org; linaro-...@lists.linaro.org;
linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org; patc...@linaro.org
Subject: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for
exynos platform
Importance: High
Hi Andrew,
This patchset introduces a new generic cooling device based on cpufreq that
can be used on non-ACPI platforms. As a proof of concept, we have drivers for
the following platforms using this mechanism now:
* TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git
omap4460_thermal)
* Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
* Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git
imx6q_thermal)
These patches have been reviewed by Rui Zhang
(https://lkml.org/lkml/2012/4/9/448)
who seems to agree with them in principle, but I haven't had any luck getting
them merged, perhaps
Re: [PATCH] ARM: exynos: Adapt to cpuidle core time keeping and irq enable
Hi Mr Kukjin,
Any comment or update about this patch?
Regards,
Amit Daniel
On Mon, Apr 30, 2012 at 10:13 PM, Rob Lee rob@linaro.org wrote:
On Wed, Apr 25, 2012 at 9:44 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
On 04/25/2012 02:11 PM, Amit Daniel Kachhap wrote:
This patch enables core cpuidle timekeeping and irq enabling and
remove those redundant parts from the exynos cpuidle drivers
CC: Daniel Lezcanodaniel.lezc...@linaro.org
CC: Robert Leerob@linaro.org
Signed-off-by: Amit Danielamit.kach...@linaro.org
---
arch/arm/mach-exynos/cpuidle.c | 53
---
1 files changed, 6 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-exynos/cpuidle.c
b/arch/arm/mach-exynos/cpuidle.c
index 33ab4e7..26dac28 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -20,6 +20,7 @@
#includeasm/smp_scu.h
#includeasm/suspend.h
#includeasm/unified.h
+#includeasm/cpuidle.h
#includemach/regs-pmu.h
#includemach/pmu.h
@@ -34,22 +35,12 @@
#define S5P_CHECK_AFTR 0xFCBA0D10
-static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index);
static int exynos4_enter_lowpower(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
static struct cpuidle_state exynos4_cpuidle_set[] __initdata = {
- [0] = {
- .enter = exynos4_enter_idle,
- .exit_latency = 1,
- .target_residency = 10,
- .flags = CPUIDLE_FLAG_TIME_VALID,
- .name = C0,
- .desc = ARM clock gating(WFI),
- },
+ [0] = ARM_CPUIDLE_WFI_STATE,
[1] = {
.enter = exynos4_enter_lowpower,
.exit_latency = 300,
@@ -63,8 +54,9 @@ static struct cpuidle_state exynos4_cpuidle_set[]
__initdata = {
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
static struct cpuidle_driver exynos4_idle_driver = {
- .name = exynos4_idle,
- .owner = THIS_MODULE,
+ .name = exynos4_idle,
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
};
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
@@ -103,13 +95,8 @@ static int exynos4_enter_core0_aftr(struct
cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct timeval before, after;
- int idle_time;
unsigned long tmp;
- local_irq_disable();
- do_gettimeofday(before);
-
exynos4_set_wakeupmask();
/* Set value of power down register for aftr mode */
@@ -150,34 +137,6 @@ static int exynos4_enter_core0_aftr(struct
cpuidle_device *dev,
/* Clear wakeup state register */
__raw_writel(0x0, S5P_WAKEUP_STAT);
- do_gettimeofday(after);
-
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
- return index;
-}
-
-static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct timeval before, after;
- int idle_time;
-
- local_irq_disable();
- do_gettimeofday(before);
-
- cpu_do_idle();
-
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
return index;
}
@@ -192,7 +151,7 @@ static int exynos4_enter_lowpower(struct
cpuidle_device *dev,
new_index = drv-safe_state_index;
if (new_index == 0)
- return exynos4_enter_idle(dev, drv, new_index);
+ return arm_cpuidle_simple_enter(dev, drv, new_index);
else
return exynos4_enter_core0_aftr(dev, drv, new_index);
}
Acked-by: Robert Lee rob@linaro.org
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc in
the
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 16 April 2012 07:37, Zhang Rui rui.zh...@intel.com wrote:
On 三, 2012-04-11 at 18:17 +0530, Amit Kachhap wrote:
Hi Rui,
Thanks for looking into the patches.
On 10 April 2012 06:28, Zhang Rui rui.zh...@intel.com wrote:
Hi, Amit,
On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
Hi Len/Rui,
Any comment or feedback from your side about the status of this patch?
Is it merge-able or major re-work is needed? I have fixed most of the
comments in this patchset and currently working on some of the minor
comments received and will submit them shortly.
Sorry for the late response.
First of all, it makes sense to me to introduce the generic cpufrq
cooling implementation.
ok thanks
But I still have some questions.
I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
current passive handling in the generic thermal layer well, right?
e.g. there is no tc1/tc2 on exynos4.
If yes, is it possible that we can enhance the passive cooling to
support the generic processor cooling?
say, introduce another way to throttle the processor in
thermal_zone_device_passive when tc1 and tc2 are not available?
I agree that this new trip type code can be moved into passive trip
type when tc1 and tc2 are 0. but this is special type of cooling
devices behaviour where only instances of the same cooling device is
binded to a trip point. The order of mapping is the only
differentiating criteria and there are some checks used to implement
this like
1) The trip points should be in ascending order.(This is missing in my
original patch, so I added below)
2) The set_cur_state has to be called for the exact temp range so
get_cur_state(state) and set_cur_state(state ++/state--) logic is not
possible.
3) set_cur_state is called as set_cur_state(cdev_instance).
Do you really need two THERMAL_TRIP_STATE_INSTANCE trip points?
Sorry for late reply as I was off for vacation.
Yes we need 2 trip points of type THERMAL_TRIP_STATE_INSTANCE as we
need different cooling for these 2 zones. Anyways Do you feel that
these whole/partial patch series(cpufreq cooling api's, new trip type
etc) is ack-able or some modification is needed?
I'm not sure if my understanding is right, but IMO, we can have one
THERMAL_TRIP_STATE_INSTANCE only, for both MONIROR_ZONE and WARN_ZONE,
and the trip temperature equals MONIROR_ZONE.
The cpufreq cooling device will work in the same way, no?
thanks,
rui
There is a chance that people might confuse that these checks are
applicable for passive trip types also which is not the case here.
@@ -1187,6 +1228,21 @@ struct thermal_zone_device
*thermal_zone_device_register(char *type,
tz-ops-get_trip_type(tz, count, trip_type);
if (trip_type == THERMAL_TRIP_PASSIVE)
passive = 1;
+ /*
+ * For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
+ * be in ascending order.
+ */
+ if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
+ tz-ops-get_trip_temp(tz, count, trip_temp);
+ if (first_trip_temp == 0)
+ first_trip_temp = trip_temp;
+ else if (first_trip_temp trip_temp)
+ first_trip_temp = trip_temp;
+ else if (first_trip_temp trip_temp) {
+ pr_warn(Zone trip points should be in
ascending order\n);
+ goto unregister;
+ }
+ }
}
if (!passive)
Anyway there is other alternative where this new trip type is not
needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
I had thought to make this generic and just to manage with 1 cooling
device.
What is your view?
Thanks,
Amit Daniel
thanks,
rui
Regards,
Amit Daniel
On 19 March 2012 11:47, Amit Daniel Kachhap amit.kach...@linaro.org
wrote:
Changes since V1:
*Moved the sensor driver to driver/thermal folder from driver/hwmon
folder
as suggested by Mark Brown and Guenter Roeck
*Added notifier support to notify the registered drivers of any cpu
cooling
action. The driver can modify the default cooling behaviour(eg set
different
max clip frequency).
*The percentage based frequency replaced with absolute clipped
frequency.
*Some more conditional checks when setting max frequency.
*Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
THERMAL_TRIP_STATE_INSTANCE
*Many review comments from R, Durgadoss durgados...@intel.com and
eduardo.valen...@ti.com implemented.
*Removed cooling stats through debugfs patch
*The V1 based can be found here,
https://lkml.org/lkml
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
Hi Len/Rui, Any comment or feedback from your side about the status of this patch? Is it merge-able or major re-work is needed? I have fixed most of the comments in this patchset and currently working on some of the minor comments received and will submit them shortly. Regards, Amit Daniel On 19 March 2012 11:47, Amit Daniel Kachhap amit.kach...@linaro.org wrote: Changes since V1: *Moved the sensor driver to driver/thermal folder from driver/hwmon folder as suggested by Mark Brown and Guenter Roeck *Added notifier support to notify the registered drivers of any cpu cooling action. The driver can modify the default cooling behaviour(eg set different max clip frequency). *The percentage based frequency replaced with absolute clipped frequency. *Some more conditional checks when setting max frequency. *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to THERMAL_TRIP_STATE_INSTANCE *Many review comments from R, Durgadoss durgados...@intel.com and eduardo.valen...@ti.com implemented. *Removed cooling stats through debugfs patch *The V1 based can be found here, https://lkml.org/lkml/2012/2/22/123 http://lkml.org/lkml/2012/3/3/32 Changes since RFC: *Changed the cpu cooling registration/unregistration API's to instance based *Changed the STATE_ACTIVE trip type to pass correct instance id *Adding support to restore back the policy-max_freq after doing frequency clipping. *Moved the trip cooling stats from sysfs node to debugfs node as suggested by Greg KH g...@kroah.com *Incorporated several review comments from eduardo.valen...@ti.com *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd as discussed with Guenter Roeck guenter.ro...@ericsson.com and Donggeun Kim dg77@samsung.com (https://lkml.org/lkml/2012/1/5/7) *Some changes according to the changes in common cpu cooling APIs *The RFC based patches can be found here, https://lkml.org/lkml/2011/12/13/186 https://lkml.org/lkml/2011/12/21/169 Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This codes is architecture independent. 2) This patchset adds a new trip type THERMAL_TRIP_STATE_INSTANCE which passes cooling device instance number and may be helpful for cpufreq cooling devices to take the correct cooling action. This trip type avoids the temperature comparision check again inside the cooling handler. 3) This patchset adds generic cpu cooling low level implementation through frequency clipping and cpu hotplug. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c). But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a)struct thermal_cooling_device *cpufreq_cooling_register( struct freq_clip_table *tab_ptr, unsigned int tab_size, const struct cpumask *mask_val) b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 4) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. All this patchset is based on Kernel version 3.3-rc7 A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/ | Cpufreq cooling device --- Amit Daniel Kachhap (6): thermal: Add a new trip type to use cooling device instance number thermal: Add generic cpufreq cooling implementation thermal: Add generic cpuhotplug cooling implementation hwmon: exynos4: Move thermal sensor driver to driver/thermal directory thermal: exynos4: Register the tmu sensor with the kernel thermal layer ARM: exynos4: Add thermal sensor driver platform device support Documentation/hwmon/exynos4_tmu | 81 --- Documentation/thermal/cpu-cooling-api.txt | 76 +++ Documentation/thermal/exynos4_tmu | 52 ++ Documentation/thermal/sysfs-api.txt | 4 +- arch/arm/mach-exynos/Kconfig | 11 + arch/arm/mach-exynos/Makefile | 1 + arch/arm/mach-exynos/clock.c | 4 + arch/arm/mach-exynos/dev-tmu.c | 39 ++ arch/arm/mach-exynos/include/mach/irqs.h | 2 + arch/arm/mach-exynos/include/mach/map.h | 1 + arch/arm/mach-exynos/mach-origen.c | 1 + arch/arm/plat-samsung/include/plat/devs.h | 1 + drivers/hwmon/Kconfig | 10 -
Re: [PATCH V2 3/6] thermal: Add generic cpuhotplug cooling implementation
On 19 March 2012 17:15, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 03/19/2012 11:47 AM, Amit Daniel Kachhap wrote:
This patch adds support for generic cpu thermal cooling low level
implementations using cpuhotplug based on the thermal level requested
from user. Different cpu related cooling devices can be registered by the
user and the binding of these cooling devices to the corresponding
trip points can be easily done as the registration APIs return the
cooling device pointer. The user of these APIs are responsible for
passing the cpumask.
I am really not aware of the cpu thermal cooling stuff, but since this patch
deals with CPU Hotplug (which I am interested in), I have some questions
below..
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
+
+static int cpuhotplug_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ int ret = -EINVAL;
+ struct hotplug_cooling_device *hotplug_dev;
+
+ mutex_lock(cooling_cpuhotplug_lock);
+ list_for_each_entry(hotplug_dev, cooling_cpuhotplug_list, node) {
+ if (hotplug_dev hotplug_dev-cool_dev == cdev) {
+ *state = hotplug_dev-hotplug_state;
+ ret = 0;
+ break;
+ }
+ }
+ mutex_unlock(cooling_cpuhotplug_lock);
+ return ret;
+}
+
+/*This cooling may be as ACTIVE type*/
+static int cpuhotplug_set_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long state)
+{
+ int cpuid, this_cpu = smp_processor_id();
What prevents this task from being migrated to another CPU?
IOW, what ensures that 'this_cpu' remains valid throughout this function?
I see that you are acquiring mutex locks below.. So this is definitely not
a preempt disabled section.. so I guess my question above is valid..
Or is this code bound to a particular cpu?
No this thread is not bound to a cpu. Your comment is valid and some
synchronization is needed for preemption. Thanks for pointing this
out.
+ struct hotplug_cooling_device *hotplug_dev;
+
+ mutex_lock(cooling_cpuhotplug_lock);
+ list_for_each_entry(hotplug_dev, cooling_cpuhotplug_list, node)
+ if (hotplug_dev hotplug_dev-cool_dev == cdev)
+ break;
+
+ mutex_unlock(cooling_cpuhotplug_lock);
+ if (!hotplug_dev || hotplug_dev-cool_dev != cdev)
+ return -EINVAL;
+
+ if (hotplug_dev-hotplug_state == state)
+ return 0;
+
+ /*
+ * This cooling device may be of type ACTIVE, so state field can
+ * be 0 or 1
+ */
+ if (state == 1) {
+ for_each_cpu(cpuid, hotplug_dev-allowed_cpus) {
+ if (cpu_online(cpuid) (cpuid != this_cpu))
What prevents the cpu numbered cpuid from being taken down right at this
moment?
Don't you need explicit synchronization with CPU Hotplug using something like
get_online_cpus()/put_online_cpus() here?
+ cpu_down(cpuid);
+ }
+ } else if (state == 0) {
+ for_each_cpu(cpuid, hotplug_dev-allowed_cpus) {
+ if (!cpu_online(cpuid) (cpuid != this_cpu))
Same here.
+ cpu_up(cpuid);
+ }
+ } else {
+ return -EINVAL;
+ }
+
+ hotplug_dev-hotplug_state = state;
+
+ return 0;
+}
+/* bind hotplug callbacks to cpu hotplug cooling device */
+static struct thermal_cooling_device_ops cpuhotplug_cooling_ops = {
+ .get_max_state = cpuhotplug_get_max_state,
+ .get_cur_state = cpuhotplug_get_cur_state,
+ .set_cur_state = cpuhotplug_set_cur_state,
+};
+
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
Hi Durgadoss,
Thanks for the detailed review.
On 12 March 2012 16:21, R, Durgadoss durgados...@intel.com wrote:
Hi Amit,
Thanks for keeping this up. And Sorry for late reply.
-Original Message-
From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
Kachhap
Sent: Saturday, March 03, 2012 4:36 PM
To: linux...@lists.linux-foundation.org; linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
a...@vger.kernel.org; l...@kernel.org; linaro-...@lists.linaro.org; lm-
sens...@lm-sensors.org; amit.kach...@linaro.org; eduardo.valen...@ti.com; R,
Durgadoss; patc...@linaro.org
Subject: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux
thermal layer
This codes uses the generic linux thermal layer and creates a bridge
between temperature sensors, linux thermal framework and cooling devices
for samsung exynos platform. This layer recieves or monitor the
temperature from the sensor and informs the generic thermal layer to take
the necessary cooling action.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/Kconfig | 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/exynos_thermal.c | 272
++
include/linux/exynos_thermal.h | 72 ++
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/exynos_thermal.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 298c1cd..4e8df56 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,3 +29,11 @@ config CPU_THERMAL
This will be useful for platforms using the generic thermal interface
and not the ACPI interface.
If you want this support, you should say Y or M here.
+
+config SAMSUNG_THERMAL_INTERFACE
+ bool Samsung Thermal interface support
+ depends on THERMAL CPU_THERMAL
+ help
+ This is a samsung thermal interface which will be used as
+ a link between sensors and cooling devices with linux thermal
+ framework.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 655cbc4..c67b6b2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
+obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
new file mode 100644
index 000..878d45c
--- /dev/null
+++ b/drivers/thermal/exynos_thermal.c
@@ -0,0 +1,272 @@
+/* linux/drivers/thermal/exynos_thermal.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.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.
+*/
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+#include linux/platform_device.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/cpu_cooling.h
+#include linux/exynos_thermal.h
+
+#define MAX_COOLING_DEVICE 4
+struct exynos4_thermal_zone {
+ unsigned int idle_interval;
+ unsigned int active_interval;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos4_thermal_zone *th_zone;
+
+static int exynos4_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
+{
+ if (th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ *mode = THERMAL_DEVICE_DISABLED;
+ } else
+ *mode = THERMAL_DEVICE_ENABLED;
+ return 0;
+}
+
+static int exynos4_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay =
+ th_zone-active_interval*1000;
+ else
+ th_zone-therm_dev-polling_delay =
+ th_zone-idle_interval*1000;
If it is 'DISABLED' mode, shouldn't the polling delay be just 0 ?
Yes Ideally this should be zero. But I wanted thermal monitoring to
always happen with some long interval in case of error scenarios.
Anyway I will check this again.
+
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set
Re: [PATCH 2/4] hwmon: exynos4: Move thermal sensor driver to driver/mfd directory
On 3 March 2012 17:51, Sylwester Nawrocki snj...@gmail.com wrote: On 03/03/2012 12:06 PM, Amit Daniel Kachhap wrote: This movement is needed because the hwmon entries and corresponding sysfs interface is a duplicate of utilities already provided by driver/thermal/thermal_sys.c. The goal is to place it in mfd folder and add necessary calls to get the temperature information. Signed-off-by: Amit Daniel Kachhapamit.kach...@linaro.org Signed-off-by: Donggeun Kimdg77@samsung.com --- Documentation/hwmon/exynos4_tmu | 81 -- Documentation/mfd/exynos4_tmu | 81 ++ drivers/hwmon/Kconfig | 10 - drivers/hwmon/Makefile | 1 - drivers/hwmon/exynos4_tmu.c | 514 --- drivers/mfd/Kconfig | 10 + drivers/mfd/Makefile | 1 + drivers/mfd/exynos4_tmu.c | 514 +++ 8 files changed, 606 insertions(+), 606 deletions(-) delete mode 100644 Documentation/hwmon/exynos4_tmu create mode 100644 Documentation/mfd/exynos4_tmu delete mode 100644 drivers/hwmon/exynos4_tmu.c create mode 100644 drivers/mfd/exynos4_tmu.c Please consider adding -M option to git format-patch next time, which would make the patch smaller and would let to see clearly what's moved and what has changed. Sure , will keep it in mind. Thanks -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lm-sensors] [linux-pm] [PATCH 2/4] hwmon: exynos4: Move thermal sensor driver to driver/mfd directory
On 3 March 2012 23:34, Guenter Roeck guenter.ro...@ericsson.com wrote: On Sat, Mar 03, 2012 at 11:44:10AM -0500, Mark Brown wrote: On Sat, Mar 03, 2012 at 04:36:05PM +0530, Amit Daniel Kachhap wrote: This movement is needed because the hwmon entries and corresponding sysfs interface is a duplicate of utilities already provided by driver/thermal/thermal_sys.c. The goal is to place it in mfd folder and add necessary calls to get the temperature information. --- a/Documentation/hwmon/exynos4_tmu +++ /dev/null Moving this seems to be a failure, the device is exposing a hwmon interface even if you've moved the code to mfd (though it doesn't actually look like a multi-function device at all as far as I can see - usually a MFD would have a bunch of unrelated functionality while this has one function used by two subsystems). If anything it looks like the ADC driver ought to be moved into IIO with either generic or Exynos specific function drivers layered on top of it in hwmon and thermal making use of the values that are read. I would agree. Or maybe move it all to thermal, since thermal devices register the hwmon subsystem. Ok I agree with your suggestion of moving into thermal. Since I wanted to separate exynos specific generic thermal implementation with the H/W driver so that other versions of the sensor driver can easily hook into the common part. Anyway this implementation seems possible. Thanks for the comments Guenter -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 1/5] ARM: exynos: Add support AFTR mode on EXYNOS4210
On 23 February 2012 11:54, Rob Lee rob@linaro.org wrote:
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -27,9 +47,17 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
.exit_latency = 1,
.target_residency = 10,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .name = IDLE,
+ .name = C0,
.desc = ARM clock gating(WFI),
},
+ [1] = {
+ .enter = exynos4_enter_lowpower,
+ .exit_latency = 300,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C1,
+ .desc = ARM power down,
+ },
};
It looks like you could make this __initdata because your are copying
this state data over to the cpuidle_driver object during
initialization.
Hi Rob,
This is a good suggestion. I tested it and this works fine.
Hi Mr kim,
Can this change be accommodated in the current patch series as below
or should i send a new patchset?
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -41,7 +41,7 @@ static int exynos4_enter_lowpower(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
-static struct cpuidle_state exynos4_cpuidle_set[] = {
+static struct cpuidle_state exynos4_cpuidle_set[] __initdata = {
[0] = {
.enter = exynos4_enter_idle,
.exit_latency = 1,
Thanks,
Amit Daniel
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
@@ -39,9 +67,100 @@ static struct cpuidle_driver exynos4_idle_driver = {
.owner = THIS_MODULE,
};
+/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
+static void exynos4_set_wakeupmask(void)
+{
+ __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+}
+
+static unsigned int g_pwr_ctrl, g_diag_reg;
+
+static void save_cpu_arch_register(void)
+{
+ /*read power control register*/
+ asm(mrc p15, 0, %0, c15, c0, 0 : =r(g_pwr_ctrl) : : cc);
+ /*read diagnostic register*/
+ asm(mrc p15, 0, %0, c15, c0, 1 : =r(g_diag_reg) : : cc);
+ return;
+}
+
+static void restore_cpu_arch_register(void)
+{
+ /*write power control register*/
+ asm(mcr p15, 0, %0, c15, c0, 0 : : r(g_pwr_ctrl) : cc);
+ /*write diagnostic register*/
+ asm(mcr p15, 0, %0, c15, c0, 1 : : r(g_diag_reg) : cc);
+ return;
+}
+
+static int idle_finisher(unsigned long flags)
+{
+ cpu_do_idle();
+ return 1;
+}
+
+static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct timeval before, after;
+ int idle_time;
+ unsigned long tmp;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ exynos4_set_wakeupmask();
+
+ /* Set value of power down register for aftr mode */
+ exynos4_sys_powerdown_conf(SYS_AFTR);
+
+ __raw_writel(virt_to_phys(s3c_cpu_resume), REG_DIRECTGO_ADDR);
+ __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
+
+ save_cpu_arch_register();
+
+ /* Setting Central Sequence Register for power down mode */
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ tmp = ~S5P_CENTRAL_LOWPWR_CFG;
+ __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+
+ cpu_pm_enter();
+ cpu_suspend(0, idle_finisher);
+
+ scu_enable(S5P_VA_SCU);
+ cpu_pm_exit();
+
+ restore_cpu_arch_register();
+
+ /*
+ * If PMU failed while entering sleep mode, WFI will be
+ * ignored by PMU and then exiting cpu_do_idle().
+ * S5P_CENTRAL_LOWPWR_CFG bit will not be set automatically
+ * in this situation.
+ */
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ if (!(tmp S5P_CENTRAL_LOWPWR_CFG)) {
+ tmp |= S5P_CENTRAL_LOWPWR_CFG;
+ __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+ }
+
+ /* Clear wakeup state register */
+ __raw_writel(0x0, S5P_WAKEUP_STAT);
+
+ do_gettimeofday(after);
+
+ local_irq_enable();
+ idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
+ (after.tv_usec - before.tv_usec);
+
+ dev-last_residency = idle_time;
+ return index;
+}
+
static int exynos4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
- int index)
+ int index)
{
struct timeval before, after;
Re: [lm-sensors] [RFC PATCH 2/3] thermal: exynos4: Register the tmu sensor with the thermal interface layer
Hi Guenter,
The main idea of this work is to leave the current userspace based
notification scheme and add the kernel based cooling scheme on top of
it. Anyway, It is a good idea to move the file hwmon/exynos4_tmu.c as
this creates 2 hwmon entries.
Adding CC: Donggeun Kim to know his opinion.
Thanks,
Amit Daniel
On 4 January 2012 03:55, Guenter Roeck guenter.ro...@ericsson.com wrote:
On Wed, 2011-12-21 at 06:59 -0500, Amit Daniel Kachhap wrote:
Export and register information from the hwmon tmu sensor to the samsung
exynos kernel thermal framework where different cooling devices and thermal
zone are binded. The exported information is based according to the data
structure thermal_sensor_conf present in exynos_thermal.h. HWMON sysfs
functions are currently left although all of them are present in generic
linux thermal layer.
Also the platform data structure is modified to pass frequency cooling
in percentages for each thermal level.
Hi Amit,
wouldn't it make more sense to merge the code as necessary from
hwmon/exynos4_tmu.c into the new thermal/exynos_thermal.c, and drop
hwmon/exynos4_tmu.c entirely ?
With that, you should get the hwmon entries for free, and we would not
have to maintain two drivers with overlapping functionality.
Thanks,
Guenter
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/hwmon/exynos4_tmu.c | 34
++--
include/linux/platform_data/exynos4_tmu.h | 7 ++
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
index f2359a0..6912a7f 100644
--- a/drivers/hwmon/exynos4_tmu.c
+++ b/drivers/hwmon/exynos4_tmu.c
@@ -37,6 +37,9 @@
#include linux/hwmon-sysfs.h
#include linux/platform_data/exynos4_tmu.h
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+#include linux/exynos_thermal.h
+#endif
#define EXYNOS4_TMU_REG_TRIMINFO 0x0
#define EXYNOS4_TMU_REG_CONTROL 0x20
@@ -248,10 +251,13 @@ static void exynos4_tmu_work(struct work_struct *work)
kobject_uevent(data-hwmon_dev-kobj, KOBJ_CHANGE);
- enable_irq(data-irq);
clk_disable(data-clk);
mutex_unlock(data-lock);
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+ exynos4_report_trigger();
+#endif
+ enable_irq(data-irq);
}
static irqreturn_t exynos4_tmu_irq(int irq, void *id)
@@ -345,6 +351,14 @@ static const struct attribute_group
exynos4_tmu_attr_group = {
.attrs = exynos4_tmu_attributes,
};
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+static struct thermal_sensor_conf exynos4_sensor_conf = {
+ .name = exynos4-therm,
+ .read_temperature = (int (*)(void *))exynos4_tmu_read,
+};
+#endif
+/*CONFIG_SAMSUNG_THERMAL_INTERFACE*/
+
static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
{
struct exynos4_tmu_data *data;
@@ -432,9 +446,20 @@ static int __devinit exynos4_tmu_probe(struct
platform_device *pdev)
}
exynos4_tmu_control(pdev, true);
-
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+ (exynos4_sensor_conf)-private_data = data;
+ (exynos4_sensor_conf)-sensor_data = pdata;
+ ret = exynos4_register_thermal(exynos4_sensor_conf);
+ if (ret) {
+ dev_err(pdev-dev, Failed to register thermal interface\n);
+ goto err_hwmon_device;
+ }
+#endif
return 0;
-
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+err_hwmon_device:
+ hwmon_device_unregister(data-hwmon_dev);
+#endif
err_create_group:
sysfs_remove_group(pdev-dev.kobj, exynos4_tmu_attr_group);
err_clk:
@@ -458,6 +483,9 @@ static int __devexit exynos4_tmu_remove(struct
platform_device *pdev)
exynos4_tmu_control(pdev, false);
+#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
+ exynos4_unregister_thermal();
+#endif
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(pdev-dev.kobj, exynos4_tmu_attr_group);
diff --git a/include/linux/platform_data/exynos4_tmu.h
b/include/linux/platform_data/exynos4_tmu.h
index 39e038c..642c508 100644
--- a/include/linux/platform_data/exynos4_tmu.h
+++ b/include/linux/platform_data/exynos4_tmu.h
@@ -21,6 +21,7 @@
#ifndef _LINUX_EXYNOS4_TMU_H
#define _LINUX_EXYNOS4_TMU_H
+#include linux/cpu_cooling.h
enum calibration_type {
TYPE_ONE_POINT_TRIMMING,
@@ -64,6 +65,9 @@ enum calibration_type {
* in the positive-TC generator block
* 0 = reference_voltage = 31
* @cal_type: calibration type for temperature
+ * @freq_pctg_table: Table representing frequency reduction percentage.
+ * @freq_tab_count: Count of the above table as frequency reduction may
+ * applicable to only some of the trigger levels.
*
* This structure is required for configuration of exynos4_tmu driver.
*/
@@ -79,5 +83,8 @@ struct exynos4_tmu_platform_data {
u8 reference_voltage;
enum calibration_type cal_type;
+
+ struct
Re: [PATCH V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
On 3 January 2012 18:52, Kukjin Kim kgene@samsung.com wrote: amit kachhap wrote: Hi Mr kim, All the comments have been addressed for the Exynos cpu idle patchset. The updated patchset was posted about one month back and there have been no further comments on the patchset since then. As this patchset seems to be stable now, do you think these these patches can merged in this 3.3 merge window? Kindly let me know your opinion. This conflicts with local common.[ch] working for ARM restart. Please wait until after the merge window for this patches. Thanks for the update. Actually I have fixed the merging issue in common.[ch] files so sending the V5 series of the patchset shortly. If possible add in this merge window or next merge window is also fine. Regards, Amit daniel Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 5/5] ARM: exynos: Enable l2 configuration through device tree
On 5 January 2012 10:06, Olof Johansson o...@lixom.net wrote:
On Wed, Jan 4, 2012 at 8:25 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
This patch enables calling generic l2 setup functions if device tree is used.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos/common.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index f8bb808..e91b92d 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -47,6 +47,8 @@
#include plat/regs-serial.h
#include common.h
+#define L2_AUX_VAL 0x7C470001
+#define L2_AUX_MASK 0xC200
static const char name_exynos4210[] = EXYNOS4210;
static const char name_exynos4212[] = EXYNOS4212;
@@ -453,6 +455,15 @@ core_initcall(exynos4_core_init);
#ifdef CONFIG_CACHE_L2X0
static int __init exynos4_l2x0_cache_init(void)
{
+#ifdef CONFIG_OF
+ int ret;
+ ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
+ if (!ret) {
+ l2x0_regs_phys = virt_to_phys(l2x0_saved_regs);
+ clean_dcache_area(l2x0_regs_phys, sizeof(unsigned long));
+ return 0;
+ }
+#endif
No need for ifdef here, if CONFIG_OF is off, then there's a static
inline version of l2x_of_init() that will return -ENODEV.
Will accept your suggestion. Thanks
-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos4: Fix for stall in case of cpu hotplug or sleep
On Thu, Dec 1, 2011 at 4:05 PM, Kukjin Kim kgene@samsung.com wrote:
Amit Daniel Kachhap wrote:
This patch adds remove_irq in place of disable_irq which is
correct equivalent function for setup_irq used in
exynos4_mct_tick_init.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Tested-by: Inderpal Singh inderpal.si...@linaro.org
---
arch/arm/mach-exynos/mct.c | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index 97343df..959f251 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -428,9 +428,13 @@ int __cpuinit local_timer_setup(struct
clock_event_device *evt)
void local_timer_stop(struct clock_event_device *evt)
{
+ unsigned int cpu = smp_processor_id();
evt-set_mode(CLOCK_EVT_MODE_UNUSED, evt);
if (mct_int_type == MCT_INT_SPI)
- disable_irq(evt-irq);
+ if (cpu == 0)
+ remove_irq(evt-irq, mct_tick0_event_irq);
+ else
+ remove_irq(evt-irq, mct_tick1_event_irq);
Hmm, how about the cpu number is 2 or 3 on Quad-core?
As you know, this should be used for all of EXYNOS SoCs.
This code change is specific for EXYNOS4210 where the MCT irq is SPI
type. Other exynos soc's (4412 etc) are not effected by this change.
I am adding the cpu stall log currently caused during cpu1 hotplug or
sleep/wakeup sequence. This commit fixes this.
root@localhost:~# echo 1 /sys/devices/system/cpu/cpu1/online
CPU1: Booted secondary processor
Calibrating delay loop (skipped) already calibrated this CPU
CPU1: Unknown IPI message 0x1
INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0,
t=12002 jiffies)
[c0015980] (unwind_backtrace+0x0/0xfc) from [c0075124]
(__rcu_pending+0x45c/0x4d8)
[c0075124] (__rcu_pending+0x45c/0x4d8) from [c0075250]
(rcu_check_callbacks+0xb0/0x210)
[c0075250] (rcu_check_callbacks+0xb0/0x210) from [c003f62c]
(update_process_times+0x3c/0x50)
[c003f62c] (update_process_times+0x3c/0x50) from [c005ee50]
(tick_sched_timer+0x94/0xd0)
[c005ee50] (tick_sched_timer+0x94/0xd0) from [c00527ac]
(__run_hrtimer+0x44/0xd8)
[c00527ac] (__run_hrtimer+0x44/0xd8) from [c0052af0]
(hrtimer_interrupt+0x100/0x330)
[c0052af0] (hrtimer_interrupt+0x100/0x330) from [c001f080]
(exynos4_mct_tick_isr+0x50/0x68)
[c001f080] (exynos4_mct_tick_isr+0x50/0x68) from [c006d438]
(handle_irq_event_percpu+0x54/0x180)
[c006d438] (handle_irq_event_percpu+0x54/0x180) from [c006d5a0]
(handle_irq_event+0x3c/0x5c)
[c006d5a0] (handle_irq_event+0x3c/0x5c) from [c00701a8]
(handle_fasteoi_irq+0x9c/0x104)
[c00701a8] (handle_fasteoi_irq+0x9c/0x104) from [c006cf0c]
(generic_handle_irq+0x34/0x3c)
[c006cf0c] (generic_handle_irq+0x34/0x3c) from [c000fde8]
(handle_IRQ+0x58/0xb8)
[c000fde8] (handle_IRQ+0x58/0xb8) from [c000e8ec] (__irq_svc+0x6c/0xe8)
[c000e8ec] (__irq_svc+0x6c/0xe8) from [c001edbc]
(exynos4_enter_idle+0x2c/0x60)
[c001edbc] (exynos4_enter_idle+0x2c/0x60) from [c01cfa7c]
(cpuidle_idle_call+0xb8/0x12c)
[c01cfa7c] (cpuidle_idle_call+0xb8/0x12c) from [c0010744]
(cpu_idle+0xac/0xf4)
[c0010744] (cpu_idle+0xac/0xf4) from [c02908f8] (start_kernel+0x36c/0x378)
INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0,
t=12002 jiffies)
[c0015980] (unwind_backtrace+0x0/0xfc) from [c0075124]
(__rcu_pending+0x45c/0x4d8)
[c0075124] (__rcu_pending+0x45c/0x4d8) from [c00752ec]
(rcu_check_callbacks+0x14c/0x210)
[c00752ec] (rcu_check_callbacks+0x14c/0x210) from [c003f62c]
(update_process_times+0x3c/0x50)
[c003f62c] (update_process_times+0x3c/0x50) from [c005ee50]
(tick_sched_timer+0x94/0xd0)
[c005ee50] (tick_sched_timer+0x94/0xd0) from [c00527ac]
(__run_hrtimer+0x44/0xd8)
[c00527ac] (__run_hrtimer+0x44/0xd8) from [c0052af0]
(hrtimer_interrupt+0x100/0x330)
[c0052af0] (hrtimer_interrupt+0x100/0x330) from [c001f080]
(exynos4_mct_tick_isr+0x50/0x68)
[c001f080] (exynos4_mct_tick_isr+0x50/0x68) from [c006d438]
(handle_irq_event_percpu+0x54/0x180)
[c006d438] (handle_irq_event_percpu+0x54/0x180) from [c006d5a0]
(handle_irq_event+0x3c/0x5c)
[c006d5a0] (handle_irq_event+0x3c/0x5c) from [c00701a8]
(handle_fasteoi_irq+0x9c/0x104)
[c00701a8] (handle_fasteoi_irq+0x9c/0x104) from [c006cf0c]
(generic_handle_irq+0x34/0x3c)
[c006cf0c] (generic_handle_irq+0x34/0x3c) from [c000fde8]
(handle_IRQ+0x58/0xb8)
[c000fde8] (handle_IRQ+0x58/0xb8) from [c000e8ec] (__irq_svc+0x6c/0xe8)
[c000e8ec] (__irq_svc+0x6c/0xe8) from [c001edbc]
(exynos4_enter_idle+0x2c/0x60)
[c001edbc] (exynos4_enter_idle+0x2c/0x60) from [c01cfa7c]
(cpuidle_idle_call+0xb8/0x12c)
[c01cfa7c] (cpuidle_idle_call+0xb8/0x12c) from [c0010744]
(cpu_idle+0xac/0xf4)
[c0010744] (cpu_idle+0xac/0xf4) from [c02908f8] (start_kernel+0x36c/0x378)
Thanks,
Amit Daniel
else
disable_percpu_irq(IRQ_MCT_LOCALTIMER);
}
--
1.7.1
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung
Re: [PATCH V3 1/6] ARM: exynos: Add AFTR mode cpuidle state on EXYNOS4210
On Thu, Nov 24, 2011 at 9:37 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
Hi Amit,
On 22 November 2011 15:05, Amit Daniel Kachhap amit.kach...@linaro.org
wrote:
This patch adds support AFTR(ARM OFF TOP RUNNING) mode in
cpuidle driver. L2 cache keeps their data in this mode.
This patch ports the code to the latest interfaces to
save/restore CPU state inclusive of CPU PM notifiers, l2
resume and cpu_suspend/resume.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos/cpuidle.c | 152
++-
arch/arm/mach-exynos/include/mach/pmu.h | 2 +
2 files changed, 151 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 21403c8..89afa93 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -12,15 +12,37 @@
#include linux/module.h
#include linux/init.h
#include linux/cpuidle.h
+#include linux/cpu_pm.h
#include linux/io.h
#include linux/export.h
#include linux/time.h
#include asm/proc-fns.h
+#include asm/smp_scu.h
+#include asm/suspend.h
+#include asm/unified.h
+#include mach/regs-pmu.h
+#include mach/pmu.h
+
+#include plat/exynos4.h
+#include plat/cpu.h
+
+#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ?
\
+ (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
+#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0 ?
\
+ (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
+
+#define S5P_CHECK_AFTR (samsung_rev() == EXYNOS4210_REV_1_0 ? \
+ 0xBAD0 : 0xFCBA0D10)
static int exynos4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
+static int exynos4_enter_lowpower(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index);
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -28,9 +50,17 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
.exit_latency = 1,
.target_residency = 10,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .name = IDLE,
+ .name = C0,
.desc = ARM clock gating(WFI),
},
+ [1] = {
+ .enter = exynos4_enter_lowpower,
+ .exit_latency = 300,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C1,
+ .desc = ARM power down,
+ },
};
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
@@ -40,9 +70,101 @@ static struct cpuidle_driver exynos4_idle_driver = {
.owner = THIS_MODULE,
};
+/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
+static void exynos4_set_wakeupmask(void)
+{
+ __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+}
+
+static unsigned int g_pwr_ctrl, g_diag_reg;
+
+static void save_cpu_arch_register(void)
+{
+ /*read power control register*/
+ asm(mrc p15, 0, %0, c15, c0, 0 : =r(g_pwr_ctrl) : : cc);
+ /*read diagnostic register*/
+ asm(mrc p15, 0, %0, c15, c0, 1 : =r(g_diag_reg) : : cc);
+ return;
+}
+
+static void restore_cpu_arch_register(void)
+{
+ /*write power control register*/
+ asm(mcr p15, 0, %0, c15, c0, 0 : : r(g_pwr_ctrl) : cc);
+ /*write diagnostic register*/
+ asm(mcr p15, 0, %0, c15, c0, 1 : : r(g_diag_reg) : cc);
+ return;
+}
+
+static int idle_finisher(unsigned long flags)
+{
+ cpu_do_idle();
+ return 1;
+}
+
+static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct timeval before, after;
+ int idle_time;
+ unsigned long tmp;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ exynos4_set_wakeupmask();
+
+ /* Set value of power down register for aftr mode */
+ exynos4_sys_powerdown_conf(SYS_AFTR);
+
+ __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)),
+ REG_DIRECTGO_ADDR);
+ __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
+
+ save_cpu_arch_register();
+
+ /* Setting Central Sequence Register for power down mode */
+
Re: [PATCH V3 0/6] ARM: exynos: Add l2 retention mode cpuidle state
Dear Kukjin Kim, Any comments or feedback on this patchset from your side. I am preparing another version with fixes/issues suggested by Russell and Inder. Thanks, Amit Daniel On Tue, Nov 22, 2011 at 3:05 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: Changes since V2: *Implemented the suggestion of MyungJoo Ham and used INFORM0/1 registers for resume for some board versions. *Added back save/restore through CPU PM notifiers as suggested by Lorenzo Pieralisi. This is useful to restore vfp state. *some patch modularization (s5p/exynos) and proper commit logs. Changes since V1: *rebased the whole patch against 3.2-rc1 tree *removed GIC save/restore in AFTR cpuidle state as it is external to cpu powerdomain *Added L2 setup code through device tree *Removed only l2 save/restore registers in sleep This Patch series adds support for AFTR mode cpuidle state based on patch (http://www.spinics.net/lists/arm-kernel/msg132243.html) earlier submitted by Jaecheol Lee jc@samsung.com. This patch uses CPU PM notifiers , common l2 save/restore and new cpu_suspend/resume interfaces and is based on the tip of for-next branch of samsung tree. (git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next). Amit Daniel Kachhap (6): ARM: exynos: Add support AFTR mode on EXYNOS4210 ARM: s5p: remove useless churn in sleep.S ARM: exynos: save L2 settings during bootup ARM: s5p: add L2 early resume code ARM: exynos: remove useless code to save/restore L2 ARM: exynos: Enable l2 configuration through device tree arch/arm/mach-exynos/cpu.c | 60 +--- arch/arm/mach-exynos/cpuidle.c | 152 ++- arch/arm/mach-exynos/include/mach/pmu.h | 2 + arch/arm/mach-exynos/pm.c | 15 --- arch/arm/plat-s5p/sleep.S | 32 ++- 5 files changed, 226 insertions(+), 35 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/6] ARM: s5p: remove useless churn in sleep.S
On Tue, Nov 22, 2011 at 3:18 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Nov 22, 2011 at 03:05:28PM +0530, Amit Daniel Kachhap wrote: This patch cleans up sleep code in preparation for L2 resume code and hotplug functions I wonder whether anyone read the comments in this file before they changed the section for the code. /* * sleep magic, to allow the bootloader to check for an valid * image to resume to. Must be the first word before the * s3c_cpu_resume entry. */ Ok,This looks like an error. Thanks for pointing this out. Will put the entire section into data. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/6] ARM: exynos: save L2 settings during bootup
On Tue, Nov 22, 2011 at 3:19 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Nov 22, 2011 at 03:05:29PM +0530, Amit Daniel Kachhap wrote: This patch adds code to save L2 register configuration at boot, and later used to resume L2 before MMU is enabled in suspend and cpuidle resume paths. Is there a reason exynos isn't using the generic l2 code? Actually the generic l2 save/resume works fine for full l2 shutdown but in case of l2 retention mode few registers need to be re-initialised which is not handled in the generic code.(implemented in file arch/arm/plat-s5p/sleep.S) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state
On 11 November 2011 13:03, MyungJoo Ham myungjoo@gmail.com wrote: On Sat, Nov 5, 2011 at 2:03 AM, amit.kach...@linaro.org wrote: From: Amit Daniel Kachhap amit.kach...@linaro.org This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode. This patch ports the code to the latest interfaces to save/restore CPU state inclusive of CPU PM notifiers, l2 resume and cpu_suspend/resume. Signed-off-by: Jaecheol Lee jc@samsung.com Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- [] +#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \ + S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24)) +#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \ + S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20)) [] + + __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)), + REG_DIRECTGO_ADDR); + __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG); + return 0; Hello, Why are you using INFORM6 and 7 registers in order to save resume address and power-mode flags? INFORM0 and 1 have been used in pm.c for the exactly same purpose. Please use the same registers in cpuidle.c as well. The same part in bootloader (IPL) can handle whether it's suspend-to-RAM or AFTR and the both modes are mutually exclusive and you only need one value for resume PC. Therefore, you can keep the value at the same location, which is the method we have been using. Hi, I tried using INFORM0 and INFORM1 in cpuidle and make it same as pm.c. But this doesnt work. Looks like my irom fused code checks for the wakeup source and needs INFORM7 and INFORM6 for non sleep wakeups. My cpu version is S5PV310AH--0AH1113(Origen board). I suggest adding support for both type of wakeups(directly from irom and through bootloader). Thanks, Amit D Besides, the Exynos4210 chipmaker (S.LSI) has told that INFORM6 and 7 registers are used by in-chip code (iROM or iRAM). Cheers! MyungJoo -- MyungJoo Ham, Ph.D. Mobile Software Platform Lab, DMC Business, Samsung Electronics -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/5] ARM: exynos4: Add support for AFTR mode cpuidle state
On 11 November 2011 15:47, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote:
Hi Amit,
On Fri, Nov 11, 2011 at 06:29:33AM +, Amit Daniel Kachhap wrote:
This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode.
This patch adds the code to the latest interfaces to
save/restore CPU state inclusive of CPU PM notifiers, l2
resume and cpu_suspend/resume.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos/cpuidle.c | 148
++-
arch/arm/mach-exynos/include/mach/pmu.h | 2 +
2 files changed, 146 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index c6485d3..857ccc6 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -12,13 +12,31 @@
#include linux/module.h
#include linux/init.h
#include linux/cpuidle.h
+#include linux/cpu_pm.h
Included but not used, why ? Is GIC state kept in AFTR ? Even if it
is, VFP state is certainly gone, so you must call the notifiers anyway.
#include linux/io.h
-
+#include linux/suspend.h
+#include linux/err.h
#include asm/proc-fns.h
+#include asm/smp_scu.h
+#include asm/suspend.h
+#include asm/unified.h
+#include mach/regs-pmu.h
+#include mach/pmu.h
+
+#include plat/exynos4.h
+#include plat/cpu.h
+
+#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24))
+#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20))
static int exynos4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
+static int exynos4_enter_lowpower(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index);
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -26,9 +44,17 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
.exit_latency = 1,
.target_residency = 10,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .name = IDLE,
+ .name = C0,
.desc = ARM clock gating(WFI),
},
+ [1] = {
+ .enter = exynos4_enter_lowpower,
+ .exit_latency = 300,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C1,
+ .desc = ARM power down,
+ },
};
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
@@ -38,9 +64,95 @@ static struct cpuidle_driver exynos4_idle_driver = {
.owner = THIS_MODULE,
};
+/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
+static void exynos4_set_wakeupmask(void)
+{
+ __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+}
+
+static unsigned int g_pwr_ctrl, g_diag_reg;
+
+static void save_cpu_arch_register(void)
+{
+ /*read power control register*/
+ asm(mrc p15, 0, %0, c15, c0, 0 : =r(g_pwr_ctrl) : : cc);
+ /*read diagnostic register*/
+ asm(mrc p15, 0, %0, c15, c0, 1 : =r(g_diag_reg) : : cc);
+ return;
+}
+
+static void restore_cpu_arch_register(void)
+{
+ /*write power control register*/
+ asm(mcr p15, 0, %0, c15, c0, 0 : : r(g_pwr_ctrl) : cc);
+ /*write diagnostic register*/
+ asm(mcr p15, 0, %0, c15, c0, 1 : : r(g_diag_reg) : cc);
+ return;
+}
+
+static int idle_finisher(unsigned long flags)
+{
+ cpu_do_idle();
+ return 1;
+}
+
+static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct timeval before, after;
+ int idle_time;
+ unsigned long tmp;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ exynos4_set_wakeupmask();
+
+ /* Set value of power down register for aftr mode */
+ exynos4_sys_powerdown_conf(SYS_AFTR);
+
+ save_cpu_arch_register();
+
You must call the notifiers here, at least cpu_pm_enter();
Yes lorenzo, cpu_pm_enter may be needed although it does GIC_CPU
save/restore which may not be needed.
Thanks for the review.
+ /* Setting Central Sequence Register for power down mode */
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ tmp = ~S5P_CENTRAL_LOWPWR_CFG;
+ __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+
+ cpu_suspend(0, idle_finisher);
+
+ scu_enable(S5P_VA_SCU);
+
[PATCH 0/4]ARM: exynos4: Add l2 retention mode cpuidle state
From: Amit Daniel Kachhap amit.kach...@linaro.org This Patch series adds support for AFTR mode cpuidle state based on patch (http://www.spinics.net/lists/arm-kernel/msg132243.html) earlier submitted by Jaecheol Lee jc@samsung.com. This patch uses CPU PM notifiers , common l2 save/restore and new cpu_suspend/resume interfaces and is based on the tip of linus tree(git://github.com/torvalds/linux.git). Amit Daniel Kachhap (3): ARM: exynos4: Add support for AFTR mode cpuidle state ARM: exynos4: add L2 early resume code ARM: exynos4: remove useless code to save/restore L2 and GIC state Lorenzo Pieralisi (1): ARM: exynos4: remove useless churn in sleep.S arch/arm/mach-exynos4/cpu.c | 43 ++-- arch/arm/mach-exynos4/cpuidle.c | 152 +- arch/arm/mach-exynos4/include/mach/pmu.h |2 + arch/arm/mach-exynos4/pm.c | 86 - arch/arm/mach-exynos4/sleep.S| 29 +- 5 files changed, 210 insertions(+), 102 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state
From: Amit Daniel Kachhap amit.kach...@linaro.org
This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode.
This patch ports the code to the latest interfaces to
save/restore CPU state inclusive of CPU PM notifiers, l2
resume and cpu_suspend/resume.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos4/cpuidle.c | 152 +-
arch/arm/mach-exynos4/include/mach/pmu.h |2 +
2 files changed, 151 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-exynos4/cpuidle.c
index bf7e96f..111ccc3 100644
--- a/arch/arm/mach-exynos4/cpuidle.c
+++ b/arch/arm/mach-exynos4/cpuidle.c
@@ -11,22 +11,48 @@
#include linux/kernel.h
#include linux/init.h
#include linux/cpuidle.h
+#include linux/cpu_pm.h
#include linux/io.h
-
+#include linux/suspend.h
+#include linux/err.h
#include asm/proc-fns.h
+#include asm/smp_scu.h
+#include asm/suspend.h
+#include asm/unified.h
+#include mach/regs-pmu.h
+#include mach/pmu.h
+
+#include plat/exynos4.h
+#include plat/cpu.h
+
+#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24))
+#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20))
static int exynos4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_state *state);
+static int exynos4_enter_lowpower(struct cpuidle_device *dev,
+ struct cpuidle_state *state);
+
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
.enter = exynos4_enter_idle,
.exit_latency = 1,
.target_residency = 10,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .name = IDLE,
+ .name = C0,
.desc = ARM clock gating(WFI),
},
+ [1] = {
+ .enter = exynos4_enter_lowpower,
+ .exit_latency = 300,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C1,
+ .desc = ARM power down,
+ },
};
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
@@ -36,6 +62,96 @@ static struct cpuidle_driver exynos4_idle_driver = {
.owner = THIS_MODULE,
};
+/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
+static void exynos4_set_wakeupmask(void)
+{
+ __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+}
+
+static unsigned int g_pwr_ctrl, g_diag_reg;
+
+static void save_cpu_arch_register(void)
+{
+ /*read power control register*/
+ asm(mrc p15, 0, %0, c15, c0, 0 : =r(g_pwr_ctrl) : : cc);
+ /*read diagnostic register*/
+ asm(mrc p15, 0, %0, c15, c0, 1 : =r(g_diag_reg) : : cc);
+ return;
+}
+
+static void restore_cpu_arch_register(void)
+{
+ /*write power control register*/
+ asm(mcr p15, 0, %0, c15, c0, 0 : : r(g_pwr_ctrl) : cc);
+ /*write diagnostic register*/
+ asm(mcr p15, 0, %0, c15, c0, 1 : : r(g_diag_reg) : cc);
+ return;
+}
+
+static int idle_finisher(unsigned long flags)
+{
+ cpu_do_idle();
+ return 1;
+}
+
+static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct timeval before, after;
+ int idle_time;
+ unsigned long tmp;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ exynos4_set_wakeupmask();
+
+ /* Set value of power down register for aftr mode */
+ exynos4_sys_powerdown_conf(SYS_AFTR);
+
+ save_cpu_arch_register();
+
+ /* Setting Central Sequence Register for power down mode */
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ tmp = ~S5P_CENTRAL_LOWPWR_CFG;
+ __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+
+ cpu_pm_enter();
+ cpu_cluster_pm_enter();
+
+ cpu_suspend(0, idle_finisher);
+
+ scu_enable(S5P_VA_SCU);
+
+ cpu_cluster_pm_exit();
+ cpu_pm_exit();
+
+ restore_cpu_arch_register();
+
+ /*
+* If PMU failed while entering sleep mode, WFI will be
+* ignored by PMU and then exiting cpu_do_idle().
+* S5P_CENTRAL_LOWPWR_CFG bit will not be set automatically
+* in this situation.
+*/
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ if (!(tmp S5P_CENTRAL_LOWPWR_CFG)) {
+ tmp |= S5P_CENTRAL_LOWPWR_CFG;
+
[PATCH 2/4] ARM: exynos4: remove useless churn in sleep.S
From: Lorenzo Pieralisi lorenzo.pieral...@arm.com This patch cleans up sleep code in preparation for L2 resume code and hotplug functions Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- arch/arm/mach-exynos4/sleep.S |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos4/sleep.S b/arch/arm/mach-exynos4/sleep.S index 0984078..c19527b 100644 --- a/arch/arm/mach-exynos4/sleep.S +++ b/arch/arm/mach-exynos4/sleep.S @@ -27,8 +27,6 @@ */ #include linux/linkage.h -#include asm/assembler.h -#include asm/memory.h .text @@ -52,3 +50,4 @@ ENTRY(s3c_cpu_resume) b cpu_resume +ENDPROC(s3c_cpu_resume) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: exynos4: add L2 early resume code
From: Amit Daniel Kachhap amit.kach...@linaro.org
This patch adds code to save L2 register configuration at boot, and to
resume L2 before MMU is enabled in suspend and cpuidle resume paths.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos4/cpu.c | 43 ++--
arch/arm/mach-exynos4/sleep.S | 26
2 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index a348434..53c6cd3 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -11,6 +11,7 @@
#include linux/sched.h
#include linux/sysdev.h
+#include asm/cacheflush.h
#include asm/mach/map.h
#include asm/mach/irq.h
@@ -31,6 +32,7 @@
#include mach/regs-irq.h
#include mach/regs-pmu.h
+#include mach/pmu.h
unsigned int gic_bank_offset __read_mostly;
@@ -254,20 +256,39 @@ core_initcall(exynos4_core_init);
#ifdef CONFIG_CACHE_L2X0
static int __init exynos4_l2x0_cache_init(void)
{
- /* TAG, Data Latency Control: 2cycle */
- __raw_writel(0x110, S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL);
+ if (!(__raw_readl(S5P_VA_L2CC + L2X0_CTRL) 0x1)) {
- if (soc_is_exynos4210())
- __raw_writel(0x110, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
- else if (soc_is_exynos4212() || soc_is_exynos4412())
- __raw_writel(0x120, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
+ l2x0_saved_regs.phy_base = EXYNOS4_PA_L2CC;
+ /* TAG, Data Latency Control: 2 cycles */
+ l2x0_saved_regs.tag_latency = 0x110;
+
+ if (soc_is_exynos4212() || soc_is_exynos4412())
+ l2x0_saved_regs.data_latency = 0x120;
+ else
+ l2x0_saved_regs.data_latency = 0x110;
+
+ l2x0_saved_regs.prefetch_ctrl = 0x3007;
+ l2x0_saved_regs.pwr_ctrl =
+ (L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN);
- /* L2X0 Prefetch Control */
- __raw_writel(0x3007, S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
+ l2x0_regs_phys = virt_to_phys(l2x0_saved_regs);
- /* L2X0 Power Control */
- __raw_writel(L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN,
-S5P_VA_L2CC + L2X0_POWER_CTRL);
+ __raw_writel(l2x0_saved_regs.tag_latency,
+ S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL);
+ __raw_writel(l2x0_saved_regs.data_latency,
+ S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
+
+ /* L2X0 Prefetch Control */
+ __raw_writel(l2x0_saved_regs.prefetch_ctrl,
+ S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
+
+ /* L2X0 Power Control */
+ __raw_writel(l2x0_saved_regs.pwr_ctrl,
+ S5P_VA_L2CC + L2X0_POWER_CTRL);
+
+ clean_dcache_area(l2x0_regs_phys, sizeof(unsigned long));
+ clean_dcache_area(l2x0_saved_regs, sizeof(struct l2x0_regs));
+ }
l2x0_init(S5P_VA_L2CC, 0x7C470001, 0xC200);
diff --git a/arch/arm/mach-exynos4/sleep.S b/arch/arm/mach-exynos4/sleep.S
index c19527b..3284213 100644
--- a/arch/arm/mach-exynos4/sleep.S
+++ b/arch/arm/mach-exynos4/sleep.S
@@ -27,6 +27,8 @@
*/
#include linux/linkage.h
+#include asm/asm-offsets.h
+#include asm/hardware/cache-l2x0.h
.text
@@ -47,7 +49,31 @@
* other way of restoring the stack pointer after sleep, and we
* must not write to the code segment (code is read-only)
*/
+ .align
+ .data
ENTRY(s3c_cpu_resume)
+ adr r0, l2x0_regs_phys
+ ldr r0, [r0]
+ ldr r1, [r0, #L2X0_R_PHY_BASE]
+ ldr r2, [r1, #L2X0_CTRL]
+ tst r2, #0x1
+ bne resume_l2on
+ ldr r2, [r0, #L2X0_R_AUX_CTRL]
+ str r2, [r1, #L2X0_AUX_CTRL]
+ ldr r2, [r0, #L2X0_R_TAG_LATENCY]
+ str r2, [r1, #L2X0_TAG_LATENCY_CTRL]
+ ldr r2, [r0, #L2X0_R_DATA_LATENCY]
+ str r2, [r1, #L2X0_DATA_LATENCY_CTRL]
+ ldr r2, [r0, #L2X0_R_PREFETCH_CTRL]
+ str r2, [r1, #L2X0_PREFETCH_CTRL]
+ ldr r2, [r0, #L2X0_R_PWR_CTRL]
+ str r2, [r1, #L2X0_POWER_CTRL]
+ mov r2, #1
+ str r2, [r1, #L2X0_CTRL]
+resume_l2on:
b cpu_resume
ENDPROC(s3c_cpu_resume)
+ .globl l2x0_regs_phys
+l2x0_regs_phys:
+ .long 0
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: exynos4: remove useless code to save/restore L2 and GIC state
From: Amit Daniel Kachhap amit.kach...@linaro.org
Following the merge of CPU PM notifiers and L2 resume code, this patch
removes useless code to save and restore L2 and GIC registers.
This is now automatically covered by suspend calls which integrated
CPU PM notifiers and new sleep code that allows to resume L2 before MMU
is turned on.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos4/pm.c | 86
1 files changed, 0 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-exynos4/pm.c b/arch/arm/mach-exynos4/pm.c
index 62e4f43..7499f14 100644
--- a/arch/arm/mach-exynos4/pm.c
+++ b/arch/arm/mach-exynos4/pm.c
@@ -63,77 +63,6 @@ static struct sleep_save exynos4_vpll_save[] = {
};
static struct sleep_save exynos4_core_save[] = {
- /* GIC side */
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x000),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x004),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x008),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x00C),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x014),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x018),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x000),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x004),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x100),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x104),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x108),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x300),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x304),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x308),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x400),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x404),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x408),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x40C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x410),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x414),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x418),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x41C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x420),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x424),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x428),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x42C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x430),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x434),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x438),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x43C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x440),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x444),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x448),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x44C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x450),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x454),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x458),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x45C),
-
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x800),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x804),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x808),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x80C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x810),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x814),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x818),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x81C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x820),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x824),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x828),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x82C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x830),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x834),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x838),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x83C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x840),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x844),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x848),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x84C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x850),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x854),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x858),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x85C),
-
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC00),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC04),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC08),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC0C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC10),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC14),
SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x000),
SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x010),
@@ -154,13 +83,6 @@ static struct sleep_save exynos4_core_save[] = {
SAVE_ITEM(S5P_SROM_BC3),
};
-static struct sleep_save exynos4_l2cc_save[] = {
- SAVE_ITEM(S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL),
- SAVE_ITEM(S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL),
- SAVE_ITEM(S5P_VA_L2CC + L2X0_PREFETCH_CTRL),
- SAVE_ITEM(S5P_VA_L2CC + L2X0_POWER_CTRL),
- SAVE_ITEM(S5P_VA_L2CC + L2X0_AUX_CTRL),
-};
/* For Cortex-A9 Diagnostic and Power control register */
static unsigned int save_arm_register[2];
@@ -181,7 +103,6 @@ static void exynos4_pm_prepare(void)
u32 tmp;
s3c_pm_do_save(exynos4_core_save, ARRAY_SIZE(exynos4_core_save));
- s3c_pm_do_save(exynos4_l2cc_save, ARRAY_SIZE(exynos4_l2cc_save));
s3c_pm_do_save(exynos4_epll_save, ARRAY_SIZE(exynos4_epll_save));
s3c_pm_do_save(exynos4_vpll_save, ARRAY_SIZE(exynos4_vpll_save));
@@ -397,13 +318,6 @@ static void exynos4_pm_resume(void)
Re: [RFC PATCH 3/4] ARM: EXYNOS4: Add support AFTR mode cpuidle state on EXYNOS4210
On 21 August 2011 22:48, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Aug 19, 2011 at 06:39:59PM +0530, Amit Daniel Kachhap wrote:
+ENTRY(exynos4_enter_lp)
+ stmfd sp!, { r3 - r12, lr }
+
+ adr r0, sleep_save_misc
+
+ mrc p15, 0, r2, c15, c0, 0 @ read power control register
+ str r2, [r0], #4
+
+ mrc p15, 0, r2, c15, c0, 1 @ read diagnostic register
+ str r2, [r0], #4
+
+ ldr r3, =resume_with_mmu
+ bl cpu_suspend
+
+ mov r0, sp
+ bl exynos4_cpu_lp
+
+ /* Restore original sp */
+ mov r0, sp
+ add r0, r0, #4
+ ldr sp, [r0]
+
+ mov r0, #0
+ b early_wakeup
This is based upon old kernel code. Clearly hasn't been tested with
anything later than 3.0.
You are right. I will rebase it to the latest tree in the next
version. The main intention of the patch series (mostly patch 4) is to
collect information or issues on samsung platform with the new common
cpuidle framework.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/4] ARM: EXYNOS4: Fix to work with origen boards.
On 19 August 2011 19:29, Kyungmin Park kmp...@infradead.org wrote:
On Fri, Aug 19, 2011 at 10:09 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
This adds a function to get the revision id.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
---
arch/arm/mach-exynos4/cpu.c | 10 ++
arch/arm/plat-s5p/include/plat/exynos4.h | 1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..8b106b8 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -234,6 +234,16 @@ static int __init exynos4_l2x0_cache_init(void)
early_initcall(exynos4_l2x0_cache_init);
#endif
+int exynos4_subrev(void)
+{
+ static int subrev = -1;
+
+ if (unlikely(subrev 0))
+ subrev = readl(S5P_VA_CHIPID) 0xf;
How about to add the clock control here?
1. Register chipid clk
2. Get the chipid clk
3. Read CHPIID,
4. Put tht chipid clk.
Nice suggestion. Will do it in the next patch version. Actually the
main focus of this
patch series was to have a proof of concept of the new cpuidle common code.
Thanks,
Amit Daniel
Then you can save some power.
Thank you,
Kyungmin Park
+
+ return subrev;
+}
+
int __init exynos4_init(void)
{
printk(KERN_INFO EXYNOS4: Initializing architecture\n);
diff --git a/arch/arm/plat-s5p/include/plat/exynos4.h
b/arch/arm/plat-s5p/include/plat/exynos4.h
index 907caab..d62f7f7 100644
--- a/arch/arm/plat-s5p/include/plat/exynos4.h
+++ b/arch/arm/plat-s5p/include/plat/exynos4.h
@@ -15,6 +15,7 @@
extern void exynos4_common_init_uarts(struct s3c2410_uartcfg *cfg, int no);
extern void exynos4_register_clocks(void);
extern void exynos4_setup_clocks(void);
+extern int exynos4_subrev(void);
#ifdef CONFIG_CPU_EXYNOS4210
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C: Samsung: Add support for PM_runtime in the I2C driver.
On Mon, Mar 28, 2011 at 4:41 AM, Ben Dooks ben-li...@fluff.org wrote:
On Sun, Mar 27, 2011 at 04:32:43PM -0400, Amit Daniel Kachhap wrote:
This patch adds PM runtime management support in the I2C driver.
The functionality of the driver is not modified much but some extra I2C
states are added for PM runtime. The runtime suspend keeps the interrupt
for the I2C interface disabled.
ok, whilst this looks ok, it's too late for the current merge window,
so will go into the -next for the next kernel
Hi Ben,
I do not see this patch in your i2c-next branch. Could you please
merge this patch in the next merge window.
Thanks,
Amit Daniel
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/i2c/busses/i2c-s3c2410.c | 61
+-
1 files changed, 53 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index 6c00c10..8ebe621 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -35,6 +35,7 @@
#include linux/cpufreq.h
#include linux/slab.h
#include linux/io.h
+#include linux/pm_runtime.h
#include asm/irq.h
@@ -48,7 +49,9 @@ enum s3c24xx_i2c_state {
STATE_START,
STATE_READ,
STATE_WRITE,
- STATE_STOP
+ STATE_STOP,
+ STATE_STANDBY,
+ STATE_SUSPEND
};
enum s3c24xx_i2c_type {
@@ -59,7 +62,6 @@ enum s3c24xx_i2c_type {
struct s3c24xx_i2c {
spinlock_t lock;
wait_queue_head_t wait;
- unsigned int suspended:1;
struct i2c_msg *msg;
unsigned int msg_num;
@@ -400,8 +402,13 @@ static int i2s_s3c_irq_nextbyte(struct s3c24xx_i2c
*i2c, unsigned long iicstat)
i2c-msg++;
}
}
+ break;
+ default:
+ dev_err(i2c-dev, %s: called with invalid state\n, __func__);
+ goto out;
break;
+
}
/* acknowlegde the IRQ and get back on with the work */
@@ -485,7 +492,7 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
int spins = 20;
int ret;
- if (i2c-suspended)
+ if (i2c-state == STATE_SUSPEND)
return -EIO;
ret = s3c24xx_i2c_set_master(i2c);
@@ -555,12 +562,14 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
int ret;
clk_enable(i2c-clk);
+ pm_runtime_get_sync(i2c-dev);
for (retry = 0; retry adap-retries; retry++) {
ret = s3c24xx_i2c_doxfer(i2c, msgs, num);
if (ret != -EAGAIN) {
+ pm_runtime_put_sync(i2c-dev);
clk_disable(i2c-clk);
return ret;
}
@@ -570,6 +579,7 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
udelay(100);
}
+ pm_runtime_put_sync(i2c-dev);
clk_disable(i2c-clk);
return -EREMOTEIO;
}
@@ -912,10 +922,14 @@ static int s3c24xx_i2c_probe(struct platform_device
*pdev)
goto err_cpufreq;
}
+ /*Set Initial I2C state*/
+ i2c-state = STATE_STANDBY;
+
platform_set_drvdata(pdev, i2c);
dev_info(pdev-dev, %s: S3C I2C adapter\n,
dev_name(i2c-adap.dev));
clk_disable(i2c-clk);
+ pm_runtime_enable(pdev-dev);
return 0;
err_cpufreq:
@@ -956,6 +970,7 @@ static int s3c24xx_i2c_remove(struct platform_device
*pdev)
clk_disable(i2c-clk);
clk_put(i2c-clk);
+ pm_runtime_disable(pdev-dev);
iounmap(i2c-regs);
@@ -972,9 +987,9 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
- i2c-suspended = 1;
-
+ i2c-state = STATE_SUSPEND;
return 0;
+
}
static int s3c24xx_i2c_resume(struct device *dev)
@@ -982,17 +997,47 @@ static int s3c24xx_i2c_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
- i2c-suspended = 0;
clk_enable(i2c-clk);
s3c24xx_i2c_init(i2c);
+ i2c-state = STATE_STANDBY;
clk_disable(i2c-clk);
return 0;
}
+static int s3c_i2c_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
+
+ i2c-state = STATE_STANDBY;
+ s3c24xx_i2c_disable_irq(i2c);
+ s3c24xx_i2c_disable_ack(i2c);
+
+ return 0;
+}
+
+static int s3c_i2c_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
+
+ if (i2c-state != STATE_STANDBY)
+ return 0;
+
+ /*No major activity in runtime resume because all the registers are
+
