Re: [PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
On Wed, Jul 9, 2014 at 8:30 AM, Chanwoo Choi 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
>> [Add MUX address setting bits by Jonghwa Lee]
>> Signed-off-by: Jonghwa Lee
>> Acked-by: Kyungmin Park
Changes look fine to me.
Reviewed-by: Amit Daniel Kachhap
>> ---
>> .../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,
Re: [PATCH 00/10] thermal: exynos: various cleanups
On 5/15/14, Zhang Rui 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 R&D 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 10/10] thermal: exynos: remove identical values from exynos*_tmu_registers structures
On 5/5/14, Bartlomiej Zolnierkiewicz 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 Kachhap
>
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> 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_CO
Re: [PATCH 09/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_control()
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz 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
> ---
> 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 08/10] thermal: exynos: cache non_hw_trigger_levels in pdata
On 5/5/14, Bartlomiej Zolnierkiewicz 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 Kachhap
>
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> 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,
Re: [PATCH 07/10] thermal: exynos: simplify temp_to_code() and code_to_temp()
On 5/5/14, Bartlomiej Zolnierkiewicz 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
Changes looks fine.
Reviewed-by: Amit Daniel Kachhap
> ---
> 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 06/10] thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize()
On 5/5/14, Bartlomiej Zolnierkiewicz 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
> ---
> 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 05/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize()
On 5/15/14, Bartlomiej Zolnierkiewicz 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
>> > ---
>> > 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 R&D 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 04/10] thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration
On 5/5/14, Bartlomiej Zolnierkiewicz 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
> ---
> 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/
Re: [PATCH 03/10] thermal: exynos: remove dead code for HW_MODE calibration
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> 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 drescribi
Re: [PATCH 02/10] thermal: exynos: remove unused defines
Hi Bartlomiej, On 5/5/14, Bartlomiej Zolnierkiewicz wrote: > There should be no functional changes caused by this patch. > > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > 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 01/10] thermal: exynos: remove unused struct exynos_tmu_registers entries
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> 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_s
Re: [PATCH 2/2] cpufreq: Remove exynos_sort_descend_freq_table in exynos5440-cpufreq.c
On 4/29/14, Viresh Kumar wrote:
> On 29 April 2014 10:54, Jonghwan Choi wrote:
>> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
>> -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;
>> - /*
>> -* Exynos5440 clock controller state logic expects the cpufreq
>> table
>> to
>> -* be in descending order. But the OPP library constructs the
>> table
>> in
>> -* ascending order. So to make the table descending we just need
>> to
>> -* swap the i element with the N - i element.
>> -*/
>
> What I am more focused is on: Why do we need to worry about order at
> all in the first place.
>
> Okay, above comment says something about it but I couldn't understand
> what's the logic behind that. Why do we need same order as of clock
> controller. Please point out relevant code pieces as well..
>
> @Amit: Your comments on this ?
Hi Viresh/Jonghwan,
In the frequency table dts file, the frequencies are arranged in
descending order which maps 1 to 1 with other frequency parameter to
be calculated and programmed in some registers.
But the OPP library works by generating the frequencies in ascending
order which breaks the above logic. Ideally i should expect frequency
values in same order as what is supplied.
So OPP library should not change the order or should take input flags
flags like,
dev_pm_opp_init_cpufreq_table(TABLE_ORDER_ASCEND|
TABLE_ORDER_DESCEND|TABLE_ORDER_ORIGINAL )
Thanks,
Amit Daniel
>
> ___
> 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] thermal: samsung: Only update available threshold limits
On 4/14/14, Tushar Behera wrote:
> Currently the threshold limits are updated in 2 stages, once for all
> software trigger levels and again for hardware trip point.
I guess the first stage is bootloader as could not find this in this file.
Anyways the changes looks fine to me.
Acked-by: Amit Daniel Kachhap
>
> While updating the software trigger levels, it overwrites the threshold
> limit for hardware trip point thereby forcing the Exynos core to issue
> an emergency shutdown.
>
> Updating only the required fields in threshold register fixes this issue.
>
> Signed-off-by: Tushar Behera
> ---
> Based on v3.15-rc1.
>
> drivers/thermal/samsung/exynos_tmu.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 0d96a51..ffccc89 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -225,6 +225,8 @@ skip_calib_data:
> trigger_levs++;
> }
>
> + rising_threshold = readl(data->base + reg->threshold_th0);
> +
> if (data->soc == SOC_ARCH_EXYNOS4210) {
> /* Write temperature code for threshold */
> threshold_code = temp_to_code(data, pdata->threshold);
> @@ -249,6 +251,7 @@ skip_calib_data:
> ret = threshold_code;
> goto out;
> }
> + rising_threshold &= ~(0xff << 8 * i);
> rising_threshold |= threshold_code << 8 * i;
> if (pdata->threshold_falling) {
> threshold_code = temp_to_code(data,
> @@ -281,6 +284,7 @@ skip_calib_data:
> }
> if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
> /* 1-4 level to be assigned in th0 reg */
> + rising_threshold &= ~(0xff << 8 * i);
> rising_threshold |= threshold_code << 8 * i;
> writel(rising_threshold,
> data->base + reg->threshold_th0);
> --
> 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
>
--
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 wrote:
>
> Hi,
>
> Could you please also apply this patch?
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D 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
>> Signed-off-by: Kyungmin Park
>> ---
>> 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: [PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
On 10/4/13, Bartlomiej Zolnierkiewicz 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 > Signed-off-by: Kyungmin Park Looks good, so Acked-by: Amit Daniel Kachhap > --- > 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: [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 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 > > while at it. > > Thanks. > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D 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 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 >> >> Cc: Thomas Abraham >> >> Signed-off-by: Amit Daniel Kachhap >> > >> > 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 >> > >> > 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 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 > > while at it. > > Thanks. > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D 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 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 >> >> Cc: Thomas Abraham >> >> Signed-off-by: Amit Daniel Kachhap >> > >> > 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 >> > >> > 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
wrote:
> Enable TMU support for Exynos4412 based target with device tree.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
> ---
> 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: [2/9] thermal: exynos: Add support for instance based register/unregister
Hi Eduardo,
On Fri, Apr 12, 2013 at 1:39 AM, Eduardo Valentin
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
>
>
> 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(str
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
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
>> Signed-off-by: Amit Daniel Kachhap
>>
>> ---
>> 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.
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 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
> 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
>> ---
>> .../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_coun
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 wrote:
> On 7 March 2013 12:13, Amit Daniel Kachhap 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 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
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 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
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
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 wrote:
> On 2 March 2013 15:04, Amit Daniel Kachhap 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
>> ---
>> 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 @@
Re: [PATCH 3/3] dts: Add cpufreq controller node for Exynos5440 SoC
On Fri, Feb 8, 2013 at 8:49 AM, Inderpal Singh
wrote:
> On 8 February 2013 00:03, amit kachhap wrote:
>> On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
>> wrote:
>>> On 7 February 2013 01:09, Amit Daniel Kachhap
>>> 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
>>>> ---
>>>> 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 V2 2/2] thermal: exynos: Use the framework for temperature emulation support
On Thu, Feb 7, 2013 at 7:04 PM, Zhang Rui 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
>> > Acked-by: Kukjin Kim
>> > ---
>> > 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;
>> > + }
Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440
On Thu, Feb 7, 2013 at 6:42 PM, Viresh Kumar wrote:
> On 8 February 2013 00:38, amit kachhap 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 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
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 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
>> Acked-by: Kukjin Kim
>> ---
>> 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->sens
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 wrote:
> On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap
> 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
>> ---
>> .../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
>> + *
>> + * 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
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/*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
>>
Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Inder,
Thanks for the review,
On Wed, Feb 6, 2013 at 9:09 PM, Inderpal Singh
wrote:
> On 7 February 2013 01:09, Amit Daniel Kachhap 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.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> .../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,
>> + 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/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index a0b3661..554756f 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -77,6 +77,14 @@ config ARM_EXYNOS5250_CPUFREQ
>> This adds the CPUFreq driver for Samsung EXYNOS5250
>> SoC.
>>
>> +config ARM_EXYNOS5440_CPUFREQ
>> + def_bool SOC_EXYNOS5440
>> + 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_SPEAR_CPUFREQ
>> bool "SPEAr CPUFreq support"
>> depends on PLAT_SPEAR
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index fadc4d4..5159ba4 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -50,6 +50,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_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..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
>> + *
>> + * 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
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/*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_CSCL
Re: [PATCH 3/3] dts: Add cpufreq controller node for Exynos5440 SoC
On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
wrote:
> On 7 February 2013 01:09, Amit Daniel Kachhap 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
>> ---
>> 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 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 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
>> Acked-by: Kukjin Kim
>> ---
>>
>> 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 (cou
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
On Mon, Jan 21, 2013 at 7:20 PM, Zhang Rui 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 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 >> >> --- >> >> 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 suppor
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 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
>> ---
>> 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 D
Re: [linux-pm] [PATCH] cpufreq: exynos: Show list of available frequencies
On Tue, Jan 8, 2013 at 2:50 AM, Inderpal Singh
wrote:
> Add freq_attr attribute to show list of available frequencies.
>
> Signed-off-by: Donggeun Kim
> Signed-off-by: MyungJoo Ham
> Signed-off-by: KyungMin Park
> Signed-off-by: Inderpal Singh
> ---
> 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 Kachhap
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 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 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: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 13:42, Zhang Rui wrote:
> On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
>> On 22 November 2012 06:52, Zhang Rui 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
>> >> Signed-off-by: Amit Daniel Kachhap
>> >> ---
>> >> 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 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 06:52, Zhang Rui 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
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> 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-Resend] thermal: Exynos: Add missing dependency
On 15 November 2012 12:34, Zhang Rui wrote: > On Thu, 2012-11-15 at 12:31 +0530, Amit Kachhap wrote: >> On 15 November 2012 12:09, Sachin Kamat 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 >> > Signed-off-by: Sachin Kamat >> > --- >> > 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-Resend] thermal: Exynos: Add missing dependency
On 15 November 2012 12:09, Sachin Kamat 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 > Signed-off-by: Sachin Kamat > --- > 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 1/4] thermal: Add new thermal trend type to support quick cooling
On 9 November 2012 09:21, Zhang Rui wrote:
> On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
>> On 8 November 2012 11:31, Zhang Rui 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
>> >> Signed-off-by: Amit Daniel Kachhap
>> >> ---
>> >> 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 the
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 8 November 2012 11:31, Zhang Rui 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
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> 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 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 > 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 > Cc: SangWook Ju > Cc: Durgadoss > Cc: Len Brown > Cc: Jean Delvare > Cc: Kyungmin Park > Cc: Kukjin Kim > Signed-off-by: Zhang Rui > Signed-off-by: Andrew Morton > Signed-off-by: Amit Daniel Kachhap > --- > 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 > + > +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 c
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 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 > Cc: Guenter Roeck > Cc: SangWook Ju > Cc: Durgadoss > Cc: Len Brown > Cc: Jean Delvare > Cc: Kyungmin Park > Cc: Kukjin Kim > Reviewed-by: Eduardo Valentin > Signed-off-by: Andrew Morton > Signed-off-by: Amit Daniel Kachhap > --- > 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 > + > +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_devi
Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
On 17 August 2012 12:54, Zhang Rui 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 >> Cc: Guenter Roeck >> Cc: SangWook Ju >> Cc: Durgadoss >> Cc: Len Brown >> Cc: Jean Delvare >> Cc: Kyungmin Park >> Cc: Kukjin Kim >> Signed-off-by: Andrew Morton >> Signed-off-by: Amit Daniel Kachhap >> --- >> 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 >> + >> +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 funct
Re: [linux-pm] [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
On 16 August 2012 20:22, Valentin, Eduardo wrote: > > Amit, > > Thanks again for keeping this up. > > On Thu, Aug 16, 2012 at 2:41 PM, 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) > > 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 > > Cc: Guenter Roeck > > Cc: SangWook Ju > > Cc: Durgadoss > > Cc: Len Brown > > Cc: Jean Delvare > > Cc: Kyungmin Park > > Cc: Kukjin Kim > > Signed-off-by: Andrew Morton > > Signed-off-by: Amit Daniel Kachhap > > > Reviewed-by: Eduardo Valentin 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 > > + > > +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_coo
Re: [PATCH v5 5/5] ARM: exynos: add thermal sensor driver platform data support
On Sat, Jul 14, 2012 at 7:03 AM, Kyungmin Park wrote:
> On Fri, Jul 13, 2012 at 8:10 PM, Amit Daniel Kachhap
> wrote:
>> Add necessary default platform data support needed for TMU driver. This
>> dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
>> platforms.
> Looks good to me.
Thanks.
> just nitpicks below.
>
> Thank you,
> Kyungmin Park
>>
>> Signed-off-by: Amit Daniel Kachhap
>> Cc: Donggeun Kim
>> Acked-by: Guenter Roeck
>> Cc: SangWook Ju
>> Cc: Durgadoss
>> Cc: Len Brown
>> Cc: Jean Delvare
>> Signed-off-by: Andrew Morton
>> ---
>> drivers/thermal/exynos_thermal.c | 111
>> +-
>> 1 files changed, 110 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> index 9ef8c37..07736ea 100644
>> --- a/drivers/thermal/exynos_thermal.c
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -662,14 +662,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>> static struct thermal_sensor_conf exynos_sensor_conf = {
>> .name = "exynos-therm",
>> .read_temperature = (int (*)(void *))exynos_tmu_read,
>> +};
>> +
>> +#if defined(CONFIG_CPU_EXYNOS4210)
> BTW, doesn't it same as exynos4412? does it different from exynos4412?
Currently I only tested this only for origen and exynos5250 board.
Maybe somebody can add 4412 support also.
> If it's same, it's better to use CONFIG_SOC_EXYNOS4?
>> +static struct exynos_tmu_platform_data const exynos4_default_tmu_data = {
>> + .threshold = 80,
>> + .trigger_levels[0] = 5,
>> + .trigger_levels[1] = 20,
>> + .trigger_levels[2] = 30,
>> + .trigger_level0_en = 1,
>> + .trigger_level1_en = 1,
>> + .trigger_level2_en = 1,
>> + .trigger_level3_en = 0,
>> + .gain = 15,
>> + .reference_voltage = 7,
>> + .cal_type = TYPE_ONE_POINT_TRIMMING,
>> + .freq_tab[0] = {
>> + .freq_clip_max = 800 * 1000,
>> + .temp_level = 85,
>> + },
>> + .freq_tab[1] = {
>> + .freq_clip_max = 200 * 1000,
>> + .temp_level = 100,
>> + },
>> + .freq_tab_count = 2,
>> + .type = SOC_ARCH_EXYNOS4,
>> +};
>> +#define EXYNOS4_TMU_DRV_DATA (&exynos4_default_tmu_data)
>> +#else
>> +#define EXYNOS4_TMU_DRV_DATA (NULL)
>> +#endif
>> +
>> +#if defined(CONFIG_SOC_EXYNOS5250)
> similar.
>> +static struct exynos_tmu_platform_data const exynos5_default_tmu_data = {
>> + .trigger_levels[0] = 85,
>> + .trigger_levels[1] = 103,
>> + .trigger_levels[2] = 110,
>> + .trigger_level0_en = 1,
>> + .trigger_level1_en = 1,
>> + .trigger_level2_en = 1,
>> + .trigger_level3_en = 0,
>> + .gain = 8,
>> + .reference_voltage = 16,
>> + .noise_cancel_mode = 4,
>> + .cal_type = TYPE_ONE_POINT_TRIMMING,
>> + .efuse_value = 55,
>> + .freq_tab[0] = {
>> + .freq_clip_max = 800 * 1000,
>> + .temp_level = 85,
>> + },
>> + .freq_tab[1] = {
>> + .freq_clip_max = 200 * 1000,
>> + .temp_level = 103,
>> + },
>> + .freq_tab_count = 2,
>> + .type = SOC_ARCH_EXYNOS5,
>> +};
>> +#define EXYNOS5_TMU_DRV_DATA (&exynos5_default_tmu_data)
>> +#else
>> +#define EXYNOS5_TMU_DRV_DATA (NULL)
>> +#endif
>> +
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id exynos_tmu_match[] = {
>> + {
>> + .compatible = "samsung,exynos4-tmu",
>> + .data = (void *)EXYNOS4_TMU_DRV_DATA,
>> + },
>> + {
>> + .compatible = "samsung,exynos5-tmu",
>> + .data = (void *)EXYNOS5_TMU_DRV_DATA,
>> + },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, exynos_tmu_match);
>> +#else
>> +#define exynos_tmu_match NULL
>> +#endif
>> +
>> +static struct platform_device_id exynos_tmu_driver_ids[] = {
>> + {
>> + .name = "exynos4-tmu",
>> + .driver_data= (kernel_ulong_t)EXYNOS4_TMU_DRV_DATA,
>> + },
>> + {
>> + .name = "exynos5-tmu",
>> + .driver_data= (kernel_ulong_t)EXYNOS5_TMU_DRV_DATA,
>> + },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
>> +
>> +static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
>> + struct platform_device *pdev)
>> +{
>> +#ifdef CONFIG_OF
>> + if (pdev->dev.of_node) {
>> + const struct of_device_id *match;
>> + match = of_match_node(exynos_tmu_match, pdev->dev.of_node);
>> + if (!match)
>> + return NULL;
>> + return (struct exynos_tmu_platform_data *) match->data;
>> + }
>> +#endif
>> + return (struct exynos_tmu_platform_data *)
>> + platform_get_device_id(pdev)->driver_data;
>> }
>> -;
>> static in
Re: [PATCH 0/2] ARM: exynos: Enable TMU support in exynos platforms
On Fri, Jul 13, 2012 at 8:11 PM, Guenter Roeck 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: [PATCH 0/2] ARM: exynos: Enable TMU support in exynos platforms
On Fri, Jul 13, 2012 at 4:58 PM, 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 :( 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 , 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 v4 1/5] thermal: Add generic cpufreq cooling implementation
On Fri, Jul 13, 2012 at 3:39 PM, Hongbo Zhang wrote: > > > On 12 May 2012 17:40, Amit Daniel Kachhap 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 >> --- >> 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 >> + >> +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/d
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 wrote: > On Thu, 12 Jul 2012 19:11:04 +0530 > Amit Daniel Kachhap wrote: > >> [a...@linux-foundation.org: fix comment layout] >> Signed-off-by: Amit Daniel Kachhap >> Cc: Donggeun Kim >> Cc: Guenter Roeck >> Cc: SangWook Ju >> Cc: Durgadoss >> Cc: Len Brown >> Cc: Jean Delvare >> Signed-off-by: Andrew Morton > > 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: [linux-pm] [RESEND PATCH v4 1/5] thermal: add generic cpufreq cooling implementation
On Thu, Jul 12, 2012 at 8:40 PM, Valentin, Eduardo wrote: > Amit, > > On Thu, Jul 12, 2012 at 4:41 PM, 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. >> * 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 >> Cc: Donggeun Kim >> Cc: Guenter Roeck >> Cc: SangWook Ju >> Cc: Durgadoss >> Cc: Len Brown >> Cc: Jean Delvare >> Signed-off-by: Andrew Morton >> --- >> 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 >> + >> +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 poin
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
On Tue, Jul 10, 2012 at 12:31 PM, Hongbo Zhang wrote: > > > On 12 May 2012 17:40, Amit Daniel Kachhap 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 >> --- >> 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 >> + >> +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/ther
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 wrote: > Hey Rob and Amit, > > On Tue, Jun 26, 2012 at 6:12 AM, Rob Lee 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 >> 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 >>> --- >>> 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 >>> + >>> +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 HWM
Re: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 9 May 2012 01:36, Zhang, Rui 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 & 1< 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 & 1ops->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 a
Re: [PATCH v3 5/6] thermal: exynos: Register the tmu sensor with the kernel thermal layer
On 9 May 2012 01:46, Andrew Morton wrote:
> On Tue, 8 May 2012 21:48:17 +0530
> Amit Daniel Kachhap 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) {
>> +
Re: [PATCH v3 2/6] thermal: Add generic cpufreq cooling implementation
On 9 May 2012 01:46, Andrew Morton wrote:
> On Tue, 8 May 2012 21:48:14 +0530
> Amit Daniel Kachhap 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;
>> +
>> +
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 wrote:
> On Wed, Apr 25, 2012 at 9:44 AM, Daniel Lezcano
> 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 Lezcano
>>> CC: Robert Lee
>>> Signed-off-by: Amit Daniel
>>> ---
>>> 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 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> @@ -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
>
>>
>>
>> Acked-by: Daniel Lezcano
>>
>> --
>> Facebook |
>> Twitter |
>>
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 16 April 2012 07:37, Zhang Rui 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 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
>> >
>
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
Hi Rui,
Thanks for looking into the patches.
On 10 April 2012 06:28, Zhang Rui 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).
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 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 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
>
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 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 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 and > Donggeun Kim (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
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
>> +
>> +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 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
>> ---
>> 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
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#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
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 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 2/4] hwmon: exynos4: Move thermal sensor driver to driver/mfd directory
On 3 March 2012 17:51, Sylwester Nawrocki 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 Kachhap >> Signed-off-by: Donggeun Kim >> --- >> 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: [PATCH V6 1/5] ARM: exynos: Add support AFTR mode on EXYNOS4210
On 23 February 2012 11:54, Rob Lee 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;
>> +}
>
Re: [PATCH V5 5/5] ARM: exynos: Enable l2 configuration through device tree
On 5 January 2012 10:06, Olof Johansson wrote:
> On Wed, Jan 4, 2012 at 8:25 PM, Amit Daniel Kachhap
> wrote:
>> This patch enables calling generic l2 setup functions if device tree is used.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> 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
>>
>> #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 V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
On 3 January 2012 18:52, Kukjin Kim 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 , 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: [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 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
>> ---
>> 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
>>
>> #include
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> +#include
>> +#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
>>
>> 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
Re: [PATCH V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
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. Thanks, Amit Daniel On Mon, Dec 5, 2011 at 4:36 PM, Amit Daniel Kachhap wrote: > Changes since V3: > *Implemented Russell feedback and moved sleep magic 4byte memory before > s3c_cpu_resume to data section. > > 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 . > > 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 (5): > ARM: exynos: Add support AFTR mode on EXYNOS4210 > 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 | 44 - > 5 files changed, 233 insertions(+), 40 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 V2] mmc: core: Add host capability check for power class
On Thu, Dec 15, 2011 at 9:28 AM, Girish K S
wrote:
> This patch adds a check whether the host supports maximum current value
> obtained from the device's extended csd register for a selected interface
> voltage and frequency.
>
> cc: Chris Ball
> Signed-off-by: Girish K S
> ---
> Changes in v2:
> deleted a unnecessary if else condition identified by subhash J
> Changes in v1:
> reduced the number of comparisons as per Hein's suggestion
>
> drivers/mmc/core/mmc.c | 19 +++
> include/linux/mmc/card.h | 4
> 2 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 006e932..b9ef777 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -688,6 +688,25 @@ static int mmc_select_powerclass(struct mmc_card *card,
> pwrclass_val = (pwrclass_val & EXT_CSD_PWR_CL_4BIT_MASK) >>
> EXT_CSD_PWR_CL_4BIT_SHIFT;
>
> + if (pwrclass_val >= MMC_MAX_CURRENT_800)
Hi girish,
These checks can be made like ,
if (pwrclass_val > MMC_MAX_CURRENT_800)
pwrclass_val = MMC_MAX_CURRENT_800;
Applicable in all below conditional checks.
Thanks,
Amit D
> + pwrclass_val = MMC_MAX_CURRENT_800;
> + else if (pwrclass_val >= MMC_MAX_CURRENT_600)
> + pwrclass_val = MMC_MAX_CURRENT_600;
> + else if (pwrclass_val >= MMC_MAX_CURRENT_400)
> + pwrclass_val = MMC_MAX_CURRENT_400;
> + else
> + pwrclass_val = MMC_MAX_CURRENT_200;
> +
> + if ((pwrclass_val == MMC_MAX_CURRENT_800) &&
> + !(card->host->caps & MMC_CAP_MAX_CURRENT_800))
> + pwrclass_val = MMC_MAX_CURRENT_600;
> + if ((pwrclass_val == MMC_MAX_CURRENT_600) &&
> + !(card->host->caps & MMC_CAP_MAX_CURRENT_600))
> + pwrclass_val = MMC_MAX_CURRENT_400;
> + if ((pwrclass_val == MMC_MAX_CURRENT_400) &&
> + !(card->host->caps & MMC_CAP_MAX_CURRENT_400))
> + pwrclass_val = MMC_MAX_CURRENT_200;
> +
> /* If the power class is different from the default value */
> if (pwrclass_val > 0) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 9478a6b..c5e031a 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -195,6 +195,10 @@ struct mmc_part {
> #define MMC_BLK_DATA_AREA_GP (1<<2)
> };
>
> +#define MMC_MAX_CURRENT_200 (0)
> +#define MMC_MAX_CURRENT_400 (7)
> +#define MMC_MAX_CURRENT_600 (11)
> +#define MMC_MAX_CURRENT_800 (13)
> /*
> * MMC device
> */
> --
> 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] ARM: exynos4: Fix for stall in case of cpu hotplug or sleep
On Thu, Dec 1, 2011 at 4:05 PM, Kukjin Kim 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
>> Tested-by: Inderpal Singh
>> ---
>> 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)
[] (unwind_backtrace+0x0/0xfc) from []
(__rcu_pending+0x45c/0x4d8)
[] (__rcu_pending+0x45c/0x4d8) from []
(rcu_check_callbacks+0xb0/0x210)
[] (rcu_check_callbacks+0xb0/0x210) from []
(update_process_times+0x3c/0x50)
[] (update_process_times+0x3c/0x50) from []
(tick_sched_timer+0x94/0xd0)
[] (tick_sched_timer+0x94/0xd0) from []
(__run_hrtimer+0x44/0xd8)
[] (__run_hrtimer+0x44/0xd8) from []
(hrtimer_interrupt+0x100/0x330)
[] (hrtimer_interrupt+0x100/0x330) from []
(exynos4_mct_tick_isr+0x50/0x68)
[] (exynos4_mct_tick_isr+0x50/0x68) from []
(handle_irq_event_percpu+0x54/0x180)
[] (handle_irq_event_percpu+0x54/0x180) from []
(handle_irq_event+0x3c/0x5c)
[] (handle_irq_event+0x3c/0x5c) from []
(handle_fasteoi_irq+0x9c/0x104)
[] (handle_fasteoi_irq+0x9c/0x104) from []
(generic_handle_irq+0x34/0x3c)
[] (generic_handle_irq+0x34/0x3c) from []
(handle_IRQ+0x58/0xb8)
[] (handle_IRQ+0x58/0xb8) from [] (__irq_svc+0x6c/0xe8)
[] (__irq_svc+0x6c/0xe8) from []
(exynos4_enter_idle+0x2c/0x60)
[] (exynos4_enter_idle+0x2c/0x60) from []
(cpuidle_idle_call+0xb8/0x12c)
[] (cpuidle_idle_call+0xb8/0x12c) from []
(cpu_idle+0xac/0xf4)
[] (cpu_idle+0xac/0xf4) from [] (start_kernel+0x36c/0x378)
INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0,
t=12002 jiffies)
[] (unwind_backtrace+0x0/0xfc) from []
(__rcu_pending+0x45c/0x4d8)
[] (__rcu_pending+0x45c/0x4d8) from []
(rcu_check_callbacks+0x14c/0x210)
[] (rcu_check_callbacks+0x14c/0x210) from []
(update_process_times+0x3c/0x50)
[] (update_process_times+0x3c/0x50) from []
(tick_sched_timer+0x94/0xd0)
[] (tick_sched_timer+0x94/0xd0) from []
(__run_hrtimer+0x44/0xd8)
[] (__run_hrtimer+0x44/0xd8) from []
(hrtimer_interrupt+0x100/0x330)
[] (hrtimer_interrupt+0x100/0x330) from []
(exynos4_mct_tick_isr+0x50/0x68)
[] (exynos4_mct_tick_isr+0x50/0x68) from []
(handle_irq_event_percpu+0x54/0x180)
[] (handle_irq_event_percpu+0x54/0x180) from []
(handle_irq_event+0x3c/0x5c)
[] (handle_irq_event+0x3c/0x5c) from []
(handle_fasteoi_irq+0x9c/0x104)
[] (handle_fasteoi_irq+0x9c/0x104) from []
(generic_handle_irq+0x34/0x3c)
[] (generic_handle_irq+0x34/0x3c) from []
(handle_IRQ+0x58/0xb8)
[] (handle_IRQ+0x58/0xb8) from [] (__irq_svc+0x6c/0xe8)
[] (__irq_svc+0x6c/0xe8) from []
(exynos4_enter_idle+0x2c/0x60)
[] (exynos4_enter_idle+0x2c/0x60) from []
(cpuidle_idle_call+0xb8/0x12c)
[] (cpuidle_idle_call+0xb8/0x12c) from []
(cpu_idle+0xac/0xf4)
[] (cpu_idle+0xac/0xf4) from [] (start_kernel+0x36c/0x378)
Thanks,
Amit Daniel
>
>> else
>> disable_percpu_irq(IRQ_MCT_LOCALTIMER);
>> }
>> --
>> 1.7.1
>
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , 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 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 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 . > > 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 1/6] ARM: exynos: Add AFTR mode cpuidle state on EXYNOS4210
On Thu, Nov 24, 2011 at 9:37 AM, Inderpal Singh
wrote:
> Hi Amit,
>
> On 22 November 2011 15:05, Amit Daniel Kachhap
> 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
>> Signed-off-by: Lorenzo Pieralisi
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> 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
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>>
>> #include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +
>> +#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 mod
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 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 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 wrote: > On Sat, Nov 5, 2011 at 2:03 AM, wrote: >> From: Amit Daniel Kachhap >> >> 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 >> Signed-off-by: Lorenzo Pieralisi >> Signed-off-by: Amit Daniel Kachhap >> --- > [] >> +#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 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
>> Signed-off-by: Lorenzo Pieralisi
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> 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
>> #include
>> #include
>> +#include
>
> 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
>> -
>> +#include
>> +#include
>> #include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +
>> +#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);
>> +
>> +
Re: [PATCH 4/4] ARM: exynos4: remove useless code to save/restore L2 and GIC state
On 4 November 2011 23:03, Sylwester Nawrocki wrote:
> On 11/04/2011 06:03 PM, amit.kach...@linaro.org wrote:
>> From: Amit Daniel Kachhap
>>
>> 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
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> 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),
>
>
> This list is not complete anyway, some peripheral devices interrupts do not
> work after resume from system suspend to RAM.
> Is there any code already handling GIC state during system suspend/resume
> cycles?
> Or you refer to some upcoming patches ?
In my next patch series I have left the GIC save/restore from platform code.
>
> --
> 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
[PATCH 3/4] ARM: exynos4: add L2 early resume code
From: Amit Daniel Kachhap
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
Signed-off-by: Amit Daniel Kachhap
---
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
#include
+#include
#include
#include
@@ -31,6 +32,7 @@
#include
#include
+#include
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
+#include
+#include
.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
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
Signed-off-by: Amit Daniel Kachhap
---
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)
exynos4_scu_enable(S5P_VA_SCU);
-#ifdef CONFIG_CACHE_L2X0
- s3c_pm_do_restore_core(exynos4_l2c
[PATCH 2/4] ARM: exynos4: remove useless churn in sleep.S
From: Lorenzo Pieralisi This patch cleans up sleep code in preparation for L2 resume code and hotplug functions Signed-off-by: Lorenzo Pieralisi --- 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 -#include -#include .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 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state
From: Amit Daniel Kachhap
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
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Amit Daniel Kachhap
---
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
#include
#include
+#include
#include
-
+#include
+#include
#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#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;
+ __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 - befor
[PATCH 0/4]ARM: exynos4: Add l2 retention mode cpuidle state
From: Amit Daniel Kachhap 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 . 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
Re: [RFC PATCH 2/4] ARM: EXYNOS4: Fix to work with origen boards.
On 19 August 2011 19:29, Kyungmin Park wrote:
> On Fri, Aug 19, 2011 at 10:09 PM, Amit Daniel Kachhap
> wrote:
>> This adds a function to get the revision id.
>>
>> Signed-off-by: Jaecheol Lee
>> Signed-off-by: Changhwan Youn
>> ---
>> 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: [RFC PATCH 3/4] ARM: EXYNOS4: Add support AFTR mode cpuidle state on EXYNOS4210
On 21 August 2011 22:48, Russell King - ARM Linux
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: [PATCH] I2C: Samsung: Add support for PM_runtime in the I2C driver.
On Mon, Mar 28, 2011 at 4:41 AM, Ben Dooks 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
>> ---
>> 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
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -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
