[U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit

[U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit

[Hatim Ali]

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>

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..ad9e394
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
@@ -0,0 +1,82 @@
+/*
+ * 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_THERMAL_H
+#define __ASM_ARCH_THERMAL_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;
+};
+
+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
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..ee596d5
--- /dev/null
+++ b/drivers/power/exynos-tmu.c
@@ -0,0 +1,296 @@
+/*
+ * 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 <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(&reg->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, &reg->triminfo_control);
+
+	/* Get the compensation parameter */
+	te_temp = readl(&reg->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, &reg->threshold_temp_rise);
+	writel(cooling_temp, &reg->threshold_temp_fall);
+
+	/*
+	 * Need to init all regsiter setting after getting parameter info
+	 * [28:23] vref [11:8] slope - Tunning parameter
+	 */
+	writel(data->slope, &reg->tmu_control);
+
+	writel(INTCLEARALL, &reg->intclear);
+	/* TMU core enable */
+	con = readl(&reg->tmu_control);
+	con |= (info->tmu_mux << 20) | CORE_EN;
+
+	writel(con, &reg->tmu_control);
+
+	/* LEV0 LEV1 LEV2 interrupt enable */
+	writel(INTEN_RISE0 | INTEN_RISE1 | INTEN_RISE2,	&reg->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;
+}
-- 
1.7.2.3

[U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit

[Simon Glass]

On Tue, Nov 6, 2012 at 2:18 AM, Hatim Ali <hatim.rv@samsung.com> 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.
>
> Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>

Acked-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250

[Hatim Ali]

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

-- 
1.7.2.3

[U-Boot] [PATCH 1/8] EXYNOS5: FDT: Add TMU device node values

[Hatim Ali]

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 at 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 at 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 at 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

[U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit

[Hatim Ali]

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(&reg->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, &reg->triminfo_control);
+
+	/* Get the compensation parameter */
+	te_temp = readl(&reg->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, &reg->threshold_temp_rise);
+	writel(cooling_temp, &reg->threshold_temp_fall);
+
+	/*
+	 * Need to init all regsiter setting after getting parameter info
+	 * [28:23] vref [11:8] slope - Tunning parameter
+	 */
+	writel(data->slope, &reg->tmu_control);
+
+	writel(INTCLEARALL, &reg->intclear);
+	/* TMU core enable */
+	con = readl(&reg->tmu_control);
+	con |= (info->tmu_mux << 20) | CORE_EN;
+
+	writel(con, &reg->tmu_control);
+
+	/* LEV0 LEV1 LEV2 interrupt enable */
+	writel(INTEN_RISE0 | INTEN_RISE1 | INTEN_RISE2,	&reg->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_ */
-- 
1.7.2.3

[U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit

[Hatim Ali]

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
-- 
1.7.2.3

[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Hatim Ali]

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 */
-- 
1.7.2.3

[U-Boot] [PATCH 5/8] EXYNOS5: TMU: Add TMU status polling

[Hatim Ali]

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
-- 
1.7.2.3

[U-Boot] [PATCH 6/8] EXYNOS5: Config: Enable support for Exynos TMU driver

[Hatim Ali]

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
-- 
1.7.2.3

[U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp

[Hatim Ali]

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"
+);
-- 
1.7.2.3

[U-Boot] [PATCH 8/8] EXYNOS5: Config: Enable tmu command

[Hatim Ali]

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
-- 
1.7.2.3

[U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp

[Wolfgang Denk]

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

-- 
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 at denx.de
The explanation requiring the fewest assumptions is the  most  likely
to be correct.                                    -- William of Occam

[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Wolfgang Denk]

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

-- 
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 at denx.de
Without facts, the decision cannot be made logically. You  must  rely
on your human intuition.
	-- Spock, "Assignment: Earth", stardate unknown

[U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit

[Wolfgang Denk]

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

-- 
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 at denx.de
"Beware of bugs in the above code; I have only proved it correct, not
tried it."                                             - Donald Knuth

[U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit

[Wolfgang Denk]

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 at 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] [PATCH 7/8] TMU: Add u-boot command to read current temp

[Simon Glass]

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 at denx.de
> The explanation requiring the fewest assumptions is the  most  likely
> to be correct.                                    -- William of Occam
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit

[Simon Glass]

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 at 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Simon Glass]

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 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.

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.

>
> 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?

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.

>
> 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.

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 at 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/8] EXYNOS5: FDT: Add TMU device node values

[Simon Glass]

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 at 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 at 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 at 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

[U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp

[Wolfgang Denk]

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

-- 
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 at denx.de
"I used to think that the brain was the most wonderful  organ  in  my
body. Then I realized who was telling me this."        - Emo Phillips

[U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit

[Wolfgang Denk]

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

-- 
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 at denx.de
Only two things are infinite,  the universe and human stupidity,  and
I'm not sure about the former.                     -- Albert Einstein

[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Wolfgang Denk]

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

-- 
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 at denx.de
I often quote myself; it adds spice to my conversation.  - G. B. Shaw

[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Simon Glass]

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 down
>
> 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
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 at denx.de
> I often quote myself; it adds spice to my conversation.  - G. B. Shaw

[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Wolfgang Denk]

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

-- 
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 at denx.de
Weekends were made for programming.                 - Karl Lehenbauer

[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Simon Glass]

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 at denx.de
> Weekends were made for programming.                 - Karl Lehenbauer

[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Wolfgang Denk]

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

-- 
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 at denx.de
I mean, I . . . think to understand you, I just don't know  what  you
are saying ...                        - Terry Pratchett, _Soul Music_