Re: [PATCH] i2c-s3c2410: Convert to devm_request_and_ioremap()
On Mon, Jul 09, 2012 at 02:58:10PM +0100, Mark Brown wrote: On Mon, Jul 09, 2012 at 03:52:29PM +0200, Wolfram Sang wrote: On Thu, Jun 28, 2012 at 01:55:38PM +0100, Mark Brown wrote: A small code saving and less error handling to worry about. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com What about devm for the clocks, too? The devm_ versions of the API aren't exported there yet and there's a bug fix pending too but Russell and Mike have ignored the patches thus far. I'd rather wait for this to be fixed and have all devm applied in one go? -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [linux-pm] [RESEND PATCH v4 1/5] thermal: add generic cpufreq cooling implementation
On Thu, Jul 12, 2012 at 8:40 PM, Valentin, Eduardo eduardo.valen...@ti.com wrote: Amit, On Thu, Jul 12, 2012 at 4: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. * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal) FYI, I have rewriten the OMAP BG driver and currently trying to push it to staging area. It should now support more omap versions. I will readapt the cpu cooling based on this patch. I am keeping the reworked driver here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/bandgap_staging Yes Eduardo, The link I have given here is slightly old. After your implementation is done maybe this link can be updated. Thanks, Amit D * 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 OMAP and 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 codes is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) . But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct freq_clip_table *tab_ptr, unsigned int tab_size) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. 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: Donggeun Kim dg77@samsung.com 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 Signed-off-by: Andrew Morton a...@linux-foundation.org --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap 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, cpuhotplug etc) provides +registration/unregistration APIs to the caller. The binding of the cooling +devices to the trip point is left for the user. The registration APIs returns +the cooling
Re: [PATCH v3 3/6] mmc: dw_mmc: lookup for optional biu and ciu clocks
On 12 July 2012 18:24, Thomas Abraham thomas.abra...@linaro.org wrote:
Some platforms allow for clock gating and control of bus interface unit clock
and card interface unit clock. Add support for clock lookup of optional biu
and ciu clocks for clock gating and clock speed determination.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/mmc/host/dw_mmc.c | 42 +++---
include/linux/mmc/dw_mmc.h |4
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index cd58063..679473c 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1953,18 +1953,38 @@ int dw_mci_probe(struct dw_mci *host)
return -ENODEV;
}
- if (!host-pdata-bus_hz) {
+ host-biu_clk = clk_get(host-dev, biu);
+ if (IS_ERR(host-biu_clk))
+ dev_dbg(host-dev, biu clock not available\n);
+ else
+ clk_prepare_enable(host-biu_clk);
+
+ host-ciu_clk = clk_get(host-dev, ciu);
+ if (IS_ERR(host-ciu_clk))
+ dev_dbg(host-dev, ciu clock not available\n);
+ else
+ clk_prepare_enable(host-ciu_clk);
+
+ if (IS_ERR(host-ciu_clk))
+ host-bus_hz = host-pdata-bus_hz;
+ else
+ host-bus_hz = clk_get_rate(host-ciu_clk);
+
+ if (!host-bus_hz) {
dev_err(host-dev,
Platform data must supply bus speed\n);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_clk;
}
- host-bus_hz = host-pdata-bus_hz;
host-quirks = host-pdata-quirks;
spin_lock_init(host-lock);
INIT_LIST_HEAD(host-queue);
+ host-dma_ops = host-pdata-dma_ops;
+ dw_mci_init_dma(host);
This initialization is already done.
+
/*
* Get the host data width - this assumes that HCON has been set with
* the correct values.
@@ -2109,6 +2129,16 @@ err_dmaunmap:
regulator_disable(host-vmmc);
regulator_put(host-vmmc);
}
+
+err_clk:
+ if (!IS_ERR(host-ciu_clk)) {
+ clk_disable_unprepare(host-ciu_clk);
+ clk_put(host-ciu_clk);
+ }
+ if (!IS_ERR(host-biu_clk)) {
+ clk_disable_unprepare(host-biu_clk);
+ clk_put(host-biu_clk);
+ }
return ret;
}
EXPORT_SYMBOL(dw_mci_probe);
@@ -2142,6 +2172,12 @@ void dw_mci_remove(struct dw_mci *host)
regulator_put(host-vmmc);
}
+ if (!IS_ERR(host-ciu_clk))
+ clk_disable_unprepare(host-ciu_clk);
+ if (!IS_ERR(host-biu_clk))
+ clk_disable_unprepare(host-biu_clk);
+ clk_put(host-ciu_clk);
+ clk_put(host-biu_clk);
}
EXPORT_SYMBOL(dw_mci_remove);
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index a37a573..787ad56 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -78,6 +78,8 @@ struct mmc_data;
* @data_offset: Set the offset of DATA register according to VERID.
* @dev: Device associated with the MMC controller.
* @pdata: Platform data associated with the MMC controller.
+ * @biu_clk: Pointer to bus interface unit clock instance.
+ * @ciu_clk: Pointer to card interface unit clock instance.
* @slot: Slots sharing this MMC controller.
* @fifo_depth: depth of FIFO.
* @data_shift: log2 of FIFO item size.
@@ -158,6 +160,8 @@ struct dw_mci {
u16 data_offset;
struct device *dev;
struct dw_mci_board *pdata;
+ struct clk *biu_clk;
+ struct clk *ciu_clk;
struct dw_mci_slot *slot[MAX_MCI_SLOTS];
/* FIFO push and pull */
--
1.6.6.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] i2c-s3c2410: Convert to devm_request_and_ioremap()
On Fri, Jul 13, 2012 at 10:37:12AM +0200, Wolfram Sang wrote: On Mon, Jul 09, 2012 at 02:58:10PM +0100, Mark Brown wrote: The devm_ versions of the API aren't exported there yet and there's a bug fix pending too but Russell and Mike have ignored the patches thus far. I'd rather wait for this to be fixed and have all devm applied in one go? clkdev is vanishingly unlikely to be fixed this release, the patches have been languishing in the patch tracker for essentially the entire release cycle, rmk is on vacation now and Mike doesn't like taking clkdev stuff. signature.asc Description: Digital signature
Re: [linux-pm] [RESEND PATCH v4 1/5] thermal: add generic cpufreq cooling implementation
On Fri, Jul 13, 2012 at 4:34 AM, Andrew Morton a...@linux-foundation.org wrote: On Thu, 12 Jul 2012 19:11:04 +0530 Amit Daniel Kachhap amit.kach...@linaro.org wrote: [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Donggeun Kim dg77@samsung.com 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 Signed-off-by: Andrew Morton a...@linux-foundation.org Something strange appears to have happened here? At a guess it seems that the patches were in my tree, I sent them to someone (Len?), then they were merged into linux-next by someone and then they fell out of linux-next again? If so, they will hopefully come back soon. If not, something failed fairly seriously. Hi Andrew, Yes you are right that this patches first came into your tree and then Len applied into his next tree for 3.5 merge. so they got into linux-next tree. After some last minute pull issues they could not be merged in 3.5 and Len dropped this series from his -next branch. I hope to get it accepted in 3.6 merge. I am aware that some work is going on for thermal framework improvement but that will have minimal changes on cpufreq cooling APIs and I hope to fix them as bug fix patches. I took a look at re-merging these patches into my tree, but there are significant conflicts with other work which has gone into linux-next. Its my fault that I didn't check the hwmon-next branch. I will repost them after merging with hwmon-next branch. Thanks, Amit Daniel -- 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 v4 1/5] thermal: Add generic cpufreq cooling implementation
On Fri, Jul 13, 2012 at 3:39 PM, Hongbo Zhang hongbo.zh...@linaro.org wrote: On 12 May 2012 17:40, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap 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, cpuhotplug etc) provides +registration/unregistration APIs to the caller. The binding of the cooling +devices to the trip point is left for the user. The registration APIs returns +the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_clip_table *tab_ptr, unsigned int tab_size) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + +tab_ptr: The table containing the maximum value of frequency to be clipped +for each cooling state. + .freq_clip_max: Value of frequency to be clipped for each allowed +cpus. + .temp_level: Temperature level at which the frequency clamping will + happen. + .mask_val: cpumask of the allowed cpu's +tab_size: the total number of cpufreq cooling states. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the thermal-cpufreq-%x cooling device. + +cdev: Cooling device pointer which has to be unregistered. + + +1.2 CPU cooling action notifier register/unregister interface +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP + +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, + unsigned int list) + +This interface registers a driver with cpu cooling layer. The driver will +be notified when any cpu cooling action is called. + +nb: notifier function to register +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 514a691..d9c529f 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -19,6 +19,17 @@ config THERMAL_HWMON depends on HWMON=y || HWMON=THERMAL default y +config CPU_THERMAL + bool generic cpu cooling support + depends on THERMAL CPU_FREQ + help + This implements the generic cpu cooling mechanism through frequency + reduction, cpu hotplug and any other ways of reducing temperature. An + ACPI version of this already exists(drivers/acpi/processor_thermal.c). + This will be useful for platforms using the generic thermal interface + and not the ACPI interface. + If you want this support, you should say Y or M here. No M value for bool item, should be N ? Yes I will include this change. + config SPEAR_THERMAL bool SPEAr thermal sensor driver depends on THERMAL diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index a9fff0b..30c456c 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -3,4 +3,5 @@ # obj-$(CONFIG_THERMAL) +=
Re: [linux-pm] [RESEND PATCH v4 1/5] thermal: add generic cpufreq cooling implementation
Hello everyone, I am new to linux and i also want to contribute in linux community. I am running Ubuntu 11.04 and i have downloaded linux-2.6.35.13 for learning. so kindly tell me how to set up and starting kernel development. I did tried some books and websites but i am still unable to do some productive work. So,, its my request that kindly help me in setting up the environment and start learning. Regards Rakesh kumar -- 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 v5 0/5] thermal: Add kernel thermal support for exynos platform
Hi Len/Andrew, This series is a repost of the thermal support for exynos platform. This current patchset is based on 3.5-rc6 with hwmon-next branch merged. (git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next) Version v4 was accepted for 3.5 merge by Len. (https://lkml.org/lkml/2012/6/2/7) but somehow could not go through. I am aware that some work is going on for thermal framework improvement but that will have minimal changes on cpufreq cooling APIs and I hope to fix them as bug fix patches later. Please consider them for 3.6 merge. Thanks, Amit Daniel Amit Daniel Kachhap (5): thermal: add generic cpufreq cooling implementation hwmon: exynos4: move thermal sensor driver to driver/thermal directory thermal: exynos5: add exynos5 thermal sensor driver support thermal: exynos: register the tmu sensor with the kernel thermal layer ARM: exynos: add thermal sensor driver platform data support Documentation/hwmon/exynos4_tmu | 81 --- Documentation/thermal/cpu-cooling-api.txt| 60 ++ Documentation/thermal/exynos_thermal | 52 ++ drivers/hwmon/Kconfig| 10 - drivers/hwmon/Makefile |1 - drivers/hwmon/exynos4_tmu.c | 518 -- drivers/thermal/Kconfig | 20 + drivers/thermal/Makefile |4 +- drivers/thermal/cpu_cooling.c| 483 + drivers/thermal/exynos_thermal.c | 960 ++ include/linux/cpu_cooling.h | 99 +++ include/linux/platform_data/exynos4_tmu.h| 83 --- include/linux/platform_data/exynos_thermal.h | 100 +++ 13 files changed, 1777 insertions(+), 694 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 v5 5/5] ARM: exynos: add thermal sensor driver platform data support
Add necessary default platform data support needed for TMU driver. This
dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Cc: Donggeun Kim dg77@samsung.com
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
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
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 9ef8c37..07736ea 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -662,14 +662,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static struct thermal_sensor_conf exynos_sensor_conf = {
.name = exynos-therm,
.read_temperature = (int (*)(void *))exynos_tmu_read,
+};
+
+#if defined(CONFIG_CPU_EXYNOS4210)
+static struct exynos_tmu_platform_data const exynos4_default_tmu_data = {
+ .threshold = 80,
+ .trigger_levels[0] = 5,
+ .trigger_levels[1] = 20,
+ .trigger_levels[2] = 30,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 15,
+ .reference_voltage = 7,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 100,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS4,
+};
+#define EXYNOS4_TMU_DRV_DATA (exynos4_default_tmu_data)
+#else
+#define EXYNOS4_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250)
+static struct exynos_tmu_platform_data const exynos5_default_tmu_data = {
+ .trigger_levels[0] = 85,
+ .trigger_levels[1] = 103,
+ .trigger_levels[2] = 110,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 8,
+ .reference_voltage = 16,
+ .noise_cancel_mode = 4,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .efuse_value = 55,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 103,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS5,
+};
+#define EXYNOS5_TMU_DRV_DATA (exynos5_default_tmu_data)
+#else
+#define EXYNOS5_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+ {
+ .compatible = samsung,exynos4-tmu,
+ .data = (void *)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .compatible = samsung,exynos5-tmu,
+ .data = (void *)EXYNOS5_TMU_DRV_DATA,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_tmu_match);
+#else
+#define exynos_tmu_match NULL
+#endif
+
+static struct platform_device_id exynos_tmu_driver_ids[] = {
+ {
+ .name = exynos4-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .name = exynos5-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS5_TMU_DRV_DATA,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
+
+static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(exynos_tmu_match, pdev-dev.of_node);
+ if (!match)
+ return NULL;
+ return (struct exynos_tmu_platform_data *) match-data;
+ }
+#endif
+ return (struct exynos_tmu_platform_data *)
+ platform_get_device_id(pdev)-driver_data;
}
-;
static int __devinit exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
struct exynos_tmu_platform_data *pdata = pdev-dev.platform_data;
int ret, i;
+ if (!pdata)
+ pdata = exynos_get_driver_data(pdev);
+
if (!pdata) {
dev_err(pdev-dev, No platform init data supplied.\n);
return -ENODEV;
@@ -838,9 +945,11 @@ static struct platform_driver exynos_tmu_driver = {
.name = exynos-tmu,
.owner = THIS_MODULE,
.pm = EXYNOS_TMU_PM,
+ .of_match_table = exynos_tmu_match,
},
.probe = exynos_tmu_probe,
.remove =
[PATCH v5 1/5] 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. * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal) * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for OMAP and 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 codes is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) . But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct freq_clip_table *tab_ptr, unsigned int tab_size) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. 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: Donggeun Kim dg77@samsung.com 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 Signed-off-by: Andrew Morton a...@linux-foundation.org --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap 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, cpuhotplug etc) provides +registration/unregistration APIs to the caller. The binding of the cooling +devices to the trip point is left for the user. The registration APIs returns +the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct freq_clip_table *tab_ptr, unsigned int tab_size) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + +tab_ptr: The table containing the maximum value of frequency to be clipped +for each cooling state. + .freq_clip_max: Value of frequency to be clipped for each allowed +cpus. + .temp_level: Temperature level at which the frequency clamping will + happen. + .mask_val: cpumask of the allowed
[PATCH v5 2/5] hwmon: exynos4: move thermal sensor driver to driver/thermal directory
This movement is needed because the hwmon entries and corresponding sysfs interface is a duplicate of utilities already provided by driver/thermal/thermal_sys.c. The goal is to place it in thermal folder and add necessary functions to use the in-kernel thermal interfaces. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Signed-off-by: Donggeun Kim dg77@samsung.com 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 Signed-off-by: Andrew Morton a...@linux-foundation.org --- 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 |9 + 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, 558 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 8-bit temperature code value +through a register. +Temperature can be taken from the
[PATCH v5 4/5] thermal: exynos: register the tmu sensor with the kernel thermal layer
This code added creates a link between temperature sensors, linux thermal
framework and cooling devices for samsung exynos platform. This layer
monitors the temperature from the sensor and informs the generic thermal
layer to take the necessary cooling action.
[a...@linux-foundation.org: fix comment layout]
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Cc: Donggeun Kim dg77@samsung.com
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
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/thermal/exynos_thermal.c | 344 +-
include/linux/platform_data/exynos_thermal.h |6 +
2 files changed, 348 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index fe4c81e..9ef8c37 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -35,6 +35,9 @@
#include linux/mutex.h
#include linux/err.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
@@ -95,6 +98,7 @@
#define ACTIVE_INTERVAL 500
#define IDLE_INTERVAL 1
+#define MCELSIUS 1000
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -105,6 +109,8 @@
#define GET_ZONE(trip) (trip + 2)
#define GET_TRIP(zone) (zone - 2)
+#define EXYNOS_ZONE_COUNT 3
+
struct exynos_tmu_data {
struct exynos_tmu_platform_data *pdata;
struct resource *mem;
@@ -117,6 +123,309 @@ struct exynos_tmu_data {
u8 temp_error1, temp_error2;
};
+struct thermal_trip_point_conf {
+ int trip_val[MAX_TRIP_COUNT];
+ int trip_count;
+};
+
+struct thermal_cooling_conf {
+ struct freq_clip_table freq_data[MAX_TRIP_COUNT];
+ int freq_clip_count;
+};
+
+struct thermal_sensor_conf {
+ char name[SENSOR_NAME_LEN];
+ int (*read_temperature)(void *data);
+ struct thermal_trip_point_conf trip_data;
+ struct thermal_cooling_conf cooling_data;
+ void *private_data;
+};
+
+struct exynos_thermal_zone {
+ enum thermal_device_mode mode;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos_thermal_zone *th_zone;
+static void exynos_unregister_thermal(void);
+static int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
+
+/* Get mode callback functions for thermal zone */
+static int exynos_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
+{
+ if (th_zone)
+ *mode = th_zone-mode;
+ return 0;
+}
+
+/* Set mode callback functions for thermal zone */
+static int exynos_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+
+ mutex_lock(th_zone-therm_dev-lock);
+
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
+ else
+ th_zone-therm_dev-polling_delay = 0;
+
+ mutex_unlock(th_zone-therm_dev-lock);
+
+ th_zone-mode = mode;
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set for duration=%d msec\n,
+ th_zone-therm_dev-polling_delay);
+ return 0;
+}
+
+/*
+ * This function may be called from interrupt based temperature sensor
+ * when threshold is changed.
+ */
+static void exynos_report_trigger(void)
+{
+ unsigned int i;
+ char data[10];
+ char *envp[] = { data, NULL };
+
+ if (!th_zone || !th_zone-therm_dev)
+ return;
+
+ thermal_zone_device_update(th_zone-therm_dev);
+
+ mutex_lock(th_zone-therm_dev-lock);
+ /* Find the level for which trip happened */
+ for (i = 0; i th_zone-sensor_conf-trip_data.trip_count; i++) {
+ if (th_zone-therm_dev-last_temperature
+ th_zone-sensor_conf-trip_data.trip_val[i] * MCELSIUS)
+ break;
+ }
+
+ if (th_zone-mode == THERMAL_DEVICE_ENABLED) {
+ if (i 0)
+ th_zone-therm_dev-polling_delay = ACTIVE_INTERVAL;
+ else
+ th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
+ }
+
+ snprintf(data, sizeof(data), %u, i);
+ kobject_uevent_env(th_zone-therm_dev-device.kobj, KOBJ_CHANGE, envp);
+ mutex_unlock(th_zone-therm_dev-lock);
+}
+
+/* Get trip type callback functions for thermal zone */
[PATCH v5 3/5] thermal: exynos5: add exynos5 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
Cc: Donggeun Kim dg77@samsung.com
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
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/thermal/Kconfig |6 +-
drivers/thermal/exynos_thermal.c | 320 +-
include/linux/platform_data/exynos_thermal.h | 19 ++-
3 files changed, 227 insertions(+), 118 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b0806cf..04c6796 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -39,10 +39,10 @@ config SPEAR_THERMAL
thermal framework
config EXYNOS_THERMAL
- tristate Temperature sensor on Samsung EXYNOS4
- depends on ARCH_EXYNOS4 THERMAL
+ tristate Temperature sensor on Samsung EXYNOS
+ depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) THERMAL
help
If you say yes here you get support for TMU (Thermal Managment
- Unit) on SAMSUNG EXYNOS4 series of SoC.
+ Unit) on SAMSUNG EXYNOS series of SoC.
This driver can also be built as a module. If so, the module
will be called exynos4-tmu
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 556d15b..fe4c81e 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -33,13 +33,29 @@
#include linux/kobject.h
#include linux/io.h
#include linux/mutex.h
-
+#include linux/err.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
+#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
+
+/* Exynos4 specific registers */
#define EXYNOS4_TMU_REG_THRESHOLD_TEMP 0x44
#define EXYNOS4_TMU_REG_TRIG_LEVEL00x50
#define EXYNOS4_TMU_REG_TRIG_LEVEL10x54
@@ -49,28 +65,52 @@
#define EXYNOS4_TMU_REG_PAST_TEMP1 0x64
#define EXYNOS4_TMU_REG_PAST_TEMP2 0x68
#define EXYNOS4_TMU_REG_PAST_TEMP3 0x6C
-#define EXYNOS4_TMU_REG_INTEN 0x70
-#define EXYNOS4_TMU_REG_INTSTAT0x74
-#define EXYNOS4_TMU_REG_INTCLEAR 0x78
-#define EXYNOS4_TMU_GAIN_SHIFT 8
-#define EXYNOS4_TMU_REF_VOLTAGE_SHIFT 24
-
-#define EXYNOS4_TMU_TRIM_TEMP_MASK 0xff
-#define EXYNOS4_TMU_CORE_ON3
-#define EXYNOS4_TMU_CORE_OFF 2
-#define EXYNOS4_TMU_DEF_CODE_TO_TEMP_OFFSET50
#define EXYNOS4_TMU_TRIG_LEVEL0_MASK 0x1
#define EXYNOS4_TMU_TRIG_LEVEL1_MASK 0x10
#define EXYNOS4_TMU_TRIG_LEVEL2_MASK 0x100
#define EXYNOS4_TMU_TRIG_LEVEL3_MASK 0x1000
#define EXYNOS4_TMU_INTCLEAR_VAL 0x
-struct exynos4_tmu_data {
- struct exynos4_tmu_platform_data *pdata;
+/* Exynos5 specific registers */
+#define EXYNOS5_TMU_TRIMINFO_CON 0x14
+#define EXYNOS5_THD_TEMP_RISE 0x50
+#define EXYNOS5_THD_TEMP_FALL 0x54
+#define EXYNOS5_EMUL_CON 0x80
+
+#define EXYNOS5_TRIMINFO_RELOAD0x1
+#define EXYNOS5_TMU_CLEAR_RISE_INT 0x111
+#define EXYNOS5_TMU_CLEAR_FALL_INT (0x111 16)
+#define EXYNOS5_MUX_ADDR_VALUE 6
+#define EXYNOS5_MUX_ADDR_SHIFT 20
+#define EXYNOS5_TMU_TRIP_MODE_SHIFT13
+
+#define EFUSE_MIN_VALUE 40
+#define EFUSE_MAX_VALUE 100
+
+/* In-kernel thermal framework related macros definations */
+#define SENSOR_NAME_LEN16
+#define MAX_TRIP_COUNT 8
+#define MAX_COOLING_DEVICE 4
+
+#define ACTIVE_INTERVAL 500
+#define IDLE_INTERVAL 1
+
+/* CPU Zone information */
+#define PANIC_ZONE 4
+#define WARN_ZONE 3
+#define MONITOR_ZONE2
+#define SAFE_ZONE 1
+
+#define GET_ZONE(trip) (trip + 2)
+#define GET_TRIP(zone) (zone - 2)
+
+struct exynos_tmu_data {
+ struct exynos_tmu_platform_data *pdata;
struct resource *mem;
void __iomem *base;
int irq;
+ enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
struct
RE: [PATCH v2] ARM: Exynos: Add device tree node for Exynos4 interrupt combiner controller
Thomas Abraham wrote:
Add node for Exynos4 interrupt combiner controller.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/boot/dts/exynos4210.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index a1dd2ee..0e4f659 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -33,6 +33,17 @@
reg = 0x1049 0x1000, 0x1048 0x100;
};
+ combiner:interrupt-controller@1044 {
+ compatible = samsung,exynos4210-combiner;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ reg = 0x1044 0x1000;
+ interrupts = 0 0 0, 0 1 0, 0 2 0, 0 3 0,
+ 0 4 0, 0 5 0, 0 6 0, 0 7 0,
+ 0 8 0, 0 9 0, 0 10 0, 0 11 0,
+ 0 12 0, 0 13 0, 0 14 0, 0 15 0;
+ };
+
watchdog@1006 {
compatible = samsung,s3c2410-wdt;
reg = 0x1006 0x100;
--
1.6.6.rc2
Looks ok to me, applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 v5 6/6] spi: s3c64xx: add device tree support
Thomas Abraham wrote: On 13 July 2012 04:08, Kukjin Kim kgene@samsung.com wrote: Thomas, the DMACH_DT_PROP is available only on pl330 now. So seems occur following build error with s3c6400_defconfig. drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_get_dmares': drivers/spi/spi-s3c64xx.c:1098: error: 'DMACH_DT_PROP' undeclared (first use in this function) drivers/spi/spi-s3c64xx.c:1098: error: (Each undeclared identifier is reported only once drivers/spi/spi-s3c64xx.c:1098: error: for each function it appears in.) make[3]: *** [drivers/spi/spi-s3c64xx.o] Error 1 make[2]: *** [drivers/spi] Error 2 Dear Mr. Kim, Thanks for considering these patches to be merged via your tree. For the build break you mentioned above, there was a patch submitted some time back to handle this. The link to that patch is: http://lists.infradead.org/pipermail/linux-arm-kernel/2012- June/102627.html. Could you please apply this patch also to your tree. Sure, it looks good to me, will apply that then this series will be rebased on top of that. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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: samsung: adc: fix race in s3c_adc_start
Todd Poynor wrote: On Fri, Jul 13, 2012 at 07:41:11AM +0900, Kukjin Kim wrote: BTW, Todd, do you want to keep the 'Change-Id' in mainline? If you don't mind, I'd like to remove it... Oops, I forgot to take it out, please do remove it, thanks. Sure, will remove when I apply this into -fixes. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 0/2] ARM: exynos: Enable TMU support in exynos platforms
Amit Daniel Kachhap wrote: These TMU enablement patches are needed for exynos4 and exynos5 TMU driver patches sent earlier. The link for those are http://www.spinics.net/lists/lm-sensors/msg35858.html. How was going on above patches? I can't see them you said in linux-next now, it means if I apply this series in my tree, problem will be happened :( Note1: I've seen Rafael's updating exynos4_tmu patch which is using struct dev_pm_ops for pm and applied by Guenter. Note2: would be helpful if you could do adding me in Cc of exynos tmu patches... Also patch 1 depends on combiner dt node patch sent by Thomas Abraham. (http://www.spinics.net/lists/arm-kernel/msg184129.html) Already in my tree. This patchset is based Samsung Maintainer's tree, git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for- next OK. Amit Daniel Kachhap (2): ARM: exynos4: Add devicetree node for TMU driver ARM: exynos5: Add devicetree node for TMU driver arch/arm/boot/dts/exynos4210.dtsi|7 +++ arch/arm/boot/dts/exynos5250.dtsi|6 ++ arch/arm/mach-exynos/clock-exynos4.c |5 + arch/arm/mach-exynos/clock-exynos5.c |5 + arch/arm/mach-exynos/include/mach/irqs.h |3 +++ arch/arm/mach-exynos/include/mach/map.h |3 +++ arch/arm/mach-exynos/mach-exynos4-dt.c |2 ++ arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++ 8 files changed, 33 insertions(+), 0 deletions(-) Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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][Resend] ARM: EXYNOS: Add HSOTG support to SMDK4X12
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Thursday, June 21, 2012 1:22 PM
To: linux-samsung-soc@vger.kernel.org
Cc: kgene@samsung.com; sachin.ka...@linaro.org; patc...@linaro.org
Subject: [PATCH][Resend] ARM: EXYNOS: Add HSOTG support to SMDK4X12
S3C-HSOTG support is added to SMDK4212 and SMDK4412 boards.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on Kukjin Kim's tree -next/board-samsung branch.
---
arch/arm/mach-exynos/Kconfig |2 ++
arch/arm/mach-exynos/mach-smdk4x12.c |7 +++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index f5fb6ea..ee8fa10 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -362,6 +362,7 @@ config MACH_SMDK4212
select S3C_DEV_I2C3
select S3C_DEV_I2C7
select S3C_DEV_RTC
+ select S3C_DEV_USB_HSOTG
select S3C_DEV_WDT
select S5P_DEV_FIMC0
select S5P_DEV_FIMC1
@@ -378,6 +379,7 @@ config MACH_SMDK4212
select EXYNOS4_SETUP_I2C7
select EXYNOS4_SETUP_KEYPAD
select EXYNOS4_SETUP_SDHCI
+ select EXYNOS4_SETUP_USB_PHY
help
Machine support for Samsung SMDK4212
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-
exynos/mach-smdk4x12.c
index e134c95..61abbc4 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -19,6 +19,7 @@
#include linux/pwm_backlight.h
#include linux/regulator/machine.h
#include linux/serial_core.h
+#include linux/platform_data/s3c-hsotg.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
@@ -236,6 +237,9 @@ static struct samsung_keypad_platdata
smdk4x12_keypad_data __initdata = {
.cols = 8,
};
+/* USB OTG */
+static struct s3c_hsotg_plat smdk4x12_hsotg_pdata;
+
static struct platform_device *smdk4x12_devices[] __initdata = {
s3c_device_hsmmc2,
s3c_device_hsmmc3,
@@ -244,6 +248,7 @@ static struct platform_device *smdk4x12_devices[]
__initdata = {
s3c_device_i2c3,
s3c_device_i2c7,
s3c_device_rtc,
+ s3c_device_usb_hsotg,
s3c_device_wdt,
s5p_device_fimc0,
s5p_device_fimc1,
@@ -295,6 +300,8 @@ static void __init smdk4x12_machine_init(void)
s3c_sdhci2_set_platdata(smdk4x12_hsmmc2_pdata);
s3c_sdhci3_set_platdata(smdk4x12_hsmmc3_pdata);
+ s3c_hsotg_set_platdata(smdk4x12_hsotg_pdata);
+
platform_add_devices(smdk4x12_devices,
ARRAY_SIZE(smdk4x12_devices));
}
--
1.7.4.1
Applied, thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 framebuffer support for SMDK4X12
Sachin Kamat wrote:
This patch adds framebuffer support to SMDK4212 and SMDK4412 boards.
A framebuffer window of 480x800x24bpp is defined.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/Kconfig |2 ++
arch/arm/mach-exynos/mach-smdk4x12.c | 34
++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 573be57..96f898a 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -365,12 +365,14 @@ config MACH_SMDK4212
select S5P_DEV_FIMC1
select S5P_DEV_FIMC2
select S5P_DEV_FIMC3
+ select S5P_DEV_FIMD0
select S5P_DEV_MFC
select SAMSUNG_DEV_BACKLIGHT
select SAMSUNG_DEV_KEYPAD
select SAMSUNG_DEV_PWM
select EXYNOS_DEV_SYSMMU
select EXYNOS_DEV_DMA
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_I2C3
select EXYNOS4_SETUP_I2C7
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-
exynos/mach-smdk4x12.c
index fb09c70..c4f4060 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -13,6 +13,7 @@
#include linux/i2c.h
#include linux/input.h
#include linux/io.h
+#include linux/lcd.h
#include linux/mfd/max8997.h
#include linux/mmc/host.h
#include linux/platform_device.h
@@ -28,10 +29,12 @@
#include plat/clock.h
#include plat/cpu.h
#include plat/devs.h
+#include plat/fb.h
#include plat/gpio-cfg.h
#include plat/iic.h
#include plat/keypad.h
#include plat/mfc.h
+#include plat/regs-fb.h
#include plat/regs-serial.h
#include plat/sdhci.h
@@ -234,6 +237,34 @@ static struct samsung_keypad_platdata
smdk4x12_keypad_data __initdata = {
.cols = 5,
};
+static struct s3c_fb_pd_win smdk4x12_fb_win0 = {
+ .xres = 480,
+ .yres = 800,
+ .virtual_x = 480,
+ .virtual_y = 800 * 2,
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
+
+static struct fb_videomode smdk4x12_lcd_timing = {
+ .left_margin= 8,
+ .right_margin = 8,
+ .upper_margin = 6,
+ .lower_margin = 6,
+ .hsync_len = 6,
+ .vsync_len = 4,
+ .xres = 480,
+ .yres = 800,
+};
+
+static struct s3c_fb_platdata smdk4x12_lcd_pdata __initdata = {
+ .win[0] = smdk4x12_fb_win0,
+ .vtiming= smdk4x12_lcd_timing,
+ .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct platform_device *smdk4x12_devices[] __initdata = {
s3c_device_hsmmc2,
s3c_device_hsmmc3,
@@ -248,6 +279,7 @@ static struct platform_device *smdk4x12_devices[]
__initdata = {
s5p_device_fimc2,
s5p_device_fimc3,
s5p_device_fimc_md,
+ s5p_device_fimd0,
s5p_device_mfc,
s5p_device_mfc_l,
s5p_device_mfc_r,
@@ -293,6 +325,8 @@ static void __init smdk4x12_machine_init(void)
s3c_sdhci2_set_platdata(smdk4x12_hsmmc2_pdata);
s3c_sdhci3_set_platdata(smdk4x12_hsmmc3_pdata);
+ s5p_fimd0_set_platdata(smdk4x12_lcd_pdata);
+
platform_add_devices(smdk4x12_devices,
ARRAY_SIZE(smdk4x12_devices));
}
--
1.7.4.1
Applied, thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 v5 6/6] spi: s3c64xx: add device tree support
On 13 July 2012 16:58, Kukjin Kim kgene@samsung.com wrote: Thomas Abraham wrote: On 13 July 2012 04:08, Kukjin Kim kgene@samsung.com wrote: Thomas, the DMACH_DT_PROP is available only on pl330 now. So seems occur following build error with s3c6400_defconfig. drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_get_dmares': drivers/spi/spi-s3c64xx.c:1098: error: 'DMACH_DT_PROP' undeclared (first use in this function) drivers/spi/spi-s3c64xx.c:1098: error: (Each undeclared identifier is reported only once drivers/spi/spi-s3c64xx.c:1098: error: for each function it appears in.) make[3]: *** [drivers/spi/spi-s3c64xx.o] Error 1 make[2]: *** [drivers/spi] Error 2 Dear Mr. Kim, Thanks for considering these patches to be merged via your tree. For the build break you mentioned above, there was a patch submitted some time back to handle this. The link to that patch is: http://lists.infradead.org/pipermail/linux-arm-kernel/2012- June/102627.html. Could you please apply this patch also to your tree. Sure, it looks good to me, will apply that then this series will be rebased on top of that. There are six more patches that enable spi device tree support for Exynos4 and Exynos5 platforms. Could you consider to apply those patches as well. The link to those patches is: http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg10851.html. 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] mmc: core: skip mmc_power_up call from start host
The call to the mmc_power_up during the mmc_start_host breaks the card
detection in design-ware host controller. This patch removes the call to
mmc_power_up function during host start.
This fix works fine with sdhci (sdhci compatilble host controller)
and dw_mmc (design-ware host controller). and has no side effect due to
this removal.
Tested on : origen-board and smdk-5250 board.
Signed-off-by: Girish K S girish.shivananja...@linaro.org
Cc: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/core/core.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 9503cab..503aefc 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2108,7 +2108,6 @@ void mmc_start_host(struct mmc_host *host)
{
host-f_init = max(freqs[0], host-f_min);
host-rescan_disable = 0;
- mmc_power_up(host);
mmc_detect_change(host, 0);
}
--
1.7.4.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 1/2] ARM: EXYNOS: Move G2D clock entries to clock-exynos4210.c file
Sachin Kamat wrote:
G2D clock registers are different in Exynos4210 and Exynos4X12 SoCs.
Hence moving the SoC specific G2D clock entries from common clock file
(clock-exynos4.c) to Exynos4210 specific clock file (clock-exynos4210.c).
Yeah, I agree but there are small comments.
[snip]
+static struct clksrc_clk exynos4_clk_mout_g2d0 = {
In this case, 'exynos4210_clk_mout_g2d0' is clearer, it is static though.
+ .clk= {
+ .name = mout_g2d0,
+ },
+ .sources = exynos4_clkset_mout_g2d0,
+ .reg_src = { .reg = EXYNOS4_CLKSRC_IMAGE, .shift = 0, .size = 1 },
+};
+
+static struct clksrc_clk exynos4_clk_mout_g2d1 = {
Same as above, exynos4210_clk_mout_g2d1.
+ .clk= {
+ .name = mout_g2d1,
+ },
+ .sources = exynos4_clkset_mout_g2d1,
+ .reg_src = { .reg = EXYNOS4_CLKSRC_IMAGE, .shift = 4, .size = 1 },
+};
+
+static struct clk *exynos4_clkset_mout_g2d_list[] = {
Same, exynos4210_clkset_mout_g2d_list[]
+ [0] = exynos4_clk_mout_g2d0.clk,
exynos4210_clk_mout_g2d0.clk
+ [1] = exynos4_clk_mout_g2d1.clk,
exynos4210_clk_mout_g2d1.clk
+};
+
+static struct clksrc_sources exynos4_clkset_mout_g2d = {
Same, exynos4210_clkset_mout_g2d
+ .sources= exynos4_clkset_mout_g2d_list,
exynos4210_clkset_mout_g2d_list
+ .nr_sources = ARRAY_SIZE(exynos4_clkset_mout_g2d_list),
exynos4210_clkset_mout_g2d_list
+};
+
static int exynos4_clksrc_mask_lcd1_ctrl(struct clk *clk, int enable)
{
return s5p_gatectrl(EXYNOS4210_CLKSRC_MASK_LCD1, clk, enable);
@@ -74,6 +100,13 @@ static struct clksrc_clk clksrcs[] = {
.sources = exynos4_clkset_group,
.reg_src = { .reg = EXYNOS4210_CLKSRC_LCD1, .shift =
0, .size = 4 },
.reg_div = { .reg = EXYNOS4210_CLKDIV_LCD1, .shift =
0, .size = 4 },
+ }, {
+ .clk= {
+ .name = sclk_fimg2d,
+ },
+ .sources = exynos4_clkset_mout_g2d,
exynos4210_clkset_mout_g2d
[snip]
Could you please re-submit this after re-working on top of my
next/devel-samsung.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 2/2] ARM: EXYNOS: Add G2D related clock entries for SMDK4X12
Sachin Kamat wrote:
Adds G2D related clock entries for SMDK4X12 boards.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/clock-exynos4212.c | 41
+-
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos4212.c b/arch/arm/mach-
exynos/clock-exynos4212.c
index da397d2..fdc26ac 100644
--- a/arch/arm/mach-exynos/clock-exynos4212.c
+++ b/arch/arm/mach-exynos/clock-exynos4212.c
@@ -68,12 +68,45 @@ static struct clksrc_clk clk_mout_mpll_user = {
.reg_src= { .reg = EXYNOS4_CLKSRC_CPU, .shift = 24, .size =
1 },
};
+static struct clksrc_clk exynos4_clk_mout_g2d0 = {
Same as previous comments, 'exynos4212_clk_mout_g2d0' is better here, or
exynos4x12_clk_mout_g2d0.
[snip]...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 v5 6/6] spi: s3c64xx: add device tree support
Thomas Abraham wrote: On 13 July 2012 16:58, Kukjin Kim kgene@samsung.com wrote: Thomas Abraham wrote: On 13 July 2012 04:08, Kukjin Kim kgene@samsung.com wrote: Thomas, the DMACH_DT_PROP is available only on pl330 now. So seems occur following build error with s3c6400_defconfig. drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_get_dmares': drivers/spi/spi-s3c64xx.c:1098: error: 'DMACH_DT_PROP' undeclared (first use in this function) drivers/spi/spi-s3c64xx.c:1098: error: (Each undeclared identifier is reported only once drivers/spi/spi-s3c64xx.c:1098: error: for each function it appears in.) make[3]: *** [drivers/spi/spi-s3c64xx.o] Error 1 make[2]: *** [drivers/spi] Error 2 Dear Mr. Kim, Thanks for considering these patches to be merged via your tree. For the build break you mentioned above, there was a patch submitted some time back to handle this. The link to that patch is: http://lists.infradead.org/pipermail/linux-arm-kernel/2012- June/102627.html. Could you please apply this patch also to your tree. Sure, it looks good to me, will apply that then this series will be rebased on top of that. There are six more patches that enable spi device tree support for Exynos4 and Exynos5 platforms. Could you consider to apply those patches as well. The link to those patches is: http://www.mail-archive.com/linux-samsung- s...@vger.kernel.org/msg10851.html. Yeah, I remember, but I think some patches is needed to re-work as per comments...? Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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/1] ARM: EXYNOS: Add touchscreen support to SMDK4X12
Sachin Kamat wrote:
Pixcir touchscreen device support is added to SMDK4X12 boards.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/mach-smdk4x12.c | 32
+++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-
exynos/mach-smdk4x12.c
index fe772d8..0af6088 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -9,10 +9,12 @@
* published by the Free Software Foundation.
*/
+#include linux/delay.h
#include linux/gpio.h
#include linux/i2c.h
#include linux/input.h
#include linux/io.h
+#include linux/input/pixcir_ts.h
#include linux/mfd/max8997.h
#include linux/mmc/host.h
#include linux/platform_device.h
@@ -203,8 +205,34 @@ static struct i2c_board_info smdk4x12_i2c_devs3[]
__initdata = {
/* nothing here yet */
};
+static void smdk4x12_ts_gpio_setup(void)
+{
+ int gpio_reset = EXYNOS4_GPM3(4);
+
+ gpio_request_one(gpio_reset, GPIOF_OUT_INIT_LOW, TOUCH RESET);
+ mdelay(20);
+ gpio_direction_output(gpio_reset, 1);
Do you want to set the gpio_reset value from 0 to 1 with 20m delays? Why?
+ mdelay(30);
+ s3c_gpio_setpull(EXYNOS4_GPX2(6), S3C_GPIO_PULL_NONE);
Hmm...don't we need gpio_reqeust()? and what's the gpx2(6)?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 V2 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
This patch set adds following features - Seprates PCI specific code from ufshcd.c to make it as core - Adds PCI glue driver ufshcd-pci.c - Adds Platform glue driver ufshcd-pltfrm.c - Update correct transfer size in Command UPIU Vinayak Holikatti (4): [SCSI] drivers/scsi/ufs: Remove PCI specific code [SCSI] drivers/scsi/ufs: Add PCI glue driver [SCSI] ufs: Add Platform glue driver for ufshcd [SCSI] ufs: Correct the expected data transfer size drivers/scsi/ufs/Kconfig | 37 +++- drivers/scsi/ufs/Makefile|2 + drivers/scsi/ufs/ufshcd-pci.c| 227 drivers/scsi/ufs/ufshcd-pltfrm.c | 215 +++ drivers/scsi/ufs/ufshcd.c| 422 ++ drivers/scsi/ufs/ufshcd.h| 206 +++ drivers/scsi/ufs/ufshcd_common.h | 53 + 7 files changed, 805 insertions(+), 357 deletions(-) create mode 100644 drivers/scsi/ufs/ufshcd-pci.c create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c create mode 100644 drivers/scsi/ufs/ufshcd.h create mode 100644 drivers/scsi/ufs/ufshcd_common.h -- 1.7.9.5 -- 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 V2 1/4] [SCSI] drivers/scsi/ufs: Remove PCI specific code
This patch removes the PCI specific code to make it into
core ufs driver. This separation allows room for other
bus specific glue drivers to be added in future
Signed-off-by: Vinayak Holikatti vinholika...@gmail.com
Signed-off-by: Santosh Yaraganavi santos...@gmail.com
---
drivers/scsi/ufs/Kconfig | 15 ++-
drivers/scsi/ufs/ufshcd.c | 270 -
2 files changed, 80 insertions(+), 205 deletions(-)
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 8f27f9d..8c0cd22 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -43,7 +43,16 @@
# USA.
config SCSI_UFSHCD
- tristate Universal Flash Storage host controller driver
- depends on PCI SCSI
+ tristate Universal Flash Storage Controller Driver Core
+ depends on SCSI
---help---
- This is a generic driver which supports PCIe UFS Host controllers.
+ This selects the support for UFS devices in Linux, say Y and make
+ sure that you know the name of your UFS host adapter (the card
+ inside your computer that speaks the UFS protocol, also
+ called UFS Host Controller), because you will be asked for it.
+ The module will be called ufshcd.
+
+ To compile this driver as a module, choose M here and read
+ file:Documentation/scsi/ufs.txt.
+ However, do not compile this as a module if your root file system
+ (the one containing the directory /) is located on a UFS device.
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6a4fd00..ef442c9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -129,7 +129,7 @@ struct uic_command {
* @utrdl_dma_addr: UTRDL DMA address
* @utmrdl_dma_addr: UTMRDL DMA address
* @host: Scsi_Host instance of the driver
- * @pdev: PCI device handle
+ * @dev: device handle
* @lrb: local reference block
* @outstanding_tasks: Bits representing outstanding task requests
* @outstanding_reqs: Bits representing outstanding transfer requests
@@ -159,7 +159,7 @@ struct ufs_hba {
dma_addr_t utmrdl_dma_addr;
struct Scsi_Host *host;
- struct pci_dev *pdev;
+ struct device *dev;
struct ufshcd_lrb *lrb;
@@ -335,21 +335,21 @@ static inline void ufshcd_free_hba_memory(struct ufs_hba
*hba)
if (hba-utmrdl_base_addr) {
utmrdl_size = sizeof(struct utp_task_req_desc) * hba-nutmrs;
- dma_free_coherent(hba-pdev-dev, utmrdl_size,
+ dma_free_coherent(hba-dev, utmrdl_size,
hba-utmrdl_base_addr, hba-utmrdl_dma_addr);
}
if (hba-utrdl_base_addr) {
utrdl_size =
(sizeof(struct utp_transfer_req_desc) * hba-nutrs);
- dma_free_coherent(hba-pdev-dev, utrdl_size,
+ dma_free_coherent(hba-dev, utrdl_size,
hba-utrdl_base_addr, hba-utrdl_dma_addr);
}
if (hba-ucdl_base_addr) {
ucdl_size =
(sizeof(struct utp_transfer_cmd_desc) * hba-nutrs);
- dma_free_coherent(hba-pdev-dev, ucdl_size,
+ dma_free_coherent(hba-dev, ucdl_size,
hba-ucdl_base_addr, hba-ucdl_dma_addr);
}
}
@@ -724,7 +724,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
/* Allocate memory for UTP command descriptors */
ucdl_size = (sizeof(struct utp_transfer_cmd_desc) * hba-nutrs);
- hba-ucdl_base_addr = dma_alloc_coherent(hba-pdev-dev,
+ hba-ucdl_base_addr = dma_alloc_coherent(hba-dev,
ucdl_size,
hba-ucdl_dma_addr,
GFP_KERNEL);
@@ -737,7 +737,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
*/
if (!hba-ucdl_base_addr ||
WARN_ON(hba-ucdl_dma_addr (PAGE_SIZE - 1))) {
- dev_err(hba-pdev-dev,
+ dev_err(hba-dev,
Command Descriptor Memory allocation failed\n);
goto out;
}
@@ -747,13 +747,13 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
* UFSHCI requires 1024 byte alignment of UTRD
*/
utrdl_size = (sizeof(struct utp_transfer_req_desc) * hba-nutrs);
- hba-utrdl_base_addr = dma_alloc_coherent(hba-pdev-dev,
+ hba-utrdl_base_addr = dma_alloc_coherent(hba-dev,
utrdl_size,
hba-utrdl_dma_addr,
GFP_KERNEL);
if (!hba-utrdl_base_addr ||
WARN_ON(hba-utrdl_dma_addr (PAGE_SIZE - 1))) {
- dev_err(hba-pdev-dev,
+ dev_err(hba-dev,
Transfer Descriptor Memory allocation failed\n);
[PATCH V2 2/4] [SCSI] drivers/scsi/ufs: Add PCI glue driver
This patch adds PCI glue driver support
Signed-off-by: Vinayak Holikatti vinholika...@gmail.com
Signed-off-by: Santosh Yaraganavi santos...@gmail.com
---
drivers/scsi/ufs/Kconfig | 11 ++
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufshcd-pci.c| 227 ++
drivers/scsi/ufs/ufshcd.c| 154 +-
drivers/scsi/ufs/ufshcd.h| 206 ++
drivers/scsi/ufs/ufshcd_common.h | 53 +
6 files changed, 499 insertions(+), 153 deletions(-)
create mode 100644 drivers/scsi/ufs/ufshcd-pci.c
create mode 100644 drivers/scsi/ufs/ufshcd.h
create mode 100644 drivers/scsi/ufs/ufshcd_common.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 8c0cd22..265a8c8 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -56,3 +56,14 @@ config SCSI_UFSHCD
file:Documentation/scsi/ufs.txt.
However, do not compile this as a module if your root file system
(the one containing the directory /) is located on a UFS device.
+
+config SCSI_UFSHCD_PCI
+ tristate PCI bus based UFS Controller support
+ depends on SCSI_UFSHCD PCI
+ ---help---
+ This selects the PCI UFS Host Controller Interface.
+ Most controllers found today are PCI devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index adf7895..9eda0df 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,2 +1,3 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
+obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
new file mode 100644
index 000..0c0cc92
--- /dev/null
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -0,0 +1,227 @@
+/*
+ * Universal Flash Storage Host controller driver
+ *
+ * This code is based on drivers/scsi/ufs/ufshcd-pci.c
+ * Copyright (C) 2011-2012 Samsung India Software Operations
+ *
+ * Santosh Yaraganavi santosh...@samsung.com
+ * Vinayak Holikatti h.vina...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN AS IS BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ * USA.
+ */
+
+#include ufshcd.h
+#include ufshcd_common.h
+#include linux/pci.h
+
+#ifdef CONFIG_PM
+/**
+ * ufshcd_suspend - suspend power management function
+ * @pdev: pointer to PCI device handle
+ * @state: power state
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ /*
+* TODO:
+* 1. Block SCSI requests from SCSI midlayer
+* 2. Change the internal driver state to non operational
+* 3. Set UTRLRSR and UTMRLRSR bits to zero
+* 4. Wait until outstanding commands are completed
+* 5. Set HCE to zero to send the UFS host controller to reset state
+*/
+
+ return -ENOSYS;
+}
+
+/**
+ * ufshcd_resume - resume power management function
+ * @pdev: pointer to PCI device handle
+ *
+ * Returns -ENOSYS
+ */
[PATCH V2 3/4] [SCSI] ufs: Add Platform glue driver for ufshcd
This patch adds Platform glue driver for ufshcd.
Signed-off-by: Vinayak Holikatti vinholika...@gmail.com
Signed-off-by: Santosh Yaraganavi santos...@gmail.com
---
drivers/scsi/ufs/Kconfig | 11 ++
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufshcd-pltfrm.c | 215 ++
3 files changed, 227 insertions(+)
create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 265a8c8..8c06330 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -67,3 +67,14 @@ config SCSI_UFSHCD_PCI
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config SCSI_UFSHCD_PLATFORM
+ tristate Platform based UFS Controller support
+ depends on SCSI_UFSHCD
+ ---help---
+ This selects the UFS host controller support. If you have a
+ platform with UFS controller, say Y or M here.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 9eda0df..1e5bd48 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,3 +1,4 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
+obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
new file mode 100644
index 000..1d3a63f
--- /dev/null
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -0,0 +1,215 @@
+/*
+ * Universal Flash Storage Host controller driver
+ *
+ * This code is based on drivers/scsi/ufs/ufshcd-pltfm.c
+ * Copyright (C) 2011-2012 Samsung India Software Operations
+ *
+ * Santosh Yaraganavi santosh...@samsung.com
+ * Vinayak Holikatti h.vina...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN AS IS BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ * USA.
+ */
+
+#include ufshcd.h
+#include ufshcd_common.h
+#include linux/platform_device.h
+
+#ifdef CONFIG_PM
+/**
+ * ufshcd_suspend - suspend power management function
+ * @pdev: pointer to Platform device handle
+ * @mesg: power state
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pltfrm_suspend(struct platform_device *pdev,
+pm_message_t mesg)
+{
+ /*
+* TODO:
+* 1. Block SCSI requests from SCSI midlayer
+* 2. Change the internal driver state to non operational
+* 3. Set UTRLRSR and UTMRLRSR bits to zero
+* 4. Wait until outstanding commands are completed
+* 5. Set HCE to zero to send the UFS host controller to reset state
+*/
+
+ return -ENOSYS;
+}
+
+/**
+ * ufshcd_resume - resume power management function
+ * @pdev: pointer to Platform device handle
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pltfrm_resume(struct platform_device *pdev)
+{
+ /*
+* TODO:
+* 1. Set HCE to 1, to start the UFS host controller
+* initialization process
+* 2. Set UTRLRSR and UTMRLRSR bits to 1
+* 3.
Re: [PATCH 1/2] ASoC: Convert S3C24XX I2S driver to gpiolib API
On Thu, Jul 12, 2012 at 08:09:09PM +0200, Sylwester Nawrocki wrote: Thanks, would that be Takashi Iwai and Jaroslav Kysela then ? I just want to get it right this time... Or perhaps could you take care of them ? As with everything else look in MAINTAINERS, so me for ASoC. signature.asc Description: Digital signature
[PATCH V2 4/4] [SCSI] ufs: Correct the expected data transfer size
This patch corrects the expected data transfer size of the command UPIU. The current implementation of cmd-transfersize is wrong as it probably equal to sector size. With this implementation the transfer size is updated correctly Signed-off-by: Vinayak Holikatti vinholika...@gmail.com Signed-off-by: Santosh Yaraganavi santos...@gmail.com --- drivers/scsi/ufs/ufshcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index dfc3e85..5e732c3 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -488,7 +488,7 @@ static void ufshcd_compose_upiu(struct ufshcd_lrb *lrbp) ucd_cmd_ptr-header.dword_2 = 0; ucd_cmd_ptr-exp_data_transfer_len = - cpu_to_be32(lrbp-cmd-transfersize); + cpu_to_be32(lrbp-cmd-sdb.length); memcpy(ucd_cmd_ptr-cdb, lrbp-cmd-cmnd, -- 1.7.9.5 -- 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 0/2] ARM: exynos: Enable TMU support in exynos platforms
On Fri, Jul 13, 2012 at 08:28:18PM +0900, Kukjin Kim wrote: Amit Daniel Kachhap wrote: These TMU enablement patches are needed for exynos4 and exynos5 TMU driver patches sent earlier. The link for those are http://www.spinics.net/lists/lm-sensors/msg35858.html. How was going on above patches? I can't see them you said in linux-next now, it means if I apply this series in my tree, problem will be happened :( Note1: I've seen Rafael's updating exynos4_tmu patch which is using struct dev_pm_ops for pm and applied by Guenter. If that is in the way, I can drop it, to be applied after the move. Let me know. There is now another patch pending, to convert the driver to use devm_ functions. Please let me know what you want me to do with it. Note2: would be helpful if you could do adding me in Cc of exynos tmu patches... If you want to be copied, it might make sense to add yourself as maintainer for this file. Otherwise you can not expect people to know. 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: [PATCH 1/2] ARM: EXYNOS: Move G2D clock entries to clock-exynos4210.c file
On 13 July 2012 19:08, Kukjin Kim kgene@samsung.com wrote:
Sachin Kamat wrote:
G2D clock registers are different in Exynos4210 and Exynos4X12 SoCs.
Hence moving the SoC specific G2D clock entries from common clock file
(clock-exynos4.c) to Exynos4210 specific clock file (clock-exynos4210.c).
Yeah, I agree but there are small comments.
[snip]
+static struct clksrc_clk exynos4_clk_mout_g2d0 = {
In this case, 'exynos4210_clk_mout_g2d0' is clearer, it is static though.
+ .clk= {
+ .name = mout_g2d0,
+ },
+ .sources = exynos4_clkset_mout_g2d0,
+ .reg_src = { .reg = EXYNOS4_CLKSRC_IMAGE, .shift = 0, .size = 1 },
+};
+
+static struct clksrc_clk exynos4_clk_mout_g2d1 = {
Same as above, exynos4210_clk_mout_g2d1.
+ .clk= {
+ .name = mout_g2d1,
+ },
+ .sources = exynos4_clkset_mout_g2d1,
+ .reg_src = { .reg = EXYNOS4_CLKSRC_IMAGE, .shift = 4, .size = 1 },
+};
+
+static struct clk *exynos4_clkset_mout_g2d_list[] = {
Same, exynos4210_clkset_mout_g2d_list[]
+ [0] = exynos4_clk_mout_g2d0.clk,
exynos4210_clk_mout_g2d0.clk
+ [1] = exynos4_clk_mout_g2d1.clk,
exynos4210_clk_mout_g2d1.clk
+};
+
+static struct clksrc_sources exynos4_clkset_mout_g2d = {
Same, exynos4210_clkset_mout_g2d
+ .sources= exynos4_clkset_mout_g2d_list,
exynos4210_clkset_mout_g2d_list
+ .nr_sources = ARRAY_SIZE(exynos4_clkset_mout_g2d_list),
exynos4210_clkset_mout_g2d_list
+};
+
static int exynos4_clksrc_mask_lcd1_ctrl(struct clk *clk, int enable)
{
return s5p_gatectrl(EXYNOS4210_CLKSRC_MASK_LCD1, clk, enable);
@@ -74,6 +100,13 @@ static struct clksrc_clk clksrcs[] = {
.sources = exynos4_clkset_group,
.reg_src = { .reg = EXYNOS4210_CLKSRC_LCD1, .shift =
0, .size = 4 },
.reg_div = { .reg = EXYNOS4210_CLKDIV_LCD1, .shift =
0, .size = 4 },
+ }, {
+ .clk= {
+ .name = sclk_fimg2d,
+ },
+ .sources = exynos4_clkset_mout_g2d,
exynos4210_clkset_mout_g2d
[snip]
Could you please re-submit this after re-working on top of my
next/devel-samsung.
Ok. I will update as per your suggestion and re-send.
Thanks for the review.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
With warm regards,
Sachin
--
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 v5 6/6] spi: s3c64xx: add device tree support
On 13 July 2012 19:12, Kukjin Kim kgene@samsung.com wrote: Thomas Abraham wrote: On 13 July 2012 16:58, Kukjin Kim kgene@samsung.com wrote: Thomas Abraham wrote: On 13 July 2012 04:08, Kukjin Kim kgene@samsung.com wrote: Thomas, the DMACH_DT_PROP is available only on pl330 now. So seems occur following build error with s3c6400_defconfig. drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_get_dmares': drivers/spi/spi-s3c64xx.c:1098: error: 'DMACH_DT_PROP' undeclared (first use in this function) drivers/spi/spi-s3c64xx.c:1098: error: (Each undeclared identifier is reported only once drivers/spi/spi-s3c64xx.c:1098: error: for each function it appears in.) make[3]: *** [drivers/spi/spi-s3c64xx.o] Error 1 make[2]: *** [drivers/spi] Error 2 Dear Mr. Kim, Thanks for considering these patches to be merged via your tree. For the build break you mentioned above, there was a patch submitted some time back to handle this. The link to that patch is: http://lists.infradead.org/pipermail/linux-arm-kernel/2012- June/102627.html. Could you please apply this patch also to your tree. Sure, it looks good to me, will apply that then this series will be rebased on top of that. There are six more patches that enable spi device tree support for Exynos4 and Exynos5 platforms. Could you consider to apply those patches as well. The link to those patches is: http://www.mail-archive.com/linux-samsung- s...@vger.kernel.org/msg10851.html. Yeah, I remember, but I think some patches is needed to re-work as per comments...? I checked again for any pending comments on v2 version. There are no pending comments for the v2 version of this patch series. Thanks. -- 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] ASoC: Convert S3C24XX I2S driver to gpiolib API
On 07/13/2012 04:28 PM, Mark Brown wrote: On Thu, Jul 12, 2012 at 08:09:09PM +0200, Sylwester Nawrocki wrote: Thanks, would that be Takashi Iwai and Jaroslav Kysela then ? I just want to get it right this time... Or perhaps could you take care of them ? As with everything else look in MAINTAINERS, so me for ASoC. Gah, how could I miss that.. especially having gone through the WolfsonMicro ASoC website before. scripts/get_maintainer.pl must have led me astray: $ scripts/get_maintainer.pl -f sound/soc/samsung Ben Dooks ben-li...@fluff.org (maintainer:ARM/SAMSUNG ARM A...) Kukjin Kim kgene@samsung.com (maintainer:ARM/SAMSUNG ARM A...) Sangbeom Kim sbki...@samsung.com (supporter:SAMSUNG AUDIO (AS...) Liam Girdwood l...@ti.com (supporter:SOUND - SOC LAYER...) Mark Brown broo...@opensource.wolfsonmicro.com (supporter:SOUND - SOC LAYER...) Jaroslav Kysela pe...@perex.cz (maintainer:SOUND) Takashi Iwai ti...@suse.de (maintainer:SOUND) linux-arm-ker...@lists.infradead.org (moderated list:ARM/SAMSUNG ARM A...) linux-samsung-soc@vger.kernel.org (moderated list:ARM/SAMSUNG ARM A...) alsa-de...@alsa-project.org (moderated list:SAMSUNG AUDIO (AS...) linux-ker...@vger.kernel.org (open list) Looks like there is something that could be improved in the MAINTAINERS file. -- 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 V2 2/4] [SCSI] drivers/scsi/ufs: Add PCI glue driver
Vinayak Holikatti wrote:
+static int __devinit
+ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ struct ufs_hba *hba;
+ void __iomem *mmio_base;
+ int err;
+
+ err = pci_enable_device(pdev);
+ if (err) {
+ dev_err(pdev-dev, pci_enable_device failed\n);
+ goto out_error;
+ }
My question as basically every time at this point: why not use devres, i.e.
pcim_enable_device()? This would make the cleanup and error handling much
easier. See Documentation/driver-model/devres.txt.
+
+ pci_set_master(pdev);
+
+
Duplicate newline.
Eike
signature.asc
Description: This is a digitally signed message part.
[sachin.ka...@linaro.org: [PATCH] hwmon: exynos4_tmu: Use devm_* functions]
Fyi.
Guenter
- Forwarded message from Sachin Kamat sachin.ka...@linaro.org -
Date: Fri, 13 Jul 2012 14:16:27 +0530
From: Sachin Kamat sachin.ka...@linaro.org
To: lm-sens...@lm-sensors.org
Cc: kh...@linux-fr.org, li...@roeck-us.net, sachin.ka...@linaro.org,
patc...@linaro.org
Subject: [PATCH] hwmon: exynos4_tmu: Use devm_* functions
X-Mailer: git-send-email 1.7.4.1
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
---
drivers/hwmon/exynos4_tmu.c | 44 --
1 files changed, 9 insertions(+), 35 deletions(-)
diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
index e912059..ee6e26c 100644
--- a/drivers/hwmon/exynos4_tmu.c
+++ b/drivers/hwmon/exynos4_tmu.c
@@ -356,7 +356,8 @@ static int __devinit exynos4_tmu_probe(struct
platform_device *pdev)
return -ENODEV;
}
- data = kzalloc(sizeof(struct exynos4_tmu_data), GFP_KERNEL);
+ data = devm_kzalloc(pdev-dev, sizeof(struct exynos4_tmu_data),
+ GFP_KERNEL);
if (!data) {
dev_err(pdev-dev, Failed to allocate driver structure\n);
return -ENOMEM;
@@ -364,48 +365,36 @@ static int __devinit exynos4_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, exynos4_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, exynos4_tmu_irq,
+ ret = devm_request_irq(pdev-dev, data-irq, exynos4_tmu_irq,
IRQF_TRIGGER_RISING,
exynos4-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);
}
data-pdata = pdata;
@@ -440,14 +429,6 @@ err_create_group:
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;
}
@@ -463,15 +444,8 @@ static int __devexit exynos4_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.4.1
- End forwarded message -
--
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
[GIT PULL] Samsung fixes-2 for v3.5
Hi Arnd, Olof, Please pull second samsung fixes for v3.5 from: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.5-samsung-fixes-2 Correcting some values, fixing race and fixing regarding pm_domains are included in. If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit bd0a521e88aa7a06ae7aabaed7ae196ed4ad867a: Linux 3.5-rc6 (2012-07-07 17:23:56 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.5-samsung-fixes-2 Marek Szyprowski (2): ARM: EXYNOS: read initial state of power domain from hw registers ARM: EXYNOS: register devices in 'need_restore' state for pm_domains Sylwester Nawrocki (2): ARM: S3C24XX: Correct AC97 clock control bit for S3C2440 ARM: S3C24XX: Correct CAMIF interrupt definitions Todd Poynor (1): ARM: SAMSUNG: fix race in s3c_adc_start for ADC Tushar Behera (1): ARM: SAMSUNG: Update default rate for xusbxti clock arch/arm/mach-exynos/pm_domains.c | 13 + arch/arm/mach-s3c24xx/clock-s3c2440.c |2 +- arch/arm/plat-samsung/adc.c |8 +--- arch/arm/plat-samsung/devs.c |3 ++- arch/arm/plat-samsung/s5p-clock.c |1 + 5 files changed, 18 insertions(+), 9 deletions(-) -- 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 v5 5/5] ARM: exynos: add thermal sensor driver platform data support
On Fri, Jul 13, 2012 at 8:10 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
Add necessary default platform data support needed for TMU driver. This
dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms.
Looks good to me.
just nitpicks below.
Thank you,
Kyungmin Park
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Cc: Donggeun Kim dg77@samsung.com
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
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
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 9ef8c37..07736ea 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -662,14 +662,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static struct thermal_sensor_conf exynos_sensor_conf = {
.name = exynos-therm,
.read_temperature = (int (*)(void *))exynos_tmu_read,
+};
+
+#if defined(CONFIG_CPU_EXYNOS4210)
BTW, doesn't it same as exynos4412? does it different from exynos4412?
If it's same, it's better to use CONFIG_SOC_EXYNOS4?
+static struct exynos_tmu_platform_data const exynos4_default_tmu_data = {
+ .threshold = 80,
+ .trigger_levels[0] = 5,
+ .trigger_levels[1] = 20,
+ .trigger_levels[2] = 30,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 15,
+ .reference_voltage = 7,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 100,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS4,
+};
+#define EXYNOS4_TMU_DRV_DATA (exynos4_default_tmu_data)
+#else
+#define EXYNOS4_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250)
similar.
+static struct exynos_tmu_platform_data const exynos5_default_tmu_data = {
+ .trigger_levels[0] = 85,
+ .trigger_levels[1] = 103,
+ .trigger_levels[2] = 110,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 8,
+ .reference_voltage = 16,
+ .noise_cancel_mode = 4,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .efuse_value = 55,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 103,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS5,
+};
+#define EXYNOS5_TMU_DRV_DATA (exynos5_default_tmu_data)
+#else
+#define EXYNOS5_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+ {
+ .compatible = samsung,exynos4-tmu,
+ .data = (void *)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .compatible = samsung,exynos5-tmu,
+ .data = (void *)EXYNOS5_TMU_DRV_DATA,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_tmu_match);
+#else
+#define exynos_tmu_match NULL
+#endif
+
+static struct platform_device_id exynos_tmu_driver_ids[] = {
+ {
+ .name = exynos4-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .name = exynos5-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS5_TMU_DRV_DATA,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
+
+static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(exynos_tmu_match, pdev-dev.of_node);
+ if (!match)
+ return NULL;
+ return (struct exynos_tmu_platform_data *) match-data;
+ }
+#endif
+ return (struct exynos_tmu_platform_data *)
+ platform_get_device_id(pdev)-driver_data;
}
-;
static int __devinit exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
struct exynos_tmu_platform_data *pdata = pdev-dev.platform_data;
int ret, i;
+ if (!pdata)
+ pdata = exynos_get_driver_data(pdev);
+
if
