[PATCH RESEND] thermal: add generic cpufreq cooling implementation
Refreshed to remove the notifier mechanism as we do not have a real user of it. if there is no problem, I'll apply the whole patch set to thermal next tree. From: Amit Daniel Kachhap amit.kach...@linaro.org Date: Thu, 16 Aug 2012 17:11:40 +0530 This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Zhang Rui rui.zh...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/thermal/cpu-cooling-api.txt | 33 ++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 450 + include/linux/cpu_cooling.h | 58 5 files changed, 553 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..6fe9cdb --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,33 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + + clip_cpus: cpumask of cpus where the frequency constraints will happen. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the thermal-cpufreq-%x
Re: [PATCH RESEND] thermal: add generic cpufreq cooling implementation
Hello Rui and Amit, On Mon, Sep 10, 2012 at 9:25 AM, Zhang Rui rui.zh...@intel.com wrote: Refreshed to remove the notifier mechanism as we do not have a real user of it. if there is no problem, I'll apply the whole patch set to thermal next tree. From: Amit Daniel Kachhap amit.kach...@linaro.org Date: Thu, 16 Aug 2012 17:11:40 +0530 This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Zhang Rui rui.zh...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com can you please include my Reviewed-by? Also on your patch series I have reviewed. Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com --- Documentation/thermal/cpu-cooling-api.txt | 33 ++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 450 + include/linux/cpu_cooling.h | 58 5 files changed, 553 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..6fe9cdb --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,33 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device
Re: [PATCH RESEND] thermal: add generic cpufreq cooling implementation
On δΈ€, 2012-09-10 at 09:50 +0300, Valentin, Eduardo wrote: Hello Rui and Amit, On Mon, Sep 10, 2012 at 9:25 AM, Zhang Rui rui.zh...@intel.com wrote: Refreshed to remove the notifier mechanism as we do not have a real user of it. if there is no problem, I'll apply the whole patch set to thermal next tree. From: Amit Daniel Kachhap amit.kach...@linaro.org Date: Thu, 16 Aug 2012 17:11:40 +0530 This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Zhang Rui rui.zh...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com can you please include my Reviewed-by? Also on your patch series I have reviewed. sure. Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com thanks! -rui --- Documentation/thermal/cpu-cooling-api.txt | 33 ++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 450 + include/linux/cpu_cooling.h | 58 5 files changed, 553 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..6fe9cdb --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,33 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq
[PATCH] ARM: EXYNOS5: Add bus clock and set parent clock for FIMD
This patch adds the bus clock for FIMD and changes the device name for lcd clock
also sets mout_mpll_user as parent clock to fimd
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
arch/arm/mach-exynos/clock-exynos5.c | 34 +++
arch/arm/plat-samsung/include/plat/clock.h |2 +
2 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 774533c..f1281cf 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -891,6 +891,13 @@ static struct clk exynos5_clk_mdma1 = {
.ctrlbit= (1 4),
};
+static struct clk exynos5_clk_fimd = {
+ .name = fimd,
+ .devname= exynos5-fb,
+ .enable = exynos5_clk_ip_disp1_ctrl,
+ .ctrlbit= (1 0),
+};
+
struct clk *exynos5_clkset_group_list[] = {
[0] = clk_ext_xtal_mux,
[1] = NULL,
@@ -1120,6 +1127,18 @@ static struct clksrc_clk exynos5_clk_sclk_spi2 = {
.reg_div = { .reg = EXYNOS5_CLKDIV_PERIC2, .shift = 8, .size = 8 },
};
+struct clksrc_clk exynos5_clk_sclk_fimd = {
+ .clk= {
+ .name = sclk_fimd,
+ .devname= exynos5-fb,
+ .enable = exynos5_clksrc_mask_disp1_0_ctrl,
+ .ctrlbit= (1 0),
+ },
+ .sources = exynos5_clkset_group,
+ .reg_src = { .reg = EXYNOS5_CLKSRC_DISP1_0, .shift = 0, .size = 4 },
+ .reg_div = { .reg = EXYNOS5_CLKDIV_DISP1_0, .shift = 0, .size = 4 },
+};
+
static struct clksrc_clk exynos5_clksrcs[] = {
{
.clk= {
@@ -1131,16 +1150,6 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.reg_div = { .reg = EXYNOS5_CLKDIV_FSYS3, .shift = 8, .size = 8
},
}, {
.clk= {
- .name = sclk_fimd,
- .devname= s3cfb.1,
- .enable = exynos5_clksrc_mask_disp1_0_ctrl,
- .ctrlbit= (1 0),
- },
- .sources = exynos5_clkset_group,
- .reg_src = { .reg = EXYNOS5_CLKSRC_DISP1_0, .shift = 0, .size =
4 },
- .reg_div = { .reg = EXYNOS5_CLKDIV_DISP1_0, .shift = 0, .size =
4 },
- }, {
- .clk= {
.name = aclk_266_gscl,
},
.sources = clk_src_gscl_266,
@@ -1240,12 +1249,14 @@ static struct clksrc_clk *exynos5_sysclks[] = {
exynos5_clk_mdout_spi0,
exynos5_clk_mdout_spi1,
exynos5_clk_mdout_spi2,
+ exynos5_clk_sclk_fimd,
};
static struct clk *exynos5_clk_cdev[] = {
exynos5_clk_pdma0,
exynos5_clk_pdma1,
exynos5_clk_mdma1,
+ exynos5_clk_fimd,
};
static struct clksrc_clk *exynos5_clksrc_cdev[] = {
@@ -1274,6 +1285,7 @@ static struct clk_lookup exynos5_clk_lookup[] = {
CLKDEV_INIT(dma-pl330.0, apb_pclk, exynos5_clk_pdma0),
CLKDEV_INIT(dma-pl330.1, apb_pclk, exynos5_clk_pdma1),
CLKDEV_INIT(dma-pl330.2, apb_pclk, exynos5_clk_mdma1),
+ CLKDEV_INIT(exynos5-fb, lcd, exynos5_clk_fimd),
};
static unsigned long exynos5_epll_get_rate(struct clk *clk)
@@ -1492,6 +1504,8 @@ void __init_or_cpufreq exynos5_setup_clocks(void)
clk_set_rate(exynos5_clk_aclk_acp.clk, 26700);
clk_set_rate(exynos5_clk_pclk_acp.clk, 13400);
+ clk_set_parent(exynos5_clk_sclk_fimd.clk,
+ exynos5_clk_mout_mpll_user.clk);
for (ptr = 0; ptr ARRAY_SIZE(exynos5_clksrcs); ptr++)
s3c_set_clksrc(exynos5_clksrcs[ptr], true);
diff --git a/arch/arm/plat-samsung/include/plat/clock.h
b/arch/arm/plat-samsung/include/plat/clock.h
index a62753d..3d27783 100644
--- a/arch/arm/plat-samsung/include/plat/clock.h
+++ b/arch/arm/plat-samsung/include/plat/clock.h
@@ -83,6 +83,8 @@ extern struct clk clk_ext;
extern struct clksrc_clk clk_epllref;
extern struct clksrc_clk clk_esysclk;
+extern struct clksrc_clk exynos5_clk_sclk_fimd;
+
/* S3C64XX specific clocks */
extern struct clk clk_h2;
extern struct clk clk_27m;
--
1.7.0.4
--
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] i2c: s3c2410: add optional pin configuration using pinctrl interface
On 09/06/2012 05:06 AM, Thomas Abraham wrote:
On 6 September 2012 15:04, Tomasz Figa t.f...@samsung.com wrote:
Hi,
This patch shows the problem of the need to explicitly migrate all drivers
to pinctrl.
Maybe we should consider extending the pinctrl subsystem to set the default
state automatically before binding a driver to a device, at least in case
of DT-based platforms?
The pinctrl driver allows for activating default pin configuration
when the pinctrl driver loads. This is referred to as hogging. But
should hog be used or not is something that needs to be decided. Some
of the factors which favor the driver explicitly setting up the pin
configuration are
1. After a suspend and resume cycle, the pin configuration registers
may be reset to default values. Hence, during resume, the pin
configuration has be redone.
I'd think it's the pinctrl driver's responsibility to make hogging work
correctly across suspend/resume.
2. Runtime muxing/config is possible.
The client driver would definitely have to be involved there, I agree.
3. Setting some of the config options such as pull-up by default might
start consuming power from boot time itself, which could be avoided if
such setup is done only when needed.
Well, the difference in time between just before driver binding and
during probe is minimal. If the driver/HW really needs to explicitly
differentiate between those states to save power, I'd assert that it's
covered by case (2) above.
Adding pinctrl driver support in device drivers seems to be simple
task. And it is just one time effort which can be reused on multiple
SoC's.
This would be similar to what is done currently with samsung-gpio bindings
- the pin is being configured by custom xlate callback based on additional
cells in GPIO specifier, when the driver retrieves the pin using
of_get{_named,}_gpio without the need of setting it up in the driver.
The Samsung gpio dt bindings was just a bootstrap method to get device
tree support going for Samsung platforms. The gpio xlate callback was
used as a back door to setup the pinmux/pinconfig due to lack of
generic driver interface to setup the pinmux/pinconfig for Samsung
platforms. From a linux perspective, gpio and pinmux/pinconfig are
separate entities. So using gpio xlate to setup pinmux/pinconfig was
not correct but helped getting device tree enabled for Samsung
platforms. With the pinctrl framework available now, there are generic
interfaces to setup gpio and pinmux /pinconfig.
I agree; the Samsung GPIO bindings were surprising to me when I first
realized what was in the GPIO specifiers...
--
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: dts: exynos4: allow i2c0 bus to be configured using pinctrl interface
On 09/06/2012 05:14 AM, Thomas Abraham wrote: On 6 September 2012 15:43, Tomasz Figa t.f...@samsung.com wrote: Hi Thomas, On Thursday 06 of September 2012 14:53:01 Thomas Abraham wrote: compatible = samsung,s3c2440-i2c; reg = 0x1386 0x100; interrupts = 0 58 0; + pinctrl-names = default; + pinctrl-0 = i2c0_bus; If pinctrl-names property is omitted then the state index is used as a name (e.g. pinctrl-0 would be named 0). Maybe it would be better to use this approach (with respective adjustment in first patch)? What do you think? I tend to prefer to name the states because it is easier to cross-reference code and dts files. i2c was a simple one, but for mmc controllers, there will 1-bit state, 4-bit state and 8-bit state, and it will be nicer to name then accordingly. So I prefer to use names but if there is wider consensus on not using names, we can drop names. I would only expect to see multiple states defined in a single board .dts file /if/ runtime muxing is required. Given MMC doesn't runtime mux, I wouldn't expect there to be multiple states for different bus widths; it's just that the default state would point at whatever single configuration is appropriate for the board. -- 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] i2c: s3c2410: add optional pin configuration using pinctrl interface
On Thu, Sep 6, 2012 at 2:28 PM, Tomasz Figa t.f...@samsung.com wrote: Thanks for your comments. On Thursday 06 of September 2012 16:36:08 Thomas Abraham wrote: This patch shows the problem of the need to explicitly migrate all drivers to pinctrl. Maybe we should consider extending the pinctrl subsystem to set the default state automatically before binding a driver to a device, at least in case of DT-based platforms? The pinctrl driver allows for activating default pin configuration when the pinctrl driver loads. This is referred to as hogging. What I suggested is that such default configuration would be applied just before binding a driver, i.e. when it's almost sure that the device will be actually used and the configuration will be needed. In that case the pinctrl driver can poke down a default register configuration, but just like Stephen remarks I do not see the point either. Hogs should work just fine? Of course such functionality would not have to be obligatory. For example, we could add new property, like pinctrl-set-default, to point in device tree that this device should have its pinctrl state set up automatically. This doesn't have a semantic difference to a default hog AFAICT. 1. After a suspend and resume cycle, the pin configuration registers may be reset to default values. Hence, during resume, the pin configuration has be redone. In my opinion it should be saved and restored by pinctrl driver (as it was done in case of GPIO subsystem previously). This is one way to do it. I see Stephen has the same idea. Another way is actually to go to the default state from the default state. Or from any state to itself rather. Currently pinctrl_select_state_locked() contains this: if (p-state == state) return 0; If we just add pinctrl_select_state_force() excluding that clause we can force re-poking of the state at any time. Compare regulator_force_disable() and similar. Maybe this is actually more helpful? Yours, Linus Walleij -- 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] i2c: s3c2410: add optional pin configuration using pinctrl interface
On Thu, Sep 6, 2012 at 11:23 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
Add optional support for i2c bus pin configuration using pinctrl interface
Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
(...)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
(...)
- else
- if (s3c24xx_i2c_parse_dt_gpio(i2c))
+ } else if (!IS_ERR_OR_NULL(i2c-pctrl)
+ !IS_ERR_OR_NULL(i2c-pctrl_state)) {
You don't need to check i2c-pctrl here, just check i2c-pctrl_state.
If i2c-pctrl failed the other one will be null too, anyway.
(Or the struct isn't kzalloc:ed properly... which I assume.)
+ if (pinctrl_select_state(i2c-pctrl, i2c-pctrl_state)) {
+ dev_err(i2c-dev, failed to configure io-pins\n);
+ return -ENXIO;
+ }
+ } else if (s3c24xx_i2c_parse_dt_gpio(i2c)) {
return -EINVAL;
+ }
/* write slave address */
@@ -1013,6 +1022,10 @@ static int s3c24xx_i2c_probe(struct platform_device
*pdev)
i2c-adap.algo_data = i2c;
i2c-adap.dev.parent = pdev-dev;
+ i2c-pctrl = devm_pinctrl_get(i2c-dev);
+ if (!IS_ERR_OR_NULL(i2c-pctrl))
+ i2c-pctrl_state = pinctrl_lookup_state(i2c-pctrl,
default);
+
If all you do is select the default state (later, in the init function)
the use devm_pinctrl_get_select_default() and be done
with it.
In any case do not open code the string default, use
PINCTRL_STATE_DEFAULT which defines to that string.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH RESEND] thermal: add generic cpufreq cooling implementation
On Monday, September 10, 2012, Rafael J. Wysocki wrote: On Monday, September 10, 2012, Zhang Rui wrote: Refreshed to remove the notifier mechanism as we do not have a real user of it. if there is no problem, I'll apply the whole patch set to thermal next tree. From: Amit Daniel Kachhap amit.kach...@linaro.org Date: Thu, 16 Aug 2012 17:11:40 +0530 This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Zhang Rui rui.zh...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Can you please resend the patch inline (i.e. not as an attachment)? Sorry, it was inline (obviously). I seem to be too tired. Please resend it to linux...@vger.kernel.org. The linux-pm list at linux-foundation.org is not functional any more. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH RESEND] thermal: add generic cpufreq cooling implementation
On Monday, September 10, 2012, Zhang Rui wrote: Refreshed to remove the notifier mechanism as we do not have a real user of it. if there is no problem, I'll apply the whole patch set to thermal next tree. From: Amit Daniel Kachhap amit.kach...@linaro.org Date: Thu, 16 Aug 2012 17:11:40 +0530 This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Zhang Rui rui.zh...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Can you please resend the patch inline (i.e. not as an attachment)? Rafael -- 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: EXYNOS5: Add bus clock and set parent clock for FIMD
On Tuesday, September 11, 2012 5:11 AM Leela Krishna Amudala wrote
This patch adds the bus clock for FIMD and changes the device name for lcd
clock
also sets mout_mpll_user as parent clock to fimd
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
arch/arm/mach-exynos/clock-exynos5.c | 34 +++
arch/arm/plat-samsung/include/plat/clock.h |2 +
2 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 774533c..f1281cf 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -891,6 +891,13 @@ static struct clk exynos5_clk_mdma1 = {
.ctrlbit= (1 4),
};
+static struct clk exynos5_clk_fimd = {
+ .name = fimd,
+ .devname= exynos5-fb,
Replace 'exynos5-fb' with 'exynos5-fb.1', as exynos4 fimd uses exynos4-fb.0
as devname. Exynos5 can use fimd0 or fimd1. Also, Exynos5250 uses fimd1.
+ .enable = exynos5_clk_ip_disp1_ctrl,
+ .ctrlbit= (1 0),
+};
+
--
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
