Re: Unbalanced calls to spi_master_get in coldfire-qspi and s3c64xx SPI master drivers
On 14 August 2012 03:14, Guenter Roeck li...@roeck-us.net wrote: Hi all, looking through SPI master drivers, I noticed that the following drivers call spi_master_get() in their suspend and resume functions. Yet, there is no matching call to spi_master_put(), meaning the reference count will increase with each suspend/resume cycle. spi-coldfire-qspi.c spi-s3c64xx.c Other SPI master drivers also support suspend and resume, but do not call spi_master_get() in the suspend/resume functions. The spi-pl022 driver calls spi_master_suspend() and spi_master_resume() like the above, but does not call spi_master_get() either. This leads me to believe that the above drivers will hang on unload after a suspend/resume cycle due to the extra references. Can someone please have a look and confirm if my understanding is correct ? If so I'll send a set of patches to fix the problems. For spi-s3c64xx.c, yes it does seem that the spi_master_get() and spi_master_put() calls are not balanced. The probable change could be - struct spi_master *master = spi_master_get(dev_get_drvdata(dev)); + struct spi_master *master = dev_get_drvdata(dev); Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add MFC device tree support
This patch incorporates device tree support for the video codec IP (MFC) present in Exynos series SoCs. The driver side support for this will be posted as a separate patch in the linux-media mailing list. Naveen Krishna Chatradhi (1): ARM: EXYNOS: Add MFC device tree support .../devicetree/bindings/media/s5p-mfc.txt | 24 arch/arm/boot/dts/exynos4210.dtsi | 10 arch/arm/boot/dts/exynos5250.dtsi | 10 arch/arm/mach-exynos/clock-exynos5.c |2 +- arch/arm/mach-exynos/mach-exynos4-dt.c | 22 ++ arch/arm/mach-exynos/mach-exynos5-dt.c | 22 ++ 6 files changed, 89 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: EXYNOS: Add MFC device tree support
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch adds device tree entry for MFC in the Exynos
machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
MFC v6.x version. So making the required changes in the clock
files and adds MFC to the DT device list.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../devicetree/bindings/media/s5p-mfc.txt | 24
arch/arm/boot/dts/exynos4210.dtsi | 10
arch/arm/boot/dts/exynos5250.dtsi | 10
arch/arm/mach-exynos/clock-exynos5.c |2 +-
arch/arm/mach-exynos/mach-exynos4-dt.c | 22 ++
arch/arm/mach-exynos/mach-exynos5-dt.c | 22 ++
6 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
new file mode 100644
index 000..b9bd266
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -0,0 +1,24 @@
+* Samsung Multi Format Codec (MFC)
+
+Mult Format Codec (MFC) is the IP present in Samsung SoCs which
+supports high resolution decoding and encoding functionalities.
+
+Required properties:
+ - compatible : value should be either one among the following
+ (a) samsung,s5p-mfc-v5 for MFC v5 present in Exynos4 SoCs
+ (b) samsung,s5p-mfc-v6 for MFC v6.x present in Exynos5 SoCs
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : MFC interupt number to the CPU.
+
+ - samsung,mfc-r : Base address of the first memory bank used by MFC
+ for DMA contiguous memory allocation.
+
+ - samsung,mfc-r-size : Size of the first memory bank.
+
+ - samsung,mfc-l : Base address of the second memory bank used by MFC
+ for DMA contiguous memory allocation.
+
+ - samsung,mfc-l-size : Size of the second memory bank.
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 02891fe..b5ee43d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -56,6 +56,16 @@
interrupts = 0 43 0;
};
+ mfc {
+ compatible = samsung,s5p-mfc;
+ reg = 0x1340 0x1;
+ interrupts = 0 94 0;
+ samsung,mfc-r = 0x4300;
+ samsung,mfc-r-size = 8388608;
+ samsung,mfc-l = 0x5100;
+ samsung,mfc-l-size = 8388608;
+ };
+
rtc@1007 {
compatible = samsung,s3c6410-rtc;
reg = 0x1007 0x100;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 004aaa8..3c762a4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,6 +58,16 @@
interrupts = 0 42 0;
};
+ mfc {
+ compatible = samsung,s5p-mfc-v6;
+ reg = 0x1100 0x1;
+ interrupts = 0 96 0;
+ samsung,mfc-r = 0x4300;
+ samsung,mfc-r-size = 8388608;
+ samsung,mfc-l = 0x5100;
+ samsung,mfc-l-size = 8388608;
+ };
+
rtc {
compatible = samsung,s3c6410-rtc;
reg = 0x101E 0x100;
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 3b00e29..c85e7b2 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -607,7 +607,7 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit= (1 25),
}, {
.name = mfc,
- .devname= s5p-mfc,
+ .devname= s5p-mfc-v6,
.enable = exynos5_clk_ip_mfc_ctrl,
.ctrlbit= (1 0),
}, {
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index b2b5d5f..c4a0e16 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -13,6 +13,7 @@
#include linux/of_platform.h
#include linux/serial_core.h
+#include linux/memblock.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
@@ -63,6 +64,7 @@ static const struct of_dev_auxdata
exynos4210_auxdata_lookup[] __initconst = {
exynos4210-spi.2, NULL),
OF_DEV_AUXDATA(arm,pl330, EXYNOS4_PA_PDMA0, dma-pl330.0, NULL),
OF_DEV_AUXDATA(arm,pl330, EXYNOS4_PA_PDMA1, dma-pl330.1, NULL),
+ OF_DEV_AUXDATA(samsung,s5p-mfc, 0x1340, s5p-mfc, NULL),
{},
};
@@ -83,6 +85,25 @@ static char const *exynos4210_dt_compat[] __initdata = {
NULL
};
+static void
[PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/thermal/cpu-cooling-api.txt | 52 +++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 512 + include/linux/cpu_cooling.h | 79 + 5 files changed, 655 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..a1f2a6b --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,52 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + + clip_cpus: cpumask of cpus where the frequency constraints will happen. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the thermal-cpufreq-%x cooling device. + +cdev: Cooling device pointer which has to be unregistered. + + +1.2 CPU cooling action notifier register/unregister interface +1.2.1 int
[PATCH v6 0/6] thermal: Add kernel thermal support for exynos platform
Hi Andrew/Zhang/Len, This current patchset is based on 3.6-rc1 and Zhang Rui's core thermal enhancement patches(http://permalink.gmane.org/gmane.linux.acpi.devel/54564). Version V5 is present in linux-next tree. Since Zhang Rui's implementation are already present in linux-next so requesting Andrew to add this V6 series and drop earlier V5 version. Changes since v5: This patchset basically simplifies the cpufreq cooling API's to take just cpumask as an input parameter and also removes the state management logic as they are now taken care in the core thermal layer. All these patches over Zhang Rui's work can be found in the git link git://git.linaro.org/people/amitdanielk/linux.git exynos_v6_thermal_tree Thanks, Amit Daniel Amit Daniel Kachhap (6): thermal: add generic cpufreq cooling implementation hwmon: exynos4: move thermal sensor driver to driver/thermal directory thermal: exynos5: add exynos5250 thermal sensor driver support thermal: exynos: register the tmu sensor with the kernel thermal layer ARM: exynos: add thermal sensor driver platform data support thermal: exynos: Use devm_* functions Documentation/hwmon/exynos4_tmu | 81 --- Documentation/thermal/cpu-cooling-api.txt| 52 ++ Documentation/thermal/exynos_thermal | 52 ++ drivers/hwmon/Kconfig| 10 - drivers/hwmon/Makefile |1 - drivers/hwmon/exynos4_tmu.c | 518 -- drivers/thermal/Kconfig | 18 + drivers/thermal/Makefile |2 + drivers/thermal/cpu_cooling.c| 512 + drivers/thermal/exynos_thermal.c | 994 ++ include/linux/cpu_cooling.h | 79 ++ include/linux/platform_data/exynos4_tmu.h| 83 --- include/linux/platform_data/exynos_thermal.h | 116 +++ 13 files changed, 1825 insertions(+), 693 deletions(-) delete mode 100644 Documentation/hwmon/exynos4_tmu create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 Documentation/thermal/exynos_thermal delete mode 100644 drivers/hwmon/exynos4_tmu.c create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 drivers/thermal/exynos_thermal.c create mode 100644 include/linux/cpu_cooling.h delete mode 100644 include/linux/platform_data/exynos4_tmu.h create mode 100644 include/linux/platform_data/exynos_thermal.h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/6] 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. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Acked-by: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/hwmon/exynos4_tmu | 81 Documentation/thermal/exynos_thermal | 52 +++ drivers/hwmon/Kconfig| 10 - drivers/hwmon/Makefile |1 - drivers/hwmon/exynos4_tmu.c | 518 -- drivers/thermal/Kconfig |7 + drivers/thermal/Makefile |1 + drivers/thermal/exynos_thermal.c | 413 include/linux/platform_data/exynos4_tmu.h| 83 include/linux/platform_data/exynos_thermal.h | 83 10 files changed, 556 insertions(+), 693 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 dg77@samsung.com - -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 dg77@samsung.com + +Description +--- + +This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC. + +The chip only exposes the measured
[PATCH v6 4/6] 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.
[a...@linux-foundation.org: fix comment layout]
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/thermal/exynos_thermal.c | 406 +-
include/linux/platform_data/exynos_thermal.h | 22 ++
2 files changed, 426 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index c9a33dd..e79cdc9 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -34,6 +34,9 @@
#include linux/io.h
#include linux/mutex.h
#include linux/platform_data/exynos_thermal.h
+#include linux/thermal.h
+#include linux/cpufreq.h
+#include linux/cpu_cooling.h
#include linux/of.h
#include plat/cpu.h
@@ -94,6 +97,7 @@
#define ACTIVE_INTERVAL 500
#define IDLE_INTERVAL 1
+#define MCELSIUS 1000
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -104,6 +108,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;
@@ -116,6 +122,371 @@ 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;
+ bool bind;
+};
+
+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;
+}
+
+
+/* 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 -EINVAL;
+ }
+ return 0;
+}
+
+/* Get trip temperature callback functions for thermal zone */
+static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int trip,
+ unsigned long *temp)
+{
+ if (trip GET_TRIP(MONITOR_ZONE) || trip GET_TRIP(PANIC_ZONE))
+ return -EINVAL;
+
+ *temp = th_zone-sensor_conf-trip_data.trip_val[trip];
+ /* convert the temperature into millicelsius */
+ *temp = *temp * MCELSIUS;
+
+ return 0;
+}
+
+/* Get critical temperature callback functions for thermal zone */
+static int
[PATCH v6 5/6] ARM: exynos: add thermal sensor driver platform data support
Add necessary default platform data support needed for TMU driver. The
supplied dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms and only compile tested for exynos4412.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: jonghwa lee jonghwa3@samsung.com
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
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 e79cdc9..03a99e4 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -723,14 +723,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 exynos4210_default_tmu_data = {
+ .threshold = 80,
+ .trigger_levels[0] = 5,
+ .trigger_levels[1] = 20,
+ .trigger_levels[2] = 30,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 15,
+ .reference_voltage = 7,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 100,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS4210,
+};
+#define EXYNOS4210_TMU_DRV_DATA (exynos4210_default_tmu_data)
+#else
+#define EXYNOS4210_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
+static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
+ .trigger_levels[0] = 85,
+ .trigger_levels[1] = 103,
+ .trigger_levels[2] = 110,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 8,
+ .reference_voltage = 16,
+ .noise_cancel_mode = 4,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .efuse_value = 55,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 103,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS,
+};
+#define EXYNOS_TMU_DRV_DATA (exynos_default_tmu_data)
+#else
+#define EXYNOS_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+ {
+ .compatible = samsung,exynos4210-tmu,
+ .data = (void *)EXYNOS4210_TMU_DRV_DATA,
+ },
+ {
+ .compatible = samsung,exynos5250-tmu,
+ .data = (void *)EXYNOS_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 = exynos4210-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS4210_TMU_DRV_DATA,
+ },
+ {
+ .name = exynos5250-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS_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;
@@ -899,9 +1006,11 @@ static struct platform_driver
[PATCH v6 6/6] thermal: exynos: Use devm_* functions
devm_* functions are used to replace kzalloc, request_mem_region, ioremap
and request_irq functions in probe call. With the usage of devm_* functions
explicit freeing and unmapping is not required.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Signed-off-by: Sachin Kamat sachin.ka...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/exynos_thermal.c | 45 +++--
1 files changed, 9 insertions(+), 36 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 03a99e4..e84acde 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -842,7 +842,8 @@ static int __devinit exynos_tmu_probe(struct
platform_device *pdev)
dev_err(pdev-dev, No platform init data supplied.\n);
return -ENODEV;
}
- data = kzalloc(sizeof(struct exynos_tmu_data), GFP_KERNEL);
+ data = devm_kzalloc(pdev-dev, sizeof(struct exynos_tmu_data),
+ GFP_KERNEL);
if (!data) {
dev_err(pdev-dev, Failed to allocate driver structure\n);
return -ENOMEM;
@@ -850,47 +851,35 @@ static int __devinit exynos_tmu_probe(struct
platform_device *pdev)
data-irq = platform_get_irq(pdev, 0);
if (data-irq 0) {
- ret = data-irq;
dev_err(pdev-dev, Failed to get platform irq\n);
- goto err_free;
+ return data-irq;
}
INIT_WORK(data-irq_work, exynos_tmu_work);
data-mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!data-mem) {
- ret = -ENOENT;
dev_err(pdev-dev, Failed to get platform resource\n);
- goto err_free;
+ return -ENOENT;
}
- data-mem = request_mem_region(data-mem-start,
- resource_size(data-mem), pdev-name);
- if (!data-mem) {
- ret = -ENODEV;
- dev_err(pdev-dev, Failed to request memory region\n);
- goto err_free;
- }
-
- data-base = ioremap(data-mem-start, resource_size(data-mem));
+ data-base = devm_request_and_ioremap(pdev-dev, data-mem);
if (!data-base) {
- ret = -ENODEV;
dev_err(pdev-dev, Failed to ioremap memory\n);
- goto err_mem_region;
+ return -ENODEV;
}
- ret = request_irq(data-irq, exynos_tmu_irq,
+ ret = devm_request_irq(pdev-dev, data-irq, exynos_tmu_irq,
IRQF_TRIGGER_RISING, exynos-tmu, data);
if (ret) {
dev_err(pdev-dev, Failed to request irq: %d\n, data-irq);
- goto err_io_remap;
+ return ret;
}
data-clk = clk_get(NULL, tmu_apbif);
if (IS_ERR(data-clk)) {
- ret = PTR_ERR(data-clk);
dev_err(pdev-dev, Failed to get clock\n);
- goto err_irq;
+ return PTR_ERR(data-clk);
}
if (pdata-type == SOC_ARCH_EXYNOS ||
@@ -942,15 +931,6 @@ static int __devinit exynos_tmu_probe(struct
platform_device *pdev)
err_clk:
platform_set_drvdata(pdev, NULL);
clk_put(data-clk);
-err_irq:
- free_irq(data-irq, data);
-err_io_remap:
- iounmap(data-base);
-err_mem_region:
- release_mem_region(data-mem-start, resource_size(data-mem));
-err_free:
- kfree(data);
-
return ret;
}
@@ -964,15 +944,8 @@ static int __devexit exynos_tmu_remove(struct
platform_device *pdev)
clk_put(data-clk);
- free_irq(data-irq, data);
-
- iounmap(data-base);
- release_mem_region(data-mem-start, resource_size(data-mem));
-
platform_set_drvdata(pdev, NULL);
- kfree(data);
-
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: Add MFC device tree support
On 16 August 2012 18:01, Arun Kumar K arun...@samsung.com wrote:
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch adds device tree entry for MFC in the Exynos
machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
MFC v6.x version. So making the required changes in the clock
files and adds MFC to the DT device list.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../devicetree/bindings/media/s5p-mfc.txt | 24
arch/arm/boot/dts/exynos4210.dtsi | 10
arch/arm/boot/dts/exynos5250.dtsi | 10
arch/arm/mach-exynos/clock-exynos5.c |2 +-
arch/arm/mach-exynos/mach-exynos4-dt.c | 22 ++
arch/arm/mach-exynos/mach-exynos5-dt.c | 22 ++
6 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
new file mode 100644
index 000..b9bd266
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -0,0 +1,24 @@
+* Samsung Multi Format Codec (MFC)
+
+Mult Format Codec (MFC) is the IP present in Samsung SoCs which
+supports high resolution decoding and encoding functionalities.
In addition to this, specifying that mfc is used for video
encode/decode would be informative.
+
+Required properties:
+ - compatible : value should be either one among the following
+ (a) samsung,s5p-mfc-v5 for MFC v5 present in Exynos4 SoCs
+ (b) samsung,s5p-mfc-v6 for MFC v6.x present in Exynos5 SoCs
s5p should be dropped from the compatible values. For example, it
should be samsung,mfc-v5, which is sufficient to identify the
version of the mfc controller.
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : MFC interupt number to the CPU.
+
+ - samsung,mfc-r : Base address of the first memory bank used by MFC
+ for DMA contiguous memory allocation.
+
+ - samsung,mfc-r-size : Size of the first memory bank.
It is not allowed to pass buffer base address and size from device
tree. Device tree node should describe only the MFC controller
hardware. Any memory management related information should be handled
outside of device tree. This helps the bindings to be reusable across
multiple operating systems.
+
+ - samsung,mfc-l : Base address of the second memory bank used by MFC
+ for DMA contiguous memory allocation.
+
+ - samsung,mfc-l-size : Size of the second memory bank.
Same comment as above. And the bindings documentation is usually
included in the same patch that adds device tree support for the
driver.
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 02891fe..b5ee43d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -56,6 +56,16 @@
interrupts = 0 43 0;
};
+ mfc {
+ compatible = samsung,s5p-mfc;
+ reg = 0x1340 0x1;
+ interrupts = 0 94 0;
+ samsung,mfc-r = 0x4300;
+ samsung,mfc-r-size = 8388608;
+ samsung,mfc-l = 0x5100;
+ samsung,mfc-l-size = 8388608;
+ };
+
rtc@1007 {
compatible = samsung,s3c6410-rtc;
reg = 0x1007 0x100;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 004aaa8..3c762a4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,6 +58,16 @@
interrupts = 0 42 0;
};
+ mfc {
+ compatible = samsung,s5p-mfc-v6;
+ reg = 0x1100 0x1;
+ interrupts = 0 96 0;
+ samsung,mfc-r = 0x4300;
+ samsung,mfc-r-size = 8388608;
+ samsung,mfc-l = 0x5100;
+ samsung,mfc-l-size = 8388608;
+ };
+
rtc {
compatible = samsung,s3c6410-rtc;
reg = 0x101E 0x100;
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 3b00e29..c85e7b2 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -607,7 +607,7 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit= (1 25),
}, {
.name = mfc,
- .devname= s5p-mfc,
+ .devname= s5p-mfc-v6,
.enable = exynos5_clk_ip_mfc_ctrl,
.ctrlbit= (1 0),
}, {
diff --git
[PATCH v6 3/6] thermal: exynos5: add exynos5250 thermal sensor driver support
Insert exynos5 TMU sensor changes into the thermal driver. Some exynos4
changes are made generic for exynos series.
[a...@linux-foundation.org: fix comment layout]
Signed-off-by: SangWook Ju sw...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/thermal/Kconfig |2 +-
drivers/thermal/exynos_thermal.c | 351 --
include/linux/platform_data/exynos_thermal.h | 19 ++-
3 files changed, 240 insertions(+), 132 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 8f2b6ea..edfd67d 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -49,7 +49,7 @@ config RCAR_THERMAL
config EXYNOS_THERMAL
tristate Temperature sensor on Samsung EXYNOS
- depends on ARCH_EXYNOS4 THERMAL
+ depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) THERMAL
help
If you say yes here you get support for TMU (Thermal Managment
Unit) on SAMSUNG EXYNOS series of SoC.
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 556d15b..c9a33dd 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -33,44 +33,83 @@
#include linux/kobject.h
#include linux/io.h
#include linux/mutex.h
-
#include linux/platform_data/exynos_thermal.h
-
-#define EXYNOS4_TMU_REG_TRIMINFO 0x0
-#define EXYNOS4_TMU_REG_CONTROL0x20
-#define EXYNOS4_TMU_REG_STATUS 0x28
-#define EXYNOS4_TMU_REG_CURRENT_TEMP 0x40
-#define EXYNOS4_TMU_REG_THRESHOLD_TEMP 0x44
-#define EXYNOS4_TMU_REG_TRIG_LEVEL00x50
-#define EXYNOS4_TMU_REG_TRIG_LEVEL10x54
-#define EXYNOS4_TMU_REG_TRIG_LEVEL20x58
-#define EXYNOS4_TMU_REG_TRIG_LEVEL30x5C
-#define EXYNOS4_TMU_REG_PAST_TEMP0 0x60
-#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;
+#include linux/of.h
+
+#include plat/cpu.h
+
+/* 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
+
+/* Exynos4210 specific registers */
+#define EXYNOS4210_TMU_REG_THRESHOLD_TEMP 0x44
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL1 0x54
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL2 0x58
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL3 0x5C
+#define EXYNOS4210_TMU_REG_PAST_TEMP0 0x60
+#define EXYNOS4210_TMU_REG_PAST_TEMP1 0x64
+#define EXYNOS4210_TMU_REG_PAST_TEMP2 0x68
+#define EXYNOS4210_TMU_REG_PAST_TEMP3 0x6C
+
+#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK0x1
+#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK0x10
+#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK0x100
+#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK0x1000
+#define EXYNOS4210_TMU_INTCLEAR_VAL0x
+
+/* Exynos5250 and Exynos4412 specific registers */
+#define EXYNOS_TMU_TRIMINFO_CON0x14
+#define EXYNOS_THD_TEMP_RISE 0x50
+#define EXYNOS_THD_TEMP_FALL 0x54
+#define EXYNOS_EMUL_CON0x80
+
+#define EXYNOS_TRIMINFO_RELOAD 0x1
+#define EXYNOS_TMU_CLEAR_RISE_INT 0x111
+#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 16)
+#define EXYNOS_MUX_ADDR_VALUE 6
+#define EXYNOS_MUX_ADDR_SHIFT 20
+#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
+
+#define EFUSE_MIN_VALUE 40
+#define EFUSE_MAX_VALUE 100
+
+/* In-kernel thermal framework related
Re: Unbalanced calls to spi_master_get in coldfire-qspi and s3c64xx SPI master drivers
On Thu, Aug 16, 2012 at 02:27:49PM +0530, Thomas Abraham wrote: On 14 August 2012 03:14, Guenter Roeck li...@roeck-us.net wrote: Hi all, looking through SPI master drivers, I noticed that the following drivers call spi_master_get() in their suspend and resume functions. Yet, there is no matching call to spi_master_put(), meaning the reference count will increase with each suspend/resume cycle. spi-coldfire-qspi.c spi-s3c64xx.c Other SPI master drivers also support suspend and resume, but do not call spi_master_get() in the suspend/resume functions. The spi-pl022 driver calls spi_master_suspend() and spi_master_resume() like the above, but does not call spi_master_get() either. This leads me to believe that the above drivers will hang on unload after a suspend/resume cycle due to the extra references. Can someone please have a look and confirm if my understanding is correct ? If so I'll send a set of patches to fix the problems. For spi-s3c64xx.c, yes it does seem that the spi_master_get() and spi_master_put() calls are not balanced. The probable change could be - struct spi_master *master = spi_master_get(dev_get_drvdata(dev)); + struct spi_master *master = dev_get_drvdata(dev); Yes, that is what I thought. Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
Amit, Thanks again for keeping this up. On Thu, Aug 16, 2012 at 2:41 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) FYI, the OMAP code is under drivers/staging/omap-thermal/. The file omap-thermal-common.c is the one which is using your generic cooling device. But it needs to be updated accordingly to the API change you mention. There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com --- Documentation/thermal/cpu-cooling-api.txt | 52 +++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 512 + include/linux/cpu_cooling.h | 79 + 5 files changed, 655 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..a1f2a6b --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,52 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +
[PATCH] mmc: sdhci-s3c: Add device tree support
Add device tree based discovery support for Samsung's sdhci controller
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Chris Ball c...@laptop.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/mmc/host/sdhci-s3c.c | 146 --
1 files changed, 140 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index a50c205..7fcc642 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -34,6 +34,9 @@
#define MAX_BUS_CLK(4)
+/* Number of gpio's used is max data bus width + command and clock lines */
+#define NUM_GPIOS(x) (x + 2)
+
/**
* struct sdhci_s3c - S3C SDHCI instance
* @host: The SDHCI host created
@@ -41,6 +44,7 @@
* @ioarea: The resource created when we claimed the IO area.
* @pdata: The platform data for this controller.
* @cur_clk: The index of the current bus clock.
+ * @gpios: List of gpio numbers parsed from device tree.
* @clk_io: The clock for the internal bus interface.
* @clk_bus: The clocks that are available for the SD/MMC bus clock.
*/
@@ -52,6 +56,7 @@ struct sdhci_s3c {
unsigned intcur_clk;
int ext_cd_irq;
int ext_cd_gpio;
+ int *gpios;
struct clk *clk_io;
struct clk *clk_bus[MAX_BUS_CLK];
@@ -419,9 +424,109 @@ static void sdhci_s3c_setup_card_detect_gpio(struct
sdhci_s3c *sc)
}
}
+#ifdef CONFIG_OF
+static int __devinit sdhci_s3c_parse_dt(struct device *dev,
+ struct sdhci_host *host, struct s3c_sdhci_platdata *pdata)
+{
+ struct device_node *node = dev-of_node;
+ struct sdhci_s3c *ourhost = to_s3c(host);
+ u32 max_width;
+ int gpio, cnt, ret;
+
+ /* if the bus-width property is not specified, assume width as 1 */
+ if (of_property_read_u32(node, bus-width, max_width))
+ max_width = 1;
+ pdata-max_width = max_width;
+
+ ourhost-gpios = devm_kzalloc(dev, NUM_GPIOS(pdata-max_width) *
+ sizeof(int), GFP_KERNEL);
+ if (!ourhost-gpios)
+ return -ENOMEM;
+
+ /* get the card detection method */
+ if (of_get_property(node, samsung,sdhci-cd-internal, NULL))
+ pdata-cd_type = S3C_SDHCI_CD_INTERNAL;
+ else if (of_get_property(node, samsung,sdhci-cd-gpio, NULL))
+ pdata-cd_type = S3C_SDHCI_CD_GPIO;
+ else if (of_get_property(node, samsung,sdhci-cd-none, NULL))
+ pdata-cd_type = S3C_SDHCI_CD_NONE;
+ else if (of_get_property(node, samsung,sdhci-cd-permanent, NULL))
+ pdata-cd_type = S3C_SDHCI_CD_PERMANENT;
+ else
+ pdata-cd_type = S3C_SDHCI_CD_NONE;
+
+ /* get the gpio used for card detection */
+ if (pdata-cd_type == S3C_SDHCI_CD_GPIO ||
+ pdata-cd_type == S3C_SDHCI_CD_INTERNAL) {
+ gpio = of_get_named_gpio(node, cd-gpios, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(dev, invalid card detect gpio specified\n);
+ return -EINVAL;
+ }
+ }
+
+ if (pdata-cd_type == S3C_SDHCI_CD_GPIO) {
+ pdata-ext_cd_gpio = gpio;
+ ourhost-ext_cd_gpio = -1;
+ if (of_get_property(node, cd-inverted, NULL))
+ pdata-ext_cd_gpio_invert = 1;
+ } else if (pdata-cd_type == S3C_SDHCI_CD_INTERNAL) {
+ ret = gpio_request(gpio, sdhci-cd);
+ if (ret) {
+ dev_err(dev, card detect gpio request failed\n);
+ return -EINVAL;
+ }
+ ourhost-ext_cd_gpio = gpio;
+ }
+
+ /* get the gpios for command, clock and data lines */
+ for (cnt = 0; cnt NUM_GPIOS(pdata-max_width); cnt++) {
+ gpio = of_get_gpio(node, cnt);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(dev, invalid gpio[%d]\n, cnt);
+ goto err_free_dt_cd_gpio;
+ }
+ ourhost-gpios[cnt] = gpio;
+ }
+
+ for (cnt = 0; cnt NUM_GPIOS(pdata-max_width); cnt++) {
+ ret = gpio_request(ourhost-gpios[cnt], sdhci-gpio);
+ if (ret) {
+ dev_err(dev, gpio[%d] request failed\n, cnt);
+ goto err_free_dt_gpios;
+ }
+ }
+
+ return 0;
+
+ err_free_dt_gpios:
+ while (--cnt = 0)
+ gpio_free(ourhost-gpios[cnt]);
+ err_free_dt_cd_gpio:
+ if (pdata-cd_type == S3C_SDHCI_CD_INTERNAL)
+ gpio_free(ourhost-ext_cd_gpio);
+ return -EINVAL;
+}
+#else
+static int __devinit sdhci_s3c_parse_dt(struct device *dev,
+ struct sdhci_host *host, struct s3c_sdhci_platdata *pdata)
+{
+
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
Hi Thomas, On Thu, Aug 16 2012, Thomas Abraham wrote: Add device tree based discovery support for Samsung's sdhci controller Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Chris Ball c...@laptop.org Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- drivers/mmc/host/sdhci-s3c.c | 146 -- 1 files changed, 140 insertions(+), 6 deletions(-) I know your initial version was submitted before we adopted a set of standard MMC DT bindings, but now that those bindings exist this code should be using them -- there should be a new file: Documentation/devicetree/bindings/mmc/sdhci-s3c.txt describing differences between the mmc.txt bindings and this driver's. Also, you didn't include a patch changelog, so I can't tell whether this contains changes against your v3 of this patch; please do that. Thanks! - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
Hi Chris, Thanks for your review. On 16 August 2012 21:17, Chris Ball c...@laptop.org wrote: Hi Thomas, On Thu, Aug 16 2012, Thomas Abraham wrote: Add device tree based discovery support for Samsung's sdhci controller Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Chris Ball c...@laptop.org Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- drivers/mmc/host/sdhci-s3c.c | 146 -- 1 files changed, 140 insertions(+), 6 deletions(-) I know your initial version was submitted before we adopted a set of standard MMC DT bindings, but now that those bindings exist this code should be using them -- there should be a new file: Documentation/devicetree/bindings/mmc/sdhci-s3c.txt describing differences between the mmc.txt bindings and this driver's. Sorry, I missed that. I will resend this patch with the documentation. Also, you didn't include a patch changelog, so I can't tell whether this contains changes against your v3 of this patch; please do that. Yes, I missed the changelog as well. I will add it in the next version of this patch. Thanks, Thomas. Thanks! - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: sdhci-s3c: Add device tree support
Add device tree based discovery support for Samsung's sdhci controller
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Chris Ball c...@laptop.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
Changes since v3:
The patch series that adds device tree support for Samsung sdhci controller
had six patches in total, of which, the first five patches have been accepted.
The sixth patch in the series was dropped since it was using custom Samsung
properties for descrbing the bus-width and card-detect gpio, but had otherwise
addressed all the comments.
This patch reworks the sixth patch in v3 of the sdhci device tree support
patch series. The only change in this patch from the v3 version is the use of
generic mmc bindings for descrbing the bus-width and card-detect gpio.
.../devicetree/bindings/mmc/samsung-sdhci.txt | 51 +++
drivers/mmc/host/sdhci-s3c.c | 146 +++-
2 files changed, 191 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
new file mode 100644
index 000..398540b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -0,0 +1,51 @@
+* Samsung's SDHCI Controller device tree bindings
+
+Samsung's SDHCI controller is used as a connectivity interface with external
+MMC, SD and eMMC storage mediums. This file documents differences between the
+core mmc properties described by mmc.txt and the properties used by the
+Samsung implmentation of the SDHCI controller.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - samsung,s3c6410-sdhci: For controllers compatible with s3c6410 sdhci
+controller.
+ - samsung,exynos4210-sdhci: For controllers compatible with Exynos4 sdhci
+controller.
+
+Required Board Specific Properties:
+- gpios: Should specify the gpios used for clock, command and data lines. The
+ gpio specifier format depends on the gpio controller.
+
+Optional Board Specific Properties:
+- One of the following properties for card detect type.
+ - samsung,sdhci-cd-internal: Card detect line from the card slot is
+connected to the card detect pad of the sdhci controller. A gpio is
+used for this connection (with possible pin function settings).
+ - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
+is used a card detect line. This gpio line is not connected to card detect
+pad of the sdhci controller.
+ - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
+detect the presence of the card. (DEFAULT, if no card detect property
+is specified).
+ - samsung,sdhci-cd-permanent: There is no card detect line. The card is
+permanently connected to the sdhci controller.
+
+Example:
+ sdhci@1253 {
+ compatible = samsung,exynos4210-sdhci;
+ reg = 0x1253 0x100;
+ interrupts = 0 75 0;
+ bus-width = 4;
+ samsung,sdhci-cd-internal;
+ cd-gpios = gpk2 2 2 3 3;
+ gpios = gpk2 0 2 0 3, /* clock line */
+ gpk2 1 2 0 3, /* command line */
+ gpk2 3 2 3 3, /* data line 0 */
+ gpk2 4 2 3 3, /* data line 1 */
+ gpk2 5 2 3 3, /* data line 2 */
+ gpk2 6 2 3 3; /* data line 3 */
+ };
+
+ Note: This example shows both SoC specific and board specific properties
+ in a single device node. The properties can be actually be seperated
+ into SoC specific node and board specific node.
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index a50c205..7fcc642 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -34,6 +34,9 @@
#define MAX_BUS_CLK(4)
+/* Number of gpio's used is max data bus width + command and clock lines */
+#define NUM_GPIOS(x) (x + 2)
+
/**
* struct sdhci_s3c - S3C SDHCI instance
* @host: The SDHCI host created
@@ -41,6 +44,7 @@
* @ioarea: The resource created when we claimed the IO area.
* @pdata: The platform data for this controller.
* @cur_clk: The index of the current bus clock.
+ * @gpios: List of gpio numbers parsed from device tree.
* @clk_io: The clock for the internal bus interface.
* @clk_bus: The clocks that are available for the SD/MMC bus clock.
*/
@@ -52,6 +56,7 @@ struct sdhci_s3c {
unsigned intcur_clk;
int ext_cd_irq;
int ext_cd_gpio;
+ int *gpios;
struct clk *clk_io;
struct clk *clk_bus[MAX_BUS_CLK];
@@ -419,9 +424,109 @@ static void sdhci_s3c_setup_card_detect_gpio(struct
sdhci_s3c *sc)
}
}
+#ifdef CONFIG_OF
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
Hi,
On Thu, Aug 16 2012, Thomas Abraham wrote:
Add device tree based discovery support for Samsung's sdhci controller
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Chris Ball c...@laptop.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
Changes since v3:
The patch series that adds device tree support for Samsung sdhci controller
had six patches in total, of which, the first five patches have been accepted.
The sixth patch in the series was dropped since it was using custom Samsung
properties for descrbing the bus-width and card-detect gpio, but had otherwise
addressed all the comments.
This patch reworks the sixth patch in v3 of the sdhci device tree support
patch series. The only change in this patch from the v3 version is the use of
generic mmc bindings for descrbing the bus-width and card-detect gpio.
.../devicetree/bindings/mmc/samsung-sdhci.txt | 51 +++
drivers/mmc/host/sdhci-s3c.c | 146
+++-
2 files changed, 191 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
new file mode 100644
index 000..398540b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -0,0 +1,51 @@
+* Samsung's SDHCI Controller device tree bindings
+
+Samsung's SDHCI controller is used as a connectivity interface with external
+MMC, SD and eMMC storage mediums. This file documents differences between the
+core mmc properties described by mmc.txt and the properties used by the
+Samsung implmentation of the SDHCI controller.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - samsung,s3c6410-sdhci: For controllers compatible with s3c6410 sdhci
+controller.
+ - samsung,exynos4210-sdhci: For controllers compatible with Exynos4 sdhci
+controller.
+
+Required Board Specific Properties:
+- gpios: Should specify the gpios used for clock, command and data lines. The
+ gpio specifier format depends on the gpio controller.
+
+Optional Board Specific Properties:
+- One of the following properties for card detect type.
+ - samsung,sdhci-cd-internal: Card detect line from the card slot is
+connected to the card detect pad of the sdhci controller. A gpio is
+used for this connection (with possible pin function settings).
+ - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
+is used a card detect line. This gpio line is not connected to card
detect
+pad of the sdhci controller.
+ - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
+detect the presence of the card. (DEFAULT, if no card detect property
+is specified).
+ - samsung,sdhci-cd-permanent: There is no card detect line. The card is
+permanently connected to the sdhci controller.
+
+Example:
+ sdhci@1253 {
+ compatible = samsung,exynos4210-sdhci;
+ reg = 0x1253 0x100;
+ interrupts = 0 75 0;
+ bus-width = 4;
+ samsung,sdhci-cd-internal;
+ cd-gpios = gpk2 2 2 3 3;
+ gpios = gpk2 0 2 0 3, /* clock line */
+ gpk2 1 2 0 3, /* command line */
+ gpk2 3 2 3 3, /* data line 0 */
+ gpk2 4 2 3 3, /* data line 1 */
+ gpk2 5 2 3 3, /* data line 2 */
+ gpk2 6 2 3 3; /* data line 3 */
+ };
+
+ Note: This example shows both SoC specific and board specific properties
+ in a single device node. The properties can be actually be seperated
+ into SoC specific node and board specific node.
Looks good, except the text file doesn't mention anywhere that it describes
the bindings used by sdhci-s3c.c -- that could be useful information to
someone reading the binding and trying to discover which driver uses it.
Maybe we can call the text file sdhci-s3c.txt? Or samsung,sdhci-s3c.txt
if you prefer.
Thanks,
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
On 16 August 2012 21:59, Chris Ball c...@laptop.org wrote:
Hi,
On Thu, Aug 16 2012, Thomas Abraham wrote:
Add device tree based discovery support for Samsung's sdhci controller
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Chris Ball c...@laptop.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
Changes since v3:
The patch series that adds device tree support for Samsung sdhci controller
had six patches in total, of which, the first five patches have been
accepted.
The sixth patch in the series was dropped since it was using custom Samsung
properties for descrbing the bus-width and card-detect gpio, but had
otherwise
addressed all the comments.
This patch reworks the sixth patch in v3 of the sdhci device tree support
patch series. The only change in this patch from the v3 version is the use of
generic mmc bindings for descrbing the bus-width and card-detect gpio.
.../devicetree/bindings/mmc/samsung-sdhci.txt | 51 +++
drivers/mmc/host/sdhci-s3c.c | 146
+++-
2 files changed, 191 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
new file mode 100644
index 000..398540b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -0,0 +1,51 @@
+* Samsung's SDHCI Controller device tree bindings
+
+Samsung's SDHCI controller is used as a connectivity interface with external
+MMC, SD and eMMC storage mediums. This file documents differences between
the
+core mmc properties described by mmc.txt and the properties used by the
+Samsung implmentation of the SDHCI controller.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - samsung,s3c6410-sdhci: For controllers compatible with s3c6410 sdhci
+controller.
+ - samsung,exynos4210-sdhci: For controllers compatible with Exynos4
sdhci
+controller.
+
+Required Board Specific Properties:
+- gpios: Should specify the gpios used for clock, command and data lines.
The
+ gpio specifier format depends on the gpio controller.
+
+Optional Board Specific Properties:
+- One of the following properties for card detect type.
+ - samsung,sdhci-cd-internal: Card detect line from the card slot is
+connected to the card detect pad of the sdhci controller. A gpio is
+used for this connection (with possible pin function settings).
+ - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
+is used a card detect line. This gpio line is not connected to card
detect
+pad of the sdhci controller.
+ - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
+detect the presence of the card. (DEFAULT, if no card detect property
+is specified).
+ - samsung,sdhci-cd-permanent: There is no card detect line. The card is
+permanently connected to the sdhci controller.
+
+Example:
+ sdhci@1253 {
+ compatible = samsung,exynos4210-sdhci;
+ reg = 0x1253 0x100;
+ interrupts = 0 75 0;
+ bus-width = 4;
+ samsung,sdhci-cd-internal;
+ cd-gpios = gpk2 2 2 3 3;
+ gpios = gpk2 0 2 0 3, /* clock line */
+ gpk2 1 2 0 3, /* command line */
+ gpk2 3 2 3 3, /* data line 0 */
+ gpk2 4 2 3 3, /* data line 1 */
+ gpk2 5 2 3 3, /* data line 2 */
+ gpk2 6 2 3 3; /* data line 3 */
+ };
+
+ Note: This example shows both SoC specific and board specific
properties
+ in a single device node. The properties can be actually be seperated
+ into SoC specific node and board specific node.
Looks good, except the text file doesn't mention anywhere that it describes
the bindings used by sdhci-s3c.c -- that could be useful information to
someone reading the binding and trying to discover which driver uses it.
Maybe we can call the text file sdhci-s3c.txt? Or samsung,sdhci-s3c.txt
if you prefer.
Hi Chris,
The assumption here was that the all the binding documentation have to
be generic enough to be useful for non-linux platforms as well. And
there were previous discussions on actually moving the binding
documentation outside of the linux source and maintained separately.
Hence, the text file states that it describes the bindings used by
Samsung's SDHCI controller. If you prefer, I can resubmit this patch
with samsung,sdhci-s3c.txt as the file name for the bindings
documentation file.
Thanks,
Thomas.
Thanks,
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to
[PATCH] ARM: dts: use generic mmc properties for Samsung Exynos4210 sdhci nodes
The SDHCI controller nodes in platforms which are based on Samsung's Exynos4210
SoC are using the older custom Samsung SDHCI bindings. Remove the old Samsung
specific bindings and use the generic mmc bindings that are defined for mmc
controllers.
Cc: Kukjin Kim kgene@samsung.com
Cc: Chris Ball c...@laptop.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/boot/dts/exynos4210-origen.dts | 10 --
arch/arm/boot/dts/exynos4210-smdkv310.dts |5 ++---
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 0c49caa..5b5f389 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -30,10 +30,9 @@
};
sdhci@1253 {
- samsung,sdhci-bus-width = 4;
- linux,mmc_cap_4_bit_data;
+ bus-width = 4;
samsung,sdhci-cd-internal;
- gpio-cd = gpk2 2 2 3 3;
+ cd-gpios = gpk2 2 2 3 3;
gpios = gpk2 0 2 0 3,
gpk2 1 2 0 3,
gpk2 3 2 3 3,
@@ -43,10 +42,9 @@
};
sdhci@1251 {
- samsung,sdhci-bus-width = 4;
- linux,mmc_cap_4_bit_data;
+ bus-width = 4;
samsung,sdhci-cd-internal;
- gpio-cd = gpk0 2 2 3 3;
+ cd-gpios = gpk0 2 2 3 3;
gpios = gpk0 0 2 0 3,
gpk0 1 2 0 3,
gpk0 3 2 3 3,
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 1beccc8..f090095 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -30,10 +30,9 @@
};
sdhci@1253 {
- samsung,sdhci-bus-width = 4;
- linux,mmc_cap_4_bit_data;
+ bus-width = 4;
samsung,sdhci-cd-internal;
- gpio-cd = gpk2 2 2 3 3;
+ cd-gpios = gpk2 2 2 3 3;
gpios = gpk2 0 2 0 3,
gpk2 1 2 0 3,
gpk2 3 2 3 3,
--
1.6.6.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
Hi Thomas, On Thu, Aug 16 2012, Thomas Abraham wrote: +Optional Board Specific Properties: +- One of the following properties for card detect type. + - samsung,sdhci-cd-internal: Card detect line from the card slot is +connected to the card detect pad of the sdhci controller. A gpio is +used for this connection (with possible pin function settings). + - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings) +is used a card detect line. This gpio line is not connected to card detect +pad of the sdhci controller. + - samsung,sdhci-cd-none: There is no card detect line. Polling is used to +detect the presence of the card. (DEFAULT, if no card detect property +is specified). + - samsung,sdhci-cd-permanent: There is no card detect line. The card is +permanently connected to the sdhci controller. sdhci-s3c isn't the only driver that's going to have options for different cd configurations -- maybe now is the right time to move these options into the core bindings? At OLPC we've just started using: * broken-cd to mean samsung,sdhci-cd-none, * the presence of a cd-gpios property to imply samsung,sdhci-cd-gpio. * non-removable to mean samsung,sdhci-cd-permanent (this is already specified in mmc.txt) Would these work for you? We don't have a distinction between sdhci-cd-internal and sdhci-cd-gpio, and I'm having trouble working out why one is necessary. Why does the driver need to know where the gpio came from, aside from knowing which gpio it is and whether it needs to be inverted (with cd-inverted)? Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
On 16 August 2012 22:22, Chris Ball c...@laptop.org wrote: Hi Thomas, On Thu, Aug 16 2012, Thomas Abraham wrote: +Optional Board Specific Properties: +- One of the following properties for card detect type. + - samsung,sdhci-cd-internal: Card detect line from the card slot is +connected to the card detect pad of the sdhci controller. A gpio is +used for this connection (with possible pin function settings). + - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings) +is used a card detect line. This gpio line is not connected to card detect +pad of the sdhci controller. + - samsung,sdhci-cd-none: There is no card detect line. Polling is used to +detect the presence of the card. (DEFAULT, if no card detect property +is specified). + - samsung,sdhci-cd-permanent: There is no card detect line. The card is +permanently connected to the sdhci controller. sdhci-s3c isn't the only driver that's going to have options for different cd configurations -- maybe now is the right time to move these options into the core bindings? Yes, I agree. It will be better to reduce the custom bindings. At OLPC we've just started using: * broken-cd to mean samsung,sdhci-cd-none, Yes, they are mean the same. * the presence of a cd-gpios property to imply samsung,sdhci-cd-gpio. samsung,sdhci-cd-gpio and sdhci-cd-internal both use the cd-gpio line. samsung,sdhci-cd-gpio means that the cd-gpio line is not connected to the card-detect pad of the sdhci controller. Instead, it identifies cd-gpio as a gpio pin, connected to the card-detect pin of the card slot and it can used as a source of external interrupt. The driver can register card insert/remove handler for this interrupt and get notified about the changes in card state. sdhci-cd-internal means that the cd-gpio line is used to connect the card-detect pin of the card slot and the card-detect pad of the sdhci controller. The controller is then aware of any changes in card state and the controller generates appropriate interrupts to notify changes in card-state. * non-removable to mean samsung,sdhci-cd-permanent (this is already specified in mmc.txt) Ok. Would these work for you? Yes, the first and the third works, but the second point needs a way to identify the type of external card-detection mechanism. We don't have a distinction between sdhci-cd-internal and sdhci-cd-gpio, and I'm having trouble working out why one is necessary. Why does the driver need to know where the gpio came from, aside from knowing which gpio it is and whether it needs to be inverted (with cd-inverted)? This is as explained above. Maybe other controllers also need something similar to samsung,sdhci-cd-gpio and sdhci-cd-internal. And so, we could make a generic binding for these as well. Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Add pinctrl node entries for Samsung Exynos4210 SoC
Re: samsung,pin-function samsung,pin-pud samsung,pin-drv - why can't
these be one property, why take the space to define them individually
instead of in an array of 3 values under one property name?
--
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
On Wed, Aug 15, 2012 at 3:10 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
Add pinctrl driver nodes for the three instances of pin controllers
in Samsung Exynos4210 SoC and add the pin group nodes available in the
each of those three instances.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 457
+
arch/arm/boot/dts/exynos4210.dtsi | 37 +++
2 files changed, 494 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4210-pinctrl.dtsi
diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
new file mode 100644
index 000..b12cf27
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -0,0 +1,457 @@
+/*
+ * Samsung's Exynos4210 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2011-2012 Linaro Ltd.
+ * www.linaro.org
+ *
+ * Samsung's Exynos4210 SoC pin-mux and pin-config optiosn are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+/ {
+ pinctrl@1140 {
+ uart0_data: uart0-data {
+ samsung,pins = gpa0-0, gpa0-1;
+ samsung,pin-function = 0x2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = gpa0-2, gpa0-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = gpa0-4, gpa0-5;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = gpa0-6, gpa0-7;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ i2c2_bus: i2c2-bus {
+ samsung,pins = gpa0-6, gpa0-7;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ uart2_data: uart2-data {
+ samsung,pins = gpa1-0, gpa1-1;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart2_fctl: uart2-fctl {
+ samsung,pins = gpa1-2, gpa1-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart_audio_a: uart-audio-a {
+ samsung,pins = gpa1-0, gpa1-1;
+ samsung,pin-function = 4;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ i2c3_bus: i2c3-bus {
+ samsung,pins = gpa1-2, gpa1-3;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ uart3_data: uart3-data {
+ samsung,pins = gpa1-4, gpa1-5;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart_audio_b: uart-audio-b {
+ samsung,pins = gpa1-4, gpa1-5;
+ samsung,pin-function = 4;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ spi0_bus: spi0-bus {
+ samsung,pins = gpb-0, gpb-2, gpb-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ i2c4_bus: i2c4-bus {
+ samsung,pins =
[PATCH] spi/s3c64xx: Drop extra calls to spi_master_get in suspend/remove functions
Suspend and resume functions call spi_master_get() without matching
spi_master_put(). The extra references are unnecessary and cause subsequent
module unload attempts to fail. Drop the calls.
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/spi/spi-s3c64xx.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 646a765..d7a87df 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1409,7 +1409,7 @@ static int s3c64xx_spi_remove(struct platform_device
*pdev)
#ifdef CONFIG_PM
static int s3c64xx_spi_suspend(struct device *dev)
{
- struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
spi_master_suspend(master);
@@ -1428,7 +1428,7 @@ static int s3c64xx_spi_suspend(struct device *dev)
static int s3c64xx_spi_resume(struct device *dev)
{
- struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct s3c64xx_spi_info *sci = sdd-cntrlr_info;
@@ -1452,7 +1452,7 @@ static int s3c64xx_spi_resume(struct device *dev)
#ifdef CONFIG_PM_RUNTIME
static int s3c64xx_spi_runtime_suspend(struct device *dev)
{
- struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
clk_disable(sdd-clk);
@@ -1463,7 +1463,7 @@ static int s3c64xx_spi_runtime_suspend(struct device *dev)
static int s3c64xx_spi_runtime_resume(struct device *dev)
{
- struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
clk_enable(sdd-src_clk);
--
1.7.9.7
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi/s3c64xx: Drop extra calls to spi_master_get in suspend/remove functions
Sigh.
s/remove/resume/ in headline.
Guenter
On Thu, Aug 16, 2012 at 08:14:25PM -0700, Guenter Roeck wrote:
Suspend and resume functions call spi_master_get() without matching
spi_master_put(). The extra references are unnecessary and cause subsequent
module unload attempts to fail. Drop the calls.
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/spi/spi-s3c64xx.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 646a765..d7a87df 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1409,7 +1409,7 @@ static int s3c64xx_spi_remove(struct platform_device
*pdev)
#ifdef CONFIG_PM
static int s3c64xx_spi_suspend(struct device *dev)
{
- struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
spi_master_suspend(master);
@@ -1428,7 +1428,7 @@ static int s3c64xx_spi_suspend(struct device *dev)
static int s3c64xx_spi_resume(struct device *dev)
{
- struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct s3c64xx_spi_info *sci = sdd-cntrlr_info;
@@ -1452,7 +1452,7 @@ static int s3c64xx_spi_resume(struct device *dev)
#ifdef CONFIG_PM_RUNTIME
static int s3c64xx_spi_runtime_suspend(struct device *dev)
{
- struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
clk_disable(sdd-clk);
@@ -1463,7 +1463,7 @@ static int s3c64xx_spi_runtime_suspend(struct device
*dev)
static int s3c64xx_spi_runtime_resume(struct device *dev)
{
- struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
clk_enable(sdd-src_clk);
--
1.7.9.7
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation
On 16 August 2012 20:22, Valentin, Eduardo eduardo.valen...@ti.com wrote: Amit, Thanks again for keeping this up. On Thu, Aug 16, 2012 at 2:41 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) FYI, the OMAP code is under drivers/staging/omap-thermal/. The file omap-thermal-common.c is the one which is using your generic cooling device. But it needs to be updated accordingly to the API change you mention. There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com Thanks Eduardo . --- Documentation/thermal/cpu-cooling-api.txt | 52 +++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 512 + include/linux/cpu_cooling.h | 79 + 5 files changed, 655 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..a1f2a6b --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,52 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq
Re: [PATCH v6 5/6] ARM: exynos: add thermal sensor driver platform data support
On 16 August 2012 17:11, Amit Daniel Kachhap amit.kach...@linaro.org wrote:
Add necessary default platform data support needed for TMU driver. The
supplied dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms and only compile tested for exynos4412.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: jonghwa lee jonghwa3@samsung.com
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/thermal/exynos_thermal.c | 111
+-
1 files changed, 110 insertions(+), 1 deletions(-)
Reviewed-by: Thomas Abraham thomas.abra...@linaro.org
Few minor comments inline below.
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index e79cdc9..03a99e4 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -723,14 +723,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 exynos4210_default_tmu_data = {
+ .threshold = 80,
+ .trigger_levels[0] = 5,
+ .trigger_levels[1] = 20,
+ .trigger_levels[2] = 30,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 15,
+ .reference_voltage = 7,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 100,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS4210,
+};
+#define EXYNOS4210_TMU_DRV_DATA (exynos4210_default_tmu_data)
+#else
+#define EXYNOS4210_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
+static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
+ .trigger_levels[0] = 85,
+ .trigger_levels[1] = 103,
+ .trigger_levels[2] = 110,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 8,
+ .reference_voltage = 16,
+ .noise_cancel_mode = 4,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .efuse_value = 55,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 103,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS,
+};
+#define EXYNOS_TMU_DRV_DATA (exynos_default_tmu_data)
+#else
+#define EXYNOS_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+ {
+ .compatible = samsung,exynos4210-tmu,
+ .data = (void *)EXYNOS4210_TMU_DRV_DATA,
+ },
+ {
This can be }, {
+ .compatible = samsung,exynos5250-tmu,
+ .data = (void *)EXYNOS_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 = exynos4210-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS4210_TMU_DRV_DATA,
+ },
+ {
+ .name = exynos5250-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS_TMU_DRV_DATA,
+ },
Since Exynos5250 platforms are dt based, the above entry could be left out.
+ { },
+};
+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)
Re: [PATCH] ARM: EXYNOS: Add MFC device tree support
Hi Thomas,
Thank you for the comments.
Please find my response inline.
--- Original Message ---
Sender : Thomas Abrahamthomas.abra...@linaro.org
Date : Aug 16, 2012 17:12 (GMT+05:30)
Title : Re: [PATCH] ARM: EXYNOS: Add MFC device tree support
On 16 August 2012 18:01, Arun Kumar K arun...@samsung.com wrote:
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch adds device tree entry for MFC in the Exynos
machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
MFC v6.x version. So making the required changes in the clock
files and adds MFC to the DT device list.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../devicetree/bindings/media/s5p-mfc.txt | 24
arch/arm/boot/dts/exynos4210.dtsi | 10
arch/arm/boot/dts/exynos5250.dtsi | 10
arch/arm/mach-exynos/clock-exynos5.c |2 +-
arch/arm/mach-exynos/mach-exynos4-dt.c | 22 ++
arch/arm/mach-exynos/mach-exynos5-dt.c | 22 ++
6 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
new file mode 100644
index 000..b9bd266
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -0,0 +1,24 @@
+* Samsung Multi Format Codec (MFC)
+
+Mult Format Codec (MFC) is the IP present in Samsung SoCs which
+supports high resolution decoding and encoding functionalities.
In addition to this, specifying that mfc is used for video
encode/decode would be informative.
Ok. I will make it more descriptive.
+
+Required properties:
+ - compatible : value should be either one among the following
+ (a) samsung,s5p-mfc-v5 for MFC v5 present in Exynos4 SoCs
+ (b) samsung,s5p-mfc-v6 for MFC v6.x present in Exynos5 SoCs
s5p should be dropped from the compatible values. For example, it
should be samsung,mfc-v5, which is sufficient to identify the
version of the mfc controller.
Ok will remove s5p.
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : MFC interupt number to the CPU.
+
+ - samsung,mfc-r : Base address of the first memory bank used by MFC
+ for DMA contiguous memory allocation.
+
+ - samsung,mfc-r-size : Size of the first memory bank.
It is not allowed to pass buffer base address and size from device
tree. Device tree node should describe only the MFC controller
hardware. Any memory management related information should be handled
outside of device tree. This helps the bindings to be reusable across
multiple operating systems.
The mfc-l and mfc-r base address and size is board specific info which has to
be passed to the driver. This is used for DMA contiguous allocation by driver
and this value
can change on a different board.
So in that case, i will pass it as platform data to the driver from
mach-exynos5-dt.c file.
I hope that would be ok.
+
+ - samsung,mfc-l : Base address of the second memory bank used by MFC
+ for DMA contiguous memory allocation.
+
+ - samsung,mfc-l-size : Size of the second memory bank.
Same comment as above. And the bindings documentation is usually
included in the same patch that adds device tree support for the
driver.
Ok
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 02891fe..b5ee43d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -56,6 +56,16 @@
interrupts = 0 43 0;
};
+ mfc {
+ compatible = samsung,s5p-mfc;
+ reg = 0x1340 0x1;
+ interrupts = 0 94 0;
+ samsung,mfc-r = 0x4300;
+ samsung,mfc-r-size = 8388608;
+ samsung,mfc-l = 0x5100;
+ samsung,mfc-l-size = 8388608;
+ };
+
rtc@1007 {
compatible = samsung,s3c6410-rtc;
reg = 0x1007 0x100;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 004aaa8..3c762a4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,6 +58,16 @@
interrupts = 0 42 0;
};
+ mfc {
+ compatible = samsung,s5p-mfc-v6;
+ reg = 0x1100 0x1;
+ interrupts = 0 96 0;
+ samsung,mfc-r = 0x4300;
+ samsung,mfc-r-size = 8388608;
+ samsung,mfc-l = 0x5100;
+ samsung,mfc-l-size = 8388608;
+ };
+
rtc {
compatible =
Re: [PATCH 1/2] ARM: dts: Add pinctrl node entries for Samsung Exynos4210 SoC
On 17 August 2012 00:26, Matt Sealey m...@genesi-usa.com wrote:
Re: samsung,pin-function samsung,pin-pud samsung,pin-drv - why can't
these be one property, why take the space to define them individually
instead of in an array of 3 values under one property name?
Samsung pinctrl driver was written to be usable on all of the Samsung
application processors starting from 24xx series to the latest
Exynos5.
The gpio/pinmux/pinconfig controllers on these SoC have varying
capabilities. Some of the banks in s3c24xx series support mux function
but do not support pull up/down (pud) or driver strength (drv).
s3c64xx soc's have banks that support pin mux and 'pud' but do not
support 'drv'. And there are banks that do not support mux function
but support 'pud' and 'drv'. Further, a given SoC can have multiple
combinations of different bank types.
In addition to this, there are two more properties for mux and pud
values in power down mode in some of the samsung SoC's.
To keep the bindings common across all the possible Samsung SoC's, the
mux, pud and drv properties were split so that the parsing code in the
Samsung pinctrl driver remains generic for all the possible
combinations of pin banks and SoC's.
Thanks,
Thomas.
--
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
On Wed, Aug 15, 2012 at 3:10 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
Add pinctrl driver nodes for the three instances of pin controllers
in Samsung Exynos4210 SoC and add the pin group nodes available in the
each of those three instances.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 457
+
arch/arm/boot/dts/exynos4210.dtsi | 37 +++
2 files changed, 494 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4210-pinctrl.dtsi
diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
new file mode 100644
index 000..b12cf27
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -0,0 +1,457 @@
+/*
+ * Samsung's Exynos4210 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2011-2012 Linaro Ltd.
+ * www.linaro.org
+ *
+ * Samsung's Exynos4210 SoC pin-mux and pin-config optiosn are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+/ {
+ pinctrl@1140 {
+ uart0_data: uart0-data {
+ samsung,pins = gpa0-0, gpa0-1;
+ samsung,pin-function = 0x2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = gpa0-2, gpa0-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = gpa0-4, gpa0-5;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = gpa0-6, gpa0-7;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ i2c2_bus: i2c2-bus {
+ samsung,pins = gpa0-6, gpa0-7;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ uart2_data: uart2-data {
+ samsung,pins = gpa1-0, gpa1-1;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart2_fctl: uart2-fctl {
+ samsung,pins = gpa1-2, gpa1-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart_audio_a: uart-audio-a {
+ samsung,pins = gpa1-0, gpa1-1;
+ samsung,pin-function = 4;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ i2c3_bus: i2c3-bus {
+ samsung,pins = gpa1-2, gpa1-3;
+
