Re: What is right git tree/ branch for imx28/evk device tree work?
Hi Subodh, On 11 May 2012 18:03, Subodh Nijsure wrote: > > Sounds like a very basic question, I would like to test some of the recent > patches related to mx28 for freescale EVK board. > ( Some thing like - https://lkml.org/lkml/2012/3/13/176 ) > > Is there specific branch one should be looking for in > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git? Or these > changes are being staged some place other than arm-soc.git? > I plan to send my mxs/dt/for-3.5 branch to arm-soc soon. Before that happens, you can play the branch below, which has various dependencies solved there. git://git.linaro.org/people/shawnguo/linux-2.6.git mxs/dt/test Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v4 5/5] ARM: exynos: Add thermal sensor driver platform data support
This patch adds necessary default platform data support needed for TMU driver.
This dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms.
Signed-off-by: Amit Daniel Kachhap
---
drivers/thermal/exynos_thermal.c | 111 +-
1 files changed, 110 insertions(+), 1 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 48106d8..e4e6759 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -662,14 +662,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static struct thermal_sensor_conf exynos_sensor_conf = {
.name = "exynos-therm",
.read_temperature = (int (*)(void *))exynos_tmu_read,
+};
+
+#if defined(CONFIG_CPU_EXYNOS4210)
+static struct exynos_tmu_platform_data const exynos4_default_tmu_data = {
+ .threshold = 80,
+ .trigger_levels[0] = 5,
+ .trigger_levels[1] = 20,
+ .trigger_levels[2] = 30,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 15,
+ .reference_voltage = 7,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 100,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS4,
+};
+#define EXYNOS4_TMU_DRV_DATA (&exynos4_default_tmu_data)
+#else
+#define EXYNOS4_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250)
+static struct exynos_tmu_platform_data const exynos5_default_tmu_data = {
+ .trigger_levels[0] = 85,
+ .trigger_levels[1] = 103,
+ .trigger_levels[2] = 110,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 8,
+ .reference_voltage = 16,
+ .noise_cancel_mode = 4,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .efuse_value = 55,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 103,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS5,
+};
+#define EXYNOS5_TMU_DRV_DATA (&exynos5_default_tmu_data)
+#else
+#define EXYNOS5_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+ {
+ .compatible = "samsung,exynos4-tmu",
+ .data = (void *)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .compatible = "samsung,exynos5-tmu",
+ .data = (void *)EXYNOS5_TMU_DRV_DATA,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_tmu_match);
+#else
+#define exynos_tmu_match NULL
+#endif
+
+static struct platform_device_id exynos_tmu_driver_ids[] = {
+ {
+ .name = "exynos4-tmu",
+ .driver_data= (kernel_ulong_t)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .name = "exynos5-tmu",
+ .driver_data= (kernel_ulong_t)EXYNOS5_TMU_DRV_DATA,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
+
+static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+ if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(exynos_tmu_match, pdev->dev.of_node);
+ if (!match)
+ return NULL;
+ return (struct exynos_tmu_platform_data *) match->data;
+ }
+#endif
+ return (struct exynos_tmu_platform_data *)
+ platform_get_device_id(pdev)->driver_data;
}
-;
static int __devinit exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
struct exynos_tmu_platform_data *pdata = pdev->dev.platform_data;
int ret, i;
+ if (!pdata)
+ pdata = exynos_get_driver_data(pdev);
+
if (!pdata) {
dev_err(&pdev->dev, "No platform init data supplied.\n");
return -ENODEV;
@@ -832,11 +939,13 @@ static struct platform_driver exynos_tmu_driver = {
.driver = {
.name = "exynos-tmu",
.owner = THIS_MODULE,
+ .of_match_table = exynos_tmu_match,
},
.probe = exynos_tmu_probe,
.remove = __devexit_p(exynos_tmu_remove),
.suspend = exynos_tmu_suspend,
.resume = exynos_tmu_resume,
+ .id_table = exynos_tmu_driver_ids,
};
module_platform_driver(exynos_tmu_driver);
--
1.7.1
___
linaro-dev mailing list
linaro
[PATCH v4 0/5] thermal: exynos: Add kernel thermal support for exynos platform
Hi Andrew/Rui, As discussed with Rui Zhang, I dropped the patch for new trip type THERMAL_TRIP_STATE_INSTANCE and made the necessary state magnagement changes in cpufreq cooling functions. Also I fixed all the review comments suggested by Andrew. If any other changes please let me know. This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal) * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) The is a small change in cpufreq cooling registration APIs, so a minor change is needed for OMAP and Freescale platforms. Thanks, Amit Daniel Changes since V3: * Dropped the concept of using new trip type THERMAL_TRIP_STATE_INSTANCE as discussed with Rui Zhang. This requires adding some state management logic in cpufreq cooling implementation. * Many review comments suggested by Andrew Morton * More documentation added in cpufreq cooling codes. Changes since V2: *Added Exynos5 TMU sensor support by enhancing the exynos4 tmu driver. Exynos5 TMU driver was internally developed by SangWook Ju . *Removed cpuhotplug cooling code in this patchset. *Rebased the patches against 3.4-rc6 kernel. Changes since V1: *Moved the sensor driver to driver/thermal folder from driver/hwmon folder as suggested by Mark Brown and Guenter Roeck *Added notifier support to notify the registered drivers of any cpu cooling action. The driver can modify the default cooling behaviour(eg set different max clip frequency). *The percentage based frequency replaced with absolute clipped frequency. *Some more conditional checks when setting max frequency. *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to THERMAL_TRIP_STATE_INSTANCE *Many review comments from R, Durgadoss and eduardo.valen...@ti.com implemented. *Removed cooling stats through debugfs patch *The V1 based can be found here, https://lkml.org/lkml/2012/2/22/123 http://lkml.org/lkml/2012/3/3/32 Changes since RFC: *Changed the cpu cooling registration/unregistration API's to instance based *Changed the STATE_ACTIVE trip type to pass correct instance id *Adding support to restore back the policy->max_freq after doing frequency clipping. *Moved the trip cooling stats from sysfs node to debugfs node as suggested by Greg KH g...@kroah.com *Incorporated several review comments from eduardo.valen...@ti.com *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd as discussed with Guenter Roeck and Donggeun Kim (https://lkml.org/lkml/2012/1/5/7) *Some changes according to the changes in common cpu cooling APIs *The RFC based patches can be found here, https://lkml.org/lkml/2011/12/13/186 https://lkml.org/lkml/2011/12/21/169 Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This codes is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) . But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a)struct thermal_cooling_device *cpufreq_cooling_register( struct freq_clip_table *tab_ptr, unsigned int tab_size) b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. All this patchset is based on Kernel version 3.4-rc6 A simple data/control flow diagrams is shown below, Core Linux thermal <-> Exynos thermal interface <- Temperature Sensor | | \|/| Cpufreq cooling device <--- TODO: *Will send the DT enablement patches later after the driver is merged. Amit Daniel Kachhap (5): thermal: Add generic cpufreq cooling implementation hwmon: exynos4: Move thermal sensor driver to driver/thermal directory thermal: exynos5: Add exynos5 thermal sensor driver support thermal: exynos: Register the tmu sensor with the kernel thermal layer ARM: exynos: Add thermal sensor driver platform data support Documentation/hwmon/exynos4_tmu | 81 --- Documentation/thermal/cpu-c
[PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Signed-off-by: Amit Daniel Kachhap --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping, cpuhotplug etc) provides +registration/unregistration APIs to the caller. The binding of the cooling +devices to the trip point is left for the user. The registration APIs returns +the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_clip_table *tab_ptr, unsigned int tab_size) + +This interface function registers the cpufreq cooling device with the name +"thermal-cpufreq-%x". This api can support multiple instances of cpufreq +cooling devices. + +tab_ptr: The table containing the maximum value of frequency to be clipped +for each cooling state. + .freq_clip_max: Value of frequency to be clipped for each allowed +cpus. + .temp_level: Temperature level at which the frequency clamping will + happen. + .mask_val: cpumask of the allowed cpu's +tab_size: the total number of cpufreq cooling states. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the "thermal-cpufreq-%x" cooling device. + +cdev: Cooling device pointer which has to be unregistered. + + +1.2 CPU cooling action notifier register/unregister interface +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP + +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 514a691..d9c529f 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -19,6 +19,17 @@ config THERMAL_HWMON depends on HWMON=y || HWMON=THERMAL default y +config CPU_THERMAL + bool "generic cpu cooling support" + depends on THERMAL && CPU_FREQ + help + This implements the generic cpu cooling mechanism through frequency + reduction, cpu hotplug and any other ways of reducing temperature. An + ACPI version of this already exists(drivers/acpi/processor_thermal.c). + This will be useful for platforms using the generic thermal interface + and not the ACPI interface. + If you want this support, you should say Y or M here. + config SPEAR_THERMAL bool "SPEAr thermal sensor driver" depends on THERMAL diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index a9fff0b..30c456c 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,4 +3,5 @@ # obj-$(CONFIG_THERMAL) += thermal_sys.o -obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o \ No newline at end of file +obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o +obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c new file mode 100644 index 000..c40d9a0 --- /dev/null +++ b/drivers/thermal/cpu_cooling.c @@ -0,0 +1,48
[PATCH v4 2/5] hwmon: exynos4: Move thermal sensor driver to driver/thermal directory
This movement is needed because the hwmon entries and corresponding sysfs interface is a duplicate of utilities already provided by driver/thermal/thermal_sys.c. The goal is to place it in thermal folder and add necessary functions to use the in-kernel thermal interfaces. CC: Guenter Roeck Signed-off-by: Amit Daniel Kachhap Signed-off-by: Donggeun Kim --- Documentation/hwmon/exynos4_tmu | 81 Documentation/thermal/exynos_thermal | 52 +++ drivers/hwmon/Kconfig| 10 - drivers/hwmon/Makefile |1 - drivers/hwmon/exynos4_tmu.c | 514 -- drivers/thermal/Kconfig |9 + drivers/thermal/Makefile |1 + drivers/thermal/exynos_thermal.c | 409 include/linux/platform_data/exynos4_tmu.h| 83 include/linux/platform_data/exynos_thermal.h | 83 10 files changed, 554 insertions(+), 689 deletions(-) delete mode 100644 Documentation/hwmon/exynos4_tmu create mode 100644 Documentation/thermal/exynos_thermal delete mode 100644 drivers/hwmon/exynos4_tmu.c create mode 100644 drivers/thermal/exynos_thermal.c delete mode 100644 include/linux/platform_data/exynos4_tmu.h create mode 100644 include/linux/platform_data/exynos_thermal.h diff --git a/Documentation/hwmon/exynos4_tmu b/Documentation/hwmon/exynos4_tmu deleted file mode 100644 index c3c6b41..000 --- a/Documentation/hwmon/exynos4_tmu +++ /dev/null @@ -1,81 +0,0 @@ -Kernel driver exynos4_tmu -= - -Supported chips: -* ARM SAMSUNG EXYNOS4 series of SoC - Prefix: 'exynos4-tmu' - Datasheet: Not publicly available - -Authors: Donggeun Kim - -Description - -This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC. - -The chip only exposes the measured 8-bit temperature code value -through a register. -Temperature can be taken from the temperature code. -There are three equations converting from temperature to temperature code. - -The three equations are: - 1. Two point trimming - Tc = (T - 25) * (TI2 - TI1) / (85 - 25) + TI1 - - 2. One point trimming - Tc = T + TI1 - 25 - - 3. No trimming - Tc = T + 50 - - Tc: Temperature code, T: Temperature, - TI1: Trimming info for 25 degree Celsius (stored at TRIMINFO register) - Temperature code measured at 25 degree Celsius which is unchanged - TI2: Trimming info for 85 degree Celsius (stored at TRIMINFO register) - Temperature code measured at 85 degree Celsius which is unchanged - -TMU(Thermal Management Unit) in EXYNOS4 generates interrupt -when temperature exceeds pre-defined levels. -The maximum number of configurable threshold is four. -The threshold levels are defined as follows: - Level_0: current temperature > trigger_level_0 + threshold - Level_1: current temperature > trigger_level_1 + threshold - Level_2: current temperature > trigger_level_2 + threshold - Level_3: current temperature > trigger_level_3 + threshold - - The threshold and each trigger_level are set - through the corresponding registers. - -When an interrupt occurs, this driver notify user space of -one of four threshold levels for the interrupt -through kobject_uevent_env and sysfs_notify functions. -Although an interrupt condition for level_0 can be set, -it is not notified to user space through sysfs_notify function. - -Sysfs Interface -name name of the temperature sensor - RO - -temp1_inputtemperature - RO - -temp1_max temperature for level_1 interrupt - RO - -temp1_crit temperature for level_2 interrupt - RO - -temp1_emergencytemperature for level_3 interrupt - RO - -temp1_max_alarmalarm for level_1 interrupt - RO - -temp1_crit_alarm - alarm for level_2 interrupt - RO - -temp1_emergency_alarm - alarm for level_3 interrupt - RO diff --git a/Documentation/thermal/exynos_thermal b/Documentation/thermal/exynos_thermal new file mode 100644 index 000..2b46f67 --- /dev/null +++ b/Documentation/thermal/exynos_thermal @@ -0,0 +1,52 @@ +Kernel driver exynos4_tmu += + +Supported chips: +* ARM SAMSUNG EXYNOS4 series of SoC + Prefix: 'exynos4-tmu' + Datasheet: Not publicly available + +Authors: Donggeun Kim + +Description +--- + +This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC. + +The chip only exposes the measured 8-bit temperature code value +through a register. +Temperature can be taken from the temperature code. +There are three equations converting from temperature to temperature code. + +The three equations are: + 1. Two point trimming + Tc = (T - 25) * (TI2 - TI1) / (85 - 25) + TI1 + + 2. One point trimming + Tc = T + TI1 - 25 + + 3. No trimming + Tc = T + 50 + + Tc: Tem
[PATCH v4 3/5] thermal: exynos5: Add exynos5 thermal sensor driver support
This patch inserts exynos5 TMU sensor changes in the thermal driver.
Some exynos4 changes are made generic for exynos series.
Signed-off-by: SangWook Ju
Signed-off-by: Amit Daniel Kachhap
---
drivers/thermal/Kconfig |6 +-
drivers/thermal/exynos_thermal.c | 318 +-
include/linux/platform_data/exynos_thermal.h | 19 ++-
3 files changed, 226 insertions(+), 117 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b0806cf..04c6796 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -39,10 +39,10 @@ config SPEAR_THERMAL
thermal framework
config EXYNOS_THERMAL
- tristate "Temperature sensor on Samsung EXYNOS4"
- depends on ARCH_EXYNOS4 && THERMAL
+ tristate "Temperature sensor on Samsung EXYNOS"
+ depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) && THERMAL
help
If you say yes here you get support for TMU (Thermal Managment
- Unit) on SAMSUNG EXYNOS4 series of SoC.
+ Unit) on SAMSUNG EXYNOS series of SoC.
This driver can also be built as a module. If so, the module
will be called exynos4-tmu
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index bda02fe..cfe4aeb 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -33,13 +33,29 @@
#include
#include
#include
-
+#include
#include
-
-#define EXYNOS4_TMU_REG_TRIMINFO 0x0
-#define EXYNOS4_TMU_REG_CONTROL0x20
-#define EXYNOS4_TMU_REG_STATUS 0x28
-#define EXYNOS4_TMU_REG_CURRENT_TEMP 0x40
+#include
+
+#include
+
+/*Exynos generic registers*/
+#define EXYNOS_TMU_REG_TRIMINFO0x0
+#define EXYNOS_TMU_REG_CONTROL 0x20
+#define EXYNOS_TMU_REG_STATUS 0x28
+#define EXYNOS_TMU_REG_CURRENT_TEMP0x40
+#define EXYNOS_TMU_REG_INTEN 0x70
+#define EXYNOS_TMU_REG_INTSTAT 0x74
+#define EXYNOS_TMU_REG_INTCLEAR0x78
+
+#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
+#define EXYNOS_TMU_GAIN_SHIFT 8
+#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
+#define EXYNOS_TMU_CORE_ON 3
+#define EXYNOS_TMU_CORE_OFF2
+#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
+
+/*Exynos4 specific registers*/
#define EXYNOS4_TMU_REG_THRESHOLD_TEMP 0x44
#define EXYNOS4_TMU_REG_TRIG_LEVEL00x50
#define EXYNOS4_TMU_REG_TRIG_LEVEL10x54
@@ -49,28 +65,52 @@
#define EXYNOS4_TMU_REG_PAST_TEMP1 0x64
#define EXYNOS4_TMU_REG_PAST_TEMP2 0x68
#define EXYNOS4_TMU_REG_PAST_TEMP3 0x6C
-#define EXYNOS4_TMU_REG_INTEN 0x70
-#define EXYNOS4_TMU_REG_INTSTAT0x74
-#define EXYNOS4_TMU_REG_INTCLEAR 0x78
-#define EXYNOS4_TMU_GAIN_SHIFT 8
-#define EXYNOS4_TMU_REF_VOLTAGE_SHIFT 24
-
-#define EXYNOS4_TMU_TRIM_TEMP_MASK 0xff
-#define EXYNOS4_TMU_CORE_ON3
-#define EXYNOS4_TMU_CORE_OFF 2
-#define EXYNOS4_TMU_DEF_CODE_TO_TEMP_OFFSET50
#define EXYNOS4_TMU_TRIG_LEVEL0_MASK 0x1
#define EXYNOS4_TMU_TRIG_LEVEL1_MASK 0x10
#define EXYNOS4_TMU_TRIG_LEVEL2_MASK 0x100
#define EXYNOS4_TMU_TRIG_LEVEL3_MASK 0x1000
#define EXYNOS4_TMU_INTCLEAR_VAL 0x
-struct exynos4_tmu_data {
- struct exynos4_tmu_platform_data *pdata;
+/*Exynos5 specific registers*/
+#define EXYNOS5_TMU_TRIMINFO_CON 0x14
+#define EXYNOS5_THD_TEMP_RISE 0x50
+#define EXYNOS5_THD_TEMP_FALL 0x54
+#define EXYNOS5_EMUL_CON 0x80
+
+#define EXYNOS5_TRIMINFO_RELOAD0x1
+#define EXYNOS5_TMU_CLEAR_RISE_INT 0x111
+#define EXYNOS5_TMU_CLEAR_FALL_INT (0x111 << 16)
+#define EXYNOS5_MUX_ADDR_VALUE 6
+#define EXYNOS5_MUX_ADDR_SHIFT 20
+#define EXYNOS5_TMU_TRIP_MODE_SHIFT13
+
+#define EFUSE_MIN_VALUE 40
+#define EFUSE_MAX_VALUE 100
+
+/*In-kernel thermal framework related macros & definations*/
+#define SENSOR_NAME_LEN16
+#define MAX_TRIP_COUNT 8
+#define MAX_COOLING_DEVICE 4
+
+#define ACTIVE_INTERVAL 500
+#define IDLE_INTERVAL 1
+
+/* CPU Zone information */
+#define PANIC_ZONE 4
+#define WARN_ZONE 3
+#define MONITOR_ZONE2
+#define SAFE_ZONE 1
+
+#define GET_ZONE(trip) (trip + 2)
+#define GET_TRIP(zone) (zone - 2)
+
+struct exynos_tmu_data {
+ struct exynos_tmu_platform_data *pdata;
struct resource *mem;
void __iomem *base;
int irq;
+ enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
struct clk *clk;
@@ -81,16 +121,17 @@ struct exynos4_tmu_data {
* TMU treats temperature as a mapped temperature code.
* The temperature is converted differently depending on the calibration type.
*/
-static int temp_to_code(struct exynos4_tmu_data *data, u8 temp)
+static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
{
- struct exynos4_tmu_platform_data *pdata = data->pdata;
+ struct exynos_tmu_platform_
[PATCH v4 4/5] thermal: exynos: Register the tmu sensor with the kernel thermal layer
This code added creates a link between temperature sensors, linux thermal
framework and cooling devices for samsung exynos platform. This layer
monitors the temperature from the sensor and informs the generic thermal
layer to take the necessary cooling action.
Signed-off-by: Amit Daniel Kachhap
---
drivers/thermal/exynos_thermal.c | 344 +-
include/linux/platform_data/exynos_thermal.h |6 +
2 files changed, 348 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index cfe4aeb..48106d8 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -35,6 +35,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -95,6 +98,7 @@
#define ACTIVE_INTERVAL 500
#define IDLE_INTERVAL 1
+#define MCELSIUS 1000
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -105,6 +109,8 @@
#define GET_ZONE(trip) (trip + 2)
#define GET_TRIP(zone) (zone - 2)
+#define EXYNOS_ZONE_COUNT 3
+
struct exynos_tmu_data {
struct exynos_tmu_platform_data *pdata;
struct resource *mem;
@@ -117,6 +123,309 @@ struct exynos_tmu_data {
u8 temp_error1, temp_error2;
};
+struct thermal_trip_point_conf {
+ int trip_val[MAX_TRIP_COUNT];
+ int trip_count;
+};
+
+struct thermal_cooling_conf {
+ struct freq_clip_table freq_data[MAX_TRIP_COUNT];
+ int freq_clip_count;
+};
+
+struct thermal_sensor_conf {
+ char name[SENSOR_NAME_LEN];
+ int (*read_temperature)(void *data);
+ struct thermal_trip_point_conf trip_data;
+ struct thermal_cooling_conf cooling_data;
+ void *private_data;
+};
+
+struct exynos_thermal_zone {
+ enum thermal_device_mode mode;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos_thermal_zone *th_zone;
+static void exynos_unregister_thermal(void);
+static int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
+
+/* Get mode callback functions for thermal zone */
+static int exynos_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
+{
+ if (th_zone)
+ *mode = th_zone->mode;
+ return 0;
+}
+
+/* Set mode callback functions for thermal zone */
+static int exynos_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
+{
+ if (!th_zone->therm_dev) {
+ pr_notice("thermal zone not registered\n");
+ return 0;
+ }
+
+ mutex_lock(&th_zone->therm_dev->lock);
+
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
+ else
+ th_zone->therm_dev->polling_delay = 0;
+
+ mutex_unlock(&th_zone->therm_dev->lock);
+
+ th_zone->mode = mode;
+ thermal_zone_device_update(th_zone->therm_dev);
+ pr_info("thermal polling set for duration=%d msec\n",
+ th_zone->therm_dev->polling_delay);
+ return 0;
+}
+
+/*
+ * This function may be called from interrupt based temperature sensor
+ * when threshold is changed.
+ */
+static void exynos_report_trigger(void)
+{
+ unsigned int i;
+ char data[10];
+ char *envp[] = { data, NULL };
+
+ if (!th_zone || !th_zone->therm_dev)
+ return;
+
+ thermal_zone_device_update(th_zone->therm_dev);
+
+ mutex_lock(&th_zone->therm_dev->lock);
+ /* Find the level for which trip happened */
+ for (i = 0; i < th_zone->sensor_conf->trip_data.trip_count; i++) {
+ if (th_zone->therm_dev->last_temperature <
+ th_zone->sensor_conf->trip_data.trip_val[i] * MCELSIUS)
+ break;
+ }
+
+ if (th_zone->mode == THERMAL_DEVICE_ENABLED) {
+ if (i > 0)
+ th_zone->therm_dev->polling_delay = ACTIVE_INTERVAL;
+ else
+ th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
+ }
+
+ snprintf(data, sizeof(data), "%u", i);
+ kobject_uevent_env(&th_zone->therm_dev->device.kobj, KOBJ_CHANGE, envp);
+ mutex_unlock(&th_zone->therm_dev->lock);
+}
+
+/* Get trip type callback functions for thermal zone */
+static int exynos_get_trip_type(struct thermal_zone_device *thermal, int trip,
+enum thermal_trip_type *type)
+{
+ switch (GET_ZONE(trip)) {
+ case MONITOR_ZONE:
+ case WARN_ZONE:
+ *type = THERMAL_TRIP_ACTIVE;
+ break;
+ case PANIC_ZONE:
+ *type = THERMAL_TRIP_CRITICAL;
+ break;
+ default:
+ return -EINVA
Re: 12.05 linux-linaro kernel tree
Tushar, On 05/11/2012 09:04 AM, Tushar Behera wrote: On 05/11/2012 01:04 AM, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking. That's a good idea, thanks! The only problem is that your topic/cma_v24 is based on the topic/base, and thus includes "CONFIG: ORIGEN:" commits and an older version of linaro-configs-3.4 topic. In particular, the latter recreates configs/panda.conf file which has been deleted from the current linaro-configs-3.4. Could you please make topic/cma_v24 mainline based (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is generic, it should go into a separate file, e.g. configs/cma.conf. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 05/11/2012 09:13 AM, Andy Green wrote: On 11/05/12 13:04, Somebody in the thread at some point said: On 05/11/2012 01:04 AM, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking. We'll be using it again shortly, CMA is in linux-linaro-core-tracking already though, I believe the same version #24. http://git.linaro.org/gitweb?p=kernel%2Flinux-linaro-tracking.git&a=search&h=refs%2Fheads%2Flinux-linaro-core-tracking&st=commit&s=CMA Indeed. Thanks Andy! They came into linux-linaro-core-tracking from the umm-3.4rc4-wip topic. Would it make sense to have the CMA patches in a separate topic? I could even start tracking the git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git, for-next-cma (or 3.4--cma-v24 ?) branch directly provided that Sumit or Tushar would do the fixes when needed (maintain cma-fixes topic). Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
