RE: [PATCH v2] thermal: consistently use int for temperatures
As the original patch has not been in upstream, I'd prefer a refreshed patch,
rather than an incremental fix.
Thanks,
rui
> -Original Message-
> From: Sascha Hauer [mailto:s.ha...@pengutronix.de]
> Sent: Thursday, July 23, 2015 6:38 PM
> To: Zhang, Rui
> Cc: Punit Agrawal; linux...@vger.kernel.org; Eduardo Valentin; linux-
> ker...@vger.kernel.org; Jean Delvare; Peter Feuerer; Heiko Stuebner;
> Lukasz Majewski; Stephen Warren; Thierry Reding; linux-
> a...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-o...@vger.kernel.org; linux-samsung-
> s...@vger.kernel.org; Guenter Roeck; Rafael J. Wysocki; Maxime Ripard;
> Darren Hart; lm-sens...@lm-sensors.org
> Subject: Re: [PATCH v2] thermal: consistently use int for temperatures
> Importance: High
>
> Hi Zhang,
>
> On Tue, Jul 21, 2015 at 01:35:31PM +, Zhang, Rui wrote:
> > > >
> > Patch applied.
>
> Thanks for applying. I missed to convert another place, so we get a new
> compiler warning. The attached patch fixes this (suitable for git rebase --
> autosquash). Please let me know if you can handle this or if you prefer a new
> patch instead.
>
> Thanks
> Sascha
>
>
> -8<-
>
> From 4907a7c32fd16eaf9f31d9f904276c9a0176b717 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer
> Date: Thu, 23 Jul 2015 12:32:31 +0200
> Subject: [PATCH] fixup! thermal: consistently use int for temperatures
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> fixes:
> drivers/power/charger-manager.c: In function
> ‘cm_get_battery_temperature’:
> drivers/power/charger-manager.c:622:45: warning: passing argument 2 of
> ‘thermal_zone_get_temp’ from incompatible pointer type
>ret = thermal_zone_get_temp(cm->tzd_batt, (unsigned long *)temp);
>
> Signed-off-by: Sascha Hauer
> ---
> drivers/power/charger-manager.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-
> manager.c index 1c202cc..907293e 100644
> --- a/drivers/power/charger-manager.c
> +++ b/drivers/power/charger-manager.c
> @@ -619,7 +619,7 @@ static int cm_get_battery_temperature(struct
> charger_manager *cm,
>
> #ifdef CONFIG_THERMAL
> if (cm->tzd_batt) {
> - ret = thermal_zone_get_temp(cm->tzd_batt, (unsigned long
> *)temp);
> + ret = thermal_zone_get_temp(cm->tzd_batt, temp);
> if (!ret)
> /* Calibrate temperature unit */
> *temp /= 100;
> --
> 2.1.4
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
RE: [PATCH v2] thermal: consistently use int for temperatures
> -Original Message- > From: Punit Agrawal [mailto:punit.agra...@arm.com] > Sent: Tuesday, July 21, 2015 6:52 PM > To: Sascha Hauer > Cc: linux...@vger.kernel.org; Zhang, Rui; Eduardo Valentin; linux- > ker...@vger.kernel.org; Jean Delvare; Peter Feuerer; Heiko Stuebner; > Lukasz Majewski; Stephen Warren; Thierry Reding; linux- > a...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-o...@vger.kernel.org; linux-samsung- > s...@vger.kernel.org; Guenter Roeck; Rafael J. Wysocki; Maxime Ripard; > Darren Hart; lm-sens...@lm-sensors.org > Subject: Re: [PATCH v2] thermal: consistently use int for temperatures > Importance: High > > Hi Sascha, > > Sascha Hauer writes: > > > The thermal code uses int, long and unsigned long for temperatures in > > different places. > > > > Using an unsigned type limits the thermal framework to positive > > temperatures without need. Also several drivers currently will report > > temperatures near UINT_MAX for temperatures below 0°C. This will > > probably immediately shut the machine down due to overtemperature if > > started below 0°C. > > > > 'long' is 64bit on several architectures. This is not needed since > > INT_MAX °mC is above the melting point of all known materials. > > > > Consistently use a plain 'int' for temperatures throughout the thermal > > code and the drivers. This only changes the places in the drivers > > where the temperature is passed around as pointer, when drivers > > internally use another type this is not changed. > > > > Signed-off-by: Sascha Hauer > > Acked-by: Geert Uytterhoeven > > Reviewed-by: Jean Delvare > > Reviewed-by: Lukasz Majewski > > Reviewed-by: Darren Hart > > Reviewed-by: Heiko Stuebner > > Reviewed-by: Peter Feuerer > > Cc: Punit Agrawal > > The changes below look good. > > For the power_allocator governor and corresponding trace events, > > Reviewed-by: Punit Agrawal > > Thanks > > > Cc: Zhang Rui > > Cc: Eduardo Valentin > > Cc: linux...@vger.kernel.org > > Cc: linux-ker...@vger.kernel.org > > Cc: Jean Delvare > > Cc: Peter Feuerer > > Cc: Heiko Stuebner > > Cc: Lukasz Majewski > > Cc: Stephen Warren > > Cc: Thierry Reding > > Cc: linux-a...@vger.kernel.org > > Cc: platform-driver-...@vger.kernel.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: linux-o...@vger.kernel.org > > Cc: linux-samsung-soc@vger.kernel.org > > Cc: Guenter Roeck > > Cc: Rafael J. Wysocki > > Cc: Maxime Ripard > > Cc: Darren Hart > > Cc: lm-sens...@lm-sensors.org > > --- > > Patch applied. Thanks, rui > > changes since v1: > > - Add missing pieces for power_allocator driver > > > > drivers/acpi/thermal.c | 12 +- > > drivers/hwmon/lm75.c | 2 +- > > drivers/hwmon/ntc_thermistor.c | 2 +- > > drivers/hwmon/tmp102.c | 2 +- > > drivers/input/touchscreen/sun4i-ts.c | 8 +++ > > drivers/platform/x86/acerhdf.c | 9 > > drivers/platform/x86/intel_mid_thermal.c | 9 > > drivers/power/power_supply_core.c | 2 +- > > drivers/thermal/armada_thermal.c | 2 +- > > drivers/thermal/db8500_thermal.c | 7 +++--- > > drivers/thermal/dove_thermal.c | 2 +- > > drivers/thermal/fair_share.c | 2 +- > > drivers/thermal/gov_bang_bang.c| 5 ++-- > > drivers/thermal/hisi_thermal.c | 4 ++-- > > drivers/thermal/imx_thermal.c | 27 > > +++--- > > drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +- > > .../thermal/int340x_thermal/int340x_thermal_zone.c | 10 > > .../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++ > > .../int340x_thermal/processor_thermal_device.c | 4 ++-- > > drivers/thermal/intel_quark_dts_thermal.c | 13 +-- > > drivers/thermal/intel_soc_dts_iosf.c | 8 +++ > > drivers/thermal/kirkwood_thermal.c | 2 +- > > drivers/thermal/of-thermal.c | 14 +-- > > drivers/thermal/power_allocator.c | 16 ++--- > > drivers/thermal/qcom-spmi-temp-alarm.c | 2 +- > > drivers/thermal/rcar_thermal.c | 7 +++-
Re: [RESEND PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
On Fri, 2014-07-18 at 09:00 +0900, Chanwoo Choi wrote:
> This patch adds the registers, bit fields and compatible strings
> required to support for the 1 TMU channels on Exynos3250.
>
> Signed-off-by: Chanwoo Choi
> [Add MUX address setting bits by Jonghwa Lee]
> Signed-off-by: Jonghwa Lee
> Acked-by: Kyungmin Park
> Reviewed-by: Amit Daniel Kachhap
Eduardo and Amit,
do you have any comments on this?
thanks,
rui
> ---
> .../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 d7ca9f4..a2a08ea 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -505,6 +505,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,
> },
> @@ -677,7 +681,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
> goto err_clk_sec;
> }
>
> - if (pdata->type == SOC_ARCH_EXYNOS4210 ||
> + if (pdata->type == SOC_ARCH_EXYNOS3250 ||
> + pdata->type == SOC_ARCH_EXYNOS4210 ||
> pdata->type == SOC_ARCH_EXYNOS4412 ||
> pdata->type == SOC_ARCH_EXYNOS5250 ||
> pdata->type == SOC_ARCH_EXYNOS5260 ||
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index edd08cf..1b4a644 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -40,7 +40,8 @@ enum calibration_mode {
> };
>
> enum soc_type {
> - SOC_ARCH_EXYNOS4210 = 1,
> + SOC_ARCH_EXYNOS3250 = 1,
> + SOC_ARCH_EXYNOS4210,
> SOC_ARCH_EXYNOS4412,
> SOC_ARCH_EXYNOS5250,
> SOC_ARCH_EXYNOS5260,
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index c1d81dc..aa8e0de 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
> exynos4210_default_tmu_data = {
> };
> #endif
>
> +#if defined(CONFIG_SOC_EXYNOS3250)
> +static const struct exynos_tmu_registers exynos3250_tmu_registers = {
> + .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> + .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> + .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> + .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> + .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> + .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> + .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
> + .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
> + .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
> + .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
> + .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
> + .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
> + .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
> + .tmu_status = EXYNOS_TMU_REG_STATUS,
> + .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
> + .threshold_th0 = EXYNOS_THD_TEMP_RISE,
> + .threshold_th1 = EXYNOS_THD_TEMP_FALL,
> + .tmu_inten = EXYNOS_TMU_REG_INTEN,
> + .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
> + .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
> + .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
> + .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
> + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
> + .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
> + .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
> + .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
> + .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
> + .intclr_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
> + .emul_con = EXYNOS_EMUL_CON,
> + .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
> + .emul_time_sh
Re: [PATCH v2 0/9] thermal: exynos: various cleanups
Eduardo, what do you think of this patch set? thanks, rui On Tue, 2014-06-17 at 19:27 +0200, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series contains various cleanups for EXYNOS thermal > driver. Overall it decreases driver's LOC by 12%. It is based > on next-20140617 kernel. It should not cause any functionality > changes. > > Changes since v1: > - synced patches against next-20140617 > - merged patch "thermal: exynos: remove unused defines" into > "thermal: exynos: remove unused struct exynos_tmu_registers > entries" one (per request from Eduardo) > - improved patch descriptions for patches #1-5 > - fixed documentation for pdata->gain and pdata->reference_voltage > - added Reviewed-by from Amit to patches #6, #7 and #10 > - added missing Acked-by from Kyungmin Park > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > > Bartlomiej Zolnierkiewicz (9): > thermal: exynos: remove unused struct exynos_tmu_registers entries > 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| 90 +--- > drivers/thermal/samsung/exynos_tmu_data.c | 64 + > drivers/thermal/samsung/exynos_tmu_data.h | 33 + > 5 files changed, 41 insertions(+), 328 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
Re: [PATCH 00/10] thermal: exynos: various cleanups
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 > 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-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 四, 2014-04-24 at 11:48 +0530, Amit Kachhap wrote:
> 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
applied.
thanks,
rui
>
> >
> > 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 v12 7/7] thermal:exynos:boost: Automatic enable/disable of BOOST feature (at Exynos4412)
On Fri, 2013-12-20 at 15:24 +0100, Lukasz Majewski wrote:
> This patch provides auto disable/enable operation for boost. It uses already
> present thermal infrastructure to provide BOOST hysteresis.
> The TMU data has been modified to work properly with or without BOOST.
> Hence, the two first trip points with corresponding clip frequencies were
> adjusted.
>
> The first one was reduced from 85 to 70 degrees and clip frequency was
> increased to 1.4 GHz from 800 MHz. This trip point is in fact responsible
> for providing BOOST hysteresis. When temperature exceeds 70 deg, the maximal
> non BOOST frequency for Exynos4412 is imposed.
>
> Since the first trigger level has been "stolen" for BOOST, the second one
> needs to be a compromise for the previously used two for non BOOST
> configuration. The 95 deg with modified clip freq (to 400 MHz) shall provide
> a good balance between cooling down the overheated device and throughput on
> an acceptable level.
>
> Two last trigger levels were not modified since, they cause platform shutdown
> on emergency overheat situation.
> Third trip point passage results in SW managed shut down of the system.
> If the last trip point is crossed, the PMU HW generates the power off
> signal.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Myungjoo Ham
> Acked-by: Eduardo Valentin
Reviewed-by: Zhang Rui
thanks,
rui
>
> ---
> Changes for v12:
> - More verbose patch description to explain new TMU temperature assignment
> for Exynos4412
>
> Changes for v11:
> - Use only one thermal data set
> - Adjust Exynos4412 thermal data to work with or without BOOST
>
> Changes for v10:
> - Remove boost related code from thermal_core.c
> - Use already present thermal infrastructure to provide thermal hysteresis
> - Introduce special set of TMU data for BOOST
>
> Changes for v9:
> - None
>
> Changes for v8:
> - Move cpufreq_boost_* stub functions definition (needed when cpufreq
> is not compiled in) to cpufreq.h at cpufreq core support commit
>
> Changes for v7:
> - None
>
> Changes for v6:
> - Disable boost only when supported and enabled
> - Protect boost related thermal_zone_device struct fields with mutex
> - Evaluate temperature trend during boost enable decision
> - Create separate methods to handle boost enable/disable
> (thermal_boost_{enable|disable}) operations
> - Boost is disabled at any trip point passage (not only the non critical
> one)
> - Add stub definitions for cpufreq boost functions used when
> CONFIG_CPU_FREQ is NOT defined.
>
> Changes for v5:
> - Move boost disable code from cpu_cooling.c to thermal_core.c
> (to handle_non_critical_trips)
> - Extent struct thermal_zone_device by adding overheated bool flag
> - Implement auto enable of boost after device cools down
> - Introduce boost_polling flag, which indicates if thermal uses it's
> predefined
> pool delay or has woken up thermal workqueue only to wait until device
> cools down.
>
> Changes for v4:
> - New patch
>
> drivers/thermal/samsung/exynos_tmu_data.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index 073c292..476b768 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -131,8 +131,8 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
>
> #define EXYNOS4412_TMU_DATA \
> .threshold_falling = 10, \
> - .trigger_levels[0] = 85, \
> - .trigger_levels[1] = 103, \
> + .trigger_levels[0] = 70, \
> + .trigger_levels[1] = 95, \
> .trigger_levels[2] = 110, \
> .trigger_levels[3] = 120, \
> .trigger_enable[0] = true, \
> @@ -155,12 +155,12 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .second_point_trim = 85, \
> .default_temp_offset = 50, \
> .freq_tab[0] = { \
> - .freq_clip_max = 800 * 1000, \
> - .temp_level = 85, \
> + .freq_clip_max = 1400 * 1000, \
> + .temp_level = 70, \
> }, \
> .freq_tab[1] = { \
> - .freq_clip_max = 200 * 1000, \
> - .temp_level = 103, \
> + .freq_clip_max = 400 * 1000, \
> + .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> .registers = &exynos4412_tmu_registers, \
--
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 v12 0/7] cpufreq:boost: CPU Boost mode support
On Wed, 2014-01-08 at 01:35 +0100, Rafael J. Wysocki wrote: > On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote: > > Hi Rafael, > > Hi, > > > > This patch series introduces support for CPU overclocking technique > > > called Boost. > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > component: > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > > > software oriented one (like the one done at Exynos). > > > For this reason cpufreq/freq_table code has been reorganized to > > > include common code. > > > > > > Important design decisions: > > > - Boost related code is compiled-in unconditionally to cpufreq core > > > and disabled by default. The cpufreq_driver is responsibile for > > > setting boost_supported flag and providing set_boost callback(if HW > > > support is needed). For software managed boost, special Kconfig flag - > > > CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only > > > when a target platform has thermal framework properly configured. > > > > > > - struct cpufreq_driver has been extended with boost related fields: > > > -- boost_supported - when driver supports boosting > > > -- boost_enabled - boost state > > > -- set_boost - callback to function, which is necessary to > > >enable/disable boost > > > > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is > > > visible _only_ when cpufreq driver supports Boost. > > > > > > - No special spin_lock for Boost was created. The one from cpufreq > > > core was reused. > > > > > > - The Boost code doesn't rely on any policy. When boost state is > > > changed, then the policy list is iterated and proper adjustements are > > > done. > > > > > > - To improve safety level, the thermal framework is also extended to > > > disable software boosting, when thermal trip point is reached. After > > > cooling down the boost can be enabled again. This emulates behaviour > > > similar to HW managed boost (like x86) > > > > > > Tested at HW: > > >Exynos 4412 3.13-rc4 Linux > > >Intel Core i7-3770 3.13-rc4 Linux > > > > > > Above patches were posted on top of kernel_pm/bleeding-edge > > > (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) > > > > > > Lukasz Majewski (7): > > > cpufreq: Add boost frequency support in core > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common > > > boost solution > > > cpufreq:boost:Kconfig: Provide support for software managed BOOST > > > cpufreq:exynos:Extend Exynos cpufreq driver to support boost > > > framework > > > Documentation:cpufreq:boost: Update BOOST documentation > > > cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ > > > thermal:exynos:boost: Automatic enable/disable of BOOST feature (at > > > Exynos4412) > > > > > > Documentation/cpu-freq/boost.txt | 26 +++ > > > drivers/cpufreq/Kconfig |4 + > > > drivers/cpufreq/Kconfig.arm | 15 > > > drivers/cpufreq/acpi-cpufreq.c| 86 > > > +++-- drivers/cpufreq/cpufreq.c | > > > 118 - > > > drivers/cpufreq/exynos-cpufreq.c |3 + > > > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > > > drivers/cpufreq/freq_table.c | 56 -- > > > drivers/thermal/samsung/exynos_tmu_data.c | 12 +-- > > > include/linux/cpufreq.h | 24 ++ 10 files > > > changed, 261 insertions(+), 85 deletions(-) > > > > > > > A gentle ping about BOOST patches. > > > > Its been already acked by Viresh and Eduardo. > > > > It applies on kernel_pm/bleeding_edge SHA1: > > 4836deb72c5e2a9af0cb2129c1149783a26d99ab > > It looks like Rui is still looking into this. > > Rui, are you fine with this series? > Yes, I'm okay with the thermal related parts of this patch set. thanks, rui > Rafael > -- 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: handle gate clock for misplaced TRIMINFO register
On Thu, 2013-11-07 at 18:12 +0530, Naveen Krishna Chatradhi wrote:
> On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
> the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
> should be acompanied by enabling the respective clock.
>
> This patch which allow for a "clk_sec" clock to be specified in the
> device-tree which will be ungated when accessing the TRIMINFO register.
>
> Signed-off-by: Andrew Bresticker
> Signed-off-by: Naveen Krishna Chatradhi
Eduardo,
what do you think of this patch?
thanks,
rui
> ---
> drivers/thermal/samsung/exynos_tmu.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index b54825a..33edd1a 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -47,6 +47,7 @@
> * @irq_work: pointer to the irq work structure.
> * @lock: lock to implement synchronization.
> * @clk: pointer to the clock structure.
> + * @clk_sec: pointer to the clock structure for accessing the base_second.
> * @temp_error1: fused value of the first point trim.
> * @temp_error2: fused value of the second point trim.
> * @regulator: pointer to the TMU regulator structure.
> @@ -61,7 +62,7 @@ struct exynos_tmu_data {
> enum soc_type soc;
> struct work_struct irq_work;
> struct mutex lock;
> - struct clk *clk;
> + struct clk *clk, *clk_sec;
> u8 temp_error1, temp_error2;
> struct regulator *regulator;
> struct thermal_sensor_conf *reg_conf;
> @@ -152,6 +153,8 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
>
> mutex_lock(&data->lock);
> clk_enable(data->clk);
> + if (!IS_ERR(data->clk_sec))
> + clk_enable(data->clk_sec);
>
> if (TMU_SUPPORTS(pdata, READY_STATUS)) {
> status = readb(data->base + reg->tmu_status);
> @@ -306,6 +309,8 @@ skip_calib_data:
> out:
> clk_disable(data->clk);
> mutex_unlock(&data->lock);
> + if (!IS_ERR(data->clk_sec))
> + clk_disable(data->clk_sec);
>
> return ret;
> }
> @@ -457,12 +462,16 @@ static void exynos_tmu_work(struct work_struct *work)
> const struct exynos_tmu_registers *reg = pdata->registers;
> unsigned int val_irq, val_type;
>
> + if (!IS_ERR(data->clk_sec))
> + clk_enable(data->clk_sec);
> /* Find which sensor generated this interrupt */
> if (reg->tmu_irqstatus) {
> val_type = readl(data->base_second + reg->tmu_irqstatus);
> if (!((val_type >> data->id) & 0x1))
> goto out;
> }
> + if (!IS_ERR(data->clk_sec))
> + clk_disable(data->clk_sec);
>
> exynos_report_trigger(data->reg_conf);
> mutex_lock(&data->lock);
> @@ -641,6 +650,15 @@ static int exynos_tmu_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + data->clk_sec = devm_clk_get(&pdev->dev, "tmu_apbif_sec");
> + if (!IS_ERR(data->clk_sec)) {
> + ret = clk_prepare(data->clk_sec);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to get clock\n");
> + return PTR_ERR(data->clk_sec);
> + }
> + }
> +
> if (pdata->type == SOC_ARCH_EXYNOS4210 ||
> pdata->type == SOC_ARCH_EXYNOS4412 ||
> pdata->type == SOC_ARCH_EXYNOS5250 ||
> @@ -713,6 +731,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
> return 0;
> err_clk:
> clk_unprepare(data->clk);
> + if (!IS_ERR(data->clk_sec))
> + clk_unprepare(data->clk_sec);
> return ret;
> }
>
> @@ -725,6 +745,8 @@ static int exynos_tmu_remove(struct platform_device *pdev)
> exynos_unregister_thermal(data->reg_conf);
>
> clk_unprepare(data->clk);
> + if (!IS_ERR(data->clk_sec))
> + clk_unprepare(data->clk_sec);
>
> if (!IS_ERR(data->regulator))
> regulator_disable(data->regulator);
--
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 v12 1/4] thermal: samsung: replace inten_ bit fields with intclr_
On Thu, 2013-12-19 at 11:35 +0530, Naveen Krishna Chatradhi wrote:
> This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
> with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
> Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
> to configure intclr related registers.
>
> Description of H/W:
> The offset for the bits in the CLEAR register are not consistent across TMU
> modules in Exynso5250, 5420 and 5440.
>
> On Exynos5250, the FALL interrupt related en, status and clear bits are
> available at an offset of
> 16 in INTEN, INTSTAT registers and at an offset of
> 12 in INTCLEAR register.
>
> On Exynos5420, the FALL interrupt related en, status and clear bits are
> available at an offset of
> 16 in INTEN, INTSTAT and INTCLEAR registers.
>
> On Exynos5440,
> the FALL_IRQEN bits are at an offset of 4
> and the RISE_IRQEN bits are at an offset of 0
>
> Signed-off-by: Naveen Krishna Chatradhi
> Acked-by: Amit Daniel Kachhap
> Reviewed-by: Bartlomiej Zolnierkiewicz
> Reviewed-by: Tomasz Figa
Eduardo,
what do you think of this patch set?
thanks,
rui
> ---
> Changes since v11:
> Added Reviewed by Tomasz
>
> Changes since v10:
> None
>
> drivers/thermal/samsung/exynos_tmu.c |6 +++---
> drivers/thermal/samsung/exynos_tmu.h | 16
> drivers/thermal/samsung/exynos_tmu_data.c | 18 +-
> drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
> 4 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 32f38b9..c493245 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -237,7 +237,7 @@ skip_calib_data:
> 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);
> + writel(reg->intclr_rise_mask, data->base + reg->tmu_intclear);
> } else {
> /* Write temperature code for rising and falling threshold */
> for (i = 0;
> @@ -264,8 +264,8 @@ skip_calib_data:
> writel(falling_threshold,
> data->base + reg->threshold_th1);
>
> - writel((reg->inten_rise_mask << reg->inten_rise_shift) |
> - (reg->inten_fall_mask << reg->inten_fall_shift),
> + writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
> + (reg->intclr_fall_mask << reg->intclr_fall_shift),
> data->base + reg->tmu_intclear);
>
> /* if last threshold limit is also present */
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index 3fb6554..980859a 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -122,10 +122,6 @@ enum soc_type {
> * @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
> * @tmu_inten: register containing the different threshold interrupt
> enable bits.
> - * @inten_rise_shift: shift bits of all rising interrupt bits.
> - * @inten_rise_mask: mask bits of all rising interrupt bits.
> - * @inten_fall_shift: shift bits of all rising interrupt bits.
> - * @inten_fall_mask: mask bits of all rising interrupt bits.
> * @inten_rise0_shift: shift bits of rising 0 interrupt bits.
> * @inten_rise1_shift: shift bits of rising 1 interrupt bits.
> * @inten_rise2_shift: shift bits of rising 2 interrupt bits.
> @@ -136,6 +132,10 @@ enum soc_type {
> * @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.
> + * @intclr_fall_shift: shift bits for interrupt clear fall 0
> + * @intclr_rise_shift: shift bits of all rising interrupt bits.
> + * @intclr_rise_mask: mask bits of all rising interrupt bits.
> + * @intclr_fall_mask: mask bits of all rising interrupt bits.
> * @emul_con: TMU emulation controller register.
> * @emul_temp_shift: shift bits of emulation temperature.
> * @emul_time_shift: shift bits of emulation time.
> @@ -191,10 +191,6 @@ struct exynos_tmu_registers {
> u32 threshold_th3_l0_shift;
>
> u32 tmu_inten;
> - u32 inten_rise_shift;
> - u32 inten_rise_mask;
> - u32 inten_fall_shift;
> - u32 inten_fall_mask;
> u32 inten_rise0_shift;
> u32 inten_rise1_shift;
> u32 inten_rise2_shift;
> @@ -207,6 +203,10 @@ struct exynos_tmu_registers {
> u32 tmu_intstat;
>
> u32 tmu_intclear;
> + u32 intclr_fall_shift;
> + u32 intclr_rise_shift;
> + u32 intclr_fall_mask;
> + u32 intclr_rise_mask;
>
> u32 emul_con;
Re: [PATCH] thermal:samsung: fix compilation warning
On Fri, 2013-12-20 at 17:42 +0530, Naveen Krishna Chatradhi wrote:
> This patch fixes a compilation warning.
>
> warning: passing argument 5 of 'thermal_zone_device_register' discards 'const'
> qualifier from pointer target type [enabled by default]
> include/linux/thermal.h:270:29: note: expected 'struct
> thermal_zone_device_ops *'
> but argument is of type 'const struct thermal_zone_device_ops *'
>
> Signed-off-by: Naveen Krishna Chatradhi
applied.
thanks,
rui
> ---
> drivers/thermal/samsung/exynos_thermal_common.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index c2301da..3f5ad25 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -280,7 +280,7 @@ static int exynos_get_trend(struct thermal_zone_device
> *thermal,
> return 0;
> }
> /* Operation callback functions for thermal zone */
> -static struct thermal_zone_device_ops const exynos_dev_ops = {
> +static struct thermal_zone_device_ops exynos_dev_ops = {
> .bind = exynos_bind,
> .unbind = exynos_unbind,
> .get_temp = exynos_get_temp,
--
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 23/25] thermal: exynos: fix error return code
On Sun, 2013-12-29 at 23:47 +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> Set the return variable to an error code as done elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> //
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
>
> //
>
> Signed-off-by: Julia Lawall
applied.
thanks,
rui
>
> ---
> Not tested.
>
> drivers/thermal/samsung/exynos_tmu.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 32f38b9..0d96a51 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -205,6 +205,7 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> skip_calib_data:
> if (pdata->max_trigger_level > MAX_THRESHOLD_LEVS) {
> dev_err(&pdev->dev, "Invalid max trigger level\n");
> + ret = -EINVAL;
> goto out;
> }
>
>
--
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 0/5] thermal: exynos: Fixes for v3.12
Eduardo, What's your opinion on this patch set? BTW, please send me all the urgent fixes for thermal soc drivers that you think should go to 3.12. Thanks, rui > -Original Message- > From: Lukasz Majewski [mailto:l.majew...@samsung.com] > Sent: Monday, October 14, 2013 1:47 PM > To: Zhang, Rui; Eduardo Valentin; kgene@samsung.com > Cc: Lukasz Majewski; Linux PM list; Lukasz Majewski; linux-kernel; > Bartlomiej Zolnierkiewicz; devicet...@vger.kernel.org; Amit Daniel > Kachhap; linux-samsung-soc@vger.kernel.org > Subject: Re: [PATCH v2 0/5] thermal: exynos: Fixes for v3.12 > Importance: High > > Hi Zhang, Eduardo, > > > This patch series is divided into two parts: > > 1. Device tree node definition and enabelement for TMU at Exynos4412 > > (Trats2) 2. Exynos thermal subsystem regressions for v3.12-rc4. > > Several commits were necessary to properly fix regression for TMU > test > > MUX address setting after reset. > > > > Test HW: > > - Exynos4412 - TRATS2 board (Linux v3.12-rc4) > > SHA1: 8b5ede69d24db939f52b47e2f6fe1e83e08b > > > > > > Lukasz Majewski (5): > > thermal: exynos: Remove check for thermal device pointer at > > exynos_report_trigger() > > thermal: exynos: Provide separate TMU data for Exynos4412 > > thermal: exynos: Provide initial setting for TMU's test MUX address > > at Exynos4412 > > ARM: dts: exynos4x12: Device tree node definition for TMU on > > Exynos4x12 > > ARM: dts: exynos4412-trats2: Enable TMU support at Trats2 > > > > Zhang, Eduardo - any comments? > > Would it be possible to add them to v3.12 since they do fix critical > error and regression on Exynos4412. > > > > arch/arm/boot/dts/exynos4412-trats2.dts |5 > > arch/arm/boot/dts/exynos4x12.dtsi | 10 > > drivers/thermal/samsung/exynos_thermal_common.c |2 -- > > drivers/thermal/samsung/exynos_tmu.c| 12 ++--- > > drivers/thermal/samsung/exynos_tmu.h|7 +- > > drivers/thermal/samsung/exynos_tmu_data.c | 30 > > ++- > > drivers/thermal/samsung/exynos_tmu_data.h | 13 +- 7 > > files changed, 65 insertions(+), 14 deletions(-) > > > > > > -- > Best regards, > > Lukasz Majewski > > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional
On 二, 2013-08-27 at 23:17 +0200, Rafael J. Wysocki wrote:
> On Tuesday, August 27, 2013 02:26:41 PM Eduardo Valentin wrote:
> > On 23-08-2013 19:08, Rafael J. Wysocki wrote:
> > > On Friday, August 23, 2013 06:03:14 PM Eduardo Valentin wrote:
> > >> When registering a new thermal_device, the thermal framework
> > >> will always add a hwmon sysfs interface.
> > >>
> > >> This patch adds a flag to make this behavior optional. Now
> > >> when registering a new thermal device, the caller needs
> > >> to say if the hwmon interface is required.
> > >>
> > >> In order to keep same behavior as of today, all current
> > >> calls will by default create the hwmon interface.
> > >
> > > Well, instead of modifying all of the callers this way, why don't
> > > you add new versions taking the additional argument as, for example,
> > >
> > > thermal_zone_device_register_full()
> > >
> > > and redefine the old ones as static inline wrappers, for example
> > >
> > > static inline struct thermal_zone_device
> > > *thermal_zone_device_register(args)
> > > {
> > > return thermal_zone_device_register_full(args, true);
> > > }
> > >
> > > ?
> >
> > Yeah, that is another way to go and I thought of doing it like that. I
> > just could not come out with a good API naming:
> >
> > thermal_zone_device_register_full(all args)
> >
> > thermal_zone_device_register(args) /* on hwmon == true */
> > thermal_zone_device_register_no_hwmon(args) /* on hwmon == false */
> >
> > Would this sound reasonable naming?
>
> Yeah, sounds good to me.
>
Well, actually, Tianyu is working on a patch set to move all the
thermal_zone_device_register() parameters to struct thermal_zone_params.
But with that patch set done, what you need to do next is just to
introduce a new field in struct thermal_zone_params and make sure 0
means registering hwmon sysfs I/F.
thanks,
rui
> Thanks,
> Rafael
>
--
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_tmu: fix wrong error check for mapped memory
On 三, 2013-08-07 at 14:01 +0530, Naveen Krishna Chatradhi wrote:
> The error check is checking for a "base" mapped memory base
> instead of "base_common". Fixing the same.
>
> Signed-off-by: Naveen Krishna Chatradhi
applied. Thanks!
BTW, can you rebase the other three exynos patches you submitted?
thanks,
rui
> ---
> drivers/thermal/samsung/exynos_tmu.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index ec01dfe..a033dbb 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -592,7 +592,7 @@ static int exynos_map_dt_data(struct platform_device
> *pdev)
>
> data->base_common = devm_ioremap(&pdev->dev, res.start,
> resource_size(&res));
> - if (!data->base) {
> + if (!data->base_common) {
> dev_err(&pdev->dev, "Failed to ioremap memory\n");
> return -ENOMEM;
> }
--
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 V7 00/30] thermal: exynos: Re-structure driver and add support for exynos5440
> -Original Message- > From: amit.kach...@gmail.com [mailto:amit.kach...@gmail.com] On Behalf > Of amit daniel kachhap > Sent: Friday, June 28, 2013 1:20 PM > To: Zhang, Rui > Cc: Eduardo Valentin; Kukjin Kim; linux...@vger.kernel.org; linux- > samsung-...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH V7 00/30] thermal: exynos: Re-structure driver and > add support for exynos5440 > Importance: High > > On Tue, Jun 25, 2013 at 5:23 PM, amit daniel kachhap > wrote: > > On Tue, Jun 25, 2013 at 1:21 AM, Eduardo Valentin > > wrote: > >> On 24-06-2013 13:13, Kukjin Kim wrote: > >>> On 06/24/13 19:50, Amit Daniel Kachhap wrote: > >>>> Submitting V7 version with all comments fixed. Most of the patches > >>>> are acked by Eduardo. All the un-acked patches are modified > >>>> according to the review comments. > >>>> If any comments please let me know. > >>>> > >>>> Thanks, > >>>> Amit Daniel > >>>> > >>>> Changes in V7: > >>>> * Fixed all the coding guidelines comments given by Eduardo. > >>>> * Moved the request irq call below the core thermal registration > as > >>>> per discussion > >>>>with Eduardo. > >>>> * Appropriate logs/TODO's/comments added for some review comments > >>>> which are still > >>>>same as before, > >>>>1) calibration register setting still uses enums. > >>>>2) very few soc check's still left in the driver. > >>>>3) Cooling devices stored in an array in the exynos core > thermal > >>>> layer. > >>>> > >>>> Changes in V6: > >>>> * Uses ARCH_HAS_BANDGAP config flag which is merged now in arm > tree. > >>>> > (http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7758/1). > >>>> * In this version patches 1, 2, 3, 4 and 30 are modified. Others > >>>> are same as V5. > >>>> * Added acked by from Jonghwa Lee. > >>>> * Rebased against Thermal Maintainer next tree. > >>>> > >>>> Changes in V5: > >>>> * Most of the changes in this version is as per suggestion from > >>>> Jonghwa Lee. I > >>>> have retained one to one mapping of platform data with TMU > >>>> instances as the > >>>> TMU's are different devices. In exynos5440 soc there is some > register > >>>> sharing across multiple TMU's but in exynos5420 there is no > >>>> register between > >>>> multiple TMU's, so the current implementation is useful to > >>>> support both of the > >>>> above. > >>>> This patch uses localized ARCH_HAS_TMU Kconfig option and is a > >>>> temporary solution > >>>> until a more generic macro ARCH_HAS_BANDGAP is introduced as per > >>>> discussion in > >>>> the link https://patchwork.kernel.org/patch/2659001/. > >>>> * trip type is passed as platform data. > >>>> * HW trip is allowed only for maximum level. > >>>> * Platform data structure is now abstracted inside 1 more > structure > >>>> to support > >>>>multiple sensor TMU data. > >>>> > >>>> Changes in V4: > >>>> Almost all the changes in this version is as per suggestion from > >>>> Eduardo.The > >>>> major ones are listed below, > >>>> * Added kconfig symbol ARCH_HAS_TMU which needs to be enabled by > >>>> platform. With > >>>>this change existing symbol EXYNOS_TMU_DATA is not needed. > >>>> * Movement of freq_clip_table from exynos_tmu.h to > >>>> exynos_thermal_common.h is > >>>>explained in the commit logs. > >>>> * Wrote all register description documentation. > >>>> * Split 5440 TMU support patch into controller change, > >>>> configuration data and > >>>>feature addition patches. > >>>> * Remove all *LINUX_* in the header files. > >>>> * Still regulator enable is kept optional but a TODO: comment is > >>>> added to fix > >>>>it later. > >>>> > >>>> Changes in V3: > >>>> * Added proper dependency of different exynos thermal Kconfig > symbols. > >>>> Basically 3 > &
Re: [PATCH V3 02/21] thermal: exynos: Bifurcate exynos thermal common and tmu controller code
On Tue, 2013-05-07 at 18:30 +0530, Amit Daniel Kachhap wrote:
> This code bifurcates exynos thermal implementation into common and sensor
> specific parts. The common thermal code interacts with core thermal layer and
> core cpufreq cooling parts and is independent of SOC specific driver. This
> change is needed to cleanly add support for new TMU sensors.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Amit Daniel Kachhap
> ---
> drivers/thermal/samsung/Kconfig | 20 +-
> drivers/thermal/samsung/Makefile|4 +-
> drivers/thermal/samsung/exynos_thermal.c| 421
> +--
> drivers/thermal/samsung/exynos_thermal_common.c | 389 +
> drivers/thermal/samsung/exynos_thermal_common.h | 83 +
> 5 files changed, 498 insertions(+), 419 deletions(-)
> create mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
> create mode 100644 drivers/thermal/samsung/exynos_thermal_common.h
>
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> index 2d3d9dc..7857e20 100644
> --- a/drivers/thermal/samsung/Kconfig
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -1,9 +1,17 @@
> config EXYNOS_THERMAL
> - tristate "Temperature sensor on Samsung EXYNOS"
> + tristate "Exynos thermal management unit driver"
> depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
> - depends on CPU_THERMAL
> help
> - If you say yes here you get support for TMU (Thermal Management
> - Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
> - the exynos thermal driver with the core thermal layer and cpu
> - cooling API's.
> + If you say yes here you get support for the exynos thermal driver
> + for exynos4 and exynos5 soc. This driver initialises the TMU, reports
> + temperature and handles cooling action if defined. This driver uses
> + core thermal API's.
> +
> +config EXYNOS_THERMAL_CORE
> + bool "Core thermal framework support for EXYNOS SOC's"
> + 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 API's.
I'm still not quite clear what you want to get there.
If EXYNOS_THERMAL=y and EXYNOS_THERMAL_CORE=n, you'll get an Exynos tmu
driver which is not shown in /sys/class/thermal/ and can not be used for
thermal management?
thanks,
rui
> diff --git a/drivers/thermal/samsung/Makefile
> b/drivers/thermal/samsung/Makefile
> index 1fe6d93..6227d4f 100644
> --- a/drivers/thermal/samsung/Makefile
> +++ b/drivers/thermal/samsung/Makefile
> @@ -1,4 +1,6 @@
> #
> # Samsung thermal specific Makefile
> #
> -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> +obj-$(CONFIG_EXYNOS_THERMAL) += exynos_soc_thermal.o
> +exynos_soc_thermal-y := exynos_thermal.o
> +exynos_soc_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o
> diff --git a/drivers/thermal/samsung/exynos_thermal.c
> b/drivers/thermal/samsung/exynos_thermal.c
> index d20ce9e..4c85945 100644
> --- a/drivers/thermal/samsung/exynos_thermal.c
> +++ b/drivers/thermal/samsung/exynos_thermal.c
> @@ -21,23 +21,19 @@
> *
> */
>
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> #include
> -#include
> -#include
> -#include
> #include
> +#include
> +#include
> +#include
> +#include
> #include
> -#include
> -#include
> -#include
> -#include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include "exynos_thermal_common.h"
>
> /* Exynos generic registers */
> #define EXYNOS_TMU_REG_TRIMINFO 0x0
> @@ -88,16 +84,6 @@
> #define EFUSE_MIN_VALUE 40
> #define EFUSE_MAX_VALUE 100
>
> -/* In-kernel thermal framework related macros & definations */
> -#define SENSOR_NAME_LEN 16
> -#define MAX_TRIP_COUNT 8
> -#define MAX_COOLING_DEVICE 4
> -#define MAX_THRESHOLD_LEVS 4
> -
> -#define ACTIVE_INTERVAL 500
> -#define IDLE_INTERVAL 1
> -#define MCELSIUS 1000
> -
> #ifdef CONFIG_THERMAL_EMULATION
> #define EXYNOS_EMUL_TIME 0x57F0
> #define EXYNOS_EMUL_TIME_SHIFT 16
> @@ -106,17 +92,6 @@
> #define EXYNOS_EMUL_ENABLE 0x1
> #endif /* CONFIG_THERMAL_EMULATION */
>
> -/* CPU Zone information */
> -#define PANIC_ZONE 4
> -#define WARN_ZONE 3
> -#define MONITOR_ZONE2
> -#define SAFE_ZONE 1
> -
> -#define GET_ZONE(trip) (trip + 2)
> -#define GET_TRIP(zone) (zone - 2)
> -
> -#define EXYNOS_ZONE_COUNT3
> -
> struct exynos_tmu_data {
> struct exynos_tmu_platform_data *pdata;
> struct resource *mem;
> @@ -129,384 +104,6 @@ struct exynos_tmu_data {
> u8 temp_error1, temp_error2;
> };
>
> -struct thermal_trip_point_conf {
> - int trip_val[MAX_TRIP_COUNT];
> - int trip_count;
> - u8 trigg
Re: [PATCH V2 05/20] thermal: exynos: Bifurcate exynos tmu driver and configuration data
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote:
> This code splits the exynos tmu driver code into SOC specific data parts.
> This will simplify adding new SOC specific data to the same TMU controller.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Amit Daniel Kachhap
I'm okay with all the rest patches in this patch series.
thanks,
rui
> ---
> drivers/thermal/samsung/Makefile|1 +
> drivers/thermal/samsung/exynos_thermal_common.h |2 +-
> drivers/thermal/samsung/exynos_tmu.c| 67 +--
> drivers/thermal/samsung/exynos_tmu_data.c | 78
> +++
> drivers/thermal/samsung/exynos_tmu_data.h | 40
> 5 files changed, 124 insertions(+), 64 deletions(-)
> create mode 100644 drivers/thermal/samsung/exynos_tmu_data.c
> create mode 100644 drivers/thermal/samsung/exynos_tmu_data.h
>
> diff --git a/drivers/thermal/samsung/Makefile
> b/drivers/thermal/samsung/Makefile
> index 75e1f97..b133255 100644
> --- a/drivers/thermal/samsung/Makefile
> +++ b/drivers/thermal/samsung/Makefile
> @@ -3,4 +3,5 @@
> #
> obj-$(CONFIG_EXYNOS_SOC_THERMAL) += exynos_soc_thermal.o
> exynos_soc_thermal-y := exynos_tmu.o
> +exynos_soc_thermal-y += exynos_tmu_data.o
> exynos_soc_thermal-$(CONFIG_EXYNOS_COMMON) += exynos_thermal_common.o
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
> b/drivers/thermal/samsung/exynos_thermal_common.h
> index 985b848..6ed9bd9 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> @@ -62,7 +62,7 @@ struct freq_clip_table {
> struct thermal_trip_point_conf {
> int trip_val[MAX_TRIP_COUNT];
> int trip_count;
> - u8 trigger_falling;
> + unsigned char trigger_falling;
> };
>
> struct thermal_cooling_conf {
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index a02f2c9..05b5068 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -34,6 +34,7 @@
> #include
> #include "exynos_thermal_common.h"
> #include "exynos_tmu.h"
> +#include "exynos_tmu_data.h"
>
> /* Exynos generic registers */
> #define EXYNOS_TMU_REG_TRIMINFO 0x0
> @@ -385,66 +386,6 @@ static struct thermal_sensor_conf exynos_sensor_conf = {
> .write_emul_temp= exynos_tmu_set_emulation,
> };
>
> -#if defined(CONFIG_CPU_EXYNOS4210)
> -static struct exynos_tmu_platform_data const exynos4210_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_EXYNOS4210,
> -};
> -#define EXYNOS4210_TMU_DRV_DATA (&exynos4210_default_tmu_data)
> -#else
> -#define EXYNOS4210_TMU_DRV_DATA (NULL)
> -#endif
> -
> -#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
> -static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
> - .threshold_falling = 10,
> - .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_EXYNOS,
> -};
> -#define EXYNOS_TMU_DRV_DATA (&exynos_default_tmu_data)
> -#else
> -#define EXYNOS_TMU_DRV_DATA (NULL)
> -#endif
> -
> #ifdef CONFIG_OF
> static const struct of_device_id exynos_tmu_match[] = {
> {
> @@ -453,11 +394,11 @@ static const struct of_device_id exynos_tmu_match[] = {
> },
> {
> .compatible = "samsung,exynos4412-tmu",
> - .data = (void *)EXYNOS_TMU_DRV_DATA,
> + .data = (void *)EXYNOS5250_TMU_DRV_DATA,
> },
> {
> .compatible = "samsung,exynos5250-tmu",
> - .data = (void *)EXYNOS_TMU_DRV_DATA,
> + .data = (void *)EXYNOS5250_TMU_DRV_DATA,
> },
> {},
> };
> @@ -471,7 +412,7 @@ static s
Re: [PATCH V2 04/20] thermal: exynos: Move exynos_thermal.h from include/* to driver/* folder
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote:
> This patch renames and moves include/linux/platform_data/exynos_thermal.h to
> drivers/thermal/samsung/exynos_tmu.h. This file movement is needed as exynos
> SOC's are not supporting non-DT based platforms. Also the rename is needed as
> this
> file now just contains exynos tmu driver related definations.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Amit Daniel Kachhap
this one looks okay to me.
thanks,
rui
> ---
> drivers/thermal/samsung/exynos_thermal_common.c|1 -
> drivers/thermal/samsung/exynos_thermal_common.h| 15 +++
> drivers/thermal/samsung/exynos_tmu.c |2 +-
> .../thermal/samsung/exynos_tmu.h | 15 ---
> 4 files changed, 16 insertions(+), 17 deletions(-)
> rename include/linux/platform_data/exynos_thermal.h =>
> drivers/thermal/samsung/exynos_tmu.h (88%)
>
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index 9a57606..dae5476 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -27,7 +27,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include "exynos_thermal_common.h"
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
> b/drivers/thermal/samsung/exynos_thermal_common.h
> index 165401f..985b848 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> @@ -44,6 +44,21 @@
>
> #define EXYNOS_ZONE_COUNT3
>
> +/**
> + * struct freq_clip_table
> + * @freq_clip_max: maximum frequency allowed for this cooling state.
> + * @temp_level: Temperature level at which the temperature clipping will
> + * happen.
> + * @mask_val: cpumask of the allowed cpu's where the clipping will take
> place.
> + *
> + * This structure is required to be filled and passed to the
> + * cpufreq_cooling_unregister function.
> + */
> +struct freq_clip_table {
> + unsigned int freq_clip_max;
> + unsigned int temp_level;
> + const struct cpumask *mask_val;
> +};
> struct thermal_trip_point_conf {
> int trip_val[MAX_TRIP_COUNT];
> int trip_count;
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 3de3e61..a02f2c9 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -30,10 +30,10 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include "exynos_thermal_common.h"
> +#include "exynos_tmu.h"
>
> /* Exynos generic registers */
> #define EXYNOS_TMU_REG_TRIMINFO 0x0
> diff --git a/include/linux/platform_data/exynos_thermal.h
> b/drivers/thermal/samsung/exynos_tmu.h
> similarity index 88%
> rename from include/linux/platform_data/exynos_thermal.h
> rename to drivers/thermal/samsung/exynos_tmu.h
> index da7e627..342fb1f 100644
> --- a/include/linux/platform_data/exynos_thermal.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -33,21 +33,6 @@ enum soc_type {
> SOC_ARCH_EXYNOS4210 = 1,
> SOC_ARCH_EXYNOS,
> };
> -/**
> - * struct freq_clip_table
> - * @freq_clip_max: maximum frequency allowed for this cooling state.
> - * @temp_level: Temperature level at which the temperature clipping will
> - * happen.
> - * @mask_val: cpumask of the allowed cpu's where the clipping will take
> place.
> - *
> - * This structure is required to be filled and passed to the
> - * cpufreq_cooling_unregister function.
> - */
> -struct freq_clip_table {
> - unsigned int freq_clip_max;
> - unsigned int temp_level;
> - const struct cpumask *mask_val;
> -};
>
> /**
> * struct exynos_tmu_platform_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
Re: [PATCH V2 03/20] thermal: exynos: Rename exynos_thermal.c to exynos_tmu.c
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote:
> This patch renames exynos_thermal.c to exynos_tmu.c. This change is needed as
> this file now just contains exynos tmu driver related codes and thermal zone
> or cpufreq cooling registration related changes are not there anymore.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Amit Daniel Kachhap
This one looks okay to me.
thanks,
rui
> ---
> drivers/thermal/samsung/Makefile |2 +-
> .../samsung/{exynos_thermal.c => exynos_tmu.c} |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> rename drivers/thermal/samsung/{exynos_thermal.c => exynos_tmu.c} (99%)
>
> diff --git a/drivers/thermal/samsung/Makefile
> b/drivers/thermal/samsung/Makefile
> index fcda5b4..75e1f97 100644
> --- a/drivers/thermal/samsung/Makefile
> +++ b/drivers/thermal/samsung/Makefile
> @@ -2,5 +2,5 @@
> # Samsung thermal specific Makefile
> #
> obj-$(CONFIG_EXYNOS_SOC_THERMAL) += exynos_soc_thermal.o
> -exynos_soc_thermal-y := exynos_thermal.o
> +exynos_soc_thermal-y := exynos_tmu.o
> exynos_soc_thermal-$(CONFIG_EXYNOS_COMMON) += exynos_thermal_common.o
> diff --git a/drivers/thermal/samsung/exynos_thermal.c
> b/drivers/thermal/samsung/exynos_tmu.c
> similarity index 99%
> rename from drivers/thermal/samsung/exynos_thermal.c
> rename to drivers/thermal/samsung/exynos_tmu.c
> index 4c85945..3de3e61 100644
> --- a/drivers/thermal/samsung/exynos_thermal.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -1,5 +1,5 @@
> /*
> - * exynos_thermal.c - Samsung EXYNOS TMU (Thermal Management Unit)
> + * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
> *
> * Copyright (C) 2011 Samsung Electronics
> * Donggeun Kim
--
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 02/20] thermal: exynos: Bifurcate exynos thermal common and tmu controller code
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote: > This code bifurcates exynos thermal implementation into common and sensor > specific parts. The common thermal code interacts with core thermal layer and > core cpufreq cooling parts and is independent of SOC specific driver. This > change is needed to cleanly add support for new TMU sensors. > > Acked-by: Kukjin Kim > Signed-off-by: Amit Daniel Kachhap > --- > drivers/thermal/samsung/Kconfig | 26 +- > drivers/thermal/samsung/Makefile|4 +- > drivers/thermal/samsung/exynos_thermal.c| 421 > +-- > drivers/thermal/samsung/exynos_thermal_common.c | 389 + > drivers/thermal/samsung/exynos_thermal_common.h | 71 > 5 files changed, 491 insertions(+), 420 deletions(-) > create mode 100644 drivers/thermal/samsung/exynos_thermal_common.c > create mode 100644 drivers/thermal/samsung/exynos_thermal_common.h > > diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig > index 2d3d9dc..1e3ba31 100644 > --- a/drivers/thermal/samsung/Kconfig > +++ b/drivers/thermal/samsung/Kconfig > @@ -1,9 +1,21 @@ > -config EXYNOS_THERMAL > - tristate "Temperature sensor on Samsung EXYNOS" > +config EXYNOS_COMMON EXYNOS_COMMON is misleading here, better use EXYNOS_THERMAL_COMMON? > + bool "Common thermal support for EXYNOS SOC's" > depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) > - depends on CPU_THERMAL > help > - If you say yes here you get support for TMU (Thermal Management > - Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering > - the exynos thermal driver with the core thermal layer and cpu > - cooling API's. > + 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 API's. > + > +if EXYNOS_COMMON > + > +config EXYNOS_SOC_THERMAL > + tristate "Temperature sensor on Samsung EXYNOS series SOC" > + depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || > SOC_EXYNOS5250) > + help > + If you say yes here you can enable TMU (Thermal Management Unit) on > + SAMSUNG EXYNOS 4210, 4412, 4414 and 5250 series of SoC. This option > + initialises the TMU controller and registers/unregisters with exynos > + common thermal layer. > + > +endif > diff --git a/drivers/thermal/samsung/Makefile > b/drivers/thermal/samsung/Makefile > index 1fe6d93..fcda5b4 100644 > --- a/drivers/thermal/samsung/Makefile > +++ b/drivers/thermal/samsung/Makefile > @@ -1,4 +1,6 @@ > # > # Samsung thermal specific Makefile > # > -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o > +obj-$(CONFIG_EXYNOS_SOC_THERMAL) += exynos_soc_thermal.o > +exynos_soc_thermal-y := exynos_thermal.o > +exynos_soc_thermal-$(CONFIG_EXYNOS_COMMON) += exynos_thermal_common.o the Makefile suggests that exynos_soc_thermal driver could be built without CONFIG_EXYNOS_COMMON. But the Kconfig file shows that exynos_soc_thermal depends on CONFIG_EXYNOS_COMMON. If exynos_thermal_common.c contains the code to interact with the generic thermal layer and you do not want a soc driver without thermal support, just remove CONFIG_EXYNOS_COMMON and always build it into exynos_soc_thermal.o. what do you think? thanks, rui > diff --git a/drivers/thermal/samsung/exynos_thermal.c > b/drivers/thermal/samsung/exynos_thermal.c > index d20ce9e..4c85945 100644 > --- a/drivers/thermal/samsung/exynos_thermal.c > +++ b/drivers/thermal/samsung/exynos_thermal.c > @@ -21,23 +21,19 @@ > * > */ > > -#include > -#include > -#include > -#include > -#include > -#include > #include > -#include > -#include > -#include > #include > +#include > +#include > +#include > +#include > #include > -#include > -#include > -#include > -#include > #include > +#include > +#include > +#include > +#include > +#include "exynos_thermal_common.h" > > /* Exynos generic registers */ > #define EXYNOS_TMU_REG_TRIMINFO 0x0 > @@ -88,16 +84,6 @@ > #define EFUSE_MIN_VALUE 40 > #define EFUSE_MAX_VALUE 100 > > -/* In-kernel thermal framework related macros & definations */ > -#define SENSOR_NAME_LEN 16 > -#define MAX_TRIP_COUNT 8 > -#define MAX_COOLING_DEVICE 4 > -#define MAX_THRESHOLD_LEVS 4 > - > -#define ACTIVE_INTERVAL 500 > -#define IDLE_INTERVAL 1 > -#define MCELSIUS 1000 > - > #ifdef CONFIG_THERMAL_EMULATION > #define EXYNOS_EMUL_TIME 0x57F0 > #define EXYNOS_EMUL_TIME_SHIFT 16 > @@ -106,17 +92,6 @@ > #define EXYNOS_EMUL_ENABLE 0x1 > #endif /* CONFIG_THERMAL_EMULATION */ > > -/* CPU Zone information */ > -#define PANIC_ZONE 4 > -#define WARN_ZONE 3 > -#define MONITOR_ZONE2 > -#define SAFE_ZONE 1 > - > -#define GET_ZONE(trip) (trip + 2) > -
Re: [PATCH V2 01/20] thermal: exynos: Moving exynos thermal files into samsung directory
On Fri, 2013-04-26 at 16:07 +0530, Amit Daniel Kachhap wrote:
> This movement of files is done for easy maintenance and adding more
> new sensor's support for exynos platform easily . This will also help in
> bifurcating exynos common, sensor driver and sensor data related parts.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Amit Daniel Kachhap
> ---
> drivers/thermal/Kconfig| 13 +
> drivers/thermal/Makefile |2 +-
> drivers/thermal/samsung/Kconfig|9 +
> drivers/thermal/samsung/Makefile |4
> drivers/thermal/{ => samsung}/exynos_thermal.c |0
> 5 files changed, 19 insertions(+), 9 deletions(-)
> create mode 100644 drivers/thermal/samsung/Kconfig
> create mode 100644 drivers/thermal/samsung/Makefile
> rename drivers/thermal/{ => samsung}/exynos_thermal.c (100%)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 5e3c025..081ddc5 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -114,14 +114,6 @@ config KIRKWOOD_THERMAL
> Support for the Kirkwood thermal sensor driver into the Linux thermal
> framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
>
> -config EXYNOS_THERMAL
> - tristate "Temperature sensor on Samsung EXYNOS"
> - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
> - depends on CPU_THERMAL
> - help
> - If you say yes here you get support for TMU (Thermal Management
> - Unit) on SAMSUNG EXYNOS series of SoC.
> -
> config DOVE_THERMAL
> tristate "Temperature sensor on Marvell Dove SoCs"
> depends on ARCH_DOVE
> @@ -169,4 +161,9 @@ config INTEL_POWERCLAMP
> enforce idle time which results in more package C-state residency. The
> user interface is exposed via generic thermal framework.
>
> +menu "Exynos thermal drivers"
would it be more proper to use "Samsung thermal drivers" or "Samsung
Exynos thermal drivers" instead?
> +depends on PLAT_SAMSUNG
> +source "drivers/thermal/samsung/Kconfig"
> +endmenu
> +
sorry I know few about arm,
could you tell me the difference between
CONFIG_ARCH_EXYNOS4/CONFIG_ARCH_EXYNOS5 and CONFIG_PLAT_SAMSUNG please,
I do not see the dependency between these in Kconfig file?
thanks,
rui
> endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index c054d41..b3063a9 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -17,7 +17,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
> -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> +obj-y+= samsung/
> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> new file mode 100644
> index 000..2d3d9dc
> --- /dev/null
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -0,0 +1,9 @@
> +config EXYNOS_THERMAL
> + tristate "Temperature sensor on Samsung EXYNOS"
> + depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
> + depends on CPU_THERMAL
> + help
> + If you say yes here you get support for TMU (Thermal Management
> + Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
> + the exynos thermal driver with the core thermal layer and cpu
> + cooling API's.
> diff --git a/drivers/thermal/samsung/Makefile
> b/drivers/thermal/samsung/Makefile
> new file mode 100644
> index 000..1fe6d93
> --- /dev/null
> +++ b/drivers/thermal/samsung/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# Samsung thermal specific Makefile
> +#
> +obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/samsung/exynos_thermal.c
> similarity index 100%
> rename from drivers/thermal/exynos_thermal.c
> rename to drivers/thermal/samsung/exynos_thermal.c
--
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/4] Thermal: exynos: Support for TMU regulator defined at device tree
Hi, all, what is the status now? which one is preferred, this one or the one from Amit's patch set? thanks, rui On Thu, 2013-04-25 at 18:29 +0200, Lukasz Majewski wrote: > Hi Eduardo, > > > Amit, Lukasz, > > > > On 25-04-2013 09:29, Lukasz Majewski wrote: > > > Hi Amit, > > > > > >> Hi Lukasz Majewski, > > >> > > >> Sorry for late review but I am currently working on restructuring > > >> the whole exynos thermal driver and this support of LDO can be > > >> added as feature as not all socs support this. This is also > > >> suggested by Eduardo. All your other patches looks fine. > > > > > > But this is how it is already done. The VDD_TS is optional, so > > > Exynos5440 and Exynos4210 will not be broken. > > > > > > This shall preserve the correct behavior of the thermal driver. > > > > > > > If you guys plan to move to feature based approach, like suggested in > > V1, then Id recommend adding a /* TODO: */ entry in your driver. > > Ok, nice idea. > > > > > Amit, are you including this LDO support on your rework? > > > -- 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 14/30] thermal/exynos: remove unnecessary header inclusions
On Wed, 2013-04-10 at 21:19 -0400, Eduardo Valentin wrote: > Rui, Arnd, > > As agreed in [1], I will be helping on the thermal maintenance. > > On 10-04-2013 20:04, Arnd Bergmann wrote: > > In multiplatform configurations, we cannot include headers > > provided by only the exynos platform. Fortunately a number > > of drivers that include those headers do not actually need > > them, so we can just remove the inclusions. > > > > Signed-off-by: Arnd Bergmann > > Cc: linux...@vger.kernel.org > > Cc: Zhang Rui > > This patch looks good to me. > > You can add my: > Acked-by: Eduardo Valentin > applied to thermal thermal branch. thanks, rui > > [1] - http://marc.info/?l=linux-pm&m=136560509922173&w=2 -- 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: fix handling of invalid frequency table entries
Hi, Andrew,
can you please verify
commit fc35b35cbe24ef021ea9acfba21e54da958df747
commit 57df8106932b57427df1eaaa13871857f75b1194
at
http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/log/?h=thermal
fixes the problem for you?
thanks,
rui
On Tue, 2013-04-09 at 14:59 -0700, Andrew Bresticker wrote:
> Similar to the error described in "thermal: cpu_cooling: fix handling
> of invalid frequency table entries," exynos_get_frequency_level() will
> enter an infinite loop if any CPU frequency table entries are invalid.
> This patch fixes the handling of invalid frequency entries so that
> there is no infinite loop and the correct level is returned.
>
> Signed-off-by: Andrew Bresticker
> ---
> drivers/thermal/exynos_thermal.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index d5e6267..524b2a0 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -237,7 +237,7 @@ static int exynos_get_crit_temp(struct
> thermal_zone_device *thermal,
>
> static int exynos_get_frequency_level(unsigned int cpu, unsigned int freq)
> {
> - int i = 0, ret = -EINVAL;
> + int i, level = 0, ret = -EINVAL;
> struct cpufreq_frequency_table *table = NULL;
> #ifdef CONFIG_CPU_FREQ
> table = cpufreq_frequency_get_table(cpu);
> @@ -245,12 +245,12 @@ static int exynos_get_frequency_level(unsigned int cpu,
> unsigned int freq)
> if (!table)
> return ret;
>
> - while (table[i].frequency != CPUFREQ_TABLE_END) {
> + for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
> if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> continue;
> if (table[i].frequency == freq)
> - return i;
> - i++;
> + return level;
> + level++;
> }
> return ret;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] thermal: exynos: Use the new thermal trend type for quick cooling action.
On Thu, 2013-02-07 at 17:13 -0800, Amit Daniel Kachhap wrote:
> This patch uses the quick thermal cooling trend type macros. This is needed
> as exynos5 and other thermal sensors now supports only interrupt method for
> thresold temperature check.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Amit Daniel Kachhap
applied to thermal -next.
thanks,
rui
> ---
>
> Hi,
>
> Submitting these patches again as they got lost somewhere and was not merged.
>
> Changes since V2:
> * Rebased against Rui Zhang next tree.
> * Added Kukjin Kim acked by.
>
> All these patches are based on thermal maintainer next branch.
> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git thermal
>
> drivers/thermal/exynos_thermal.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index 65f69cf..030bba3 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -296,7 +296,7 @@ static int exynos_bind(struct thermal_zone_device
> *thermal,
> case MONITOR_ZONE:
> case WARN_ZONE:
> if (thermal_zone_bind_cooling_device(thermal, i, cdev,
> - level, level)) {
> + level, 0)) {
> pr_err("error binding cdev inst %d\n", i);
> ret = -EINVAL;
> }
> @@ -399,9 +399,9 @@ static int exynos_get_trend(struct thermal_zone_device
> *thermal,
> return ret;
>
> if (thermal->temperature >= trip_temp)
> - *trend = THERMAL_TREND_RAISING;
> + *trend = THERMAL_TREND_RAISE_FULL;
> else
> - *trend = THERMAL_TREND_DROPPING;
> + *trend = THERMAL_TREND_DROP_FULL;
>
> return 0;
> }
--
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/2] Thermal: exynos: Add support for temperature falling interrupt.
On Thu, 2013-02-07 at 17:13 -0800, Amit Daniel Kachhap wrote:
> From: Jonghwa Lee
>
> This patch introduces using temperature falling interrupt in exynos
> thermal driver. Former patch, it only use polling way to check
> whether if system themperature is fallen. However, exynos SOC also
> provides temperature falling interrupt way to do same things by hw.
> This feature is not supported in exynos4210.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Jonghwa Lee
> Signed-off-by: Amit Daniel Kachhap
applied to thermal -next.
thanks,
rui
> ---
> Hi,
>
> Submitting these patches again as they got lost somewhere and was not merged.
>
> Changes since V2:
> * Rebased against Rui Zhang next tree.
> * Added Kukjin Kim acked by.
>
> Changes since V1: Used the new thermal trend type macro
>
> All these patches are based on thermal maintainer next branch.
> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git thermal
>
> drivers/thermal/exynos_thermal.c | 81
> +++---
> include/linux/platform_data/exynos_thermal.h |3 +
> 2 files changed, 49 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index 3a1b01e..65f69cf 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -94,6 +94,7 @@
> #define SENSOR_NAME_LEN 16
> #define MAX_TRIP_COUNT 8
> #define MAX_COOLING_DEVICE 4
> +#define MAX_THRESHOLD_LEVS 4
>
> #define ACTIVE_INTERVAL 500
> #define IDLE_INTERVAL 1
> @@ -133,6 +134,7 @@ struct exynos_tmu_data {
> struct thermal_trip_point_conf {
> int trip_val[MAX_TRIP_COUNT];
> int trip_count;
> + u8 trigger_falling;
> };
>
> struct thermal_cooling_conf {
> @@ -183,7 +185,8 @@ static int exynos_set_mode(struct thermal_zone_device
> *thermal,
>
> mutex_lock(&th_zone->therm_dev->lock);
>
> - if (mode == THERMAL_DEVICE_ENABLED)
> + if (mode == THERMAL_DEVICE_ENABLED &&
> + !th_zone->sensor_conf->trip_data.trigger_falling)
> th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
> else
> th_zone->therm_dev->polling_delay = 0;
> @@ -447,7 +450,8 @@ static void exynos_report_trigger(void)
> break;
> }
>
> - if (th_zone->mode == THERMAL_DEVICE_ENABLED) {
> + if (th_zone->mode == THERMAL_DEVICE_ENABLED &&
> + !th_zone->sensor_conf->trip_data.trigger_falling) {
> if (i > 0)
> th_zone->therm_dev->polling_delay = ACTIVE_INTERVAL;
> else
> @@ -486,7 +490,8 @@ static int exynos_register_thermal(struct
> thermal_sensor_conf *sensor_conf)
>
> th_zone->therm_dev = thermal_zone_device_register(sensor_conf->name,
> EXYNOS_ZONE_COUNT, 0, NULL, &exynos_dev_ops, NULL, 0,
> - IDLE_INTERVAL);
> + sensor_conf->trip_data.trigger_falling ?
> + 0 : IDLE_INTERVAL);
>
> if (IS_ERR(th_zone->therm_dev)) {
> pr_err("Failed to register thermal zone device\n");
> @@ -593,8 +598,9 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> {
> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> struct exynos_tmu_platform_data *pdata = data->pdata;
> - unsigned int status, trim_info, rising_threshold;
> - int ret = 0, threshold_code;
> + unsigned int status, trim_info;
> + unsigned int rising_threshold = 0, falling_threshold = 0;
> + int ret = 0, threshold_code, i, trigger_levs = 0;
>
> mutex_lock(&data->lock);
> clk_enable(data->clk);
> @@ -619,6 +625,11 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> (data->temp_error2 != 0))
> data->temp_error1 = pdata->efuse_value;
>
> + /* Count trigger levels to be enabled */
> + for (i = 0; i < MAX_THRESHOLD_LEVS; i++)
> + if (pdata->trigger_levels[i])
> + trigger_levs++;
> +
> if (data->soc == SOC_ARCH_EXYNOS4210) {
> /* Write temperature code for threshold */
> threshold_code = temp_to_code(data, pdata->threshold);
> @@ -628,44 +639,38 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> }
> writeb(threshold_code,
> data->base + EXYNOS4210_TMU_REG_THRESHOLD_TEMP);
> -
> - writeb(pdata->trigger_levels[0],
> - data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL0);
> - writeb(pdata->trigger_levels[1],
> - data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL1);
> - writeb(pdata->trigger_levels[2],
> - data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL2);
> - writeb(pdata->trigger_levels[3],
> - data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL3);
> + for (i = 0; i < tr
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
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_dat
Re: [PATCH V3 1/2] thermal: sysfs: Add a new sysfs node emul_temp for thermal emulation
On Sun, 2013-02-03 at 16:30 -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
applied to thermal -next.
thanks,
rui
> ---
> Changes in V3:
> * Removed the un-necessary get_temp pointer check.
> * Added the read temp code in #ifdef EMULATION macros
>
> 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 | 79
> ++-
> include/linux/thermal.h |2 +
> 4 files changed, 91 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..0675687 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -378,24 +378,54 @@ 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);
> +
> + ret = tz->ops->get_temp(tz, temp);
> +#ifdef CONFIG_THERMAL_EMULATION
> + if (!tz->emul_temperature)
> + goto skip_emul;
> +
> + for (count = 0; count < tz->trips; count++) {
> + ret = tz->ops->get_trip_type(tz, count, &type);
> + if (!ret && type == THERMAL_TRIP
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
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->sensor_conf->private_data;
> + if (th_zone->sensor_conf->write_emul_temp)
> + ret = th_zone->sensor_conf->write_emul_temp(data, temp);
> + return ret;
> +}
> +
> /* Get the temperature trend */
> static int exynos_get_trend(struct thermal_zone_device *thermal,
> int trip, enum thermal_trend *tren
Re: [PATCH V2 1/2] thermal: sysfs: Add a new sysfs node emul_temp for thermal emulation
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 (count = 0; count < tz->trips; count++) {
> + ret = tz->ops->get_trip_type(tz, count, &type);
> + if (!ret && type == THERMAL_TRIP_CRITICAL) {
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
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 support emulation is CONFIG_THERMAL_EMULATION is cleared. And further more, for pure software emulation, we should check if the real temperature reaches critical trip point. thanks, rui > I will re-submit with this change. > > Thanks, > Amit > > > > thanks, > > rui > >> + This is useful in debugging different temperature threshold and its > >> + associated
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
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?
As this is for debug purpose, I'd prefer to have a seperate Kconfig
option for this feature.
> 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.
thanks,
rui
> + This is useful in debugging different temperature threshold and its
> + associated cooling action. Writing 0 on this node should disable
> + emulation.
> + Unit: millidegree Celsius
> + WO, Optional
> +
> *
> * Cooling device attributes *
> *
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 8c8ce80..ecdfc7d 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -700,11 +700,31 @@ policy_show(struct device *dev, struct device_attribute
> *devattr, char *buf)
> return sprintf(buf, "%s\n", tz->governor->name);
> }
>
> +static ssize_t
> +emul_temp_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct thermal_zone_device *tz = to_thermal_zone(dev);
> + int ret;
> + unsigned long temperature;
> +
> + if (!tz->ops->set_emul_temp)
> + return -EPERM;
> +
> + if (kstrtoul(buf, 10, &temperature))
> + return -EINVAL;
> +
> + ret = tz->ops->set_emul_temp(tz, temperature);
> +
> + return ret ? ret : count;
> +}
> +
> static DEVICE_ATTR(type, 0444, type_show, NULL);
> static DEVICE_ATTR(temp, 0444, temp_show, NULL);
> static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
> static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
> static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
> +static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
>
> /* sys I/F for cooling device */
> #define to_cooling_device(_dev) \
> @@ -1592,6 +1612,12 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
> goto unregister;
> }
>
> + if (ops->set_emul_temp) {
> + result = device_create_file(&tz->device, &dev_attr_emul_temp);
> + if (result)
> + goto unregister;
> + }
> +
> /* Create policy attr
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Fri, 2012-11-23 at 09:35 +0530, Amit Kachhap wrote:
> 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.
>
great. please rebase your patch on top of thermal-thermal tree.
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 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?
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 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
--
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/4] thermal: Add support for interrupt based notification to thermal layer
Hi, Amit, As THERMAL_TREND_RAISE_FULL/THERMAL_TREND_DROP_FULL has been introduced to thermal next tree, I'd like to get your plan about this patch set? 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: Thursday, November 08, 2012 12:26 PM > To: linux...@lists.linux-foundation.org > Cc: linux-samsung-soc@vger.kernel.org; linux-ker...@vger.kernel.org; R, > Durgadoss; l...@kernel.org; Zhang, Rui; linux-a...@vger.kernel.org; > amit.kach...@linaro.org; jonghwa3@samsung.com > Subject: [PATCH 0/4] thermal: Add support for interrupt based > notification to thermal layer > Importance: High > > The patch submitted by Jonghwa Lee > (https://patchwork.kernel.org/patch/1683441/) > adds support for interrupt based notification to thermal layer. This is > a good feature but the current thermal framework needs polling/regular > notification for invoking suitable cooling action. So adding 2 new > thermal trend type to implement this feature. > > All these patches are based on thermal maintainer next tree. > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next > > Amit Daniel Kachhap (3): > thermal: Add new thermal trend type to support quick cooling > thermal: exynos: Miscellaneous fixes to support falling threshold > interrupt > thermal: exynos: Use the new thermal trend type for quick cooling > action. > > Jonghwa Lee (1): > Thermal: exynos: Add support for temperature falling interrupt. > > drivers/thermal/exynos_thermal.c | 105 +++--- > > drivers/thermal/step_wise.c | 19 - > include/linux/platform_data/exynos_thermal.h |3 + > include/linux/thermal.h |2 + > 4 files changed, 80 insertions(+), 49 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" > 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-Resend] thermal: Exynos: Add missing dependency
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? > See drivers/cpufreq/Kconfig > Also "depends THERMAL" should be there otherwise menuconfig > parent/child relationship is broken. > this should be solved by my patch 1/2. :) thanks, rui > Thanks, > Amit Daniel > > > + depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) && CPU_THERMAL > > help > > If you say yes here you get support for TMU (Thermal Managment > > Unit) on SAMSUNG EXYNOS series of SoC. > > -- > > 1.7.4.1 > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
> Hi Amit/Rui,
>
> > -Original Message-
> > From: Amit Kachhap [mailto:amit.kach...@linaro.org]
> > Sent: Friday, November 09, 2012 11:52 AM
> > To: Zhang, Rui
> > Cc: linux...@lists.linux-foundation.org; linux-samsung-
> > s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
> > l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
> > Subject: 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.
>
> Yes, in this particular case, we neither need to poll nor do step wise
> operations. But, most of the other sensors need at least one of them.
>
> So, I think we can try it this way:
> if (sensor supports interrupt) {
> 'always' use RAISE_MAX and DROP_MAX;
> } else {
> Do Step wise operations
> }
>
why should the generic thermal layer be aware of this?
IMO, it is the platform thermal driver that is responsible for returning
THERMAL_TREND_RAISE_STEP or THERMAL_TREND_RAISE_MAX.
and the step_wise governor just takes action based on the return value
of .get_trend() callback.
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 Fri, 2012-11-09 at 11:51 +0530, Amit Kachhap wrote:
> 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 ?
>
this sounds good to me.
I'd like to see Durga' comments on this as well.
thanks,
rui
> > 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 vo
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
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.
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 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
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
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.
I can write such a governor if you do not have time to.
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: [PATCH RESEND] thermal: add generic cpufreq cooling implementation
On 一, 2012-09-10 at 09:50 +0300, Valentin, Eduardo wrote: > Hello Rui and Amit, > > On Mon, Sep 10, 2012 at 9:25 AM, 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. > > > > 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 > > > can you please include my Reviewed-by? Also on your patch series I > have reviewed. > sure. > Reviewed-by: Eduardo Valentin > thanks! -rui > > > > --- > > 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 @@ >
[PATCH RESEND] thermal: add generic cpufreq cooling implementation
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. 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 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. + diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 7dd8c34..996003b 100644 --- a/drivers/thermal/Kcon
Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
On 五, 2012-08-17 at 11:56 +0300, Valentin, Eduardo wrote: > Hello, > >>> + > >>> + > >>> +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 > >> > >> what are these two APIs used for? > >> I did not see they are used in your patch set, do I miss something? > > No currently they are not used by my patches. I added them on request > > from Eduardo and others > > Yeah, this was a suggestion as we didn't really know how the FW part > would evolve by that time. > > The reasoning is to allow any interested user (in kernel) to be > notified when max frequency changes. in this case, the cooling device should be updated. Say all the target of the thermal_instances of a cooling devices is 0, which means they want the cpu to run at maximum frequency, when the max frequency changes, we should set the processor to the new max frequency as well. Using notification is not a good idea as user can not handle this without interacting with the thermal framework. IMO, we should introduce a new API to handle this, rather than just notifications to users. > Actually, the use case behind > this is to allow such users to perform some handshaking or stop their > activities or even change some paramenters, in case the max frequency > would change. It is the cooling device driver that notice this change first, and it should invoke something like thermal_cooling_device_update/rebind() to tell the thermal framework this change. > Ideally it would be possible to nack the cooling > transition. But that is yet a wider discussion. So far we don't have > users for this. > yep. I thought about this before, but I'd prefer to do this when there is a real user. Or else, we are kind of over-designing here. how about removing this piece of code for now? thanks, rui > >> > >>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > >>> index 7dd8c34..996003b 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 here. > >>> + > >>> config SPEAR_THERMAL > >>> bool "SPEAr thermal sensor driver" > >>> depends on THERMAL > >>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile > >>> index fd9369a..aae59ad 100644 > >>> --- a/drivers/thermal/Makefile > >>> +++ b/drivers/thermal/Makefile > >>> @@ -3,5 +3,6 @@ > >>> # > >>> > >>> obj-$(CONFIG_THERMAL)+= thermal_sys.o > >>> +obj-$(CONFIG_CPU_THERMAL)+= cpu_cooling.o > >>> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o > >>> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o > >>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > >>> new file mode 100644 > >>> index 000..c42e557 > >>> --- /dev/null > >>> +++ b/drivers/thermal/cpu_cooling.c > >>> @@ -0,0 +1,512 @@ > >>> +/* > >>> + * linux/drivers/thermal/cpu_cooling.c > >>> + * > >>> + * Copyright (C) 2012 Samsung Electronics Co., > >>> Ltd(http://www.samsung.com) > >>> + * Copyright (C) 2012 Amit Daniel > >>> + * > >>> + * > >>> ~~ > >>> + * This program is free software; you can redistribute it and/or modify > >>> + * it under the terms of the GNU General Public License as published by > >>> + * the Free Software Foundation; version 2 of the License. > >>> + * > >>> + * This program is distributed in the hope that it will be useful, but > >>> + * WITHOUT ANY WARRANTY; without even the implied warranty of > >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR
Re: [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
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 function unregisters the "thermal-cpufreq-%x" cooling > device. > + > +cdev: Cooling device pointer which has to be unregistered. > + > + > +1.2 CPU cooli
RE: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for exynos platform
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<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);
}
}
With these two things, I think the WARN_ZONE AND MONITOR_ZONE can be registered
as two PASSIVE trip points in the generic thermal layer, right?
Actually, this is one thing in my TODO list. And I'd glad to make it high
priority if this solves the problem you have.
Thanks,
rui
-Original Message-
From: linux-acpi-ow...@vger.kernel.org
[mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Amit Daniel Kachhap
Sent: Tuesday, May 08, 2012 9:18 AM
To: a...@linux-foundation.org; linux...@lists.linux-foundation.org
Cc: R, Durgadoss; linux-a...@vger.kernel.org; l...@kernel.org; Zhang, Rui;
amit.kach...@linaro.org; linaro-...@lists.linaro.org;
linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org; patc...@linaro.org
Subject: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for exynos
platform
Importance: High
Hi Andrew,
This patchset introduces a new generic cooling device based on cpufreq that can
be used on non-ACPI platforms. As a proof of concept, we have drivers for the
following platforms using this mechanism now:
* TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal)
* Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
* Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git
imx6q_thermal)
These patches have been reviewed by Rui Zhang
(https://lkml.org/lkml/2012/4/9/448)
who seems to agree with them in principle, but I haven't had any luck getting
them merged, perhaps a lack of maintainer bandwidth.
ACPI platforms currently have such a mechanism but it is wrapped in ACPI'isms
that we don't have on ARM platforms. If this is accepted, I'm proposing to
convert over the ACPI thermal driver to use this common code too.
Can you please merge these patches for 3.5?
Thanks,
Amit Daniel
Changes since V2:
*Added Exynos5 TMU sensor support by enhancing the exynos4 tmu driver. Exynos5
TMU driver was internally developed by SangWook Ju .
*Removed cpuhotplug cooling code in this patchset.
*Rebased the patches against 3.4-rc6 kernel.
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 cool
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
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?
I'm not sure if my understanding is right, but IMO, we can have one
THERMAL_TRIP_STATE_INSTANCE only, for both MONIROR_ZONE and WARN_ZONE,
and the trip temperature equals MONIROR_ZONE.
The cpufreq cooling device will work in the same way, no?
thanks,
rui
> There is a chance that people might confuse that these checks are
> applicable for passive trip types also which is not the case here.
>
> @@ -1187,6 +1228,21 @@ struct thermal_zone_device
> *thermal_zone_device_register(char *type,
> tz->ops->get_trip_type(tz, count, &trip_type);
> if (trip_type == THERMAL_TRIP_PASSIVE)
> passive = 1;
> + /*
> +* For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
> +* be in ascending order.
> + */
> + if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
> + tz->ops->get_trip_temp(tz, count, &trip_temp);
> + if (first_trip_temp == 0)
> + first_trip_temp = trip_temp;
> + else if (first_trip_temp < trip_temp)
> + first_trip_temp = trip_temp;
> + else if (first_trip_temp > trip_temp) {
> + pr_warn("Zone trip points should be in
> ascending order\n");
> + goto unregister;
> + }
> + }
> }
>
> if (!passive)
>
> Anyway there is other alternative where this new trip type is not
> needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
> and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
> I had thought to make this generic and just to manage with 1 cooling
> device.
> What is your view?
>
> Thanks,
> Amit Daniel
>
>
> >
> > thanks,
> > rui
> >
> >> Regards,
> >> Amit Daniel
> >>
> >> On 19 March 2012 11:47, Amit Daniel Kachhap
> >> 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.
> >
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
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. 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? 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 > > 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 therma
