[PATCH RESEND] thermal: add generic cpufreq cooling implementation

2012-09-10 Thread Zhang Rui
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

2012-09-10 Thread Valentin, Eduardo
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

2012-09-10 Thread Zhang Rui
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

2012-09-10 Thread Leela Krishna Amudala
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

2012-09-10 Thread Stephen Warren
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

2012-09-10 Thread Stephen Warren
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

2012-09-10 Thread Linus Walleij
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

2012-09-10 Thread Linus Walleij
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

2012-09-10 Thread Rafael J. Wysocki
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

2012-09-10 Thread Rafael J. Wysocki
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

2012-09-10 Thread Jingoo Han
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