* [U-Boot] [PATCH 1/8] EXYNOS5: FDT: Add TMU device node values
2012-12-11 10:54 [U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
@ 2012-12-11 10:54 ` Hatim Ali
2012-12-12 14:51 ` Simon Glass
2012-12-11 10:54 ` [U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit Hatim Ali
` (6 subsequent siblings)
7 siblings, 1 reply; 26+ messages in thread
From: Hatim Ali @ 2012-12-11 10:54 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH 1/8] EXYNOS5: FDT: Add TMU device node values
2012-12-11 10:54 ` [U-Boot] [PATCH 1/8] EXYNOS5: FDT: Add TMU device node values Hatim Ali
@ 2012-12-12 14:51 ` Simon Glass
0 siblings, 0 replies; 26+ messages in thread
From: Simon Glass @ 2012-12-12 14:51 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit
2012-12-11 10:54 [U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
2012-12-11 10:54 ` [U-Boot] [PATCH 1/8] EXYNOS5: FDT: Add TMU device node values Hatim Ali
@ 2012-12-11 10:54 ` Hatim Ali
2012-12-11 12:41 ` Wolfgang Denk
2012-12-11 10:54 ` [U-Boot] [PATCH 3/8] EXYNOS5: Power down API " Hatim Ali
` (5 subsequent siblings)
7 siblings, 1 reply; 26+ messages in thread
From: Hatim Ali @ 2012-12-11 10:54 UTC (permalink / raw)
To: u-boot
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_ */
--
1.7.2.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit
2012-12-11 10:54 ` [U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit Hatim Ali
@ 2012-12-11 12:41 ` Wolfgang Denk
0 siblings, 0 replies; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-11 12:41 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit
2012-12-11 10:54 [U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
2012-12-11 10:54 ` [U-Boot] [PATCH 1/8] EXYNOS5: FDT: Add TMU device node values Hatim Ali
2012-12-11 10:54 ` [U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit Hatim Ali
@ 2012-12-11 10:54 ` Hatim Ali
2012-12-11 12:43 ` Wolfgang Denk
2012-12-11 10:54 ` [U-Boot] [PATCH 4/8] Add a poll function to monitor events Hatim Ali
` (4 subsequent siblings)
7 siblings, 1 reply; 26+ messages in thread
From: Hatim Ali @ 2012-12-11 10:54 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit
2012-12-11 10:54 ` [U-Boot] [PATCH 3/8] EXYNOS5: Power down API " Hatim Ali
@ 2012-12-11 12:43 ` Wolfgang Denk
2012-12-12 14:00 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-11 12:43 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit
2012-12-11 12:43 ` Wolfgang Denk
@ 2012-12-12 14:00 ` Simon Glass
2012-12-12 20:27 ` Wolfgang Denk
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2012-12-12 14:00 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit
2012-12-12 14:00 ` Simon Glass
@ 2012-12-12 20:27 ` Wolfgang Denk
0 siblings, 0 replies; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-12 20:27 UTC (permalink / raw)
To: 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
--
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 4/8] Add a poll function to monitor events
2012-12-11 10:54 [U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
` (2 preceding siblings ...)
2012-12-11 10:54 ` [U-Boot] [PATCH 3/8] EXYNOS5: Power down API " Hatim Ali
@ 2012-12-11 10:54 ` Hatim Ali
2012-12-11 12:39 ` Wolfgang Denk
2012-12-11 10:54 ` [U-Boot] [PATCH 5/8] EXYNOS5: TMU: Add TMU status polling Hatim Ali
` (3 subsequent siblings)
7 siblings, 1 reply; 26+ messages in thread
From: Hatim Ali @ 2012-12-11 10:54 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH 4/8] Add a poll function to monitor events
2012-12-11 10:54 ` [U-Boot] [PATCH 4/8] Add a poll function to monitor events Hatim Ali
@ 2012-12-11 12:39 ` Wolfgang Denk
2012-12-12 14:14 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-11 12:39 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 4/8] Add a poll function to monitor events
2012-12-11 12:39 ` Wolfgang Denk
@ 2012-12-12 14:14 ` Simon Glass
2012-12-12 20:44 ` Wolfgang Denk
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2012-12-12 14:14 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 4/8] Add a poll function to monitor events
2012-12-12 14:14 ` Simon Glass
@ 2012-12-12 20:44 ` Wolfgang Denk
2012-12-12 21:07 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-12 20:44 UTC (permalink / raw)
To: 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
--
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 4/8] Add a poll function to monitor events
2012-12-12 20:44 ` Wolfgang Denk
@ 2012-12-12 21:07 ` Simon Glass
2012-12-12 22:11 ` Wolfgang Denk
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2012-12-12 21:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread* [U-Boot] [PATCH 4/8] Add a poll function to monitor events
2012-12-12 21:07 ` Simon Glass
@ 2012-12-12 22:11 ` Wolfgang Denk
2012-12-12 23:34 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-12 22:11 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 4/8] Add a poll function to monitor events
2012-12-12 22:11 ` Wolfgang Denk
@ 2012-12-12 23:34 ` Simon Glass
2012-12-13 10:23 ` Wolfgang Denk
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2012-12-12 23:34 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 4/8] Add a poll function to monitor events
2012-12-12 23:34 ` Simon Glass
@ 2012-12-13 10:23 ` Wolfgang Denk
0 siblings, 0 replies; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-13 10:23 UTC (permalink / raw)
To: u-boot
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_
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 5/8] EXYNOS5: TMU: Add TMU status polling
2012-12-11 10:54 [U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
` (3 preceding siblings ...)
2012-12-11 10:54 ` [U-Boot] [PATCH 4/8] Add a poll function to monitor events Hatim Ali
@ 2012-12-11 10:54 ` Hatim Ali
2012-12-11 10:54 ` [U-Boot] [PATCH 6/8] EXYNOS5: Config: Enable support for Exynos TMU driver Hatim Ali
` (2 subsequent siblings)
7 siblings, 0 replies; 26+ messages in thread
From: Hatim Ali @ 2012-12-11 10:54 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH 6/8] EXYNOS5: Config: Enable support for Exynos TMU driver
2012-12-11 10:54 [U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
` (4 preceding siblings ...)
2012-12-11 10:54 ` [U-Boot] [PATCH 5/8] EXYNOS5: TMU: Add TMU status polling Hatim Ali
@ 2012-12-11 10:54 ` Hatim Ali
2012-12-11 10:54 ` [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp Hatim Ali
2012-12-11 10:54 ` [U-Boot] [PATCH 8/8] EXYNOS5: Config: Enable tmu command Hatim Ali
7 siblings, 0 replies; 26+ messages in thread
From: Hatim Ali @ 2012-12-11 10:54 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp
2012-12-11 10:54 [U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
` (5 preceding siblings ...)
2012-12-11 10:54 ` [U-Boot] [PATCH 6/8] EXYNOS5: Config: Enable support for Exynos TMU driver Hatim Ali
@ 2012-12-11 10:54 ` Hatim Ali
2012-12-11 12:30 ` Wolfgang Denk
2012-12-11 10:54 ` [U-Boot] [PATCH 8/8] EXYNOS5: Config: Enable tmu command Hatim Ali
7 siblings, 1 reply; 26+ messages in thread
From: Hatim Ali @ 2012-12-11 10:54 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp
2012-12-11 10:54 ` [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp Hatim Ali
@ 2012-12-11 12:30 ` Wolfgang Denk
2012-12-12 13:57 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-11 12:30 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp
2012-12-11 12:30 ` Wolfgang Denk
@ 2012-12-12 13:57 ` Simon Glass
2012-12-12 20:26 ` Wolfgang Denk
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2012-12-12 13:57 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp
2012-12-12 13:57 ` Simon Glass
@ 2012-12-12 20:26 ` Wolfgang Denk
0 siblings, 0 replies; 26+ messages in thread
From: Wolfgang Denk @ 2012-12-12 20:26 UTC (permalink / raw)
To: 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
--
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 8/8] EXYNOS5: Config: Enable tmu command
2012-12-11 10:54 [U-Boot] [PATCH 0/8 v4] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
` (6 preceding siblings ...)
2012-12-11 10:54 ` [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp Hatim Ali
@ 2012-12-11 10:54 ` Hatim Ali
7 siblings, 0 replies; 26+ messages in thread
From: Hatim Ali @ 2012-12-11 10:54 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 2/8] EXYNOS5: TMU: Add driver for Thermal Management Unit
2012-11-06 10:18 [U-Boot] [PATCH 0/8] Add TMU support for Exynos5250 based SMDK5250 Hatim Ali
@ 2012-11-06 10:18 ` Hatim Ali
2012-11-07 0:03 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Hatim Ali @ 2012-11-06 10:18 UTC (permalink / raw)
To: u-boot
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(®->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;
+}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 26+ messages in thread