Re: [PATCH v5 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver

2014-01-09 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Thursday, January 09, 2014 08:58:13 AM Shaik Ameer Basha wrote:
 This patch adds the Makefile and memory to memory (m2m) interface
 functionality for the SCALER driver.
 
 [arun...@samsung.com: fix compilation issues]
 
 Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
 Signed-off-by: Arun Kumar K arun...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  drivers/media/platform/Kconfig|8 +
  drivers/media/platform/Makefile   |1 +
  drivers/media/platform/exynos-scaler/Makefile |3 +
  drivers/media/platform/exynos-scaler/scaler-m2m.c |  788 
 +

It would be cleaner to add Kconfig + Makefiles in the same patch
that adds core functionality (patch #2) and then switch the order of
patch #2 and patch #3.

  4 files changed, 800 insertions(+)
  create mode 100644 drivers/media/platform/exynos-scaler/Makefile
  create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
 
 diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
 index b2a4403..aec5b80 100644
 --- a/drivers/media/platform/Kconfig
 +++ b/drivers/media/platform/Kconfig
 @@ -196,6 +196,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
   help
 This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
  
 +config VIDEO_SAMSUNG_EXYNOS_SCALER
 + tristate Samsung Exynos SCALER driver
 + depends on OF  VIDEO_DEV  VIDEO_V4L2  ARCH_EXYNOS5

Please check for EXYNOS5410 and EXYNOS5420 explicitly instead
of checking just for ARCH_EXYNOS5.

Also this config option doesn't need to depend on OF since
the whole EXYNOS support is OF only now.

 + select VIDEOBUF2_DMA_CONTIG
 + select V4L2_MEM2MEM_DEV
 + help
 +   This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER.
 +
  config VIDEO_SH_VEU
   tristate SuperH VEU mem2mem video processing driver
   depends on VIDEO_DEV  VIDEO_V4L2  HAS_DMA

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

--
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 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver

2014-01-09 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Thursday, January 09, 2014 08:58:12 AM Shaik Ameer Basha wrote:
 This patch adds the core functionality for the SCALER driver.
 
 Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  drivers/media/platform/exynos-scaler/scaler.c | 1231 
 +
  drivers/media/platform/exynos-scaler/scaler.h |  376 
  2 files changed, 1607 insertions(+)
  create mode 100644 drivers/media/platform/exynos-scaler/scaler.c
  create mode 100644 drivers/media/platform/exynos-scaler/scaler.h

[...]

 +static int scaler_probe(struct platform_device *pdev)
 +{
 + struct scaler_dev *scaler;
 + struct resource *res;
 + struct device *dev = pdev-dev;
 + int ret;
 +
 + if (!dev-of_node)
 + return -ENODEV;
 +
 + scaler = devm_kzalloc(dev, sizeof(*scaler), GFP_KERNEL);
 + if (!scaler)
 + return -ENOMEM;
 +
 + scaler-pdev = pdev;
 + scaler-variant = scaler_get_variant_data(pdev);
 +
 + init_waitqueue_head(scaler-irq_queue);
 + spin_lock_init(scaler-slock);
 + mutex_init(scaler-lock);
 + scaler-clock = ERR_PTR(-EINVAL);
 +
 + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 + scaler-regs = devm_request_and_ioremap(dev, res);
 + if (!scaler-regs)
 + return -ENODEV;
 +
 + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 + if (!res) {
 + dev_err(dev, failed to get IRQ resource\n);
 + return -ENXIO;
 + }
 +
 + ret = scaler_clk_get(scaler);
 + if (ret  0)
 + return ret;
 +
 + ret = devm_request_irq(dev, res-start, scaler_irq_handler,
 + 0, pdev-name, scaler);
 + if (ret  0) {
 + dev_err(dev, failed to install irq (%d)\n, ret);
 + goto err_clk;
 + }
 +
 + platform_set_drvdata(pdev, scaler);
 + pm_runtime_enable(dev);
 +
 + /* Initialize the continious memory allocator */
 + scaler-alloc_ctx = vb2_dma_contig_init_ctx(dev);
 + if (IS_ERR(scaler-alloc_ctx)) {
 + ret = PTR_ERR(scaler-alloc_ctx);
 + goto err_clk;
 + }
 +
 + ret = v4l2_device_register(dev, scaler-v4l2_dev);
 + if (ret  0)
 + goto err_clk;
 +
 + ret = scaler_register_m2m_device(scaler);
 + if (ret  0)
 + goto err_v4l2;
 +
 + dev_info(dev, registered successfully\n);
 + return 0;
 +
 +err_v4l2:
 + v4l2_device_unregister(scaler-v4l2_dev);
 +err_clk:
 + scaler_clk_put(scaler);

vb2_dma_contig_cleanup_ctx() and pm_runtime_disable() calls on
failure are missing

 + return ret;
 +}
 +
 +static int scaler_remove(struct platform_device *pdev)
 +{
 + struct scaler_dev *scaler = platform_get_drvdata(pdev);
 +
 + scaler_unregister_m2m_device(scaler);
 + v4l2_device_unregister(scaler-v4l2_dev);
 +
 + vb2_dma_contig_cleanup_ctx(scaler-alloc_ctx);
 + pm_runtime_disable(pdev-dev);
 + scaler_clk_put(scaler);
 +
 + scaler_dbg(scaler, %s driver unloaded\n, pdev-name);
 + return 0;
 +}

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

--
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 4/4] [media] exynos-scaler: Add DT bindings for SCALER driver

2014-01-09 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Thursday, January 09, 2014 08:58:14 AM Shaik Ameer Basha wrote:
 This patch adds the DT binding documentation for the
 Exynos5420/5410 based SCALER device driver.
 
 Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  .../devicetree/bindings/media/exynos5-scaler.txt   |   22 
 
  1 file changed, 22 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt
 
 diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt 
 b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
 new file mode 100644
 index 000..9328e7d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
 @@ -0,0 +1,22 @@
 +* Samsung Exynos5 SCALER device
 +
 +SCALER is used for scaling, blending, color fill and color space
 +conversion on EXYNOS[5420/5410] SoCs.
 +
 +Required properties:
 +- compatible: should be samsung,exynos5420-scaler or
 + samsung,exynos5410-scaler
 +- reg: should contain SCALER physical address location and length
 +- interrupts: should contain SCALER interrupt number
 +- clocks: should contain the SCALER clock specifier, from the
 + common clock bindings
 +- clock-names: should be scaler
 +
 +Example:
 + scaler_0: scaler@1280 {
 + compatible = samsung,exynos5420-scaler;
 + reg = 0x1280 0x1000;
 + interrupts = 0 220 0;
 + clocks = clock 381;
 + clock-names = scaler;
 + };

Your patchset adds support for EXYNOS5 SCALER but doesn't add any real
users of it yet.  Could you please explain why?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

--
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 4/6 v2] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver

2014-01-09 Thread Sachin Kamat 
Hi Naveen,

On 9 January 2014 10:29, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote:
 From: Naveen Krishna Ch ch.nav...@samsung.com

 This patch modifies Kconfig such that ARCH_EXYNOS SoCs
 which includes (Exynos4210, Exynos5250 and Exynos5420)
 can also select Samsung SSS(Security SubSystem) driver.

What about Exynos4x12 and 5440 as they too come under ARCH_EXYNOS?

-- 
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 3/6 v2] crypto:s5p-sss: Add support for SSS module on Exynos

2014-01-09 Thread Sachin Kamat 
Hi Naveen,

On 9 January 2014 10:29, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote:
 This patch adds new compatible and varient to support the SSS module
 on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250) for which
 1. AES register are at an offset of 0x200 and
 2. hash interrupt is not available

 Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
 CC: Herbert Xu herb...@gondor.apana.org.au
 CC: David S. Miller da...@davemloft.net
 CC: Vladimir Zapolskiy vzapols...@gmail.com
 TO: linux-cry...@vger.kernel.org
 CC: linux-samsung-soc@vger.kernel.org
 ---
 Changes since v1:
 1. Used varient struct
 2. Added description in Documentation

  .../devicetree/bindings/crypto/samsung-sss.txt |   20 +
  drivers/crypto/s5p-sss.c   |   43 
 ++--
  2 files changed, 51 insertions(+), 12 deletions(-)

 diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt 
 b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
 index 0e45b0d..4531da2 100644
 --- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
 +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
 @@ -8,13 +8,33 @@ The SSS module in S5PV210 SoC supports the following:
  -- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
  -- PRNG: Pseudo Random Number Generator

 +The SSS module in Exynos4 (Exynos4210) and
 +Exynos5 (Exynos5420 and Exynos5250) SoCs
 +supports the following also:
 +-- ARCFOUR (ARC4)
 +-- True Random Number Generator (TRNG)
 +-- Secure Key Manager
 +
  Required properties:

  - compatible : Should contain entries for this and backward compatible
SSS versions:
- samsung,s5p-secss for S5PV210 SoC.
 +  - samsung,exynos-secss for Exynos4210, Exynos5250 and Exynos5420 SoCs.

Shouldn't the compatible string be more specific with the name of the
first SoC that had this IP?

-- 
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: Arndale Timer Interrupt Question

2014-01-09 Thread Bartlomiej Zolnierkiewicz 

added linux-samsung-soc to cc:,
it is a better suited list for this question

On Thursday, January 09, 2014 10:30:56 AM Mj Embd wrote:
 I am a bit confused on the interrupt number for CNTVIRQ..CNTHPIRQ. Can
 you please help here.
 
 As per the exynos5 public manual
 What is the difference between  CPU_nCNTHPIRQ[0] and CNTHPIRQ.
 
 While the later has an interrupt ID 26, the former is part of a group
 with combined interrupt id as 33 for core 0 and 54 for core 1.
 
 For a timer interrupt which goes to PL2, which id should be used 26 or
 33 for core 0 ?
 
 Please clear this confusion.
 
 Many 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 2/6 v2] crypto:s5p-sss: Add device tree support

2014-01-09 Thread Tomasz Figa 

Hi Naveen,

On 09.01.2014 05:59, Naveen Krishna Chatradhi wrote:

This patch adds device tree support to the s5p-sss.c crypto driver.
Implements a varient struct to address the changes in SSS hardware
on various SoCs from Samsung.

Also, Documentation under devicetree/bindings added.

Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v1:
1. Added description of the SSS module in Documentation
2. Corrected the interrupts description
3. Added varient struct instead of the version variable

  .../devicetree/bindings/crypto/samsung-sss.txt |   20 +
  drivers/crypto/s5p-sss.c   |   81 ++--
  2 files changed, 95 insertions(+), 6 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt

diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt 
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..0e45b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,20 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  SSS versions:
+  - samsung,s5p-secss for S5PV210 SoC.


As I wrote in my previous reply, please use specific compatible string 
containing name of SoC on which the block described by it appeared 
first. Let me say it again, for security block that showed up first on 
S5PV210 the string will be samsung,s5pv210-secss.



+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+   Two interrupts feed control and hash in case of S5PV210
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name to be requested in the SSS driver.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..78e0c37 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
  #include linux/scatterlist.h
  #include linux/dma-mapping.h
  #include linux/io.h
+#include linux/of.h
  #include linux/crypto.h
  #include linux/interrupt.h

@@ -145,6 +146,20 @@
  #define AES_KEY_LEN 16
  #define CRYPTO_QUEUE_LEN1

+/**
+ * struct samsung_aes_varient - platform specific SSS driver data


typo: s/varient/variant/g

Anyway, I think this should be moved to the patch adding support for 
Exynos5, as before it there is no use for this struct and it's not 
directly related to DT support.



+ * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
+ * @aes_offset: AES register offset from SSS module's base.
+ *
+ * Specifies platform specific configuration of SSS module.
+ * Note: A structure for driver specific platform data is used for future
+ * expansion of its usage.
+ */
+struct samsung_aes_varient {
+   boolhas_hash_irq;
+   unsigned intaes_offset;
+};
+
  struct s5p_aes_reqctx {
unsigned long mode;
  };
@@ -173,10 +188,56 @@ struct s5p_aes_dev {
struct crypto_queue queue;
boolbusy;
spinlock_t  lock;
+
+   struct samsung_aes_varient *varient;
  };

  static struct s5p_aes_dev *s5p_dev;

+static struct samsung_aes_varient s5p_aes_data = {


Remember to mark constant data as const.


+   .has_hash_irq   = true,
+   .aes_offset = 0x4000,
+};
+
+static const struct platform_device_id s5p_sss_ids[] = {
+   {
+   .name   = s5p-secss,
+   .driver_data= (kernel_ulong_t)s5p_aes_data,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(platform, s5p_sss_ids);
+
+#ifdef CONFIG_OF
+static const struct of_device_id s5p_sss_dt_match[] = {
+   {
+   .compatible = samsung,s5p-secss,
+   .data = (void *)s5p_aes_data,


No need to cast pointers to (void *) explicitly.


+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+#else
+static struct of_device_id s5p_sss_dt_match[] =  {
+   { },
+};


Hmm, I don't think there is any need for this.


+#endif
+
+static inline struct samsung_aes_varient *find_s5p_sss_version
+  (struct platform_device *pdev)
+{
+   if (IS_ENABLED(CONFIG_OF)) {
+   if (pdev-dev.of_node) {


What about using a single if, as follows:

if (IS_ENABLED(CONFIG_IF)  pdev-dev.of_node)


+   const

[PATCH 0/6] cpufreq: use cpufreq-cpu0 driver for exynos4210 based platforms

2014-01-09 Thread Thomas Abraham 
The patch series removes the use of Exynos4210 specific cpufreq driver
and enables to use the cpufreq-cpu0 driver for Exynos4210 based platforms.
This is being done for few reasons.

(a) The Exynos4210 cpufreq driver reads/writes clock controller registers
bypassing the Exynos4 CCF driver which is sort of problematic.
(b) Removes the need for having clock controller register definitions
in the cpufreq driver and also removes the need for statically
io-remapping clock controller address space (helps in moving towards
multiplatform kernel).

In order to use cpufreq-cpu0 driver and provide fast cpu clock switching
during dvfs operations, the following apporach has been used.

(a) A new CPU clock provider type has been introduced in Samsung's CCF
support. This clock provider type can be a compostion of multiple
clock blocks such as mux, dividers and gates. Typically, in Exynos
platforms, there are multiple clock blocks in between the output
of the APLL and the CPU clock domain output. Representing these
mutiple clock blocks within a opaque CPU clock provider type helps
in reducing the time taken to perform a CPU clock frequency change
operation, which is generally required during DVFS operations.
This approach was suggested by Arnd Bergmann a...@arndb.de during
LCE-2013.

(b) A new optional safe operating point property has been introduced
in the cpufreq-cpu0 driver binding. On some platforms such as the
Samsung Exynos, a change in CPU frequency requires a change in the
PLL output that drives the CPU clock. A change in PLL output
requires the PLL output be turned off, which implies that the CPU
(and other components in the CPU clock domain) be supplied with
an alternate clock source during the time the PLL output is changed.

The clock speed of this alternate clock source could be higher
than the clock speed of the PLL at the time of switching over to
the alternate clock source. This temporary increase in clock speed
of the CPU clock domain implies that the blocks within the CPU
clock domain should also be supplied with an appropriate voltage
supply level as required to drive the CPU clock domain components
at the speed of the alternative clock source. This temporary
voltage level required during switching of CPU clock speed is
called safe voltage level. And the cpufreq-cpu0 driver has been
modified to setup the safe voltage levels during the changes
in CPU clock speed.

(c) The CPU clock supply as been restructured as
[ Output of APLL - Opaque CPU clock provider - CPU clock output ]
And with the changes in (a) and (b) above, the cpufreq-cpu0 driver
can now be used and can remove the use of Exynos4210 specific
cpufreq driver.

This approach is currently tried on Exynos4210 only. The same approach
can be adopted for other Exynos SoCs as well. This patch series is
based on linux-next master branch.

Thomas Abraham (6):
  cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency 
transitions
  clk: samsung: add infrastructure to register CPU clocks
  clk: samsung: register cpu clock provider for exynos4210 SoC
  cpufreq: exynos: remove Exynos4210 specific cpufreq driver support
  arm: exynos4-dt: statically add platform device for cpufreq-cpu0 platform 
driver
  arm: dts: add cpu nodes for Exynos4210 SoC

 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |5 +
 arch/arm/boot/dts/exynos4210-origen.dts|6 +
 arch/arm/boot/dts/exynos4210-trats.dts |6 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts|6 +
 arch/arm/boot/dts/exynos4210.dtsi  |   22 +++
 arch/arm/mach-exynos/mach-exynos4-dt.c |6 +
 drivers/clk/samsung/clk-exynos4.c  |   96 -
 drivers/clk/samsung/clk.c  |   71 +
 drivers/clk/samsung/clk.h  |   37 +-
 drivers/cpufreq/Kconfig.arm|   11 --
 drivers/cpufreq/Makefile   |1 -
 drivers/cpufreq/cpufreq-cpu0.c |   49 ++-
 drivers/cpufreq/exynos-cpufreq.c   |4 +-
 drivers/cpufreq/exynos-cpufreq.h   |8 -
 drivers/cpufreq/exynos4210-cpufreq.c   |  157 
 15 files changed, 301 insertions(+), 184 deletions(-)
 delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c


--
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 3/6] clk: samsung: register cpu clock provider for exynos4210 SoC

2014-01-09 Thread Thomas Abraham 
Add a new clock provider for ARM clock domain. This clock provider
is composed of multiple components which include mux_core, div_core,
div_core2, div_corem0, div_corem1, div_periph, div_atb, div_pclk_dbg,
div_copy and div_hpm. This composition of mutiple components into
a single clock provider helps with faster completion of CPU clock
speed switching during DVFS operations.

Signed-off-by: Thomas Abraham thomas...@samsung.com
---
 drivers/clk/samsung/clk-exynos4.c |   96 -
 1 files changed, 95 insertions(+), 1 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index d967571..4bf2f93 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -108,8 +108,11 @@
 #define APLL_CON0  0x14100
 #define E4210_MPLL_CON00x14108
 #define SRC_CPU0x14200
+#define STAT_CPU   0x14400
 #define DIV_CPU0   0x14500
 #define DIV_CPU1   0x14504
+#define DIV_STAT_CPU0  0x14600
+#define DIV_STAT_CPU1  0x14604
 #define GATE_SCLK_CPU  0x14800
 #define GATE_IP_CPU0x14900
 #define E4X12_DIV_ISP0 0x18300
@@ -289,7 +292,7 @@ static unsigned long exynos4_clk_regs[] __initdata = {
 };
 
 /* list of all parent clock list */
-PNAME(mout_apll_p) = { fin_pll, fout_apll, };
+PNAME(mout_apll_p) = { fin_pll, fout_apll1, };
 PNAME(mout_mpll_p) = { fin_pll, fout_mpll, };
 PNAME(mout_epll_p) = { fin_pll, fout_epll, };
 PNAME(mout_vpllsrc_p)  = { fin_pll, sclk_hdmi24m, };
@@ -306,6 +309,7 @@ PNAME(mout_onenand_p)  = {aclk133, aclk160, };
 PNAME(mout_onenand1_p) = {mout_onenand, sclk_vpll, };
 
 /* Exynos 4210-specific parent groups */
+PNAME(armclk_p) = { fout_apll, };
 PNAME(sclk_vpll_p4210) = { mout_vpllsrc, fout_vpll, };
 PNAME(mout_core_p4210) = { mout_apll, sclk_mpll, };
 PNAME(sclk_ampll_p4210)= { sclk_mpll, sclk_apll, };
@@ -1089,6 +1093,92 @@ static struct samsung_pll_clock exynos4x12_plls[nr_plls] 
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
 };
 
+#define EXYNOS4210_DIV_CPU0(apll, pclk_dbg, atb, periph, corem1, corem0) \
+   ((apll  24) | (pclk_dbg  20) | (atb  16) | \
+   (periph  12) | (corem1  8) | (corem0  4))
+#define EXYNOS4210_DIV_CPU1(hpm, copy) \
+   ((hpm  4) | (copy  0))
+static const unsigned long exynos4210_armclk_data[][2] = {
+   { EXYNOS4210_DIV_CPU0(7, 1, 4, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 5), },
+   { EXYNOS4210_DIV_CPU0(7, 1, 4, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 4), },
+   { EXYNOS4210_DIV_CPU0(7, 1, 3, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 3), },
+   { EXYNOS4210_DIV_CPU0(7, 1, 3, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 3), },
+   { EXYNOS4210_DIV_CPU0(7, 1, 3, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 3), },
+   { EXYNOS4210_DIV_CPU0(0, 1, 3, 1, 3, 1), EXYNOS4210_DIV_CPU1(0, 3), },
+};
+
+static const unsigned long exynos4210_armclk_freqs[] = {
+   120 , 100, 80, 50, 40, 20,
+};
+
+static const struct samsung_core_clock_freq_table exyno4210_armclk_table = {
+   .freq   = exynos4210_armclk_freqs,
+   .freq_count = ARRAY_SIZE(exynos4210_armclk_freqs),
+   .data   = (void *)exynos4210_armclk_data,
+};
+
+static int exynos4210_armclk_set_rate(struct clk_hw *hw, unsigned long drate,
+   unsigned long prate)
+{
+   struct samsung_core_clock *armclk;
+   const struct samsung_core_clock_freq_table *freq_tbl;
+   unsigned long *freq_data;
+   unsigned long mux_reg, idx;
+   void __iomem *base;
+
+   if (drate == prate)
+   return 0;
+
+   armclk = container_of(hw, struct samsung_core_clock, hw);
+   freq_tbl = armclk-freq_table;
+   freq_data = (unsigned long *)freq_tbl-data;
+   base = armclk-ctrl_base;
+
+   for (idx = 0; idx  freq_tbl-freq_count; idx++, freq_data += 2)
+   if ((freq_tbl-freq[idx] * 1000) == drate)
+   break;
+
+   if (!armclk-fout_pll)
+   armclk-fout_pll = __clk_lookup(fout_apll);
+
+   if (drate  prate) {
+   mux_reg = readl(base + SRC_CPU);
+   writel(mux_reg | (1  16), base + SRC_CPU);
+   while (((readl(base + STAT_CPU)  16)  0x7) != 2)
+   ;
+
+   clk_set_rate(armclk-fout_pll, drate);
+   }
+
+   writel(freq_data[0], base + DIV_CPU0);
+   while (readl(base + DIV_STAT_CPU0) != 0)
+   ;
+   writel(freq_data[1], base + DIV_CPU1);
+   while (readl(base + DIV_STAT_CPU1) != 0)
+   ;
+
+   if (drate  prate) {
+   mux_reg = readl(base + SRC_CPU);
+   writel(mux_reg | (1  16), base + SRC_CPU);
+   while (((readl(base + STAT_CPU)  16)  0x7) != 2)
+   ;
+
+   clk_set_rate(armclk-fout_pll, drate);
+

[PATCH 2/6] clk: samsung: add infrastructure to register CPU clocks

2014-01-09 Thread Thomas Abraham 
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.

Signed-off-by: Thomas Abraham thomas...@samsung.com
---
 drivers/clk/samsung/clk.c |   71 +
 drivers/clk/samsung/clk.h |   37 +++-
 2 files changed, 107 insertions(+), 1 deletions(-)

diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index f503f32..9ac9056 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -316,3 +316,74 @@ unsigned long _get_rate(const char *clk_name)
 
return clk_get_rate(clk);
 }
+
+/*
+ * On most platform, the core clock rate is equal to the clock rate of
+ * parent pll. This is a simple helper function to support recalc_rate
+ * callback for such platforms.
+ */
+unsigned long samsung_core_clock_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   /*
+* Assuming that the output of the parent pll is the output clock
+* frequency of the core clock.
+*/
+   return parent_rate;
+}
+
+/* This is a helper function to perform clock rounding for core clocks. */
+long samsung_core_clk_round_rate(struct clk_hw *hw,
+   unsigned long drate, unsigned long *prate)
+{
+   struct samsung_core_clock *core_clk;
+   const struct samsung_core_clock_freq_table *freq_tbl;
+   int i;
+
+   core_clk = container_of(hw, struct samsung_core_clock, hw);
+   freq_tbl = core_clk-freq_table;
+   drate /= 1000;
+
+   for (i = 0; i  freq_tbl-freq_count; i++) {
+   if (drate = freq_tbl-freq[i])
+   return freq_tbl-freq[i] * 1000;
+   }
+   return freq_tbl-freq[i - 1] * 1000;
+}
+
+/* helper function to register a core clock */
+void __init samsung_coreclk_register(const char *name, const char **parents,
+   unsigned int num_parents, const char *pllclk,
+   const struct clk_ops *clk_ops, unsigned int lookup_id,
+   const struct samsung_core_clock_freq_table *freq_tbl)
+{
+   struct samsung_core_clock *coreclk;
+   struct clk_init_data init;
+   struct clk *clk;
+
+   coreclk = kzalloc(sizeof(*coreclk), GFP_KERNEL);
+   if (!coreclk) {
+   pr_err(%s: could not allocate memory for coreclk %s\n,
+   __func__, name);
+   return;
+   }
+
+   init.name = name;
+   init.flags = CLK_GET_RATE_NOCACHE;
+   init.parent_names = parents;
+   init.num_parents = num_parents;
+   init.ops = clk_ops;
+
+   coreclk-hw.init = init;
+   coreclk-ctrl_base = reg_base;
+   coreclk-fout_pll = __clk_lookup(pllclk);
+   coreclk-freq_table = freq_tbl;
+
+   clk = clk_register(NULL, coreclk-hw);
+   if (IS_ERR(clk)) {
+   pr_err(%s: could not register coreclk %s\n, __func__, name);
+   kfree(coreclk);
+   return;
+   }
+   samsung_clk_add_lookup(clk, lookup_id);
+}
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 31b4174..0e43023 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -312,6 +312,37 @@ struct samsung_pll_clock {
__PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
_lock, _con, _rtable, _alias)
 
+/**
+ * struct samsung_core_clock_freq_table: table of frequency supported by
+ * a core clock and associated data if any.
+ * @freq: points to a table of supported frequencies (in KHz)
+ * @freq_count: number of entries in the frequency table
+ * @data: core clock specific data, if any
+ */
+struct samsung_core_clock_freq_table {
+   const unsigned long *freq;   /* in KHz */
+   unsigned long   freq_count;
+   const void  *data;
+};
+
+/**
+ * struct samsung_core_clock: information about clock supplied to a CPU core.
+ * @hw: handle between ccf and core clock.
+ * @ctrl_base: base address of the clock controller.
+ * @fout_pll: clock handle representing the clock output of the associated PLL.
+ */
+struct samsung_core_clock {
+   struct clk_hw   hw;
+   void __iomem*ctrl_base;
+   struct clk  *fout_pll;
+   const struct samsung_core_clock_freq_table *freq_table;
+};
+
+extern unsigned long samsung_core_clock_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate);
+extern long samsung_core_clk_round_rate(struct clk_hw *hw,
+   unsigned long drate, unsigned long *prate);
+
 extern void __init samsung_clk_init(struct device_node *np, void __iomem *base,

[PATCH 1/6] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions

2014-01-09 Thread Thomas Abraham 
On some platforms such as the Samsung Exynos, changing the frequency
of the CPU clock requires changing the frequency of the PLL that is
supplying the CPU clock. To change the frequency of the PLL, the CPU
clock is temporarily reparented to another parent clock.

The clock frequency of this temporary parent clock could be much higher
than the clock frequency of the PLL at the time of reparenting. Due
to the temporary increase in the CPU clock speed, the CPU (and any other
components in the CPU clock domain such as dividers, mux, etc.) have to
to be operated at a higher voltage level, called the safe voltage level.
This patch adds optional support to temporarily switch to a safe voltage
level during CPU frequency transitions.

Cc: Shawn Guo shawn@linaro.org
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |5 ++
 drivers/cpufreq/cpufreq-cpu0.c |   49 +++-
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..020d859 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -19,6 +19,10 @@ Optional properties:
 - cooling-min-level:
 - cooling-max-level:
  Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
+- safe-opp-index: Certain platforms require that during a opp transition,
+  a system should not go below a particular opp level. For such systems,
+  this property specifies the minimum opp to be maintained during the
+  opp transitions.
 
 Examples:
 
@@ -36,6 +40,7 @@ cpus {
396000  95
198000  85
;
+   safe-opp-index = 1;
clock-latency = 61036; /* two CLK32 periods */
#cooling-cells = 2;
cooling-min-level = 0;
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 0c12ffc..dda4b7b 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -27,6 +27,8 @@
 
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
+static unsigned long safe_frequency;
+static unsigned long safe_voltage;
 
 static struct device *cpu_dev;
 static struct clk *cpu_clk;
@@ -69,12 +71,26 @@ static int cpu0_set_target(struct cpufreq_policy *policy, 
unsigned int index)
 new_freq / 1000, volt ? volt / 1000 : -1);
 
/* scaling up?  scale voltage before frequency */
-   if (!IS_ERR(cpu_reg)  new_freq  old_freq) {
+   if (!IS_ERR(cpu_reg)  new_freq  old_freq 
+   new_freq = safe_frequency) {
ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
if (ret) {
pr_err(failed to scale voltage up: %d\n, ret);
return ret;
}
+   } else if (!IS_ERR(cpu_reg)  old_freq  safe_frequency) {
+   /*
+* the scaled up voltage level for the new_freq is lower
+* than the safe voltage level. so set safe_voltage
+* as the intermediate voltage level and revert it
+* back after the frequency has been changed.
+*/
+   ret = regulator_set_voltage(cpu_reg, safe_voltage,
+   safe_voltage);
+   if (ret) {
+   pr_err(failed to set safe voltage: %d\n, ret);
+   return ret;
+   }
}
 
ret = clk_set_rate(cpu_clk, freq_exact);
@@ -94,6 +110,19 @@ static int cpu0_set_target(struct cpufreq_policy *policy, 
unsigned int index)
}
}
 
+   /*
+* if safe voltage was applied during voltage scale up, then set
+* the correct target voltage now.
+*/
+   if (!IS_ERR(cpu_reg)  new_freq  old_freq 
+   new_freq  safe_frequency) {
+   ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+   if (ret) {
+   pr_err(failed to scale voltage up: %d\n, ret);
+   return ret;
+   }
+   }
+
return ret;
 }
 
@@ -116,7 +145,9 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
 
 static int cpu0_cpufreq_probe(struct platform_device *pdev)
 {
+   struct dev_pm_opp *opp;
struct device_node *np;
+   unsigned int safe_opp_index;
int ret;
 
cpu_dev = get_cpu_device(0);
@@ -165,13 +196,27 @@ static int cpu0_cpufreq_probe(struct platform_device 
*pdev)
goto out_put_node;
}
 
+   if (!of_property_read_u32(np, safe-opp-index, safe_opp_index)) {
+   rcu_read_lock();
+   opp =

[PATCH 6/6] arm: dts: add cpu nodes for Exynos4210 SoC

2014-01-09 Thread Thomas Abraham 
Add CPU nodes for Exynos4210 SoC and also properties required by the
cpufreq-cpu0 driver.

Signed-off-by: Thomas Abraham thomas...@samsung.com
---
 arch/arm/boot/dts/exynos4210-origen.dts |6 ++
 arch/arm/boot/dts/exynos4210-trats.dts  |6 ++
 arch/arm/boot/dts/exynos4210-universal_c210.dts |6 ++
 arch/arm/boot/dts/exynos4210.dtsi   |   22 ++
 4 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-origen.dts 
b/arch/arm/boot/dts/exynos4210-origen.dts
index 2aa13cb..afecd8f 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -32,6 +32,12 @@
bootargs =root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M 
console=ttySAC2,115200 init=/linuxrc;
};
 
+   cpus {
+   cpu: cpu@0 {
+   cpu0-supply = buck1_reg;
+   };
+   };
+
regulators {
compatible = simple-bus;
#address-cells = 1;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 63cc571..25487d7 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,6 +30,12 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 
rootwait earlyprintk panic=5;
};
 
+   cpus {
+   cpu: cpu@0 {
+   cpu0-supply = varm_breg;
+   };
+   };
+
regulators {
compatible = simple-bus;
 
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d2e3f5f..74d5a70 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,12 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw 
rootwait earlyprintk panic=5 maxcpus=1;
};
 
+   cpus {
+   cpu: cpu@0 {
+   cpu0-supply = vdd_arm_reg;
+   };
+   };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index 48ecd7a..3db2da8 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -36,6 +36,28 @@
reg = 0x10023CA0 0x20;
};
 
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+   cpu: cpu@0 {
+   device_type = cpu;
+   compatible = arm,cortex-a9;
+   reg = 0;
+   clocks = clock 12;
+   clock-names = cpu;
+
+   operating-points = 
+   20  95
+   40  975000
+   50  975000
+   80  1075000
+   100 115
+   120 125
+   ;
+   safe-opp-index = 3;
+   };
+   };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x8000;
};
-- 
1.6.6.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6] arm: exynos4-dt: statically add platform device for cpufreq-cpu0 platform driver

2014-01-09 Thread Thomas Abraham 
In order to use the cpufreq-cpu0 driver on Exynos4 based platforms,
statically add the platform device for cpufreq-cpu0 platform driver.

Signed-off-by: Thomas Abraham thomas...@samsung.com
---
 arch/arm/mach-exynos/mach-exynos4-dt.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c 
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index d3e54b7..8b8ad41 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -19,11 +19,17 @@
 
 #include common.h
 
+static struct platform_device cpufreq_device = {
+   .name   = cpufreq-cpu0,
+   .id = -1,
+};
+
 static void __init exynos4_dt_machine_init(void)
 {
exynos_cpuidle_init();
exynos_cpufreq_init();
 
+   platform_device_register(cpufreq_device);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-- 
1.6.6.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/6] cpufreq: exynos: remove Exynos4210 specific cpufreq driver support

2014-01-09 Thread Thomas Abraham 
The Exynos4210 specific cpufreq driver performs read/write operations
of clock controller registers bypassing the Exynos common clock
framework driver. This could lead to potential issues if CCF and
cpufreq driver modify the clock registers independently of each other.
In addition to this, the generic cpufreq-cpu0 driver is sufficient
for Exynos4210 based platforms since this SoC uses a single clock
and voltage line for both the ARM cores. So remove the support for
Exynos4210 specific cpufreq driver and use cpufreq-cpu0 driver
for Exynos4210 platforms

Signed-off-by: Thomas Abraham thomas...@samsung.com
---
 drivers/cpufreq/Kconfig.arm  |   11 ---
 drivers/cpufreq/Makefile |1 -
 drivers/cpufreq/exynos-cpufreq.c |4 +-
 drivers/cpufreq/exynos-cpufreq.h |8 --
 drivers/cpufreq/exynos4210-cpufreq.c |  157 --
 5 files changed, 1 insertions(+), 180 deletions(-)
 delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0468ad1..0a2a589 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -19,17 +19,6 @@ config ARM_DT_BL_CPUFREQ
 config ARM_EXYNOS_CPUFREQ
bool
 
-config ARM_EXYNOS4210_CPUFREQ
-   bool SAMSUNG EXYNOS4210
-   depends on CPU_EXYNOS4210
-   default y
-   select ARM_EXYNOS_CPUFREQ
-   help
- This adds the CPUFreq driver for Samsung EXYNOS4210
- SoC (S5PV310 or S5PC210).
-
- If in doubt, say N.
-
 config ARM_EXYNOS4X12_CPUFREQ
bool SAMSUNG EXYNOS4x12
depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412)
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7494565..ce2abf9 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -50,7 +50,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)   += 
arm_big_little_dt.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)   += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 4ee3804..eacc7eb 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -237,9 +237,7 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
if (!exynos_info)
return -ENOMEM;
 
-   if (soc_is_exynos4210())
-   ret = exynos4210_cpufreq_init(exynos_info);
-   else if (soc_is_exynos4212() || soc_is_exynos4412())
+   if (soc_is_exynos4212() || soc_is_exynos4412())
ret = exynos4x12_cpufreq_init(exynos_info);
else if (soc_is_exynos5250())
ret = exynos5250_cpufreq_init(exynos_info);
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 3ddade8..1e0afbe 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -43,14 +43,6 @@ struct exynos_dvfs_info {
bool (*need_apll_change)(unsigned int, unsigned int);
 };
 
-#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
-extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
-#else
-static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
-{
-   return -EOPNOTSUPP;
-}
-#endif
 #ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
 extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
 #else
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c 
b/drivers/cpufreq/exynos4210-cpufreq.c
deleted file mode 100644
index 40d84c4..000
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ /dev/null
@@ -1,157 +0,0 @@
-/*
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4210 - CPU frequency scaling support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include linux/module.h
-#include linux/kernel.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/slab.h
-#include linux/cpufreq.h
-
-#include exynos-cpufreq.h
-
-static struct clk *cpu_clk;
-static struct clk *moutcore;
-static struct clk *mout_mpll;
-static struct clk *mout_apll;
-
-static unsigned int exynos4210_volt_table[] = {
-   125, 115, 105, 975000, 95,
-};
-
-static struct cpufreq_frequency_table exynos4210_freq_table[] = {
-   {L0, 1200 * 1000},
-   {L1, 1000 * 1000},
-   {L2,  800 * 1000},
-   {L3,  500 * 1000},
-   {L4,  200 * 1000},
-   {0, CPUFREQ_TABLE_END},
-};
-
-static struct apll_freq apll_freq_4210[] = {
-   /*
-* values:
-*

Re: [GIT PULL] Samsung Clock changes for v3.14

2014-01-09 Thread Tomasz Figa 
On Wednesday 08 of January 2014 16:49:56 Mike Turquette wrote:
 Quoting Mike Turquette (2014-01-08 14:59:43)
  Quoting Tomasz Figa (2014-01-08 14:43:24)
   On Wednesday 08 of January 2014 14:07:49 Mike Turquette wrote:
Quoting Tomasz Figa (2014-01-08 11:13:38)
 Hi Mike,
 
 Please consider pulling following Samsung Clock changes for v3.14.
 
 The following changes since commit 
 2bb00c68e094271b79deac993893461cc051b721:

Hi Tomasz,

Commit 2bb00c68 is the tip of the Samsung clk fixes that I'm about to
send out. Can you rebase this request onto the tip of clk-next?
   
   I guess I can do it, but wouldn't this introduce merge conflicts, since
   some of the fixes are changing the same parts of the code?
  
  Yes it will cause conflicts, but that is sometimes OK.
  
   
   I based my samsung-next branch on top of your clk-next with my fixes
   branch merged, since that's what will end up in Linus' tree anyway. Was it
   not the right thing to do?
  
  Well maybe I am missing something, but I think it is not the best thing.
  The problem is that those patches will sort of be merged twice. Again
  maybe I am missing something. The same commit IDs will be used so
  perhaps it is OK...
  
  Part of this trouble is caused by the simple way that I fork clk-next
  from v3.xx-rc1. Since I never rebase that branch to a more recent -rc
  then there is a delta between the fixes that go in the queue of patches
  for the next merge window.
  
  I guess one way that other subsystems handle this is by having something
  like clk-next-late which is a new branch based on a later -rc.
  
  How awful is the merge conflict resolution?
 
 Thanks for working this out on IRC. I've taken this pull request into
 clk-next for 3.14.

Great, thanks.

One more thing. Could you update your public tree to let patches get some
wider testing in linux-next before the merge window?

Best regards,
Tomasz

--
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] clocksource: exynos_mct: remove unwanted header file inclusion

2014-01-09 Thread Pankaj Dubey 
remove unwanted header file inclusion asm/mach/time.h from exynos_mct.c

Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
 drivers/clocksource/exynos_mct.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 48f76bc..ed49b25 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -25,8 +25,6 @@
 #include linux/of_address.h
 #include linux/clocksource.h
 
-#include asm/mach/time.h
-
 #define EXYNOS4_MCTREG(x)  (x)
 #define EXYNOS4_MCT_G_CNT_LEXYNOS4_MCTREG(0x100)
 #define EXYNOS4_MCT_G_CNT_UEXYNOS4_MCTREG(0x104)
-- 
1.7.10.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

[PATCH 1/3] irqchip: exynos-combiner: call handle_bad_irq directly

2014-01-09 Thread Pankaj Dubey 
This patch is inspired from following commit
 aec0095653: (irqchip: gic: Call handle_bad_irq() directly)

Also this will help in removing unwanted inclusion
of header file asm/mach/irq.h

Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
 drivers/irqchip/exynos-combiner.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c 
b/drivers/irqchip/exynos-combiner.c
index 40e6440..f8636a6 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -17,7 +17,6 @@
 #include linux/irqchip/chained_irq.h
 #include linux/of_address.h
 #include linux/of_irq.h
-#include asm/mach/irq.h
 
 #include irqchip.h
 
@@ -81,7 +80,7 @@ static void combiner_handle_cascade_irq(unsigned int irq, 
struct irq_desc *desc)
cascade_irq = irq_find_mapping(combiner_irq_domain, combiner_irq);
 
if (unlikely(!cascade_irq))
-   do_bad_IRQ(irq, desc);
+   handle_bad_irq(irq, desc);
else
generic_handle_irq(cascade_irq);
 
-- 
1.7.10.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/3] irqchip: exynos-combiner: call handle_bad_irq directly

2014-01-09 Thread Pankaj Dubey 

On 01/10/2014 11:32 AM, Pankaj Dubey wrote:

This patch is inspired from following commit
  aec0095653: (irqchip: gic: Call handle_bad_irq() directly)

Also this will help in removing unwanted inclusion
of header file asm/mach/irq.h

Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com

This is single patch only. By mistake sent as Patch[1/3].

---
  drivers/irqchip/exynos-combiner.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c 
b/drivers/irqchip/exynos-combiner.c
index 40e6440..f8636a6 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -17,7 +17,6 @@
  #include linux/irqchip/chained_irq.h
  #include linux/of_address.h
  #include linux/of_irq.h
-#include asm/mach/irq.h
  
  #include irqchip.h
  
@@ -81,7 +80,7 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)

cascade_irq = irq_find_mapping(combiner_irq_domain, combiner_irq);
  
  	if (unlikely(!cascade_irq))

-   do_bad_IRQ(irq, desc);
+   handle_bad_irq(irq, desc);
else
generic_handle_irq(cascade_irq);
  


--
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 1/1] drivers: net: silence compiler warning in smc91x.c

2014-01-09 Thread Pankaj Dubey 
If used 64 bit compiler GCC warns that:

drivers/net/ethernet/smsc/smc91x.c:1897:7:
warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]

This patch fixes this by changing typecase from unsigned int to unsigned 
long

CC: David S. Miller da...@davemloft.net
CC: Jingoo Han jg1@samsung.com 
CC: net...@vger.kernel.org
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
 drivers/net/ethernet/smsc/smc91x.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/smsc/smc91x.c 
b/drivers/net/ethernet/smsc/smc91x.c
index 0c9b5d9..42e79b4 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -1894,7 +1894,7 @@ static int smc_probe(struct net_device *dev, void __iomem 
*ioaddr,
SMC_SELECT_BANK(lp, 1);
val = SMC_GET_BASE(lp);
val = ((val  0x1F00)  3)  SMC_IO_SHIFT;
-   if (((unsigned int)ioaddr  (0x3e0  SMC_IO_SHIFT)) != val) {
+   if (((unsigned long)ioaddr  (0x3e0  SMC_IO_SHIFT)) != val) {
netdev_warn(dev, %s: IOADDR %p doesn't match configuration 
(%x).\n,
CARDNAME, ioaddr, val);
}
-- 
1.7.10.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

[PATCH 1/1] drivers: i2c: silence a compile warning in i2c-s3c2410.c

2014-01-09 Thread Pankaj Dubey 
If used 64 bit compiler GCC warns that:

drivers/i2c/busses/i2c-s3c2410.c: In function ‘s3c24xx_get_device_quirks’:
drivers/i2c/busses/i2c-s3c2410.c:168:10: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]

This patch fixes this by converting unsigned int to unsigned long.

CC: Kukjin Kim kgene@samsung.com
CC: Wolfram Sang w...@the-dreams.de
CC: linux-...@vger.kernel.org
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
 drivers/i2c/busses/i2c-s3c2410.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index bf8fb94..447dd98 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -101,7 +101,7 @@ enum s3c24xx_i2c_state {
 
 struct s3c24xx_i2c {
wait_queue_head_t   wait;
-   unsigned intquirks;
+   unsigned longquirks;
unsigned intsuspended:1;
 
struct i2c_msg  *msg;
@@ -160,12 +160,13 @@ MODULE_DEVICE_TABLE(of, s3c24xx_i2c_match);
  * Get controller type either from device tree or platform device variant.
 */
 
-static inline unsigned int s3c24xx_get_device_quirks(struct platform_device 
*pdev)
+static inline unsigned long
+   s3c24xx_get_device_quirks(struct platform_device *pdev)
 {
if (pdev-dev.of_node) {
const struct of_device_id *match;
match = of_match_node(s3c24xx_i2c_match, pdev-dev.of_node);
-   return (unsigned int)match-data;
+   return (unsigned long)match-data;
}
 
return platform_get_device_id(pdev)-driver_data;
-- 
1.7.10.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 2/6 v2] crypto:s5p-sss: Add device tree support

2014-01-09 Thread Naveen Krishna Ch 
Hello Tomasz,

Thanks for time and review comments they are really helping me a lot
in getting the patches merged.

Secondly, accept my apologies for not giving proper writeup of why i
din't address
few of your comments on v1 of this patchset.

On 9 January 2014 19:44, Tomasz Figa t.f...@samsung.com wrote:
 Hi Naveen,


 On 09.01.2014 05:59, Naveen Krishna Chatradhi wrote:

 This patch adds device tree support to the s5p-sss.c crypto driver.
 Implements a varient struct to address the changes in SSS hardware
 on various SoCs from Samsung.

 Also, Documentation under devicetree/bindings added.

 Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
 CC: Herbert Xu herb...@gondor.apana.org.au
 CC: David S. Miller da...@davemloft.net
 CC: Vladimir Zapolskiy vzapols...@gmail.com
 TO: linux-cry...@vger.kernel.org
 CC: linux-samsung-soc@vger.kernel.org
 ---
 Changes since v1:
 1. Added description of the SSS module in Documentation
 2. Corrected the interrupts description
 3. Added varient struct instead of the version variable

   .../devicetree/bindings/crypto/samsung-sss.txt |   20 +
   drivers/crypto/s5p-sss.c   |   81
 ++--
   2 files changed, 95 insertions(+), 6 deletions(-)
   create mode 100644
 Documentation/devicetree/bindings/crypto/samsung-sss.txt

 diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
 b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
 new file mode 100644
 index 000..0e45b0d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
 @@ -0,0 +1,20 @@
 +Samsung SoC SSS (Security SubSystem) module
 +
 +The SSS module in S5PV210 SoC supports the following:
 +-- Feeder (FeedCtrl)
 +-- Advanced Encryption Standard (AES)
 +-- Data Encryption Standard (DES)/3DES
 +-- Public Key Accelerator (PKA)
 +-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
 +-- PRNG: Pseudo Random Number Generator
 +
 +Required properties:
 +
 +- compatible : Should contain entries for this and backward compatible
 +  SSS versions:
 +  - samsung,s5p-secss for S5PV210 SoC.


 As I wrote in my previous reply, please use specific compatible string
 containing name of SoC on which the block described by it appeared first.
 Let me say it again, for security block that showed up first on S5PV210 the
 string will be samsung,s5pv210-secss.
1. .name   = s5p-secss, is the name used in the present driver.
So, i dint modify that.
2. I'm not sure which one is the first soc to have the new varient.
May be Exynos4210. Will modify in the next version.



 +- reg : Offset and length of the register set for the module
 +- interrupts : the interrupt-specifier for the SSS module.
 +   Two interrupts feed control and hash in case of S5PV210
 +- clocks : the required gating clock for the SSS module.
 +- clock-names : the gating clock name to be requested in the SSS driver.
 diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
 index 93cddeb..78e0c37 100644
 --- a/drivers/crypto/s5p-sss.c
 +++ b/drivers/crypto/s5p-sss.c
 @@ -22,6 +22,7 @@
   #include linux/scatterlist.h
   #include linux/dma-mapping.h
   #include linux/io.h
 +#include linux/of.h
   #include linux/crypto.h
   #include linux/interrupt.h

 @@ -145,6 +146,20 @@
   #define AES_KEY_LEN 16
   #define CRYPTO_QUEUE_LEN1

 +/**
 + * struct samsung_aes_varient - platform specific SSS driver data


 typo: s/varient/variant/g

 Anyway, I think this should be moved to the patch adding support for
 Exynos5, as before it there is no use for this struct and it's not directly
 related to DT support.


 + * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
 + * @aes_offset: AES register offset from SSS module's base.
 + *
 + * Specifies platform specific configuration of SSS module.
 + * Note: A structure for driver specific platform data is used for future
 + * expansion of its usage.
 + */
 +struct samsung_aes_varient {
 +   boolhas_hash_irq;
 +   unsigned intaes_offset;
 +};
 +
   struct s5p_aes_reqctx {
 unsigned long mode;
   };
 @@ -173,10 +188,56 @@ struct s5p_aes_dev {
 struct crypto_queue queue;
 boolbusy;
 spinlock_t  lock;
 +
 +   struct samsung_aes_varient *varient;
   };

   static struct s5p_aes_dev *s5p_dev;

 +static struct samsung_aes_varient s5p_aes_data = {


 Remember to mark constant data as const.


 +   .has_hash_irq   = true,
 +   .aes_offset = 0x4000,
 +};
 +
 +static const struct platform_device_id s5p_sss_ids[] = {
 +   {
 +   .name   = s5p-secss,
 +   .driver_data= (kernel_ulong_t)s5p_aes_data,
 +   },
 +   { },
 +};
 +MODULE_DEVICE_TABLE(platform, s5p_sss_ids);
 +
 +#ifdef CONFIG_OF
 +static const struct of_device_id s5p_sss_dt_match[] = {
 +   {
 +   .compatible = samsung,s5p-secss,
 +

Re: [PATCH 2/6 v2] crypto:s5p-sss: Add device tree support

2014-01-09 Thread Sachin Kamat 
Hi Naveen,

On 10 January 2014 11:37, Naveen Krishna Ch naveenkrishna...@gmail.com wrote:
 Hello Tomasz,


[snip]
 *pdev)
   static struct platform_driver s5p_aes_crypto = {
 .probe  = s5p_aes_probe,
 .remove = s5p_aes_remove,
 +   .id_table   = s5p_sss_ids,
 .driver = {
 .owner  = THIS_MODULE,
 .name   = s5p-secss,
 +   .of_match_table = s5p_sss_dt_match,


 .of_match_table = of_match_ptr(s5p_sss_dt_match),
 I dint use it, Some time back there was a patchset from Sachin
 https://lkml.org/lkml/2013/9/28/61
 Please suggest me on this.

In those cases the structure was always compiled in. i.e., it was not protected
by #ifdef CONFIG_OF. Hence use of of_match_ptr was not required. of_match_ptr
abstracts this check depending on OF is enabled or not. In the case of
this (sss) driver,
since you are using CONFIG_OF to selectively compile out the code (and esp.
s5p_sss_dt_match structure), use of of_match_ptr will make the code
simpler as it
avoids the use of a dummy structure definition (the #else part of the
struct definition) when OF is
disabled. Hope this clarifies.

-- 
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 v12 0/7] cpufreq:boost: CPU Boost mode support

2014-01-09 Thread Zhang Rui 
On Wed, 2014-01-08 at 01:35 +0100, Rafael J. Wysocki wrote:
 On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote:
  Hi Rafael,
 
 Hi,
 
   This patch series introduces support for CPU overclocking technique
   called Boost.
   
   It is a follow up of a LAB governor proposal. Boost is a LAB
   component:
   http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
   
   Boost unifies hardware based solution (e.g. Intel Nehalem) with
   software oriented one (like the one done at Exynos).
   For this reason cpufreq/freq_table code has been reorganized to
   include common code.
   
   Important design decisions:
   - Boost related code is compiled-in unconditionally to cpufreq core
   and disabled by default. The cpufreq_driver is responsibile for
   setting boost_supported flag and providing set_boost callback(if HW
   support is needed). For software managed boost, special Kconfig flag -
 CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only
 when a target platform has thermal framework properly configured.
   
   - struct cpufreq_driver has been extended with boost related fields:
   -- boost_supported - when driver supports boosting
   -- boost_enabled - boost state
   -- set_boost - callback to function, which is necessary to
  enable/disable boost
   
   - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is
   visible _only_ when cpufreq driver supports Boost.
   
   - No special spin_lock for Boost was created. The one from cpufreq
   core was reused.
   
   - The Boost code doesn't rely on any policy. When boost state is
   changed, then the policy list is iterated and proper adjustements are
   done.
   
   - To improve safety level, the thermal framework is also extended to
   disable software boosting, when thermal trip point is reached. After
   cooling down the boost can be enabled again. This emulates behaviour
   similar to HW managed boost (like x86)
   
   Tested at HW:
  Exynos 4412 3.13-rc4 Linux
  Intel Core i7-3770 3.13-rc4 Linux
   
   Above patches were posted on top of kernel_pm/bleeding-edge
   (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149)
   
   Lukasz Majewski (7):
 cpufreq: Add boost frequency support in core
 cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common
   boost solution
 cpufreq:boost:Kconfig: Provide support for software managed BOOST
 cpufreq:exynos:Extend Exynos cpufreq driver to support boost
   framework
 Documentation:cpufreq:boost: Update BOOST documentation
 cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ
 thermal:exynos:boost: Automatic enable/disable of BOOST feature (at
   Exynos4412)
   
Documentation/cpu-freq/boost.txt  |   26 +++
drivers/cpufreq/Kconfig   |4 +
drivers/cpufreq/Kconfig.arm   |   15 
drivers/cpufreq/acpi-cpufreq.c|   86
   +++-- drivers/cpufreq/cpufreq.c |
   118 -
   drivers/cpufreq/exynos-cpufreq.c  |3 +
   drivers/cpufreq/exynos4x12-cpufreq.c  |2 +-
   drivers/cpufreq/freq_table.c  |   56 --
   drivers/thermal/samsung/exynos_tmu_data.c |   12 +--
   include/linux/cpufreq.h   |   24 ++ 10 files
   changed, 261 insertions(+), 85 deletions(-)
   
  
  A gentle ping about BOOST patches.
  
  Its been already acked by Viresh and Eduardo.
  
  It applies on kernel_pm/bleeding_edge SHA1:
  4836deb72c5e2a9af0cb2129c1149783a26d99ab
 
 It looks like Rui is still looking into this.
 
 Rui, are you fine with this series?
 
Yes, I'm okay with the thermal related parts of this patch set.

thanks,
rui
 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 v12 7/7] thermal:exynos:boost: Automatic enable/disable of BOOST feature (at Exynos4412)

2014-01-09 Thread Zhang Rui 
On Fri, 2013-12-20 at 15:24 +0100, Lukasz Majewski wrote:
 This patch provides auto disable/enable operation for boost. It uses already
 present thermal infrastructure to provide BOOST hysteresis.
 The TMU data has been modified to work properly with or without BOOST.
 Hence, the two first trip points with corresponding clip frequencies were
 adjusted.
 
 The first one was reduced from 85 to 70 degrees and clip frequency was
 increased to 1.4 GHz from 800 MHz. This trip point is in fact responsible
 for providing BOOST hysteresis. When temperature exceeds 70 deg, the maximal
 non BOOST frequency for Exynos4412 is imposed.
 
 Since the first trigger level has been stolen for BOOST, the second one
 needs to be a compromise for the previously used two for non BOOST
 configuration. The 95 deg with modified clip freq (to 400 MHz) shall provide
 a good balance between cooling down the overheated device and throughput on
 an acceptable level.
 
 Two last trigger levels were not modified since, they cause platform shutdown
 on emergency overheat situation.
 Third trip point passage results in SW managed shut down of the system.
 If the last trip point is crossed, the PMU HW generates the power off
 signal.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Myungjoo Ham myungjoo@samsung.com
 Acked-by: Eduardo Valentin eduardo.valen...@ti.com

Reviewed-by: Zhang Rui rui.zh...@intel.com

thanks,
rui
 
 ---
 Changes for v12:
 - More verbose patch description to explain new TMU temperature assignment
   for Exynos4412
 
 Changes for v11:
 - Use only one thermal data set
 - Adjust Exynos4412 thermal data to work with or without BOOST
 
 Changes for v10:
 - Remove boost related code from thermal_core.c
 - Use already present thermal infrastructure to provide thermal hysteresis
 - Introduce special set of TMU data for BOOST
 
 Changes for v9:
 - None
 
 Changes for v8:
 - Move cpufreq_boost_* stub functions definition (needed when cpufreq
   is not compiled in) to cpufreq.h at cpufreq core support commit
 
 Changes for v7:
 - None
 
 Changes for v6:
 - Disable boost only when supported and enabled
 - Protect boost related thermal_zone_device struct fields with mutex
 - Evaluate temperature trend during boost enable decision
 - Create separate methods to handle boost enable/disable
   (thermal_boost_{enable|disable}) operations
 - Boost is disabled at any trip point passage (not only the non critical 
 one)
 - Add stub definitions for cpufreq boost functions used when
   CONFIG_CPU_FREQ is NOT defined.
 
 Changes for v5:
 - Move boost disable code from cpu_cooling.c to thermal_core.c
   (to handle_non_critical_trips)
 - Extent struct thermal_zone_device by adding overheated bool flag
 - Implement auto enable of boost after device cools down
 - Introduce boost_polling flag, which indicates if thermal uses it's 
 predefined
   pool delay or has woken up thermal workqueue only to wait until device
   cools down.
 
 Changes for v4:
 - New patch
 
  drivers/thermal/samsung/exynos_tmu_data.c |   12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
 b/drivers/thermal/samsung/exynos_tmu_data.c
 index 073c292..476b768 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.c
 +++ b/drivers/thermal/samsung/exynos_tmu_data.c
 @@ -131,8 +131,8 @@ static const struct exynos_tmu_registers 
 exynos4412_tmu_registers = {
  
  #define EXYNOS4412_TMU_DATA \
   .threshold_falling = 10, \
 - .trigger_levels[0] = 85, \
 - .trigger_levels[1] = 103, \
 + .trigger_levels[0] = 70, \
 + .trigger_levels[1] = 95, \
   .trigger_levels[2] = 110, \
   .trigger_levels[3] = 120, \
   .trigger_enable[0] = true, \
 @@ -155,12 +155,12 @@ static const struct exynos_tmu_registers 
 exynos4412_tmu_registers = {
   .second_point_trim = 85, \
   .default_temp_offset = 50, \
   .freq_tab[0] = { \
 - .freq_clip_max = 800 * 1000, \
 - .temp_level = 85, \
 + .freq_clip_max = 1400 * 1000, \
 + .temp_level = 70, \
   }, \
   .freq_tab[1] = { \
 - .freq_clip_max = 200 * 1000, \
 - .temp_level = 103, \
 + .freq_clip_max = 400 * 1000, \
 + .temp_level = 95, \
   }, \
   .freq_tab_count = 2, \
   .registers = exynos4412_tmu_registers, \


--
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 V12 2/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register

2014-01-09 Thread Wim Van Sebroeck 
Hi Leela

 Add device tree support for exynos5250 and 5420 SoCs and use syscon regmap 
 interface
 to configure AUTOMATIC_WDT_RESET_DISABLE and MASK_WDT_RESET_REQUEST registers 
 of PMU
 to mask/unmask enable/disable of watchdog in probe and s2r scenarios.
 
 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 Signed-off-by: Doug Anderson diand...@chromium.org

This patch has been added to linux-watchdog-next.

Kind regards,
Wim.

--
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 V12 1/3] ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files

2014-01-09 Thread Wim Van Sebroeck 
Hi Leela,

 This patch adds pmusysreg node to exynos5250 and exynos5420 dtsi files to
 handle PMU register accesses in a centralized way using syscon driver
 
 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 Reviewed-by: Doug Anderson diand...@chromium.org
 Tested-by: Doug Anderson diand...@chromium.org
 ---
...
 diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
 b/arch/arm/boot/dts/exynos5420.dtsi
 index b1fa334..cd47db0 100644
 --- a/arch/arm/boot/dts/exynos5420.dtsi
 +++ b/arch/arm/boot/dts/exynos5420.dtsi
 @@ -402,4 +402,9 @@
   clock-names = gscl;
   samsung,power-domain = gsc_pd;
   };

I can't add this patch since there is no gscl in the current linux-tree.
Is this depending on another patch or are we going to fix this in another way?

Kind regards,
Wim.

--
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: Re: [PATCH V12 1/3] ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files

2014-01-09 Thread Leela Krishna Amudala 
Hi Wim,
I rebased this patch series on Kukjin's for-next branch.
That is the reason for missing this context code in the patch.

As this is a dts file change and if Kukjin accepts to merge this patch
into your linux-watchdog-next tree you can rebase and apply it.

Best Wishes,
Leela Krishna.

--- Original Message ---
Sender : Wim Van Sebroeckw...@iguana.be
Date : Jan 10, 2014 13:11 (GMT+05:30)
Title : Re: [PATCH V12 1/3] ARM: dts: Add pmu sysreg node to exynos5250 and 
exynos5420 dtsi files

Hi Leela,

 This patch adds pmusysreg node to exynos5250 and exynos5420 dtsi files to
 handle PMU register accesses in a centralized way using syscon driver
 
 Signed-off-by: Leela Krishna Amudala 
 Reviewed-by: Tomasz Figa 
 Reviewed-by: Doug Anderson 
 Tested-by: Doug Anderson 
 ---
...
 diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
 b/arch/arm/boot/dts/exynos5420.dtsi
 index b1fa334..cd47db0 100644
 --- a/arch/arm/boot/dts/exynos5420.dtsi
 +++ b/arch/arm/boot/dts/exynos5420.dtsi
 @@ -402,4 +402,9 @@
   clock-names = gscl;
   samsung,power-domain = gsc_pd;
   };

I can't add this patch since there is no gscl in the current linux-tree.
Is this depending on another patch or are we going to fix this in another way?

Kind regards,
Wim.





Best Wishes,
Leela Krishna.