Re: [PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

2014-04-24 Thread Thierry Reding
On Thu, Apr 24, 2014 at 12:56:02AM +0530, Ajay kumar wrote:
 Thierry,
 
 On Wed, Apr 23, 2014 at 1:12 PM, Thierry Reding
 thierry.red...@gmail.com wrote:
  On Wed, Apr 23, 2014 at 09:29:15AM +0200, Daniel Vetter wrote:
[...]
  Imo this makes sense, especially if we go through with the idea talked
  about yesterday of creating a drm_bridge to wrap-up a drm_panel with
  sufficient isolation between all components.
 
  I'm not at all comfortable with these. The names are totally confusing.
  Next somebody will need to do something after the panel has been enabled
  and we'll have to introduce .post_enable() and .pre_disable() functions.
  And worse, what if somebody needs something to be done between
  .pre_enable() and .enable()? .post_pre_enable()? Where does it end?
 
  According to the above description the only reason why we need this is
  to avoid visible glitches when the panel is already on, but the video
  stream hasn't started yet. If that's the only reason why we need this,
  then perhaps adding a way for a panel to expose the associated backlight
  would be better?
 Actually, we need not expose the entire backlight device.
 AFAIK, the glitch is caused when you enable BL_EN before
 there is valid video data. So, one way to mask off the glitch is to
 follow this sequence:
 -- power up the panel.
 -- start video data, (start PWM here or)
 -- (start PWM here), enable backlight

That's very difficult to get right, isn't it? Even if you have fine-
grained control over what to enable you still need a way to determine
_when_ it's safe to enable the backlight. Typically I guess that would
be the duration of one frame (or perhaps 2, depending on when the panel
syncs to the video signal).

Perhaps it could even by sync'ed to the VBLANK?

 The problem is that the above scenario cannot be mapped to panel-simple 
 driver.
 IMO, panel_simple should provide enable/disable controls both for LCD
 and backlight.
 something like panel_simple_lcd_enable/panel_simple_led_enable, and
 panel_simple_lcd_disable/panel_simple_led_disable.

That's not what the simple panel driver can do. If we want this it needs
to be solved in a generic way for all panels since they all need to use
the drm_panel_*() functions to abstract away the details from drivers
that use the panels.

Thierry


pgpCcImfBpebT.pgp
Description: PGP signature


Re: [PATCH v2] ARM: dts: Add peach-pit board support

2014-04-24 Thread Doug Anderson
Arun,

On Wed, Apr 23, 2014 at 9:17 PM, Arun Kumar K arun...@samsung.com wrote:
 Adds the google peach-pit board dts file which uses
 exynos5420 SoC.

 Signed-off-by: Arun Kumar K arun...@samsung.com
 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
 Changes from v1
 ---
 - Addressed review comments from Doug, Sachin  Tushar
 - Removed adc and lid-switch nodes
 ---
  arch/arm/boot/dts/Makefile |1 +
  arch/arm/boot/dts/exynos5420-peach-pit.dts |  182 
 
  2 files changed, 183 insertions(+)
 +   spi@12d3 {
 +   status = okay;
 +   samsung,spi-src-clk = 0;
 +   num-cs = 1;
 +
 +   spidev@0 {
 +   compatible = spidev;
 +   reg = 0;
 +   spi-max-frequency = 5000;
 +   pinctrl-names = default;
 +   pinctrl-0 = spi_flash_cs;
 +
 +   controller-data {
 +   cs-gpio = gpa2 5 0;

Technically this could be

cs-gpio = gpa2 5 GPIO_ACTIVE_HIGH;

...but I don't think that's a huge deal...

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 v8 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC

2014-04-24 Thread Rahul Sharma
Hi Kukjin,

Need this macro to enable build for clock driver.

Regards,
Rahul Sharma.


On 22 April 2014 15:36, Kukjin Kim kgene@samsung.com wrote:
 Tomasz Figa wrote:

 On 16.04.2014 10:08, Sachin Kamat wrote:
  Hi Tomasz,
 
  On 16 April 2014 13:27, Tomasz Figa tomasz.f...@gmail.com wrote:
  Hi Rahul,
 
 
  On 16.04.2014 05:58, Rahul Sharma wrote:
 
  From: Pankaj Dubey pankaj.du...@samsung.com
 
  This patch add basic arch side support for exynos5260 SoC.
 
  Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
  Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
  Reviewed-by: Tomasz Figa t.f...@samsung.com
  ---
 arch/arm/mach-exynos/Kconfig |5 +
 1 file changed, 5 insertions(+)
 
  diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-
 exynos/Kconfig
  index fc8bf18..bf4ed87 100644
  --- a/arch/arm/mach-exynos/Kconfig
  +++ b/arch/arm/mach-exynos/Kconfig
  @@ -84,6 +84,11 @@ config SOC_EXYNOS5250
   help
 Enable EXYNOS5250 SoC support
 
  +config SOC_EXYNOS5260
  +   bool SAMSUNG EXYNOS5260
  +   default y
  +   depends on ARCH_EXYNOS5
  +
 config SOC_EXYNOS5420
   bool SAMSUNG EXYNOS5420
   default y
 
 
  Is this patch necessary now? After Sachin's consolidation series there
 are
  no per SoC entries anymore.
 
  Kukjin still wanted individual SoCs to be selectable. Please refer [1].
 
  [1] http://www.spinics.net/lists/devicetree/msg27040.html

 I don't think any valid reason was presented there. Features in code
 should not be selected using #ifdef CONFIG_ anymore, so I don't really
 see any reason to not proceed with this consolidation. Olof, Arnd?

 Hi,

 Yeah, in this case, nothing happened with adding SOC_EXYNOS5260. So I don't 
 have any idea why this is required.

 - Kukjin

--
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


[PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Chanwoo Choi
This patch fix the offset of CPU boot address and don't need to send smc call
of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
WFE in secure mode.

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/firmware.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..386d01d 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -31,11 +31,17 @@ static int exynos_do_idle(void)
 static int exynos_cpu_boot(int cpu)
 {
/*
+* Exynos3250 doesn't need to send smc command for secondary CPU boot
+* because Exynos3250 removes WFE in secure mode.
+*/
+   if (soc_is_exynos3250())
+   return 0;
+   /*
 * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
 * But, Exynos4212 has only one secondary CPU so second parameter
 * isn't used for informing secure firmware about CPU id.
 */
-   if (soc_is_exynos4212())
+   else if (soc_is_exynos4212())
cpu = 0;
 
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
@@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
boot_addr)
 {
void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
 
-   if (!soc_is_exynos4212())
+   if (!soc_is_exynos4212()  !soc_is_exynos3250())
boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
-- 
1.8.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


[PATCHv4 0/7] Support new Exynos3250 SoC based on Cortex-A7 dual core

2014-04-24 Thread Chanwoo Choi
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core.
Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor
for Smartphone. It is desigend with the 28nm low-power high-K metal gate process
and provides the best performance features.

This patchset include some patches such as:
- Support booting of Exynos3250
- Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba
- Support the clock control for Exynos3250 using common clk framework

[Pinctrl patch for Exynos3250]
The pinctrl patch for Exynos3250 has been merged in pinctrl.git of Linus Walleij
- [1] https://lkml.org/lkml/2014/4/23/72

This patchset is based on following git repo/branch.
- git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
- branch   : for-next (Linux 3.15-rc1)

Changes from v3:
- Remove all dependency about following patchset to remove static memory
  mapping for SYSRAM[1] / PMU ([2] or [3]). If following patchset merged,
  I'll send a further patches to support SYSRAM/PMU for secondary CPU.
 [1] http://www.spinics.net/lists/arm-kernel/msg323011.html
 [2] https://lkml.org/lkml/2014/4/2/48
 [3] http://www.spinics.net/lists/arm-kernel/msg316013.html

Changes from v2:
- Remove static memory mapping about SYSRAM/PMU such as following patches:
  ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
  ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
- Add description for secondary CPU boot of Exynos4212/Exynos3250
- Fix description in exynos_cpu_die() to remove particular SoC series
- Fix minor coding style
- Add documentation for Exynos3250 clock controller

Changes from v1:
- Add new samsung,exynos3 compatible name
- Add comment about exynos_cpu_boot in Exynos4212
- Remove unnecessary 'goto' statement in firmware.c
- Use read_cpuid_part_number() function instead of assembler directly
- Post separated pinctrl patch from this patchset
  : https://lkml.org/lkml/2014/4/13/156
- Remove unused pmu interrupts due to Exynos3250 dual-core
- Cosolidate all the patches related to exynos3250.dtsi into one patch
- Fix gic compatible name to cortex-a15-gic because Cortex-A7 GIC is same
- Add sign-off of sender to all this patches
- Fix minor typo

Chanwoo Choi (4):
  ARM: EXYNOS: Add Exynos3250 SoC ID
  ARM: EXYNOS: Support secondary CPU boot of Exynos3250
  ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
  dt-bindings: add documentation for Exynos3250 clock controller

Kyungmin Park (1):
  ARM: EXYNOS: Support secondary CPU boot of Exynos4212

Tomasz Figa (2):
  clk: samsung: exynos3250: Add clocks using common clock framework
  ARM: dts: Add device tree sources for Exynos3250

 .../devicetree/bindings/clock/exynos3250-clock.txt |  41 +
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi  | 477 +++
 arch/arm/boot/dts/exynos3250.dtsi  | 405 +
 arch/arm/boot/dts/exynos4212-tizenw.dts| 926 +
 arch/arm/mach-exynos/Kconfig   |  22 +
 arch/arm/mach-exynos/exynos.c  |   2 +
 arch/arm/mach-exynos/firmware.c|  21 +-
 arch/arm/mach-exynos/hotplug.c |  19 +-
 arch/arm/plat-samsung/include/plat/cpu.h   |  10 +
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 ++
 12 files changed, 2957 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
 create mode 100644 arch/arm/boot/dts/exynos4212-tizenw.dts
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

-- 
1.8.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


[PATCHv4 2/7] ARM: EXYNOS: Support secondary CPU boot of Exynos4212

2014-04-24 Thread Chanwoo Choi
From: Kyungmin Park kyungmin.p...@samsung.com

This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.

Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
 arch/arm/mach-exynos/firmware.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
 
 #include mach/map.h
 
+#include plat/cpu.h
+
 #include smc.h
 
 static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
 
 static int exynos_cpu_boot(int cpu)
 {
+   /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+   if (soc_is_exynos4212())
+   cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
 }
 
 static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
 {
-   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+   if (!soc_is_exynos4212())
+   boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
return 0;
-- 
1.8.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


[PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250

2014-04-24 Thread Chanwoo Choi
From: Tomasz Figa t.f...@samsung.com

This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:

- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus

Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Russell King li...@arm.linux.org.uk
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++
 arch/arm/boot/dts/exynos3250.dtsi | 405 +
 arch/arm/boot/dts/exynos4212-tizenw.dts   | 926 ++
 3 files changed, 1808 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
 create mode 100644 arch/arm/boot/dts/exynos4212-tizenw.dts

diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as 
device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+   pinctrl@1140 {
+   gpa0: gpa0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpa1: gpa1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpb: gpb {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpc0: gpc0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpc1: gpc1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd0: gpd0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd1: gpd1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   uart0_data: uart0-data {
+   samsung,pins = gpa0-0, gpa0-1;
+   samsung,pin-function = 0x2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   uart0_fctl: uart0-fctl {
+   samsung,pins = gpa0-2, gpa0-3;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   uart1_data: uart1-data {
+   samsung,pins = gpa0-4, gpa0-5;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   uart1_fctl: uart1-fctl {
+   samsung,pins = gpa0-6, gpa0-7;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+

[PATCHv4 1/7] ARM: EXYNOS: Add Exynos3250 SoC ID

2014-04-24 Thread Chanwoo Choi
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7
dual cores and has a target speed of 1.0GHz.

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/Kconfig | 22 ++
 arch/arm/mach-exynos/exynos.c|  2 ++
 arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
 3 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
 
 menu SAMSUNG EXYNOS SoCs Support
 
+config ARCH_EXYNOS3
+   bool SAMSUNG EXYNOS3
+   select ARM_AMBA
+   select CLKSRC_OF
+   select HAVE_ARM_SCU if SMP
+   select HAVE_SMP
+   select PINCTRL
+   select PM_GENERIC_DOMAINS if PM_RUNTIME
+   help
+ Samsung EXYNOS3 SoCs based systems
+
 config ARCH_EXYNOS4
bool SAMSUNG EXYNOS4
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
 
 comment EXYNOS SoCs
 
+config SOC_EXYNOS3250
+   bool SAMSUNG EXYNOS3250
+   default y
+   depends on ARCH_EXYNOS3
+   select ARCH_HAS_BANDGAP
+   select ARM_CPU_SUSPEND if PM
+   select PINCTRL_EXYNOS
+   select SAMSUNG_DMADEV
+   help
+ Enable EXYNOS3250 CPU support
+
 config CPU_EXYNOS4210
bool SAMSUNG EXYNOS4210
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6a5fe18..e7dc6fd 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -346,6 +346,8 @@ static void __init exynos_dt_machine_init(void)
 }
 
 static char const *exynos_dt_compat[] __initconst = {
+   samsung,exynos3,
+   samsung,exynos3250,
samsung,exynos4,
samsung,exynos4210,
samsung,exynos4212,
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h 
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
 #define S5PV210_CPU_ID 0x4311
 #define S5PV210_CPU_MASK   0xF000
 
+#define EXYNOS3250_SOC_ID   0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
 #define EXYNOS4210_CPU_ID  0x4321
 #define EXYNOS4212_CPU_ID  0x4322
 #define EXYNOS4412_CPU_ID  0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
 IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
 IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
 IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
 IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, 
EXYNOS5_SOC_MASK)
 # define soc_is_s5pv210()  0
 #endif
 
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
+
 #if defined(CONFIG_CPU_EXYNOS4210)
 # define soc_is_exynos4210()   is_samsung_exynos4210()
 #else
-- 
1.8.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


[PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework

2014-04-24 Thread Chanwoo Choi
From: Tomasz Figa t.f...@samsung.com

This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7
using common clock framework. The CMU (Clock Management Unit) of Exynos3250
control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses,
and function clocks for individual IPs.

The CMU of Exynos3250 includes following clock doamins:
- CPU block for Cortex-A7 MPCore processor
- LEFTBUS/RIGHTBUS block
- TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR

Cc: Mike Turquette mturque...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Karol Wrona k.wr...@samsung.com
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 +++
 3 files changed, 1042 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..d120797 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o
+obj-$(CONFIG_SOC_EXYNOS3250)   += clk-exynos3250.o
 obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-exynos3250.c 
b/drivers/clk/samsung/clk-exynos3250.c
new file mode 100644
index 000..0574a76
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -0,0 +1,785 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * 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.
+ *
+ * Common Clock Framework support for Exynos3250 SoC.
+ */
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/syscore_ops.h
+
+#include dt-bindings/clock/exynos3250.h
+
+#include clk.h
+#include clk-pll.h
+
+#define SRC_LEFTBUS0x4200
+#define DIV_LEFTBUS0x4500
+#define GATE_IP_LEFTBUS0x4800
+#define SRC_RIGHTBUS   0x8200
+#define DIV_RIGHTBUS   0x8500
+#define GATE_IP_RIGHTBUS   0x8800
+#define GATE_IP_PERIR  0x8960
+#define MPLL_LOCK  0xc010
+#define MPLL_CON0  0xc110
+#define VPLL_LOCK  0xc020
+#define VPLL_CON0  0xc120
+#define UPLL_LOCK  0xc030
+#define UPLL_CON0  0xc130
+#define SRC_TOP0   0xc210
+#define SRC_TOP1   0xc214
+#define SRC_CAM0xc220
+#define SRC_MFC0xc228
+#define SRC_G3D0xc22c
+#define SRC_LCD0xc234
+#define SRC_ISP0xc238
+#define SRC_FSYS   0xc240
+#define SRC_PERIL0 0xc250
+#define SRC_PERIL1 0xc254
+#define SRC_MASK_TOP   0xc310
+#define SRC_MASK_CAM   0xc320
+#define SRC_MASK_LCD   0xc334
+#define SRC_MASK_ISP   0xc338
+#define SRC_MASK_FSYS  0xc340
+#define SRC_MASK_PERIL00xc350
+#define SRC_MASK_PERIL10xc354
+#define DIV_TOP0xc510
+#define DIV_CAM0xc520
+#define DIV_MFC0xc528
+#define DIV_G3D0xc52c
+#define DIV_LCD0xc534
+#define DIV_ISP0xc538
+#define DIV_FSYS0  0xc540
+#define DIV_FSYS1  0xc544
+#define DIV_FSYS2  0xc548
+#define DIV_PERIL0 0xc550
+#define DIV_PERIL1 0xc554
+#define DIV_PERIL3 0xc55c
+#define DIV_PERIL4 0xc560
+#define DIV_PERIL5 0xc564
+#define DIV_CAM1   0xc568
+#define CLKDIV2_RATIO  0xc580
+#define GATE_SCLK_CAM  0xc820
+#define GATE_SCLK_MFC  0xc828
+#define GATE_SCLK_G3D  0xc82c
+#define GATE_SCLK_LCD  0xc834
+#define GATE_SCLK_ISP_TOP  0xc838
+#define GATE_SCLK_FSYS 0xc840

[PATCHv4 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7

2014-04-24 Thread Chanwoo Choi
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.

Cc: Arnd Bergmann a...@arndb.de
Cc: Marc Zynigier marc.zyng...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/hotplug.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
 
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
+* Prepare the CPU for shutting down. The required sequence of
+* operations depends on core type. CPUID part number can be used to
+* determine the right way.
 */
-   asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
-   if ((primary_part  0xfff0) == 0xc0f0)
+   primary_part = read_cpuid_part_number();
+
+   switch (primary_part) {
+   case ARM_CPU_PART_CORTEX_A7:
+   case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
-   else
+   break;
+   default:
cpu_enter_lowpower_a9();
+   break;
+   }
 
platform_do_lowpower(cpu, spurious);
 
-- 
1.8.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


[PATCHv4 6/7] dt-bindings: add documentation for Exynos3250 clock controller

2014-04-24 Thread Chanwoo Choi
The Exynos3250 clocks are statically listed and registered using the
Samsung specific common clock helper functions. Both device tree based
clock lookup and clkdev based clock lookups are supported.

Cc: Mike Turquette mturque...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Randy Dunlap rdun...@infradead.org
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 .../devicetree/bindings/clock/exynos3250-clock.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
new file mode 100644
index 000..aadc9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -0,0 +1,41 @@
+* Samsung Exynos3250 Clock Controller
+
+The Exynos3250 clock controller generates and supplies clock to various
+controllers within the Exynos3250 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - samsung,exynos3250-cmu - controller compatible with Exynos3250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos3250.h header and can be used in device
+tree sources.
+
+Example 1: An example of a clock controller node is listed below.
+
+   cmu: clock-controller@1003 {
+   compatible = samsung,exynos3250-cmu;
+   reg = 0x1003 0x2;
+   #clock-cells = 1;
+   };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+  controller. Refer to the standard clock bindings for information
+  about 'clocks' and 'clock-names' property.
+
+   serial@1380 {
+   compatible = samsung,exynos4210-uart;
+   reg = 0x1380 0x100;
+   interrupts = 0 109 0;
+   clocks = cmu CLK_UART0, cmu CLK_SCLK_UART0;
+   clock-names = uart, clk_uart_baud0;
+   };
-- 
1.8.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


RE: [PATCH] ARM: dts: exynos4: clean up arm-pmu node

2014-04-24 Thread Chanho Park
Hi Tomasz,

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-
 boun...@lists.infradead.org] On Behalf Of Tomasz Figa
 Sent: Friday, April 25, 2014 2:04 AM
 To: Chanho Park; kgene@samsung.com; linux-samsung-
 s...@vger.kernel.org
 Cc: Chanwoo Choi; linux-arm-ker...@lists.infradead.org
 Subject: Re: [PATCH] ARM: dts: exynos4: clean up arm-pmu node
 
 Hi Chanho,
 
 On 14.04.2014 15:03, Chanho Park wrote:
  This patch cleans a arm-pmu node up for exynos4. Only exynos4412
 series
  boards have four pmu interrupts. Rest of exynos4 boards, except 4412,
 have only
  two pmu interrupts. Thus, we can define two interrupts in the
  exynos4.dtsi and extends the interrupts only exynos4412.dtsi.
 
  Cc: Chanwoo Choi cw00.c...@samsung.com
  Signed-off-by: Chanho Park chanho61.p...@samsung.com
  ---
arch/arm/boot/dts/exynos4.dtsi| 6 ++
arch/arm/boot/dts/exynos4210.dtsi | 6 --
arch/arm/boot/dts/exynos4412.dtsi | 6 ++
arch/arm/boot/dts/exynos4x12.dtsi | 6 --
4 files changed, 12 insertions(+), 12 deletions(-)
 
  diff --git a/arch/arm/boot/dts/exynos4.dtsi
 b/arch/arm/boot/dts/exynos4.dtsi
  index e541ecb..6de978c 100644
  --- a/arch/arm/boot/dts/exynos4.dtsi
  +++ b/arch/arm/boot/dts/exynos4.dtsi
  @@ -105,6 +105,12 @@
  reg = 0x1044 0x1000;
  };
 
  +   pmu {
  +   compatible = arm,cortex-a9-pmu;
  +   interrupt-parent = combiner;
  +   interrupts = 2 2, 3 2;
  +   };
  +
  sys_reg: syscon@1001 {
  compatible = samsung,exynos4-sysreg, syscon;
  reg = 0x1001 0x400;
  diff --git a/arch/arm/boot/dts/exynos4210.dtsi
 b/arch/arm/boot/dts/exynos4210.dtsi
  index cacf614..4e7610f 100644
  --- a/arch/arm/boot/dts/exynos4210.dtsi
  +++ b/arch/arm/boot/dts/exynos4210.dtsi
  @@ -75,12 +75,6 @@
  #clock-cells = 1;
  };
 
  -   pmu {
  -   compatible = arm,cortex-a9-pmu;
  -   interrupt-parent = combiner;
  -   interrupts = 2 2, 3 2;
  -   };
  -
  pinctrl_0: pinctrl@1140 {
  compatible = samsung,exynos4210-pinctrl;
  reg = 0x1140 0x1000;
  diff --git a/arch/arm/boot/dts/exynos4412.dtsi
 b/arch/arm/boot/dts/exynos4412.dtsi
  index 15d3c0a..e6af870 100644
  --- a/arch/arm/boot/dts/exynos4412.dtsi
  +++ b/arch/arm/boot/dts/exynos4412.dtsi
  @@ -26,6 +26,12 @@
  samsung,combiner-nr = 20;
  };
 
  +   pmu {
  +   compatible = arm,cortex-a9-pmu;
  +   interrupt-parent = combiner;
 
 I guess you could omit the two properties above and let them be
 inherited from exynos4.dtsi.

Yes. It can be omitted in the exynos4412.dtsi. Thank you for your review.
I'll send V2 Patch.

Best Regards,
Chanho Park

--
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


[RESEND PATCH 0/3] ARM: dts: add device data for exynos4412-trats2

2014-04-24 Thread Beomho Seo
This patchset add some device node for exynos4412-trats2.
It is based on v3.15-next/dt-samsung-2 branch.

exynos4412-trats2.dts
- Fix incorrect compatible. Compatible of AK8975 are ak8975 or 
asahi-kasei,ak8975.
- Add cm36651 light/proximity sensor device node.
- Change gpio-key device node. fix incorrect gpio property, and then add 
ok-key node.

Beomho Seo (3):
  ARM: dts: fix incorrect compatible for exynos4412
  ARM: dts: add cm36651 light/proximity sensor node
  ARM: dts: fixed gpio key node for exynos4412

 arch/arm/boot/dts/exynos4412-trats2.dts |   50 ++-
 1 file changed, 43 insertions(+), 7 deletions(-)

-- 
1.7.9.5

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


[RESEND PATCH 1/3] ARM: dts: fix incorrect compatible for exynos4412

2014-04-24 Thread Beomho Seo
This patch fixed incorrect compatible for ak8975 magnetic sensor.
ak8975 magnetic sensor use compatible ak8975 or asahi-kasei,ak8975.

Signed-off-by: Beomho Seo beomho@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 3228506..42418e2 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -494,7 +494,7 @@
status = okay;

ak8975@0c {
-   compatible = ak,ak8975;
+   compatible = ak8975;
reg = 0x0c;
gpios = gpj0 7 0;
};
-- 
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCHv2] ARM: dts: exynos4: clean up arm-pmu node

2014-04-24 Thread Chanho Park
This patch cleans a arm-pmu node up for exynos4. Only exynos4412 series
boards have four pmu interrupts. Rest of exynos4 boards, except 4412, have only
two pmu interrupts. Thus, we can define two interrupts in the
exynos4.dtsi and extends the interrupts only exynos4412.dtsi.

Cc: Chanwoo Choi cw00.c...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
Changes from v1:
 - Remove duplicated properties in exynos4412.dtsi(Comment from Tomasz Figa)

 arch/arm/boot/dts/exynos4.dtsi| 6 ++
 arch/arm/boot/dts/exynos4210.dtsi | 6 --
 arch/arm/boot/dts/exynos4412.dtsi | 4 
 arch/arm/boot/dts/exynos4x12.dtsi | 6 --
 4 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 0401f4d..b43dc24 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -105,6 +105,12 @@
reg = 0x1044 0x1000;
};
 
+   pmu {
+   compatible = arm,cortex-a9-pmu;
+   interrupt-parent = combiner;
+   interrupts = 2 2, 3 2;
+   };
+
sys_reg: syscon@1001 {
compatible = samsung,exynos4-sysreg, syscon;
reg = 0x1001 0x400;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index cb0e768d..e19c154 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -75,12 +75,6 @@
#clock-cells = 1;
};
 
-   pmu {
-   compatible = arm,cortex-a9-pmu;
-   interrupt-parent = combiner;
-   interrupts = 2 2, 3 2;
-   };
-
pinctrl_0: pinctrl@1140 {
compatible = samsung,exynos4210-pinctrl;
reg = 0x1140 0x1000;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index a40b6e2..7b75762 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -26,6 +26,10 @@
samsung,combiner-nr = 20;
};
 
+   pmu {
+   interrupts = 2 2, 3 2, 18 2, 19 2;
+   };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x4000;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306..b730a74 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -31,12 +31,6 @@
mshc0 = mshc_0;
};
 
-   pmu {
-   compatible = arm,cortex-a9-pmu;
-   interrupt-parent = combiner;
-   interrupts = 2 2, 3 2, 18 2, 19 2;
-   };
-
pd_isp: isp-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
-- 
1.8.3.2

--
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


[RESEND PATCH 2/3] ARM: dts: add cm36651 light/proximity sensor node

2014-04-24 Thread Beomho Seo
Exynos4412-trats2 board have light/proximity sensor.
This patch add cm36651 light/ proximity sensor node for exynos4412.
cm36651 is required properties as below.
- Use i2c-gpio for cm36651 sensor.
- Use fixed regulator for the IR LED.
  It is a part of the cm36651 for proximity detection.
- cm36651 is i2c device driver so need to use i2c-gpio driver.

Signed-off-by: Beomho Seo beomho@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 42418e2..c9f3c6e 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -21,6 +21,7 @@

aliases {
i2c8 = i2c_ak8975;
+   i2c9 = i2c_cm36651;
};

memory {
@@ -71,6 +72,14 @@
enable-active-high;
};

+   ps_als_reg: voltage-regulator-2 {
+   compatible = regulator-fixed;
+   regulator-name = LED_A_3.0V;
+   regulator-min-microvolt = 300;
+   regulator-max-microvolt = 300;
+   gpio = gpj0 5 0;
+   enable-active-high;
+   };
/* More to come */
};

@@ -500,6 +509,23 @@
};
};

+   i2c_cm36651: i2c-gpio-2 {
+   compatible = i2c-gpio;
+   gpios = gpf0 0 0, gpf0 1 0;
+   i2c-gpio,delay-us = 2;
+   #address-cells = 1;
+   #size-cells = 0;
+   status = okay;
+
+   cm36651@18 {
+   compatible = cm36651;
+   reg = 0x18;
+   interrupt-parent = gpx0;
+   interrupts = 2 0;
+   vled-supply = ps_als_reg;
+   };
+   };
+
spi_1: spi@1393 {
pinctrl-names = default;
pinctrl-0 = spi1_bus;
-- 
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RESEND PATCH 3/3] ARM: dts: fixed gpio key node for exynos4412

2014-04-24 Thread Beomho Seo
This patch fixed gpio key device node.
First, fix incorrect gpio property.
And then, add ok-key node where locate bottom center.
I have tested on exynos4412-trats2 board.

Signed-off-by: Beomho Seo beomho@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index c9f3c6e..cc96bee 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -87,18 +87,18 @@
compatible = gpio-keys;

key-down {
-   interrupt-parent = gpj1;
-   interrupts = 2 0;
-   gpios = gpj1 2 1;
+   interrupt-parent = gpx3;
+   interrupts = 3 0;
+   gpios = gpx3 3 1;
linux,code = 114;
label = volume down;
debounce-interval = 10;
};

key-up {
-   interrupt-parent = gpj1;
-   interrupts = 1 0;
-   gpios = gpj1 1 1;
+   interrupt-parent = gpx2;
+   interrupts = 2 0;
+   gpios = gpx2 2 1;
linux,code = 115;
label = volume up;
debounce-interval = 10;
@@ -113,6 +113,16 @@
debounce-interval = 10;
gpio-key,wakeup;
};
+
+   key-ok {
+   interrupt-parent = gpx0;
+   interrupts = 1 0;
+   gpios = gpx0 1 1;
+   linux,code = 139;
+   label = ok;
+   debounce-inteval = 10;
+   gpio-key,wakeup;
+   };
};

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


Re: [PATCH v2] ARM: dts: Add peach-pit board support

2014-04-24 Thread Arun Kumar K
Thanks Doug  Tushar for the Reviewed-by.

On Fri, Apr 25, 2014 at 12:27 AM, Doug Anderson diand...@chromium.org wrote:
 Arun,

 On Wed, Apr 23, 2014 at 9:17 PM, Arun Kumar K arun...@samsung.com wrote:
 Adds the google peach-pit board dts file which uses
 exynos5420 SoC.

 Signed-off-by: Arun Kumar K arun...@samsung.com
 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
 Changes from v1
 ---
 - Addressed review comments from Doug, Sachin  Tushar
 - Removed adc and lid-switch nodes
 ---
  arch/arm/boot/dts/Makefile |1 +
  arch/arm/boot/dts/exynos5420-peach-pit.dts |  182 
 
  2 files changed, 183 insertions(+)
 +   spi@12d3 {
 +   status = okay;
 +   samsung,spi-src-clk = 0;
 +   num-cs = 1;
 +
 +   spidev@0 {
 +   compatible = spidev;
 +   reg = 0;
 +   spi-max-frequency = 5000;
 +   pinctrl-names = default;
 +   pinctrl-0 = spi_flash_cs;
 +
 +   controller-data {
 +   cs-gpio = gpa2 5 0;

 Technically this could be

 cs-gpio = gpa2 5 GPIO_ACTIVE_HIGH;

 ...but I don't think that's a huge deal...


Kukjin, please let me know if I need to re-send this or can you take
care while applying?

Regards
Arun

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


Re: [PATCH V2] ASoC: SAMSUNG: Add sound card driver for Snow board

2014-04-24 Thread Tushar Behera
On 04/24/2014 07:09 PM, Mark Brown wrote:
 On Wed, Apr 23, 2014 at 02:31:45PM +0530, Tushar Behera wrote:
 
 +Required properties:
 +- compatible : Can be one of the following,
 +google,snow-audio-max98090 or
 +google,snow-audio-max98095
 +- samsung,i2s-controller: The phandle of the Samsung I2S0 controller
 
 This should be any I2S controller, not just I2S0?
 

Yes, right. It can be any I2S controller. Just that, right now it is
wired to I2S0.

 +- samsung,audio-codec: The phandle of the audio codec
 
 This binding only has one I2S controller and CODEC.  However...
 
 +static struct snd_soc_dai_link snow_dai[] = {
 +{ /* Playback DAI i/f */
 +.name = Playback,
 +.stream_name = Playback,
 +.codec_dai_name = HiFi,
 +.dai_fmt = SND_SOC_DAIFMT_I2S |
 +SND_SOC_DAIFMT_NB_NF |
 +SND_SOC_DAIFMT_CBS_CFS,
 +}, { /* Capture DAI i/f */
 +.name = Capture,
 +.stream_name = Capture,
 +.codec_dai_name = HiFi,
 +.dai_fmt = SND_SOC_DAIFMT_I2S |
 +SND_SOC_DAIFMT_NB_NF |
 +SND_SOC_DAIFMT_CBS_CFS,
 +},
 +};
 
 ...for some reason we have separate capture and playback DAI links

That was lack of understanding from my side. I was of the impression
that the back-end uses different DAI interfaces for aplay and arecord,
which certainly is not the case. I will remove the 'Capture' dai and
make 'Playback' dai as the primary DAI.

 defined.  Why is that?  Also, why is the secondary I2S playback stream
 not supported (this may be a reason to restrict to only the one I2S
 interface)?

AFAICS, I2S driver doesn't support secondary DAI with DT (dai type is
always TYPE_PRI in case of DT). Hence I could not find a setup to test
secondary dai with this board.

 
 Please also use subject lines consistent with the subsystem - NO NEED TO
 SHOUT.
 

Noted, will take care.

Thanks.
-- 
Tushar Behera
--
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: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Tushar Behera
On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
 This patch fix the offset of CPU boot address and don't need to send smc call
 of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
 WFE in secure mode.
 
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/firmware.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
 index aa01c42..386d01d 100644
 --- a/arch/arm/mach-exynos/firmware.c
 +++ b/arch/arm/mach-exynos/firmware.c
 @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
  static int exynos_cpu_boot(int cpu)
  {
   /*
 +  * Exynos3250 doesn't need to send smc command for secondary CPU boot
 +  * because Exynos3250 removes WFE in secure mode.
 +  */
 + if (soc_is_exynos3250())
 + return 0;
 + /*
* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
* But, Exynos4212 has only one secondary CPU so second parameter
* isn't used for informing secure firmware about CPU id.
*/
 - if (soc_is_exynos4212())
 + else if (soc_is_exynos4212())

This changes is not required.

   cpu = 0;
  
   exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
 @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
 boot_addr)
  {
   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
  
 - if (!soc_is_exynos4212())
 + if (!soc_is_exynos4212()  !soc_is_exynos3250())
   boot_reg += 4*cpu;
  
   __raw_writel(boot_addr, boot_reg);
 


-- 
Tushar Behera
--
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: [PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250

2014-04-24 Thread Tushar Behera
On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
 From: Tomasz Figa t.f...@samsung.com
 
 This patch add new exynos3250.dtsi to support Exynos3250 SoC based on 
 Cortex-A7
 dual core and includes following dt nodes:
 

[ ... ]

 ---
  arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++
  arch/arm/boot/dts/exynos3250.dtsi | 405 +
  arch/arm/boot/dts/exynos4212-tizenw.dts   | 926 
 ++

exynos4412-tizenw.dts related changes are unrelated.

-- 
Tushar Behera
--
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 v3 02/16] clk: exynos5420: add clocks for ISP block

2014-04-24 Thread Alim Akhtar
Hi Shaik,

On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
 This patch adds missing clocks for ISP block

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
 ---
  drivers/clk/samsung/clk-exynos5420.c |   80 
 ++
  1 file changed, 80 insertions(+)

 diff --git a/drivers/clk/samsung/clk-exynos5420.c 
 b/drivers/clk/samsung/clk-exynos5420.c
 index 389d4b1..972da5d 100755
 --- a/drivers/clk/samsung/clk-exynos5420.c
 +++ b/drivers/clk/samsung/clk-exynos5420.c
 @@ -57,6 +57,7 @@
  #define SRC_FSYS   0x10244
  #define SRC_PERIC0 0x10250
  #define SRC_PERIC1 0x10254
 +#define SRC_ISP0x10270
  #define SRC_TOP10  0x10280
  #define SRC_TOP11  0x10284
  #define SRC_TOP12  0x10288
 @@ -77,12 +78,15 @@
  #define DIV_PERIC2 0x10560
  #define DIV_PERIC3 0x10564
  #define DIV_PERIC4 0x10568
 +#define SCLK_DIV_ISP0  0x10580
 +#define SCLK_DIV_ISP1  0x10584
  #define GATE_BUS_TOP   0x10700
  #define GATE_BUS_FSYS0 0x10740
  #define GATE_BUS_PERIC 0x10750
  #define GATE_BUS_PERIC10x10754
  #define GATE_BUS_PERIS00x10760
  #define GATE_BUS_PERIS10x10764
 +#define GATE_TOP_SCLK_ISP  0x10870
  #define GATE_IP_GSCL0  0x10910
  #define GATE_IP_GSCL1  0x10920
  #define GATE_IP_MFC0x1092c
 @@ -145,6 +149,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
 SRC_MASK_FSYS,
 SRC_MASK_PERIC0,
 SRC_MASK_PERIC1,
 +   SRC_ISP,
 DIV_TOP0,
 DIV_TOP1,
 DIV_TOP2,
 @@ -158,12 +163,15 @@ static unsigned long exynos5420_clk_regs[] __initdata = 
 {
 DIV_PERIC2,
 DIV_PERIC3,
 DIV_PERIC4,
 +   SCLK_DIV_ISP0,
 +   SCLK_DIV_ISP1,
 GATE_BUS_TOP,
 GATE_BUS_FSYS0,
 GATE_BUS_PERIC,
 GATE_BUS_PERIC1,
 GATE_BUS_PERIS0,
 GATE_BUS_PERIS1,
 +   GATE_TOP_SCLK_ISP,
 GATE_IP_GSCL0,
 GATE_IP_GSCL1,
 GATE_IP_MFC,
 @@ -250,6 +258,15 @@ PNAME(mout_user_aclk200_fsys_p)= {fin_pll, 
 mout_sw_aclk200_fsys};

  PNAME(mout_sw_aclk200_fsys2_p) = {dout_aclk200_fsys2, mout_sclk_spll};
  PNAME(mout_user_aclk200_fsys2_p) = {fin_pll, mout_sw_aclk200_fsys2};
 +PNAME(mout_sw_aclk400_isp_p) = {dout_aclk400_isp, mout_sclk_spll};
 +PNAME(mout_user_aclk400_isp_p) = {fin_pll, mout_sw_aclk400_isp};
 +
 +PNAME(mout_sw_aclk333_432_isp0_p) = {dout_aclk333_432_isp0,
 +   mout_sclk_spll};
 +PNAME(mout_user_aclk333_432_isp0_p) = {fin_pll, 
 mout_sw_aclk333_432_isp0};
 +
 +PNAME(mout_sw_aclk333_432_isp_p) = {dout_aclk333_432_isp, 
 mout_sclk_spll};
 +PNAME(mout_user_aclk333_432_isp_p) = {fin_pll, mout_sw_aclk333_432_isp};

  PNAME(mout_sw_aclk200_p) = {dout_aclk200, mout_sclk_spll};
  PNAME(mout_aclk200_disp1_p) = {fin_pll, mout_sw_aclk200};
 @@ -265,6 +282,7 @@ PNAME(mout_user_aclk166_p) = {fin_pll, 
 mout_sw_aclk166};

  PNAME(mout_sw_aclk266_p) = {dout_aclk266, mout_sclk_spll};
  PNAME(mout_user_aclk266_p) = {fin_pll, mout_sw_aclk266};
 +PNAME(mout_user_aclk266_isp_p) = {fin_pll, mout_sw_aclk266};

  PNAME(mout_sw_aclk333_432_gscl_p) = {dout_aclk333_432_gscl, 
 mout_sclk_spll};
  PNAME(mout_user_aclk333_432_gscl_p) = {fin_pll, 
 mout_sw_aclk333_432_gscl};
 @@ -448,6 +466,31 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
 __initdata = {
 MUX(0, mout_spi0, mout_group2_p, SRC_PERIC1, 20, 3),
 MUX(0, mout_spi1, mout_group2_p, SRC_PERIC1, 24, 3),
 MUX(0, mout_spi2, mout_group2_p, SRC_PERIC1, 28, 3),
 +   MUX(0, mout_aclk400_isp, mout_group1_p, SRC_TOP0, 0, 2),
 +   MUX(0, mout_sw_aclk400_isp, mout_sw_aclk400_isp_p,
 +   SRC_TOP10, 0, 1),
 +   MUX(0, mout_user_aclk400_isp, mout_user_aclk400_isp_p,
 +   SRC_TOP3, 0, 1),
 +   MUX(0, mout_aclk333_432_isp0, mout_group4_p, SRC_TOP1, 12, 2),
 +   MUX(0, mout_sw_aclk333_432_isp0, mout_sw_aclk333_432_isp0_p,
 +   SRC_TOP11, 12, 1),
 +   MUX(0, mout_user_aclk333_432_isp0, mout_user_aclk333_432_isp0_p,
 +   SRC_TOP4, 12, 1),
 +   MUX(0, mout_aclk333_432_isp, mout_group4_p,
 +   SRC_TOP1, 4, 2),
 +   MUX(0, mout_sw_aclk333_432_isp, mout_sw_aclk333_432_isp_p,
 +   SRC_TOP11, 4, 1),
 +   MUX(0, mout_user_aclk333_432_isp, mout_user_aclk333_432_isp_p,
 +   SRC_TOP4, 4, 1),
 +   MUX(0, mout_user_aclk266_isp, mout_user_aclk266_isp_p,
 +   SRC_TOP4, 16, 1),
 +
It is nice to sort then based on the same order as mentioned in there
register discription. Thats really halps in fast review. And to be
consistance with other code in this file.
e.g Should have all the SRC_TOP4 in one place, like:
MUX(.., SRC_TOP4, 4, 1),

Re: [PATCH] i2c: exynos5: Initialise Samsung High Speed I2C controller early

2014-04-24 Thread Tushar Behera
On 04/24/2014 09:55 PM, Mark Brown wrote:
 On Thu, Apr 24, 2014 at 08:18:36PM +0530, Naveen Krishna Chatradhi wrote:
 This patch moves initialization code to subsys_initcall() to ensure
 that the i2c bus is available early so the regulators can be quickly
 probed and available for other devices on their probe() call.
 
 Such solution has been proposed by Mark Brown to fix the problem of
 the regulators not beeing available on the peripheral device probe():
 http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html
 
 What specifically is this needed for?  We *should* be able to use
 deferred probe for most things, but I know that not all subsystems are
 able to yet.
 

DRM-Exynos is one such sub-system right now that doesn't handle deferred
probe well. That is one of the reasons for this patch.

-- 
Tushar Behera
--
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: [PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250

2014-04-24 Thread Chanwoo Choi
On 04/25/2014 01:38 PM, Tushar Behera wrote:
 On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
 From: Tomasz Figa t.f...@samsung.com

 This patch add new exynos3250.dtsi to support Exynos3250 SoC based on 
 Cortex-A7
 dual core and includes following dt nodes:

 
 [ ... ]
 
 ---
  arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++
  arch/arm/boot/dts/exynos3250.dtsi | 405 +
  arch/arm/boot/dts/exynos4212-tizenw.dts   | 926 
 ++
 
 exynos4412-tizenw.dts related changes are unrelated.


Right, It is may mistake.
I'll resend this patch.

Thanks,
Chanwoo Choi

--
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 v3 6/7] arm64: mm: Implement 4 levels of translation tables

2014-04-24 Thread Jungseok Lee
On Thursday, April 24, 2014 1:02 AM, Steve Capper wrote:
 On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
  This patch implements 4 levels of translation tables since 3 levels of
  page tables with 4KB pages cannot support 40-bit physical address
  space described in [1] due to the following issue.
 
  It is a restriction that kernel logical memory map with 4KB + 3 levels
  (0xffc0-0x) cannot cover RAM region from
  544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
  mapping for this region in map_mem function since __phys_to_virt for
  this region reaches to address overflow.
 
  If SoC design follows the document, [1], over 32GB RAM would be placed
  from 544GB. Even 64GB system is supposed to use the region from 544GB
  to 576GB for only 32GB RAM. Naturally, it would reach to enable 4
  levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
 
  However, it is recommended 4 levels of page table should be only
  enabled if memory map is too sparse or there is about 512GB RAM.
 
 Hello Jungseok,
 A few comments can be found inline...

Hi Steve, The comments are very helpful. Thanks.

[ ... ]

  diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index
  0fd5650..f313a7a 100644
  --- a/arch/arm64/kernel/head.S
  +++ b/arch/arm64/kernel/head.S
  @@ -37,8 +37,8 @@
 
   /*
* swapper_pg_dir is the virtual address of the initial page table.
  We place
  - * the page tables 3 * PAGE_SIZE below KERNEL_RAM_VADDR. The
  idmap_pg_dir has
  - * 2 pages and is placed below swapper_pg_dir.
  + * the page tables 4 * PAGE_SIZE below KERNEL_RAM_VADDR. The
  + idmap_pg_dir has
  + * 3 pages and is placed below swapper_pg_dir.
*/
   #define KERNEL_RAM_VADDR   (PAGE_OFFSET + TEXT_OFFSET)
 
  @@ -46,8 +46,8 @@
   #error KERNEL_RAM_VADDR must start at 0xXXX8  #endif
 
  -#define SWAPPER_DIR_SIZE   (3 * PAGE_SIZE)
  -#define IDMAP_DIR_SIZE (2 * PAGE_SIZE)
  +#define SWAPPER_DIR_SIZE   (4 * PAGE_SIZE)
  +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE)
 
  .globl  swapper_pg_dir
  .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE
  @@ -371,16 +371,29 @@ ENDPROC(__calc_phys_offset)
 
   /*
* Macro to populate the PGD for the corresponding block entry in the
  next
  - * level (tbl) for the given virtual address.
  + * levels (tbl1 and tbl2) for the given virtual address.
*
  - * Preserves:  pgd, tbl, virt
  + * Preserves:  pgd, tbl1, tbl2, virt
 
 tbl1 and tbl2 are *not* preserved for 4 level. tbl1 is bumped up one page to 
 make space for the pud,
 then fed into create_block_mapping later.

Your logic can be extended to 3 levels.
In an original code, tbl is fed into create_block_mapping.
That is why I've written them down as preserves.

I will fix it in the next version.

* Corrupts:   tmp1, tmp2
*/
  -   .macro  create_pgd_entry, pgd, tbl, virt, tmp1, tmp2
  +   .macro  create_pgd_entry, pgd, tbl1, tbl2, virt, tmp1, tmp2
  lsr \tmp1, \virt, #PGDIR_SHIFT
  and \tmp1, \tmp1, #PTRS_PER_PGD - 1 // PGD index
  -   orr \tmp2, \tbl, #3 // PGD entry table type
  +   orr \tmp2, \tbl1, #3// PGD entry table type
  str \tmp2, [\pgd, \tmp1, lsl #3]
  +#ifdef CONFIG_ARM64_4_LEVELS
  +   ldr \tbl2, =FIXADDR_TOP
  +   cmp \tbl2, \virt
 
 Do we need this extra logic? See my other comment below where the fixed 
 mapping is placed down.
 
  +   add \tbl2, \tbl1, #PAGE_SIZE
  +   b.ne1f
  +   add \tbl2, \tbl2, #PAGE_SIZE
  +1:
  +   lsr \tmp1, \virt, #PUD_SHIFT
  +   and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index
  +   orr \tmp2, \tbl2, #3// PUD entry table type
  +   str \tmp2, [\tbl1, \tmp1, lsl #3]
  +   mov \tbl1, \tbl2
  +#endif
 
 It may be easier to read to have a create_pud_entry macro too?

Okay. I will write a create_pud_entry macro.

  .endm
 
   /*
  @@ -444,7 +457,7 @@ __create_page_tables:
  add x0, x25, #PAGE_SIZE // section table address
  ldr x3, =KERNEL_START
  add x3, x3, x28 // __pa(KERNEL_START)
  -   create_pgd_entry x25, x0, x3, x5, x6
  +   create_pgd_entry x25, x0, x1, x3, x5, x6
  ldr x6, =KERNEL_END
  mov x5, x3  // __pa(KERNEL_START)
  add x6, x6, x28 // __pa(KERNEL_END)
  @@ -455,7 +468,7 @@ __create_page_tables:
   */
  add x0, x26, #PAGE_SIZE // section table address
  mov x5, #PAGE_OFFSET
  -   create_pgd_entry x26, x0, x5, x3, x6
  +   create_pgd_entry x26, x0, x1, x5, x3, x6
  ldr x6, =KERNEL_END
  mov x3, x24 // phys offset
  create_block_map x0, x7, x3, x5, x6
  @@ -480,8 +493,11 @@ __create_page_tables:
   * Create the pgd entry for the fixed mappings.
   */
  ldr x5, =FIXADDR_TOP// Fixed mapping 

Re: [PATCH v5] arm: exynos: generalize power register address calculation

2014-04-24 Thread Chander Kashyap
On 24 April 2014 13:18, Chander Kashyap chander.kash...@linaro.org wrote:
 On 22 April 2014 17:55, Chander Kashyap chander.kash...@linaro.org wrote:
 Currently status/configuration power register values are hard-coded for cpu1.

 Make it generic so that it is useful for SoC's with more than two cpus.

 Signed-off-by: Chander Kashyap chander.kash...@linaro.org
 Signed-off-by: Chander Kashyap k.chan...@samsung.com
 ---
 changes in v5:
 1. Fix typo: enynos_pmu_cpunr - exynos_pmu_cpunr
 changes in v4:
 1: Dropped changes in platsmp.c and hotplug.c as those are taken 
 care by
Tomasz Patches.
 2. Converted ENYNOS_PMU_CPUNR macro to static inline function
 changes in v3:
 1. Move cpunr calculation to a macro
 2. Changed printk format specifier from unsigned hex to unsigned 
 decimal
 Changes in v2:
 1. Used existing macros for clusterid and cpuid calculation

  arch/arm/mach-exynos/regs-pmu.h |   18 --
  1 file changed, 16 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/regs-pmu.h 
 b/arch/arm/mach-exynos/regs-pmu.h
 index 4f6a256..f39e78c 100644
 --- a/arch/arm/mach-exynos/regs-pmu.h
 +++ b/arch/arm/mach-exynos/regs-pmu.h
 @@ -105,8 +105,13 @@
  #define S5P_GPS_LOWPWR S5P_PMUREG(0x139C)
  #define S5P_GPS_ALIVE_LOWPWR   S5P_PMUREG(0x13A0)

 -#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
 -#define S5P_ARM_CORE1_STATUS   S5P_PMUREG(0x2084)
 +#define S5P_ARM_CORE0_CONFIGURATIONS5P_PMUREG(0x2000)
 +#define S5P_ARM_CORE0_STATUS   S5P_PMUREG(0x2004)
 +
 +#define S5P_ARM_CORE_CONFIGURATION(_cpunr) \
 +   (S5P_ARM_CORE0_CONFIGURATION + 0x80 * (_cpunr))
 +#define S5P_ARM_CORE_STATUS(_cpunr) \
 +   (S5P_ARM_CORE0_STATUS + 0x80 * (_cpunr))

  #define S5P_PAD_RET_MAUDIO_OPTION  S5P_PMUREG(0x3028)
  #define S5P_PAD_RET_GPIO_OPTIONS5P_PMUREG(0x3108)
 @@ -313,4 +318,13 @@

  #define EXYNOS5_OPTION_USE_RETENTION   (1  4)

 +#include asm/cputype.h
 +#define MAX_CPUS_IN_CLUSTER4
 +
 +static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
 +{
 +   return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
 ++ MPIDR_AFFINITY_LEVEL(mpidr, 0));
 +}
 +
  #endif /* __ASM_ARCH_REGS_PMU_H */
 --
 1.7.9.5


 Any other comment on this. If not can this be merged?

Please reject this patch as some of changes also done by Tomasz in his patches.


 --
 with warm regards,
 Chander Kashyap



-- 
with warm regards,
Chander Kashyap
--
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: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Chanwoo Choi
Hi,

On 04/25/2014 01:30 PM, Tushar Behera wrote:
 On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
 This patch fix the offset of CPU boot address and don't need to send smc call
 of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
 WFE in secure mode.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/firmware.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/firmware.c 
 b/arch/arm/mach-exynos/firmware.c
 index aa01c42..386d01d 100644
 --- a/arch/arm/mach-exynos/firmware.c
 +++ b/arch/arm/mach-exynos/firmware.c
 @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
  static int exynos_cpu_boot(int cpu)
  {
  /*
 + * Exynos3250 doesn't need to send smc command for secondary CPU boot
 + * because Exynos3250 removes WFE in secure mode.
 + */
 +if (soc_is_exynos3250())
 +return 0;
 +/*
   * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
   * But, Exynos4212 has only one secondary CPU so second parameter
   * isn't used for informing secure firmware about CPU id.
   */
 -if (soc_is_exynos4212())
 +else if (soc_is_exynos4212())
 
 This changes is not required.

Do you mean it as following?

if (soc_is_exynos3250())
return 0

if (soc_is_exynos4212())
cpu = 0;

 
  cpu = 0;
  
  exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
 @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
 boot_addr)
  {
  void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
  
 -if (!soc_is_exynos4212())
 +if (!soc_is_exynos4212()  !soc_is_exynos3250())
  boot_reg += 4*cpu;
  
  __raw_writel(boot_addr, boot_reg);

 
 

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


[PATCH] arm: exynos: add generic function to calculate cpu number

2014-04-24 Thread Chander Kashyap
The address of cpu power registers in pmu is based on cpu number
offsets. This function calculate the same. This is essentially
required in case of multicluster SoC's e.g Exynos5420.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
 arch/arm/mach-exynos/regs-pmu.h |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..217da2e 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -313,4 +313,13 @@
 
 #define EXYNOS5_OPTION_USE_RETENTION   (1  4)
 
+#include asm/cputype.h
+#define MAX_CPUS_IN_CLUSTER4
+
+static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
+{
+   return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
++ MPIDR_AFFINITY_LEVEL(mpidr, 0));
+}
+
 #endif /* __ASM_ARCH_REGS_PMU_H */
-- 
1.7.9.5

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


Re: [PATCH v3 00/16] exynos5420: clock file cleanup

2014-04-24 Thread Shaik Ameer Basha
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
 Many changes/fixes have been identified for clock file for exynos5420.
 These include correct parents, bit fields, new clocks etc. Existing
 files needs some correction in terms of names of the clock and
 indentation. These issues are addressed in this patch series. It also
 replaces the usage of enums with macro as clock ids.

 This patch series is rebased on,
 git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master

 This patch is also dependent on the following patch.
 ARM: dts: add dt node for sss module for exynos5250/5420

Sorry, it depends on SSS clock patch. Not the dts one.
clk: samsung exynos5250/5420: Add gate clock for SSS module


 Changes since v2:
 -
 1] Addressed review comments from Gerhard Sittig and Tomasz Figa.

 Changes since v1:
 -
 1] Addressed review comments from Tomasz Figa.
 http://www.spinics.net/lists/devicetree/msg16759.html
 http://www.spinics.net/lists/devicetree/msg16760.html

 Shaik Ameer Basha (16):
   clk: exynos5420: rename parent clocks
   clk: exynos5420: add clocks for ISP block
   clk: exynos5420: update clocks for GSCL and MSCL blocks
   clk: exynos5420: correct clock parents for mscl sysmmu
   clk: exynos5420: update clocks for G2D block
   clk: exynos5420: update clocks for DISP1 block
   clk: exynos5420: update clocks for PERIC block
   clk: exynos5420: update clocks for PERIS and GEN blocks
   clk: exynos5420: update clocks for WCORE block
   clk: exynos5420: update clocks for FSYS and FSYS2 blocks
   clk: exynos5420: correct sysmmu-mfc parent clocks
   clk: exynos5420: fix register offset for sclk_bpll
   clk: exynos5420: cleanup core and misc clocks
   clk: exynos5420: correct g3d parent clock
   clk: exynos5420: create clock ID for mout_sclk_vpll
   clk: exynos5420: add more registers to restore list

  arch/arm/boot/dts/exynos5420.dtsi  |   14 +-
  drivers/clk/samsung/clk-exynos5420.c   |  808 
 
  include/dt-bindings/clock/exynos5420.h |   33 +-
  3 files changed, 550 insertions(+), 305 deletions(-)
  mode change 100644 = 100755 drivers/clk/samsung/clk-exynos5420.c
  mode change 100644 = 100755 include/dt-bindings/clock/exynos5420.h

 --
 1.7.9.5

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


Re: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Tushar Behera
On 04/25/2014 11:13 AM, Chanwoo Choi wrote:
 Hi,
 
 On 04/25/2014 01:30 PM, Tushar Behera wrote:
 On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
 This patch fix the offset of CPU boot address and don't need to send smc 
 call
 of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 
 removes
 WFE in secure mode.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/firmware.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/firmware.c 
 b/arch/arm/mach-exynos/firmware.c
 index aa01c42..386d01d 100644
 --- a/arch/arm/mach-exynos/firmware.c
 +++ b/arch/arm/mach-exynos/firmware.c
 @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
  static int exynos_cpu_boot(int cpu)
  {
 /*
 +* Exynos3250 doesn't need to send smc command for secondary CPU boot
 +* because Exynos3250 removes WFE in secure mode.
 +*/
 +   if (soc_is_exynos3250())
 +   return 0;
 +   /*
  * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
  * But, Exynos4212 has only one secondary CPU so second parameter
  * isn't used for informing secure firmware about CPU id.
  */
 -   if (soc_is_exynos4212())
 +   else if (soc_is_exynos4212())

 This changes is not required.
 
 Do you mean it as following?
 
   if (soc_is_exynos3250())
   return 0
 
   if (soc_is_exynos4212())
   cpu = 0;
 

Yes, logically the flow would be same and code would be more readable.


 cpu = 0;
  
 exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
 @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned 
 long boot_addr)
  {
 void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
  
 -   if (!soc_is_exynos4212())
 +   if (!soc_is_exynos4212()  !soc_is_exynos3250())
 boot_reg += 4*cpu;
  
 __raw_writel(boot_addr, boot_reg);



 


-- 
Tushar Behera
--
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: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Chanwoo Choi
Hi,

On 04/25/2014 02:54 PM, Tushar Behera wrote:
 On 04/25/2014 11:13 AM, Chanwoo Choi wrote:
 Hi,

 On 04/25/2014 01:30 PM, Tushar Behera wrote:
 On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
 This patch fix the offset of CPU boot address and don't need to send smc 
 call
 of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 
 removes
 WFE in secure mode.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/firmware.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/firmware.c 
 b/arch/arm/mach-exynos/firmware.c
 index aa01c42..386d01d 100644
 --- a/arch/arm/mach-exynos/firmware.c
 +++ b/arch/arm/mach-exynos/firmware.c
 @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
  static int exynos_cpu_boot(int cpu)
  {
/*
 +   * Exynos3250 doesn't need to send smc command for secondary CPU boot
 +   * because Exynos3250 removes WFE in secure mode.
 +   */
 +  if (soc_is_exynos3250())
 +  return 0;
 +  /*
 * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
 * But, Exynos4212 has only one secondary CPU so second parameter
 * isn't used for informing secure firmware about CPU id.
 */
 -  if (soc_is_exynos4212())
 +  else if (soc_is_exynos4212())

 This changes is not required.

 Do you mean it as following?

  if (soc_is_exynos3250())
  return 0

  if (soc_is_exynos4212())
  cpu = 0;

 
 Yes, logically the flow would be same and code would be more readable.

OK, I'll fix it.

Thanks,
Chanwoo Choi

--
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 2/2] ARM: dts: Add sound node for Peach-pit board

2014-04-24 Thread Tushar Behera
The audio setup on Peach-pit board is similar to Snow board, hence the
sound-card driver used on Snow board can be reused on Peach-pit board.

Peach-pit board uses MAX98090 audio codec.

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   31 
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index fbb0469..1043bd3 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -37,6 +37,13 @@
};
 
pinctrl@1340 {
+   max98090_irq: max98090-irq {
+   samsung,pins = gpx0-2;
+   samsung,pin-function = 0;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
tpm_irq: tpm-irq {
samsung,pins = gpx1-0;
samsung,pin-function = 0;
@@ -143,6 +150,19 @@
};
};
 
+   i2c@12CD {
+   status = okay;
+
+   max98090: codec@10 {
+   compatible = maxim,max98090;
+   reg = 0x10;
+   interrupts = 2 0;
+   interrupt-parent = gpx0;
+   pinctrl-names = default;
+   pinctrl-0 = max98090_irq;
+   };
+   };
+
spi@12d3 {
status = okay;
samsung,spi-src-clk = 0;
@@ -179,4 +199,15 @@
watchdog@101D {
timeout-sec = 32;
};
+
+   i2s0: i2s@0383 {
+   status = okay;
+   };
+
+   sound {
+   compatible = google,snow-audio-max98090;
+
+   samsung,i2s-controller = i2s0;
+   samsung,audio-codec = max98090;
+   };
 };
-- 
1.7.9.5

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


[PATCH 1/2] ARM: dts: Add sound node for Snow board

2014-04-24 Thread Tushar Behera
The audio codec on Snow board, MAX98095 is connected on I2C7 bus.
Also it requires the GPX1-7 line to be pulled up.

Updated Snow DTS file to incorporate above changes and added a
sound node to instantiate the I2S-based sound card.

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
 arch/arm/boot/dts/exynos5250-snow.dts |   32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1bc9b50..f63df3c 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -196,6 +196,38 @@
};
};
 
+   regulators {
+   compatible = simple-bus;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   max98095-en-regulator {
+   compatible = regulator-fixed;
+   gpio = gpx1 7 0;
+   enable-active-high;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   };
+
+   i2c@12CD {
+   max98095: codec@11 {
+   compatible = maxim,max98095;
+   reg = 0x11;
+   };
+   };
+
+   i2s0: i2s@0383 {
+   status = okay;
+   };
+
+   sound {
+   compatible = google,snow-audio-max98095;
+
+   samsung,i2s-controller = i2s0;
+   samsung,audio-codec = max98095;
+   };
+
usb@1211 {
samsung,vbus-gpio = gpx1 1 0;
};
-- 
1.7.9.5

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


[PATCH 0/2] Add sound card node Snow/Peach-pit board

2014-04-24 Thread Tushar Behera
Related sound card driver has been posted here.
1. [PATCH V2] ASoC: SAMSUNG: Add sound card driver for Snow board
https://lkml.org/lkml/2014/4/23/184

Patch 2 is dependent on Arun's following patch.
2. [PATCH v2] ARM: dts: Add peach-pit board support
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29189.html

Tushar Behera (2):
  ARM: dts: Add sound node for Snow board
  ARM: dts: Add sound node for Peach-pit board

 arch/arm/boot/dts/exynos5250-snow.dts  |   32 
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   31 +++
 2 files changed, 63 insertions(+)

-- 
1.7.9.5

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


Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-24 Thread Vivek Gautam
Hi,


On Thu, Apr 24, 2014 at 6:08 AM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
 Hi,

 Hi,

  -Original Message-
  From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
  ow...@vger.kernel.org] On Behalf Of Vivek Gautam
  Sent: Monday, April 21, 2014 9:17 PM
 
  Facilitate getting required 3.3V and 1.0V VDD supply for
  OHCI controller on Exynos.
 
  With patches for regulators' nodes merged in 3.15:
  c8c253f ARM: dts: Add regulator entries to smdk5420
  275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
 
  certain perripherals will now need to ensure that,
  they request VDD regulators in their drivers, and enable
  them so as to make them working.
 
  Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
  Cc: Jingoo Han jg1@samsung.com
  ---
 
  Based on 'usb-next' branch of Greg's usb tree.
 
   drivers/usb/host/ohci-exynos.c |   47
  
   1 file changed, 47 insertions(+)
 
  diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
  exynos.c
  index 68588d8..e2e72a8 100644
  --- a/drivers/usb/host/ohci-exynos.c
  +++ b/drivers/usb/host/ohci-exynos.c

[snip]

   static void exynos_ohci_phy_enable(struct platform_device *pdev)
  @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
 platform_device
  *pdev)
  exynos_ohci-otg = phy-otg;
  }
 
  +   exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
  +   if (IS_ERR(exynos_ohci-vdd33)) {
  +   err = PTR_ERR(exynos_ohci-vdd33);
  +   goto fail_regulator1;
  +   }
  +   err = regulator_enable(exynos_ohci-vdd33);
  +   if (err) {
  +   dev_err(pdev-dev, Failed to enable VDD33 supply\n);
  +   goto fail_regulator1;
  +   }
  +
  +   exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
  +   if (IS_ERR(exynos_ohci-vdd10)) {
  +   err = PTR_ERR(exynos_ohci-vdd10);
  +   goto fail_regulator2;
  +   }
  +   err = regulator_enable(exynos_ohci-vdd10);
  +   if (err) {
  +   dev_err(pdev-dev, Failed to enable VDD10 supply\n);
  +   goto fail_regulator2;
  +   }
  +

 Do we need to skip regulator settings together with PHY configuration
 in case of exynos5440?

   skip_phy:
  exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
 

[snip]

  @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
  struct usb_hcd *hcd = dev_get_drvdata(dev);
  struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
  struct platform_device *pdev= to_platform_device(dev);
  +   int ret;
  +
  +   ret = regulator_enable(exynos_ohci-vdd33);
  +   if (ret) {
  +   dev_err(dev, Failed to enable VDD33 supply\n);
  +   return ret;

 Not sure, but shall we continue resuming and do everything
 we can in case of error? At least it will avoid
 WARN_ON(clk-enable_count == 0) on next system suspend.

True, i will modify it.

 On the other hand, if power is not applied to the controller,
 register access in ohci_resume() may lead to undefined behavior.
 What's your opinion?

AFA i think, it is obvious that the regulators would not work without
a VDD supply.
So the question is, do we have VDD LDOs available on all Exynos
systems for usb ?
From the schemata of Exynos5250 and Exynos5420 boards, i can see the
required VDD LDOs
for USB. Unfortunately at present i don't have a Exynos4* schemata.

If regulator is not a mandatory, then we can make it option similar to
what Jingoo has also suggested
in subsequent mail.

[snip]


-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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] usb: ohci-exynos: Make provision for vdd regulators

2014-04-24 Thread Vivek Gautam
Hi Jingoo,


On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han jg1@samsung.com wrote:
 On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
 On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
  On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
  
   Facilitate getting required 3.3V and 1.0V VDD supply for
   OHCI controller on Exynos.
  
   With patches for regulators' nodes merged in 3.15:
   c8c253f ARM: dts: Add regulator entries to smdk5420
   275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
  
   certain perripherals will now need to ensure that,
   they request VDD regulators in their drivers, and enable
   them so as to make them working.
  
   Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
   Cc: Jingoo Han jg1@samsung.com
   ---
  
   Based on 'usb-next' branch of Greg's usb tree.
  
drivers/usb/host/ohci-exynos.c |   47
   
1 file changed, 47 insertions(+)
  
   diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
   exynos.c
   index 68588d8..e2e72a8 100644
   --- a/drivers/usb/host/ohci-exynos.c
   +++ b/drivers/usb/host/ohci-exynos.c

[snip]

   @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
   *pdev)
 exynos_ohci-otg = phy-otg;
 }
  
   + exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
   + if (IS_ERR(exynos_ohci-vdd33)) {
   + err = PTR_ERR(exynos_ohci-vdd33);
   + goto fail_regulator1;
   + }
   + err = regulator_enable(exynos_ohci-vdd33);
   + if (err) {
   + dev_err(pdev-dev, Failed to enable VDD33 supply\n);
   + goto fail_regulator1;
   + }
   +
   + exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
   + if (IS_ERR(exynos_ohci-vdd10)) {
   + err = PTR_ERR(exynos_ohci-vdd10);
   + goto fail_regulator2;
   + }
   + err = regulator_enable(exynos_ohci-vdd10);
   + if (err) {
   + dev_err(pdev-dev, Failed to enable VDD10 supply\n);
   + goto fail_regulator2;
   + }
   +
 
  Do we need to skip regulator settings together with PHY configuration
  in case of exynos5440?

 Oh, right. In the case of exynos5440, regulator settings is not
 necessary. Vivek, would you fix it in order skip regulator settings
 in exynos5440? It also applies to ehci-exynos.

 Sorry, in the case of exynos5440, this patch already skips
 regulator settings.

 In the case of exynos5440, there is no need to set PHY setting
 and regulator setting.

Right, in case of exynos5440, we are skipping PHY setting and regulator setting.
Actually i had missed taking into account 5440, so just curious. Do we
really not need a regulator
settings for Exynos5440 ?


 How about making regulator setting optional?
 Then, regulator setting can be done, only when regulator
 is supported.

True, so with Exynos5440 not needing the regulator, we should make the
regulator settings optional.


 exynos_ohci_probe()
 exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
 if (IS_ERR(exynos_ohci-vdd33)) {
 dev_err(pdev-dev, Failed to get VDD33 supply\n);
 } else {
 err = regulator_enable(exynos_ohci-vdd33);
 if (err) {
 dev_err(pdev-dev, Failed to enable VDD33 
 supply\n);
 goto fail_regulator1;
 }
 }

 exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
 if (IS_ERR(exynos_ohci-vdd10)) {
 dev_err(pdev-dev, Failed to get VDD10 supply\n);
 } else {
 err = regulator_enable(exynos_ohci-vdd10);
 if (err) {
 dev_err(pdev-dev, Failed to enable VDD10 
 supply\n);
 goto fail_regulator2;
 }
 }

 In this case, suspend/resume can be fixed as below.

 exynos_ohci_suspend()
 if (exynos_ohci-vdd10)
 regulator_disable(exynos_ohci-vdd10);
 if (exynos_ohci-vdd33)
 regulator_disable(exynos_ohci-vdd33);

 exynos_ohci_resume()

 if (exynos_ohci-vdd33) {
 ret = regulator_enable(exynos_ohci-vdd33);
 if (ret) {
 dev_err(dev, Failed to enable VDD33 supply\n);
 return ret;
 }
 }
 if (exynos_ohci-vdd10) {
 ret = regulator_enable(exynos_ohci-vdd10);
 if (ret) {
 dev_err(dev, Failed to enable VDD10 supply\n);
 return ret;
 }
 }

Thanks for the suggestion.
I will make the required changes, and post the patchset again.

[snip]


-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: S3C24XX: remove SAMSUNG_CLOCK remnants after ccf conversion

2014-04-24 Thread Heiko Stübner
This finally removes all remaining SAMSUNG_CLOCK conditional code
from s3c24xx architectures.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
This is of course meant to go on top of the s3c2410 ccf conversion

 arch/arm/mach-s3c24xx/Kconfig |  5 -
 arch/arm/mach-s3c24xx/common.c| 17 -
 arch/arm/mach-s3c24xx/cpufreq-utils.c |  6 --
 arch/arm/mach-s3c24xx/mach-anubis.c   | 27 ---
 arch/arm/mach-s3c24xx/mach-bast.c | 27 ---
 arch/arm/mach-s3c24xx/mach-osiris.c   | 27 ---
 arch/arm/mach-s3c24xx/mach-rx1950.c   | 14 --
 arch/arm/mach-s3c24xx/mach-vr1000.c   | 27 ---
 arch/arm/mach-s3c24xx/pm.c| 12 
 9 files changed, 162 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 77b0fb5..4500802 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -265,7 +265,6 @@ config ARCH_BAST
select ISA
select MACH_BAST_IDE
select S3C2410_IOTIMING if ARM_S3C2410_CPUFREQ
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
@@ -347,7 +346,6 @@ config MACH_TCT_HAMMER
 config MACH_VR1000
bool Thorcom VR1000
select MACH_BAST_IDE
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
@@ -533,7 +531,6 @@ config MACH_ANUBIS
bool Simtec Electronics ANUBIS
select HAVE_PATA_PLATFORM
select S3C2440_XTAL_1200
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_USB_HOST
@@ -574,7 +571,6 @@ config MACH_OSIRIS
bool Simtec IM2440D20 (OSIRIS) module
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_1200
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_NAND
@@ -646,7 +642,6 @@ config MACH_RX1950
select PM_H1940 if PM
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_16934400
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C24XX_COMMON_DCLK if COMMON_CLK
select S3C24XX_PWM
select S3C_DEV_NAND
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 600a1be..c0763b8 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -307,23 +307,6 @@ struct s3c24xx_uart_resources s3c2410_uart_resources[] 
__initdata = {
},
 };
 
-/* initialise all the clocks */
-
-#ifdef CONFIG_SAMSUNG_CLOCK
-void __init_or_cpufreq s3c24xx_setup_clocks(unsigned long fclk,
-  unsigned long hclk,
-  unsigned long pclk)
-{
-   clk_upll.rate = s3c24xx_get_pll(__raw_readl(S3C2410_UPLLCON),
-   clk_xtal.rate);
-
-   clk_mpll.rate = fclk;
-   clk_h.rate = hclk;
-   clk_p.rate = pclk;
-   clk_f.rate = fclk;
-}
-#endif
-
 #if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2412) || \
defined(CONFIG_CPU_S3C2440) || defined(CONFIG_CPU_S3C2442)
 static struct resource s3c2410_dma_resource[] = {
diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c 
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index c1b7508..d4d9514 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
@@ -61,12 +61,6 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config 
*cfg)
  */
 void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
 {
-#ifdef CONFIG_SAMSUNG_CLOCK
-   __raw_writel(cfg-pll.driver_data, S3C2410_MPLLCON);
-#endif
-
-#ifdef CONFIG_COMMON_CLK
if (!IS_ERR(cfg-mpll))
clk_set_rate(cfg-mpll, cfg-pll.frequency);
-#endif
 }
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c 
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 7a0d83b..e053581 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -364,16 +364,6 @@ static struct platform_device *anubis_devices[] __initdata 
= {
anubis_device_sm501,
 };
 
-#ifdef CONFIG_SAMSUNG_CLOCK
-static struct clk *anubis_clocks[] __initdata = {
-   s3c24xx_dclk0,
-   s3c24xx_dclk1,
-   s3c24xx_clkout0,
-   s3c24xx_clkout1,
-   s3c24xx_uclk,
-};
-#endif
-
 /* I2C devices. */
 
 static struct i2c_board_info anubis_i2c_devs[] __initdata = {
@@ -396,23 +386,6 @@ static struct s3c24xx_audio_simtec_pdata __initdata 
anubis_audio = {
 
 static void __init anubis_map_io(void)
 {
-#ifdef CONFIG_SAMSUNG_CLOCK
-   /* initialise the clocks */
-
-   s3c24xx_dclk0.parent = clk_upll;
-   

Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-24 Thread Jingoo Han
On Thursday, April 24, 2014 3:40 PM, Vivek Gautam wrote:
 On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han jg1@samsung.com wrote:
  On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
  On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
   On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
   
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
   
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
   
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
   
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
   
Based on 'usb-next' branch of Greg's usb tree.
   
 drivers/usb/host/ohci-exynos.c |   47

 1 file changed, 47 insertions(+)
   
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
 
 [snip]
 
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
  exynos_ohci-otg = phy-otg;
  }
   
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
  
   Do we need to skip regulator settings together with PHY configuration
   in case of exynos5440?
 
  Oh, right. In the case of exynos5440, regulator settings is not
  necessary. Vivek, would you fix it in order skip regulator settings
  in exynos5440? It also applies to ehci-exynos.
 
  Sorry, in the case of exynos5440, this patch already skips
  regulator settings.
 
  In the case of exynos5440, there is no need to set PHY setting
  and regulator setting.
 
 Right, in case of exynos5440, we are skipping PHY setting and regulator 
 setting.
 Actually i had missed taking into account 5440, so just curious. Do we
 really not need a regulator
 settings for Exynos5440 ?

To be more specific, there is no regulator on ssdk5440 board
which is the Exynos5440-based board.

Best regards,
Jingoo Han

  How about making regulator setting optional?
  Then, regulator setting can be done, only when regulator
  is supported.
 
 True, so with Exynos5440 not needing the regulator, we should make the
 regulator settings optional.

[.]

 Thanks for the suggestion.
 I will make the required changes, and post the patchset again.

OK, I see.
Thank you for accepting my suggestion.

Best regards,
Jingoo Han

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


Re: [Patch v2 4/4] mcpm: exynos: populate suspend and powered_up callbacks

2014-04-24 Thread Chander Kashyap
On 23 April 2014 21:32, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote:
 [added Nico in CC]

 On Wed, Apr 23, 2014 at 10:25:54AM +0100, Chander Kashyap wrote:
 In order to support cpuidle through mcpm, suspend and powered-up
 callbacks are required in mcpm platform code.
 Hence populate the same callbacks.

 Signed-off-by: Chander Kashyap chander.kash...@linaro.org
 Signed-off-by: Chander Kashyap k.chan...@samsung.com
 ---
 changes in v2:
   1. Fixed typo: enynos_pmu_cpunr to exynos_pmu_cpunr

  arch/arm/mach-exynos/mcpm-exynos.c |   53 
 
  1 file changed, 53 insertions(+)

 diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
 b/arch/arm/mach-exynos/mcpm-exynos.c
 index 6c74c82..d53f597 100644
 --- a/arch/arm/mach-exynos/mcpm-exynos.c
 +++ b/arch/arm/mach-exynos/mcpm-exynos.c
 @@ -272,10 +272,63 @@ static int exynos_power_down_finish(unsigned int cpu, 
 unsigned int cluster)
   return 0; /* success: the CPU is halted */
  }

 +static void enable_coherency(void)
 +{
 + unsigned long v, u;
 +
 + asm volatile(
 + mrcp15, 0, %0, c1, c0, 1\n
 + orr%0, %0, %2\n
 + ldr%1, [%3]\n
 + and%1, %1, #0\n
 + orr%0, %0, %1\n
 + mcrp15, 0, %0, c1, c0, 1\n
 + : =r (v), =r (u)
 + : Ir (0x40), Ir (S5P_INFORM0)
 + : cc);
 +}
 +
 +void exynos_powered_up(void)
 +{
 + unsigned int mpidr, cpu, cluster;
 +
 + mpidr = read_cpuid_mpidr();
 + cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
 + cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
 +
 + arch_spin_lock(exynos_mcpm_lock);
 + if (cpu_use_count[cpu][cluster] == 0)
 + cpu_use_count[cpu][cluster] = 1;
 + arch_spin_unlock(exynos_mcpm_lock);
 +}
 +
 +static void exynos_suspend(u64 residency)
 +{
 + unsigned int mpidr, cpunr;
 +
 + mpidr = read_cpuid_mpidr();
 + cpunr = exynos_pmu_cpunr(mpidr);
 +
 + __raw_writel(virt_to_phys(mcpm_entry_point), REG_ENTRY_ADDR);
 +
 + exynos_power_down();
 +
 + /*
 +  * Execution reaches here only if cpu did not power down.
 +  * Hence roll back the changes done in exynos_power_down function.
 + */
 + __raw_writel(EXYNOS_CORE_LOCAL_PWR_EN,
 + EXYNOS_ARM_CORE_CONFIGURATION(cpunr));
 + set_cr(get_cr() | CR_C);
 + enable_coherency();

 This is wrong:

 1) MCPM would eventually reboot the CPU in question if the suspend call
returns (and restore SCTLR and ACTLR in cpu_resume), so there is 0 point
in doing that here.

Yes i missed that. I will correct it.

 2) The core would have executed out of coherency for a while so the
tlbs could be stale and you do not invalidate them. But given (1), (2)
becomes just informational. The register write must be executed
though (I guess...). Now, on restoring the SMP bit in cpu_resume
(errata 799270) I need to verify this is safe and get back to you.

Ok

Thanks Lorenzo.



 Cheers,
 Lorenzo




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


Re: [Patch v2 2/4] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420

2014-04-24 Thread Chander Kashyap
On 23 April 2014 22:02, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote:
 On Wed, Apr 23, 2014 at 10:25:52AM +0100, Chander Kashyap wrote:
 Add samsung,exynos5420 compatible string to initialize generic
 big-little cpuidle driver for Exynos5420.

 Signed-off-by: Chander Kashyap chander.kash...@linaro.org
 Signed-off-by: Chander Kashyap k.chan...@samsung.com
 Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
 ---
  drivers/cpuidle/cpuidle-big_little.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/cpuidle/cpuidle-big_little.c 
 b/drivers/cpuidle/cpuidle-big_little.c
 index b45fc62..d0fac53 100644
 --- a/drivers/cpuidle/cpuidle-big_little.c
 +++ b/drivers/cpuidle/cpuidle-big_little.c
 @@ -170,7 +170,8 @@ static int __init bl_idle_init(void)
   /*
* Initialize the driver just for a compliant set of machines
*/
 - if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7))
 + if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7) 
 + (!of_machine_is_compatible(samsung,exynos5420)))
   return -ENODEV;

 We should handle the string matching differently, we can't keep adding
 comparisons.

yes, that's true.



 Daniel raised the point already: what about the idle tables (data and
 number of states ?). TC2 has just a cluster state, and specific
 latencies, which are highly unlikely to be correct for this platform.


As of now only support for one state i.e. core power down.

As latencies are  concerned, need to fine tune.

Thanks again for the review.

 Lorenzo




-- 
with warm regards,
Chander Kashyap
--
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] arm: exynos: generalize power register address calculation

2014-04-24 Thread Chander Kashyap
On 22 April 2014 17:55, Chander Kashyap chander.kash...@linaro.org wrote:
 Currently status/configuration power register values are hard-coded for cpu1.

 Make it generic so that it is useful for SoC's with more than two cpus.

 Signed-off-by: Chander Kashyap chander.kash...@linaro.org
 Signed-off-by: Chander Kashyap k.chan...@samsung.com
 ---
 changes in v5:
 1. Fix typo: enynos_pmu_cpunr - exynos_pmu_cpunr
 changes in v4:
 1: Dropped changes in platsmp.c and hotplug.c as those are taken care 
 by
Tomasz Patches.
 2. Converted ENYNOS_PMU_CPUNR macro to static inline function
 changes in v3:
 1. Move cpunr calculation to a macro
 2. Changed printk format specifier from unsigned hex to unsigned 
 decimal
 Changes in v2:
 1. Used existing macros for clusterid and cpuid calculation

  arch/arm/mach-exynos/regs-pmu.h |   18 --
  1 file changed, 16 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
 index 4f6a256..f39e78c 100644
 --- a/arch/arm/mach-exynos/regs-pmu.h
 +++ b/arch/arm/mach-exynos/regs-pmu.h
 @@ -105,8 +105,13 @@
  #define S5P_GPS_LOWPWR S5P_PMUREG(0x139C)
  #define S5P_GPS_ALIVE_LOWPWR   S5P_PMUREG(0x13A0)

 -#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
 -#define S5P_ARM_CORE1_STATUS   S5P_PMUREG(0x2084)
 +#define S5P_ARM_CORE0_CONFIGURATIONS5P_PMUREG(0x2000)
 +#define S5P_ARM_CORE0_STATUS   S5P_PMUREG(0x2004)
 +
 +#define S5P_ARM_CORE_CONFIGURATION(_cpunr) \
 +   (S5P_ARM_CORE0_CONFIGURATION + 0x80 * (_cpunr))
 +#define S5P_ARM_CORE_STATUS(_cpunr) \
 +   (S5P_ARM_CORE0_STATUS + 0x80 * (_cpunr))

  #define S5P_PAD_RET_MAUDIO_OPTION  S5P_PMUREG(0x3028)
  #define S5P_PAD_RET_GPIO_OPTIONS5P_PMUREG(0x3108)
 @@ -313,4 +318,13 @@

  #define EXYNOS5_OPTION_USE_RETENTION   (1  4)

 +#include asm/cputype.h
 +#define MAX_CPUS_IN_CLUSTER4
 +
 +static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
 +{
 +   return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
 ++ MPIDR_AFFINITY_LEVEL(mpidr, 0));
 +}
 +
  #endif /* __ASM_ARCH_REGS_PMU_H */
 --
 1.7.9.5


Any other comment on this. If not can this be merged?


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


Re: [PATCH 1/1] ARM: exynos_defconfig: Enable HS-I2C

2014-04-24 Thread Tushar Behera
On 03/04/2014 05:52 PM, Sachin Kamat wrote:
 High speed I2C is used on Exynos5 based SoCs. Enable it.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  arch/arm/configs/exynos_defconfig |1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm/configs/exynos_defconfig 
 b/arch/arm/configs/exynos_defconfig
 index 4ce7b70ea901..e07a227ec0db 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -65,6 +65,7 @@ CONFIG_TCG_TIS_I2C_INFINEON=y
  CONFIG_I2C=y
  CONFIG_I2C_MUX=y
  CONFIG_I2C_ARB_GPIO_CHALLENGE=y
 +CONFIG_I2C_EXYNOS5=y
  CONFIG_I2C_S3C2410=y
  CONFIG_DEBUG_GPIO=y
  # CONFIG_HWMON is not set
 
Kukjin,

Please consider picking this patch when you plan to update
exynos_defconfig. With this change on upstream kernel, we are able to
get Arndale_Octa board to boot and mount an MMC partition successfully.

-- 
Tushar Behera
--
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: dts: Remove mau_pd node for Exynos5420

2014-04-24 Thread Tushar Behera
On 04/23/2014 03:43 PM, Kukjin Kim wrote:
 Tushar Behera wrote:

 On 22 April 2014 13:08, Alim Akhtar alim.akh...@gmail.com wrote:
 Hi Tushar

 On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
 tushar.beh...@linaro.org wrote:
 MAU powerdomain provides clocks for Audio sub-system block. This block
 comprises of the I2S audio controller, audio DMA blocks and Audio
 sub-system clock registers.

 Right now, there is no way to hook up power-domains with clock
 providers.
 During late boot when this power-domain gets disabled, we get following
 external abort.
 
 + Jonghwan Choi
 
 Well, this is not a perfect solution to support MAU power domain, it's true 
 it is a problem right now though.
 
 In other words, this is just temporal fix for the problem.
 
 How about accessing clock stuff for audio sub-system with handling MAU power 
 domain via generic IO power domain?
 

+ Tomasz Figa

Existing power domain driver exynos4_pm_init_power_domain is registered
with an arch_initcall whereas the clk-exynos-audss driver is registered
with core_initcall. Hence even if add mau_pd node to clk-exynos-audss
node, the binding with power-domain doesn't happen.

Alternately, if Tomasz's patches are applied [1], power-domain binding
is successful. But because of the init order, clk-exynos-audss defers
probe resulting in a kernel crash. Forcing clk-exynos-audss to register
through arch_initcall() fixes this issue, but I am not sure if that is okay.

[1] http://www.spinics.net/lists/kernel/msg1728566.html

 ?? which abort?? Can you please mention it here?


 Thanks Alim for spotting this ... I somehow missed adding this.

 
 Unhandled fault: imprecise external abort (0x1406) at 0x
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007


 Kukjin,

 Let me know if I need to resend the patch.
 
 - Kukjin
 


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


Re: [PATCH] mmc: dw_mmc: Don't print data errors

2014-04-24 Thread Ulf Hansson
 The status here could be useful information about the status
 register, which is not considered while printing errors by the higher
 levels. An option could be to print the error, but not when you
 perform tuning.

 No big deal though, just a thought.

 Right, I could potentially put the driver into tuning mode and then
 suppress the errors during that time.  If you request it I will do
 that.

 I will also note that there are many other error conditions in the
 driver that don't have such printouts.  I think the general philosophy
 of this driver is not to print them...

So, then let's stick to that philosophy and keep this as is.

Kind regards
Ulf Hansson


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


[PATCH] ARM: exynos: register sched_clock callback

2014-04-24 Thread Vincent Guittot
Use the clocksource mct-frc for sched_clock

Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
 drivers/clocksource/exynos_mct.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index a6ee6d7..61b0577 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -24,6 +24,7 @@
 #include linux/of_irq.h
 #include linux/of_address.h
 #include linux/clocksource.h
+#include linux/sched_clock.h
 
 #define EXYNOS4_MCTREG(x)  (x)
 #define EXYNOS4_MCT_G_CNT_LEXYNOS4_MCTREG(0x100)
@@ -192,12 +193,19 @@ struct clocksource mct_frc = {
.resume = exynos4_frc_resume,
 };
 
+static u64 notrace exynos4_read_sched_clock(void)
+{
+   return exynos4_frc_read(mct_frc);
+}
+
 static void __init exynos4_clocksource_init(void)
 {
exynos4_mct_frc_start(0, 0);
 
if (clocksource_register_hz(mct_frc, clk_rate))
panic(%s: can't register clocksource\n, mct_frc.name);
+
+   sched_clock_register(exynos4_read_sched_clock, 64, clk_rate);
 }
 
 static void exynos4_mct_comp0_stop(void)
-- 
1.9.1

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


[PATCH 2/2] ARM: EXYNOS: use generic exynos cpu power control functions

2014-04-24 Thread Leela Krishna Amudala
Use generic exynos cpu power control functions to power up/down
and to know the status of the cpu.

Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
---
 arch/arm/mach-exynos/platsmp.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 03e5e9f..e3d005b 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -107,15 +107,12 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 */
write_pen_release(phys_cpu);
 
-   if (!(__raw_readl(S5P_ARM_CORE1_STATUS)  S5P_CORE_LOCAL_PWR_EN)) {
-   __raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
-
+   if (!exynos_cpu_power_state(cpu)) {
+   exynos_cpu_powerup(cpu);
timeout = 10;
 
/* wait max 10 ms until cpu1 is on */
-   while ((__raw_readl(S5P_ARM_CORE1_STATUS)
-S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
+   while (exynos_cpu_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
 
-- 
1.7.9.5

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


[PATCH 1/2] ARM: EXYNOS: Add generic cpu power control functions for all exynos based SoCs

2014-04-24 Thread Leela Krishna Amudala
Add generic cpu power control functions for exynos based SoCS
for cpu power up/down and to know the cpu status.

Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
---
 arch/arm/mach-exynos/common.h   |3 +++
 arch/arm/mach-exynos/pm.c   |   36 
 arch/arm/mach-exynos/regs-pmu.h |6 ++
 3 files changed, 45 insertions(+)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9ef3f83..566f222 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -62,5 +62,8 @@ struct exynos_pmu_conf {
 };
 
 extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void exynos_cpu_powerdown(int cpu);
+extern void exynos_cpu_powerup(int cpu);
+extern int  exynos_cpu_power_state(int cpu);
 
 #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..6651028 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -100,6 +100,42 @@ static int exynos_irq_set_wake(struct irq_data *data, 
unsigned int state)
return -ENOENT;
 }
 
+/**
+ * exynos_cpu_powerdown : power down the specified cpu
+ * @cpu : the cpu to power down
+ *
+ * Power downs the specified cpu. The sequence must be finished by a
+ * call to cpu_do_idle()
+ *
+ */
+void exynos_cpu_powerdown(int cpu)
+{
+   __raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_powerup : power up the specified cpu
+ * @cpu : the cpu to power up
+ *
+ * Power up the specified cpu
+ */
+void exynos_cpu_powerup(int cpu)
+{
+   __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_power_state : returns the power state of the cpu
+ * @cpu : the cpu to retrieve the power state from
+ *
+ */
+int exynos_cpu_power_state(int cpu)
+{
+   return (__raw_readl(EXYNOS_ARM_CORE_STATUS(cpu)) 
+   S5P_CORE_LOCAL_PWR_EN);
+}
+
 /* For Cortex-A9 Diagnostic and Power control register */
 static unsigned int save_arm_register[2];
 
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..0bdfcbc 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -121,6 +121,12 @@
 
 #define S5P_CHECK_SLEEP0x0BAD
 
+#define EXYNOS_ARM_CORE0_CONFIGURATION S5P_PMUREG(0x2000)
+#define EXYNOS_ARM_CORE_CONFIGURATION(_nr) \
+   (EXYNOS_ARM_CORE0_CONFIGURATION + (0x80 * (_nr)))
+#define EXYNOS_ARM_CORE_STATUS(_nr)\
+   (EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
+
 /* Only for EXYNOS4210 */
 #define S5P_CMU_CLKSTOP_LCD1_LOWPWRS5P_PMUREG(0x1154)
 #define S5P_CMU_RESET_LCD1_LOWPWR  S5P_PMUREG(0x1174)
-- 
1.7.9.5

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


[PATCH 0/2] Add generic cpu power control functions for exynos

2014-04-24 Thread Leela Krishna Amudala
This patchset adds the generic cpu power control functions for
exynos based SoCs to power up/down and to know the status of the cpu.

Note: This series has been rebased on 3.15-rc1 and tested on 
Exynos based Origen(Cortex-A9) and Arndale-octa(Cortex A7,A15) boards.

Leela Krishna Amudala (2):
  ARM: EXYNOS: Add generic cpu power control functions for all exynos
based SoCs
  ARM: EXYNOS: use generic exynos cpu power control functions

 arch/arm/mach-exynos/common.h   |3 +++
 arch/arm/mach-exynos/platsmp.c  |9 +++--
 arch/arm/mach-exynos/pm.c   |   36 
 arch/arm/mach-exynos/regs-pmu.h |6 ++
 4 files changed, 48 insertions(+), 6 deletions(-)

-- 
1.7.9.5

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


Re: [PATCH 0/2] Add generic cpu power control functions for exynos

2014-04-24 Thread Daniel Lezcano


Hi Abhilash and Leela,

FYI I think you are working on similar patches.

On 04/24/2014 11:31 AM, Leela Krishna Amudala wrote:
 This patchset adds the generic cpu power control functions for

exynos based SoCs to power up/down and to know the status of the cpu.

Note: This series has been rebased on 3.15-rc1 and tested on
Exynos based Origen(Cortex-A9) and Arndale-octa(Cortex A7,A15) boards.

Leela Krishna Amudala (2):
   ARM: EXYNOS: Add generic cpu power control functions for all exynos
 based SoCs
   ARM: EXYNOS: use generic exynos cpu power control functions

  arch/arm/mach-exynos/common.h   |3 +++
  arch/arm/mach-exynos/platsmp.c  |9 +++--
  arch/arm/mach-exynos/pm.c   |   36 
  arch/arm/mach-exynos/regs-pmu.h |6 ++
  4 files changed, 48 insertions(+), 6 deletions(-)




--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

--
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: dts: Remove mau_pd node for Exynos5420

2014-04-24 Thread Tomasz Figa

On 24.04.2014 11:07, Tushar Behera wrote:

On 04/23/2014 03:43 PM, Kukjin Kim wrote:

Tushar Behera wrote:


On 22 April 2014 13:08, Alim Akhtar alim.akh...@gmail.com wrote:

Hi Tushar

On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
tushar.beh...@linaro.org wrote:

MAU powerdomain provides clocks for Audio sub-system block. This block
comprises of the I2S audio controller, audio DMA blocks and Audio
sub-system clock registers.

Right now, there is no way to hook up power-domains with clock

providers.

During late boot when this power-domain gets disabled, we get following
external abort.


+ Jonghwan Choi

Well, this is not a perfect solution to support MAU power domain, it's true it 
is a problem right now though.

In other words, this is just temporal fix for the problem.

How about accessing clock stuff for audio sub-system with handling MAU power 
domain via generic IO power domain?



+ Tomasz Figa

Existing power domain driver exynos4_pm_init_power_domain is registered
with an arch_initcall whereas the clk-exynos-audss driver is registered
with core_initcall. Hence even if add mau_pd node to clk-exynos-audss
node, the binding with power-domain doesn't happen.


I'd say core_initcall is way too early for clk-exynos-audss driver. It 
should be at most subsys_initcall. As far as I can see, all users of 
clocks provided by this driver (i.e. i2s) are probed at device_initcall 
level anyway.




Alternately, if Tomasz's patches are applied [1], power-domain binding
is successful. But because of the init order, clk-exynos-audss defers
probe resulting in a kernel crash. Forcing clk-exynos-audss to register
through arch_initcall() fixes this issue, but I am not sure if that is okay.


If the driver crashes on deferred probe, then it's a bug and it should 
be fixed.


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 0/4] ARM: S3C24XX: cleanup debug macro/earlyprintk

2014-04-24 Thread Heiko Stübner
This series tries to simplify the s3c24xx debug macro, removing dependencies
on mach/ includes, static mappings and finally moving it into include/debug.

The one slightly invasive change is the need for the developer to select
the uart type by himself, which gets rid of the debug macro trying to
determine the uart type itself.

But as usage of the debug-uart is not the common case - especially in a
multiplatform scenario - I didn't worry to much.

Based on 3.15-rc1 and tested on a S3C2442 Openmoko Freerunner (GTA02)


Heiko Stuebner (4):
  ARM: compressed/head.S: remove s3c24xx special case
  ARM: S3C24XX: trim down debug uart handling
  ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro
  ARM: S3C24XX: move debug-macro.S into the common space

 arch/arm/Kconfig.debug   |  36 +++-
 arch/arm/boot/compressed/head.S  |   5 --
 arch/arm/include/debug/s3c24xx.S |  46 +++
 arch/arm/mach-s3c24xx/Kconfig|  28 ---
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 101 ---
 5 files changed, 80 insertions(+), 136 deletions(-)
 create mode 100644 arch/arm/include/debug/s3c24xx.S
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/debug-macro.S

-- 
1.9.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


[PATCH 1/4] ARM: compressed/head.S: remove s3c24xx special case

2014-04-24 Thread Heiko Stübner
addruart from the generic debug macro is doing exactly the same using
the common lowlevel uart definition, so there is no cause for this
special casing for s3c24xx.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/boot/compressed/head.S | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 066b034..3a8b32d 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -60,11 +60,6 @@
add \rb, \rb, #0x0001   @ Ser1
 #endif
.endm
-#elif defined(CONFIG_ARCH_S3C24XX)
-   .macro loadsp, rb, tmp
-   mov \rb, #0x5000
-   add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
-   .endm
 #else
.macro  loadsp, rb, tmp
addruart \rb, \tmp
-- 
1.9.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


[PATCH 2/4] ARM: S3C24XX: trim down debug uart handling

2014-04-24 Thread Heiko Stübner
Using the lowlevel debug uart is a corner case - even more so in a
multiplatform environment. So it seems reasonable to simply let the
developer set the appropriate uart type for the debugged SoC.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/Kconfig.debug   | 16 
 arch/arm/mach-s3c24xx/Kconfig| 28 -
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 52 +---
 3 files changed, 17 insertions(+), 79 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 4a2fc0b..43b94a9 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -918,6 +918,22 @@ choice
 
 endchoice
 
+choice
+   prompt S3C24XX low-level debugging port type
+   depends on DEBUG_LL  ARCH_S3C24XX
+
+   config DEBUG_S3C24XX_UART_S3C2440
+   bool S3C2440 uart type
+   help
+ Select this if you're debugging S3C2416, S3C2440, S3C2442,
+ S3C2443 or S3C2450 SoCs.
+
+   config DEBUG_S3C24XX_UART_S3C2410
+   bool S3C2410 uart type
+   help
+ Select this if you're debugging S3C2410 or S3C2412 SoCs.
+endchoice
+
 config DEBUG_EXYNOS_UART
bool
 
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 40cf50b..98d17af 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -26,7 +26,6 @@ config CPU_S3C2410
bool SAMSUNG S3C2410
default y
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2410
select S3C2410_CLOCK
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
@@ -39,7 +38,6 @@ config CPU_S3C2410
 config CPU_S3C2412
bool SAMSUNG S3C2412
select CPU_ARM926T
-   select CPU_LLSERIAL_S3C2440
select S3C2412_DMA if S3C24XX_DMA
select S3C2412_PM if PM
help
@@ -48,7 +46,6 @@ config CPU_S3C2412
 config CPU_S3C2416
bool SAMSUNG S3C2416/S3C2450
select CPU_ARM926T
-   select CPU_LLSERIAL_S3C2440
select S3C2416_PM if PM
select S3C2443_COMMON
select S3C2443_DMA if S3C24XX_DMA
@@ -59,7 +56,6 @@ config CPU_S3C2416
 config CPU_S3C2440
bool SAMSUNG S3C2440
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2410_CLOCK
select S3C2410_PM if PM
select S3C2440_DMA if S3C24XX_DMA
@@ -69,7 +65,6 @@ config CPU_S3C2440
 config CPU_S3C2442
bool SAMSUNG S3C2442
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2410_CLOCK
select S3C2410_DMA if S3C24XX_DMA
select S3C2410_PM if PM
@@ -84,7 +79,6 @@ config CPU_S3C244X
 config CPU_S3C2443
bool SAMSUNG S3C2443
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2443_COMMON
select S3C2443_DMA if S3C24XX_DMA
select SAMSUNG_CLKSRC
@@ -158,28 +152,6 @@ config S3C2410_PM
help
  Power Management code common to S3C2410 and better
 
-# low-level serial option nodes
-
-config CPU_LLSERIAL_S3C2410_ONLY
-   bool
-   default y if CPU_LLSERIAL_S3C2410  !CPU_LLSERIAL_S3C2440
-
-config CPU_LLSERIAL_S3C2440_ONLY
-   bool
-   default y if CPU_LLSERIAL_S3C2440  !CPU_LLSERIAL_S3C2410
-
-config CPU_LLSERIAL_S3C2410
-   bool
-   help
- Selected if there is an S3C2410 (or register compatible) serial
- low-level implementation needed
-
-config CPU_LLSERIAL_S3C2440
-   bool
-   help
- Selected if there is an S3C2440 (or register compatible) serial
- low-level implementation needed
-
 config S3C24XX_PLL
bool Support CPUfreq changing of PLL frequency (EXPERIMENTAL)
depends on ARM_S3C24XX_CPUFREQ
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 
b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 2f39737..3077a5f 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -13,11 +13,9 @@
 */
 
 #include mach/map.h
-#include mach/regs-gpio.h
 #include linux/serial_s3c.h
 
 #define S3C2410_UART1_OFF (0x4000)
-#define SHIFT_2440TXF (14-9)
 
.macro addruart, rp, rv, tmp
ldr \rp, = S3C24XX_PA_UART
@@ -28,56 +26,11 @@
 #endif
.endm
 
-   .macro fifo_full_s3c24xx rd, rx
-   @ check for arm920 vs arm926. currently assume all arm926
-   @ devices have an 64 byte FIFO identical to the s3c2440
-   mrc p15, 0, \rd, c0, c0
-   and \rd, \rd, #0xff0
-   teq \rd, #0x260
-   beq 1004f
-   mrc p15, 0, \rd, c1, c0
-   tst \rd, #1
-   addeq   \rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
-   addne   \rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
-   bic \rd, \rd, #0xff000
-   ldr

[PATCH 3/4] ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro

2014-04-24 Thread Heiko Stübner
This removes the need for mach/-headers in the debug macro.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/Kconfig.debug   | 19 +--
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |  9 ++---
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 43b94a9..2476f84 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -625,6 +625,7 @@ choice
config DEBUG_S3C_UART0
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool Use S3C UART 0 for low-level debug
help
  Say Y here if you want the debug print routines to direct
@@ -637,6 +638,7 @@ choice
config DEBUG_S3C_UART1
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool Use S3C UART 1 for low-level debug
help
  Say Y here if you want the debug print routines to direct
@@ -649,6 +651,7 @@ choice
config DEBUG_S3C_UART2
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool Use S3C UART 2 for low-level debug
help
  Say Y here if you want the debug print routines to direct
@@ -661,6 +664,7 @@ choice
config DEBUG_S3C_UART3
depends on PLAT_SAMSUNG  ARCH_EXYNOS
select DEBUG_EXYNOS_UART
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool Use S3C UART 3 for low-level debug
help
  Say Y here if you want the debug print routines to direct
@@ -937,6 +941,9 @@ endchoice
 config DEBUG_EXYNOS_UART
bool
 
+config DEBUG_S3C24XX_UART
+   bool
+
 config DEBUG_OMAP2PLUS_UART
bool
depends on ARCH_OMAP2PLUS
@@ -1045,6 +1052,10 @@ config DEBUG_UART_PHYS
default 0x4009 if ARCH_LPC32XX
default 0x4010 if DEBUG_PXA_UART1
default 0x4200 if ARCH_GEMINI
+   default 0x5000 if DEBUG_S3C24XX_UART  DEBUG_S3C_UART0
+   default 0x50004000 if DEBUG_S3C24XX_UART  DEBUG_S3C_UART1
+   default 0x50008000 if DEBUG_S3C24XX_UART  DEBUG_S3C_UART2
+   default 0x5000C000 if DEBUG_S3C24XX_UART  DEBUG_S3C_UART3
default 0x7c0003f8 if FOOTBRIDGE
default 0x8023 if DEBUG_PICOXCELL_UART
default 0x8007 if DEBUG_IMX23_UART
@@ -1074,7 +1085,7 @@ config DEBUG_UART_PHYS
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
DEBUG_LL_UART_EFM32 || \
-   DEBUG_UART_8250 || DEBUG_UART_PL01X
+   DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
 
 config DEBUG_UART_VIRT
hex Virtual base address of debug UART
@@ -1091,6 +1102,10 @@ config DEBUG_UART_VIRT
default 0xf210 if DEBUG_PXA_UART1
default 0xf409 if ARCH_LPC32XX
default 0xf420 if ARCH_GEMINI
+   default 0xf700 if DEBUG_S3C24XX_UART  DEBUG_S3C_UART0
+   default 0xf7004000 if DEBUG_S3C24XX_UART  DEBUG_S3C_UART1
+   default 0xf7008000 if DEBUG_S3C24XX_UART  DEBUG_S3C_UART2
+   default 0xf700c000 if DEBUG_S3C24XX_UART  DEBUG_S3C_UART3
default 0xf7fc9000 if DEBUG_BERLIN_UART
default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9
default 0xf809 if DEBUG_VEXPRESS_UART0_RS1
@@ -1132,7 +1147,7 @@ config DEBUG_UART_VIRT
default 0xff003000 if DEBUG_U300_UART
default DEBUG_UART_PHYS if !MMU
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
-   DEBUG_UART_8250 || DEBUG_UART_PL01X
+   DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
 
 config DEBUG_UART_8250_SHIFT
int Register offset shift for the 8250 debug UART
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 
b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 3077a5f..5b165d8 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -12,18 +12,13 @@
  * published by the Free Software Foundation.
 */
 
-#include mach/map.h
 #include linux/serial_s3c.h
 
 #define S3C2410_UART1_OFF (0x4000)
 
.macro addruart, rp, rv, tmp
-   ldr \rp, = S3C24XX_PA_UART
-   ldr \rv, = S3C24XX_VA_UART
-#if CONFIG_DEBUG_S3C_UART != 0
-   add \rp, \rp, #(S3C2410_UART1_OFF * CONFIG_DEBUG_S3C_UART)
-   add \rv, \rv, #(S3C2410_UART1_OFF * CONFIG_DEBUG_S3C_UART)
-#endif
+   ldr \rp, = CONFIG_DEBUG_UART_PHYS
+   ldr \rv, = CONFIG_DEBUG_UART_VIRT
.endm
 
.macro  fifo_full_s3c2410 rd, rx
-- 

[PATCH 4/4] ARM: S3C24XX: move debug-macro.S into the common space

2014-04-24 Thread Heiko Stübner
Move debug-macro.S from mach/include to include/debug where all other common
debug macros are.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/Kconfig.debug   | 1 +
 .../{mach-s3c24xx/include/mach/debug-macro.S = include/debug/s3c24xx.S} | 0
 2 files changed, 1 insertion(+)
 rename arch/arm/{mach-s3c24xx/include/mach/debug-macro.S = 
include/debug/s3c24xx.S} (100%)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 2476f84..00d3ee6 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -996,6 +996,7 @@ config DEBUG_LL_INCLUDE
 DEBUG_IMX6SL_UART
default debug/msm.S if DEBUG_MSM_UART
default debug/omap2plus.S if DEBUG_OMAP2PLUS_UART
+   default debug/s3c24xx.S if DEBUG_S3C24XX_UART
default debug/sirf.S if DEBUG_SIRFPRIMA2_UART1 || 
DEBUG_SIRFMARCO_UART1
default debug/sti.S if DEBUG_STI_UART
default debug/tegra.S if DEBUG_TEGRA_UART
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 
b/arch/arm/include/debug/s3c24xx.S
similarity index 100%
rename from arch/arm/mach-s3c24xx/include/mach/debug-macro.S
rename to arch/arm/include/debug/s3c24xx.S
-- 
1.9.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


Re: [PATCH 0/2] Add generic cpu power control functions for exynos

2014-04-24 Thread Leela Krishna Amudala
Hi Abhilash,

If you are okay with this patchset you can rebase/merge it with your
mcpm patches.

Best Wishes,
Leela Krishna.

On Thu, Apr 24, 2014 at 3:24 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:

 Hi Abhilash and Leela,

 FYI I think you are working on similar patches.


 On 04/24/2014 11:31 AM, Leela Krishna Amudala wrote:
 This patchset adds the generic cpu power control functions for

 exynos based SoCs to power up/down and to know the status of the cpu.

 Note: This series has been rebased on 3.15-rc1 and tested on
 Exynos based Origen(Cortex-A9) and Arndale-octa(Cortex A7,A15) boards.

 Leela Krishna Amudala (2):
ARM: EXYNOS: Add generic cpu power control functions for all exynos
  based SoCs
ARM: EXYNOS: use generic exynos cpu power control functions

   arch/arm/mach-exynos/common.h   |3 +++
   arch/arm/mach-exynos/platsmp.c  |9 +++--
   arch/arm/mach-exynos/pm.c   |   36
 
   arch/arm/mach-exynos/regs-pmu.h |6 ++
   4 files changed, 48 insertions(+), 6 deletions(-)



 --
  http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

 Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
 http://twitter.com/#!/linaroorg Twitter |
 http://www.linaro.org/linaro-blog/ Blog

--
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/4] ARM: S3C24XX: trim down debug uart handling

2014-04-24 Thread Russell King - ARM Linux
On Thu, Apr 24, 2014 at 12:24:31PM +0200, Heiko Stübner wrote:
 +choice
 + prompt S3C24XX low-level debugging port type
 + depends on DEBUG_LL  ARCH_S3C24XX
 +
 + config DEBUG_S3C24XX_UART_S3C2440
 + bool S3C2440 uart type
 + help
 +   Select this if you're debugging S3C2416, S3C2440, S3C2442,
 +   S3C2443 or S3C2450 SoCs.
 +
 + config DEBUG_S3C24XX_UART_S3C2410
 + bool S3C2410 uart type
 + help
 +   Select this if you're debugging S3C2410 or S3C2412 SoCs.
 +endchoice

Why does this need to be a separate choice statement?  What's special
about S3C24XX?  Is there something wrong with the main choice statement
just above this where everyone else lists their debugging UART?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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: dts: Remove mau_pd node for Exynos5420

2014-04-24 Thread Tushar Behera
On 04/24/2014 03:36 PM, Tomasz Figa wrote:
 On 24.04.2014 11:07, Tushar Behera wrote:
 On 04/23/2014 03:43 PM, Kukjin Kim wrote:
 Tushar Behera wrote:

 On 22 April 2014 13:08, Alim Akhtar alim.akh...@gmail.com wrote:
 Hi Tushar

 On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
 tushar.beh...@linaro.org wrote:
 MAU powerdomain provides clocks for Audio sub-system block. This
 block
 comprises of the I2S audio controller, audio DMA blocks and Audio
 sub-system clock registers.

 Right now, there is no way to hook up power-domains with clock
 providers.
 During late boot when this power-domain gets disabled, we get
 following
 external abort.

 + Jonghwan Choi

 Well, this is not a perfect solution to support MAU power domain,
 it's true it is a problem right now though.

 In other words, this is just temporal fix for the problem.

 How about accessing clock stuff for audio sub-system with handling
 MAU power domain via generic IO power domain?


 + Tomasz Figa

 Existing power domain driver exynos4_pm_init_power_domain is registered
 with an arch_initcall whereas the clk-exynos-audss driver is registered
 with core_initcall. Hence even if add mau_pd node to clk-exynos-audss
 node, the binding with power-domain doesn't happen.
 
 I'd say core_initcall is way too early for clk-exynos-audss driver. It
 should be at most subsys_initcall. As far as I can see, all users of
 clocks provided by this driver (i.e. i2s) are probed at device_initcall
 level anyway.
 

It is also used by ADMA node, which gets probed.


 Alternately, if Tomasz's patches are applied [1], power-domain binding
 is successful. But because of the init order, clk-exynos-audss defers
 probe resulting in a kernel crash. Forcing clk-exynos-audss to register
 through arch_initcall() fixes this issue, but I am not sure if that is
 okay.
 
 If the driver crashes on deferred probe, then it's a bug and it should
 be fixed.
 

By the time clk-exynos-audss is getting called, mau_pd is already
disabled by power-domain driver. That is not getting enabled during
clk-exynos-audss probe. Am I missing something?


 Best regards,
 Tomasz


-- 
Tushar Behera
--
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/4] ARM: S3C24XX: trim down debug uart handling

2014-04-24 Thread Heiko Stübner
Am Donnerstag, 24. April 2014, 11:34:55 schrieb Russell King - ARM Linux:
 On Thu, Apr 24, 2014 at 12:24:31PM +0200, Heiko Stübner wrote:
  +choice
  +   prompt S3C24XX low-level debugging port type
  +   depends on DEBUG_LL  ARCH_S3C24XX
  +
  +   config DEBUG_S3C24XX_UART_S3C2440
  +   bool S3C2440 uart type
  +   help
  + Select this if you're debugging S3C2416, S3C2440, S3C2442,
  + S3C2443 or S3C2450 SoCs.
  +
  +   config DEBUG_S3C24XX_UART_S3C2410
  +   bool S3C2410 uart type
  +   help
  + Select this if you're debugging S3C2410 or S3C2412 SoCs.
  +endchoice
 
 Why does this need to be a separate choice statement?  What's special
 about S3C24XX?  Is there something wrong with the main choice statement
 just above this where everyone else lists their debugging UART?

The special case is that s3c24xx as architecture has two different uart types. 
Everything else is the same so I didn't want to duplicate the s3c_debug_uartX 
entries.

The other option would have been to duplicate these, like having

- s3c_debug_uart[0-3] for the more common s3c2440 type and
- s3c2410_debug_uart[0-3] for the named type

I guess, judging from your comment this would be better?
[or I'm just overlooking the obvious third way :-) ]


Heiko
--
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] ARM: dts: Add PMU reg node to exynos4210

2014-04-24 Thread Vikas Sajjan
+Tomasz


On Wed, Apr 2, 2014 at 1:32 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 This patch adds pmu regnode to exynos4210 dtsi to handle
 PMU register access via DT.

 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 ---
  arch/arm/boot/dts/exynos4210.dtsi |5 +
  1 file changed, 5 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index cacf614..0a2c0fe 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -81,6 +81,11 @@
 interrupts = 2 2, 3 2;
 };

 +   pmu_system_controller: system-controller@1002 {
 +   compatible = samsung,exynos4210-pmu, syscon;
 +   reg = 0x1002 0x5000;

Can we have 2 strings as compatible and these 2 strings are used by
2 different driver?

Because once syscon driver gets probed, exynos-pmu.c [1] driver will
never be probed.

The new PMU driver [1] completely relies on this. With just
exynos_defconfig, you will not notice this issue, since syscon is NOT
enabled by exynos_defconfig. When I enabled System Controller
Register R/W Based on Regmap in menuconfig, I could see PMU driver
[1] is NEVER probed.

Let me know, if I am missing something.

 [1] http://www.spinics.net/lists/arm-kernel/msg319750.html


 +   };
 +
 pinctrl_0: pinctrl@1140 {
 compatible = samsung,exynos4210-pinctrl;
 reg = 0x1140 0x1000;
 --
 1.7.10.4


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] ARM: dts: Add PMU reg node to exynos4210

2014-04-24 Thread Pankaj Dubey

Hi Vikas,

On 04/24/2014 08:59 PM, Vikas Sajjan wrote:

+Tomasz


On Wed, Apr 2, 2014 at 1:32 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:

This patch adds pmu regnode to exynos4210 dtsi to handle
PMU register access via DT.

Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
  arch/arm/boot/dts/exynos4210.dtsi |5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..0a2c0fe 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -81,6 +81,11 @@
 interrupts = 2 2, 3 2;
 };

+   pmu_system_controller: system-controller@1002 {
+   compatible = samsung,exynos4210-pmu, syscon;
+   reg = 0x1002 0x5000;

Can we have 2 strings as compatible and these 2 strings are used by
2 different driver?

Because once syscon driver gets probed, exynos-pmu.c [1] driver will
never be probed.

The new PMU driver [1] completely relies on this. With just
exynos_defconfig, you will not notice this issue, since syscon is NOT
enabled by exynos_defconfig. When I enabled System Controller
Register R/W Based on Regmap in menuconfig, I could see PMU driver
[1] is NEVER probed.

Let me know, if I am missing something.

  [1] http://www.spinics.net/lists/arm-kernel/msg319750.html


You are correct. We also missed this because SYSCON option was
not enabled in exynos_defconfig.
I noticed this during preparation of V2 when I planned to use
early_syscon_init [1] as suggested by Sylwester here [2].

In V2 I will take care of this. I hope soon I will be able to post second
version of this series, just waiting for testing and internal code review.

[1] https://lkml.org/lkml/2014/4/8/239
[2] https://lkml.org/lkml/2014/4/2/171




+   };
+
 pinctrl_0: pinctrl@1140 {
 compatible = samsung,exynos4210-pinctrl;
 reg = 0x1140 0x1000;
--
1.7.10.4


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
Best Regards,
Pankaj Dubey

--
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 v3 00/16] exynos5420: clock file cleanup

2014-04-24 Thread Shaik Ameer Basha
Many changes/fixes have been identified for clock file for exynos5420.
These include correct parents, bit fields, new clocks etc. Existing
files needs some correction in terms of names of the clock and
indentation. These issues are addressed in this patch series. It also
replaces the usage of enums with macro as clock ids.

This patch series is rebased on,
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master

This patch is also dependent on the following patch.
ARM: dts: add dt node for sss module for exynos5250/5420

Changes since v2:
-
1] Addressed review comments from Gerhard Sittig and Tomasz Figa.

Changes since v1:
-
1] Addressed review comments from Tomasz Figa.
http://www.spinics.net/lists/devicetree/msg16759.html
http://www.spinics.net/lists/devicetree/msg16760.html

Shaik Ameer Basha (16):
  clk: exynos5420: rename parent clocks
  clk: exynos5420: add clocks for ISP block
  clk: exynos5420: update clocks for GSCL and MSCL blocks
  clk: exynos5420: correct clock parents for mscl sysmmu
  clk: exynos5420: update clocks for G2D block
  clk: exynos5420: update clocks for DISP1 block
  clk: exynos5420: update clocks for PERIC block
  clk: exynos5420: update clocks for PERIS and GEN blocks
  clk: exynos5420: update clocks for WCORE block
  clk: exynos5420: update clocks for FSYS and FSYS2 blocks
  clk: exynos5420: correct sysmmu-mfc parent clocks
  clk: exynos5420: fix register offset for sclk_bpll
  clk: exynos5420: cleanup core and misc clocks
  clk: exynos5420: correct g3d parent clock
  clk: exynos5420: create clock ID for mout_sclk_vpll
  clk: exynos5420: add more registers to restore list

 arch/arm/boot/dts/exynos5420.dtsi  |   14 +-
 drivers/clk/samsung/clk-exynos5420.c   |  808 
 include/dt-bindings/clock/exynos5420.h |   33 +-
 3 files changed, 550 insertions(+), 305 deletions(-)
 mode change 100644 = 100755 drivers/clk/samsung/clk-exynos5420.c
 mode change 100644 = 100755 include/dt-bindings/clock/exynos5420.h

-- 
1.7.9.5

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


[PATCH v3 01/16] clk: exynos5420: rename parent clocks

2014-04-24 Thread Shaik Ameer Basha
This patch modifies the defined parent clock names as per the
exynos5420 datasheet.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c |  359 ++
 1 file changed, 187 insertions(+), 172 deletions(-)
 mode change 100644 = 100755 drivers/clk/samsung/clk-exynos5420.c

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
old mode 100644
new mode 100755
index 35311e1..389d4b1
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -217,85 +217,92 @@ static void exynos5420_clk_sleep_init(void) {}
 #endif
 
 /* list of all parent clocks */
-PNAME(mspll_cpu_p) = { sclk_cpll, sclk_dpll,
-   sclk_mpll, sclk_spll };
-PNAME(cpu_p)   = { mout_apll , mout_mspll_cpu };
-PNAME(kfc_p)   = { mout_kpll , mout_mspll_kfc };
-PNAME(apll_p)  = { fin_pll, fout_apll, };
-PNAME(bpll_p)  = { fin_pll, fout_bpll, };
-PNAME(cpll_p)  = { fin_pll, fout_cpll, };
-PNAME(dpll_p)  = { fin_pll, fout_dpll, };
-PNAME(epll_p)  = { fin_pll, fout_epll, };
-PNAME(ipll_p)  = { fin_pll, fout_ipll, };
-PNAME(kpll_p)  = { fin_pll, fout_kpll, };
-PNAME(mpll_p)  = { fin_pll, fout_mpll, };
-PNAME(rpll_p)  = { fin_pll, fout_rpll, };
-PNAME(spll_p)  = { fin_pll, fout_spll, };
-PNAME(vpll_p)  = { fin_pll, fout_vpll, };
-
-PNAME(group1_p)= { sclk_cpll, sclk_dpll, sclk_mpll };
-PNAME(group2_p)= { fin_pll, sclk_cpll, sclk_dpll, 
sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(group3_p)= { sclk_rpll, sclk_spll };
-PNAME(group4_p)= { sclk_ipll, sclk_dpll, sclk_mpll };
-PNAME(group5_p)= { sclk_vpll, sclk_dpll };
-
-PNAME(sw_aclk66_p) = { dout_aclk66, sclk_spll };
-PNAME(aclk66_peric_p)  = { fin_pll, mout_sw_aclk66 };
-
-PNAME(sw_aclk200_fsys_p) = { dout_aclk200_fsys, sclk_spll};
-PNAME(user_aclk200_fsys_p) = { fin_pll, mout_sw_aclk200_fsys };
-
-PNAME(sw_aclk200_fsys2_p) = { dout_aclk200_fsys2, sclk_spll};
-PNAME(user_aclk200_fsys2_p)= { fin_pll, mout_sw_aclk200_fsys2 };
-
-PNAME(sw_aclk200_p) = { dout_aclk200, sclk_spll};
-PNAME(aclk200_disp1_p) = { fin_pll, mout_sw_aclk200 };
-
-PNAME(sw_aclk400_mscl_p) = { dout_aclk400_mscl, sclk_spll};
-PNAME(user_aclk400_mscl_p) = { fin_pll, mout_sw_aclk400_mscl };
-
-PNAME(sw_aclk333_p) = { dout_aclk333, sclk_spll};
-PNAME(user_aclk333_p)  = { fin_pll, mout_sw_aclk333 };
-
-PNAME(sw_aclk166_p) = { dout_aclk166, sclk_spll};
-PNAME(user_aclk166_p)  = { fin_pll, mout_sw_aclk166 };
-
-PNAME(sw_aclk266_p) = { dout_aclk266, sclk_spll};
-PNAME(user_aclk266_p)  = { fin_pll, mout_sw_aclk266 };
-
-PNAME(sw_aclk333_432_gscl_p) = { dout_aclk333_432_gscl, sclk_spll};
-PNAME(user_aclk333_432_gscl_p) = { fin_pll, mout_sw_aclk333_432_gscl };
-
-PNAME(sw_aclk300_gscl_p) = { dout_aclk300_gscl, sclk_spll};
-PNAME(user_aclk300_gscl_p) = { fin_pll, mout_sw_aclk300_gscl };
-
-PNAME(sw_aclk300_disp1_p) = { dout_aclk300_disp1, sclk_spll};
-PNAME(user_aclk300_disp1_p)= { fin_pll, mout_sw_aclk300_disp1 };
-
-PNAME(sw_aclk300_jpeg_p) = { dout_aclk300_jpeg, sclk_spll};
-PNAME(user_aclk300_jpeg_p) = { fin_pll, mout_sw_aclk300_jpeg };
-
-PNAME(sw_aclk_g3d_p) = { dout_aclk_g3d, sclk_spll};
-PNAME(user_aclk_g3d_p) = { fin_pll, mout_sw_aclk_g3d };
-
-PNAME(sw_aclk266_g2d_p) = { dout_aclk266_g2d, sclk_spll};
-PNAME(user_aclk266_g2d_p)  = { fin_pll, mout_sw_aclk266_g2d };
-
-PNAME(sw_aclk333_g2d_p) = { dout_aclk333_g2d, sclk_spll};
-PNAME(user_aclk333_g2d_p)  = { fin_pll, mout_sw_aclk333_g2d };
-
-PNAME(audio0_p)= { fin_pll, cdclk0, sclk_dpll, sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(audio1_p)= { fin_pll, cdclk1, sclk_dpll, sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(audio2_p)= { fin_pll, cdclk2, sclk_dpll, sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(spdif_p) = { fin_pll, dout_audio0, dout_audio1, dout_audio2,
- spdif_extclk, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(hdmi_p)  = { dout_hdmi_pixel, sclk_hdmiphy };
-PNAME(maudio0_p)   = { fin_pll, maudio_clk, sclk_dpll, sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
+PNAME(mout_mspll_cpu_p) = {mout_sclk_cpll, mout_sclk_dpll,
+   mout_sclk_mpll, mout_sclk_spll};
+PNAME(mout_cpu_p) = {mout_apll , mout_mspll_cpu};
+PNAME(mout_kfc_p) = {mout_kpll , mout_mspll_kfc};
+PNAME(mout_apll_p) = {fin_pll, fout_apll};
+PNAME(mout_bpll_p) = {fin_pll, fout_bpll};
+PNAME(mout_cpll_p) = {fin_pll, fout_cpll};
+PNAME(mout_dpll_p) = {fin_pll, fout_dpll};
+PNAME(mout_epll_p) = {fin_pll, fout_epll};
+PNAME(mout_ipll_p) = 

[PATCH v3 06/16] clk: exynos5420: update clocks for DISP1 block

2014-04-24 Thread Shaik Ameer Basha
This patch corrects some child-parent clock relationships,
and updates the clocks according to the latest datasheet.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c   |   44 
 include/dt-bindings/clock/exynos5420.h |3 ++-
 2 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index ab07299..cd75661 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -61,6 +61,7 @@
 #define SRC_TOP10  0x10280
 #define SRC_TOP11  0x10284
 #define SRC_TOP12  0x10288
+#define SRC_MASK_TOP2  0x10308
 #defineSRC_MASK_DISP10 0x1032c
 #define SRC_MASK_FSYS  0x10340
 #define SRC_MASK_PERIC00x10350
@@ -100,6 +101,7 @@
 #define GATE_TOP_SCLK_MAU  0x1083c
 #define GATE_TOP_SCLK_FSYS 0x10840
 #define GATE_TOP_SCLK_PERIC0x10850
+#define TOP_SPARE2 0x10b08
 #define BPLL_LOCK  0x20010
 #define BPLL_CON0  0x20110
 #define SRC_CDREX  0x20200
@@ -146,6 +148,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SRC_TOP10,
SRC_TOP11,
SRC_TOP12,
+   SRC_MASK_TOP2,
SRC_MASK_DISP10,
SRC_MASK_FSYS,
SRC_MASK_PERIC0,
@@ -186,6 +189,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_TOP_SCLK_MAU,
GATE_TOP_SCLK_FSYS,
GATE_TOP_SCLK_PERIC,
+   TOP_SPARE2,
SRC_CDREX,
SRC_KFC,
DIV_KFC0,
@@ -252,6 +256,7 @@ PNAME(mout_group3_p) = {mout_sclk_rpll, mout_sclk_spll};
 PNAME(mout_group4_p) = {mout_sclk_ipll, mout_sclk_dpll, mout_sclk_mpll};
 PNAME(mout_group5_p) = {mout_sclk_vpll, mout_sclk_dpll};
 
+PNAME(mout_fimd1_final_p) = {mout_fimd1, mout_fimd1_opt};
 PNAME(mout_sw_aclk66_p)= {dout_aclk66, mout_sclk_spll};
 PNAME(mout_user_aclk66_peric_p) = {fin_pll, mout_sw_aclk66};
 
@@ -271,7 +276,7 @@ PNAME(mout_sw_aclk333_432_isp_p) = {dout_aclk333_432_isp, 
mout_sclk_spll};
 PNAME(mout_user_aclk333_432_isp_p) = {fin_pll, mout_sw_aclk333_432_isp};
 
 PNAME(mout_sw_aclk200_p) = {dout_aclk200, mout_sclk_spll};
-PNAME(mout_aclk200_disp1_p) = {fin_pll, mout_sw_aclk200};
+PNAME(mout_user_aclk200_disp1_p) = {fin_pll, mout_sw_aclk200};
 
 PNAME(mout_sw_aclk400_mscl_p) = {dout_aclk400_mscl, mout_sclk_spll};
 PNAME(mout_user_aclk400_mscl_p)= {fin_pll, mout_sw_aclk400_mscl};
@@ -293,7 +298,9 @@ PNAME(mout_sw_aclk300_gscl_p) = {dout_aclk300_gscl, 
mout_sclk_spll};
 PNAME(mout_user_aclk300_gscl_p)= {fin_pll, mout_sw_aclk300_gscl};
 
 PNAME(mout_sw_aclk300_disp1_p) = {dout_aclk300_disp1, mout_sclk_spll};
+PNAME(mout_sw_aclk400_disp1_p) = {dout_aclk400_disp1, mout_sclk_spll};
 PNAME(mout_user_aclk300_disp1_p) = {fin_pll, mout_sw_aclk300_disp1};
+PNAME(mout_user_aclk400_disp1_p) = {fin_pll, mout_sw_aclk400_disp1};
 
 PNAME(mout_sw_aclk300_jpeg_p) = {dout_aclk300_jpeg, mout_sclk_spll};
 PNAME(mout_user_aclk300_jpeg_p) = {fin_pll, mout_sw_aclk300_jpeg};
@@ -373,7 +380,8 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
 
MUX(0, mout_user_aclk400_mscl, mout_user_aclk400_mscl_p,
SRC_TOP3, 4, 1),
-   MUX(0, mout_aclk200_disp1, mout_aclk200_disp1_p, SRC_TOP3, 8, 1),
+   MUX(0, mout_user_aclk200_disp1, mout_user_aclk200_disp1_p,
+   SRC_TOP3, 8, 1),
MUX(0, mout_user_aclk200_fsys2, mout_user_aclk200_fsys2_p,
SRC_TOP3, 12, 1),
MUX(0, mout_user_aclk200_fsys, mout_user_aclk200_fsys_p,
@@ -443,6 +451,10 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, mout_dp1, mout_group2_p, SRC_DISP10, 20, 3),
MUX(0, mout_pixel, mout_group2_p, SRC_DISP10, 24, 3),
MUX(CLK_MOUT_HDMI, mout_hdmi, mout_hdmi_p, SRC_DISP10, 28, 1),
+   MUX_F(0, mout_fimd1_opt, mout_group2_p,
+   SRC_DISP10, 8, 3, CLK_SET_RATE_PARENT, 0),
+   MUX_F(0, mout_fimd1_final, mout_fimd1_final_p,
+   TOP_SPARE2, 8, 1, CLK_SET_RATE_PARENT, 0),
 
/* MAU Block */
MUX(0, mout_maudio0, mout_maudio0_p, SRC_MAU, 28, 3),
@@ -486,6 +498,11 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
SRC_TOP4, 4, 1),
MUX(0, mout_user_aclk266_isp, mout_user_aclk266_isp_p,
SRC_TOP4, 16, 1),
+   MUX(0, mout_aclk400_disp1, mout_group1_p, SRC_TOP2, 4, 2),
+   MUX(0, mout_sw_aclk400_disp1, mout_sw_aclk400_disp1_p,
+   SRC_TOP12, 4, 1),
+   MUX(0, mout_user_aclk400_disp1, mout_user_aclk400_disp1_p,
+   SRC_TOP5, 0, 1),
 
/* ISP Block */
MUX(0, mout_pwm_isp, mout_group2_p, SRC_ISP, 24, 3),
@@ -519,15 +536,16 @@ static struct samsung_div_clock 

[PATCH v3 07/16] clk: exynos5420: update clocks for PERIC block

2014-04-24 Thread Shaik Ameer Basha
This patch includes,
1] renaming of the HSI2C clocks
2] renaming of spi clocks according to the datasheet
3] fixes for child-parent relationships
4] adding of more clocks related to PERIC block

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 arch/arm/boot/dts/exynos5420.dtsi  |   14 +++---
 drivers/clk/samsung/clk-exynos5420.c   |   73 
 include/dt-bindings/clock/exynos5420.h |   14 +++---
 3 files changed, 50 insertions(+), 51 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..67ba2c5 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -549,7 +549,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c4_hs_bus;
-   clocks = clock CLK_I2C4;
+   clocks = clock CLK_USI0;
clock-names = hsi2c;
status = disabled;
};
@@ -562,7 +562,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c5_hs_bus;
-   clocks = clock CLK_I2C5;
+   clocks = clock CLK_USI1;
clock-names = hsi2c;
status = disabled;
};
@@ -575,7 +575,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c6_hs_bus;
-   clocks = clock CLK_I2C6;
+   clocks = clock CLK_USI2;
clock-names = hsi2c;
status = disabled;
};
@@ -588,7 +588,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c7_hs_bus;
-   clocks = clock CLK_I2C7;
+   clocks = clock CLK_USI3;
clock-names = hsi2c;
status = disabled;
};
@@ -601,7 +601,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c8_hs_bus;
-   clocks = clock CLK_I2C8;
+   clocks = clock CLK_USI4;
clock-names = hsi2c;
status = disabled;
};
@@ -614,7 +614,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c9_hs_bus;
-   clocks = clock CLK_I2C9;
+   clocks = clock CLK_USI5;
clock-names = hsi2c;
status = disabled;
};
@@ -627,7 +627,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c10_hs_bus;
-   clocks = clock CLK_I2C10;
+   clocks = clock CLK_USI6;
clock-names = hsi2c;
status = disabled;
};
diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index cd75661..b4cf4c1 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -95,6 +95,7 @@
 #define GATE_IP_DISP1  0x10928
 #define GATE_IP_G3D0x10930
 #define GATE_IP_GEN0x10934
+#define GATE_IP_PERIC  0x10950
 #define GATE_IP_MSCL   0x10970
 #define GATE_TOP_SCLK_GSCL 0x10820
 #define GATE_TOP_SCLK_DISP10x10828
@@ -183,6 +184,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_IP_DISP1,
GATE_IP_G3D,
GATE_IP_GEN,
+   GATE_IP_PERIC,
GATE_IP_MSCL,
GATE_TOP_SCLK_GSCL,
GATE_TOP_SCLK_DISP1,
@@ -588,9 +590,9 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, dout_audio2, mout_audio2, DIV_PERIC3, 28, 4),
 
/* SPI Pre-Ratio */
-   DIV(0, dout_pre_spi0, dout_spi0, DIV_PERIC4, 8, 8),
-   DIV(0, dout_pre_spi1, dout_spi1, DIV_PERIC4, 16, 8),
-   DIV(0, dout_pre_spi2, dout_spi2, DIV_PERIC4, 24, 8),
+   DIV(0, dout_spi0_pre, dout_spi0, DIV_PERIC4, 8, 8),
+   DIV(0, dout_spi1_pre, dout_spi1, DIV_PERIC4, 16, 8),
+   DIV(0, dout_spi2_pre, dout_spi2, DIV_PERIC4, 24, 8),
 
/* GSCL Block */
DIV(0, dout_gscl_blk_300, mout_user_aclk300_gscl,
@@ -641,8 +643,8 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_BUS_TOP, 9, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk66_psgen, mout_aclk66_psgen,
GATE_BUS_TOP, 10, CLK_IGNORE_UNUSED, 0),
-   GATE(0, aclk66_peric, mout_aclk66_peric,
-   GATE_BUS_TOP, 11, 0, 0),
+   GATE(0, aclk66_peric, mout_user_aclk66_peric,
+   GATE_BUS_TOP, 11, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk166, mout_user_aclk166,
GATE_BUS_TOP, 14, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk333, mout_aclk333,
@@ -657,11 +659,11 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_TOP_SCLK_PERIC, 

[PATCH v3 08/16] clk: exynos5420: update clocks for PERIS and GEN blocks

2014-04-24 Thread Shaik Ameer Basha
This patch fixes some parent-child relationships according
to the latest datasheet and adds more clocks related to
PERIS and GEN blocks.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c   |   70 
 include/dt-bindings/clock/exynos5420.h |5 +++
 2 files changed, 48 insertions(+), 27 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index b4cf4c1..6ad87d1 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -83,6 +83,7 @@
 #define SCLK_DIV_ISP1  0x10584
 #define DIV2_RATIO00x10590
 #define GATE_BUS_TOP   0x10700
+#define GATE_BUS_GEN   0x1073c
 #define GATE_BUS_FSYS0 0x10740
 #define GATE_BUS_PERIC 0x10750
 #define GATE_BUS_PERIC10x10754
@@ -96,6 +97,7 @@
 #define GATE_IP_G3D0x10930
 #define GATE_IP_GEN0x10934
 #define GATE_IP_PERIC  0x10950
+#define GATE_IP_PERIS  0x10960
 #define GATE_IP_MSCL   0x10970
 #define GATE_TOP_SCLK_GSCL 0x10820
 #define GATE_TOP_SCLK_DISP10x10828
@@ -172,6 +174,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SCLK_DIV_ISP1,
DIV2_RATIO0,
GATE_BUS_TOP,
+   GATE_BUS_GEN,
GATE_BUS_FSYS0,
GATE_BUS_PERIC,
GATE_BUS_PERIC1,
@@ -185,6 +188,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_IP_G3D,
GATE_IP_GEN,
GATE_IP_PERIC,
+   GATE_IP_PERIS,
GATE_IP_MSCL,
GATE_TOP_SCLK_GSCL,
GATE_TOP_SCLK_DISP1,
@@ -602,6 +606,10 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
/* MSCL Blk */
DIV(0, dout_mscl_blk, aclk400_mscl, DIV2_RATIO0, 28, 2),
 
+   /* PSGEN */
+   DIV(0, dout_gen_blk, mout_user_aclk266, DIV2_RATIO0, 8, 1),
+   DIV(0, dout_jpg_blk, aclk166, DIV2_RATIO0, 20, 1),
+
/* ISP Block */
DIV(0, dout_aclk400_isp, mout_aclk400_isp, DIV_TOP0, 0, 3),
DIV(0, dout_aclk333_432_isp0, mout_aclk333_432_isp0,
@@ -620,9 +628,7 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
 };
 
 static struct samsung_gate_clock exynos5420_gate_clks[] __initdata = {
-   /* TODO: Re-verify the CG bits for all the gate clocks */
-   GATE_A(CLK_MCT, pclk_st, aclk66_psgen, GATE_BUS_PERIS1, 2, 0, 0,
-   mct),
+   GATE(CLK_MCT, mct, aclk66_psgen, GATE_IP_PERIS, 18, 0, 0),
 
GATE(0, aclk200_fsys, mout_user_aclk200_fsys,
GATE_BUS_FSYS0, 9, CLK_IGNORE_UNUSED, 0),
@@ -769,27 +775,30 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_SPDIF, spdif, aclk66_peric, GATE_IP_PERIC, 26, 0, 0),
 
GATE(CLK_CHIPID, chipid, aclk66_psgen,
-   GATE_BUS_PERIS0, 12, CLK_IGNORE_UNUSED, 0),
+   GATE_IP_PERIS, 0, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SYSREG, sysreg, aclk66_psgen,
-   GATE_BUS_PERIS0, 13, CLK_IGNORE_UNUSED, 0),
-   GATE(CLK_TZPC0, tzpc0, aclk66_psgen, GATE_BUS_PERIS0, 18, 0, 0),
-   GATE(CLK_TZPC1, tzpc1, aclk66_psgen, GATE_BUS_PERIS0, 19, 0, 0),
-   GATE(CLK_TZPC2, tzpc2, aclk66_psgen, GATE_BUS_PERIS0, 20, 0, 0),
-   GATE(CLK_TZPC3, tzpc3, aclk66_psgen, GATE_BUS_PERIS0, 21, 0, 0),
-   GATE(CLK_TZPC4, tzpc4, aclk66_psgen, GATE_BUS_PERIS0, 22, 0, 0),
-   GATE(CLK_TZPC5, tzpc5, aclk66_psgen, GATE_BUS_PERIS0, 23, 0, 0),
-   GATE(CLK_TZPC6, tzpc6, aclk66_psgen, GATE_BUS_PERIS0, 24, 0, 0),
-   GATE(CLK_TZPC7, tzpc7, aclk66_psgen, GATE_BUS_PERIS0, 25, 0, 0),
-   GATE(CLK_TZPC8, tzpc8, aclk66_psgen, GATE_BUS_PERIS0, 26, 0, 0),
-   GATE(CLK_TZPC9, tzpc9, aclk66_psgen, GATE_BUS_PERIS0, 27, 0, 0),
-
-   GATE(CLK_HDMI_CEC, hdmi_cec, aclk66_psgen, GATE_BUS_PERIS1, 0, 0,
-   0),
+   GATE_IP_PERIS, 1, CLK_IGNORE_UNUSED, 0),
+   GATE(CLK_TZPC0, tzpc0, aclk66_psgen, GATE_IP_PERIS, 6, 0, 0),
+   GATE(CLK_TZPC1, tzpc1, aclk66_psgen, GATE_IP_PERIS, 7, 0, 0),
+   GATE(CLK_TZPC2, tzpc2, aclk66_psgen, GATE_IP_PERIS, 8, 0, 0),
+   GATE(CLK_TZPC3, tzpc3, aclk66_psgen, GATE_IP_PERIS, 9, 0, 0),
+   GATE(CLK_TZPC4, tzpc4, aclk66_psgen, GATE_IP_PERIS, 10, 0, 0),
+   GATE(CLK_TZPC5, tzpc5, aclk66_psgen, GATE_IP_PERIS, 11, 0, 0),
+   GATE(CLK_TZPC6, tzpc6, aclk66_psgen, GATE_IP_PERIS, 12, 0, 0),
+   GATE(CLK_TZPC7, tzpc7, aclk66_psgen, GATE_IP_PERIS, 13, 0, 0),
+   GATE(CLK_TZPC8, tzpc8, aclk66_psgen, GATE_IP_PERIS, 14, 0, 0),
+   GATE(CLK_TZPC9, tzpc9, aclk66_psgen, GATE_IP_PERIS, 15, 0, 0),
+
+   /* GATE_IP_PERIS doesn't list TZPC10,11 */
+   GATE(CLK_TZPC10, tzpc10, aclk66_psgen, GATE_BUS_GEN, 30, 0, 0),
+   GATE(CLK_TZPC11, tzpc11, aclk66_psgen, GATE_BUS_GEN, 31, 0, 0),
+
+   

[PATCH v3 09/16] clk: exynos5420: update clocks for WCORE block

2014-04-24 Thread Shaik Ameer Basha
This patch adds missing clocks from WCORE block.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c |   28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 6ad87d1..d9996dd 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -89,6 +89,7 @@
 #define GATE_BUS_PERIC10x10754
 #define GATE_BUS_PERIS00x10760
 #define GATE_BUS_PERIS10x10764
+#define GATE_BUS_NOC   0x10770
 #define GATE_TOP_SCLK_ISP  0x10870
 #define GATE_IP_GSCL0  0x10910
 #define GATE_IP_GSCL1  0x10920
@@ -180,6 +181,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_BUS_PERIC1,
GATE_BUS_PERIS0,
GATE_BUS_PERIS1,
+   GATE_BUS_NOC,
GATE_TOP_SCLK_ISP,
GATE_IP_GSCL0,
GATE_IP_GSCL1,
@@ -271,6 +273,13 @@ PNAME(mout_user_aclk200_fsys_p)= {fin_pll, 
mout_sw_aclk200_fsys};
 
 PNAME(mout_sw_aclk200_fsys2_p) = {dout_aclk200_fsys2, mout_sclk_spll};
 PNAME(mout_user_aclk200_fsys2_p) = {fin_pll, mout_sw_aclk200_fsys2};
+PNAME(mout_sw_aclk100_noc_p) = {dout_aclk100_noc, mout_sclk_spll};
+PNAME(mout_user_aclk100_noc_p) = {fin_pll, mout_sw_aclk100_noc};
+
+PNAME(mout_sw_aclk400_wcore_p) = {dout_aclk400_wcore, mout_sclk_spll};
+PNAME(mout_aclk400_wcore_bpll_p) = {mout_aclk400_wcore, sclk_bpll};
+PNAME(mout_user_aclk400_wcore_p) = {fin_pll, mout_sw_aclk400_wcore};
+
 PNAME(mout_sw_aclk400_isp_p) = {dout_aclk400_isp, mout_sclk_spll};
 PNAME(mout_user_aclk400_isp_p) = {fin_pll, mout_sw_aclk400_isp};
 
@@ -486,6 +495,18 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, mout_spi0, mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, mout_spi1, mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, mout_spi2, mout_group2_p, SRC_PERIC1, 28, 3),
+   MUX(0, mout_aclk100_noc, mout_group1_p, SRC_TOP0, 20, 2),
+   MUX(0, mout_sw_aclk100_noc, mout_sw_aclk100_noc_p,
+   SRC_TOP10, 20, 1),
+   MUX(0, mout_user_aclk100_noc, mout_user_aclk100_noc_p,
+   SRC_TOP3, 20, 1),
+   MUX(0, mout_aclk400_wcore, mout_group1_p, SRC_TOP0, 16, 2),
+   MUX(0, mout_aclk400_wcore_bpll, mout_aclk400_wcore_bpll_p,
+   TOP_SPARE2, 4, 1),
+   MUX(0, mout_sw_aclk400_wcore, mout_sw_aclk400_wcore_p,
+   SRC_TOP10, 16, 1),
+   MUX(0, mout_user_aclk400_wcore, mout_user_aclk400_wcore_p,
+   SRC_TOP3, 16, 1),
MUX(0, mout_aclk400_isp, mout_group1_p, SRC_TOP0, 0, 2),
MUX(0, mout_sw_aclk400_isp, mout_sw_aclk400_isp_p,
SRC_TOP10, 0, 1),
@@ -553,6 +574,10 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, dout_disp1_blk, aclk200_disp1, DIV2_RATIO0, 16, 2),
DIV(0, dout_aclk400_disp1, mout_aclk400_disp1, DIV_TOP2, 4, 3),
 
+   DIV(0, dout_aclk100_noc, mout_aclk100_noc, DIV_TOP0, 20, 3),
+   DIV(0, dout_aclk400_wcore, mout_aclk400_wcore_bpll,
+   DIV_TOP0, 16, 3),
+
/* Audio Block */
DIV(0, dout_maudio0, mout_maudio0, DIV_MAU, 20, 4),
DIV(0, dout_maupcm0, dout_maudio0, DIV_MAU, 24, 8),
@@ -867,6 +892,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_IP_MSCL, 10, 0, 0),
GATE(CLK_SMMU_MIXER, smmu_mixer, aclk200_disp1,
GATE_IP_DISP1, 9, 0, 0),
+   /* aclk266 also gates other IPs in psgen. It should not be gated. */
+   GATE(0, aclk266, mout_user_aclk266,
+   GATE_BUS_NOC, 22, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk200_disp1, mout_user_aclk200_disp1,
GATE_BUS_TOP, 18, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk300_disp1, mout_user_aclk300_disp1,
-- 
1.7.9.5

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


[PATCH v3 10/16] clk: exynos5420: update clocks for FSYS and FSYS2 blocks

2014-04-24 Thread Shaik Ameer Basha
This patch adds more clocks from FSYS and FSYS2 blocks
and uses GATE_IP_* registers for gating IPs.

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c |   37 +++---
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index d9996dd..d8fe6d8 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -85,6 +85,7 @@
 #define GATE_BUS_TOP   0x10700
 #define GATE_BUS_GEN   0x1073c
 #define GATE_BUS_FSYS0 0x10740
+#define GATE_BUS_FSYS2 0x10748
 #define GATE_BUS_PERIC 0x10750
 #define GATE_BUS_PERIC10x10754
 #define GATE_BUS_PERIS00x10760
@@ -97,6 +98,7 @@
 #define GATE_IP_DISP1  0x10928
 #define GATE_IP_G3D0x10930
 #define GATE_IP_GEN0x10934
+#define GATE_IP_FSYS   0x10944
 #define GATE_IP_PERIC  0x10950
 #define GATE_IP_PERIS  0x10960
 #define GATE_IP_MSCL   0x10970
@@ -177,6 +179,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_BUS_TOP,
GATE_BUS_GEN,
GATE_BUS_FSYS0,
+   GATE_BUS_FSYS2,
GATE_BUS_PERIC,
GATE_BUS_PERIC1,
GATE_BUS_PERIS0,
@@ -189,6 +192,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_IP_DISP1,
GATE_IP_G3D,
GATE_IP_GEN,
+   GATE_IP_FSYS,
GATE_IP_PERIC,
GATE_IP_PERIS,
GATE_IP_MSCL,
@@ -269,6 +273,8 @@ PNAME(mout_sw_aclk66_p) = {dout_aclk66, 
mout_sclk_spll};
 PNAME(mout_user_aclk66_peric_p) = {fin_pll, mout_sw_aclk66};
 
 PNAME(mout_sw_aclk200_fsys_p) = {dout_aclk200_fsys, mout_sclk_spll};
+PNAME(mout_sw_pclk200_fsys_p) = {dout_pclk200_fsys, mout_sclk_spll};
+PNAME(mout_user_pclk200_fsys_p)= {fin_pll, mout_sw_pclk200_fsys};
 PNAME(mout_user_aclk200_fsys_p)= {fin_pll, mout_sw_aclk200_fsys};
 
 PNAME(mout_sw_aclk200_fsys2_p) = {dout_aclk200_fsys2, mout_sclk_spll};
@@ -481,6 +487,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, mout_mmc2, mout_group2_p, SRC_FSYS, 16, 3),
MUX(0, mout_usbd300, mout_group2_p, SRC_FSYS, 20, 3),
MUX(0, mout_unipro, mout_group2_p, SRC_FSYS, 24, 3),
+   MUX(0, mout_mphy_refclk, mout_group2_p, SRC_FSYS, 28, 3),
 
/* PERIC Block */
MUX(0, mout_uart0, mout_group2_p, SRC_PERIC0, 4, 3),
@@ -495,6 +502,11 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, mout_spi0, mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, mout_spi1, mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, mout_spi2, mout_group2_p, SRC_PERIC1, 28, 3),
+   MUX(0, mout_pclk200_fsys, mout_group1_p, SRC_TOP0, 24, 2),
+   MUX(0, mout_sw_pclk200_fsys, mout_sw_pclk200_fsys_p,
+   SRC_TOP10, 24, 1),
+   MUX(0, mout_user_pclk200_fsys, mout_user_pclk200_fsys_p,
+   SRC_TOP3, 24, 1),
MUX(0, mout_aclk100_noc, mout_group1_p, SRC_TOP0, 20, 2),
MUX(0, mout_sw_aclk100_noc, mout_sw_aclk100_noc_p,
SRC_TOP10, 20, 1),
@@ -594,6 +606,7 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, dout_mmc2, mout_mmc2, DIV_FSYS1, 20, 10),
 
DIV(0, dout_unipro, mout_unipro, DIV_FSYS2, 24, 8),
+   DIV(0, dout_mphy_refclk, mout_mphy_refclk, DIV_FSYS2, 16, 8),
 
/* UART and PWM */
DIV(0, dout_uart0, mout_uart0, DIV_PERIC0, 8, 4),
@@ -720,12 +733,12 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_SCLK_USBPHY300, sclk_usbphy300, dout_usbphy300,
GATE_TOP_SCLK_FSYS, 8, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_USBD300, sclk_usbd300, dout_usbd300,
-   GATE_TOP_SCLK_FSYS, 9, CLK_SET_RATE_PARENT, 0),
+   GATE_TOP_SCLK_FSYS, 9, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_USBD301, sclk_usbd301, dout_usbd301,
-   GATE_TOP_SCLK_FSYS, 10, CLK_SET_RATE_PARENT, 0),
+   GATE_TOP_SCLK_FSYS, 10, CLK_IGNORE_UNUSED, 0),
 
-   GATE(CLK_SCLK_USBD301, sclk_unipro, dout_unipro,
-   SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
+   GATE(CLK_SCLK_UNIPRO, sclk_unipro, dout_unipro,
+   GATE_IP_FSYS, 23, CLK_SET_RATE_PARENT, 0),
 
GATE(CLK_SCLK_GSCL_WA, sclk_gscl_wa, mout_user_aclk333_432_gscl,
GATE_TOP_SCLK_GSCL, 6, CLK_SET_RATE_PARENT, 0),
@@ -754,15 +767,15 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_PDMA0, pdma0, aclk200_fsys, GATE_BUS_FSYS0, 1, 0, 0),
GATE(CLK_PDMA1, pdma1, aclk200_fsys, GATE_BUS_FSYS0, 2, 0, 0),
GATE(CLK_UFS, ufs, aclk200_fsys2, GATE_BUS_FSYS0, 3, 0, 0),
-   GATE(CLK_RTIC, rtic, aclk200_fsys, GATE_BUS_FSYS0, 5, 0, 0),
-   GATE(CLK_MMC0, mmc0, aclk200_fsys2, GATE_BUS_FSYS0, 12, 0, 

[PATCH v3 11/16] clk: exynos5420: correct sysmmu-mfc parent clocks

2014-04-24 Thread Shaik Ameer Basha
This patch corrects the wrong parent-child relationship
between sysmmu-mfc clocks.

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index d8fe6d8..6daf739 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -82,6 +82,7 @@
 #define SCLK_DIV_ISP0  0x10580
 #define SCLK_DIV_ISP1  0x10584
 #define DIV2_RATIO00x10590
+#define DIV4_RATIO 0x105a0
 #define GATE_BUS_TOP   0x10700
 #define GATE_BUS_GEN   0x1073c
 #define GATE_BUS_FSYS0 0x10740
@@ -176,6 +177,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SCLK_DIV_ISP0,
SCLK_DIV_ISP1,
DIV2_RATIO0,
+   DIV4_RATIO,
GATE_BUS_TOP,
GATE_BUS_GEN,
GATE_BUS_FSYS0,
@@ -636,6 +638,9 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, dout_spi1_pre, dout_spi1, DIV_PERIC4, 16, 8),
DIV(0, dout_spi2_pre, dout_spi2, DIV_PERIC4, 24, 8),
 
+   /* Mfc Blk */
+   DIV(0, dout_mfc_blk, mout_user_aclk333, DIV4_RATIO, 0, 2),
+
/* GSCL Block */
DIV(0, dout_gscl_blk_300, mout_user_aclk300_gscl,
DIV2_RATIO0, 4, 2),
@@ -873,8 +878,8 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_IP_DISP1, 8, 0, 0),
 
GATE(CLK_MFC, mfc, aclk333, GATE_IP_MFC, 0, 0, 0),
-   GATE(CLK_SMMU_MFCL, smmu_mfcl, aclk333, GATE_IP_MFC, 1, 0, 0),
-   GATE(CLK_SMMU_MFCR, smmu_mfcr, aclk333, GATE_IP_MFC, 2, 0, 0),
+   GATE(CLK_SMMU_MFCL, smmu_mfcl, dout_mfc_blk, GATE_IP_MFC, 1, 0, 0),
+   GATE(CLK_SMMU_MFCR, smmu_mfcr, dout_mfc_blk, GATE_IP_MFC, 2, 0, 0),
 
GATE(CLK_G3D, g3d, aclkg3d, GATE_IP_G3D, 9, 0, 0),
 
-- 
1.7.9.5

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


[PATCH v3 12/16] clk: exynos5420: fix register offset for sclk_bpll

2014-04-24 Thread Shaik Ameer Basha
This patch fixes the wrong register offset for sclk_bpll clock.

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 6daf739..3afc112 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -111,7 +111,6 @@
 #define TOP_SPARE2 0x10b08
 #define BPLL_LOCK  0x20010
 #define BPLL_CON0  0x20110
-#define SRC_CDREX  0x20200
 #define KPLL_LOCK  0x28000
 #define KPLL_CON0  0x28100
 #define SRC_KFC0x28200
@@ -204,7 +203,6 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_TOP_SCLK_FSYS,
GATE_TOP_SCLK_PERIC,
TOP_SPARE2,
-   SRC_CDREX,
SRC_KFC,
DIV_KFC0,
 };
@@ -380,7 +378,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, mout_kpll, mout_kpll_p, SRC_KFC, 0, 1),
MUX(0, mout_kfc, mout_kfc_p, SRC_KFC, 16, 1),
 
-   MUX(0, sclk_bpll, mout_bpll_p, SRC_CDREX, 0, 1),
+   MUX(0, sclk_bpll, mout_bpll_p, TOP_SPARE2, 0, 1),
 
MUX_A(0, mout_aclk400_mscl, mout_group1_p,
SRC_TOP0, 4, 2, aclk400_mscl),
-- 
1.7.9.5

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


[PATCH v3 13/16] clk: exynos5420: cleanup core and misc clocks

2014-04-24 Thread Shaik Ameer Basha
This patch renames some of the clocks according to the
datasheet. It also adds and updates some core and misc
clocks.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c   |   29 +++--
 include/dt-bindings/clock/exynos5420.h |3 +++
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 3afc112..0323b34 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -62,7 +62,8 @@
 #define SRC_TOP11  0x10284
 #define SRC_TOP12  0x10288
 #define SRC_MASK_TOP2  0x10308
-#defineSRC_MASK_DISP10 0x1032c
+#define SRC_MASK_DISP100x1032c
+#define SRC_MASK_MAU   0x10334
 #define SRC_MASK_FSYS  0x10340
 #define SRC_MASK_PERIC00x10350
 #define SRC_MASK_PERIC10x10354
@@ -271,6 +272,7 @@ PNAME(mout_group5_p) = {mout_sclk_vpll, mout_sclk_dpll};
 PNAME(mout_fimd1_final_p) = {mout_fimd1, mout_fimd1_opt};
 PNAME(mout_sw_aclk66_p)= {dout_aclk66, mout_sclk_spll};
 PNAME(mout_user_aclk66_peric_p) = {fin_pll, mout_sw_aclk66};
+PNAME(mout_user_aclk66_gpio_p) = {mout_sw_aclk66, ffactor_sw_aclk66};
 
 PNAME(mout_sw_aclk200_fsys_p) = {dout_aclk200_fsys, mout_sclk_spll};
 PNAME(mout_sw_pclk200_fsys_p) = {dout_pclk200_fsys, mout_sclk_spll};
@@ -351,6 +353,8 @@ PNAME(mout_hdmi_p) = {dout_hdmi_pixel, sclk_hdmiphy};
 PNAME(mout_maudio0_p) = {fin_pll, maudio_clk, mout_sclk_dpll,
 mout_sclk_mpll, mout_sclk_spll, mout_sclk_ipll,
 mout_sclk_epll, mout_sclk_rpll};
+PNAME(mout_mau_epll_clk_p) = {mout_sclk_epll, mout_sclk_dpll,
+   mout_sclk_mpll, mout_sclk_spll};
 
 /* fixed rate clocks generated outside the soc */
 static struct samsung_fixed_rate_clock exynos5420_fixed_rate_ext_clks[] 
__initdata = {
@@ -367,7 +371,8 @@ static struct samsung_fixed_rate_clock 
exynos5420_fixed_rate_clks[] __initdata =
 };
 
 static struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[] 
__initdata = {
-   FFACTOR(0, sclk_hsic_12m, fin_pll, 1, 2, 0),
+   FFACTOR(0, ffactor_hsic_12m, fin_pll, 1, 2, 0),
+   FFACTOR(0, ffactor_sw_aclk66, mout_sw_aclk66, 1, 2, 0),
 };
 
 static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
@@ -478,7 +483,8 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
TOP_SPARE2, 8, 1, CLK_SET_RATE_PARENT, 0),
 
/* MAU Block */
-   MUX(0, mout_maudio0, mout_maudio0_p, SRC_MAU, 28, 3),
+   MUX_F(CLK_MOUT_MAUDIO0, mout_maudio0, mout_maudio0_p, SRC_MAU, 28, 3,
+   CLK_SET_RATE_PARENT, 0),
 
/* FSYS Block */
MUX(0, mout_usbd301, mout_group2_p, SRC_FSYS, 4, 3),
@@ -502,6 +508,11 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, mout_spi0, mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, mout_spi1, mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, mout_spi2, mout_group2_p, SRC_PERIC1, 28, 3),
+
+   MUX(0, mout_user_aclk66_gpio, mout_user_aclk66_gpio_p,
+   SRC_TOP7, 4, 1),
+   MUX_F(0, mout_mau_epll_clk, mout_mau_epll_clk_p, SRC_TOP7, 20, 2,
+   CLK_SET_RATE_PARENT, 0),
MUX(0, mout_pclk200_fsys, mout_group1_p, SRC_TOP0, 24, 2),
MUX(0, mout_sw_pclk200_fsys, mout_sw_pclk200_fsys_p,
SRC_TOP10, 24, 1),
@@ -552,10 +563,10 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
 };
 
 static struct samsung_div_clock exynos5420_div_clks[] __initdata = {
-   DIV(0, div_arm, mout_cpu, DIV_CPU0, 0, 3),
+   DIV(0, dout_armclk1, mout_cpu, DIV_CPU0, 0, 3),
DIV(0, sclk_apll, mout_apll, DIV_CPU0, 24, 3),
-   DIV(0, armclk2, div_arm, DIV_CPU0, 28, 3),
-   DIV(0, div_kfc, mout_cpu_kfc, DIV_KFC0, 0, 3),
+   DIV(0, dout_armclk2, dout_armclk1, DIV_CPU0, 28, 3),
+   DIV(0, dout_kfc, mout_kfc, DIV_KFC0, 0, 3),
DIV(0, sclk_kpll, mout_kpll, DIV_KFC0, 24, 3),
 
DIV(0, dout_aclk400_mscl, mout_aclk400_mscl, DIV_TOP0, 4, 3),
@@ -908,6 +919,8 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_IP_MSCL, 10, 0, 0),
GATE(CLK_SMMU_MIXER, smmu_mixer, aclk200_disp1,
GATE_IP_DISP1, 9, 0, 0),
+
+   /* aclk333 gates internal MFC busses and should not be gated. */
/* aclk266 also gates other IPs in psgen. It should not be gated. */
GATE(0, aclk266, mout_user_aclk266,
GATE_BUS_NOC, 22, CLK_IGNORE_UNUSED, 0),
@@ -928,6 +941,10 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
mout_user_aclk333_432_isp, GATE_BUS_TOP, 8, 0, 0),
GATE(CLK_MC, mc, 

[PATCH v3 14/16] clk: exynos5420: correct g3d parent clock

2014-04-24 Thread Shaik Ameer Basha
This patch fixes the g3d parent clock.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c   |7 +++
 include/dt-bindings/clock/exynos5420.h |2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 0323b34..944ff20 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -427,8 +427,8 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
8, 1),
MUX(0, mout_user_aclk266_g2d, mout_user_aclk266_g2d_p, SRC_TOP5,
12, 1),
-   MUX_A(0, mout_user_aclk_g3d, mout_user_aclk_g3d_p,
-   SRC_TOP5, 16, 1, aclkg3d),
+   MUX(CLK_MOUT_G3D, mout_user_aclk_g3d, mout_user_aclk_g3d_p,
+   SRC_TOP5, 16, 1),
MUX(0, mout_user_aclk300_jpeg, mout_user_aclk300_jpeg_p,
SRC_TOP5, 20, 1),
MUX(0, mout_user_aclk300_disp1, mout_user_aclk300_disp1_p,
@@ -889,8 +889,7 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_MFC, mfc, aclk333, GATE_IP_MFC, 0, 0, 0),
GATE(CLK_SMMU_MFCL, smmu_mfcl, dout_mfc_blk, GATE_IP_MFC, 1, 0, 0),
GATE(CLK_SMMU_MFCR, smmu_mfcr, dout_mfc_blk, GATE_IP_MFC, 2, 0, 0),
-
-   GATE(CLK_G3D, g3d, aclkg3d, GATE_IP_G3D, 9, 0, 0),
+   GATE(CLK_G3D, g3d, mout_user_aclk_g3d, GATE_IP_G3D, 9, 0, 0),
 
GATE(CLK_ROTATOR, rotator, mout_user_aclk266, GATE_IP_GEN, 1, 0, 0),
GATE(CLK_JPEG, jpeg, aclk300_jpeg, GATE_IP_GEN, 2, 0, 0),
diff --git a/include/dt-bindings/clock/exynos5420.h 
b/include/dt-bindings/clock/exynos5420.h
index c36c7c6..b2410bc 100755
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -176,7 +176,6 @@
 #define CLK_SMMU_FIMCL1493
 #define CLK_SMMU_FIMCL3494
 #define CLK_FIMC_LITE3 495
-#define CLK_ACLK_G3D   500
 #define CLK_G3D501
 #define CLK_SMMU_MIXER 502
 #define CLK_SMMU_G2D   503
@@ -190,6 +189,7 @@
 /* mux clocks */
 #define CLK_MOUT_HDMI  640
 #define CLK_MOUT_MAUDIO0   642
+#define CLK_MOUT_G3D   643
 
 /* divider clocks */
 #define CLK_DOUT_PIXEL 768
-- 
1.7.9.5

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


[PATCH v3 15/16] clk: exynos5420: create clock ID for mout_sclk_vpll

2014-04-24 Thread Shaik Ameer Basha
This patch adds clock ID for mout_sclk_vpll clock

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c   |2 +-
 include/dt-bindings/clock/exynos5420.h |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 944ff20..33a48d2 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -437,7 +437,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
SRC_TOP5, 28, 1),
 
MUX(0, mout_sclk_mpll, mout_mpll_p, SRC_TOP6, 0, 1),
-   MUX(0, mout_sclk_vpll, mout_vpll_p, SRC_TOP6, 4, 1),
+   MUX(CLK_MOUT_VPLL, mout_sclk_vpll, mout_vpll_p, SRC_TOP6, 4, 1),
MUX(0, mout_sclk_spll, mout_spll_p, SRC_TOP6, 8, 1),
MUX(0, mout_sclk_ipll, mout_ipll_p, SRC_TOP6, 12, 1),
MUX(0, mout_sclk_rpll, mout_rpll_p, SRC_TOP6, 16, 1),
diff --git a/include/dt-bindings/clock/exynos5420.h 
b/include/dt-bindings/clock/exynos5420.h
index b2410bc..7c80443 100755
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -190,6 +190,7 @@
 #define CLK_MOUT_HDMI  640
 #define CLK_MOUT_MAUDIO0   642
 #define CLK_MOUT_G3D   643
+#define CLK_MOUT_VPLL  644
 
 /* divider clocks */
 #define CLK_DOUT_PIXEL 768
-- 
1.7.9.5

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


[PATCH v3 16/16] clk: exynos5420: add more registers to restore list

2014-04-24 Thread Shaik Ameer Basha
This patch adds more register offsets to the restore list.

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/clk/samsung/clk-exynos5420.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 33a48d2..6dfd3fd 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -27,6 +27,7 @@
 #define DIV_CPU1   0x504
 #define GATE_BUS_CPU   0x700
 #define GATE_SCLK_CPU  0x800
+#define CLKOUT_CMU_CPU 0xa00
 #define GATE_IP_G2D0x8800
 #define CPLL_LOCK  0x10020
 #define DPLL_LOCK  0x10030
@@ -39,7 +40,11 @@
 #define CPLL_CON0  0x10120
 #define DPLL_CON0  0x10128
 #define EPLL_CON0  0x10130
+#define EPLL_CON1  0x10134
+#define EPLL_CON2  0x10138
 #define RPLL_CON0  0x10140
+#define RPLL_CON1  0x10144
+#define RPLL_CON2  0x10148
 #define IPLL_CON0  0x10150
 #define SPLL_CON0  0x10160
 #define VPLL_CON0  0x10170
@@ -139,6 +144,13 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
DIV_CPU1,
GATE_BUS_CPU,
GATE_SCLK_CPU,
+   CLKOUT_CMU_CPU,
+   EPLL_CON0,
+   EPLL_CON1,
+   EPLL_CON2,
+   RPLL_CON0,
+   RPLL_CON1,
+   RPLL_CON2,
SRC_TOP0,
SRC_TOP1,
SRC_TOP2,
-- 
1.7.9.5

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


[PATCH v2 0/4] ARM: S3C24XX: cleanup debug macro/earlyprintk

2014-04-24 Thread Heiko Stübner
This series tries to simplify the s3c24xx debug macro, removing dependencies
on mach/ includes, static mappings and finally moving it into include/debug.

The one slightly invasive change is the need for the developer to select
the uart type by himself, which gets rid of the debug macro trying to
determine the uart type itself.

But as usage of the debug-uart is not the common case - especially in a
multiplatform scenario - I didn't worry to much.

Based on 3.15-rc1 and tested on a S3C2442 Openmoko Freerunner (GTA02)

changes since v1:
- do not introduce a secondary choice option, instead implement the
  s3c2410 debug uarts as separate options

Heiko Stuebner (4):
  ARM: compressed/head.S: remove s3c24xx special case
  ARM: S3C24XX: trim down debug uart handling
  ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro
  ARM: S3C24XX: move debug-macro.S into the common space

 arch/arm/Kconfig.debug   |  54 +++-
 arch/arm/boot/compressed/head.S  |   5 --
 arch/arm/include/debug/s3c24xx.S |  46 +++
 arch/arm/mach-s3c24xx/Kconfig|  28 ---
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 101 ---
 5 files changed, 98 insertions(+), 136 deletions(-)
 create mode 100644 arch/arm/include/debug/s3c24xx.S
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/debug-macro.S

-- 
1.9.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


[PATCH v2 1/4] ARM: compressed/head.S: remove s3c24xx special case

2014-04-24 Thread Heiko Stübner
addruart from the generic debug macro is doing exactly the same using
the common lowlevel uart definition, so there is no cause for this
special casing for s3c24xx.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/boot/compressed/head.S | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 066b034..3a8b32d 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -60,11 +60,6 @@
add \rb, \rb, #0x0001   @ Ser1
 #endif
.endm
-#elif defined(CONFIG_ARCH_S3C24XX)
-   .macro loadsp, rb, tmp
-   mov \rb, #0x5000
-   add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
-   .endm
 #else
.macro  loadsp, rb, tmp
addruart \rb, \tmp
-- 
1.9.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


[PATCH v2 2/4] ARM: S3C24XX: trim down debug uart handling

2014-04-24 Thread Heiko Stübner
Using the lowlevel debug uart is a corner case - even more so in a
multiplatform environment. So it seems reasonable to simply let the
developer set the appropriate uart type for the debugged SoC.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/Kconfig.debug   | 30 ++
 arch/arm/mach-s3c24xx/Kconfig| 28 -
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 52 +---
 3 files changed, 31 insertions(+), 79 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 4a2fc0b..cb5751f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -670,6 +670,33 @@ choice
  The uncompressor code port configuration is now handled
  by CONFIG_S3C_LOWLEVEL_UART_PORT.
 
+   config DEBUG_S3C2410_UART0
+   depends on ARCH_S3C24XX
+   select DEBUG_S3C2410_UART
+   bool Use S3C2410/S3C2412 UART 0 for low-level debug
+   help
+ Say Y here if you want the debug print routines to direct
+ their output to UART 0. The port must have been initialised
+ by the boot-loader before use.
+
+   config DEBUG_S3C2410_UART1
+   depends on ARCH_S3C24XX
+   select DEBUG_S3C2410_UART
+   bool Use S3C2410/S3C2412 UART 1 for low-level debug
+   help
+ Say Y here if you want the debug print routines to direct
+ their output to UART 1. The port must have been initialised
+ by the boot-loader before use.
+
+   config DEBUG_S3C2410_UART2
+   depends on ARCH_S3C24XX
+   select DEBUG_S3C2410_UART
+   bool Use S3C2410/S3C2412 UART 2 for low-level debug
+   help
+ Say Y here if you want the debug print routines to direct
+ their output to UART 2. The port must have been initialised
+ by the boot-loader before use.
+
config DEBUG_SOCFPGA_UART
depends on ARCH_SOCFPGA
bool Use SOCFPGA UART for low-level debug
@@ -921,6 +948,9 @@ endchoice
 config DEBUG_EXYNOS_UART
bool
 
+config DEBUG_S3C2410_UART
+   bool
+
 config DEBUG_OMAP2PLUS_UART
bool
depends on ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 40cf50b..98d17af 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -26,7 +26,6 @@ config CPU_S3C2410
bool SAMSUNG S3C2410
default y
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2410
select S3C2410_CLOCK
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
@@ -39,7 +38,6 @@ config CPU_S3C2410
 config CPU_S3C2412
bool SAMSUNG S3C2412
select CPU_ARM926T
-   select CPU_LLSERIAL_S3C2440
select S3C2412_DMA if S3C24XX_DMA
select S3C2412_PM if PM
help
@@ -48,7 +46,6 @@ config CPU_S3C2412
 config CPU_S3C2416
bool SAMSUNG S3C2416/S3C2450
select CPU_ARM926T
-   select CPU_LLSERIAL_S3C2440
select S3C2416_PM if PM
select S3C2443_COMMON
select S3C2443_DMA if S3C24XX_DMA
@@ -59,7 +56,6 @@ config CPU_S3C2416
 config CPU_S3C2440
bool SAMSUNG S3C2440
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2410_CLOCK
select S3C2410_PM if PM
select S3C2440_DMA if S3C24XX_DMA
@@ -69,7 +65,6 @@ config CPU_S3C2440
 config CPU_S3C2442
bool SAMSUNG S3C2442
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2410_CLOCK
select S3C2410_DMA if S3C24XX_DMA
select S3C2410_PM if PM
@@ -84,7 +79,6 @@ config CPU_S3C244X
 config CPU_S3C2443
bool SAMSUNG S3C2443
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2443_COMMON
select S3C2443_DMA if S3C24XX_DMA
select SAMSUNG_CLKSRC
@@ -158,28 +152,6 @@ config S3C2410_PM
help
  Power Management code common to S3C2410 and better
 
-# low-level serial option nodes
-
-config CPU_LLSERIAL_S3C2410_ONLY
-   bool
-   default y if CPU_LLSERIAL_S3C2410  !CPU_LLSERIAL_S3C2440
-
-config CPU_LLSERIAL_S3C2440_ONLY
-   bool
-   default y if CPU_LLSERIAL_S3C2440  !CPU_LLSERIAL_S3C2410
-
-config CPU_LLSERIAL_S3C2410
-   bool
-   help
- Selected if there is an S3C2410 (or register compatible) serial
- low-level implementation needed
-
-config CPU_LLSERIAL_S3C2440
-   bool
-   help
- Selected if there is an S3C2440 (or register compatible) serial
- low-level implementation needed
-
 config S3C24XX_PLL
bool Support CPUfreq changing of PLL frequency (EXPERIMENTAL)
depends on ARM_S3C24XX_CPUFREQ
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 

[PATCH] i2c: mux: Use subsys_initcall for the i2c-arb-gpio-challenge

2014-04-24 Thread Naveen Krishna Chatradhi
From: Doug Anderson diand...@chromium.org

Since many drivers rely on FETs that live behind this arbitrator, they
can't successfully probe until after the arbitrator comes up.  They
ought to handle things properly with EPROBE_DEFER and still work, but
that has some downsides:

1. Those drivers don't come up till later in the boot process.  That
   really not so nice for the LCD--we want that to init early.
2. Some drivers have bugs and don't handle EPROBE_DEFER.  Those
   drivers should be fixed but not all of them have been fixed yet.
   HDMI is one example since DRM doesn't really have good support for
   deferring probes.

With this change We end up using the same init level as the main i2c bus.

Signed-off-by: Doug Anderson diand...@chromium.org
Reviewed-on: https://gerrit.chromium.org/gerrit/57007
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c 
b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
index 69afffa..6cf52bb 100644
--- a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -241,7 +241,17 @@ static struct platform_driver i2c_arbitrator_driver = {
},
 };
 
-module_platform_driver(i2c_arbitrator_driver);
+static int __init i2c_arbitrator_init(void)
+{
+   return platform_driver_register(i2c_arbitrator_driver);
+}
+subsys_initcall(i2c_arbitrator_init);
+
+static void __exit i2c_arbitrator_exit(void)
+{
+   platform_driver_unregister(i2c_arbitrator_driver);
+}
+module_exit(i2c_arbitrator_exit);
 
 MODULE_DESCRIPTION(GPIO-based I2C Arbitration);
 MODULE_AUTHOR(Doug Anderson diand...@chromium.org);
-- 
1.7.9.5

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


Re: [PATCH 1/4] ARM: dts: exynos4: add PMU syscon node

2014-04-24 Thread Tomasz Figa

Hi Chanho,

On 14.04.2014 14:48, Chanho Park wrote:

This patch adds a PMU(Power Management Unit) syscon node. This
should be required for USB Phy syscon regmap I/F.

Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
  arch/arm/boot/dts/exynos4.dtsi | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..e565b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -110,6 +110,11 @@
reg = 0x1001 0x400;
};

+   pmu_reg: syscon@1002 {
+   compatible = samsung,exynos4-pmureg, syscon;


This compatible string doesn't seem to be defined in [1], please add it 
there,


[1] Documentation/devicetree/bindings/arm/samsung/pmu.txt

Otherwise looks good, so after fixing that you may add my

Reviewed-by: Tomasz Figa t.f...@samsung.com

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


Re: [PATCH 2/4] ARM: dts: exynos4: add exynos_usbphy node

2014-04-24 Thread Tomasz Figa

Hi Chanho,

On 14.04.2014 14:48, Chanho Park wrote:

This patch enables a exynos_usbphy node for exynos4 SoCs.
A exynos4x12 usb phy node is almost same with 4210's one
except compatible string and pmu syscon.

Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
  arch/arm/boot/dts/exynos4.dtsi| 10 ++
  arch/arm/boot/dts/exynos4x12.dtsi |  5 +
  2 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e565b86..0e32d7f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -278,6 +278,16 @@
status = disabled;
};

+   exynos_usbphy: exynos-usbphy@125B {
+   compatible = samsung,exynos4210-usb2-phy;
+   reg = 0x125B 0x100;
+   samsung,pmureg-phandle = pmu_reg;
+   clocks = clock 305, clock 2;


Please use clock macros from include/dt-bindings instead of numbers 
directly.


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


Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Rob Clark
On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar ajayn...@gmail.com wrote:
 Sorry for the previous reply,

 Here goes the full explaination:

 Rob,

 On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark robdcl...@gmail.com wrote:
 So what about, rather than adding drm_panel support to each bridge
 individually, we introduce a drm_panel_bridge (with a form of
 chaining).. ie:

   struct drm_panel_bridge {
 struct drm_bridge base;
 struct drm_panel *panel;
 struct drm_bridge *bridge; /* optional */
   };

   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
   {
 struct drm_panel_bridge *pb = to_panel_bridge(bridge);
 if (pb-bridge)
   pb-bridge-funcs-enable(pb-bridge);
 pb-panel-funcs-enable(pb-panel);
   }

 We cannot call them like this from crtc helpers in the order you mentioned,
 since each individual bridge chip expects the panel controls at
 different places.
 I mean,
 -- sometimes panel controls needs to be done before bridge
 controls(ptn3460: before RST_N and PD_N)

well, this is why bridge has pre-enable/enable/disable/post-disable
hooks, so you can choose before or after..

 -- sometimes in between the bridge controls (ps8622: one panel control
 before SLP_N and one after SLP_N)
 -- sometimes panel controls needs to be done after bridge controls.

I am not convinced that a generic panel/bridge adapter is not
possible.  Maybe we need more fine grained fxn ptr callbacks, although
seems like pre+post should give you enough.  It would certainly be
easier than having to add panel support in each individual bridge
driver (which seems like it will certainly result that only certain
combinations of panel+bridge actually work as intended)

 So, putting these drm_panel controls inside individual bridge drivers will 
 work,
 but keeping them in crtc_helpers might break stuff.

I'm not talking about crtc changing helpers.

BR,
-R

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


Re: [PATCH v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC

2014-04-24 Thread Tomasz Figa

Hi Tarek,

On 14.04.2014 13:59, Tarek Dakhran wrote:

On 04/14/2014 03:03 PM, Arnd Bergmann wrote:

On Monday 14 April 2014 11:17:38 Tarek Dakhran wrote:

--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -159,6 +159,15 @@ static struct map_desc exynos5250_iodesc[]
__initdata = {
 },
  };
+static struct map_desc exynos5410_iodesc[] __initdata = {
+   {
+   .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+   .pfn=
__phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
+   .length = SZ_4K,
+   .type   = MT_DEVICE,
+   },
+};
+
  static struct map_desc exynos5_iodesc[] __initdata = {

NAK

Why does this keep coming up?

Arnd


We need this memory region because boot address for exynos5410 located
here, same as for 5250.



Is there really no way to map this region dynamically in the entity 
(driver, source file, whatever) that actually uses it? The goal is to 
get rid of all the static mappings entirely, so adding new one makes us 
further from it.


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


Re: [PATCH 3/4] ARM: dts: exynos4: add hsotg device node

2014-04-24 Thread Tomasz Figa

Hi Chanho,

On 14.04.2014 14:48, Chanho Park wrote:

This patch adds a hsotg node for exynos4 USB2.0 device controller.

Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
  arch/arm/boot/dts/exynos4.dtsi | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 0e32d7f..e541ecb 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -288,6 +288,17 @@
#phy-cells = 1;
};

+   hsotg@1248 {
+   compatible = samsung,s3c6400-hsotg;
+   reg = 0x1248 0x2;
+   interrupts = 0 71 0;
+   clocks = clock 305;


Please use clock macros.


+   clock-names = otg;
+   phys = exynos_usbphy 0;
+   phy-names = device;


This is not the correct phy name for this binding. According to what the 
driver uses and the example in ...bindings/usb/dwc2.txt usb2-phy 
should be used.


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


Re: [PATCH] i2c: exynos5: Initialise Samsung High Speed I2C controller early

2014-04-24 Thread Mark Brown
On Thu, Apr 24, 2014 at 08:18:36PM +0530, Naveen Krishna Chatradhi wrote:
 This patch moves initialization code to subsys_initcall() to ensure
 that the i2c bus is available early so the regulators can be quickly
 probed and available for other devices on their probe() call.

 Such solution has been proposed by Mark Brown to fix the problem of
 the regulators not beeing available on the peripheral device probe():
 http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html

What specifically is this needed for?  We *should* be able to use
deferred probe for most things, but I know that not all subsystems are
able to yet.


signature.asc
Description: Digital signature


Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Ajay kumar
Rob,

On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark robdcl...@gmail.com wrote:
 On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar ajayn...@gmail.com wrote:
 Sorry for the previous reply,

 Here goes the full explaination:

 Rob,

 On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark robdcl...@gmail.com wrote:
 So what about, rather than adding drm_panel support to each bridge
 individually, we introduce a drm_panel_bridge (with a form of
 chaining).. ie:

   struct drm_panel_bridge {
 struct drm_bridge base;
 struct drm_panel *panel;
 struct drm_bridge *bridge; /* optional */
   };

   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
   {
 struct drm_panel_bridge *pb = to_panel_bridge(bridge);
 if (pb-bridge)
   pb-bridge-funcs-enable(pb-bridge);
 pb-panel-funcs-enable(pb-panel);
   }

 We cannot call them like this from crtc helpers in the order you mentioned,
 since each individual bridge chip expects the panel controls at
 different places.
 I mean,
 -- sometimes panel controls needs to be done before bridge
 controls(ptn3460: before RST_N and PD_N)

 well, this is why bridge has pre-enable/enable/disable/post-disable
 hooks, so you can choose before or after..
These calls are for a bridge to sync with the encoder calls.
We might end up defining pre-enable/enable/disable/post-disable for a
panel to sync
with the bridge calls! I have explained below.

 -- sometimes in between the bridge controls (ps8622: one panel control
 before SLP_N and one after SLP_N)
 -- sometimes panel controls needs to be done after bridge controls.

 I am not convinced that a generic panel/bridge adapter is not
 possible.  Maybe we need more fine grained fxn ptr callbacks, although
 seems like pre+post should give you enough.  It would certainly be
 easier than having to add panel support in each individual bridge
 driver (which seems like it will certainly result that only certain
 combinations of panel+bridge actually work as intended)
Ok. Consider this case:
Currently, we have the sequence as bridge-pre_enable,
encoder_enable, bridge-enable
And, the bridge should obviously be enabled in bridge-pre_enable.
Now, where do you choose to call panel-pre_enable?
-- as the first step of bridge-pre_enable, before we pull up/down bridge GPIOs.
-- at the last step of bridge-pre_enable, after we pull up/down the
bridge GPIOs.

Ideally, PTN3460 expects it to be the second case, and PS8625 expects
it to be the first case.
So, we will end up adding pre_pre_enable, post_pre_enable to
accomodate such scenarios.

So, we leave the choice for the individual bridge chip drivers to
implement panel
power up/down controls in the place where they wish to.


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


Re: [PATCH] ARM: dts: Add atmel trackpad node to 5250 cros

2014-04-24 Thread Tomasz Figa

Hi Arun,

On 14.04.2014 08:35, Arun Kumar K wrote:

The newer versions of exynos5250 based Snow boards have
atmel trackpad. Updating relevant nodes for the same.

Signed-off-by: Arun Kumar K arun...@samsung.com
---
  arch/arm/boot/dts/exynos5250-cros-common.dtsi |   24 
  1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi 
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 2c1560d..658f086 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -28,6 +28,13 @@
samsung,pin-pud = 0;
};

+   trackpad_irq: trackpad-irq {
+   samsung,pins = gpx1-2;
+   samsung,pin-function = 0;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
max77686_irq: max77686-irq {
samsung,pins = gpx3-2;
samsung,pin-function = 0;
@@ -191,6 +198,9 @@
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;

+   pinctrl-names = default;
+   pinctrl-0 = i2c1_bus trackpad_irq;


Please add trackpad_irq to trackpad node instead. Pinctrl properties of 
i2c node should contain only i2c-related pins.



+
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
@@ -198,6 +208,20 @@
interrupt-parent = gpx1;
wakeup-source;
};
+   trackpad-alt {


Style: Please keep one blank line between two nodes.


+   reg = 0x4b;
+   compatible = atmel,atmel_mxt_tp;
+   interrupts = 2 0;
+   interrupt-parent = gpx1;
+   wakeup-source;
+   };
+   trackpad-bootloader {


Ditto.


+   reg = 0x25;
+   compatible = atmel,atmel_mxt_tp;
+   interrupts = 2 0;
+   interrupt-parent = gpx1;
+   wakeup-source;
+   };


Hmm, why are there 3 different nodes here? Could you explain what one by 
one for what hardware they are?


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


Re: [PATCH V5 00/20] ARM: exynos: cpuidle: Move the driver to drivers/cpuidle

2014-04-24 Thread Tomasz Figa

On 14.04.2014 11:01, Daniel Lezcano wrote:


Hi Kukjin,

I believe I addressed all the comments. Is it possible to take this
patchset for next ?


+1.

Also when applying you might add

Reviewed-by: Tomasz Figa t.f...@samsung.com

to any patches that don't have it yet.

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


Re: [PATCH] ARM: dts: exynos4: clean up arm-pmu node

2014-04-24 Thread Tomasz Figa

Hi Chanho,

On 14.04.2014 15:03, Chanho Park wrote:

This patch cleans a arm-pmu node up for exynos4. Only exynos4412 series
boards have four pmu interrupts. Rest of exynos4 boards, except 4412, have only
two pmu interrupts. Thus, we can define two interrupts in the
exynos4.dtsi and extends the interrupts only exynos4412.dtsi.

Cc: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
  arch/arm/boot/dts/exynos4.dtsi| 6 ++
  arch/arm/boot/dts/exynos4210.dtsi | 6 --
  arch/arm/boot/dts/exynos4412.dtsi | 6 ++
  arch/arm/boot/dts/exynos4x12.dtsi | 6 --
  4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e541ecb..6de978c 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -105,6 +105,12 @@
reg = 0x1044 0x1000;
};

+   pmu {
+   compatible = arm,cortex-a9-pmu;
+   interrupt-parent = combiner;
+   interrupts = 2 2, 3 2;
+   };
+
sys_reg: syscon@1001 {
compatible = samsung,exynos4-sysreg, syscon;
reg = 0x1001 0x400;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..4e7610f 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -75,12 +75,6 @@
#clock-cells = 1;
};

-   pmu {
-   compatible = arm,cortex-a9-pmu;
-   interrupt-parent = combiner;
-   interrupts = 2 2, 3 2;
-   };
-
pinctrl_0: pinctrl@1140 {
compatible = samsung,exynos4210-pinctrl;
reg = 0x1140 0x1000;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index 15d3c0a..e6af870 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -26,6 +26,12 @@
samsung,combiner-nr = 20;
};

+   pmu {
+   compatible = arm,cortex-a9-pmu;
+   interrupt-parent = combiner;


I guess you could omit the two properties above and let them be 
inherited from exynos4.dtsi.


Otherwise looks fine.

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


Re: [PATCH] arm: dts: exynos4412-trats2: rename alias for i2c_ak8975 label

2014-04-24 Thread Tomasz Figa

Hi Tomasz,

On 15.04.2014 16:25, Tomasz Stanislawski wrote:

The i2c_ak8975 controler uses label i2c8.
This alias is already used for I2C controller 8 defined
in file arch/arm/boot/dts/exynos4.dtsi.

This patch renames a label for i2c_ak8975 to i2c9.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
  arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index c16b315..5add765 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -20,7 +20,7 @@
compatible = samsung,trats2, samsung,exynos4412, samsung,exynos4;

aliases {
-   i2c8 = i2c_ak8975;
+   i2c9 = i2c_ak8975;
};

memory {
--
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



Seems reasonable.

Reviewed-by: Tomasz Figa t.f...@samsung.com

--
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


Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Rob Clark
On Thu, Apr 24, 2014 at 12:55 PM, Ajay kumar ajayn...@gmail.com wrote:
 Rob,

 On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark robdcl...@gmail.com wrote:
 On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar ajayn...@gmail.com wrote:
 Sorry for the previous reply,

 Here goes the full explaination:

 Rob,

 On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark robdcl...@gmail.com wrote:
 So what about, rather than adding drm_panel support to each bridge
 individually, we introduce a drm_panel_bridge (with a form of
 chaining).. ie:

   struct drm_panel_bridge {
 struct drm_bridge base;
 struct drm_panel *panel;
 struct drm_bridge *bridge; /* optional */
   };

   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
   {
 struct drm_panel_bridge *pb = to_panel_bridge(bridge);
 if (pb-bridge)
   pb-bridge-funcs-enable(pb-bridge);
 pb-panel-funcs-enable(pb-panel);
   }

 We cannot call them like this from crtc helpers in the order you mentioned,
 since each individual bridge chip expects the panel controls at
 different places.
 I mean,
 -- sometimes panel controls needs to be done before bridge
 controls(ptn3460: before RST_N and PD_N)

 well, this is why bridge has pre-enable/enable/disable/post-disable
 hooks, so you can choose before or after..
 These calls are for a bridge to sync with the encoder calls.
 We might end up defining pre-enable/enable/disable/post-disable for a
 panel to sync
 with the bridge calls! I have explained below.

 -- sometimes in between the bridge controls (ps8622: one panel control
 before SLP_N and one after SLP_N)
 -- sometimes panel controls needs to be done after bridge controls.

 I am not convinced that a generic panel/bridge adapter is not
 possible.  Maybe we need more fine grained fxn ptr callbacks, although
 seems like pre+post should give you enough.  It would certainly be
 easier than having to add panel support in each individual bridge
 driver (which seems like it will certainly result that only certain
 combinations of panel+bridge actually work as intended)
 Ok. Consider this case:
 Currently, we have the sequence as bridge-pre_enable,
 encoder_enable, bridge-enable
 And, the bridge should obviously be enabled in bridge-pre_enable.
 Now, where do you choose to call panel-pre_enable?
 -- as the first step of bridge-pre_enable, before we pull up/down bridge 
 GPIOs.
 -- at the last step of bridge-pre_enable, after we pull up/down the
 bridge GPIOs.

 Ideally, PTN3460 expects it to be the second case, and PS8625 expects
 it to be the first case.
 So, we will end up adding pre_pre_enable, post_pre_enable to
 accomodate such scenarios.

ok, well I think we can deal with this with a slight modification of
my original proposal.  Split drm_panel_bridge into
drm_composite_bridge and drm_panel_bridge:

  struct drm_composite_bridge {
struct drm_bridge base;
struct drm_bridge *b1, *b2;
  }

  static void drm_composite_bridge_enable(struct drm_bridge *bridge)
  {
struct drm_composite_bridge *cbridge = to_composite_bridge(bridge);
cbridge-b1-funcs-enable(cbridge-b1);
cbridge-b2-funcs-enable(cbridge-b2);
  }

  .. and so on ..

  struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
  }

  static void drm_panel_bridge_enable(struct drm_bridge *bridge)
  {
struct drm_panel_bridge *pbridge = to_panel_bridge(bridge);
pbridge-panel-funcs-enable(pbridge-panel);
  }

  .. and so on..


then in initialization, order can be managed like:

  if (panel_first)
bridge = drm_composite_bridge_init(panel_bridge, actual_bridge)
  else
bridge = drm_composite_bridge_init(actual_bridge, panel_bridge);

  possibly parametrize drm_panel_bridge if we need to map
panel-enable() to bridge-pre_enable() vs bridge-enable(), etc..

BR,
-R

 So, we leave the choice for the individual bridge chip drivers to
 implement panel
 power up/down controls in the place where they wish to.


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


Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Ajay kumar
On Thu, Apr 24, 2014 at 10:55 PM, Rob Clark robdcl...@gmail.com wrote:
 On Thu, Apr 24, 2014 at 12:55 PM, Ajay kumar ajayn...@gmail.com wrote:
 Rob,

 On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark robdcl...@gmail.com wrote:
 On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar ajayn...@gmail.com wrote:
 Sorry for the previous reply,

 Here goes the full explaination:

 Rob,

 On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark robdcl...@gmail.com wrote:
 So what about, rather than adding drm_panel support to each bridge
 individually, we introduce a drm_panel_bridge (with a form of
 chaining).. ie:

   struct drm_panel_bridge {
 struct drm_bridge base;
 struct drm_panel *panel;
 struct drm_bridge *bridge; /* optional */
   };

   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
   {
 struct drm_panel_bridge *pb = to_panel_bridge(bridge);
 if (pb-bridge)
   pb-bridge-funcs-enable(pb-bridge);
 pb-panel-funcs-enable(pb-panel);
   }

 We cannot call them like this from crtc helpers in the order you mentioned,
 since each individual bridge chip expects the panel controls at
 different places.
 I mean,
 -- sometimes panel controls needs to be done before bridge
 controls(ptn3460: before RST_N and PD_N)

 well, this is why bridge has pre-enable/enable/disable/post-disable
 hooks, so you can choose before or after..
 These calls are for a bridge to sync with the encoder calls.
 We might end up defining pre-enable/enable/disable/post-disable for a
 panel to sync
 with the bridge calls! I have explained below.

 -- sometimes in between the bridge controls (ps8622: one panel control
 before SLP_N and one after SLP_N)
 -- sometimes panel controls needs to be done after bridge controls.

 I am not convinced that a generic panel/bridge adapter is not
 possible.  Maybe we need more fine grained fxn ptr callbacks, although
 seems like pre+post should give you enough.  It would certainly be
 easier than having to add panel support in each individual bridge
 driver (which seems like it will certainly result that only certain
 combinations of panel+bridge actually work as intended)
 Ok. Consider this case:
 Currently, we have the sequence as bridge-pre_enable,
 encoder_enable, bridge-enable
 And, the bridge should obviously be enabled in bridge-pre_enable.
 Now, where do you choose to call panel-pre_enable?
 -- as the first step of bridge-pre_enable, before we pull up/down bridge 
 GPIOs.
 -- at the last step of bridge-pre_enable, after we pull up/down the
 bridge GPIOs.

 Ideally, PTN3460 expects it to be the second case, and PS8625 expects
 it to be the first case.
 So, we will end up adding pre_pre_enable, post_pre_enable to
 accomodate such scenarios.

 ok, well I think we can deal with this with a slight modification of
 my original proposal.  Split drm_panel_bridge into
 drm_composite_bridge and drm_panel_bridge:

   struct drm_composite_bridge {
 struct drm_bridge base;
 struct drm_bridge *b1, *b2;
   }

   static void drm_composite_bridge_enable(struct drm_bridge *bridge)
   {
 struct drm_composite_bridge *cbridge = to_composite_bridge(bridge);
 cbridge-b1-funcs-enable(cbridge-b1);
 cbridge-b2-funcs-enable(cbridge-b2);
   }

   .. and so on ..

   struct drm_panel_bridge {
 struct drm_bridge base;
 struct drm_panel *panel;
   }

   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
   {
 struct drm_panel_bridge *pbridge = to_panel_bridge(bridge);
 pbridge-panel-funcs-enable(pbridge-panel);
   }

   .. and so on..


 then in initialization, order can be managed like:

   if (panel_first)
 bridge = drm_composite_bridge_init(panel_bridge, actual_bridge)
   else
 bridge = drm_composite_bridge_init(actual_bridge, panel_bridge);

   possibly parametrize drm_panel_bridge if we need to map
 panel-enable() to bridge-pre_enable() vs bridge-enable(), etc..

Well, this really does seems complex to me.
Don't you think just having a drm_panel inside drm_bridge structure is
sufficient?!
And, make a call for pre_panel_enable and post_panel_enable around
bridge-pre_enable..and so on.?
--
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] Exynos4: cpuidle: support dual CPUs with AFTR state

2014-04-24 Thread Tomasz Figa

Hi Daniel,

Please see my comments inline.

Btw. Please fix your e-mail composer to properly wrap your messages 
around 7xth column, as otherwise they're hard to read.


On 04.04.2014 11:48, Daniel Lezcano wrote:

The following driver is for exynos4210. I did not yet finished the other 
boards, so
I created a specific driver for 4210 which could be merged later.

The driver is based on Colin Cross's driver found at:

https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/

This one was based on a 3.4 kernel and an old API.

It has been refreshed, simplified and based on the recent code cleanup I sent
today.

The AFTR could be entered when all the cpus (except cpu0) are down. In order to
reach this situation, the couple idle states are used.

There is a sync barrier at the entry and the exit of the low power function. So
all cpus will enter and exit the function at the same time.

At this point, CPU0 knows the other cpu will power down itself. CPU0 waits for
the CPU1 to be powered down and then initiate the AFTR power down sequence.

No interrupts are handled by CPU1, this is why we switch to the timer broadcast
even if the local timer is not impacted by the idle state.

When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then they both
exit the idle function.

This driver allows the exynos4210 to have the same power consumption at idle
time than the one when we have to unplug CPU1 in order to let CPU0 to reach
the AFTR state.

This patch is a RFC because, we have to find a way to remove the macros
definitions and cpu powerdown function without pulling the arch dependent
headers.

Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
  arch/arm/mach-exynos/common.c|   11 +-
  drivers/cpuidle/Kconfig.arm  |8 ++
  drivers/cpuidle/Makefile |1 +
  drivers/cpuidle/cpuidle-exynos4210.c |  226 ++
  4 files changed, 245 insertions(+), 1 deletion(-)
  create mode 100644 drivers/cpuidle/cpuidle-exynos4210.c

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index d5fa21e..1765a98 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,9 +299,18 @@ static struct platform_device exynos_cpuidle = {
.id= -1,
  };

+static struct platform_device exynos4210_cpuidle = {
+   .name  = exynos4210-cpuidle,
+   .dev.platform_data = exynos_sys_powerdown_aftr,
+   .id= -1,
+};
+
  void __init exynos_cpuidle_init(void)
  {
-   platform_device_register(exynos_cpuidle);
+   if (soc_is_exynos4210())
+   platform_device_register(exynos4210_cpuidle);
+   else
+   platform_device_register(exynos_cpuidle);
  }

  void __init exynos_cpufreq_init(void)
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 92f0c12..2772130 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -51,3 +51,11 @@ config ARM_EXYNOS_CPUIDLE
depends on ARCH_EXYNOS
help
  Select this to enable cpuidle for Exynos processors
+
+config ARM_EXYNOS4210_CPUIDLE
+   bool Cpu Idle Driver for the Exynos 4210 processor
+   default y
+   depends on ARCH_EXYNOS
+   select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+   help
+ Select this to enable cpuidle for the Exynos 4210 processors
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 0d1540a..e0ec9bc 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+= 
cpuidle-zynq.o
  obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
  obj-$(CONFIG_ARM_AT91_CPUIDLE)  += cpuidle-at91.o
  obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+= cpuidle-exynos.o
+obj-$(CONFIG_ARM_EXYNOS4210_CPUIDLE)+= cpuidle-exynos4210.o

  
###
  # POWERPC drivers
diff --git a/drivers/cpuidle/cpuidle-exynos4210.c 
b/drivers/cpuidle/cpuidle-exynos4210.c
new file mode 100644
index 000..56f6d51
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-exynos4210.c
@@ -0,0 +1,226 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Copyright (c) 2014 Linaro : Daniel Lezcano daniel.lezc...@linaro.org
+ * http://www.linaro.org
+ *
+ * Based on the work of Colin Cross ccr...@android.com
+ *
+ * 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/cpuidle.h
+#include linux/cpu_pm.h
+#include linux/io.h
+#include linux/platform_device.h
+
+#include asm/proc-fns.h
+#include asm/suspend.h
+#include asm/cpuidle.h
+
+#include plat/pm.h
+#include plat/cpu.h
+#include plat/map-base.h
+#include plat/map-s5p.h


This 

Re: [PATCH 0/8] i.MX6 PCIe binding change and MSI support

2014-04-24 Thread Bjorn Helgaas
On Fri, Mar 28, 2014 at 05:52:51PM +0100, Lucas Stach wrote:
 While working on MSI support for the i.MX6 PCIe host driver
 it has been discovered that the binding for this host controller
 is broken in many ways (refer to the patch descriptions for more
 info) and was introduced without proper discussion about what
 should/should not be in the binding.
 
 This series fixes this and minimizes the difference of the
 i.MX6 binding to the common designware PCIe binding. I'm aware
 that this is a quite radical change, but I think it's justified
 to do this as long as there aren't many user of the old binding
 (most of the optional properties in the binding aren't even
 implemented).
 
 Looking forward to your feedback.
 
 Lucas Stach (8):
   ARM: imx6q-clk: parent lvds_gate from lvds_sel
   PCI: designware: split Exynos and i.MX bindings
   ARM: dts: imx6: update pcie to bring in line with new binding
   PCI: imx6: use new clock names
   PCI: imx6: drop old irq mapping
   PCI: imx6: rip out optional (and unused) irqs
   PCI: designware: make MSI isr shared irq aware
   PCI: imx6: add support for MSI

What's the status of all these?  I would normally apply patches 4-8 of this
series through my tree, given the appropriate acks, but I haven't seen
those yet.  And I'm not sure what dependencies there are between the
non-PCI patches and the PCI ones.

Bjorn
--
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