[U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250
This patch series adds support for TMU driver using device tree for Exynos5250 based SMDK5250 board. This patch series is dependent on the patch series "Add DT based ethernet driver for SMDK5250" by Hatim Ali
Changes since v3: - Rebased patch 1/8
Akshay Saraswat (6): EXYNOS5: FDT: Add TMU device node values EXYNOS5: TMU: Add driver for Thermal Management Unit EXYNOS5: Power down API for Thermal Management Unit Add a poll function to monitor events EXYNOS5: TMU: Add TMU status polling EXYNOS5: Config: Enable support for Exynos TMU driver
Alim Akhtar (2): TMU: Add u-boot command to read current temp EXYNOS5: Config: Enable tmu command
README | 8 + arch/arm/cpu/armv7/exynos/power.c | 15 ++ arch/arm/dts/exynos5250.dtsi | 5 + arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 +++++ arch/arm/include/asm/arch-exynos/power.h | 8 + board/samsung/dts/exynos5250-smdk5250.dts | 13 + board/samsung/smdk5250/smdk5250.c | 36 +++ common/Makefile | 1 + common/cmd_tmu.c | 51 +++++ common/console.c | 5 + doc/device-tree-bindings/exynos/tmu.txt | 35 +++ drivers/power/Makefile | 1 + drivers/power/exynos-tmu.c | 297 +++++++++++++++++++++++++ include/common.h | 6 + include/configs/exynos5250-dt.h | 7 + include/fdtdec.h | 1 + include/tmu.h | 46 ++++ lib/fdtdec.c | 1 + 18 files changed, 594 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h create mode 100644 common/cmd_tmu.c create mode 100644 doc/device-tree-bindings/exynos/tmu.txt create mode 100644 drivers/power/exynos-tmu.c create mode 100644 include/tmu.h
From: Akshay Saraswat akshay.s@samsung.com
Fdt entry for Exynos TMU driver specific pre-defined values used for calibration of current temperature and defining threshold values.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi index fa4d498..db22db6 100644 --- a/arch/arm/dts/exynos5250.dtsi +++ b/arch/arm/dts/exynos5250.dtsi @@ -28,4 +28,9 @@ #address-cells = <1>; #size-cells = <0>; }; + + tmu@10060000 { + compatible = "samsung,exynos-tmu"; + reg = <0x10060000 0xffff>; + }; }; diff --git a/board/samsung/dts/exynos5250-smdk5250.dts b/board/samsung/dts/exynos5250-smdk5250.dts index b6fbb67..2d3ecca 100644 --- a/board/samsung/dts/exynos5250-smdk5250.dts +++ b/board/samsung/dts/exynos5250-smdk5250.dts @@ -26,4 +26,17 @@ phy-mode = "mii"; }; }; + + tmu@10060000 { + samsung,mux = <6>; + samsung,min-temp = <25>; + samsung,max-temp = <125>; + samsung,start-warning = <95>; + samsung,start-tripping = <105>; + samsung,efuse-min-value = <40>; + samsung,efuse-value = <55>; + samsung,efuse-max-value = <100>; + samsung,slope = <268470274>; + samsung,dc-value = <25>; + }; }; diff --git a/doc/device-tree-bindings/exynos/tmu.txt b/doc/device-tree-bindings/exynos/tmu.txt new file mode 100644 index 0000000..99e7164 --- /dev/null +++ b/doc/device-tree-bindings/exynos/tmu.txt @@ -0,0 +1,35 @@ +Exynos Thermal management Unit + +The device node for TMU that is a part of Exynos5250 +SOC is as described in the document "Open Firmware Recommended +Practic : Universal Serial Bus" with the following modifications +and additions: + +Required properties : + - compatible : Should be "samsung,exynos-tmu" for TMU + - samsung,mux : mux Address for the TMU to enable TMU core: + - samsung,min-temp : Minimum temperature, default is 25: + - samsung,max-temp : Maximum temperature, defalut set to 125: + - samsung,start-warning : temp at which TMU start giving warning: + - samsung,start-tripping : temp at which system will trip and shutdown: + - samsung,efuse-min-value : SOC efuse min value: + - samsung,efuse-value : SOC actual efuse value: + - samsung,efuse-max-value : SoC max efuse value: + - samsung,slope : Gain of amplifier, default is 268470274: + - samsung,dc-value : DC value of TMU, default is 25: + +Example: + +tmu@10060000 { + compatible = "samsung,exynos-tmu" + samsung,mux = <6>; + samsung,min-temp = <25>; + samsung,max-temp = <125>; + samsung,start-warning = <95>; + samsung,start-tripping = <105>; + samsung,efuse-min-value = <40>; + samsung,efuse-value = <55>; + samsung,efuse-max-value = <100>; + samsung,slope = <268470274>; + samsung,dc-value = <25>; +}; diff --git a/include/fdtdec.h b/include/fdtdec.h index da3c85f..2d74cec 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -70,6 +70,7 @@ enum fdt_compat_id { COMPAT_NVIDIA_TEGRA20_DC, /* Tegra 2 Display controller */ COMPAT_SMSC_LAN9215, /* SMSC 10/100 Ethernet LAN9215 */ COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */ + COMPAT_SAMSUNG_EXYNOS_TMU, /* Exynos TMU */
COMPAT_COUNT, }; diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 85e733c..2b9df7f 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -47,6 +47,7 @@ static const char * const compat_names[COMPAT_COUNT] = { COMPAT(NVIDIA_TEGRA20_DC, "nvidia,tegra20-dc"), COMPAT(SMSC_LAN9215, "smsc,lan9215"), COMPAT(SAMSUNG_EXYNOS5_SROMC, "samsung,exynos-sromc"), + COMPAT(SAMSUNG_EXYNOS_TMU, "samsung,exynos-tmu"), };
const char *fdtdec_get_compatible(enum fdt_compat_id id)
Hi Hatim,
On Tue, Dec 11, 2012 at 2:54 AM, Hatim Ali hatim.rv@samsung.com wrote:
From: Akshay Saraswat akshay.s@samsung.com
Fdt entry for Exynos TMU driver specific pre-defined values used for calibration of current temperature and defining threshold values.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi index fa4d498..db22db6 100644 --- a/arch/arm/dts/exynos5250.dtsi +++ b/arch/arm/dts/exynos5250.dtsi @@ -28,4 +28,9 @@ #address-cells = <1>; #size-cells = <0>; };
tmu@10060000 {compatible = "samsung,exynos-tmu";reg = <0x10060000 0xffff>;
I think the ffff should be 0x10000.
};}; diff --git a/board/samsung/dts/exynos5250-smdk5250.dts b/board/samsung/dts/exynos5250-smdk5250.dts index b6fbb67..2d3ecca 100644 --- a/board/samsung/dts/exynos5250-smdk5250.dts +++ b/board/samsung/dts/exynos5250-smdk5250.dts @@ -26,4 +26,17 @@ phy-mode = "mii"; }; };
tmu@10060000 {samsung,mux = <6>;samsung,min-temp = <25>;samsung,max-temp = <125>;samsung,start-warning = <95>;samsung,start-tripping = <105>;samsung,efuse-min-value = <40>;samsung,efuse-value = <55>;samsung,efuse-max-value = <100>;samsung,slope = <268470274>;samsung,dc-value = <25>;};}; diff --git a/doc/device-tree-bindings/exynos/tmu.txt b/doc/device-tree-bindings/exynos/tmu.txt new file mode 100644 index 0000000..99e7164 --- /dev/null +++ b/doc/device-tree-bindings/exynos/tmu.txt @@ -0,0 +1,35 @@ +Exynos Thermal management Unit
+The device node for TMU that is a part of Exynos5250 +SOC is as described in the document "Open Firmware Recommended +Practic : Universal Serial Bus" with the following modifications +and additions:
+Required properties :
- compatible : Should be "samsung,exynos-tmu" for TMU
- samsung,mux : mux Address for the TMU to enable TMU core:
- samsung,min-temp : Minimum temperature, default is 25:
- samsung,max-temp : Maximum temperature, defalut set to 125:
- samsung,start-warning : temp at which TMU start giving warning:
- samsung,start-tripping : temp at which system will trip and shutdown:
- samsung,efuse-min-value : SOC efuse min value:
- samsung,efuse-value : SOC actual efuse value:
- samsung,efuse-max-value : SoC max efuse value:
- samsung,slope : Gain of amplifier, default is 268470274:
- samsung,dc-value : DC value of TMU, default is 25:
Can you add a few more details here on these last 5? The units of each should be listed (and for temperature above which I think is degrees C). The 'slope' in particular is a very large random number which could do with some docs. Also re samsung.mux, what are the available options?
Also remove : at the end of lines.
+Example:
+tmu@10060000 {
compatible = "samsung,exynos-tmu"samsung,mux = <6>;samsung,min-temp = <25>;samsung,max-temp = <125>;samsung,start-warning = <95>;samsung,start-tripping = <105>;samsung,efuse-min-value = <40>;samsung,efuse-value = <55>;samsung,efuse-max-value = <100>;samsung,slope = <268470274>;samsung,dc-value = <25>;+}; diff --git a/include/fdtdec.h b/include/fdtdec.h index da3c85f..2d74cec 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -70,6 +70,7 @@ enum fdt_compat_id { COMPAT_NVIDIA_TEGRA20_DC, /* Tegra 2 Display controller */ COMPAT_SMSC_LAN9215, /* SMSC 10/100 Ethernet LAN9215 */ COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */
COMPAT_SAMSUNG_EXYNOS_TMU, /* Exynos TMU */ COMPAT_COUNT,}; diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 85e733c..2b9df7f 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -47,6 +47,7 @@ static const char * const compat_names[COMPAT_COUNT] = { COMPAT(NVIDIA_TEGRA20_DC, "nvidia,tegra20-dc"), COMPAT(SMSC_LAN9215, "smsc,lan9215"), COMPAT(SAMSUNG_EXYNOS5_SROMC, "samsung,exynos-sromc"),
COMPAT(SAMSUNG_EXYNOS_TMU, "samsung,exynos-tmu"),};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
1.7.2.3
Regards, Simon
From: Akshay Saraswat akshay.s@samsung.com
Adding Exynos Thermal Management Unit driver to monitor SOC temperature and take actions corresponding to states of TMU. System will shutdown if tripping temperature is reached.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/include/asm/arch-exynos/exynos-tmu.h b/arch/arm/include/asm/arch-exynos/exynos-tmu.h new file mode 100644 index 0000000..c79a520 --- /dev/null +++ b/arch/arm/include/asm/arch-exynos/exynos-tmu.h @@ -0,0 +1,58 @@ +/* + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * Akshay Saraswat akshay.s@samsung.com + * + * EXYNOS - Thermal Management Unit + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __ASM_ARCH_TMU_H +#define __ASM_ARCH_TMU_H + +struct tmu_reg { + unsigned triminfo; + unsigned rsvd1; + unsigned rsvd2; + unsigned rsvd3; + unsigned rsvd4; + unsigned triminfo_control; + unsigned rsvd5; + unsigned rsvd6; + unsigned tmu_control; + unsigned rsvd7; + unsigned tmu_status; + unsigned sampling_internal; + unsigned counter_value0; + unsigned counter_value1; + unsigned rsvd8; + unsigned rsvd9; + unsigned current_temp; + unsigned rsvd10; + unsigned rsvd11; + unsigned rsvd12; + unsigned threshold_temp_rise; + unsigned threshold_temp_fall; + unsigned rsvd13; + unsigned rsvd14; + unsigned past_temp3_0; + unsigned past_temp7_4; + unsigned past_temp11_8; + unsigned past_temp15_12; + unsigned inten; + unsigned intstat; + unsigned intclear; + unsigned rsvd15; + unsigned emul_con; +}; +#endif /* __ASM_ARCH_THERMAL_H */ diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 6bf388c..192a7cb 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -30,6 +30,7 @@ COBJS-$(CONFIG_TPS6586X_POWER) += tps6586x.o COBJS-$(CONFIG_TWL4030_POWER) += twl4030.o COBJS-$(CONFIG_TWL6030_POWER) += twl6030.o COBJS-$(CONFIG_TWL6035_POWER) += twl6035.o +COBJS-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o
COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c new file mode 100644 index 0000000..ce71408 --- /dev/null +++ b/drivers/power/exynos-tmu.c @@ -0,0 +1,297 @@ +/* + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * Akshay Saraswat akshay.s@samsung.com + * + * EXYNOS - Thermal Management Unit + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <errno.h> +#include <fdtdec.h> +#include <tmu.h> +#include <asm/arch/exynos-tmu.h> + +#define TRIMINFO_RELOAD 1 +#define CORE_EN 1 + +#define INTEN_RISE0 1 +#define INTEN_RISE1 (1 << 4) +#define INTEN_RISE2 (1 << 8) +#define INTEN_FALL0 (1 << 16) +#define INTEN_FALL1 (1 << 20) +#define INTEN_FALL2 (1 << 24) + +#define TRIM_INFO_MASK 0xff + +#define INTCLEAR_RISE0 1 +#define INTCLEAR_RISE1 (1 << 4) +#define INTCLEAR_RISE2 (1 << 8) +#define INTCLEAR_FALL0 (1 << 16) +#define INTCLEAR_FALL1 (1 << 20) +#define INTCLEAR_FALL2 (1 << 24) +#define INTCLEARALL (INTCLEAR_RISE0 | INTCLEAR_RISE1 | \ + INTCLEAR_RISE2 | INTCLEAR_FALL0 | \ + INTCLEAR_FALL1 | INTCLEAR_FALL2) + +/* Tmeperature threshold values for various thermal events */ +struct temperature_params { + /* minimum value in temperature code range */ + unsigned int min_val; + /* maximum value in temperature code range */ + unsigned int max_val; + /* temperature threshold to start warning */ + unsigned int start_warning; + /* temperature threshold CPU tripping */ + unsigned int start_tripping; +}; + +/* Pre-defined values and thresholds for calibration of current temperature */ +struct tmu_data { + /* pre-defined temperature thresholds */ + struct temperature_params ts; + /* pre-defined efuse range minimum value */ + unsigned int efuse_min_value; + /* pre-defined efuse value for temperature calibration */ + unsigned int efuse_value; + /* pre-defined efuse range maximum value */ + unsigned int efuse_max_value; + /* current temperature sensing slope */ + unsigned int slope; +}; + +/* TMU device specific details and status */ +struct tmu_info { + /* base Address for the TMU */ + unsigned tmu_base; + /* mux Address for the TMU */ + int tmu_mux; + /* pre-defined values for calibration and thresholds */ + struct tmu_data data; + /* value required for triminfo_25 calibration */ + unsigned int te1; + /* value required for triminfo_85 calibration */ + unsigned int te2; + /* TMU DC value for threshold calculation */ + int dc_value; + /* enum value indicating status of the TMU */ + int tmu_state; +}; + +/* Global struct tmu_info variable to store init values */ +static struct tmu_info gbl_info; + +/* + * After reading temperature code from register, compensating + * its value and calculating celsius temperatue, + * get current temperatue. + * + * @return current temperature of the chip as sensed by TMU + */ +int get_cur_temp(struct tmu_info *info) +{ + int cur_temp; + struct tmu_reg *reg = (struct tmu_reg *)info->tmu_base; + + /* Temperature code range between min 25 and max 125 */ + cur_temp = readl(®->current_temp) & 0xff; + + /* Calibrate current temperature */ + if (cur_temp) + cur_temp = cur_temp - info->te1 + info->dc_value; + + return cur_temp; +} + +/* + * Monitors status of the TMU device and exynos temperature + * + * @param temp pointer to the current temperature value + * @return enum tmu_status_t value, code indicating event to execute + */ +enum tmu_status_t tmu_monitor(int *temp) +{ + if (gbl_info.tmu_state == TMU_STATUS_INIT) + return -1; + + int cur_temp; + struct tmu_data *data = &gbl_info.data; + + /* Read current temperature of the SOC */ + cur_temp = get_cur_temp(&gbl_info); + *temp = cur_temp; + + /* Temperature code lies between min 25 and max 125 */ + if (cur_temp >= data->ts.start_tripping && + cur_temp <= data->ts.max_val) + return TMU_STATUS_TRIPPED; + else if (cur_temp >= data->ts.start_warning) + return TMU_STATUS_WARNING; + else if (cur_temp < data->ts.start_warning && + cur_temp >= data->ts.min_val) + return TMU_STATUS_NORMAL; + /* Temperature code does not lie between min 25 and max 125 */ + else { + gbl_info.tmu_state = TMU_STATUS_INIT; + debug("EXYNOS_TMU: Thermal reading failed\n"); + return -1; + } + return 0; +} + +/* + * Get TMU specific pre-defined values from FDT + * + * @param info pointer to the tmu_info struct + * @param blob FDT blob + * @return int value, 0 for success + */ +int get_tmu_fdt_values(struct tmu_info *info, const void *blob) +{ + int node; + int error = 0; + + /* Get the node from FDT for TMU */ + node = fdtdec_next_compatible(blob, 0, + COMPAT_SAMSUNG_EXYNOS_TMU); + if (node < 0) { + debug("EXYNOS_TMU: No node for tmu in device tree\n"); + return -1; + } + + /* + * Get the pre-defined TMU specific values from FDT. + * All of these are expected to be correct otherwise + * miscalculation of register values in tmu_setup_parameters + * may result in misleading current temperature. + */ + info->tmu_base = fdtdec_get_addr(blob, node, "reg"); + if (info->tmu_base == FDT_ADDR_T_NONE) { + debug("%s: Missing tmu-base\n", __func__); + return -1; + } + info->tmu_mux = fdtdec_get_int(blob, + node, "samsung,mux", -1); + error |= info->tmu_mux; + info->data.ts.min_val = fdtdec_get_int(blob, + node, "samsung,min-temp", -1); + error |= info->data.ts.min_val; + info->data.ts.max_val = fdtdec_get_int(blob, + node, "samsung,max-temp", -1); + error |= info->data.ts.max_val; + info->data.ts.start_warning = fdtdec_get_int(blob, + node, "samsung,start-warning", -1); + error |= info->data.ts.start_warning; + info->data.ts.start_tripping = fdtdec_get_int(blob, + node, "samsung,start-tripping", -1); + error |= info->data.ts.start_tripping; + info->data.efuse_min_value = fdtdec_get_int(blob, + node, "samsung,efuse-min-value", -1); + error |= info->data.efuse_min_value; + info->data.efuse_value = fdtdec_get_int(blob, + node, "samsung,efuse-value", -1); + error |= info->data.efuse_value; + info->data.efuse_max_value = fdtdec_get_int(blob, + node, "samsung,efuse-max-value", -1); + error |= info->data.efuse_max_value; + info->data.slope = fdtdec_get_int(blob, + node, "samsung,slope", -1); + error |= info->data.slope; + info->dc_value = fdtdec_get_int(blob, + node, "samsung,dc-value", -1); + error |= info->dc_value; + + if (error == -1) { + debug("fail to get tmu node properties\n"); + return -1; + } + + return 0; +} + +/* + * Calibrate and calculate threshold values and + * enable interrupt levels + * + * @param info pointer to the tmu_info struct + */ +void tmu_setup_parameters(struct tmu_info *info) +{ + unsigned int te_temp, con; + unsigned int warning_temp, trip_temp; + unsigned int cooling_temp; + unsigned int rising_value; + struct tmu_data *data = &info->data; + struct tmu_reg *reg = (struct tmu_reg *)info->tmu_base; + + /* Must reload for using efuse value at EXYNOS */ + writel(TRIMINFO_RELOAD, ®->triminfo_control); + + /* Get the compensation parameter */ + te_temp = readl(®->triminfo); + info->te1 = te_temp & TRIM_INFO_MASK; + info->te2 = ((te_temp >> 8) & TRIM_INFO_MASK); + + if ((data->efuse_min_value > info->te1) || + (info->te1 > data->efuse_max_value) + || (info->te2 != 0)) + info->te1 = data->efuse_value; + + /* Get RISING & FALLING Threshold value */ + warning_temp = data->ts.start_warning + + info->te1 - info->dc_value; + trip_temp = data->ts.start_tripping + + info->te1 - info->dc_value; + cooling_temp = 0; + + rising_value = ((warning_temp << 8) | (trip_temp << 16)); + + /* Set interrupt level */ + writel(rising_value, ®->threshold_temp_rise); + writel(cooling_temp, ®->threshold_temp_fall); + + /* + * Need to init all regsiter setting after getting parameter info + * [28:23] vref [11:8] slope - Tunning parameter + */ + writel(data->slope, ®->tmu_control); + + writel(INTCLEARALL, ®->intclear); + /* TMU core enable */ + con = readl(®->tmu_control); + con |= (info->tmu_mux << 20) | CORE_EN; + + writel(con, ®->tmu_control); + + /* LEV0 LEV1 LEV2 interrupt enable */ + writel(INTEN_RISE0 | INTEN_RISE1 | INTEN_RISE2, ®->inten); +} + +/* + * Initialize TMU device + * + * @param blob FDT blob + * @return int value, 0 for success + */ +int tmu_init(const void *blob) +{ + gbl_info.tmu_state = TMU_STATUS_INIT; + if (get_tmu_fdt_values(&gbl_info, blob) < 0) + return -1; + + tmu_setup_parameters(&gbl_info); + gbl_info.tmu_state = TMU_STATUS_NORMAL; + + return 0; +} diff --git a/include/tmu.h b/include/tmu.h new file mode 100644 index 0000000..17e9a85 --- /dev/null +++ b/include/tmu.h @@ -0,0 +1,46 @@ +/* + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * Akshay Saraswat akshay.s@samsung.com + * + * Thermal Management Unit + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef _TMU_H +#define _TMU_H + +enum tmu_status_t { + TMU_STATUS_INIT = 0, + TMU_STATUS_NORMAL, + TMU_STATUS_WARNING, + TMU_STATUS_TRIPPED, +}; + +/* + * Monitors status of the TMU device and exynos temperature + * + * @param temp pointer to the current temperature value + * @return enum tmu_status_t value, code indicating event to execute + * and -1 on error + */ +enum tmu_status_t tmu_monitor(int *temp); + +/* + * Initialize TMU device + * + * @param blob FDT blob + * @return int value, 0 for success + */ +int tmu_init(const void *blob); +#endif /* _THERMAL_H_ */
Dear Hatim Ali,
In message 1355223289-15685-3-git-send-email-hatim.rv@samsung.com you wrote:
From: Akshay Saraswat akshay.s@samsung.com
Adding Exynos Thermal Management Unit driver to monitor SOC temperature and take actions corresponding to states of TMU. System will shutdown if tripping temperature is reached.
Do we really need this in the boot loader?
If so, can we please implement this in a way comaptible to the existing DTT code?
Best regards,
Wolfgang Denk
From: Akshay Saraswat akshay.s@samsung.com
Adding API in power for system shutdown when tripping value is reached in Exynos Thermal Management Unit.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/arm/cpu/armv7/exynos/power.c b/arch/arm/cpu/armv7/exynos/power.c index d4bce6d..725c2d3 100644 --- a/arch/arm/cpu/armv7/exynos/power.c +++ b/arch/arm/cpu/armv7/exynos/power.c @@ -95,3 +95,18 @@ void set_dp_phy_ctrl(unsigned int enable) if (cpu_is_exynos5()) exynos5_dp_phy_control(enable); } + +/* + * This function never returns. + * When called this function makes system hang and PAD driving value high + * which in turn makes system power down in case of cold reboot. + */ +void power_shutdown(void) +{ + struct exynos5_power *power = + (struct exynos5_power *)samsung_get_base_power(); + + clrbits_le32(&power->ps_hold_control, POWER_PS_HOLD_CONTROL_DATA_HIGH); + + hang(); +} diff --git a/arch/arm/include/asm/arch-exynos/power.h b/arch/arm/include/asm/arch-exynos/power.h index d2fdb59..f069a0b 100644 --- a/arch/arm/include/asm/arch-exynos/power.h +++ b/arch/arm/include/asm/arch-exynos/power.h @@ -863,5 +863,13 @@ void set_usbhost_phy_ctrl(unsigned int enable); void set_dp_phy_ctrl(unsigned int enable);
#define EXYNOS_DP_PHY_ENABLE (1 << 0) +#define POWER_PS_HOLD_CONTROL_DATA_HIGH (1 << 8) + +/* + * This function never returns. + * When called this function makes system hang and PAD driving value high + * which in turn makes system power down in case of cold reboot. + */ +void power_shutdown(void) __attribute__ ((noreturn));
#endif
Dear Hatim Ali,
In message 1355223289-15685-4-git-send-email-hatim.rv@samsung.com you wrote:
From: Akshay Saraswat akshay.s@samsung.com
Adding API in power for system shutdown when tripping value is reached in Exynos Thermal Management Unit.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
If we add something like this, it should be general enough to be used by other systems as well, i. e. please chose a generic API like plain poweroff() or similar.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Chapter 1 -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.
Hi Hatim,
On Tue, Dec 11, 2012 at 4:43 AM, Wolfgang Denk wd@denx.de wrote:
Dear Hatim Ali,
In message 1355223289-15685-4-git-send-email-hatim.rv@samsung.com you wrote:
From: Akshay Saraswat akshay.s@samsung.com
Adding API in power for system shutdown when tripping value is reached in Exynos Thermal Management Unit.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
If we add something like this, it should be general enough to be used by other systems as well, i. e. please chose a generic API like plain poweroff() or similar.
Maybe rename the function and move to a new include/power.h header, with the implementation staying where it is?
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Chapter 1 -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Simon Glass,
In message CAPnjgZ0Biqyy-k0RBrLomKqFK6pC1rJvGTMBLuvp3wr9USsUOw@mail.gmail.com you wrote:
If we add something like this, it should be general enough to be used by other systems as well, i. e. please chose a generic API like plain poweroff() or similar.
Maybe rename the function and move to a new include/power.h header, with the implementation staying where it is?
Assuming there is no common code to be expected, yes.
Best regards,
Wolfgang Denk
From: Akshay Saraswat akshay.s@samsung.com
Adding a generic polling function to continuously monitor events and trigger actions corresponding to them.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/README b/README index 037513a..0e4083c 100644 --- a/README +++ b/README @@ -2841,6 +2841,13 @@ Configuration Settings: the application (usually a Linux kernel) when it is booted
+- CONFIG_BOARD_POLL + There are various scenarios in which parallel-thread like + polling is required to monitor status of variety of devices. + For such situations CONFIG_BOARD_POLL shall be enabled + and funtion call board_poll_devices() from console_tstc() + will then poll for the device status as defined inside function. + - CONFIG_SYS_BAUDRATE_TABLE: List of legal baudrate settings for this board.
diff --git a/common/console.c b/common/console.c index 1177f7d..d320b9b 100644 --- a/common/console.c +++ b/common/console.c @@ -117,6 +117,11 @@ static int console_tstc(int file) int i, ret; struct stdio_dev *dev;
+#if defined CONFIG_BOARD_POLL + /* Generic polling function */ + board_poll_devices(); +#endif + disable_ctrlc(1); for (i = 0; i < cd_count[file]; i++) { dev = console_devices[file][i]; diff --git a/include/common.h b/include/common.h index 5e3c5ee..b6f563b 100644 --- a/include/common.h +++ b/include/common.h @@ -778,6 +778,12 @@ void clear_ctrlc (void); /* clear the Control-C condition */ int disable_ctrlc (int); /* 1 to disable, 0 to enable Control-C detect */
/* + * A generic polling function. + * This will be called form console_tstc() to poll for various events. + */ +void board_poll_devices(void); + +/* * STDIO based functions (can always be used) */ /* serial stuff */
Dear Hatim Ali,
In message 1355223289-15685-5-git-send-email-hatim.rv@samsung.com you wrote:
From: Akshay Saraswat akshay.s@samsung.com
Adding a generic polling function to continuously monitor events and trigger actions corresponding to them.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/README b/README index 037513a..0e4083c 100644 --- a/README +++ b/README @@ -2841,6 +2841,13 @@ Configuration Settings: the application (usually a Linux kernel) when it is booted
+- CONFIG_BOARD_POLL
- There are various scenarios in which parallel-thread like
- polling is required to monitor status of variety of devices.
- For such situations CONFIG_BOARD_POLL shall be enabled
- and funtion call board_poll_devices() from console_tstc()
- will then poll for the device status as defined inside function.
Sorry, but I dislike this, for a number of reasons.
1) There is, and has always been, a very basic design decision, that U-Boot is strictly single-tasking, i. e. we don't have any kind of "background activities" goind on. Your introduction of a device polling mechanism violates this principle.
I don't say that this is unacceptable, but we have to be aware that this is a far-reaching decision, so we should consider it very carefully.
If anything like this gets implemented, it has to be done in a way that will be general enough to be useful to others as well.
2) U-Boot is a boot loader, not an OS. Do we really need continuous temperature management in U-Boot? I think not. After all, our main purpose is to boot an OS, and do that as fast as possible. The majority of users will see U-Boot running only for a few milliseconds, and only when they boot the device - which may be very seldom.
So what exactly do we need this for?
3) Your hooking of a device polling into console_tstc() is broken by design. It may be sufficient for the specific use case you have in mind here, but it is totally useless for any other purpose.
This needs a lot of additional thought, and major changes to the implementation.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Tue, Dec 11, 2012 at 4:39 AM, Wolfgang Denk wd@denx.de wrote:
Dear Hatim Ali,
In message 1355223289-15685-5-git-send-email-hatim.rv@samsung.com you wrote:
From: Akshay Saraswat akshay.s@samsung.com
Adding a generic polling function to continuously monitor events and trigger actions corresponding to them.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/README b/README index 037513a..0e4083c 100644 --- a/README +++ b/README @@ -2841,6 +2841,13 @@ Configuration Settings: the application (usually a Linux kernel) when it is booted
+- CONFIG_BOARD_POLL
There are various scenarios in which parallel-thread likepolling is required to monitor status of variety of devices.For such situations CONFIG_BOARD_POLL shall be enabledand funtion call board_poll_devices() from console_tstc()will then poll for the device status as defined inside function.Sorry, but I dislike this, for a number of reasons.
There is, and has always been, a very basic design decision, that U-Boot is strictly single-tasking, i. e. we don't have any kind of "background activities" goind on. Your introduction of a device polling mechanism violates this principle.
I don't say that this is unacceptable, but we have to be aware that this is a far-reaching decision, so we should consider it very carefully.
If anything like this gets implemented, it has to be done in a way that will be general enough to be useful to others as well.
Yes. It isn't really clear how this sort of thing should be done, but creating a board polling function seems like a reasonable idea. It's then just a question of when to call it. Since there is no particular idle or event loop in U-Boot, perhaps we need to create one, and the console code is probably the only sensible place since it is waiting for user input.
I am not sure about the general issue. Obviously some sort of background activity is going on in the chip all the time, and monitoring is sometimes necessary. I am not sure about the best approach for this.
U-Boot is a boot loader, not an OS. Do we really need continuous temperature management in U-Boot? I think not. After all, our main purpose is to boot an OS, and do that as fast as possible. The majority of users will see U-Boot running only for a few milliseconds, and only when they boot the device - which may be very seldom.
So what exactly do we need this for?
It is possible that the OS cannot be found or is corrupted due to some sort of failure or error. In that case we may need to prompt the user to insert media that can be used to recover the device. If the secure boot is turned off, we may want to print a warning and require that the user confirm. In both cases, we can be in U-Boot for a while.
By monitoring temperature we can be sure that the system does not overheat - it does depend on the hardware of course (power output, heatsinks) but it can happen very quickly, certainly within a few 10s of seconds.
- Your hooking of a device polling into console_tstc() is broken by design. It may be sufficient for the specific use case you have in mind here, but it is totally useless for any other purpose.
This needs a lot of additional thought, and major changes to the implementation.
Perhaps add a new idle function in common code which can be called from various places (including console), and itself calls board_poll_devices()? That is cosmetic, but does at least detach the code from the console.
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Without facts, the decision cannot be made logically. You must rely on your human intuition. -- Spock, "Assignment: Earth", stardate unknown _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Simon Glass,
In message CAPnjgZ3VedAoM9tkzHoHWPi9cAJ=6WQ4CDOb0zQMgi7XwGwWBQ@mail.gmail.com you wrote:
If anything like this gets implemented, it has to be done in a way that will be general enough to be useful to others as well.
Yes. It isn't really clear how this sort of thing should be done, but creating a board polling function seems like a reasonable idea. It's then just a question of when to call it. Since there is no particular idle or event loop in U-Boot, perhaps we need to create one, and the console code is probably the only sensible place since it is waiting for user input.
No, using the console driver for such a hook is not sensible at all.
Do we really have to re-invent the wheel each time we need one?
If we need a periodic service, then this should be obviously (at least this seems obvious to me) be bound to the timer services. On PPC, we could for example simply hook it in the timer interrupt.
Also, this should not be considered as somethin board specific as the name "board polling function" might suggest. What is being discussed here is not more and not less than support for periodic, asynchronous services. So let's call it that, so everybody understand what it's about.
I am not sure about the general issue. Obviously some sort of background activity is going on in the chip all the time, and monitoring is sometimes necessary. I am not sure about the best approach for this.
I agree about the "sometimes necessary". In this specific case, I doubt is this is one of these "some" cases. But I asked this before.
By monitoring temperature we can be sure that the system does not overheat - it does depend on the hardware of course (power output, heatsinks) but it can happen very quickly, certainly within a few 10s of seconds.
Is this some theoretical consideration, or does it refer to the actual state of a specific piece of hardware?
Assume we have such a system - how would it be going to be used? Example:
- power on - U-Boot enters (either directly or as a result of some boot error or similar) the interactive command line interface and waits for input from the user - temperature monitoring detects overheating - system powers down
How would one recover from that?
Would it not make much more sense to bring up the system in such a mode of operation that no overheating will happen?
This needs a lot of additional thought, and major changes to the implementation.
Perhaps add a new idle function in common code which can be called from various places (including console), and itself calls board_poll_devices()? That is cosmetic, but does at least detach the code from the console.
No. This is crap. If we need a periodic service, we should implement one, and not add hooks here and there at random. We already did this once (for the watchdog triggering), and look what a crap it is. We should not repeat this.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wed, Dec 12, 2012 at 12:44 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ3VedAoM9tkzHoHWPi9cAJ=6WQ4CDOb0zQMgi7XwGwWBQ@mail.gmail.com you wrote:
If anything like this gets implemented, it has to be done in a way that will be general enough to be useful to others as well.
Yes. It isn't really clear how this sort of thing should be done, but creating a board polling function seems like a reasonable idea. It's then just a question of when to call it. Since there is no particular idle or event loop in U-Boot, perhaps we need to create one, and the console code is probably the only sensible place since it is waiting for user input.
No, using the console driver for such a hook is not sensible at all.
Do we really have to re-invent the wheel each time we need one?
If we need a periodic service, then this should be obviously (at least this seems obvious to me) be bound to the timer services. On PPC, we could for example simply hook it in the timer interrupt.
Also, this should not be considered as somethin board specific as the name "board polling function" might suggest. What is being discussed here is not more and not less than support for periodic, asynchronous services. So let's call it that, so everybody understand what it's about.
Well that means interrupts. Are you suggesting that we implement generic timers and allow drivers to register a timer callback function to be called periodically? That seems like a bold move, but we could do it.
I am not sure about the general issue. Obviously some sort of background activity is going on in the chip all the time, and monitoring is sometimes necessary. I am not sure about the best approach for this.
I agree about the "sometimes necessary". In this specific case, I doubt is this is one of these "some" cases. But I asked this before.
By monitoring temperature we can be sure that the system does not overheat - it does depend on the hardware of course (power output, heatsinks) but it can happen very quickly, certainly within a few 10s of seconds.
Is this some theoretical consideration, or does it refer to the actual state of a specific piece of hardware?
Assume we have such a system - how would it be going to be used? Example:
- power on - U-Boot enters (either directly or as a result of some boot error or similar) the interactive command line interface and waits for input from the user - temperature monitoring detects overheating - system powers downHow would one recover from that?
Firstly we can detect that the system is idle (by noticing that it has been long time since a keypress, for example), and reduce the CPU clock speed until we next see a key. This might be enough to remove the problem. Perhaps we should add some sort of feature to console to record the time of last key input to facilitate that. There are lots of ways to do it.
Secondly, when the system warms up we can display a warning on the console, and perhaps reduce CPU speed further.
Thirdly, when the system starts to melt, we can power it off.
Would it not make much more sense to bring up the system in such a mode of operation that no overheating will happen?
Yes, but perhaps only by running very slowly. In the normal case we are only in U-Boot for a short period so want to run at full speed.
This needs a lot of additional thought, and major changes to the implementation.
Perhaps add a new idle function in common code which can be called from various places (including console), and itself calls board_poll_devices()? That is cosmetic, but does at least detach the code from the console.
No. This is crap. If we need a periodic service, we should implement one, and not add hooks here and there at random. We already did this once (for the watchdog triggering), and look what a crap it is. We should not repeat this.
Yes I'm not a big fan of putting calls everywhere, but in a sense this is pointing us towards an idle loop, something that we declare must be called periodically for U-Boot to function. A timer doesn't necessarily suit the watchdog, since we may have locked up in an infinite loop somewhere due to a s/w or h/w problem - in that case we don't want to kick the watchdog on an interval, only when we know that the system is happy.
So it seems that some sort of timer hook might be good for the patch under discussion, but for the watchdog we need an idle loop or similar. The timer hook does open a bit of a can of worms for other reasons - e.g. you are in the middle of an i2c transaction, the timer fires, you jump to the temperature monitor which wants to use i2c to find out the temperature. I thought we wanted to avoid this sort of thing in U-Boot so long as possible.
We could perhaps add an 'idle hook' so that callers can register themselves:
int idle_register_handler(int (*callback_fn)(void), void *priv); int idle_free_handler(int (*callback_fn)(void), void *priv);
define an idle handler:
void idle_poll(void) { WATCHDOG_RESET(); (loop through registered handlers and call them) }
and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.
We could perhaps have a flags parameter to permit selection of what sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog reset, IDLE_POLL_ALL to call all the registered handlers).
The hooks could then be generalised to support timers, with the proviso that timers are only ever invoked from the idle loop so that there is little possibility of strange things happening. That might get around the timer interrupt problem I mentioned above.
Any of the above is much more radical than this patch.
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de I often quote myself; it adds spice to my conversation. - G. B. Shaw
Dear Simon Glass,
In message CAPnjgZ0bmsJAx4MAk-+GLo+QLC-6zbgp24N=BNqO=2fsUikjDw@mail.gmail.com you wrote:
Also, this should not be considered as somethin board specific as the name "board polling function" might suggest. What is being discussed here is not more and not less than support for periodic, asynchronous services. So let's call it that, so everybody understand what it's about.
Well that means interrupts. Are you suggesting that we implement generic timers and allow drivers to register a timer callback function to be called periodically? That seems like a bold move, but we could do it.
Which architectures do not use interrupts for the timer services?
How would one recover from that?
Firstly we can detect that the system is idle (by noticing that it has been long time since a keypress, for example), and reduce the CPU clock speed until we next see a key. This might be enough to remove the problem. Perhaps we should add some sort of feature to console to
No, this is just a crappy design.
Assume you load some big image and write it to NAND (or you do other operations that take some time; eventually in a loop). Your keyboard dependet code would not trigger here, and you would just overheat the system.
I mean, what good is such protection when a simple "while : ; do : ; done" will just toast your box?
record the time of last key input to facilitate that. There are lots of ways to do it.
Sorry, but keyboard activity has _nothing_ to do ith it and is the totally wrong place to attach such functionality to.
Secondly, when the system warms up we can display a warning on the console, and perhaps reduce CPU speed further.
Thirdly, when the system starts to melt, we can power it off.
Would you ever buy such a design? I wouldn't. And any competing company would probably have excellent arguments for their own marketing material.
So it seems that some sort of timer hook might be good for the patch under discussion, but for the watchdog we need an idle loop or
I don;t understand your arguments here. You are aware that we don;t really have watchdog support in U-Boot (not in the sense that we monitor U-Boot's operation) - we only make sure to trigger it periodically.
similar. The timer hook does open a bit of a can of worms for other reasons - e.g. you are in the middle of an i2c transaction, the timer fires, you jump to the temperature monitor which wants to use i2c to find out the temperature. I thought we wanted to avoid this sort of thing in U-Boot so long as possible.
Yes, we definitely do want to avoid this, which is the reson why I insist on asking of we actually need such a feature in U-Boot. If the hardware cannot protect itself sufficiently and relies on software support, you are doomed anyway, because somebody will always just do some stupid things and find out that he detected a HCF macro...
We could perhaps add an 'idle hook' so that callers can register themselves:
Where exactly would you hook that to, if not to some timer interrupt?
ANd please tink about this again - if you talk about an 'idle hook', you actually are talking about an "idle task", i. e. about introducing a multi-task concept (even if it's just a simple one).
This is not exactly a small can of worms, and I guess these worms have a smell ...
and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.
Oh. Cooperative multitasking...
Are you really, really sure we want to do that?
We could perhaps have a flags parameter to permit selection of what sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog reset, IDLE_POLL_ALL to call all the registered handlers).
The hooks could then be generalised to support timers, with the proviso that timers are only ever invoked from the idle loop so that
Yes, we can do all that. We can actually implement a full-blown OS.
Are you really, really sure we want to do that?
Any of the above is much more radical than this patch.
But the patch as submitted here is not even functional...
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wed, Dec 12, 2012 at 2:11 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ0bmsJAx4MAk-+GLo+QLC-6zbgp24N=BNqO=2fsUikjDw@mail.gmail.com you wrote:
Also, this should not be considered as somethin board specific as the name "board polling function" might suggest. What is being discussed here is not more and not less than support for periodic, asynchronous services. So let's call it that, so everybody understand what it's about.
Well that means interrupts. Are you suggesting that we implement generic timers and allow drivers to register a timer callback function to be called periodically? That seems like a bold move, but we could do it.
Which architectures do not use interrupts for the timer services?
For example some ARM implementations just have a hardware counter that we can read. It doesn't roll over so no need for interrupts.
How would one recover from that?
Firstly we can detect that the system is idle (by noticing that it has been long time since a keypress, for example), and reduce the CPU clock speed until we next see a key. This might be enough to remove the problem. Perhaps we should add some sort of feature to console to
No, this is just a crappy design.
Assume you load some big image and write it to NAND (or you do other operations that take some time; eventually in a loop). Your keyboard dependet code would not trigger here, and you would just overheat the system.
I mean, what good is such protection when a simple "while : ; do : ; done" will just toast your box?
Well it will force a hard power off - the hardware has a hard limit at which it will power off. Don't do that! The more common case is the user sitting at a prompt doing nothing, and that's the case which prompted this patch I think.
record the time of last key input to facilitate that. There are lots of ways to do it.
Sorry, but keyboard activity has _nothing_ to do ith it and is the totally wrong place to attach such functionality to.
Can you suggest an alternative place which gives us an indicator of user activity?
Secondly, when the system warms up we can display a warning on the console, and perhaps reduce CPU speed further.
Thirdly, when the system starts to melt, we can power it off.
Would you ever buy such a design? I wouldn't. And any competing company would probably have excellent arguments for their own marketing material.
So long as it had some fail safe power off when things get hot it is ok. But we need to try to avoid getting into that condition. Running flat out at 1.7GHz waiting for keyboard input that may never come is not good design.
So it seems that some sort of timer hook might be good for the patch under discussion, but for the watchdog we need an idle loop or
I don;t understand your arguments here. You are aware that we don;t really have watchdog support in U-Boot (not in the sense that we monitor U-Boot's operation) - we only make sure to trigger it periodically.
Yes I was responding to your complaint about how watchdogs currently work. It is ugly that things like hashing functions need a parameter telling them when to reset, and have watchdog calls in the algorithm.
similar. The timer hook does open a bit of a can of worms for other reasons - e.g. you are in the middle of an i2c transaction, the timer fires, you jump to the temperature monitor which wants to use i2c to find out the temperature. I thought we wanted to avoid this sort of thing in U-Boot so long as possible.
Yes, we definitely do want to avoid this, which is the reson why I insist on asking of we actually need such a feature in U-Boot. If the hardware cannot protect itself sufficiently and relies on software support, you are doomed anyway, because somebody will always just do some stupid things and find out that he detected a HCF macro...
Hopefully we have covered this now. HCF will cause a hard power off eventually, but we don't want sitting idle at the prompt to be equivalent to HCF.
We could perhaps add an 'idle hook' so that callers can register themselves:
Where exactly would you hook that to, if not to some timer interrupt?
Console input, places where the watchdog is currently reset, for example.
ANd please tink about this again - if you talk about an 'idle hook', you actually are talking about an "idle task", i. e. about introducing a multi-task concept (even if it's just a simple one).
This is not exactly a small can of worms, and I guess these worms have a smell ...
and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.
Oh. Cooperative multitasking...
Are you really, really sure we want to do that?
Actually I was happy enough with a simple patch to indicate idle in the console code :-)
We could perhaps have a flags parameter to permit selection of what sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog reset, IDLE_POLL_ALL to call all the registered handlers).
The hooks could then be generalised to support timers, with the proviso that timers are only ever invoked from the idle loop so that
Yes, we can do all that. We can actually implement a full-blown OS.
Are you really, really sure we want to do that?
<1> <2> <3> <4> this patch idle support co-op multitasking full-blown OS
Please choose :/) I think you are saying that <1> is too much of a hack. Clearly <4> is not why we are here. I suggest <1>, or failing that, <2>. I think <3> is scary and I think there is clear daylight between <2> and <3>.
But if you can accept that this feature is useful, how would you implement it?
Any of the above is much more radical than this patch.
But the patch as submitted here is not even functional...
It seems to work as intended, albeit I'm sure there are flaws.
Best regards,
Wolfgang Denk
--
Regards, Simon
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Weekends were made for programming. - Karl Lehenbauer
Dear Simon Glass,
In message CAPnjgZ05L+CpbQphaD6Of3zR1hst2YL3pK86=yMC79UtRxvjXQ@mail.gmail.com you wrote:
I mean, what good is such protection when a simple "while : ; do : ; done" will just toast your box?
Well it will force a hard power off - the hardware has a hard limit at which it will power off. Don't do that! The more common case is the user sitting at a prompt doing nothing, and that's the case which prompted this patch I think.
Let me summarize the facts and arguments as far as I understand these so far:
- There is built-in hardware protection; if we don't apply this patch, nothing gets broken, but the system will power off when overheating.
- The normal mode of operation s to boot an OS as quickly as possible, without any user interaction, so this patch is not needed, nor would the code be used at all.
- In the few cases where we don't boot an OS quickly, we assume that the only long-running activity that needs protection is waiting for user input.
- If we spend too much time in U-Boot and te system overheats, then we power it down.
I have these comments:
* The assumption, that only waiting for keyboard input is a critical operation, is obviously broken.
* If we just power down, we can as well use the hardware-triggered power down; the effect would be the same?
I can only repeat myself: - what would be needed here is an asynchronous (periodic) service - hooking this onto keyboard activity is broken by design - we don't have any other generic mechanism to implement such a feature yet.
Sorry, but keyboard activity has _nothing_ to do ith it and is the totally wrong place to attach such functionality to.
Can you suggest an alternative place which gives us an indicator of user activity?
Please stop thinking about user activity. It has _nothing_ to do with it. What you are looking for is a time triggered service - you want to make sure to run your temperature control code at least every N milliseconds.
So long as it had some fail safe power off when things get hot it is ok. But we need to try to avoid getting into that condition. Running flat out at 1.7GHz waiting for keyboard input that may never come is not good design.
Why are we running at such a high clock anyway in U-Boot? Most activities in U-Boot are limited by I/O troughput and/or memory bandwidth. There are very few exceptions: uncompressing and checksumming an OS image when boting it are such; at the moment I cannot think of any other that might be significant in the sense that they would play any role for boot times in the majority of use cases (just booting an OS).
So why not simply run U-Boot at a much lower clock? Has anybody measured how many milliseconds of boot time that would cost?
And, if needed, you could still rev up the clock rate when actually running the bootm code where speed actually plays a role...
Actually I was happy enough with a simple patch to indicate idle in the console code :-)
I fail to understand why you don't accept the fact that this does not even work?
<1> <2> <3> <4> this patch idle support co-op multitasking full-blown OS
Please choose :/) I think you are saying that <1> is too much of a hack. Clearly <4> is not why we are here. I suggest <1>, or failing that, <2>. I think <3> is scary and I think there is clear daylight between <2> and <3>.
My vote is to none of this.
But if you can accept that this feature is useful, how would you implement it?
I am pretty much convinced that the chosen approach is wrong, and that we do no actually need any such feature here.
I am very sure that hooking this into console code is totally wrong, as the heating up takes place independent of any user interaction.
I also challenge the assumption that periodic polling is needed. I don't know the hardware inplace, but most likely it is capable of actively signalling that overheating takes place - I guess you can program a maximum temperatrue and it will raise an interrupt if this is reached? If so, temperature control should be implemented in an event-driven way, and not using polling.
If in the end we still should find we need to implement an asynchronous, time-triggered service, then this should be implemented based on a periodic timer interrupt.
But the patch as submitted here is not even functional...
It seems to work as intended, albeit I'm sure there are flaws.
It works only as long as you do not anything which cases U-Boot to run for too long before returning to the console - and run time is totally out of your control. In other words: it is just good for a demo and to collect brownie points from some bosses. Would you drive a car where the operation of the safety belt was similarly reliable?
Best regards,
Wolfgang Denk
From: Akshay Saraswat akshay.s@samsung.com
This adds call to tmu_init() and TMU status polling in board_poll_devices() funtion to monitor temperature change of the SOC.
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/board/samsung/smdk5250/smdk5250.c b/board/samsung/smdk5250/smdk5250.c index ac7346d..db2457b 100644 --- a/board/samsung/smdk5250/smdk5250.c +++ b/board/samsung/smdk5250/smdk5250.c @@ -32,15 +32,51 @@ #include <asm/arch/pinmux.h> #include <asm/arch/sromc.h> #include <pmic.h> +#include <tmu.h> +#include <asm/arch/exynos-tmu.h> +#include <asm/arch/power.h>
DECLARE_GLOBAL_DATA_PTR;
+/* + * Polling various devices on board for details and status monitoring purposes + */ +void board_poll_devices(void) +{ +#if defined CONFIG_EXYNOS_TMU + int temp; + + switch (tmu_monitor(&temp)) { + case TMU_STATUS_TRIPPED: + puts("EXYNOS_TMU: TRIPPING! Device power going down ...\n"); + power_shutdown(); + break; + case TMU_STATUS_WARNING: + puts("EXYNOS_TMU: WARNING! Temperature very high\n"); + break; + case TMU_STATUS_INIT: + case TMU_STATUS_NORMAL: + break; + default: + debug("Unknown TMU state\n"); + } +#endif +} + int board_init(void) { gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL); #if defined(CONFIG_PMIC) pmic_init(); #endif + +#if defined CONFIG_EXYNOS_TMU + if (tmu_init(gd->fdt_blob)) { + debug("%s: Failed to init TMU\n", __func__); + return -1; + } +#endif + #ifdef CONFIG_EXYNOS_SPI spi_init(); #endif
From: Akshay Saraswat akshay.s@samsung.com
Enables TMU driver support for exynos5250
Signed-off-by: Akshay Saraswat akshay.s@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 12f555c..2f4315a 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -106,6 +106,12 @@ #define CONFIG_BOOTDELAY 3 #define CONFIG_ZERO_BOOTDELAY_CHECK
+/* Generic Device Polling */ +#define CONFIG_BOARD_POLL + +/* Thermal Management Unit */ +#define CONFIG_EXYNOS_TMU + /* USB */ #define CONFIG_CMD_USB #define CONFIG_USB_EHCI
From: Alim Akhtar alim.akhtar@samsung.com
Adds a new u-boot command to read current temprature from tmu driver.
Signed-off-by: Alim Akhtar alim.akhtar@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/README b/README index 0e4083c..d3e7ea3 100644 --- a/README +++ b/README @@ -3877,6 +3877,7 @@ icache - enable or disable instruction cache dcache - enable or disable data cache reset - Perform RESET of the CPU echo - echo args to console +tmu - measurement values by Thermal Management Unit version - print monitor version help - print online help ? - alias for 'help' diff --git a/common/Makefile b/common/Makefile index ded6318..93dc65a 100644 --- a/common/Makefile +++ b/common/Makefile @@ -155,6 +155,7 @@ COBJS-$(CONFIG_CMD_STRINGS) += cmd_strings.o COBJS-$(CONFIG_CMD_TERMINAL) += cmd_terminal.o COBJS-$(CONFIG_CMD_TIME) += cmd_time.o COBJS-$(CONFIG_SYS_HUSH_PARSER) += cmd_test.o +COBJS-$(CONFIG_CMD_TMU) += cmd_tmu.o COBJS-$(CONFIG_CMD_TPM) += cmd_tpm.o COBJS-$(CONFIG_CMD_TSI148) += cmd_tsi148.o COBJS-$(CONFIG_CMD_UBI) += cmd_ubi.o diff --git a/common/cmd_tmu.c b/common/cmd_tmu.c new file mode 100644 index 0000000..836e457 --- /dev/null +++ b/common/cmd_tmu.c @@ -0,0 +1,51 @@ +/* + * Copyright (C) 2012 Samsung Electronics + * Alim Akhtar alim.akhtar@samsung.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <command.h> +#include <tmu.h> + +int do_tmu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) +{ + int cur_temp; + + if (argc < 2) + return CMD_RET_USAGE; + + if (strcmp(argv[1], "curtemp") == 0) { + if (tmu_monitor(&cur_temp) == -1) + printf("TMU is in unknown state,temperature invalid\n"); + else + printf("Current temperature: %u Celsius\n", cur_temp); + } else { + return CMD_RET_USAGE; + } + + return 0; +} + +U_BOOT_CMD( + tmu, 2, 1, do_tmu, + "Thermal Management Unit\n", + "curtemp - show current CPU temperature in degrees Celsius\n" +);
Dear Hatim Ali,
In message 1355223289-15685-8-git-send-email-hatim.rv@samsung.com you wrote:
From: Alim Akhtar alim.akhtar@samsung.com
Adds a new u-boot command to read current temprature from tmu driver.
Signed-off-by: Alim Akhtar alim.akhtar@samsung.com Acked-by: Simon Glass sjg@chromium.org
Do we really need a new command here?
We already have dtt, which basicly does the same.
It makes no sense to add new commands for each new device, all doing basicly trhe same, just in an incompatible way.
Best regards,
Wolfgang Denk
Hi,
On Tue, Dec 11, 2012 at 4:30 AM, Wolfgang Denk wd@denx.de wrote:
Dear Hatim Ali,
In message 1355223289-15685-8-git-send-email-hatim.rv@samsung.com you wrote:
From: Alim Akhtar alim.akhtar@samsung.com
Adds a new u-boot command to read current temprature from tmu driver.
Signed-off-by: Alim Akhtar alim.akhtar@samsung.com Acked-by: Simon Glass sjg@chromium.org
Do we really need a new command here?
We already have dtt, which basicly does the same.
It makes no sense to add new commands for each new device, all doing basicly trhe same, just in an incompatible way.
This patch feature does not use i2c as the temperature measurement is inside the SOC. I wonder whether cmd_dtt.c could be extended so that it only does the i2c stuff if CONFIG_SYS_DTT_BUS_NUM is defined. Then you could use dtt_get_temp() to get the termperature as now.
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de The explanation requiring the fewest assumptions is the most likely to be correct. -- William of Occam _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Simon Glass,
In message CAPnjgZ18daUnwQtAxtPOU43EGLA7=tN0EFUtbBzKNTDY8DA-sQ@mail.gmail.com you wrote:
Do we really need a new command here?
We already have dtt, which basicly does the same.
It makes no sense to add new commands for each new device, all doing basicly trhe same, just in an incompatible way.
This patch feature does not use i2c as the temperature measurement is inside the SOC. I wonder whether cmd_dtt.c could be extended so that it only does the i2c stuff if CONFIG_SYS_DTT_BUS_NUM is defined. Then you could use dtt_get_temp() to get the termperature as now.
Dtt should actually be completely agnostic of the underlying method to access the devices it operates on. If such generalization is needed now, then yes, it should be added.
Best regards,
Wolfgang Denk
From: Alim Akhtar alim.akhtar@samsung.com
This enables the tmu command to read the current SOC temperature with the help of TMU
Signed-off-by: Alim Akhtar alim.akhtar@samsung.com Acked-by: Simon Glass sjg@chromium.org
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 2f4315a..2b9271c 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -111,6 +111,7 @@
/* Thermal Management Unit */ #define CONFIG_EXYNOS_TMU +#define CONFIG_CMD_TMU
/* USB */ #define CONFIG_CMD_USB
participants (3)
-
Hatim Ali -
Simon Glass -
Wolfgang Denk