Re: [PATCH] ARM: dts: add board dts file for Exynos3250-based Monk board

2014-10-02 Thread Kyungmin Park
+ Adding ARM maintainers.
I know it's too late. just to know we trying to push product board
support at mainline.

Thank you,
Kyungmin Park

On Thu, Oct 2, 2014 at 9:50 AM, YoungJun Cho yj44@samsung.com wrote:
 From: Youngjun Cho yj44@samsung.com

 This patch adds new board dts file to support Samsung Monk board which is
 based on Exynos3250 SoC and has different H/W configuration from Rinato.

 This patch is based on linux-samsung.git for-next branch and depends on
 [PATCH 0/2] ARM: dts: Add new board dts file for Exynos3250-based Rinato 
 board[1]

 This dts file support following features:
 - eMMC
 - Main PMIC (Samsung S2MPS14)
 - Interface PMIC (Maxim MAX77836, MUIC, fuel-gauge, charger)
 - RTC of Exynos3250
 - ADC of Exynos3250 with NTC thermistor
 - I2S of Exynos3250
 - TMU of Exynos3250
 - Secure firmware for Exynos3250 secondary cpu boot
 - Serial ports of Exynos3250
 - gpio-key for power key

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

 Signed-off-by: Youngjun Cho yj44@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@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: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/boot/dts/Makefile|   3 +-
  arch/arm/boot/dts/exynos3250-monk.dts | 592 
 ++
  2 files changed, 594 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/boot/dts/exynos3250-monk.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 5728918..0c8ae64 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -64,7 +64,8 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
  dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 da850-evm.dtb
  dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
 -dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-rinato.dtb \
 +dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-monk.dtb \
 +   exynos3250-rinato.dtb \
 exynos4210-origen.dtb \
 exynos4210-smdkv310.dtb \
 exynos4210-trats.dtb \
 diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
 b/arch/arm/boot/dts/exynos3250-monk.dts
 new file mode 100644
 index 000..9e94294
 --- /dev/null
 +++ b/arch/arm/boot/dts/exynos3250-monk.dts
 @@ -0,0 +1,592 @@
 +/*
 + * Samsung's Exynos3250 based Monk board device tree source
 + *
 + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
 + * http://www.samsung.com
 + *
 + * Device tree source file for Samsung's Monk board which is based on
 + * Samsung Exynos3250 SoC.
 + *
 + * 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.
 + */
 +
 +/dts-v1/;
 +#include exynos3250.dtsi
 +#include dt-bindings/input/input.h
 +
 +/ {
 +   model = Samsung Monk board;
 +   compatible = samsung,monk, samsung,exynos3250, samsung,exynos3;
 +
 +   aliases {
 +   i2c7 = i2c_max77836;
 +   };
 +
 +   memory {
 +   reg =  0x4000 0x0800
 +   0x4800 0x0800
 +   0x5000 0x0800
 +   0x5800 0x07F0;
 +   };
 +
 +   chosen {
 +   bootargs = console=ttySAC1,115200N8 root=/dev/mmcblk0p15 
 rootwait earlyprintk panic=5;
 +   };
 +
 +   firmware@0205F000 {
 +   compatible = samsung,secure-firmware;
 +   reg = 0x0205F000 0x1000;
 +   } ;
 +
 +   gpio_keys {
 +   compatible = gpio-keys;
 +
 +   power_key {
 +   interrupt-parent = gpx2;
 +   interrupts = 7 0;
 +   gpios = gpx2 7 1;
 +   linux,code = KEY_POWER;
 +   label = power key;
 +   debounce-interval = 10;
 +   gpio-key,wakeup;
 +   };
 +   };
 +
 +   regulators {
 +   compatible = simple-bus;
 +   #address-cells = 1;
 +   #size-cells = 0;
 +
 +   vemmc_reg: voltage-regulator-0 {
 +   compatible = regulator-fixed;
 +   regulator-name = V_EMMC_2.8V-fixed;
 +   regulator-min-microvolt = 280;
 +   regulator-max-microvolt = 280;
 +   gpio = gpk0 2 0;
 +   enable-active-high;
 +   };
 +   };
 +
 +   i2c_max77836: i2c-gpio-0 {
 +   compatible = i2c-gpio;
 +   gpios = gpd0 2 0, gpd0 3 0;
 +   #address-cells = 1;
 +   #size-cells = 0;
 +
 +   max77836: subpmic@25 {
 +   compatible = maxim,max77836;
 +   interrupt-parent = gpx1;
 +   interrupts = 5 0

Re: [PATCH 0/2] ARM: dts: Add new board dts file for Exynos3250-based Rinato board

2014-10-02 Thread Kyungmin Park
+ ARM maintainers.

It's Gear 2 board support.

Thank you,
Kyungmin Park

On Tue, Sep 30, 2014 at 8:07 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patchset adds new board dts file for Samsung Rinato board (Gear 2) which
 is based on Exynos3250 SoC and adds sleep mode pin configuration using pinctrl
 subsystem to reduce leakage power-consumption in sleep state.

 This patchset is based on linux-samsung.git (for-next branch).

 Chanwoo Choi (2):
   ARM: dts: Add board dts file for Exynos3250-based Rinato board
   ARM: dts: Add sleep mode pin configuration for exynos3250-rinato

  arch/arm/boot/dts/Makefile|   3 +-
  arch/arm/boot/dts/exynos3250-pinctrl.dtsi |  16 +
  arch/arm/boot/dts/exynos3250-rinato.dts   | 595 
 ++
  3 files changed, 613 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/boot/dts/exynos3250-rinato.dts

 --
 1.8.0


 ___
 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/2] clk: samsung: exynos3250: add uart2/3 related clocks

2014-09-29 Thread Kyungmin Park
On Mon, Sep 29, 2014 at 4:22 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 Hi,

 On Monday, September 29, 2014 9:07 AM, Kyungmin Park wrote,
 To: Pankaj Dubey
 Cc: Chanwoo Choi; Kukjin Kim; Russell King - ARM Linux;
 naus...@samsung.com;
 Tomasz Figa; linux-samsung-soc; robh...@kernel.org; Sylwester Nawrocki;
 Mike
 Turquette; arm-linux
 Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related
 clocks

 On Mon, Sep 29, 2014 at 11:47 AM, Pankaj Dubey pankaj.du...@samsung.com
 wrote:
  Hi Chanwoo,
 
  On Monday, September 29, 2014 7:42 AM, Chanwoo Choi wrote,
  To: Pankaj Dubey
  Cc: linux-arm-ker...@lists.infradead.org;
  linux-samsung-soc@vger.kernel.org;
  kgene@samsung.com; tomasz.f...@gmail.com; robh...@kernel.org;
  li...@arm.linux.org.uk; naus...@samsung.com; Mike Turquette;
  Sylwester Nawrocki
  Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3
  related
  clocks
 
  Hi Pankaj,
 
  On 09/27/2014 01:58 PM, Pankaj Dubey wrote:
   Exynos3250 has four UART channels UART0,1,2 and 3. This patch adds
   missing clock entries for UART2 and UART3.
  
   CC: Mike Turquette mturque...@linaro.org
   CC: Sylwester Nawrocki s.nawro...@samsung.com
   Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
   ---
drivers/clk/samsung/clk-exynos3250.c   |   11 +++
include/dt-bindings/clock/exynos3250.h |   10 +-
2 files changed, 20 insertions(+), 1 deletion(-)
 
  Exynos3250 has only two UART(0,1) port. Exynos3250 don't support UART
 2,3.
 
 
  As per Exynos3250 user manual that I have with me it supports
 UART(0,1,2,3).
  It has been mentioned
 which UM do you use? There are two UARTs at rev0.01


 I am using Rev 2.0.
I received the latest manual from LSI. but it's still v1.40.

 Thanks,
 Pankaj Dubey


  in UART Chapter as well as CMU IP details also mentioned about the
  clock entries. We have tested it also on Espresso3250 board which is
  based on Exynos3250 SoC.
 I can't find it at my UM.

 Kyungmin Park
 
  Thanks,
  Pankaj Dubey
 
  Thanks,
  Chanwoo Choi
 
  
   diff --git a/drivers/clk/samsung/clk-exynos3250.c
   b/drivers/clk/samsung/clk-exynos3250.c
   index dc85f8e..0722fef 100644
   --- a/drivers/clk/samsung/clk-exynos3250.c
   +++ b/drivers/clk/samsung/clk-exynos3250.c
   @@ -357,6 +357,8 @@ static struct samsung_mux_clock mux_clks[]
  __initdata =
  {
   MUX(CLK_MOUT_MMC0, mout_mmc0, group_sclk_p, SRC_FSYS, 0,
 3),
  
   /* SRC_PERIL0 */
   +   MUX(CLK_MOUT_UART3, mout_uart3, group_sclk_p, SRC_PERIL0,
  12, 4),
   +   MUX(CLK_MOUT_UART2, mout_uart2, group_sclk_p, SRC_PERIL0,
 8,
  4),
   MUX(CLK_MOUT_UART1, mout_uart1, group_sclk_p, SRC_PERIL0,
 4,
  4),
   MUX(CLK_MOUT_UART0, mout_uart0, group_sclk_p, SRC_PERIL0,
 0,
  4),
  
   @@ -439,6 +441,8 @@ static struct samsung_div_clock div_clks[]
  __initdata = {
   DIV(CLK_DIV_MMC0, div_mmc0, mout_mmc0, DIV_FSYS1, 0, 4),
  
   /* DIV_PERIL0 */
   +   DIV(CLK_DIV_UART3, div_uart3, mout_uart3, DIV_PERIL0, 12,
 4),
   +   DIV(CLK_DIV_UART2, div_uart2, mout_uart2, DIV_PERIL0, 8,
   + 4),
   DIV(CLK_DIV_UART1, div_uart1, mout_uart1, DIV_PERIL0, 4, 4),
   DIV(CLK_DIV_UART0, div_uart0, mout_uart0, DIV_PERIL0, 0,
   4),
  
   @@ -601,6 +605,10 @@ static struct samsung_gate_clock gate_clks[]
  __initdata
  = {
   GATE_SCLK_PERIL, 7, CLK_SET_RATE_PARENT, 0),
   GATE(CLK_SCLK_SPI0, sclk_spi0, div_spi0_pre,
   GATE_SCLK_PERIL, 6, CLK_SET_RATE_PARENT, 0),
   +   GATE(CLK_SCLK_UART3, sclk_uart3, div_uart3,
   +   GATE_SCLK_PERIL, 3, CLK_SET_RATE_PARENT, 0),
   +   GATE(CLK_SCLK_UART2, sclk_uart2, div_uart2,
   +   GATE_SCLK_PERIL, 2, CLK_SET_RATE_PARENT, 0),
   GATE(CLK_SCLK_UART1, sclk_uart1, div_uart1,
   GATE_SCLK_PERIL, 1, CLK_SET_RATE_PARENT, 0),
   GATE(CLK_SCLK_UART0, sclk_uart0, div_uart0, @@ -679,6
   +687,7
  @@
   static struct samsung_gate_clock gate_clks[] __initdata = {
   GATE(CLK_USBOTG, usbotg, div_aclk_200, GATE_IP_FSYS, 13,
 0,
  0),
   GATE(CLK_USBHOST, usbhost, div_aclk_200, GATE_IP_FSYS, 12,
  0, 0),
   GATE(CLK_SROMC, sromc, div_aclk_200, GATE_IP_FSYS, 11, 0,
   0),
   +   GATE(CLK_SDMMC2, sdmmc2, div_aclk_200, GATE_IP_FSYS, 7,
 0,
  0),
   GATE(CLK_SDMMC1, sdmmc1, div_aclk_200, GATE_IP_FSYS, 6,
 0,
  0),
   GATE(CLK_SDMMC0, sdmmc0, div_aclk_200, GATE_IP_FSYS, 5,
 0,
  0),
   GATE(CLK_PDMA1, pdma1, div_aclk_200, GATE_IP_FSYS, 1, 0,
   0),
  @@
   -698,6 +707,8 @@ static struct samsung_gate_clock gate_clks[]
   __initdata
  = {
   GATE(CLK_I2C2, i2c2, div_aclk_100, GATE_IP_PERIL, 8, 0, 0),
   GATE(CLK_I2C1, i2c1, div_aclk_100, GATE_IP_PERIL, 7, 0, 0),
   GATE(CLK_I2C0, i2c0, div_aclk_100, GATE_IP_PERIL, 6, 0, 0),
   +   GATE(CLK_UART3, uart3, div_aclk_100, GATE_IP_PERIL, 3, 0,
 0),
   +   GATE(CLK_UART2, uart2, div_aclk_100, GATE_IP_PERIL, 2, 0,
   + 0),
   GATE(CLK_UART1, uart1, div_aclk_100, GATE_IP_PERIL, 1, 0, 0),
   GATE(CLK_UART0, uart0

Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related clocks

2014-09-28 Thread Kyungmin Park
On Mon, Sep 29, 2014 at 11:47 AM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 Hi Chanwoo,

 On Monday, September 29, 2014 7:42 AM, Chanwoo Choi wrote,
 To: Pankaj Dubey
 Cc: linux-arm-ker...@lists.infradead.org;
 linux-samsung-soc@vger.kernel.org;
 kgene@samsung.com; tomasz.f...@gmail.com; robh...@kernel.org;
 li...@arm.linux.org.uk; naus...@samsung.com; Mike Turquette; Sylwester
 Nawrocki
 Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related
 clocks

 Hi Pankaj,

 On 09/27/2014 01:58 PM, Pankaj Dubey wrote:
  Exynos3250 has four UART channels UART0,1,2 and 3. This patch adds
  missing clock entries for UART2 and UART3.
 
  CC: Mike Turquette mturque...@linaro.org
  CC: Sylwester Nawrocki s.nawro...@samsung.com
  Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
  ---
   drivers/clk/samsung/clk-exynos3250.c   |   11 +++
   include/dt-bindings/clock/exynos3250.h |   10 +-
   2 files changed, 20 insertions(+), 1 deletion(-)

 Exynos3250 has only two UART(0,1) port. Exynos3250 don't support UART 2,3.


 As per Exynos3250 user manual that I have with me it supports UART(0,1,2,3).
 It has been mentioned
which UM do you use? There are two UARTs at rev0.01

 in UART Chapter as well as CMU IP details also mentioned about the clock
 entries. We have tested it
 also on Espresso3250 board which is based on Exynos3250 SoC.
I can't find it at my UM.

Kyungmin Park

 Thanks,
 Pankaj Dubey

 Thanks,
 Chanwoo Choi

 
  diff --git a/drivers/clk/samsung/clk-exynos3250.c
  b/drivers/clk/samsung/clk-exynos3250.c
  index dc85f8e..0722fef 100644
  --- a/drivers/clk/samsung/clk-exynos3250.c
  +++ b/drivers/clk/samsung/clk-exynos3250.c
  @@ -357,6 +357,8 @@ static struct samsung_mux_clock mux_clks[]
 __initdata =
 {
  MUX(CLK_MOUT_MMC0, mout_mmc0, group_sclk_p, SRC_FSYS, 0, 3),
 
  /* SRC_PERIL0 */
  +   MUX(CLK_MOUT_UART3, mout_uart3, group_sclk_p, SRC_PERIL0,
 12, 4),
  +   MUX(CLK_MOUT_UART2, mout_uart2, group_sclk_p, SRC_PERIL0, 8,
 4),
  MUX(CLK_MOUT_UART1, mout_uart1, group_sclk_p, SRC_PERIL0, 4,
 4),
  MUX(CLK_MOUT_UART0, mout_uart0, group_sclk_p, SRC_PERIL0, 0,
 4),
 
  @@ -439,6 +441,8 @@ static struct samsung_div_clock div_clks[]
 __initdata = {
  DIV(CLK_DIV_MMC0, div_mmc0, mout_mmc0, DIV_FSYS1, 0, 4),
 
  /* DIV_PERIL0 */
  +   DIV(CLK_DIV_UART3, div_uart3, mout_uart3, DIV_PERIL0, 12, 4),
  +   DIV(CLK_DIV_UART2, div_uart2, mout_uart2, DIV_PERIL0, 8, 4),
  DIV(CLK_DIV_UART1, div_uart1, mout_uart1, DIV_PERIL0, 4, 4),
  DIV(CLK_DIV_UART0, div_uart0, mout_uart0, DIV_PERIL0, 0, 4),
 
  @@ -601,6 +605,10 @@ static struct samsung_gate_clock gate_clks[]
 __initdata
 = {
  GATE_SCLK_PERIL, 7, CLK_SET_RATE_PARENT, 0),
  GATE(CLK_SCLK_SPI0, sclk_spi0, div_spi0_pre,
  GATE_SCLK_PERIL, 6, CLK_SET_RATE_PARENT, 0),
  +   GATE(CLK_SCLK_UART3, sclk_uart3, div_uart3,
  +   GATE_SCLK_PERIL, 3, CLK_SET_RATE_PARENT, 0),
  +   GATE(CLK_SCLK_UART2, sclk_uart2, div_uart2,
  +   GATE_SCLK_PERIL, 2, CLK_SET_RATE_PARENT, 0),
  GATE(CLK_SCLK_UART1, sclk_uart1, div_uart1,
  GATE_SCLK_PERIL, 1, CLK_SET_RATE_PARENT, 0),
  GATE(CLK_SCLK_UART0, sclk_uart0, div_uart0, @@ -679,6 +687,7
 @@
  static struct samsung_gate_clock gate_clks[] __initdata = {
  GATE(CLK_USBOTG, usbotg, div_aclk_200, GATE_IP_FSYS, 13, 0,
 0),
  GATE(CLK_USBHOST, usbhost, div_aclk_200, GATE_IP_FSYS, 12,
 0, 0),
  GATE(CLK_SROMC, sromc, div_aclk_200, GATE_IP_FSYS, 11, 0, 0),
  +   GATE(CLK_SDMMC2, sdmmc2, div_aclk_200, GATE_IP_FSYS, 7, 0,
 0),
  GATE(CLK_SDMMC1, sdmmc1, div_aclk_200, GATE_IP_FSYS, 6, 0,
 0),
  GATE(CLK_SDMMC0, sdmmc0, div_aclk_200, GATE_IP_FSYS, 5, 0,
 0),
  GATE(CLK_PDMA1, pdma1, div_aclk_200, GATE_IP_FSYS, 1, 0, 0),
 @@
  -698,6 +707,8 @@ static struct samsung_gate_clock gate_clks[] __initdata
 = {
  GATE(CLK_I2C2, i2c2, div_aclk_100, GATE_IP_PERIL, 8, 0, 0),
  GATE(CLK_I2C1, i2c1, div_aclk_100, GATE_IP_PERIL, 7, 0, 0),
  GATE(CLK_I2C0, i2c0, div_aclk_100, GATE_IP_PERIL, 6, 0, 0),
  +   GATE(CLK_UART3, uart3, div_aclk_100, GATE_IP_PERIL, 3, 0, 0),
  +   GATE(CLK_UART2, uart2, div_aclk_100, GATE_IP_PERIL, 2, 0, 0),
  GATE(CLK_UART1, uart1, div_aclk_100, GATE_IP_PERIL, 1, 0, 0),
  GATE(CLK_UART0, uart0, div_aclk_100, GATE_IP_PERIL, 0, 0, 0),
  }; diff --git a/include/dt-bindings/clock/exynos3250.h
  b/include/dt-bindings/clock/exynos3250.h
  index b535e9d..ffeb695 100644
  --- a/include/dt-bindings/clock/exynos3250.h
  +++ b/include/dt-bindings/clock/exynos3250.h
  @@ -78,6 +78,8 @@
   #define CLK_MOUT_CORE  58
   #define CLK_MOUT_APLL  59
   #define CLK_MOUT_ACLK_266_SUB  60
  +#define CLK_MOUT_UART2 61
  +#define CLK_MOUT_UART3 62
 
   /* Dividers */
   #define CLK_DIV_GPL64
  @@ -126,6 +128,8 @@
   #define CLK_DIV_CORE   107
   #define

Re: [PATCH] drm/exynos: fix nested calls to lock mutex in drm resume

2014-05-22 Thread Kyungmin Park
add Mr. Dae

On Thu, May 22, 2014 at 11:16 PM, Rahul Sharma rahul.sha...@samsung.com wrote:
 Hi Inki,

 This is another one which has not got reviewed. Please review.

 Regards,
 Rahul Sharma

 On 30 April 2014 19:11, Rahul Sharma rahul.sha...@samsung.com wrote:
 From: Rahul Sharma rahul.sha...@samsung.com

 While testing S2R on exynos board, system is hanging and
 rebooting due to nested mutex_lock calls in exynos drm
 resume callback. Changing the order of the calls is fixing
 the issue.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
 Based on exynos-drm-next branch in Inki Dae's tree.
  drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index bb7dfee..2bb6233 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -184,8 +184,8 @@ static int exynos_drm_resume(struct drm_device *dev)
 connector-funcs-dpms(connector, connector-dpms);
 }

 -   drm_helper_resume_force_mode(dev);
 drm_modeset_unlock_all(dev);
 +   drm_helper_resume_force_mode(dev);

 return 0;
  }
 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12

2014-03-15 Thread Kyungmin Park
On Sat, Mar 15, 2014 at 2:35 AM, Tomasz Figa t.f...@samsung.com wrote:
 Hi Chanwoo, Mark,


 On 14.03.2014 11:56, Chanwoo Choi wrote:

 Hi Mark,

 On 03/14/2014 07:35 PM, Mark Rutland wrote:

 On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote:

 Hi Mark,

 On 03/14/2014 02:53 AM, Mark Rutland wrote:

 On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote:

 This patch add busfreq driver for Exynos4210/Exynos4x12 memory
 interface
 and bus to support DVFS(Dynamic Voltage Frequency Scaling) according
 to PPMU
 counters. PPMU (Performance Profiling Monitorings Units) of Exynos4
 SoC provides
 PPMU counters for DMC(Dynamic Memory Controller) to check memory bus
 utilization
 and then busfreq driver adjusts dynamically the operating
 frequency/voltage
 by using DEVFREQ Subsystem.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
   .../devicetree/bindings/devfreq/exynos4_bus.txt| 49
 ++
   1 file changed, 49 insertions(+)
   create mode 100644
 Documentation/devicetree/bindings/devfreq/exynos4_bus.txt

 diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
 b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
 new file mode 100644
 index 000..2a83fcc
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
 @@ -0,0 +1,49 @@
 +
 +Exynos4210/4x12 busfreq driver
 +-
 +
 +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus
 frequency/voltage
 +scaling according to PPMU counters of memory controllers
 +
 +Required properties:
 +- compatible   : should contain Exynos4 SoC type as follwoing:
 + - samsung,exynos4x12-busfreq for Exynos4x12
 + - samsung,exynos4210-busfreq for Exynos4210


 Is there a device called busfreq? What device does this binding
 describe?


 I'll add detailed description of busfreq as following:

 busfreq(bus frequendcy) driver means that busfreq driver control
 dynamically
 memory bus frequency/voltage by checking memory bus utilization to
 optimize
 power-consumption. When checking memeory bus utilization,
 exynos4_busfreq driver
 would use PPMU(Performance Profiling Monitoring Units).


 This still sounds like a description of the _driver_, not the _device_.
 The binding should describe the hardware, now the high level abstraction
 that software is going to build atop of it.

 It sounds like this is a binding for the DMC PPMU?

 Is the PPMU a component of the DMC, or is it bolted on the side?


 PPMU(Performance Profiling Monitoring Unit) is to profile performance
 event of
 various IP on Exynos4. Each PPMU provide perforamnce event for each IP.
 We can check various PPMU as following:

 PPMU_3D
 PPMU_ACP
 PPMU_CAMIF
 PPMU_CPU
 PPMU_DMC0
 PPMU_DMC1
 PPMU_FSYS
 PPMU_IMAGE
 PPMU_LCD0
 PPMU_LCD1
 PPMU_MFC_L
 PPMU_MFC_R
 PPMU_TV
 PPMU_LEFT_BUS
 PPMU_RIGHT_BUS

 DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4
 SoC.
 If we need to get memory bust utilization of DMC, we can get memory bus
 utilization
 from PPMU_DMC0/PPMU_DMC1.

 So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various
 PPMU list.


 Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs.
 Busfreq/devfreq is just a Linux-specific abstraction responsible for
 collecting data using PPMUs and controlling frequencies and voltages of
 appropriate power planes, vdd_int responsible for powering DMC0 and DMC1
 blocks in this case.

 I'm afraid that the binding you're proposing is unfortunately incorrect,
 because it represents the software abstraction, not the real hardware.

 Instead, this should be separated into several independent bindings:

  - PPMU bindings to list all the PPMU instances present in the SoC and
 resources they need,

  - power plane bindings, which define a power plane in which multiple IP
 blocks might reside, can be monitored by one or more PPMU units and
 frequency and voltage of which can be configured according to determined
 performance level. Needed resources will be clocks and regulators to scale
 and probably also operating points.

 Then, exynos-busfreq driver should bind to such power planes, parse
 necessary data from DT (list of PPMUs and IP blocks, clocks, regulators and
 operating points) and register a devfreq entity.

How about to use component DT like DRM?

 Best regards,
 Tomasz

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
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] iommu/exynos: Remove driver

2014-03-05 Thread Kyungmin Park
On Fri, Feb 14, 2014 at 9:17 AM, Cho KyongHo pullip@samsung.com wrote:
 -Original Message-
 From: Olof Johansson [mailto:o...@lixom.net]
 Sent: Friday, February 14, 2014 4:34 AM

 On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim kgene@gmail.com wrote:

  Just adding KyongHo Cho.
 
  If he can fixup for this time, it would be best solution because he knows
  well than others, I think.

 It's not so much a matter of fixup for this time, it's a about
 having ownership of the driver, making sure it works (and keeps
 working if there is related development). The posted patches have not
 been followed through on and the result is a broken driver. :(

 I definitely appreciate his expertise, and we should make sure that he
 gets to review the code, but if someone else is able to spend time on
 reworking the driver (or rewriting a newer one) and maintaining it
 longer-term, then we should not stop them from doing so. And there is
 no reason to keep broken stale code in the kernel meanwhile.


 Thank you for your concerning.
 I also definitely agree with you that the driver must work.
 I am always concerning about it but it was not easy to make some time
 for the patches.

 I will continue to post the next version of patches, of course.
 I think it is not far from now to show it.

Lots of time is going from last reply. there are two options.
1. just waiting more
2. remove it as patch and start it again by someone.

what's the opinions?

Thank you,
Kyungmin 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


Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

2013-11-19 Thread Kyungmin Park
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 11/19/2013 11:59 AM, Doug Anderson wrote:
 On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 11/19/2013 10:15 AM, Tomasz Figa wrote:
 This patch extends the range of settings configurable via pinfunc API
 to cover pin value as well. This allows configuration of default values
 of pins.

 Shouldn't there be a driver that acquires the GPIO that's output to the
 pin, and configures the output value? IIRC there have been previous
 discussions re: having a list of e.g. initial GPIO output values in DT,
 and that was rejected, and this patch seems to be doing almost the exact
 same thing, just at the pinctrl level rather than GPIO level.

 That all said, I admit this could be a useful feature...

 I haven't followed all of the previous discussions, but I know I've
 run into scenarios where something like this would be useful.  The one
 that comes to mind is:

 * We've got GPIOs that default at bootup to a pulled up input since
 the default state of the pin should be high.

 * These pins are really intended to be outputs, like an enable,
 reset, or power down line for a peripheral.  The pullup is strong
 enough to give us a good default state but we really want outputs.

 * We'd like to provide this GPIO to a peripheral through device tree.
 ...and we'd like all the pinmux to be setup automatically so we use
 pinctrl-names = default.

 * If we set the pinmux up as output then there's a chance that the
 line will glitch at bootup since the pinmux happens (changing the pin
 to output) before the driver has a chance to run.

 I think that last point should be addressed by having a driver that owns
 the GPIO set it to the desired output level, and the implementation of
Some pins are not connected (NC). At that cases, there's no drivers to
handle it. To reduce power leakage, it sets proper configuration with
values instead of reset values.

Thank you,
Kyungmin Park

 the SoC's GPIO driver communicate with the pinctrl driver (which might
 be the same driver; not sure here) so that gpio_direction_output()
 causes the pinctrl HW to be programmed as output only after the GPIO HW
 is programmed as output and with the correct output value. In this
 scenario, the pinctrl default state wouldn't touch the pin's
 input/output setting; that operation would be deferred until the driver
 set up the GPIO as an output.

 ___
 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 3/4] mfd: sec-core: Add cells for S5M8767-clocks

2013-11-05 Thread Kyungmin Park
On Tue, Nov 5, 2013 at 5:04 PM, Tushar Behera tushar.beh...@linaro.org wrote:
 On 5 November 2013 13:27, Kyungmin Park kmp...@infradead.org wrote:
 On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera tushar.beh...@linaro.org 
 wrote:
 On 31 October 2013 21:46, Lee Jones lee.jo...@linaro.org wrote:
 On Thu, 31 Oct 2013, Tushar Behera wrote:

 S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
 supported by s2mps11-clk driver.

 Signed-off-by: Tushar Behera tushar.beh...@linaro.org
 CC: Lee Jones lee.jo...@linaro.org
 ---
  drivers/mfd/sec-core.c |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
 index 34c18fb..020b86b 100644
 --- a/drivers/mfd/sec-core.c
 +++ b/drivers/mfd/sec-core.c
 @@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
   .name = s5m8767-pmic,
   }, {
   .name = s5m-rtc,
 - },
 + }, {
 + .name = s5m8767-clk,

 Do you want to handle these as clock? previous time, it's
 implemented at regulator. please see drivers/regulator/max* series.

 Thank you,
 Kyungmin Park

 There is already a clock-implementation available for this kind of
 device (through clk-s2mps11). I would like to extend that support.
 Also for MAX77686, it is implemented through clock subsystem.


Yes it's possible, but losts of MAX chips are implemented already with
regulator.
but in case of maxim chip. it's voltage instead of clock. doesn't
better to use regulaor?

Ah I confused between 32KHz and Safeout. okay it's 32KHz clock. okay
it's better to use clock.

Ignore previous comments.

Thank you,
Kyungmin 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


Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks

2013-11-04 Thread Kyungmin Park
On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera tushar.beh...@linaro.org wrote:
 On 31 October 2013 21:46, Lee Jones lee.jo...@linaro.org wrote:
 On Thu, 31 Oct 2013, Tushar Behera wrote:

 S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
 supported by s2mps11-clk driver.

 Signed-off-by: Tushar Behera tushar.beh...@linaro.org
 CC: Lee Jones lee.jo...@linaro.org
 ---
  drivers/mfd/sec-core.c |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
 index 34c18fb..020b86b 100644
 --- a/drivers/mfd/sec-core.c
 +++ b/drivers/mfd/sec-core.c
 @@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
   .name = s5m8767-pmic,
   }, {
   .name = s5m-rtc,
 - },
 + }, {
 + .name = s5m8767-clk,

Do you want to handle these as clock? previous time, it's
implemented at regulator. please see drivers/regulator/max* series.

Thank you,
Kyungmin Park
 + }
  };

  static struct mfd_cell s2mps11_devs[] = {

 Acked-by: Lee Jones lee.jo...@linaro.org


 Thanks.

 I'd prefer to take this patch in via the MFD tree once you have
 support from the other maintainers for the set.


 Ok. I will let you know once I get the clock patches through.

 --
 Tushar Behera

 ___
 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 v2] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

2013-10-15 Thread Kyungmin Park
On Tue, Oct 15, 2013 at 3:23 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
 For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
 on a fixed 66 MHz peripheral clock, and therefore is completely
 independent of the cpu frequency.
 Thus, registering for a CPU freq notifier is very wasteful.

 This patch modifes the code such that, i2c bus registers to
 cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.

 This change should save a bunch of cpufreq transitions calls
 which does not apply to exynos SoCs.

 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 Changes since v1:
 Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ  !CONFIG_EXYNOS)
 As commented by Tomasz

  drivers/i2c/busses/i2c-s3c2410.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/i2c/busses/i2c-s3c2410.c 
 b/drivers/i2c/busses/i2c-s3c2410.c
 index cab1c91..97f14f7 100644
 --- a/drivers/i2c/busses/i2c-s3c2410.c
 +++ b/drivers/i2c/busses/i2c-s3c2410.c
 @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
 struct s3c2410_platform_i2c *pdata;
 int gpios[2];
 struct pinctrl  *pctrl;
 -#ifdef CONFIG_CPU_FREQ
 +#if defined(CONFIG_CPU_FREQ_S3C24XX)
 struct notifier_block   freq_transition;
  #endif
  };
 @@ -843,7 +843,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c, 
 unsigned int *got)
 return 0;
  }

 -#ifdef CONFIG_CPU_FREQ
 +#if defined(CONFIG_CPU_FREQ_S3C24XX)

  #define freq_to_i2c(_n) container_of(_n, struct s3c24xx_i2c, freq_transition)

 --
 1.7.10.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
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 1/2] MAINTAINERS: Add Samsung pinctrl entries

2013-06-16 Thread Kyungmin Park
On Mon, Jun 17, 2013 at 7:17 AM, Doug Anderson diand...@chromium.org wrote:
 It's convenient if get_maintainer suggests sending samsung/exynos
 pinctrl changes to linux-samsung-soc and to Tomasz and Thomas.

 Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 Changes in v2:
 - Updated with Thomas and Tomasz; removed Linus since he's already
   there as part of the general pinctrl match.

  MAINTAINERS | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 8d97b3e..f55e3c7 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -6284,6 +6284,16 @@ L:   linux-arm-ker...@lists.infradead.org 
 (moderated for non-subscribers)
  S: Maintained
  F: drivers/pinctrl/pinctrl-at91.c

 +PIN CONTROLLER - SAMSUNG
 +M: Tomasz Figa t.f...@samsung.com
 +M: Thomas Abraham thomas.abra...@linaro.org
 +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
 +S: Maintained
 +F: drivers/pinctrl/pinctrl-exynos.*
 +F: drivers/pinctrl/pinctrl-s3c*
 +F: drivers/pinctrl/pinctrl-samsung.*
 +
  PIN CONTROLLER - ST SPEAR
  M: Viresh Kumar viresh.li...@gmail.com
  L: spear-de...@list.st.com
 --
 1.8.3

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
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 02/30] ARM: exynos: prepare for sparse IRQ

2013-04-10 Thread Kyungmin Park
On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann a...@arndb.de wrote:
 When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in
 the machine_desc for legacy IRQ domains, and any file referring to the
 number of interrupts or a specific number must include the mach/irqs.h
 header file explicitly.

It's really wanted feature.

 Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/dev-uart.c  | 1 +
  arch/arm/mach-exynos/include/mach/irqs.h | 5 -
  arch/arm/mach-exynos/mach-armlex4210.c   | 2 ++
  arch/arm/mach-exynos/mach-exynos4-dt.c   | 3 +++
  arch/arm/mach-exynos/mach-exynos5-dt.c   | 2 ++
  arch/arm/mach-exynos/mach-nuri.c | 2 ++
  arch/arm/mach-exynos/mach-origen.c   | 2 ++
  arch/arm/mach-exynos/mach-smdk4x12.c | 2 ++
  arch/arm/mach-exynos/mach-smdkv310.c | 3 +++
  arch/arm/plat-samsung/irq-vic-timer.c| 1 +
  arch/arm/plat-samsung/pm.c   | 1 +
  arch/arm/plat-samsung/s5p-irq.c  | 1 +
  12 files changed, 24 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c
 index 7c42f4b..c48aff0 100644
 --- a/arch/arm/mach-exynos/dev-uart.c
 +++ b/arch/arm/mach-exynos/dev-uart.c
 @@ -20,6 +20,7 @@
  #include asm/mach/irq.h
  #include mach/hardware.h
  #include mach/map.h
 +#include mach/irqs.h

  #include plat/devs.h

 diff --git a/arch/arm/mach-exynos/include/mach/irqs.h 
 b/arch/arm/mach-exynos/include/mach/irqs.h
 index 35fe6d5..c72f59d 100644
 --- a/arch/arm/mach-exynos/include/mach/irqs.h
 +++ b/arch/arm/mach-exynos/include/mach/irqs.h
 @@ -467,7 +467,10 @@
  #define IRQ_TIMER_BASE (IRQ_GPIO_END + 64)

  /* Set the default NR_IRQS */
 +#define EXYNOS_NR_IRQS (IRQ_TIMER_BASE + IRQ_TIMER_COUNT)

 -#define NR_IRQS(IRQ_TIMER_BASE + 
 IRQ_TIMER_COUNT)
 +#ifndef CONFIG_SPARSE_IRQ
 +#define NR_IRQSEXYNOS_NR_IRQS
 +#endif

  #endif /* __ASM_ARCH_IRQS_H */
 diff --git a/arch/arm/mach-exynos/mach-armlex4210.c 
 b/arch/arm/mach-exynos/mach-armlex4210.c
 index 2c23b65..a503e02 100644
 --- a/arch/arm/mach-exynos/mach-armlex4210.c
 +++ b/arch/arm/mach-exynos/mach-armlex4210.c
 @@ -25,6 +25,7 @@
  #include plat/regs-srom.h
  #include plat/sdhci.h

 +#include mach/irqs.h
  #include mach/map.h

  #include common.h
 @@ -196,6 +197,7 @@ static void __init armlex4210_machine_init(void)
  MACHINE_START(ARMLEX4210, ARMLEX4210)
 /* Maintainer: Alim Akhtar alim.akh...@samsung.com */
 .atag_offset= 0x100,
 +   .nr_irqs= EXYNOS_NR_IRQS,
 .smp= smp_ops(exynos_smp_ops),
 .init_irq   = exynos4_init_irq,
 .map_io = armlex4210_map_io,
 diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c 
 b/arch/arm/mach-exynos/mach-exynos4-dt.c
 index b9ed834..5f23682 100644
 --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
 +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
 @@ -20,6 +20,8 @@

  #include asm/mach/arch.h
  #include plat/mfc.h
 +#include mach/irqs.h
 +

  #include common.h

 @@ -54,6 +56,7 @@ static void __init exynos4_reserve(void)
  }
  DT_MACHINE_START(EXYNOS4210_DT, Samsung Exynos4 (Flattened Device Tree))
 /* Maintainer: Thomas Abraham thomas.abra...@linaro.org */
 +   .nr_irqs= EXYNOS_NR_IRQS,
 .smp= smp_ops(exynos_smp_ops),
 .init_irq   = exynos4_init_irq,
 .map_io = exynos4_dt_map_io,
 diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c 
 b/arch/arm/mach-exynos/mach-exynos5-dt.c
 index 753b94f..8b7456a 100644
 --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
 +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
 @@ -16,6 +16,7 @@
  #include linux/clocksource.h

  #include asm/mach/arch.h
 +#include mach/irqs.h
  #include mach/regs-pmu.h

  #include plat/cpu.h
 @@ -76,6 +77,7 @@ static void __init exynos5_reserve(void)

  DT_MACHINE_START(EXYNOS5_DT, SAMSUNG EXYNOS5 (Flattened Device Tree))
 /* Maintainer: Kukjin Kim kgene@samsung.com */
 +   .nr_irqs= EXYNOS_NR_IRQS,
 .init_irq   = exynos5_init_irq,
 .smp= smp_ops(exynos_smp_ops),
 .map_io = exynos5_dt_map_io,
 diff --git a/arch/arm/mach-exynos/mach-nuri.c 
 b/arch/arm/mach-exynos/mach-nuri.c
 index 0c10852..fbae331 100644
 --- a/arch/arm/mach-exynos/mach-nuri.c
 +++ b/arch/arm/mach-exynos/mach-nuri.c
 @@ -53,6 +53,7 @@
  #include plat/fimc-core.h
  #include plat/camport.h

 +#include mach/irqs.h
  #include mach/map.h

  #include common.h
 @@ -1376,6 +1377,7 @@ static void __init nuri_machine_init(void)
  MACHINE_START(NURI, NURI)
 /* Maintainer: Kyungmin Park kyungmin.p...@samsung.com */
 .atag_offset= 0x100,
 +   .nr_irqs= EXYNOS_NR_IRQS,
 .smp= smp_ops(exynos_smp_ops),
 .init_irq   = exynos4_init_irq,
 .map_io

Re: [PATCH 15/30] mtd: onenand/samsung: make regs-onenand.h file local

2013-04-10 Thread Kyungmin Park
Thanks Arnd.

On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann a...@arndb.de wrote:
 Nothing uses the NAND register definitions other than the
 actual driver, so we can move the header file into the
 same local directory, which lets us build it in a multiplatform
 configuration.

 Signed-off-by: Arnd Bergmann a...@arndb.de
 Cc: linux-...@lists.infradead.org
 Cc: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Cc: David Woodhouse dw...@infradead.org
 ---
  drivers/mtd/onenand/samsung.c | 4 
 ++--
  .../include/plat/regs-onenand.h = drivers/mtd/onenand/samsung.h  | 2 --
  2 files changed, 2 insertions(+), 4 deletions(-)
  rename arch/arm/plat-samsung/include/plat/regs-onenand.h = 
 drivers/mtd/onenand/samsung.h (98%)

 diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
 index 33f2a8f..2cf7408 100644
 --- a/drivers/mtd/onenand/samsung.c
 +++ b/drivers/mtd/onenand/samsung.c
 @@ -23,11 +23,11 @@
  #include linux/mtd/partitions.h
  #include linux/dma-mapping.h
  #include linux/interrupt.h
 +#include linux/io.h

  #include asm/mach/flash.h
 -#include plat/regs-onenand.h

 -#include linux/io.h
 +#include samsung.h

  enum soc_type {
 TYPE_S3C6400,
 diff --git a/arch/arm/plat-samsung/include/plat/regs-onenand.h 
 b/drivers/mtd/onenand/samsung.h
 similarity index 98%
 rename from arch/arm/plat-samsung/include/plat/regs-onenand.h
 rename to drivers/mtd/onenand/samsung.h
 index 930ea8b..c4a80e6 100644
 --- a/arch/arm/plat-samsung/include/plat/regs-onenand.h
 +++ b/drivers/mtd/onenand/samsung.h
 @@ -11,8 +11,6 @@
  #ifndef __SAMSUNG_ONENAND_H__
  #define __SAMSUNG_ONENAND_H__

 -#include mach/hardware.h
 -
  /*
   * OneNAND Controller
   */
 --
 1.8.1.2


 __
 Linux MTD discussion mailing list
 http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
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] clk: samsung: always allocate the clk_table

2013-03-12 Thread Kyungmin Park
On Tue, Mar 12, 2013 at 10:48 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
 On 03/12/2013 12:46 PM, Thomas Abraham wrote:
 And, you mentioned Exynos4 will be dt-only from 3.10. Does that mean
 we just drop support for universal and nuri non-dt board support? Or,
 will there be a equivalent dt support added for these boards?

 I think Tomasz has some initial dts files for Universal_c210 ready, and
 Nuri could probably just be dropped. But we need Kyungmin's opinion on
 that.
Agree.
Tomasz will send unviersal DT files soon.

Thank you,
Kyungmin Park

 I'm not sure about other boards, they look pretty basic though.
 So it shouldn't be difficult to replace them with corresponding dts
 files. Currently there are:

 arch/arm/mach-exynos/mach-smdk4x12.c
 arch/arm/mach-exynos/mach-origen.c
 arch/arm/mach-exynos/mach-nuri.c
 arch/arm/mach-exynos/mach-universal_c210.c
 arch/arm/mach-exynos/mach-armlex4210.c
 arch/arm/mach-exynos/mach-smdkv310.c

 And there are dts files for:

 arch/arm/boot/dts/exynos4210-smdkv310.dts
 arch/arm/boot/dts/exynos4210-origen.dts
 arch/arm/boot/dts/exynos5250-smdk5250.dts
 arch/arm/boot/dts/exynos5250-snow.dts
 arch/arm/boot/dts/exynos4210-trats.dts
 arch/arm/boot/dts/exynos5440-ssdk5440.dts
 arch/arm/boot/dts/exynos4412-smdk4412.dts

 So except Universal_c210 and Nuri the only ones not supporting booting
 from DT are these two simple boards, which seem to be maintained by
 Samsung:

 arch/arm/mach-exynos/mach-smdk4x12.c
 arch/arm/mach-exynos/mach-armlex4210.c

 It would be nice to make Exynos DT only in this kernel release.
 I guess there was enough time to get all boards converted to DT
 already.

 --

 Regards,
 Sylwester

 ___
 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] ARM: EXYNOS: Keep USB related LDOs always active on Origen

2013-02-26 Thread Kyungmin Park
Hi,

On Fri, Feb 22, 2013 at 3:48 PM, Tushar Behera tushar.beh...@linaro.org wrote:
 LDO3 and LDO8 are used for powering both device and host phy controllers.
 These regulators are not handled in USB host driver. Hence we get
 unexpected behaviour when the regulators are disabled elsewhere.

 It would be best to keep these regulators always on.
No, it's just workaround patch.

It should be handled at USB drivers.
we usually used this scheme enable USB power always. but it consumes
lots of power.
There's no need to enable usb power when there's no usb connection.

So I suggest to enable power when usb is connected only.

In our case, micro IC detects the usb connection and enable usb power
at that time.

Thank you,
Kyungmin Park

 Signed-off-by: Tushar Behera tushar.beh...@linaro.org
 ---

 Based on v3.8.

  arch/arm/mach-exynos/mach-origen.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-origen.c 
 b/arch/arm/mach-exynos/mach-origen.c
 index 5e34b9c..7351063 100644
 --- a/arch/arm/mach-exynos/mach-origen.c
 +++ b/arch/arm/mach-exynos/mach-origen.c
 @@ -169,6 +169,7 @@ static struct regulator_init_data __initdata 
 max8997_ldo3_data = {
 .min_uV = 110,
 .max_uV = 110,
 .apply_uV   = 1,
 +   .always_on  = 1,
 .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 .state_mem  = {
 .disabled   = 1,
 @@ -227,6 +228,7 @@ static struct regulator_init_data __initdata 
 max8997_ldo8_data = {
 .min_uV = 330,
 .max_uV = 330,
 .apply_uV   = 1,
 +   .always_on  = 1,
 .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 .state_mem  = {
 .disabled   = 1,
 --
 1.7.4.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
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 v6 07/16] ARM: Exynos: Initialize the clocks prior to timer initialization

2013-02-18 Thread Kyungmin Park
  = mct_init,
 +   .init_time  = exynos_init_time,
 .reserve= origen_reserve,
 .restart= exynos4_restart,
  MACHINE_END
 diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c 
 b/arch/arm/mach-exynos/mach-smdk4x12.c
 index c56cc21..71422ad 100644
 --- a/arch/arm/mach-exynos/mach-smdk4x12.c
 +++ b/arch/arm/mach-exynos/mach-smdk4x12.c
 @@ -377,7 +377,7 @@ MACHINE_START(SMDK4212, SMDK4212)
 .map_io = smdk4x12_map_io,
 .handle_irq = gic_handle_irq,
 .init_machine   = smdk4x12_machine_init,
 -   .init_time  = mct_init,
 +   .init_time  = exynos_init_time,
 .restart= exynos4_restart,
 .reserve= smdk4x12_reserve,
  MACHINE_END
 @@ -392,7 +392,7 @@ MACHINE_START(SMDK4412, SMDK4412)
 .handle_irq = gic_handle_irq,
 .init_machine   = smdk4x12_machine_init,
 .init_late  = exynos_init_late,
 -   .init_time  = mct_init,
 +   .init_time  = exynos_init_time,
 .restart= exynos4_restart,
 .reserve= smdk4x12_reserve,
  MACHINE_END
 diff --git a/arch/arm/mach-exynos/mach-smdkv310.c 
 b/arch/arm/mach-exynos/mach-smdkv310.c
 index 9d511f5..eb51c06 100644
 --- a/arch/arm/mach-exynos/mach-smdkv310.c
 +++ b/arch/arm/mach-exynos/mach-smdkv310.c
 @@ -424,7 +424,7 @@ MACHINE_START(SMDKV310, SMDKV310)
 .map_io = smdkv310_map_io,
 .handle_irq = gic_handle_irq,
 .init_machine   = smdkv310_machine_init,
 -   .init_time  = mct_init,
 +   .init_time  = exynos_init_time,
 .reserve= smdkv310_reserve,
 .restart= exynos4_restart,
  MACHINE_END
 @@ -438,7 +438,7 @@ MACHINE_START(SMDKC210, SMDKC210)
 .handle_irq = gic_handle_irq,
 .init_machine   = smdkv310_machine_init,
 .init_late  = exynos_init_late,
 -   .init_time  = mct_init,
 +   .init_time  = exynos_init_time,
 .reserve= smdkv310_reserve,
 .restart= exynos4_restart,
  MACHINE_END
 diff --git a/arch/arm/mach-exynos/mach-universal_c210.c 
 b/arch/arm/mach-exynos/mach-universal_c210.c
 index 3998c81..53de074 100644
 --- a/arch/arm/mach-exynos/mach-universal_c210.c
 +++ b/arch/arm/mach-exynos/mach-universal_c210.c
 @@ -1144,6 +1144,12 @@ static void __init universal_machine_init(void)
 platform_add_devices(universal_devices, 
 ARRAY_SIZE(universal_devices));
  }

 +static void __init universal_init_time(void)
 +{
 +   exynos4_clk_init(NULL);
 +   mct_init();
No, It's not support MCT timer at universal board, please don't modify
universal board at this time.
Others are okay.

Thank you,
Kyungmin Park
 +}
 +
  MACHINE_START(UNIVERSAL_C210, UNIVERSAL_C210)
 /* Maintainer: Kyungmin Park kyungmin.p...@samsung.com */
 .atag_offset= 0x100,
 @@ -1153,7 +1159,7 @@ MACHINE_START(UNIVERSAL_C210, UNIVERSAL_C210)
 .handle_irq = gic_handle_irq,
 .init_machine   = universal_machine_init,
 .init_late  = exynos_init_late,
 -   .init_time  = samsung_timer_init,
 +   .init_time  = universal_init_time,
 .reserve= universal_reserve,
 .restart= exynos4_restart,
  MACHINE_END
 --
 1.7.5.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 00/12] ARM: samsung-time: Prepare for multiplatform support

2013-02-10 Thread Kyungmin Park
On Sun, Feb 10, 2013 at 10:32 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Seems like several mail addresses of board maintainers are no longer
 valid.

 guillaume.gou...@nexvision.tv
 mentioned in:
 arch/arm/mach-s3c24xx/mach-nexcoder.c
 arch/arm/mach-s3c24xx/mach-otom.c

 arhu...@freaks-unidos.net
 mentioned in:
 arch/arm/mach-s3c24xx/mach-gta02.c

 dand...@amltd.com
 mentioned in:
 arch/arm/mach-s3c24xx/mach-amlm5900.c
 arch/arm/mach-s3c24xx/mach-tct_hammer.c

 bh...@samsung.com
 mentioned in:
 arch/arm/mach-s5pc100/mach-smdkc100
 and a bunch of files in arch/arm/mach-s5pc100
FYI: He's left the company. and he doesn't work it anymore, so you can drop him.

Thank you,
Kyungmin Park

 I wonder if we should do anything with them?

 Best regards,
 Tomasz

 On Sunday 10 of February 2013 14:20:11 Tomasz Figa wrote:
 This series is an attempt to make the samsung-time clocksource driver
 ready for multiplatform kernels. It moves the driver to
 drivers/clocksource, cleans it up from uses of static platform-specific
 definitions, simplifies timer interrupt handling and adds Device Tree
 support.

 Tested on a Tiny6410 board (Mini6410-compatible) both with and without
 Devicee Tree (with my DT patches for S3C64xx). Compile tested for other
 related archs.

 Tomasz Figa (12):
   ARM: SAMSUNG: Move samsung-time to drivers/clocksource
   clocksource: samsung-time: Set platform-specific parameters at runtime
 clocksource: samsung-time: Drop useless defines from public header
 clocksource: samsung-time: Move samsung-time.h header to include/linux
 clocksource: samsung-time: Use local register definitions
   clocksource: samsung-time: Remove use of static register mapping
   clocksource: samsung-time: Use clk_get_sys for getting clocks
   ARM: SAMSUNG: devs: Drop unnecessary IRQ resources of timer devices
   clocksource: samsung-time: Do not use static IRQ definition
   clocksource: samsung-time: Move IRQ mask/ack handling to the driver
   ARM: SAMSUNG: Remove unused PWM timer IRQ chip code
   clocksource: samsung-time: Add Device Tree support

  .../devicetree/bindings/arm/samsung-timer.txt  |  32 ++
  arch/arm/Kconfig   |   1 -
  arch/arm/mach-exynos/include/mach/irqs.h   |   3 +-
  arch/arm/mach-exynos/mach-universal_c210.c |  15 +-
  arch/arm/mach-s3c24xx/common.c |  14 +
  arch/arm/mach-s3c24xx/mach-amlm5900.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-anubis.c|   2 +-
  arch/arm/mach-s3c24xx/mach-at2440evb.c |   2 +-
  arch/arm/mach-s3c24xx/mach-bast.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-gta02.c |   2 +-
  arch/arm/mach-s3c24xx/mach-h1940.c |   2 +-
  arch/arm/mach-s3c24xx/mach-jive.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-mini2440.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-n30.c   |   2 +-
  arch/arm/mach-s3c24xx/mach-nexcoder.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-osiris.c|   2 +-
  arch/arm/mach-s3c24xx/mach-otom.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-qt2410.c|   2 +-
  arch/arm/mach-s3c24xx/mach-rx1950.c|   2 +-
  arch/arm/mach-s3c24xx/mach-rx3715.c|   2 +-
  arch/arm/mach-s3c24xx/mach-smdk2410.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-smdk2413.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-smdk2416.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-smdk2440.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-smdk2443.c  |   2 +-
  arch/arm/mach-s3c24xx/mach-tct_hammer.c|   2 +-
  arch/arm/mach-s3c24xx/mach-vr1000.c|   2 +-
  arch/arm/mach-s3c24xx/mach-vstms.c |   2 +-
  arch/arm/mach-s3c64xx/common.c |  19 +-
  arch/arm/mach-s3c64xx/include/mach/irqs.h  |   8 -
  arch/arm/mach-s3c64xx/mach-anw6410.c   |   2 +-
  arch/arm/mach-s3c64xx/mach-crag6410.c  |   2 +-
  arch/arm/mach-s3c64xx/mach-hmt.c   |   2 +-
  arch/arm/mach-s3c64xx/mach-mini6410.c  |   2 +-
  arch/arm/mach-s3c64xx/mach-ncp.c   |   2 +-
  arch/arm/mach-s3c64xx/mach-real6410.c  |   2 +-
  arch/arm/mach-s3c64xx/mach-smartq.c|   2 +-
  arch/arm/mach-s3c64xx/mach-smartq5.c   |   2 +-
  arch/arm/mach-s3c64xx/mach-smartq7.c   |   2 +-
  arch/arm/mach-s3c64xx/mach-smdk6400.c  |   2 +-
  arch/arm/mach-s3c64xx/mach-smdk6410.c  |   2 +-
  arch/arm/mach-s5p64x0/common.c |  15 +
  arch/arm/mach-s5p64x0/include/mach/irqs.h  |   2 -
  arch/arm/mach-s5p64x0/mach-smdk6440.c  |   2 +-
  arch/arm/mach-s5p64x0/mach-smdk6450.c  |   2

Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree

2013-02-05 Thread Kyungmin Park
On Wed, Feb 6, 2013 at 9:42 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/05/2013 05:37 PM, Sean Paul wrote:
 On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 n 02/05/2013 04:42 PM, Sean Paul wrote:
 Use the compatible string in the device tree to determine which
 registers/functions to use in the HDMI driver. Also changes the
 references from v13 to 4210 and v14 to 4212 to reflect the IP
 block version instead of the HDMI version.

 diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
 b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt

 Binding looks sane to me.

 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c

  #ifdef CONFIG_OF
  static struct of_device_id hdmi_match_types[] = {
   {
 - .compatible = samsung,exynos5-hdmi,
 - .data   = (void *)HDMI_TYPE14,
 + .compatible = samsung,exynos4-hdmi,
   }, {
   /* end node */
   }

 Why not fill in all the base compatible values there (I think you need
 this anyway so that DTs don't all have to be compatible with
 samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
 values, then ...


 At the moment, all DTs have to be compatible with exynos4-hdmi since
 it provides the base for the current driver. The driver uses 4210 and
 4212 to differentiate between different register addresses and
 features, but most things are just exynos4-hdmi compatible.
I would like to distinguish between 4210 and 4x12. since it has
different features. e.g., HDMI v1.3 and v1.4.
and I also want to use 4412 instead of 4212. there's no board to use
4212 at mainline until this time.

Thank you,
Kyungmin Park

 The DT nodes should include only the compatible values that the HW is
 actually compatible with. If the HW isn't compatible with exynos4-hdmi,
 that value shouldn't be in the compatible property, but instead whatever
 the base value that the HW really is compatible with. The driver can
 support multiple base compatible values from this table.

 @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)

 +
 + if (of_device_is_compatible(dev-of_node, samsung,exynos4210-hdmi))
 + hdata-version |= HDMI_VER_EXYNOS4210;
 + if (of_device_is_compatible(dev-of_node, samsung,exynos4212-hdmi))
 + hdata-version |= HDMI_VER_EXYNOS4212;
 + if (of_device_is_compatible(dev-of_node, samsung,exynos5250-hdmi))
 + hdata-version |= HDMI_VER_EXYNOS5250;

 Instead of that, do roughly:

 match = of_match_device(hdmi_match_types, pdev-dev);
 if (match)
 hdata-version |= (int)match-data;

 That way, it's all table-based. Any future additions to
 hdmi_match_types[] won't require another if statement to be added to
 probe().

 I don't think it's that easy. of_match_device returns the first match
 from the device table, so I'd still need to iterate through the
 matches. I could still break this out into a table, but I don't think
 of_match_device is the right way to probe it.

 You shouldn't have to iterate over multiple matches. of_match_device()
 is supposed to return the match for the first entry in the compatible
 property, then if there was no match, move on to looking at the next
 entry in the compatible property, etc. In practice, I think it's still
 not implemented quite correctly for this, but you can make it work by
 putting the newest compatible value first in the match table.

 ___
 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] I2C: EXYNOS: Add slave support to i2c

2012-12-03 Thread Kyungmin Park
Hi,

On Mon, Dec 3, 2012 at 9:16 PM, Giridhar Maruthy
giridhar.maru...@linaro.org wrote:
 This patch adds slave support to i2c. The dt entry i2c-mode
 decides at probe time if the controller needs to work in
 slave mode and the controller is accordingly programmed.

 Signed-off-by: Giridhar Maruthy giridhar.maru...@linaro.org
 ---
  drivers/i2c/busses/i2c-s3c2410.c |  100
 ++
  1 file changed, 68 insertions(+), 32 deletions(-)

 diff --git a/drivers/i2c/busses/i2c-s3c2410.c
 b/drivers/i2c/busses/i2c-s3c2410.c
 index e93e7d6..d83a6d7 100644
 --- a/drivers/i2c/busses/i2c-s3c2410.c
 +++ b/drivers/i2c/busses/i2c-s3c2410.c
 @@ -53,6 +53,9 @@
  /* Max time to wait for bus to become idle after a xfer (in us) */
  #define S3C2410_IDLE_TIMEOUT   5000

 +/* To find the master/slave mode of current controller */
 +#define is_master(i2c) (!i2c-i2c_mode)
 +
  /* i2c controller state */
  enum s3c24xx_i2c_state {
 STATE_IDLE,
 @@ -89,6 +92,8 @@ struct s3c24xx_i2c {
  #ifdef CONFIG_CPU_FREQ
 struct notifier_block   freq_transition;
  #endif
 +   /* i2c_mode: 0 is for master; and 1 is for slave */
 +   unsigned inti2c_mode;
If it's used for master or not, doesn't better to use 'is_master' or
'is_slave'? what's the meaning of 'i2c_mode'?
and
#define is_master(i2c) (i2c-is_master)

Thank you,
Kyungmin Park
  };

  static struct platform_device_id s3c24xx_driver_ids[] = {
 @@ -202,11 +207,21 @@ static void s3c24xx_i2c_message_start(struct
 s3c24xx_i2c *i2c,
 stat = 0;
 stat |=  S3C2410_IICSTAT_TXRXEN;

 -   if (msg-flags  I2C_M_RD) {
 -   stat |= S3C2410_IICSTAT_MASTER_RX;
 -   addr |= 1;
 -   } else
 -   stat |= S3C2410_IICSTAT_MASTER_TX;
 +   if (is_master(i2c)) {
 +   /* Master mode */
 +   if (msg-flags  I2C_M_RD) {
 +   stat |= S3C2410_IICSTAT_MASTER_RX;
 +   addr |= 1;
 +   } else
 +   stat |= S3C2410_IICSTAT_MASTER_TX;
 +   } else {
 +   /* Slave mode */
 +   if (msg-flags  I2C_M_RD) {
 +   stat |= S3C2410_IICSTAT_SLAVE_RX;
 +   addr |= 1;
 +   } else
 +   stat |= S3C2410_IICSTAT_SLAVE_TX;
 +   }

 if (msg-flags  I2C_M_REV_DIR_ADDR)
 addr ^= 1;
 @@ -228,8 +243,10 @@ static void s3c24xx_i2c_message_start(struct
 s3c24xx_i2c *i2c,
 dev_dbg(i2c-dev, iiccon, %08lx\n, iiccon);
 writel(iiccon, i2c-regs + S3C2410_IICCON);

 -   stat |= S3C2410_IICSTAT_START;
 -   writel(stat, i2c-regs + S3C2410_IICSTAT);
 +   if (is_master(i2c)) {
 +   stat |= S3C2410_IICSTAT_START;
 +   writel(stat, i2c-regs + S3C2410_IICSTAT);
 +   }
  }

  static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c *i2c, int ret)
 @@ -272,14 +289,19 @@ static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c
 *i2c, int ret)
  * devices, the host as Master and the HDMIPHY device as the slave.
  * Skipping the STOP condition has been tested on this bus and
 works.
  */
 -   if (i2c-quirks  QUIRK_HDMIPHY) {
 -   /* Stop driving the I2C pins */
 -   iicstat = ~S3C2410_IICSTAT_TXRXEN;
 -   } else {
 -   /* stop the transfer */
 -   iicstat = ~S3C2410_IICSTAT_START;
 +   if (is_master(i2c)) {
 +   if (i2c-quirks  QUIRK_HDMIPHY) {
 +   /* Stop driving the I2C pins */
 +   iicstat = ~S3C2410_IICSTAT_TXRXEN;
 +   } else {
 +   /* stop the transfer */
 +   if (is_master(i2c)) {
 +   /* Start/Stop required only for master */
 +   iicstat = ~S3C2410_IICSTAT_START;
 +   }
 +   }
 +   writel(iicstat, i2c-regs + S3C2410_IICSTAT);
 }
 -   writel(iicstat, i2c-regs + S3C2410_IICSTAT);

 i2c-state = STATE_STOP;

 @@ -348,7 +370,8 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
 unsigned long iicstat)
  */

 if (iicstat  S3C2410_IICSTAT_LASTBIT 
 -   !(i2c-msg-flags  I2C_M_IGNORE_NAK)) {
 +   !(i2c-msg-flags  I2C_M_IGNORE_NAK) 
 +   is_master(i2c)) {
 /* ack was not received... */

 dev_dbg(i2c-dev, ack was not received\n);
 @@ -380,7 +403,7 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
 unsigned long iicstat)
  * end of the message, and if so, work out what to do
  */

 -   if (!(i2c-msg-flags  I2C_M_IGNORE_NAK)) {
 +   if (!(i2c-msg-flags  I2C_M_IGNORE_NAK)  is_master(i2c))
 {
 if (iicstat  S3C2410_IICSTAT_LASTBIT

Re: [PATCH 1/2] i2c-s3c2410: Leave the bus disabled unless it is in use

2012-11-29 Thread Kyungmin Park
Acked-by: Kyungmin Park kyungmin.p...@samsung.com

On Thu, Nov 29, 2012 at 2:05 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
 From: Simon Glass s...@chromium.org

 There is a rather odd feature of the exynos i2c controller that if it
 is left enabled, it can lock itself up with the clk line held low.
 This makes the bus unusable.

 Unfortunately, the s3c24xx_i2c_set_master() function does not notice
 this, and reports a timeout. From then on the bus cannot be used until
 the AP is rebooted.

 The problem happens when any sort of interrupt occurs (e.g. due to a
 bus transition) when we are not in the middle of a transaction. We
 have seen many instances of this when U-Boot leaves the bus apparently
 happy, but Linux cannot access it.

 The current code is therefore pretty fragile.

 This fixes things by leaving the bus disabled unless we are actually
 in a transaction. We enable the bus at the start of the transaction and
 disable it at the end. That way we won't get interrupts and will not
 lock up the bus.

 It might be possible to clear pending interrupts on start-up, but this
 seems to be a more robust solution. We can't service interrupts when
 we are not in a transaction, and anyway would rather not lock up the
 bus while we try.

 Signed-off-by: Simon Glass s...@chromium.org
 Cc: Grant Grundler grund...@chromium.org
 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 ---
  drivers/i2c/busses/i2c-s3c2410.c |   37 +
  1 file changed, 33 insertions(+), 4 deletions(-)

 diff --git a/drivers/i2c/busses/i2c-s3c2410.c 
 b/drivers/i2c/busses/i2c-s3c2410.c
 index e93e7d6..2fd346d 100644
 --- a/drivers/i2c/busses/i2c-s3c2410.c
 +++ b/drivers/i2c/busses/i2c-s3c2410.c
 @@ -186,6 +186,31 @@ static inline void s3c24xx_i2c_enable_irq(struct 
 s3c24xx_i2c *i2c)
 writel(tmp | S3C2410_IICCON_IRQEN, i2c-regs + S3C2410_IICCON);
  }

 +/*
 + * Disable the bus so that we won't get any interrupts from now on, or try
 + * to drive any lines. This is the default state when we don't have
 + * anything to send/receive.
 + *
 + * If there is an event on the bus, or we have a pre-existing event at
 + * kernel boot time, we may not notice the event and the I2C controller
 + * will lock the bus with the I2C clock line low indefinitely.
 + */
 +static inline void s3c24xx_i2c_disable_bus(struct s3c24xx_i2c *i2c)
 +{
 +   unsigned long tmp;
 +
 +   /* Stop driving the I2C pins */
 +   tmp = readl(i2c-regs + S3C2410_IICSTAT);
 +   tmp = ~S3C2410_IICSTAT_TXRXEN;
 +   writel(tmp, i2c-regs + S3C2410_IICSTAT);
 +
 +   /* We don't expect any interrupts now, and don't want send acks */
 +   tmp = readl(i2c-regs + S3C2410_IICCON);
 +   tmp = ~(S3C2410_IICCON_IRQEN | S3C2410_IICCON_IRQPEND |
 +   S3C2410_IICCON_ACKEN);
 +   writel(tmp, i2c-regs + S3C2410_IICCON);
 +}
 +

  /* s3c24xx_i2c_message_start
   *
 @@ -646,7 +671,11 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,

 s3c24xx_i2c_wait_idle(i2c);

 +   s3c24xx_i2c_disable_bus(i2c);
 +
   out:
 +   i2c-state = STATE_IDLE;
 +
 return ret;
  }

 @@ -912,7 +941,6 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c 
 *i2c)

  static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
  {
 -   unsigned long iicon = S3C2410_IICCON_IRQEN | S3C2410_IICCON_ACKEN;
 struct s3c2410_platform_i2c *pdata;
 unsigned int freq;

 @@ -926,12 +954,12 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)

 dev_info(i2c-dev, slave address 0x%02x\n, pdata-slave_addr);

 -   writel(iicon, i2c-regs + S3C2410_IICCON);
 +   writel(0, i2c-regs + S3C2410_IICCON);
 +   writel(0, i2c-regs + S3C2410_IICSTAT);

 /* we need to work out the divisors for the clock... */

 if (s3c24xx_i2c_clockrate(i2c, freq) != 0) {
 -   writel(0, i2c-regs + S3C2410_IICCON);
 dev_err(i2c-dev, cannot meet bus frequency required\n);
 return -EINVAL;
 }
 @@ -939,7 +967,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
 /* todo - check that the i2c lines aren't being dragged anywhere */

 dev_info(i2c-dev, bus frequency set to %d KHz\n, freq);
 -   dev_dbg(i2c-dev, S3C2410_IICCON=0x%02lx\n, iicon);
 +   dev_dbg(i2c-dev, S3C2410_IICCON=0x%02x\n,
 +   readl(i2c-regs + S3C2410_IICCON));

 return 0;
  }
 --
 1.7.9.5


 ___
 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] ARM: Exynos: Remove unused non-dt support for dwmci controller

2012-11-26 Thread Kyungmin Park
On 11/26/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 With device tree support enabled for dwmci controller, the unused non-dt
 support
 for dwmci controller can be removed.

Are there no problem to use legacy board? e.g., universal_c210.


 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  arch/arm/mach-exynos/Makefile |1 -
  arch/arm/mach-exynos/dev-dwmci.c  |   75
 -
  arch/arm/mach-exynos/include/mach/dwmci.h |   20 
  3 files changed, 0 insertions(+), 96 deletions(-)
  delete mode 100644 arch/arm/mach-exynos/dev-dwmci.c
  delete mode 100644 arch/arm/mach-exynos/include/mach/dwmci.h

 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index c12ed6a..b189881 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -50,7 +50,6 @@ obj-$(CONFIG_MACH_EXYNOS5_DT)   += 
 mach-exynos5-dt.o
  obj-y+= dev-uart.o
  obj-$(CONFIG_ARCH_EXYNOS4)   += dev-audio.o
  obj-$(CONFIG_EXYNOS4_DEV_AHCI)   += dev-ahci.o
 -obj-$(CONFIG_EXYNOS4_DEV_DWMCI)  += dev-dwmci.o
  obj-$(CONFIG_EXYNOS_DEV_DMA) += dma.o
  obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI)   += dev-ohci.o
  obj-$(CONFIG_EXYNOS_DEV_SYSMMU)  += dev-sysmmu.o
 diff --git a/arch/arm/mach-exynos/dev-dwmci.c
 b/arch/arm/mach-exynos/dev-dwmci.c
 deleted file mode 100644
 index 7903501..000
 --- a/arch/arm/mach-exynos/dev-dwmci.c
 +++ /dev/null
 @@ -1,75 +0,0 @@
 -/*
 - * linux/arch/arm/mach-exynos4/dev-dwmci.c
 - *
 - * Copyright (c) 2011 Samsung Electronics Co., Ltd.
 - *   http://www.samsung.com
 - *
 - * Platform device for Synopsys DesignWare Mobile Storage IP
 - *
 - * This program is free software; you can redistribute it and/or modify
 - * it under the terms of the GNU General Public License as published by
 - * the Free Software Foundation; either version 2 of the License, or
 - * (at your option) any later version.
 - */
 -
 -#include linux/kernel.h
 -#include linux/dma-mapping.h
 -#include linux/platform_device.h
 -#include linux/interrupt.h
 -#include linux/ioport.h
 -#include linux/mmc/dw_mmc.h
 -
 -#include plat/devs.h
 -
 -#include mach/map.h
 -
 -static int exynos4_dwmci_get_bus_wd(u32 slot_id)
 -{
 - return 4;
 -}
 -
 -static int exynos4_dwmci_init(u32 slot_id, irq_handler_t handler, void
 *data)
 -{
 - return 0;
 -}
 -
 -static struct resource exynos4_dwmci_resource[] = {
 - [0] = DEFINE_RES_MEM(EXYNOS4_PA_DWMCI, SZ_4K),
 - [1] = DEFINE_RES_IRQ(EXYNOS4_IRQ_DWMCI),
 -};
 -
 -static struct dw_mci_board exynos4_dwci_pdata = {
 - .num_slots  = 1,
 - .quirks = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
 - .bus_hz = 80 * 1000 * 1000,
 - .detect_delay_ms= 200,
 - .init   = exynos4_dwmci_init,
 - .get_bus_wd = exynos4_dwmci_get_bus_wd,
 -};
 -
 -static u64 exynos4_dwmci_dmamask = DMA_BIT_MASK(32);
 -
 -struct platform_device exynos4_device_dwmci = {
 - .name   = dw_mmc,
 - .id = -1,
 - .num_resources  = ARRAY_SIZE(exynos4_dwmci_resource),
 - .resource   = exynos4_dwmci_resource,
 - .dev= {
 - .dma_mask   = exynos4_dwmci_dmamask,
 - .coherent_dma_mask  = DMA_BIT_MASK(32),
 - .platform_data  = exynos4_dwci_pdata,
 - },
 -};
 -
 -void __init exynos4_dwmci_set_platdata(struct dw_mci_board *pd)
 -{
 - struct dw_mci_board *npd;
 -
 - npd = s3c_set_platdata(pd, sizeof(struct dw_mci_board),
 - exynos4_device_dwmci);
 -
 - if (!npd-init)
 - npd-init = exynos4_dwmci_init;
 - if (!npd-get_bus_wd)
 - npd-get_bus_wd = exynos4_dwmci_get_bus_wd;
 -}
 diff --git a/arch/arm/mach-exynos/include/mach/dwmci.h
 b/arch/arm/mach-exynos/include/mach/dwmci.h
 deleted file mode 100644
 index 7ce6574..000
 --- a/arch/arm/mach-exynos/include/mach/dwmci.h
 +++ /dev/null
 @@ -1,20 +0,0 @@
 -/* linux/arch/arm/mach-exynos4/include/mach/dwmci.h
 - *
 - * Copyright (c) 2011 Samsung Electronics Co., Ltd.
 - *   http://www.samsung.com/
 - *
 - * Synopsys DesignWare Mobile Storage for EXYNOS4210
 - *
 - * 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.
 - */
 -
 -#ifndef __ASM_ARM_ARCH_DWMCI_H
 -#define __ASM_ARM_ARCH_DWMCI_H __FILE__
 -
 -#include linux/mmc/dw_mmc.h
 -
 -extern void exynos4_dwmci_set_platdata(struct dw_mci_board *pd);
 -
 -#endif /* __ASM_ARM_ARCH_DWMCI_H */
 --
 1.7.5.4


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

--
To unsubscribe from 

Re: [PATCH] ARM: dts: add initial dts file for ORIGEN4QUAD

2012-11-26 Thread Kyungmin Park
Hi,

On 11/26/12, chlrb...@gmail.com chlrb...@gmail.com wrote:
 From: Kyuho Choi kh.c...@insignal.co.kr

 This patch adds initial dts file for ORIGEN4QUAD board.
 ORIGEN4QUAD board based on Samsung EXYNOS4412 SoC.
 More properties will be added later.

 Signed-off-by: Kyuho Choi kh.c...@insignal.co.kr
 ---
  arch/arm/boot/dts/exynos4412-origen4quad.dts |   45
 ++
  1 files changed, 45 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/boot/dts/exynos4412-origen4quad.dts

 diff --git a/arch/arm/boot/dts/exynos4412-origen4quad.dts
 b/arch/arm/boot/dts/exynos4412-origen4quad.dts
 new file mode 100644
 index 000..390a2ab
 --- /dev/null
 +++ b/arch/arm/boot/dts/exynos4412-origen4quad.dts
 @@ -0,0 +1,45 @@
 +/*
 + * Samsung's Exynos4412 based Origen4Quad board device tree source
 + *
 + * Copyright (c) 2012-2013 Isnignal Co., Ltd.
 + *   http://www.insignal.co.kr
 + *
 + * Device tree source file for Insignal's Origen4Quad board which is based
 on
 + * Samsung's Exynos4412 SoC.
 + *
 + * 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.
 +*/
 +
 +/dts-v1/;
 +/include/ exynos4412.dtsi
 +
 +/ {
 + model = Insignal Origen4Quad board based on Exynos4412;
 + compatible = insignal,origen4quad, samsung,exynos4412;
 +
 + memory {
 + reg = 0x4000 0x4000;
 + };
does it test to boot with this dts file?
does it support 1GiB memory section?

Thank you,
Kyungmin Park
 +
 + chosen {
 + bootargs =root=/dev/ram0 rw ramdisk=32768 initrd=0x4100,32M
 console=ttySAC2,115200 init=/linuxrc;
 + };
 +
 + serial@1380 {
 + status = okay;
 + };
 +
 + serial@1381 {
 + status = okay;
 + };
 +
 + serial@1382 {
 + status = okay;
 + };
 +
 + serial@1383 {
 + status = okay;
 + };
 +};
 --
 1.7.5.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 v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs

2012-11-09 Thread Kyungmin Park
On Fri, Nov 9, 2012 at 8:54 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Tue, Oct 30, 2012 at 10:27:32AM +0530, Praveen Paneri wrote:
 Changes from v6:
 Modified register definitions according to the existing ones.
 Changed default PHY clk selection for SoCs.
 Improved binding text and rebased to the latest usb-next.

 Changes from v5:
 Moved clk_get() to driver's probe function. Now reference clock frequency
 selection value is stored in samsung_usbphy structure for later use. Used
 IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data().

 Changes from v4:
 Moved header file contents to driver's source file
 Removed unnecessary print message from driver's probe function
 Dropped the Free Software Foundation address from the header
 Changed the platform data code to use __initdata

 Changes from v3:
 Replaced susbsys_initcall()/module_exit() by module_platform_driver().
 Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver
 is registered
 Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove.

 Changes from v2:
 Changed the driver filenames to samsung-usbphy
 Changed 's3c' to 'samsung' for platform device as well as platform data
 Moved platform data structure to a separate file
 Rectified coding style related errors

 Changes from v1:
 Rebased patches to latest usb-next branch
 Changed the name 'sec_usbphy' to 'samsung_usbphy'

 This patch set introduces a phy driver for samsung SoCs. It uses the existing
 transceiver infrastructure to provide phy control functions. Use of this 
 driver
 can be extended for usb host phy as well. Over the period of time all the phy
 related code for most of the samsung SoCs can be integrated here.
 Removing the existing phy code from mach-s3c64xx. Same can be done for other 
 SoCs
 when they start supporting this phy driver.
 This driver is tested with smdk6410 and Exynos4210(with DT).

 Praveen Paneri (5):
   usb: phy: samsung: Introducing usb phy driver for hsotg
   usb: s3c-hsotg: Adding phy driver support
For usb parts:
Acked-by: Kyungmin Park kyungmin.p...@samsung.com

   ARM: S3C64XX: Removing old phy setup code
   ARM: S3C64XX: Enabling samsung-usbphy driver
   ARM: Exynos4210: Enabling samsung-usbphy driver

 guys I can't wait any longer. If I don't get proper Acks today, I will
 go ahead without all the PHY changes from Samsung :-s

To Praveen,

To remove these dependency and merge issue, please send patches for
each subsystem. In this case, usb patches for usb tree and others are
for arm arch.

Thank you,
Kyungmin Park

 --
 balbi

 ___
 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 3/4] pinctrl: samsung: Add support for Exynos4x12

2012-10-28 Thread Kyungmin Park
On 10/29/12, Linus Walleij linus.wall...@linaro.org wrote:
 On Wed, Oct 24, 2012 at 4:37 PM, Tomasz Figa t.f...@samsung.com wrote:

 This patch extends the driver with any necessary SoC-specific
 definitions to support Exynos4x12 SoCs.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

 Acked-by: Linus Walleij linus.wall...@linaro.org

 I guess you need all of this to go into my Samsung branch?
 I need and ACK from the Samsung maintainer and preferably
 Thomas A as well.

Hi,

Now we're trying to send the standalone patches to avoid the conflict.
and hope to merge patches via proper subsystem. In this case, pinctl.

Thank you,
Kyungmin Park

 Yours,
 Linus Walleij

 ___
 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] ARM: EXYNOS: exynos4-dt: Set .smp field of machine descriptor

2012-10-21 Thread Kyungmin Park
+ Arnd, Olof,

Tomasz,
I think it's better to add arm-soc maintainers at CC when send the patches.
Samsung patches doesn't handled or merged with proper time.

Thank you,
Kyungmin Park

On 10/22/12, Tomasz Figa tomasz.f...@gmail.com wrote:
 On Friday 12 of October 2012 11:49:38 Tomasz Figa wrote:
 This patch adds missing initializer of .smp field of machine descriptor
 of Exynos 4 DT machine.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 ---
  arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
 b/arch/arm/mach-exynos/mach-exynos4-dt.c index 7222e3c..d6bdcfb 100644
 --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
 +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
 @@ -119,6 +119,7 @@ static char const *exynos4_dt_compat[] __initdata =
 {

  DT_MACHINE_START(EXYNOS4210_DT, Samsung Exynos4 (Flattened Device
 Tree)) /* Maintainer: Thomas Abraham thomas.abra...@linaro.org */
 +.smp= smp_ops(exynos_smp_ops),
  .init_irq   = exynos4_init_irq,
  .map_io = exynos4_dt_map_io,
  .handle_irq = gic_handle_irq,

 Ping. I think this should be considered a fix.

 Best regards,
 Tomasz Figa

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

--
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 0/6] arm: exynos: add dt based support for exynos5 hdmi

2012-10-16 Thread Kyungmin Park
Hi,

It's common case, one topic but two different tree.
So I suggest merge it at samsung sub-soc tree and drm parts will be
merged after arm-soc tree is merged. since arm-soc tree collect arm
soc-soc and merged early at merge window. then drm tree will be merged
later.
Until that time, drm patches are hold only at local git.

How do you think?

Thank you,
Kyungmin Park

On 10/16/12, Rahul Sharma r.sh.o...@gmail.com wrote:
 Hi Mr. Park, Mr. Kim,

 I had a suggestion here from Tomasz about dividing this patch-set into
 2 portions:

 1) DT related (patches 1-4) for samsung-dt branch.
 2) Clocks, Arch data related to Exynos5. (patches 5,6) for
 exynos-drm-fixes branch.

 Rationale behind this is kgene tree with all 6 patches applied will
 have broken drm
 exynos4 and incomplete drm exynos5.

 I want to know your opinion on this.

 regards,
 Rahul Sharma

 On Tue, Oct 16, 2012 at 3:01 PM, Tomasz Figa t.f...@samsung.com wrote:
 Hi Rahul,



 On Tuesday 16 of October 2012 05:00:28 Rahul Sharma wrote:

 This patch set adds the DT based support for Samsung's Exynos5250. It

 adds device tree nodes for hdmi, mixer, hdmiphy and hdmiddc. The name

 of these devices are changed to the one matching with drivers.

 Exynos-drm and exynos hdmi-drm-commmon devices are removed from machine

 init code.



 Exynos-drm and exynos hdmi-drm-commmon devices are removed from machine

 init code. Patch set which adds this code is posted to dri-devel list at

 http://comments.gmane.org/gmane.comp.video.dri.devel/75121.



 This patchset is based on linux v3.6-rc6, branch v3.7-next/dt-samsung at

 git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git



 v1:

 - dropped patch for hpd gpio initialisation from machine init.

 - dropped patch for platform device registration.

 - removed platform device registration from non-dt platforms.



 v2:

 - removed version information from hdmi, mixer dt nodes.

 - added DT binding documentation for hdmi, mixer, hdmiphy and hdmiddc.



 v3:

 - corrected indentations.

 - changed dt node names to name@address format.



 Rahul Sharma (6):

 dts: exynos: add device tree support for exynos5 hdmi

 dts: exynos: add device tree support for exynos5 mixer

 dts: exynos: add device tree support for exynos5 hdmiphy

 dts: exynos: add device tree support for exynos5 hdmiddc

 arm: exynos: add clocks for exynos5 hdmi

 arm: exynos: removing exynos-drm device registration from non-dt

 platforms



 .../devicetree/bindings/drm/exynos/hdmi.txt | 22

 +++ .../devicetree/bindings/drm/exynos/hdmiddc.txt |

 12  .../devicetree/bindings/drm/exynos/hdmiphy.txt | 12

  .../devicetree/bindings/drm/exynos/mixer.txt | 15

 ++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 24

 +++- arch/arm/boot/dts/exynos5250.dtsi |

 20 + arch/arm/mach-exynos/Makefile |

 1 -

 arch/arm/mach-exynos/clock-exynos5.c | 14 -

 arch/arm/mach-exynos/dev-drm.c | 29

  arch/arm/mach-exynos/include/mach/map.h

 | 2 +

 arch/arm/mach-exynos/mach-exynos5-dt.c | 8 +

 arch/arm/mach-exynos/mach-nuri.c | 3 --

 arch/arm/mach-exynos/mach-origen.c | 3 --

 arch/arm/mach-exynos/mach-smdk4x12.c | 3 --

 arch/arm/mach-exynos/mach-smdkv310.c | 3 --

 arch/arm/mach-exynos/mach-universal_c210.c | 3 --

 arch/arm/plat-samsung/include/plat/devs.h | 2 -

 17 files changed, 126 insertions(+), 50 deletions(-)

 create mode 100644

 Documentation/devicetree/bindings/drm/exynos/hdmi.txt create mode

 100644 Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt create

 mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt

 create mode 100644

 Documentation/devicetree/bindings/drm/exynos/mixer.txt delete mode

 100644 arch/arm/mach-exynos/dev-drm.c



 The patches look fine, but Kukjin's tree doesn't contain all the

 dependencies for them to be usable.



 Shouldn't they be based on exynos-drm-next branch of Kyungmin's tree at

 infradead instead:



 http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-next



 Best regards,

 --

 Tomasz Figa

 Samsung Poland RD Center


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

--
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] usb: phy: samsung: Introducing usb phy driver for hsotg

2012-10-15 Thread Kyungmin Park
+ Tomasz Figa,

Acked-by: Kyungmin Park kyungmin.p...@samsung.com

On Mon, Oct 15, 2012 at 10:28 PM, Felipe Balbi ba...@ti.com wrote:
 On Fri, Oct 12, 2012 at 03:45:34PM +0530, Praveen Paneri wrote:
 platform_set_drvdata() required for driver's remove function, so adding
 it back.

 From v6:
 Added TODO for phy bindings with controller
 Dropped platform_set_drvdata() from driver probe

 This driver uses usb_phy interface to interact with s3c-hsotg. Supports
 phy_init and phy_shutdown functions to enable/disable phy. Tested with
 smdk6410 and smdkv310. More SoCs can be brought under later.


 this commit log needs improvement. There are stuff there which shouldn't
 go to git's history.

 I would like to get Tested-bys and Acked-by from DT maintainers.

 Signed-off-by: Praveen Paneri p.pan...@samsung.com
 Acked-by: Heiko Stuebner he...@sntech.de
 ---
  .../devicetree/bindings/usb/samsung-usbphy.txt |   11 +
  drivers/usb/phy/Kconfig|8 +
  drivers/usb/phy/Makefile   |1 +
  drivers/usb/phy/samsung-usbphy.c   |  357 
 
  include/linux/platform_data/samsung-usbphy.h   |   27 ++
  5 files changed, 404 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
  create mode 100644 drivers/usb/phy/samsung-usbphy.c
  create mode 100644 include/linux/platform_data/samsung-usbphy.h

 diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt 
 b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
 new file mode 100644
 index 000..7b26e2d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
 @@ -0,0 +1,11 @@
 +* Samsung's usb phy transceiver
 +
 +The Samsung's phy transceiver is used for controlling usb otg phy for
 +s3c-hsotg usb device controller.
 +TODO: Adding the PHY binding with controller(s) according to the under
 +developement generic PHY driver.
 +
 +Required properties:
 +- compatible : should be samsung,exynos4210-usbphy
 +- reg : base physical address of the phy registers and length of memory 
 mapped
 + region.
 diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
 index 63c339b..313685f 100644
 --- a/drivers/usb/phy/Kconfig
 +++ b/drivers/usb/phy/Kconfig
 @@ -32,3 +32,11 @@ config MV_U3D_PHY
   help
 Enable this to support Marvell USB 3.0 phy controller for Marvell
 SoC.
 +
 +config SAMSUNG_USBPHY
 + bool Samsung USB PHY controller Driver
 + depends on USB_S3C_HSOTG
 + select USB_OTG_UTILS
 + help
 +   Enable this to support Samsung USB phy controller for samsung
 +   SoCs.
 diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
 index b069f29..55dcfc1 100644
 --- a/drivers/usb/phy/Makefile
 +++ b/drivers/usb/phy/Makefile
 @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2)   += omap-usb2.o
  obj-$(CONFIG_USB_ISP1301)+= isp1301.o
  obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
  obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
 +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
 diff --git a/drivers/usb/phy/samsung-usbphy.c 
 b/drivers/usb/phy/samsung-usbphy.c
 new file mode 100644
 index 000..14c182f
 --- /dev/null
 +++ b/drivers/usb/phy/samsung-usbphy.c
 @@ -0,0 +1,357 @@
 +/* linux/drivers/usb/phy/samsung-usbphy.c
 + *
 + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
 + *  http://www.samsung.com
 + *
 + * Author: Praveen Paneri p.pan...@samsung.com
 + *
 + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller
 + *
 + * 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.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/clk.h
 +#include linux/delay.h
 +#include linux/err.h
 +#include linux/io.h
 +#include linux/of.h
 +#include linux/usb/otg.h
 +#include linux/platform_data/samsung-usbphy.h
 +
 +/* Register definitions */
 +
 +#define S3C_PHYPWR   (0x00)
 +
 +#define S3C_PHYPWR_NORMAL_MASK   (0x19  0)
 +#define S3C_PHYPWR_OTG_DISABLE   (1  4)
 +#define S3C_PHYPWR_ANALOG_POWERDOWN  (1  3)
 +#define S3C_PHYPWR_FORCE_SUSPEND (1  1)
 +/* For Exynos4 */
 +#define EXYNOS4_PHYPWR_NORMAL_MASK   (0x39  0)
 +#define EXYNOS4_PHYPWR_SLEEP (1  5)
 +
 +#define S3C_PHYCLK   (0x04)
 +
 +#define S3C_PHYCLK_MODE_SERIAL   (1  6)
 +#define S3C_PHYCLK_EXT_OSC   (1  5)
 +#define

Re: [PATCH v2 00/15] pinctrl: samsung: Usability and extensibiltiy improvements

2012-10-11 Thread Kyungmin Park
Hi,

On Thu, Oct 11, 2012 at 5:11 PM, Tomasz Figa t.f...@samsung.com wrote:
 This patch series is a work on improving usability and extensibiltiy of
 the pinctrl-samsung driver. It consists of three main parts:
  - improving flexibility of SoC-specific data specification
  - converting the driver to one GPIO chip and IRQ domain per pin bank
  - improving wake-up IRQ setup and handling

Really good job! and it solved mess GPIOs H/W configurations of Samsung SoC.
Basically Samsung SoC GPIOs don't have generic rules. Even worse, pin
name is mixed but offset is still increased.

With DT support. we can solve this issue and use generic pinctrl drivers.

For all series.
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com


 1) What the first part does, in addition to various related fixes, is
 removing any unnecessary static data from pinctrl-exynos driver.

 This is achieved mostly thanks to assigning pin numbers dynamically,
 with help of only pin counts of particular banks. It also simplifies
 adding next SoC variants, since much less static data needs to be
 specified.

 2) The second part attempts to simplify usage of the driver and fix several
 problems of current implementation, in particular:

   - Simplifies GPIO pin specification in device tree by using pin
 namespace local to pin bank instead of local to pin controller, e.g.

 gpios = gpj0 3 0;

 instead of

 gpios = pinctrl0 115 0;

   - Simplifies GPIO interrupt specification in device tree by using
 namespace local to pin bank (and equal to GPIO namespace), e.g.

 interrupt-parent = gpj0;
 interrupts = 3 0;

 instead of

 interrupt-parent = pinctrl0;
 interrupts = 115 0;

   - Simplifies internal GPIO pin to bank translation thanks to
 correspondence of particular GPIO chips to pin banks. This allows
 to remove the (costly in case of GPIO bit-banging drivers) lookup
 over all banks to find the one that the pin is from.

 3) Third part is focused on removing the hard-coded description of wake-up
 interrupt layout.

 It moves wake-up interrupt description to bank struct and device tree,
 which allows to specify which pin banks support wake-up interrupts and
 how they are handled (direct or multiplexed/chained).

 See particular patches for more detailed descriptions and the last patch for
 updated device tree bindings.

 Changes since v1:
  - dropped moving SoC-specific data to device tree
(might be added in further patches)
  - dropped per-bank specification of configuration register offsets
(thus limiting scope of the driver to Exynos SoCs; will be added in
 further patches)

 Tomasz Figa (15):
   pinctrl: samsung: Detect and handle unsupported configuration types
   pinctrl: samsung: Do not pass gpio_chip to pin_to_reg_bank
   pinctrl: samsung: Assing pin numbers dynamically
   pinctrl: samsung: Remove static pin enumerations
   pinctrl: samsung: Distinguish between pin group and bank nodes
   ARM: dts: exynos4210-pinctrl: Add nodes for pin banks
   pinctrl: samsung: Match pin banks with their device nodes
   pinctrl: samsung: Hold pointer to driver data in bank struct
   pinctrl: samsung: Include bank-specific eint offset in bank struct
   pinctrl: exynos: Use one IRQ domain per pin bank
   pinctrl: samsung: Use one GPIO chip per pin bank
   pinctrl: samsung: Use per-bank IRQ domain for wake-up interrupts
   pinctrl: exynos: Set pin function to EINT in irq_set_type of wake-up
 EINT
   pinctrl: samsung: Add GPIO to IRQ translation
   Documentation: Update samsung-pinctrl device tree bindings
 documentation

  .../bindings/pinctrl/samsung-pinctrl.txt   | 118 +--
  arch/arm/boot/dts/exynos4210-pinctrl.dtsi  | 278 
  arch/arm/boot/dts/exynos4210.dtsi  | 241 +-
  drivers/pinctrl/pinctrl-exynos.c   | 367 
 ++---
  drivers/pinctrl/pinctrl-exynos.h   | 170 ++
  drivers/pinctrl/pinctrl-samsung.c  | 203 
  drivers/pinctrl/pinctrl-samsung.h  |  29 +-
  7 files changed, 741 insertions(+), 665 deletions(-)

 --
 1.7.12


 ___
 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 01/15] pinctrl: samsung: Detect and handle unsupported configuration types

2012-10-11 Thread Kyungmin Park
Hi Linus,

On Thu, Oct 11, 2012 at 10:57 PM, Linus Walleij
linus.wall...@linaro.org wrote:
 On Thu, Oct 11, 2012 at 10:11 AM, Tomasz Figa t.f...@samsung.com wrote:

 This patch modifies the pinctrl-samsung driver to detect when width of a
 bit field is set to zero (which means that such configuraton type is not
 supported) and return an error instead of trying to modify an inexistent
 register.

 Signed-off-by: Tomasz Figa t.f...@samsung.com

 I'm quite happy with these 17 patches, but I'd like to have Thomas
 Abraham's definitive ACK before I merge anything.
Thomas did ACK at [00/17] ... mail.

Thank you,
Kyungmin Park

 Yours,
 Linus Walleij
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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: [Linaro-mm-sig] [PATCHv9 00/25] Integration of videobuf2 with DMABUF

2012-10-10 Thread Kyungmin Park
On 10/10/12, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Hi,

 Em Tue, 02 Oct 2012 16:27:11 +0200
 Tomasz Stanislawski t.stanisl...@samsung.com escreveu:

 Hello everyone,
 This patchset adds support for DMABUF [2] importing and exporting to V4L2
 stack.

 v9:
 - rebase on 3.6
 - change type for fs to __s32
 - add support for vb2_ioctl_expbuf
 - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING',
   it will be posted as a separate patch
 - fix typos and style in Documentation (from Hans Verkuil)
 - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig
 - use data_offset and length while queueing DMABUF
 - return the most recently used fd at VIDIOC_DQBUF
 - use (buffer-type, index, plane) tuple instead of mem_offset
   to identify a for exporting (from Hans Verkuil)
 - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart)
 - add testing alignment of vaddr and size while verifying userptr
   against DMA capabilities (from Laurent Pinchart)
 - substitute VM_DONTDUMP with VM_RESERVED
 - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)

 For now, NACK. See below.

Sad news!
It's failed to merge by very poor samsung board support at mainline.

CC arm  samsung mailing list.

Thank you,
Kyungmin Park

 I spent 4 days trying to setup an environment that would allow testing
 DMABUF with video4linux without success (long story, see below). Also,
 Laurent tried the same without any luck, and it seems that it even
 corrupted his test machine.

 Basically Samsung generously donated me two boards that it could be
 used on this test (Origen and SMDK310). None of them actually worked
 with the upstream kernel: patches are needed to avoid OOPSes on
 Origen; both Origen/SMDK310 defconfigs are completely broken, and drivers
 don't even boot if someone tries to use the Kernel's defconfigs.

 Even after spending _days_ trying to figure out the needed .config options
 (as the config files are not easily available), both boards have... issues:

   - lack of any display output driver at SMDK310;

   - lack of any network driver at Origen: it seems that none of
 the available network options on Origen was upstreamed: no Bluetooth, no
 OTG,
 no Wifi.

 The only test I was able to do (yesterday, late night), the DMABUF caused
 an OOPS at the Origen board. So, for sure it is not ready for upstream.

 It is now, too late for 3.7. I might consider it to 3.8, if something
 can be done to fix the existing issues, and setup a proper setup, using
 the upstream Kernel.

 Regards,
 Mauro

 ___
 Linaro-mm-sig mailing list
 linaro-mm-...@lists.linaro.org
 http://lists.linaro.org/mailman/listinfo/linaro-mm-sig

--
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 0/6] ARM: EXYNOS: Add secure firmware support

2012-10-10 Thread Kyungmin Park
Hi Arnd or Olof,

Can you pick up for v3.7?

To Tomasz,
Can you rebase it on the latest arm-soc tree?

Thank you,
Kyungmin Park

On Tue, Oct 2, 2012 at 6:13 PM, Tomasz Figa t.f...@samsung.com wrote:
 Hi,

 On Monday 24 of September 2012 16:28:27 Tomasz Figa wrote:
 Some Exynos-based boards are running with secure firmware running in
 TrustZone secure world, which changes the way some things have to be
 initialized.

 This series adds support for specifying firmware operations, implements
 some firmware operations for Exynos secure firmware and adds a method of
 enabling secure firmware operations on Exynos-based boards through board
 file and device tree.

 Changes since v1
 http://thread.gmane.org/gmane.linux.kernel.samsung-soc/12583/focus=12820
   - Changed return types of all operations to int
   - Defined all operations to return 0 on success, -ENOSYS when not
 implemented or appropriate error code on error

 Tomasz Figa (6):
   ARM: Add interface for registering and calling firmware-specific
 operations
   ARM: EXYNOS: Add support for secure monitor calls
   ARM: EXYNOS: Add support for secondary CPU bring-up on Exynos4412
   ARM: EXYNOS: Add IO mapping for non-secure SYSRAM.
   ARM: EXYNOS: Add support for Exynos secure firmware
   ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up

  .../devicetree/bindings/arm/samsung-boards.txt |  8 
  arch/arm/common/Makefile   |  2 +
  arch/arm/common/firmware.c | 18 
  arch/arm/include/asm/firmware.h| 31 +
  arch/arm/mach-exynos/Makefile  |  6 +++
  arch/arm/mach-exynos/common.c  | 34 ++
  arch/arm/mach-exynos/common.h  |  2 +
  arch/arm/mach-exynos/exynos-smc.S  | 22 +
  arch/arm/mach-exynos/firmware.c| 54
 ++ arch/arm/mach-exynos/include/mach/map.h
  |  3 ++
  arch/arm/mach-exynos/mach-exynos4-dt.c |  1 +
  arch/arm/mach-exynos/platsmp.c | 36 ---
  arch/arm/mach-exynos/smc.h | 31 +
  arch/arm/plat-samsung/include/plat/map-s5p.h   |  1 +
  14 files changed, 243 insertions(+), 6 deletions(-)
  create mode 100644 arch/arm/common/firmware.c
  create mode 100644 arch/arm/include/asm/firmware.h
  create mode 100644 arch/arm/mach-exynos/exynos-smc.S
  create mode 100644 arch/arm/mach-exynos/firmware.c
  create mode 100644 arch/arm/mach-exynos/smc.h

 Any comments, nitpicks or acks on this patchset?

 Best regards,
 --
 Tomasz Figa
 Samsung Poland RD Center

 --
 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
--
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 6/8] arm: exynos: config exynos5 hdmi-hpd gpio

2012-10-04 Thread Kyungmin Park
On 10/5/12, Rahul Sharma rahul.sha...@samsung.com wrote:
 This patch adds support for the configuration of exynos5 hdmi-hpd gpio.
 It sets the gpio fucntion to EINT which is required for recieving
 external hpd interrupt in drm hdmi driver.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  arch/arm/mach-exynos/mach-exynos5-dt.c |9 +
  1 files changed, 9 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
 b/arch/arm/mach-exynos/mach-exynos5-dt.c
 index 003963c..9a6d569 100644
 --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
 +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
 @@ -11,6 +11,7 @@

  #include linux/of_platform.h
  #include linux/serial_core.h
 +#include linux/gpio.h

  #include asm/mach/arch.h
  #include asm/hardware/gic.h
 @@ -18,6 +19,7 @@

  #include plat/cpu.h
  #include plat/regs-serial.h
 +#include plat/gpio-cfg.h

  #include common.h

 @@ -81,10 +83,17 @@ static void __init exynos5250_dt_map_io(void)
   s3c24xx_init_clocks(2400);
  }

 +static void smdk_hpd_setup(void)
 +{
 + s3c_gpio_cfgpin(EXYNOS5_GPX3(7), S3C_GPIO_SFN(0xf));
 + s3c_gpio_setpull(EXYNOS5_GPX3(7), S3C_GPIO_PULL_DOWN);
 +}
these should be described at dts file instead of here. and name is not
good. smdk...

Thank you,
Kyungmin Park
 +
  static void __init exynos5250_dt_machine_init(void)
  {
   of_platform_populate(NULL, of_default_bus_match_table,
   exynos5250_auxdata_lookup, NULL);
 + smdk_hpd_setup();
  }

  static char const *exynos5250_dt_compat[] __initdata = {
 --
 1.7.0.4

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

--
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/5] ARM: Add interface for registering and calling firmware-specific operations

2012-09-22 Thread Kyungmin Park
On 9/22/12, Olof Johansson o...@lixom.net wrote:
 On Thu, Sep 13, 2012 at 10:13:35AM +0200, Tomasz Figa wrote:
 Some boards are running with secure firmware running in TrustZone secure
 world, which changes the way some things have to be initialized.

 This patch adds an interface for platforms to specify available firmware
 operations and call them.

 A wrapper macro, call_firmware_op(), checks if the operation is provided
 and calls it if so, otherwise returns 0.

 By default no operations are provided.

 This is a follow-up on the patch by Kyungmin Park:
 [PATCH v5 1/2] ARM: Make a compile firmware conditionally
 http://thread.gmane.org/gmane.linux.ports.arm.kernel/183607/focus=183988

 Example of use:

 In code using firmware ops:

  __raw_writel(virt_to_phys(exynos4_secondary_startup),
  CPU1_BOOT_REG);

  /* Call Exynos specific smc call */
  do_firmware_op(cpu_boot, cpu);

  gic_raise_softirq(cpumask_of(cpu), 1);

 In board-/platform-specific code:

  static int platformX_do_idle(void)
  {
  /* tell platformX firmware to enter idle */
  return 0;
  }

  static void platformX_cpu_boot(int i)
  {
  /* tell platformX firmware to boot CPU i */
  }

  static const struct firmware_ops platformX_firmware_ops __initdata = {
  .do_idle= exynos_do_idle,
  .cpu_boot   = exynos_cpu_boot,
  /* cpu_boot_reg not available on platformX */
  };

  static void __init board_init_early(void)
  {
  register_firmware_ops(platformX_firmware_ops);
  }

 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Tomasz Figa t.f...@samsung.com
 ---
  arch/arm/common/Makefile|  2 ++
  arch/arm/common/firmware.c  | 18 ++
  arch/arm/include/asm/firmware.h | 30 ++
  3 files changed, 50 insertions(+)
  create mode 100644 arch/arm/common/firmware.c
  create mode 100644 arch/arm/include/asm/firmware.h

 diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
 index e8a4e58..55d4182 100644
 --- a/arch/arm/common/Makefile
 +++ b/arch/arm/common/Makefile
 @@ -2,6 +2,8 @@
  # Makefile for the linux kernel.
  #

 +obj-y += firmware.o
 +
  obj-$(CONFIG_ARM_GIC)   += gic.o
  obj-$(CONFIG_ARM_VIC)   += vic.o
  obj-$(CONFIG_ICST)  += icst.o
 diff --git a/arch/arm/common/firmware.c b/arch/arm/common/firmware.c
 new file mode 100644
 index 000..27ddccb
 --- /dev/null
 +++ b/arch/arm/common/firmware.c
 @@ -0,0 +1,18 @@
 +/*
 + * Copyright (C) 2012 Samsung Electronics.
 + * Kyungmin Park kyungmin.p...@samsung.com
 + * Tomasz Figa t.f...@samsung.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/kernel.h
 +#include linux/suspend.h
 +
 +#include asm/firmware.h
 +
 +static const struct firmware_ops default_firmware_ops;
 +
 +const struct firmware_ops *firmware_ops = default_firmware_ops;
 diff --git a/arch/arm/include/asm/firmware.h
 b/arch/arm/include/asm/firmware.h
 new file mode 100644
 index 000..ed51b02
 --- /dev/null
 +++ b/arch/arm/include/asm/firmware.h
 @@ -0,0 +1,30 @@
 +/*
 + * Copyright (C) 2012 Samsung Electronics.
 + * Kyungmin Park kyungmin.p...@samsung.com
 + * Tomasz Figa t.f...@samsung.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.
 + */
 +
 +#ifndef __ASM_ARM_FIRMWARE_H
 +#define __ASM_ARM_FIRMWARE_H
 +
 +struct firmware_ops {
 +int (*do_idle)(void);
 +void (*cpu_boot)(int cpu);
 +void __iomem *(*cpu_boot_reg)(int cpu);
 +};
 +
 +extern const struct firmware_ops *firmware_ops;
 +
 +#define call_firmware_op(op, ...)   \
 +((firmware_ops-op) ? firmware_ops-op(__VA_ARGS__) : 0)

 I think this will cause sparse warnings for call_firmware_op(cpu_boot_reg)
 if there are no ops defined, since the '0' isn't annotated as __iomem. And
 you can't annotate it since the other function pointers don't need it.

 I think you might be better off with stub functions as fallbacks instead of
 allowing and checking for NULL here.
do you mean like this?

#Ifdef CONFIG_ARM_FIRMWARE
#define call_firmware_op(op, ...) ((firmware_ops-op) ?
firmware_ops-op(__VA_ARGS__) : 0)
#else
#define call_firmware_op(op, ...) do { } while (0)
#endif

No problem to modify it.

Thank you,
Kyungmin Park


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

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message

Re: [PATCH 4/5] ARM: EXYNOS: Add support for Exynos secure firmware

2012-09-22 Thread Kyungmin Park
On 9/22/12, Olof Johansson o...@lixom.net wrote:
 On Fri, Sep 21, 2012 at 10:57 PM, Kyungmin Park
 kyungmin.p...@samsung.com wrote:
 On 9/22/12, Olof Johansson o...@lixom.net wrote:
 On Wed, Sep 19, 2012 at 3:10 AM, Tomasz Figa t.f...@samsung.com wrote:
 Hi Olof,

 On Saturday 15 of September 2012 17:44:55 Olof Johansson wrote:
 On Thu, Sep 13, 2012 at 10:13:37AM +0200, Tomasz Figa wrote:
  +static void __iomem *exynos_cpu_boot_reg(int cpu)
  +{
  +   return S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
  +}

 This communication area in sysram should probably be seen as a part of
 the firmware interface. It should thus be defined as part of the
 binding
 instead, i.e.  through a reg property or similar there. That also
 would
 make it easy to convert to using ioremap() instead of iodesc tables,
 which always a nice thing.

 The problem with SYSRAM_NS is that it might be also used in other code,
 not
 related to firmware only. I don't know exactly all the use cases for
 it.

 If you don't know the use cases, and the use cases are not in the
 kernel tree that we care about here (upstream), then there's really
 nothing to worry about. It's after all just a define that's moved to
 an ioremap, if there's some out of tree code that needs the old legacy
 define then it can be added in whatever out-of-tree code that uses it.
 Right?
 Now this address is used at cpu boot, cpuidle, inform at this time.
 As it touched at several places, it's defined at iodesc. if it changed
 with ioremap, it has to export remaped address and each codes should
 use it.

 Won't you have to push down all the references to VA_SYSRAM vs
 VA_SYSRAM_NS into the firmware interface anyway, since you will need
 to use different addresses for whether you have firmware enabled or
 not? I.e. you'll have a firmware call at the appropriate level for
 the non-trustzone cases that uses the equivalent of VA_SYSRAM, and for
 the trustzone firmware op you'll use VA_SYSRAM_NS?
Right, in case of no firmware, it uses VA_SYSRAM, but VA_SYSRAM_NS is
used at firmware case.


 As I wrote at cover letter, if you want to use ioremap, it can be
 modified. however can you merge firmware codes itself? since ioremap
 is not related with trustzone  or firmware issues and it's exynos
 specific implementation issues. Right?

 I'm not quite sure which part you are asking me to merge, if it's the
 infrastructure pieces or the exynos-specific pieces.

 Either way, one isn't really usable without the other, and it doesn't
 make sense to merge code that can't be used. Infrastructure is best
 merged together with the first user of it.

Okay, we will fix it.

Thank you,
Kyungmin 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


Re: [PATCH 0/5] ARM: EXYNOS: Add secure firmware support

2012-09-21 Thread Kyungmin Park
On 9/19/12, Tomasz Figa t.f...@samsung.com wrote:
 Hi,

 On Thursday 13 of September 2012 10:13:33 Tomasz Figa wrote:
 Some Exynos-based boards are running with secure firmware running in
 TrustZone secure world, which changes the way some things have to be
 initialized.

 This series adds support for specifying firmware operations, implements
 some firmware operations for Exynos secure firmware and adds a method of
 enabling secure firmware operations on Exynos-based boards through board
 file and device tree.

 This is a continuation of the patch series by Kyungmin Park:
 [PATCH v5 1/2] ARM: Make a compile firmware conditionally
 http://thread.gmane.org/gmane.linux.ports.arm.kernel/183607
 [PATCH v5 2/2] ARM: EXYNOS: SMC instruction (aka firmware) support
 http://thread.gmane.org/gmane.linux.ports.arm.kernel/183608/focus=184109

 Tomasz Figa (5):
   ARM: EXYNOS: Add IO mapping for non-secure SYSRAM.
   ARM: Add interface for registering and calling firmware-specific
 operations
   ARM: EXYNOS: Add support for secure monitor calls
   ARM: EXYNOS: Add support for Exynos secure firmware
   ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up

  .../devicetree/bindings/arm/samsung-boards.txt |  8 
  arch/arm/common/Makefile   |  2 +
  arch/arm/common/firmware.c | 18 
  arch/arm/include/asm/firmware.h| 30 +
  arch/arm/mach-exynos/Makefile  |  6 +++
  arch/arm/mach-exynos/common.c  | 34 ++
  arch/arm/mach-exynos/common.h  |  2 +
  arch/arm/mach-exynos/exynos-smc.S  | 22 +
  arch/arm/mach-exynos/firmware.c| 52
 ++ arch/arm/mach-exynos/include/mach/map.h
  |  3 ++
  arch/arm/mach-exynos/mach-exynos4-dt.c |  1 +
  arch/arm/mach-exynos/platsmp.c |  8 
  arch/arm/mach-exynos/smc.h | 31 +
  arch/arm/plat-samsung/include/plat/map-s5p.h   |  1 +
  14 files changed, 218 insertions(+)
  create mode 100644 arch/arm/common/firmware.c
  create mode 100644 arch/arm/include/asm/firmware.h
  create mode 100644 arch/arm/mach-exynos/exynos-smc.S
  create mode 100644 arch/arm/mach-exynos/firmware.c
  create mode 100644 arch/arm/mach-exynos/smc.h

 Any further comments for this series? Maybe we could merge it for 3.7?

Hi Arnd, Olof,
Can you merge it for 3.7? If exynos implementation still has issues,
it's okay only merge firmware implementation.

Can you give your opinions?

Thank you,
Kyungmin 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


Re: [PATCH 4/5] ARM: EXYNOS: Add support for Exynos secure firmware

2012-09-21 Thread Kyungmin Park
On 9/22/12, Olof Johansson o...@lixom.net wrote:
 On Wed, Sep 19, 2012 at 3:10 AM, Tomasz Figa t.f...@samsung.com wrote:
 Hi Olof,

 On Saturday 15 of September 2012 17:44:55 Olof Johansson wrote:
 On Thu, Sep 13, 2012 at 10:13:37AM +0200, Tomasz Figa wrote:
  +static void __iomem *exynos_cpu_boot_reg(int cpu)
  +{
  +   return S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
  +}

 This communication area in sysram should probably be seen as a part of
 the firmware interface. It should thus be defined as part of the binding
 instead, i.e.  through a reg property or similar there. That also would
 make it easy to convert to using ioremap() instead of iodesc tables,
 which always a nice thing.

 The problem with SYSRAM_NS is that it might be also used in other code,
 not
 related to firmware only. I don't know exactly all the use cases for it.

 If you don't know the use cases, and the use cases are not in the
 kernel tree that we care about here (upstream), then there's really
 nothing to worry about. It's after all just a define that's moved to
 an ioremap, if there's some out of tree code that needs the old legacy
 define then it can be added in whatever out-of-tree code that uses it.
 Right?
Now this address is used at cpu boot, cpuidle, inform at this time.
As it touched at several places, it's defined at iodesc. if it changed
with ioremap, it has to export remaped address and each codes should
use it.

As I wrote at cover letter, if you want to use ioremap, it can be
modified. however can you merge firmware codes itself? since ioremap
is not related with trustzone  or firmware issues and it's exynos
specific implementation issues. Right?

Thank you,
Kyungmin Park

 Is it really a big problem or we could let it be for now, merge the
 patches
 for firmware and then convert SYSRAM_NS to dynamic mapping when its
 situation clarifies?

 What do you expect is required to clarify the situation, and when do
 you expect that to happen?


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

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


Re: [PATCH V4 2/2] video: drm: exynos: Add device tree support

2012-09-05 Thread Kyungmin Park
Hi,

On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala
l.kris...@samsung.com wrote:
 Add device tree based discovery support for DRM-FIMD driver.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 
 -
  2 files changed, 173 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

 diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
 b/Documentation/devicetree/bindings/fb/drm-fimd.txt
 new file mode 100644
 index 000..4ff1829
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
 @@ -0,0 +1,80 @@
 +* Samsung Display Controller using DRM frame work
 +
 +The display controller is used to transfer image data from memory to an
 +external LCD driver interface. It supports various color formats such as
 +rgb and yuv.
 +
 +Required properties:
 + - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fb for
Doesn't better to use single word? fimd or fb?. I think 'fb' is used
for framebuffer historically.
but now it's used both fb and drm, so fimd is neutral and architecture
specific.

To do this, Modify arch-exynos first and update it at each drivers it properly.

Thank you,
Kyungmin Park

 +   fimd using DRM frame work.
 + - reg: physical base address of the controller and length of memory
 +   mapped region.
 + - interrupts: Three interrupts should be specified. The interrupts should be
 +   specified in the following order.
 +   - VSYNC interrupt
 +   - FIFO level interrupt
 +   - FIMD System Interrupt
 +
 + - samsung,fimd-display: This property should specify the phandle of the
 +   display device node which holds the video interface timing with the
 +   below mentioned properties.
 +
 +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
 + horizontal timing includes four parameters in the following order.
 +
 + - horizontal back porch (in number of lcd clocks)
 + - horizontal front porch (in number of lcd clocks)
 + - hsync pulse width (in number of lcd clocks)
 + - Display panels X resolution.
 +
 +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
 + vertical timing includes four parameters in the following order.
 +
 + - vertical back porch (in number of lcd lines)
 + - vertical front porch (in number of lcd lines)
 + - vsync pulse width (in number of lcd clocks)
 + - Display panels Y resolution.
 +
 +
 + - samsung,default-window: Specifies the default window number of the fimd 
 controller.
 +
 + - samsung,fimd-win-bpp: Specifies the bits per pixel.
 +
 +Optional properties:
 + - samsung,fimd-vidout-rgb: Video output format is RGB.
 + - samsung,fimd-inv-vclk: invert video clock polarity.
 + - samsung,fimd-frame-rate: Number of video frames per second.
 +
 +Example:
 +
 +   The following is an example for the fimd controller is split into
 +   two portions. The SoC specific portion can be specified in the SoC
 +   specific dts file. The board specific portion can be specified in the
 +   board specific dts file.
 +
 +   - SoC Specific portion
 +
 +   fimd {
 +   compatible = samsung,exynos5-fimd;
 +   interrupt-parent = combiner;
 +   reg = 0x1440 0x4;
 +   interrupts = 18 5, 18 4, 18 6;
 +   };
 +
 +   - Board Specific portion
 +
 +   lcd_fimd0: lcd_panel0 {
 +   lcd-htiming = 4 4 4 480;
 +   lcd-vtiming = 4 4 4 320;
 +   supports-mipi-panel;
 +   };
 +
 +   fimd {
 +   samsung,fimd-display = lcd_fimd0;
 +   samsung,fimd-vidout-rgb;
 +   samsung,fimd-inv-vclk;
 +   samsung,fimd-frame-rate = 60;
 +   samsung,default-window = 0;
 +   samsung,fimd-win-bpp = 32;
 +   };
 +
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index 3701fbe..a4fa8e9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -18,6 +18,7 @@
  #include linux/platform_device.h
  #include linux/clk.h
  #include linux/pm_runtime.h
 +#include linux/of.h

  #include video/samsung_fimd.h
  #include drm/exynos_drm.h
 @@ -103,9 +104,18 @@ struct fimd_context {
 struct exynos_drm_panel_info *panel;
  };

 +static const struct of_device_id fimd_dt_match[];
 +
  static inline struct fimd_driver_data *drm_fimd_get_driver_data(
 struct platform_device *pdev)
  {
 +#ifdef CONFIG_OF
 +   if (pdev-dev.of_node) {
 +   const struct of_device_id *match;
 +   match = of_match_ptr(fimd_dt_match);
 +   return (struct fimd_driver_data *)match-data;
 +   }
 +#endif
 return (struct fimd_driver_data

Re: [PATCH 1/2] ARM: exynos: delete redundant HAVE_SCHED_CLOCK option in Kconfig

2012-08-31 Thread Kyungmin Park
Hi,

then where select it HAVE_SCHED_CLOCK? apart from other exynos board,
universal have to use another clock.

Thank you,
Kyungmin Park

On 8/31/12, Barry Song barry.s...@csr.com wrote:
 From: Barry Song baohua.s...@csr.com

 Signed-off-by: Barry Song baohua.s...@csr.com
 ---
  arch/arm/mach-exynos/Kconfig |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index b5b4c8c..3fd4ab3 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -243,7 +243,6 @@ config MACH_UNIVERSAL_C210
   select CPU_EXYNOS4210
   select S5P_HRT
   select CLKSRC_MMIO
 - select HAVE_SCHED_CLOCK
   select S5P_GPIO_INT
   select S5P_DEV_FIMC0
   select S5P_DEV_FIMC1
 --
 1.7.0.4



 Member of the CSR plc group of companies. CSR plc registered in England and
 Wales, registered number 4187346, registered office Churchill House,
 Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
 More information can be found at www.csr.com. Follow CSR on Twitter at
 http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

 ___
 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/2] ARM: exynos: delete redundant HAVE_SCHED_CLOCK option in Kconfig

2012-08-31 Thread Kyungmin Park
Acked-by: Kyungmin Park kyungmin.p...@samsung.com

# git grep HAVE_SCHED_CLOCK arch/arm/
arch/arm/Kconfig:   select HAVE_SCHED_CLOCK
arch/arm/mach-exynos/Kconfig:   select HAVE_SCHED_CLOCK

On 8/31/12, Barry Song 21cn...@gmail.com wrote:
 2012/8/31 Kyungmin Park kmp...@infradead.org:
 Hi,

 then where select it HAVE_SCHED_CLOCK? apart from other exynos board,
 universal have to use another clock.

 The old arch/arm/kernel/Makefile:
 obj-$(CONFIG_HAVE_SCHED_CLOCK)  += sched_clock.o
 has become:
 obj-y += sched_clock.o


 Thank you,
 Kyungmin Park

 On 8/31/12, Barry Song barry.s...@csr.com wrote:
 From: Barry Song baohua.s...@csr.com

 Signed-off-by: Barry Song baohua.s...@csr.com
 ---
  arch/arm/mach-exynos/Kconfig |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index b5b4c8c..3fd4ab3 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -243,7 +243,6 @@ config MACH_UNIVERSAL_C210
   select CPU_EXYNOS4210
   select S5P_HRT
   select CLKSRC_MMIO
 - select HAVE_SCHED_CLOCK
   select S5P_GPIO_INT
   select S5P_DEV_FIMC0
   select S5P_DEV_FIMC1
 --
 1.7.0.4

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

--
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/6] ARM: EXYNOS: Add support for Trats board using device tree

2012-08-29 Thread Kyungmin Park
+ Thomas Abraham,

 -Original Message-
 From: Tomasz Figa [mailto:t.f...@samsung.com]
 Sent: Wednesday, August 29, 2012 10:13 PM
 To: linux-samsung-soc@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org; kyungmin.p...@samsung.com;
 kgene@samsung.com; jy0922.s...@samsung.com; Tomasz Figa
 Subject: [PATCH 0/6] ARM: EXYNOS: Add support for Trats board using device
 tree
 
 This patch series adds basic device tree support for Samsung Trats board
 along with any necessary prerequisites.
 
 In addition it refactors Exynos4 dts include files to split parts common
 to
 the whole Exynos4 part from parts specific to Exynos4210 to allow further
 extension of Exynos4210 dts include file and addition of include files for
 other SoCs from Exynos4 line.
 
 Dependencies:
 - [PATCH v5] mmc: sdhci-s3c: Add device tree support
 http://www.spinics.net/lists/linux-samsung-soc/msg12056.html
 - [PATCH v5 2/2] regulator: add device tree support for max8997
 http://www.spinics.net/lists/kernel/msg1328117.html
 
 Tomasz Figa (6):
   ARM: dts: Move parts common to Exynos4 from Exynos4210.dtsi to
 Exynos4.dtsi
   ARM: EXYNOS: exynos4-dt: Use exynos4 prefix instead of exynos4210
   ARM: Exynos4: dts: Specify address and size cells for i2c controllers
   ARM: Exynos4: Add OF compatibility lookups for Exynos4 i2c adapters
   ARM: EXYNOS: Increase maximum possible memory bank size to 512MiB
   ARM: Exynos: Add basic dts file for Samsung Trats board
 
  arch/arm/boot/dts/exynos4.dtsi | 418
 +
  arch/arm/boot/dts/exynos4210-trats.dts | 287 
  arch/arm/boot/dts/exynos4210.dtsi  | 377
+-
  arch/arm/mach-exynos/Makefile.boot |   2 +-
  arch/arm/mach-exynos/include/mach/memory.h |   4 +-
  arch/arm/mach-exynos/mach-exynos4-dt.c |  34 ++-
  6 files changed, 734 insertions(+), 388 deletions(-)
  create mode 100644 arch/arm/boot/dts/exynos4.dtsi
  create mode 100644 arch/arm/boot/dts/exynos4210-trats.dts
 
 --
 1.7.12

--
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: EXYNOS: Use EXYNOS4210_GPEx instead of EXYNOS4_GPEx

2012-08-28 Thread Kyungmin Park
On 8/29/12, Kukjin Kim kgene@samsung.com wrote:
 On 08/28/12 03:06, Tomasz Figa wrote:
 The GPEx gpios are specific to Exynos4210 and do not exist on Exynos4x12.
 Redefine them to use the exact SoC name.

 Based on ARM: EXYYNOS: Use EXYNOS4210_GPEx instead of EXYNOS4_GPEx by
 Joonyoung Shim, see:
 http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/100738.html

 Signed-off-by: Tomasz Figat.f...@samsung.com
 ---
   arch/arm/mach-exynos/include/mach/gpio.h   | 32
 +++---
   arch/arm/mach-exynos/mach-nuri.c   | 16 +++
   arch/arm/mach-exynos/mach-origen.c |  6 +++---
   arch/arm/mach-exynos/mach-trats.c  |  4 ++--
   arch/arm/mach-exynos/mach-universal_c210.c | 32
 +++---
   arch/arm/mach-exynos/setup-fimc.c  |  4 ++--
   drivers/gpio/gpio-samsung.c| 20 +--
   7 files changed, 57 insertions(+), 57 deletions(-)

 diff --git a/arch/arm/mach-exynos/include/mach/gpio.h
 b/arch/arm/mach-exynos/include/mach/gpio.h
 index eb24f1e..21c9bf1 100644
 --- a/arch/arm/mach-exynos/include/mach/gpio.h
 +++ b/arch/arm/mach-exynos/include/mach/gpio.h
 @@ -26,11 +26,11 @@
   #define EXYNOS4_GPIO_C1_NR (5)
   #define EXYNOS4_GPIO_D0_NR (4)
   #define EXYNOS4_GPIO_D1_NR (4)
 -#define EXYNOS4_GPIO_E0_NR  (5)
 -#define EXYNOS4_GPIO_E1_NR  (8)
 -#define EXYNOS4_GPIO_E2_NR  (6)
 -#define EXYNOS4_GPIO_E3_NR  (8)
 -#define EXYNOS4_GPIO_E4_NR  (8)
 +#define EXYNOS4210_GPIO_E0_NR   (5)
 +#define EXYNOS4210_GPIO_E1_NR   (8)
 +#define EXYNOS4210_GPIO_E2_NR   (6)
 +#define EXYNOS4210_GPIO_E3_NR   (8)
 +#define EXYNOS4210_GPIO_E4_NR   (8)

 Please see my comments on Joonyoung Shim's previous patch...
 http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101522.html

It's perference issue. some person like this style. others doesn't.
Moreever vender, System LSI, provided codes have whole different style.
It lists up whole gpios for each SoCs.

EXYNOS4210_{A0,  Z}
EXYNOS4412_{A0,  V4}
EXYNOS5250_{A0,  Z}

anyway, just remain it as broken, and try to use pinctl as Thomas mentioned.

Thank you,
Kyungmin Park


 [...]

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


Re: [PATCH] ARM: EXYNOS: Use non-secure MDMA1

2012-08-28 Thread Kyungmin Park
On 8/29/12, Kukjin Kim kgene@samsung.com wrote:
 On 08/28/12 04:08, Tomasz Figa wrote:
 Using secure MDMA1 on TrustZone-enabled boards causes early boot crash,
 so use non-secure instead.

 Signed-off-by: Tomasz Figat.f...@samsung.com
 Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
 ---
   arch/arm/mach-exynos/dma.c  | 2 +-
   arch/arm/mach-exynos/include/mach/map.h | 3 ++-
   2 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
 index f60b66d..8858df5 100644
 --- a/arch/arm/mach-exynos/dma.c
 +++ b/arch/arm/mach-exynos/dma.c
 @@ -261,7 +261,7 @@ static struct dma_pl330_platdata exynos_mdma1_pdata =
 {
   };

   static AMBA_AHB_DEVICE(exynos_mdma1,  dma-pl330.2, 0x00041330,
 -EXYNOS4_PA_MDMA1, {EXYNOS4_IRQ_MDMA1},exynos_mdma1_pdata);
 +EXYNOS4_PA_NS_MDMA1, {EXYNOS4_IRQ_MDMA1},exynos_mdma1_pdata);

   static int __init exynos_dma_init(void)
   {
 diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
 exynos/include/mach/map.h
 index 51943f2..5df5910 100644
 --- a/arch/arm/mach-exynos/include/mach/map.h
 +++ b/arch/arm/mach-exynos/include/mach/map.h
 @@ -89,7 +89,8 @@
   #define EXYNOS4_PA_L2CC0x10502000

   #define EXYNOS4_PA_MDMA0   0x1081
 -#define EXYNOS4_PA_MDMA10x1284
 +#define EXYNOS4_PA_S_MDMA1  0x1284
 +#define EXYNOS4_PA_NS_MDMA1 0x1285
   #define EXYNOS4_PA_PDMA0   0x1268
   #define EXYNOS4_PA_PDMA1   0x1269
   #define EXYNOS5_PA_MDMA0   0x1080

 Cc'ed Boojin Kim.

 Well, just fix the address is enough like exynos5 stuff? I don't have
 any idea why we need secure mdma and non-secure mdma both here...

Did you see the datasheet and your team codes?

 diff --git a/arch/arm/mach-exynos/include/mach/map.h
 b/arch/arm/mach-exynos/include/mach/map.h
 index c72b675..c941053 100644
 --- a/arch/arm/mach-exynos/include/mach/map.h
 +++ b/arch/arm/mach-exynos/include/mach/map.h
 @@ -89,7 +89,7 @@
   #define EXYNOS4_PA_L2CC0x10502000

   #define EXYNOS4_PA_MDMA00x1081
 -#define EXYNOS4_PA_MDMA1 0x1284
 +#define EXYNOS4_PA_MDMA1 0x1285
   #define EXYNOS4_PA_PDMA00x1268
   #define EXYNOS4_PA_PDMA10x1269
   #define EXYNOS5_PA_MDMA00x1080
 --

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.

 ___
 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] ODROID-X: hkdk4412: Add new hardware based on Exynos4412

2012-08-06 Thread Kyungmin Park
On 8/7/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 On 7 August 2012 07:58, Olof Johansson o...@lixom.net wrote:
 Hi,

 On Mon, Aug 6, 2012 at 7:05 PM, Dongjin Kim
 dongjin@agreeyamobility.net wrote:
 Hello,

 I am trying to understand what I have to do for device tree.

 In order to create dts file for ODROID-X hardware, it seems I may need
 dts file of EXYNOS4412 SoC.
 But maybe exynos4412.dtsi is not merged yet or not exist, like
 exynos4210.dtsi or exynos5250.dtsi.
 Obviously it seems not easy to create such a file without SoC datasheet,
 and I do not have it.

 So do I wait for the file to be merged by Samsung or better to create
 initial dts file cloned from exynos4210.dtsi and modify to have verified
 nodes with the source/header files?

 Ideally they already have one waiting to be submitted, but that might
 not be the case. Given that the origenboard design with 4412 is not
 yet shipping, I'm guessing the Linaro Samsung engineers might not have
 done much work on 4412 yet. Kukjin? Thomas?

 What's your suggestion?

 The alternative is to use the data you have available -- i.e. sources
 and patches, and craft the device tree from there. The design of 4412
 is a derivative from 4210, so that's a good start. Next step would be
 to describe the board on top of the SoC, peripherals, etc. Take a look
 at how the origen board support was added, and so on.

 I ordered an odroid-x several weeks ago but I haven't have a confirmed
 shipping date yet. :( I'm not sure how long it'll be before I can help
 out, unfortunately.


 -Olof

 Most of the Exynos4210 device tree support can be reused for
 Exynos4412 as well. Looking at the hardware differences between the
 two, it might be better to create a new exynos4.dtsi file (kind of
 creating it out of the existing exynos4210.dtsi) which will have all
 the common bits across all SoC's in the Exynos4 family.

 Further, there can be exynos4210.dtsi and exynos4412.dtsi which would
 specify SoC specific differences such as the GIC cpu-offset property
 and the additional groups available in the interrupt combiner.

 There are differences in the gpio/pinmux controllers as well which
 have to be described using device tree. The current gpio/pinmux device
 tree support depends entirely on the gpio-samsung driver which handles
 both gpio and pinmux but requires listing all the banks available in
 Exynos4412. I would prefer not to do that since we are switching over
 to using a pin controller driver and I am currently working on this
 driver.

 The pin controller driver is important without which the
 gpio/pinmux/pinconf setting for devices such as i2c and sdhci
 controller cannot be setup. The basic pinctrl driver for Exynos4 has
 already been posted and now I am working on adding gpio and wakeup
 interrupt support into that driver (hoping to complete it this week).

 So the probable steps in getting started with using device tree for
 Exynos4412 would be

 1. Create a new exynos4.dtsi file with all the Exynos4 common
 properties for all dt supported controllers.
 2. Update the exynos4210.dtsi file accordingly and add the new
 exynos4412.dtsi file.
 3. With this, it will be possible to boot the kernel and test
 peripherals that do not depend on gpio/pinmux (rtc, wdt, etc).
 4. When the Exynos4 pinctrl driver is available, start adding device
 nodes for i2c and sdhci controllers.
 5. Incrementally add device tree coverage for the board and other
 peripherals on Exynos4412.
Nice!
Good plan as I thnk.

Thank you,
Kyungmin 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


Re: [PATCH v5 5/5] ARM: exynos: add thermal sensor driver platform data support

2012-07-13 Thread Kyungmin Park
On Fri, Jul 13, 2012 at 8:10 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
 Add necessary default platform data support needed for TMU driver.  This
 dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
 platforms.
Looks good to me.
just nitpicks below.

Thank you,
Kyungmin Park

 Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
 Cc: Donggeun Kim dg77@samsung.com
 Acked-by: Guenter Roeck guenter.ro...@ericsson.com
 Cc: SangWook Ju sw...@samsung.com
 Cc: Durgadoss durgados...@intel.com
 Cc: Len Brown l...@kernel.org
 Cc: Jean Delvare kh...@linux-fr.org
 Signed-off-by: Andrew Morton a...@linux-foundation.org
 ---
  drivers/thermal/exynos_thermal.c |  111 
 +-
  1 files changed, 110 insertions(+), 1 deletions(-)

 diff --git a/drivers/thermal/exynos_thermal.c 
 b/drivers/thermal/exynos_thermal.c
 index 9ef8c37..07736ea 100644
 --- a/drivers/thermal/exynos_thermal.c
 +++ b/drivers/thermal/exynos_thermal.c
 @@ -662,14 +662,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
  static struct thermal_sensor_conf exynos_sensor_conf = {
 .name   = exynos-therm,
 .read_temperature   = (int (*)(void *))exynos_tmu_read,
 +};
 +
 +#if defined(CONFIG_CPU_EXYNOS4210)
BTW, doesn't it same as exynos4412? does it different from exynos4412?
If it's same, it's better to use CONFIG_SOC_EXYNOS4?
 +static struct exynos_tmu_platform_data const exynos4_default_tmu_data = {
 +   .threshold = 80,
 +   .trigger_levels[0] = 5,
 +   .trigger_levels[1] = 20,
 +   .trigger_levels[2] = 30,
 +   .trigger_level0_en = 1,
 +   .trigger_level1_en = 1,
 +   .trigger_level2_en = 1,
 +   .trigger_level3_en = 0,
 +   .gain = 15,
 +   .reference_voltage = 7,
 +   .cal_type = TYPE_ONE_POINT_TRIMMING,
 +   .freq_tab[0] = {
 +   .freq_clip_max = 800 * 1000,
 +   .temp_level = 85,
 +   },
 +   .freq_tab[1] = {
 +   .freq_clip_max = 200 * 1000,
 +   .temp_level = 100,
 +   },
 +   .freq_tab_count = 2,
 +   .type = SOC_ARCH_EXYNOS4,
 +};
 +#define EXYNOS4_TMU_DRV_DATA (exynos4_default_tmu_data)
 +#else
 +#define EXYNOS4_TMU_DRV_DATA (NULL)
 +#endif
 +
 +#if defined(CONFIG_SOC_EXYNOS5250)
similar.
 +static struct exynos_tmu_platform_data const exynos5_default_tmu_data = {
 +   .trigger_levels[0] = 85,
 +   .trigger_levels[1] = 103,
 +   .trigger_levels[2] = 110,
 +   .trigger_level0_en = 1,
 +   .trigger_level1_en = 1,
 +   .trigger_level2_en = 1,
 +   .trigger_level3_en = 0,
 +   .gain = 8,
 +   .reference_voltage = 16,
 +   .noise_cancel_mode = 4,
 +   .cal_type = TYPE_ONE_POINT_TRIMMING,
 +   .efuse_value = 55,
 +   .freq_tab[0] = {
 +   .freq_clip_max = 800 * 1000,
 +   .temp_level = 85,
 +   },
 +   .freq_tab[1] = {
 +   .freq_clip_max = 200 * 1000,
 +   .temp_level = 103,
 +   },
 +   .freq_tab_count = 2,
 +   .type = SOC_ARCH_EXYNOS5,
 +};
 +#define EXYNOS5_TMU_DRV_DATA (exynos5_default_tmu_data)
 +#else
 +#define EXYNOS5_TMU_DRV_DATA (NULL)
 +#endif
 +
 +#ifdef CONFIG_OF
 +static const struct of_device_id exynos_tmu_match[] = {
 +   {
 +   .compatible = samsung,exynos4-tmu,
 +   .data = (void *)EXYNOS4_TMU_DRV_DATA,
 +   },
 +   {
 +   .compatible = samsung,exynos5-tmu,
 +   .data = (void *)EXYNOS5_TMU_DRV_DATA,
 +   },
 +   {},
 +};
 +MODULE_DEVICE_TABLE(of, exynos_tmu_match);
 +#else
 +#define  exynos_tmu_match NULL
 +#endif
 +
 +static struct platform_device_id exynos_tmu_driver_ids[] = {
 +   {
 +   .name   = exynos4-tmu,
 +   .driver_data= (kernel_ulong_t)EXYNOS4_TMU_DRV_DATA,
 +   },
 +   {
 +   .name   = exynos5-tmu,
 +   .driver_data= (kernel_ulong_t)EXYNOS5_TMU_DRV_DATA,
 +   },
 +   { },
 +};
 +MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
 +
 +static inline struct  exynos_tmu_platform_data *exynos_get_driver_data(
 +   struct platform_device *pdev)
 +{
 +#ifdef CONFIG_OF
 +   if (pdev-dev.of_node) {
 +   const struct of_device_id *match;
 +   match = of_match_node(exynos_tmu_match, pdev-dev.of_node);
 +   if (!match)
 +   return NULL;
 +   return (struct exynos_tmu_platform_data *) match-data;
 +   }
 +#endif
 +   return (struct exynos_tmu_platform_data *)
 +   platform_get_device_id(pdev)-driver_data;
  }
 -;
  static int __devinit exynos_tmu_probe(struct platform_device *pdev)
  {
 struct exynos_tmu_data *data;
 struct exynos_tmu_platform_data *pdata = pdev-dev.platform_data;
 int ret, i;

 +   if (!pdata)
 +   pdata = exynos_get_driver_data(pdev

Re: [PATCH 05/20] ARM: EXYNOS: Redefine IRQ_MCT_L0,1 definition

2012-05-26 Thread Kyungmin Park
Hi,

On Tue, May 1, 2012 at 4:14 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
 From: Changhwan Youn chaos.y...@samsung.com

 Redefine IRQ_MCT_L0,1 irq definition as it is changed in rev1 of EXYNOS5.

 Signed-off-by: Changhwan Youn chaos.y...@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/include/mach/irqs.h |    4 ++--
  arch/arm/mach-exynos/mct.c               |   17 +++--
  2 files changed, 13 insertions(+), 8 deletions(-)

 diff --git a/arch/arm/mach-exynos/include/mach/irqs.h 
 b/arch/arm/mach-exynos/include/mach/irqs.h
 index 591e7852..ef52f61 100644
 --- a/arch/arm/mach-exynos/include/mach/irqs.h
 +++ b/arch/arm/mach-exynos/include/mach/irqs.h
 @@ -331,6 +331,8 @@
  #define EXYNOS5_IRQ_SATA               IRQ_SPI(115)
  #define EXYNOS5_IRQ_NFCON              IRQ_SPI(116)

 +#define EXYNOS5_IRQ_MCT_L0             IRQ_SPI(120)
 +#define EXYNOS5_IRQ_MCT_L1             IRQ_SPI(121)
  #define EXYNOS5_IRQ_MMC44              IRQ_SPI(123)
  #define EXYNOS5_IRQ_MDMA1              IRQ_SPI(124)
  #define EXYNOS5_IRQ_FIMC_LITE0         IRQ_SPI(125)
 @@ -410,8 +412,6 @@
  #define EXYNOS5_IRQ_FIMD1_SYSTEM       COMBINER_IRQ(18, 6)

  #define EXYNOS5_IRQ_EINT0              COMBINER_IRQ(23, 0)
 -#define EXYNOS5_IRQ_MCT_L0             COMBINER_IRQ(23, 1)
 -#define EXYNOS5_IRQ_MCT_L1             COMBINER_IRQ(23, 2)
  #define EXYNOS5_IRQ_MCT_G0             COMBINER_IRQ(23, 3)
  #define EXYNOS5_IRQ_MCT_G1             COMBINER_IRQ(23, 4)
  #define EXYNOS5_IRQ_MCT_G2             COMBINER_IRQ(23, 5)
 diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
 index 897d9a9..b601fb8 100644
 --- a/arch/arm/mach-exynos/mct.c
 +++ b/arch/arm/mach-exynos/mct.c
 @@ -388,6 +388,7 @@ static int __cpuinit exynos4_local_timer_setup(struct 
 clock_event_device *evt)
  {
        struct mct_clock_event_device *mevt;
        unsigned int cpu = smp_processor_id();
 +       int mct_lx_irq;

        mevt = this_cpu_ptr(percpu_mct_tick);
        mevt-evt = evt;
 @@ -414,14 +415,18 @@ static int __cpuinit exynos4_local_timer_setup(struct 
 clock_event_device *evt)

        if (mct_int_type == MCT_INT_SPI) {
                if (cpu == 0) {
 +                       mct_lx_irq = soc_is_exynos4210() ? EXYNOS4_IRQ_MCT_L0 
 :
 +                                               EXYNOS5_IRQ_MCT_L0;
Does it still valid for exynos4x12?. It means exynos4x12 uses
EXYNOS5_IRQ_MCT_L0?
                        mct_tick0_event_irq.dev_id = mevt;
 -                       evt-irq = EXYNOS4_IRQ_MCT_L0;
 -                       setup_irq(EXYNOS4_IRQ_MCT_L0, mct_tick0_event_irq);
 +                       evt-irq = mct_lx_irq;
 +                       setup_irq(mct_lx_irq, mct_tick0_event_irq);
                } else {
 +                       mct_lx_irq = soc_is_exynos4210() ? EXYNOS4_IRQ_MCT_L1 
 :
 +                                               EXYNOS5_IRQ_MCT_L1;
ditto
                        mct_tick1_event_irq.dev_id = mevt;
 -                       evt-irq = EXYNOS4_IRQ_MCT_L1;
 -                       setup_irq(EXYNOS4_IRQ_MCT_L1, mct_tick1_event_irq);
 -                       irq_set_affinity(EXYNOS4_IRQ_MCT_L1, cpumask_of(1));
 +                       evt-irq = mct_lx_irq;
 +                       setup_irq(mct_lx_irq, mct_tick1_event_irq);
 +                       irq_set_affinity(mct_lx_irq, cpumask_of(1));
                }
        } else {
                enable_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER, 0);
 @@ -473,7 +478,7 @@ static void __init exynos4_timer_resources(void)

  static void __init exynos4_timer_init(void)
  {
 -       if (soc_is_exynos4210())
 +       if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
                mct_int_type = MCT_INT_SPI;
        else
                mct_int_type = MCT_INT_PPI;

BTW exynos4x12 uses MCT_INT_PPI?

Kyungmin Park
 --
 1.7.5.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 0/2] regulator: Add initial suport for max77686

2012-05-22 Thread Kyungmin Park
Hi Mark,

BTW, do you know that you're reviewing the same device driver patch
from different person?
One from Mr. Lee and another from Yadwinder.

I wonder how to handle it finally. which one is choose?

Thank you,
Kyungmin Park

On 5/22/12, yadi.bra...@gmail.com yadi.bra...@gmail.com wrote:
 From: Yadwinder Singh Brar yadi.b...@samsung.com

 This patch series adds support for max77686 which is a multifunction device
 which includes regulator (pmic), rtc and charger sub-blocks within it. The
 support for mfd driver and regulator driver are added by this patch series.
 This
 patch series also includes device tree and irqdomain support for mfd and
 regulator portions.

 Implemented the required modification, stated in the recieved review
 comments.
 changes since v1:
 -added regmap support.
 -implemented .get_voltage_sel, .set_voltage_sel and .set_voltage_time_sel
 after
  removing .get_voltage and .set_voltage in regulator driver.
 -used of_regulator_match() for parsing DT.
 -added Documentation for Devive Tree binding.

 changes since v2:
 -converted to use regulator_get_voltage_sel_regmap,
  regulator_set_voltage_sel_regmap, regulator_enable_regmap,
  regulator_disable_regmap, regulator_is_enabled_regmap.

 This patch series is based on mark_regulator/for-next and has been tested
 on
 GAIA board.

 Yadwinder Singh Brar (2):
   mfd: Add support for MAX77686.
   regulator: Add support for MAX77686.

  Documentation/devicetree/bindings/mfd/max77686.txt |   61 +++
  drivers/mfd/Kconfig|   21 +
  drivers/mfd/Makefile   |1 +
  drivers/mfd/max77686-irq.c |  255 +
  drivers/mfd/max77686.c |  322 
  drivers/regulator/Kconfig  |9 +
  drivers/regulator/Makefile |1 +
  drivers/regulator/max77686.c   |  389
 
  include/linux/mfd/max77686-private.h   |  282 ++
  include/linux/mfd/max77686.h   |  100 +
  10 files changed, 1441 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mfd/max77686.txt
  create mode 100644 drivers/mfd/max77686-irq.c
  create mode 100644 drivers/mfd/max77686.c
  create mode 100644 drivers/regulator/max77686.c
  create mode 100644 include/linux/mfd/max77686-private.h
  create mode 100644 include/linux/mfd/max77686.h

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

--
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: [PATCHv2 0/3] Add support for DRM display subsystem

2012-05-10 Thread Kyungmin Park
On 5/10/12, Kukjin Kim kgene@samsung.com wrote:
 Marek Szyprowski wrote:

 Hello,

 This patch set adds support for Exynos DRM display subsystem for
 Universal C210 and NURI boards. Exynos DRM driver has been merged to 3.3
 kernel tree and provides unified and more powerful alternative for
 s3c-fb and s5p-tv drivers. V2 includes update for the latest changes in
 platform data structure (added 'panel' entry).

 Best regards

 Marek Szyprowski
 Samsung Poland RD Center

 Patch summary:

 Marek Szyprowski (3):
   ARM: Exynos: add platform device for core DRM subsystem
   ARM: Exynos: Add DRM core device support for Universal C210 board
   ARM: Exynos: Add DRM core support for NURI board

  arch/arm/mach-exynos/Kconfig   |7 ++
  arch/arm/mach-exynos/Makefile  |1 +
  arch/arm/mach-exynos/dev-drm.c |   29
 
  arch/arm/mach-exynos/mach-nuri.c   |   33
 
  arch/arm/mach-exynos/mach-universal_c210.c |   33
 
  arch/arm/plat-samsung/include/plat/devs.h  |2 +
  6 files changed, 105 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-exynos/dev-drm.c

 --
 1.7.1.569.g6f426

 Well, 2nd and 3rd patches can break multi-platform for EXYNOS SoCs with one
 kernel image.

 And I won't apply new feature for non-dt board file from now on. I think,
 we
 need to support DT in mach-exynos/ instead of non-DT and DT together, so
 please consider to move on dt supporting for Samsung mobile boards.


Probably you misunderstand Arnd word.

From the statements made so far, I can see no clear policy that we can
apply to everyone. My take on this is that for any work I spend on
multiplatform kernel, I concentrate on the DT-based board files and
get them to work together first, but leave it up to the individual
subarch maintainers whether they want to add other board files into
the mix.

It doesn't mean add new feature to non-DT board. don't add new board file.

In this case, DRM is not yet ready to support DT.

Okay, you can just drop this patches. but please note that this
patches are posted at Mar 13 before you decide.

BR,
Kyungmin Park

 Note that I have a plan to replace board files with DT supporting in
 mach-exynos/ next time.

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.

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

--
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/7] mmc: dw_mmc: add device tree support

2012-05-10 Thread Kyungmin Park
On 5/10/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 Dear Mr. Park,

 On 2 May 2012 12:25, Kyungmin Park kmp...@infradead.org wrote:
 Hi,

 On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 Add device tree based discovery support.

 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  .../devicetree/bindings/mmc/synposis-dw-mshc.txt   |   85 +
  drivers/mmc/host/dw_mmc-pltfm.c|   24 +++
  drivers/mmc/host/dw_mmc.c  |  181
 +++-
  drivers/mmc/host/dw_mmc.h  |   10 +
  include/linux/mmc/dw_mmc.h |2 +
  5 files changed, 296 insertions(+), 6 deletions(-)
  create mode 100644
 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt

 diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 new file mode 100644
 index 000..c1ed70e
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 @@ -0,0 +1,85 @@
 +* Synopsis Designware Mobile Storage Host Controller
 +
 +The Synopsis designware mobile storage host controller is used to
 interface
 +a SoC with storage medium such as eMMC or SD/MMC cards.
 +
 +Required Properties:
 +
 +* compatible: should be one of the following
 + - synopsis,dw-mshc: for controllers compliant with synopsis
 dw-mshc.
 I googled the Synopsis Designware Mobile Storage Host Controller and
 Synopsis released it as this name. but still I like the 'dw-mmc'
 instead of'dw-mshc'.

 Ok. Synopsis abbreviates this controller as MSHC in their datasheets
 available online. Since device tree is more about describing the
 hardware, using MSHC as the abbreviation will help with correlating
 hardware specs with the dts file. So I would prefer to continue using
 mshc as the abbreviation.

Then why author of this file uses dw-mmc instead of dw-mshc? and
it uses 'dw_mci' prefix at functions. I just worried and don't want to
give confusion to users who uses this device.


 +
 +* reg: physical base address of the dw-mshc controller and size of its
 memory
 +  region.
 +
 +* interrupts: interrupt specifier for the controller. The format and
 value
 of
 +  the interrupt specifier depends on the interrupt parent for the
 controller.
 +
 +# Slots: The slot specific information are contained within child-nodes
 with
 +  each child-node representing a supported slot. There should be
 atleast
 one
 +  child node representing a card slot. The name of the slot child node
 should
 +  be 'slot{n}' where n is the unique number of the slot connnected to
 the
 +  controller. The following are optional properties which can be
 included
 in
 +  the slot child node.
 +
 + * bus-width: specifies the width of the data bus connected from
 the
 +   controller to the card slot. The value should be 1, 4 or 8. In
 case
 +   this property is not specified, a default value of 1 is assumed
 for
 +   this property.
 +
 + * cd-gpios: specifies the card detect gpio line. The format of the
 +   gpio specifier depends on the gpio controller.
 +
 + * wp-gpios: specifies the write protect gpio line. The format of
 the
 +   gpio specifier depends on the gpio controller.
 +
 + * gpios: specifies a list of gpios used for command, clock and
 data
 +   bus. The first gpio is the command line and the second gpio is
 the
 +   clock line. The rest of the gpios (depending on the bus-width
 +   property) are the data lines in no particular order. The format
 of
 +   the gpio specifier depends on the gpio controller.
 +
 +Optional properties:
 +
 +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is
 not
 +  specified, the default value of the fifo size is determined from the
 +  controller registers.
 +
 +*  card-detect-delay: Delay in milli-seconds before detecting card
 after
 card
 +   insert event. The default value is 0.
 +
 +* supports-highspeed: Enables support for high speed cards (upto 50MHz)
 +
 +* card-detection-broken: The card detection functionality is not
 available
 on
 +  any of the slots.
 +
 +* no-write-protect: The write protect pad of the controller is not
 connected
 +  to the write protect pin on the slot.
 +
 +Example:
 +
 +  The MSHC controller node can be split into two portions, SoC specific
 and
 +  board specific portions as listed below.
 +
 + dwmmc0@1220 {
 + compatible = synopsis,dw-mshc;
 + reg = 0x1220 0x1000;
 + interrupts = 0 75 0;
 + };
 +
 + dwmmc0@1220 {
 + supports-highspeed;
 + card-detection-broken;
 + no-write-protect;
 + fifo-depth = 0x80;
 + card-detect-delay = 200;
 +
 + slot0 {
 + bus-width = 8;
 + cd-gpios = gpc0 2 2 3 3;
 + gpios = gpc0 0 2 0 3, gpc0 1 2 0 3

Re: [PATCHv2 0/3] Add support for DRM display subsystem

2012-05-10 Thread Kyungmin Park
On Thu, May 10, 2012 at 10:48 PM, Arnd Bergmann a...@arndb.de wrote:
 On Thursday 10 May 2012, Kyungmin Park wrote:
  And I won't apply new feature for non-dt board file from now on. I think,
  we
  need to support DT in mach-exynos/ instead of non-DT and DT together, so
  please consider to move on dt supporting for Samsung mobile boards.
 

 Probably you misunderstand Arnd word.

 From the statements made so far, I can see no clear policy that we can
 apply to everyone. My take on this is that for any work I spend on
 multiplatform kernel, I concentrate on the DT-based board files and
 get them to work together first, but leave it up to the individual
 subarch maintainers whether they want to add other board files into
 the mix.

 It doesn't mean add new feature to non-DT board. don't add new board file.

 This is a completely separate discussion, the problem at hand doesn't
 have anything to do with building a kernel for multiple mach-*
 directories combined that I was referring to in the text you quote.

 In this case, DRM is not yet ready to support DT.

 Okay, you can just drop this patches. but please note that this
 patches are posted at Mar 13 before you decide.

 I think it's a good idea to make new features DT-only because this
 way we don't get any regressions and everyone who want to use
 the new feature will be able to test the DT support on his board.
The 'new feature' is some misleading word. In this case DRM drivers
are used from v3.2 at drivers. but not registered it at board file.
Basically agree to move DT and used it finally. Before that bring up
the board using DRM based graphics.

 This of course requires that basic DT support is available for the
 systems in question so we don't regress when moving away from the
 old board files. My impression is that we're getting close to that
 point on exynos thanks to Thomas' work on this. AFAICT we don't
 have a DT binding for screen timings yet, so you will still have
 to use auxdata for that or put the timings into the driver.
I'm also thanks to Thomas, he did a lot of works for eyxnos. but most
parts are missing at least exynos platform.
e.g., Please see the origen.dts. I wonder it's booted with any
graphical user interface platform, android or ubuntu.
Maybe not.

Anyway, as discussed in multi-platform support mail threads, we're
also moving to DT in the big picture. but still want to use existing
boards as is.

Thank you,
Kyungmin 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


Re: [PATCH 3/7] mmc: dw_mmc: add device tree support

2012-05-02 Thread Kyungmin Park
Hi,

On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 Add device tree based discovery support.

 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  .../devicetree/bindings/mmc/synposis-dw-mshc.txt   |   85 +
  drivers/mmc/host/dw_mmc-pltfm.c|   24 +++
  drivers/mmc/host/dw_mmc.c  |  181
 +++-
  drivers/mmc/host/dw_mmc.h  |   10 +
  include/linux/mmc/dw_mmc.h |2 +
  5 files changed, 296 insertions(+), 6 deletions(-)
  create mode 100644
 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt

 diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 new file mode 100644
 index 000..c1ed70e
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 @@ -0,0 +1,85 @@
 +* Synopsis Designware Mobile Storage Host Controller
 +
 +The Synopsis designware mobile storage host controller is used to
 interface
 +a SoC with storage medium such as eMMC or SD/MMC cards.
 +
 +Required Properties:
 +
 +* compatible: should be one of the following
 + - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
I googled the Synopsis Designware Mobile Storage Host Controller and
Synopsis released it as this name. but still I like the 'dw-mmc'
instead of'dw-mshc'.
 +
 +* reg: physical base address of the dw-mshc controller and size of its
 memory
 +  region.
 +
 +* interrupts: interrupt specifier for the controller. The format and value
 of
 +  the interrupt specifier depends on the interrupt parent for the
 controller.
 +
 +# Slots: The slot specific information are contained within child-nodes
 with
 +  each child-node representing a supported slot. There should be atleast
 one
 +  child node representing a card slot. The name of the slot child node
 should
 +  be 'slot{n}' where n is the unique number of the slot connnected to the
 +  controller. The following are optional properties which can be included
 in
 +  the slot child node.
 +
 + * bus-width: specifies the width of the data bus connected from the
 +   controller to the card slot. The value should be 1, 4 or 8. In case
 +   this property is not specified, a default value of 1 is assumed for
 +   this property.
 +
 + * cd-gpios: specifies the card detect gpio line. The format of the
 +   gpio specifier depends on the gpio controller.
 +
 + * wp-gpios: specifies the write protect gpio line. The format of the
 +   gpio specifier depends on the gpio controller.
 +
 + * gpios: specifies a list of gpios used for command, clock and data
 +   bus. The first gpio is the command line and the second gpio is the
 +   clock line. The rest of the gpios (depending on the bus-width
 +   property) are the data lines in no particular order. The format of
 +   the gpio specifier depends on the gpio controller.
 +
 +Optional properties:
 +
 +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is
 not
 +  specified, the default value of the fifo size is determined from the
 +  controller registers.
 +
 +*  card-detect-delay: Delay in milli-seconds before detecting card after
 card
 +   insert event. The default value is 0.
 +
 +* supports-highspeed: Enables support for high speed cards (upto 50MHz)
 +
 +* card-detection-broken: The card detection functionality is not available
 on
 +  any of the slots.
 +
 +* no-write-protect: The write protect pad of the controller is not
 connected
 +  to the write protect pin on the slot.
 +
 +Example:
 +
 +  The MSHC controller node can be split into two portions, SoC specific
 and
 +  board specific portions as listed below.
 +
 + dwmmc0@1220 {
 + compatible = synopsis,dw-mshc;
 + reg = 0x1220 0x1000;
 + interrupts = 0 75 0;
 + };
 +
 + dwmmc0@1220 {
 + supports-highspeed;
 + card-detection-broken;
 + no-write-protect;
 + fifo-depth = 0x80;
 + card-detect-delay = 200;
 +
 + slot0 {
 + bus-width = 8;
 + cd-gpios = gpc0 2 2 3 3;
 + gpios = gpc0 0 2 0 3, gpc0 1 2 0 3,
 + gpc1 0 2 3 3, gpc1 1 2 3 3,
 + gpc1 2 2 3 3, gpc1 3 2 3 3,
 + gpc0 3 2 3 3, gpc0 4 2 3 3,
 + gpc0 5 2 3 3, gpc0 6 2 3 3;
 + };
 + };
 diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
 b/drivers/mmc/host/dw_mmc-pltfm.c
 index 92ec3eb..2b2c9bd 100644
 --- a/drivers/mmc/host/dw_mmc-pltfm.c
 +++ b/drivers/mmc/host/dw_mmc-pltfm.c
 @@ -19,8 +19,24 @@
  #include linux/mmc/host.h
  #include linux/mmc/mmc.h
  #include linux/mmc/dw_mmc.h
 +#include linux/of.h
  #include dw_mmc.h

 +#ifdef CONFIG_OF
 +static struct dw_mci_drv_data synopsis_drv_data = {
 +   

Re: [PATCH 4/7] mmc: dw_mmc: add samsung exynos5250 specific extentions

2012-05-02 Thread Kyungmin Park
Hi,

On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 The instantiation of the Synopsis Designware controller on Exynos5250
 include extension for SDR and DDR specific tx/rx phase shift timing
 and CIU internal divider. In addition to that, the option to skip the
 command hold stage is also introduced. Add support for these Exynos5250
 specfic extenstions.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  .../devicetree/bindings/mmc/synposis-dw-mshc.txt   |   33
 +++-
  drivers/mmc/host/dw_mmc-pltfm.c|8 +
  drivers/mmc/host/dw_mmc.c  |   32
 ++-
  drivers/mmc/host/dw_mmc.h  |   13 
  include/linux/mmc/dw_mmc.h |6 +++
  5 files changed, 89 insertions(+), 3 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 index c1ed70e..465fc31 100644
 --- a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 @@ -7,6 +7,8 @@ Required Properties:

  * compatible: should be one of the following
   - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
 + - synopsis,dw-mshc-exynos5250: for controllers with Samsung
 +   Exynos5250 specific extentions.

  * reg: physical base address of the dw-mshc controller and size of its
 memory
region.
 @@ -55,13 +57,40 @@ Optional properties:
  * no-write-protect: The write protect pad of the controller is not
 connected
to the write protect pin on the slot.

 +Samsung Exynos5250 specific properties:
 +
 +* samsung,dw-mshc-sdr-timing: Specifies the value of CUI clock divider,
 CIU
 +  clock phase shift value in transmit mode and CIU clock phase shift value
 in
 +  receive mode for single data rate mode operation. Refer notes of the
 valid
 +  values below.
 +
 +* samsung,dw-mshc-ddr-timing: Specifies the value of CUI clock divider,
 CIU
 +  clock phase shift value in transmit mode and CIU clock phase shift value
 in
 +  receive mode for double data rate mode operation. Refer notes of the
 valid
 +  values below. The order of the cells should be
 +
 +- First Cell:CIU clock divider value.
 +- Second Cell:   CIU clock phase shift value for tx mode.
 +- Third Cell:CIU clock phase shift value for rx mode.
 +
 +  Valid values for SDR and DDR CIU clock timing:
 +
 +- valid values for CIU clock divider, tx phase shift and rx phase
 shift
 +  is 0 to 7.
 +
 +- When CIU clock divider value is set to 3, all possible 8 phase shift
 +  values can be used.
 +
 +- If CIU clock divider value is 0 (that is divide by 1), both tx and
 rx
 +  phase shift clocks should be 0.
 +
  Example:

The MSHC controller node can be split into two portions, SoC specific
 and
board specific portions as listed below.

   dwmmc0@1220 {
 - compatible = synopsis,dw-mshc;
 + compatible = synopsis,dw-mshc-exynos5250;
   reg = 0x1220 0x1000;
   interrupts = 0 75 0;
   };
 @@ -72,6 +101,8 @@ Example:
   no-write-protect;
   fifo-depth = 0x80;
   card-detect-delay = 200;
 + samsung,dw-mshc-sdr-timing = 2 3 3;
 + samsung,dw-mshc-ddr-timing = 1 2 3;

   slot0 {
   bus-width = 8;
 diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
 b/drivers/mmc/host/dw_mmc-pltfm.c
 index 2b2c9bd..35056fd 100644
 --- a/drivers/mmc/host/dw_mmc-pltfm.c
 +++ b/drivers/mmc/host/dw_mmc-pltfm.c
 @@ -27,9 +27,17 @@ static struct dw_mci_drv_data synopsis_drv_data = {
   .ctrl_type  = DW_MCI_TYPE_SYNOPSIS,
  };

 +static struct dw_mci_drv_data exynos5250_drv_data = {
 + .ctrl_type  = DW_MCI_TYPE_EXYNOS5250,
 + .caps   = MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
 + MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
These caps should be board specific. So it's not proper place. Esp.,
MMC_CAP_8_BIT_DATA.
 +};
 +
  static const struct of_device_id dw_mci_pltfm_match[] = {
   { .compatible = synopsis,dw-mshc,
   .data = (void *)synopsis_drv_data, },
 + { .compatible = synopsis,dw-mshc-exynos5250,
 + .data = (void *)exynos5250_drv_data, },
   {},
  };
  MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index bcf66d7..9174a69 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -236,6 +236,7 @@ static void dw_mci_set_timeout(struct dw_mci *host)
  static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command
 *cmd)
  {
   struct mmc_data *data;
 + struct dw_mci_slot *slot = mmc_priv(mmc);
   u32 cmdr;
   cmd-error = -EINPROGRESS;

 @@ 

Re: [PATCH 5/7] ARM: Samsung: Add support for MSHC controller clocks

2012-05-02 Thread Kyungmin Park
Hi Thomas,

I suggest to split the patches into mmc part and samsung specific
part. As you know previous time there's mismatch between mmc and
samsung. So split the patches and send it  separately to avoid merge
conflict and mismatch.

I think regardless mmc changes, it can be merged into samsung tree directly.

Thank you,
Kyungmin Park

On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 Add clock instances for bus interface unit clock and card interface unit
 clock of the all four MSHC controller instances.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  arch/arm/mach-exynos/clock-exynos5.c |   45
 --
  1 files changed, 16 insertions(+), 29 deletions(-)

 diff --git a/arch/arm/mach-exynos/clock-exynos5.c
 b/arch/arm/mach-exynos/clock-exynos5.c
 index 7c0f810..4e17131 100644
 --- a/arch/arm/mach-exynos/clock-exynos5.c
 +++ b/arch/arm/mach-exynos/clock-exynos5.c
 @@ -524,35 +524,30 @@ static struct clk exynos5_init_clocks_off[] = {
   .enable = exynos5_clk_ip_peris_ctrl,
   .ctrlbit= (1  19),
   }, {
 - .name   = hsmmc,
 - .devname= exynos4-sdhci.0,
 + .name   = biu,
 + .devname= dw_mmc.0,
   .parent = exynos5_clk_aclk_200.clk,
   .enable = exynos5_clk_ip_fsys_ctrl,
   .ctrlbit= (1  12),
   }, {
 - .name   = hsmmc,
 - .devname= exynos4-sdhci.1,
 + .name   = biu,
 + .devname= dw_mmc.1,
   .parent = exynos5_clk_aclk_200.clk,
   .enable = exynos5_clk_ip_fsys_ctrl,
   .ctrlbit= (1  13),
   }, {
 - .name   = hsmmc,
 - .devname= exynos4-sdhci.2,
 + .name   = biu,
 + .devname= dw_mmc.2,
   .parent = exynos5_clk_aclk_200.clk,
   .enable = exynos5_clk_ip_fsys_ctrl,
   .ctrlbit= (1  14),
   }, {
 - .name   = hsmmc,
 - .devname= exynos4-sdhci.3,
 + .name   = biu,
 + .devname= dw_mmc.3,
   .parent = exynos5_clk_aclk_200.clk,
   .enable = exynos5_clk_ip_fsys_ctrl,
   .ctrlbit= (1  15),
   }, {
 - .name   = dwmci,
 - .parent = exynos5_clk_aclk_200.clk,
 - .enable = exynos5_clk_ip_fsys_ctrl,
 - .ctrlbit= (1  16),
 - }, {
   .name   = sata,
   .devname= ahci,
   .enable = exynos5_clk_ip_fsys_ctrl,
 @@ -882,8 +877,8 @@ static struct clksrc_clk exynos5_clk_sclk_uart3 = {

  static struct clksrc_clk exynos5_clk_sclk_mmc0 = {
   .clk= {
 - .name   = sclk_mmc,
 - .devname= exynos4-sdhci.0,
 + .name   = ciu,
 + .devname= dw_mmc.0,
   .parent = exynos5_clk_dout_mmc0.clk,
   .enable = exynos5_clksrc_mask_fsys_ctrl,
   .ctrlbit= (1  0),
 @@ -893,8 +888,8 @@ static struct clksrc_clk exynos5_clk_sclk_mmc0 = {

  static struct clksrc_clk exynos5_clk_sclk_mmc1 = {
   .clk= {
 - .name   = sclk_mmc,
 - .devname= exynos4-sdhci.1,
 + .name   = ciu,
 + .devname= dw_mmc.1,
   .parent = exynos5_clk_dout_mmc1.clk,
   .enable = exynos5_clksrc_mask_fsys_ctrl,
   .ctrlbit= (1  4),
 @@ -904,8 +899,8 @@ static struct clksrc_clk exynos5_clk_sclk_mmc1 = {

  static struct clksrc_clk exynos5_clk_sclk_mmc2 = {
   .clk= {
 - .name   = sclk_mmc,
 - .devname= exynos4-sdhci.2,
 + .name   = ciu,
 + .devname= dw_mmc.2,
   .parent = exynos5_clk_dout_mmc2.clk,
   .enable = exynos5_clksrc_mask_fsys_ctrl,
   .ctrlbit= (1  8),
 @@ -915,8 +910,8 @@ static struct clksrc_clk exynos5_clk_sclk_mmc2 = {

  static struct clksrc_clk exynos5_clk_sclk_mmc3 = {
   .clk= {
 - .name   = sclk_mmc,
 - .devname= exynos4-sdhci.3,
 + .name   = ciu,
 + .devname= dw_mmc.3,
   .parent = exynos5_clk_dout_mmc3.clk,
   .enable = exynos5_clksrc_mask_fsys_ctrl,
   .ctrlbit= (1  12),
 @@ -927,14 +922,6 @@ static struct clksrc_clk exynos5_clk_sclk_mmc3 = {
  static struct clksrc_clk exynos5_clksrcs[] = {
   {
   .clk

Re: [PATCH] drivers: genpd: let platform code to register devices into disabled domains

2012-05-01 Thread Kyungmin Park
On 5/2/12, Rafael J. Wysocki r...@sisk.pl wrote:
 On Sunday, April 29, 2012, Rafael J. Wysocki wrote:
 On Friday, April 06, 2012, Marek Szyprowski wrote:
  Some bootloaders disable power domains on boot and the platform startup
  code registers them in the 'disabled' state. Current gen_pd code
  assumed
  that the devices can be registered only to the power domain which is in
  'enabled' state and these devices are active at the time of the
  registration. This is not correct in our case. This patch lets drivers
  to be registered into 'disabled' power domains and finally solves
  mysterious freezes and lack of resume/suspend calls on Samsung Exynos4
  NURI and UniversalC210 platforms.
 
  Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   drivers/base/power/domain.c |7 +--
   1 files changed, 1 insertions(+), 6 deletions(-)
 
  diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
  index 73ce9fb..05f5799f 100644
  --- a/drivers/base/power/domain.c
  +++ b/drivers/base/power/domain.c
  @@ -1211,11 +1211,6 @@ int __pm_genpd_add_device(struct
  generic_pm_domain *genpd, struct device *dev,
 
 genpd_acquire_lock(genpd);
 
  -  if (genpd-status == GPD_STATE_POWER_OFF) {
  -  ret = -EINVAL;
  -  goto out;
  -  }
  -
 if (genpd-prepared_count  0) {
 ret = -EAGAIN;
 goto out;
  @@ -1239,7 +1234,7 @@ int __pm_genpd_add_device(struct generic_pm_domain
  *genpd, struct device *dev,
 dev_pm_get_subsys_data(dev);
 dev-power.subsys_data-domain_data = gpd_data-base;
 gpd_data-base.dev = dev;
  -  gpd_data-need_restore = false;
  +  gpd_data-need_restore = true;

 I think that should be:

 +gpd_data-need_restore = genpd-status == GPD_STATE_POWER_OFF;

 Otherwise, on the next domain power off the device's state won't be
 saved.

 Ping?
Hi Rafael,

Now Marek is on vacation util 6 May. He'll answer at that time.
Sorry.

Thank you,
Kyungmin 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

--
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 03/12] ARM: Exynos5: Add watchdog timer clock instance

2012-04-17 Thread Kyungmin Park
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 Add watchdog timer clock instance for Exynos5 watchdog controller.

 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  arch/arm/mach-exynos/clock-exynos5.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-exynos/clock-exynos5.c
 b/arch/arm/mach-exynos/clock-exynos5.c
 index ad3bec4..662615d 100644
 --- a/arch/arm/mach-exynos/clock-exynos5.c
 +++ b/arch/arm/mach-exynos/clock-exynos5.c
 @@ -474,6 +474,11 @@ static struct clk exynos5_init_clocks_off[] = {
   .enable = exynos5_clk_ip_peris_ctrl,
   .ctrlbit= (1  20),
   }, {
 + .name   = watchdog,
 + .parent = exynos5_clk_aclk_66.clk,
 + .enable = exynos5_clk_ip_peris_ctrl,
 + .ctrlbit= (1  19),

Hi,

Can you place this in order? It has same exynos5_clk_ip_peris_ctrl,
but located under (1  20).

Thank you,
Kyungmin Park
 + }, {
   .name   = hsmmc,
   .devname= exynos4-sdhci.0,
   .parent = exynos5_clk_aclk_200.clk,
 --
 1.6.6.rc2

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

--
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 06/12] rtc-s3c: Fix breakage introduced by S3C2443/S3C2416 support

2012-04-17 Thread Kyungmin Park
Hi,

It's already merged with different patch,

#ifdef CONFIG_OF
static const struct of_device_id s3c_rtc_dt_match[] = {
{
.compatible = samsung,s3c2410-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2410],
}, {
.compatible = samsung,s3c2416-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2416],
}, {
.compatible = samsung,s3c2443-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2443],
}, {
.compatible = samsung,s3c6410-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C64XX],
},
{},
};
MODULE_DEVICE_TABLE(of, s3c_rtc_dt_match);
#else
#define s3c_rtc_dt_match NULL
#endif

Thank you,
Kyungmin Park

On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 From: Heiko Stuebner he...@sntech.de

 Commits 7006ee4f (rtc-s3c: make room for more variants in devicetree block)
 and 6c0a2365 (rtc-s3c: add variants for S3C2443 and S3C2416)
 introduced build-failures with enabled CONFIG_USE_OF option.

 This patch fixes missing , in s3c_rtc_dt_match and wrong handling of
 the of_device_id.data property.

 Reported-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Heiko Stuebner he...@sntech.de
 ---
  drivers/rtc/rtc-s3c.c |   18 +-
  1 files changed, 9 insertions(+), 9 deletions(-)

 diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
 index 9ccea13..c792b6d 100644
 --- a/drivers/rtc/rtc-s3c.c
 +++ b/drivers/rtc/rtc-s3c.c
 @@ -449,7 +449,7 @@ static inline int s3c_rtc_get_driver_data(struct
 platform_device *pdev)
   if (pdev-dev.of_node) {
   const struct of_device_id *match;
   match = of_match_node(s3c_rtc_dt_match, pdev-dev.of_node);
 - return match-data;
 + return (int)match-data;
   }
  #endif
   return platform_get_device_id(pdev)-driver_data;
 @@ -667,17 +667,17 @@ static int s3c_rtc_resume(struct platform_device
 *pdev)
  #ifdef CONFIG_OF
  static const struct of_device_id s3c_rtc_dt_match[] = {
   {
 - .compatible = samsung,s3c2410-rtc
 - .data = TYPE_S3C2410,
 + .compatible = samsung,s3c2410-rtc,
 + .data = (void *)TYPE_S3C2410,
   }, {
 - .compatible = samsung,s3c2416-rtc
 - .data = TYPE_S3C2416,
 + .compatible = samsung,s3c2416-rtc,
 + .data = (void *)TYPE_S3C2416,
   }, {
 - .compatible = samsung,s3c2443-rtc
 - .data = TYPE_S3C2443,
 + .compatible = samsung,s3c2443-rtc,
 + .data = (void *)TYPE_S3C2443,
   }, {
 - .compatible = samsung,s3c6410-rtc
 - .data = TYPE_S3C64XX,
 + .compatible = samsung,s3c6410-rtc,
 + .data = (void *)TYPE_S3C64XX,
   },
   {},
  };
 --
 1.6.6.rc2

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

--
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 07/12] ARM: Exynos5: Modify the GIC physical address for static io-mapping

2012-04-17 Thread Kyungmin Park
Hi,

On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 From: Changhwan Youn chaos.y...@samsung.com

 Adapt to changes in GIC physical address in rev1 of Exynos5.

Does it different from rev0 and rev1? and does it support the rev1 only?

Thank you,
Kyungmin Park

 Signed-off-by: Changhwan Youn chaos.y...@samsung.com
 ---
  arch/arm/mach-exynos/common.c   |4 ++--
  arch/arm/mach-exynos/include/mach/map.h |4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
 index 35ac675..457d031 100644
 --- a/arch/arm/mach-exynos/common.c
 +++ b/arch/arm/mach-exynos/common.c
 @@ -265,12 +265,12 @@ static struct map_desc exynos5_iodesc[] __initdata = {
   }, {
   .virtual= (unsigned long)S5P_VA_GIC_CPU,
   .pfn= __phys_to_pfn(EXYNOS5_PA_GIC_CPU),
 - .length = SZ_64K,
 + .length = SZ_8K,
   .type   = MT_DEVICE,
   }, {
   .virtual= (unsigned long)S5P_VA_GIC_DIST,
   .pfn= __phys_to_pfn(EXYNOS5_PA_GIC_DIST),
 - .length = SZ_64K,
 + .length = SZ_4K,
   .type   = MT_DEVICE,
   },
  };
 diff --git a/arch/arm/mach-exynos/include/mach/map.h
 b/arch/arm/mach-exynos/include/mach/map.h
 index 0e2292d..648d59b 100644
 --- a/arch/arm/mach-exynos/include/mach/map.h
 +++ b/arch/arm/mach-exynos/include/mach/map.h
 @@ -78,8 +78,8 @@

  #define EXYNOS4_PA_GIC_CPU   0x1048
  #define EXYNOS4_PA_GIC_DIST  0x1049
 -#define EXYNOS5_PA_GIC_CPU   0x1048
 -#define EXYNOS5_PA_GIC_DIST  0x1049
 +#define EXYNOS5_PA_GIC_CPU   0x10482000
 +#define EXYNOS5_PA_GIC_DIST  0x10481000

  #define EXYNOS4_PA_COREPERI  0x1050
  #define EXYNOS4_PA_TWD   0x10500600
 --
 1.6.6.rc2

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

--
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 08/12] gpio/samsung: add GPC4 bank instance

2012-04-17 Thread Kyungmin Park
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 From: Sangsu Park sangsu4u.p...@samsung.com

 Add GPC4 bank instance which is included in rev1 of Exynos5.

 Cc: Grant Likely grant.lik...@secretlab.ca
 Signed-off-by: Sangsu Park sangsu4u.p...@samsung.com
 ---
  arch/arm/mach-exynos/include/mach/gpio.h |9 ++---
  drivers/gpio/gpio-samsung.c  |8 
  2 files changed, 14 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-exynos/include/mach/gpio.h
 b/arch/arm/mach-exynos/include/mach/gpio.h
 index d7498af..df5612b 100644
 --- a/arch/arm/mach-exynos/include/mach/gpio.h
 +++ b/arch/arm/mach-exynos/include/mach/gpio.h
 @@ -153,10 +153,11 @@ enum exynos4_gpio_number {
  #define EXYNOS5_GPIO_B2_NR   (4)
  #define EXYNOS5_GPIO_B3_NR   (4)
  #define EXYNOS5_GPIO_C0_NR   (7)
 -#define EXYNOS5_GPIO_C1_NR   (7)
 +#define EXYNOS5_GPIO_C1_NR   (4)
  #define EXYNOS5_GPIO_C2_NR   (7)
  #define EXYNOS5_GPIO_C3_NR   (7)
 -#define EXYNOS5_GPIO_D0_NR   (8)
 +#define EXYNOS5_GPIO_C4_NR   (8)
 +#define EXYNOS5_GPIO_D0_NR   (4)
  #define EXYNOS5_GPIO_D1_NR   (8)
  #define EXYNOS5_GPIO_Y0_NR   (6)
  #define EXYNOS5_GPIO_Y1_NR   (4)
 @@ -199,7 +200,8 @@ enum exynos5_gpio_number {
   EXYNOS5_GPIO_C1_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C0),
   EXYNOS5_GPIO_C2_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C1),
   EXYNOS5_GPIO_C3_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C2),
 - EXYNOS5_GPIO_D0_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C3),
 + EXYNOS5_GPIO_C4_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C3),
 + EXYNOS5_GPIO_D0_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C4),
   EXYNOS5_GPIO_D1_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_D0),
   EXYNOS5_GPIO_Y0_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_D1),
   EXYNOS5_GPIO_Y1_START   = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_Y0),
 @@ -242,6 +244,7 @@ enum exynos5_gpio_number {
  #define EXYNOS5_GPC1(_nr)(EXYNOS5_GPIO_C1_START + (_nr))
  #define EXYNOS5_GPC2(_nr)(EXYNOS5_GPIO_C2_START + (_nr))
  #define EXYNOS5_GPC3(_nr)(EXYNOS5_GPIO_C3_START + (_nr))
 +#define EXYNOS5_GPC4(_nr)(EXYNOS5_GPIO_C4_START + (_nr))
  #define EXYNOS5_GPD0(_nr)(EXYNOS5_GPIO_D0_START + (_nr))
  #define EXYNOS5_GPD1(_nr)(EXYNOS5_GPIO_D1_START + (_nr))
  #define EXYNOS5_GPY0(_nr)(EXYNOS5_GPIO_Y0_START + (_nr))
 diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
 index 4627787..0153bb9 100644
 --- a/drivers/gpio/gpio-samsung.c
 +++ b/drivers/gpio/gpio-samsung.c
 @@ -2452,6 +2452,12 @@ static struct samsung_gpio_chip exynos5_gpios_1[] = {
   },
   }, {
   .chip   = {
 + .base   = EXYNOS5_GPC4(0),
 + .ngpio  = EXYNOS5_GPIO_C4_NR,
 + .label  = GPC4,
 + },
 + }, {
 + .chip   = {
   .base   = EXYNOS5_GPD0(0),
   .ngpio  = EXYNOS5_GPIO_D0_NR,
   .label  = GPD0,
 @@ -2880,6 +2886,8 @@ static __init int samsung_gpiolib_init(void)
   for (i = 0; i  4; i++, chip++, gpx_base += 0x20)
   chip-base = gpx_base;

 + exynos5_gpios_1[11].base = gpio_base1 + 0x2E0;
'11' seems dangerous. I think you add comments here and above to know
'11' meaning.
 +
   chip = exynos5_gpios_1;
   nr_chips = ARRAY_SIZE(exynos5_gpios_1);

 --
 1.6.6.rc2

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

--
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 06/12] rtc-s3c: Fix breakage introduced by S3C2443/S3C2416 support

2012-04-17 Thread Kyungmin Park
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 On 17 April 2012 12:00, Kyungmin Park kmp...@infradead.org wrote:
 Hi,

 It's already merged with different patch,

 This is a repost of the patch from Heiko Stuebner which would be
 required to fix compilation issue for rtc driver. I think you are
 referring to that patch but it is not merged yet. So I am reposting it
 with this series.

No it's 3.4.0-rc3. it's already included.

 Thanks,
 Thomas.


 #ifdef CONFIG_OF
 static const struct of_device_id s3c_rtc_dt_match[] = {
{
.compatible = samsung,s3c2410-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2410],
}, {
.compatible = samsung,s3c2416-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2416],
}, {
.compatible = samsung,s3c2443-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2443],
}, {
.compatible = samsung,s3c6410-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C64XX],
},
{},
 };
 MODULE_DEVICE_TABLE(of, s3c_rtc_dt_match);
 #else
 #define s3c_rtc_dt_match NULL
 #endif

 Thank you,
 Kyungmin Park

 On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 From: Heiko Stuebner he...@sntech.de

 Commits 7006ee4f (rtc-s3c: make room for more variants in devicetree
 block)
 and 6c0a2365 (rtc-s3c: add variants for S3C2443 and S3C2416)
 introduced build-failures with enabled CONFIG_USE_OF option.

 This patch fixes missing , in s3c_rtc_dt_match and wrong handling of
 the of_device_id.data property.

 Reported-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Heiko Stuebner he...@sntech.de
 ---
  drivers/rtc/rtc-s3c.c |   18 +-
  1 files changed, 9 insertions(+), 9 deletions(-)

 diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
 index 9ccea13..c792b6d 100644
 --- a/drivers/rtc/rtc-s3c.c
 +++ b/drivers/rtc/rtc-s3c.c
 @@ -449,7 +449,7 @@ static inline int s3c_rtc_get_driver_data(struct
 platform_device *pdev)
   if (pdev-dev.of_node) {
   const struct of_device_id *match;
   match = of_match_node(s3c_rtc_dt_match, pdev-dev.of_node);
 - return match-data;
 + return (int)match-data;
   }
  #endif
   return platform_get_device_id(pdev)-driver_data;
 @@ -667,17 +667,17 @@ static int s3c_rtc_resume(struct platform_device
 *pdev)
  #ifdef CONFIG_OF
  static const struct of_device_id s3c_rtc_dt_match[] = {
   {
 - .compatible = samsung,s3c2410-rtc
 - .data = TYPE_S3C2410,
 + .compatible = samsung,s3c2410-rtc,
 + .data = (void *)TYPE_S3C2410,
   }, {
 - .compatible = samsung,s3c2416-rtc
 - .data = TYPE_S3C2416,
 + .compatible = samsung,s3c2416-rtc,
 + .data = (void *)TYPE_S3C2416,
   }, {
 - .compatible = samsung,s3c2443-rtc
 - .data = TYPE_S3C2443,
 + .compatible = samsung,s3c2443-rtc,
 + .data = (void *)TYPE_S3C2443,
   }, {
 - .compatible = samsung,s3c6410-rtc
 - .data = TYPE_S3C64XX,
 + .compatible = samsung,s3c6410-rtc,
 + .data = (void *)TYPE_S3C64XX,
   },
   {},
  };
 --
 1.6.6.rc2

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

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

--
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] Exynos: fix SYSMMU driver to work with power domains

2012-04-16 Thread Kyungmin Park
On 4/16/12, KyongHo Cho pullip@samsung.com wrote:
 On Sun, Apr 15, 2012 at 12:51 AM, Kukjin Kim kgene@samsung.com wrote:
 On 04/12/12 01:19, KyongHo Cho wrote:

 On Wed, Apr 11, 2012 at 11:34 PM, Marek Szyprowski
 m.szyprow...@samsung.com  wrote:

 Hi!

 These two patches fixes operation of the SYSMMU driver (v12 version [1])
 with the new power domain driver based on generic power domains and
 runtime pw, which has been merged to Linux kernel v3.4-rc1.

 Thanks, Marek.

 Your way of power gating is right
 and I will look into the changed runtime PM scheme in Exynos tree.

 KyongHo,

 Do you want to upstream this series with your previous sysmmu (cleanup and
 moving) patches?


 Yes I hope so.
 Marek's patch corrects run-time power management in Exynos4 with System MMU.

Hi,

Next time, if you give Acked-By or Reviewed_by, then it's more helpful
to determine to merge or not.

Thank you,
Kyungmin Park

 Thank you.

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

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


Re: [PATCH] ARM: EXYNOS: autodetect enabled serial port in uncompress

2012-04-02 Thread Kyungmin Park
Hi,

On Tue, Apr 3, 2012 at 4:17 AM, Kukjin Kim kgene@samsung.com wrote:
 From: Colin Cross ccr...@android.com

 Check the ULCON register of each serial port to determine if
 it has been enabled by the bootloader.  If only one serial port
 is found enabled, use that one.  Otherwise, use the value from
 CONFIG_S3C_LOWLEVEL_UART_PORT.

 Signed-off-by: Colin Cross ccr...@android.com
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/include/mach/uncompress.h |   25 ++-
  1 files changed, 23 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/include/mach/uncompress.h 
 b/arch/arm/mach-exynos/include/mach/uncompress.h
 index 2979995..0d17a43 100644
 --- a/arch/arm/mach-exynos/include/mach/uncompress.h
 +++ b/arch/arm/mach-exynos/include/mach/uncompress.h
 @@ -25,6 +25,25 @@ static unsigned int __raw_readl(unsigned int ptr)
        return *((volatile unsigned int *)ptr);
  }

 +static volatile u8 *exynos_autodetect_uart(volatile u8 *base)
 +{
 +       int i;
 +       int found = 0;
 +       int port;
 +
 +       for (i = 0; i  CONFIG_SERIAL_SAMSUNG_UARTS; i++) {
 +               if (__raw_readl((unsigned int)base + S3C_UART_OFFSET * i)) {
1. Even though ULCON has offset 0, it's better to add ULCON_OFFSET.
2. In our case, we disable the unused UART at bootloader except the
debug uart, then does it possible to read this value at kernel?
I think it's hang at here. So read it correctly it should enable the
required uart clock before read it.
3. As similar tegra, how about to read specific value from RX
register. e.g., 'D'?
 +                       port = i;
 +                       found++;
To match the description, it should brake at here. if not it detects
the last uart at several detected uarts.

BR,
kmpark
 +               }
 +       }
 +
 +       if (found != 1)
 +               port = CONFIG_S3C_LOWLEVEL_UART_PORT;
 +
 +       return base + S3C_UART_OFFSET * port;
 +}
 +
  static void arch_detect_cpu(void)
  {
        u32 chip_id = __raw_readl(EXYNOS_PA_CHIPID);
 @@ -38,9 +57,11 @@ static void arch_detect_cpu(void)
        chip_id = 0xf;

        if (chip_id == 0x5)
 -               uart_base = (volatile u8 *)EXYNOS5_PA_UART + (S3C_UART_OFFSET 
 * CONFIG_S3C_LOWLEVEL_UART_PORT);
 +               uart_base = (volatile u8 *)EXYNOS5_PA_UART;
        else
 -               uart_base = (volatile u8 *)EXYNOS4_PA_UART + (S3C_UART_OFFSET 
 * CONFIG_S3C_LOWLEVEL_UART_PORT);
 +               uart_base = (volatile u8 *)EXYNOS4_PA_UART;
 +
 +       uart_base = exynos_autodetect_uart(uart_base);

        /*
         * For preventing FIFO overrun or infinite loop of UART console,
 --
 1.7.2.3

 --
 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
--
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/3 v2] Updates for exynos4210 and DT-based systems

2012-03-13 Thread Kyungmin Park
+CC another i2c subsystem maintainer, Wolfram Sang.

On 3/14/12, Karol Lewandowski k.lewando...@samsung.com wrote:
 Changes since v1:
  - Move unrelated code fragment to separate patch (of_match_ptr())
  - Move device-type handling to separate function and rework its
internals a bit

 This patchset reworks i2c-s3c2410 driver a bit to better handle
 device tree-enabled platforms and adds two quirks required by
 exynos4210-specific I2C controller used by s5p-hdmi driver.

 This patchset is based on i2c-bjdooks/for-34/i2c/i2c-samsung branch
 taken from:

   git://git.fluff.org/bjdooks/linux.git

 Karol Lewandowski (3):
   i2c-s3c2410: Drop unused define
   i2c-s3c2410: Rework device type handling
   i2c-s3c2410: Add HDMIPHY quirk for S3C2440

  .../devicetree/bindings/i2c/samsung-i2c.txt|   10 ++-
  drivers/i2c/busses/i2c-s3c2410.c   |   93
 +++-
  2 files changed, 77 insertions(+), 26 deletions(-)

 --
 1.7.9

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

--
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/3] ARM: Exynos: Add DRM core device support for Universal C210 board

2012-03-12 Thread Kyungmin Park
On 3/13/12, Sachin Kamat sachin.ka...@linaro.org wrote:
 Hi Marek,
 Thanks for the patch.

 On 09/03/2012, Marek Szyprowski m.szyprow...@samsung.com wrote:
 Add core DRM device and alternative platform device data for FIMD DRM
 subdriver. Based on the initial patch by Joonyoung Shim
 jy0922.s...@samsung.com

 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig   |1 +
  arch/arm/mach-exynos/mach-universal_c210.c |   31
 
  2 files changed, 32 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index 5a26944..c73eeba 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -257,6 +257,7 @@ config MACH_UNIVERSAL_C210
  select S5P_DEV_ONENAND
  select S5P_DEV_TV
  select EXYNOS4_DEV_DMA
 +select EXYNOS_DEV_DRM
  select EXYNOS4_SETUP_FIMD0
  select EXYNOS4_SETUP_I2C1
  select EXYNOS4_SETUP_I2C3
 diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
 b/arch/arm/mach-exynos/mach-universal_c210.c
 index 322b272..30a3ff3 100644
 --- a/arch/arm/mach-exynos/mach-universal_c210.c
 +++ b/arch/arm/mach-exynos/mach-universal_c210.c
 @@ -23,6 +23,7 @@
  #include linux/i2c-gpio.h
  #include linux/i2c/mcs.h
  #include linux/i2c/atmel_mxt_ts.h
 +#include drm/exynos_drm.h

  #include asm/mach/arch.h
  #include asm/hardware/gic.h
 @@ -811,6 +812,27 @@ static struct i2c_board_info i2c1_devs[] __initdata =
 {
  /* Gyro, To be updated */
  };

 +#ifdef CONFIG_DRM_EXYNOS
 +static struct exynos_drm_fimd_pdata drm_fimd_pdata = {
 +.timing = {
 +.left_margin= 16,
 +.right_margin   = 16,
 +.upper_margin   = 2,
 +.lower_margin   = 28,
 +.hsync_len  = 2,
 +.vsync_len  = 1,
 +.xres   = 480,
 +.yres   = 800,
 +.refresh= 55,
 +},

 Shouldn't this be:
Right, recently we added the panel information. It should be drm-next soon.

Thank you,
Kyungmin Park
.panel = {
   .timing = {
   .left_margin= 16,
   .right_margin   = 16,
 .upper_margin = 2,
   .lower_margin   = 28,
   .hsync_len  = 2,
   .vsync_len  = 1,
   .xres   = 480,
 .yres = 800,
   .refresh= 55,
  },
  },
   

 +.vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB |
 +  VIDCON0_CLKSEL_LCD,
 +.vidcon1= VIDCON1_INV_VCLK | VIDCON1_INV_VDEN
 +  | VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
 +.default_win= 3,
 +.bpp= 32,
 +};
 +#else
  /* Frame Buffer */
  static struct s3c_fb_pd_win universal_fb_win0 = {
  .win_mode = {
 @@ -838,6 +860,7 @@ static struct s3c_fb_platdata universal_lcd_pdata
 __initdata = {
| VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
  .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
  };
 +#endif

  static struct regulator_consumer_supply cam_vt_dio_supply =
  REGULATOR_SUPPLY(vdd_core, 0-003c);
 @@ -1046,6 +1069,9 @@ static struct platform_device *universal_devices[]
 __initdata = {
  universal_gpio_keys,
  s5p_device_onenand,
  s5p_device_fimd0,
 +#ifdef CONFIG_DRM_EXYNOS
 +exynos_device_drm,
 +#endif
  s5p_device_mfc,
  s5p_device_mfc_l,
  s5p_device_mfc_r,
 @@ -1091,7 +1117,12 @@ static void __init universal_machine_init(void)
  s5p_i2c_hdmiphy_set_platdata(NULL);
  i2c_register_board_info(5, i2c5_devs, ARRAY_SIZE(i2c5_devs));

 +#ifdef CONFIG_DRM_EXYNOS
 +s5p_device_fimd0.dev.platform_data = drm_fimd_pdata;
 +exynos4_fimd0_gpio_setup_24bpp();
 +#else
  s5p_fimd0_set_platdata(universal_lcd_pdata);
 +#endif

  universal_touchkey_init();
  i2c_register_board_info(I2C_GPIO_BUS_12, i2c_gpio12_devs,
 --
 1.7.1.569.g6f426

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



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

--
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 5/5] mmc: sdhci-s3c: setup pins using pinctrl interface

2012-03-11 Thread Kyungmin Park
On 3/11/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 The platform specific callback to setup the sdhci pin mux and pin config
 is removed and the pinctrl subsystem interface is used to setup the
 mux and config.

 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  drivers/mmc/host/sdhci-s3c.c |   15 +--
  1 files changed, 13 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
 index ea0767e..76c1c36 100644
 --- a/drivers/mmc/host/sdhci-s3c.c
 +++ b/drivers/mmc/host/sdhci-s3c.c
 @@ -22,6 +22,7 @@
  #include linux/module.h
  #include linux/of.h
  #include linux/of_gpio.h
 +#include linux/pinctrl/consumer.h

  #include linux/mmc/host.h

 @@ -50,6 +51,7 @@ struct sdhci_s3c {
   struct platform_device  *pdev;
   struct resource *ioarea;
   struct s3c_sdhci_platdata *pdata;
 + struct pinctrl  *pinctrl;
   unsigned intcur_clk;
   int ext_cd_irq;
   int ext_cd_gpio;
 @@ -529,6 +531,9 @@ static inline struct sdhci_s3c_drv_data
 *sdhci_s3c_get_driver_data(
   platform_get_device_id(pdev)-driver_data;
  }

 +#include plat/map-s5p.h
 +#include plat/map-base.h

Why this header files are required?
 +
  static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
  {
   struct s3c_sdhci_platdata *pdata;
 @@ -538,6 +543,7 @@ static int __devinit sdhci_s3c_probe(struct
 platform_device *pdev)
   struct sdhci_s3c *sc;
   struct resource *res;
   int ret, irq, ptr, clks;
 + char *pstate;

   if (!pdev-dev.platform_data  !pdev-dev.of_node) {
   dev_err(dev, no device data specified\n);
 @@ -643,8 +649,13 @@ static int __devinit sdhci_s3c_probe(struct
 platform_device *pdev)
   }

   /* Ensure we have minimal gpio selected CMD/CLK/Detect */
 - if (pdata-cfg_gpio)
 - pdata-cfg_gpio(pdev, pdata-max_width);
 + pstate = pdata-max_width ? sdhci-pcfg8 : sdhci-pcfg4;
You should check pdata-max_width == 8 instead of max_width itself.
BTW if platform set the amx_width as 1. How do you handle this?

Thank you,
Kyungmin Park
 + sc-pinctrl = pinctrl_get_select(pdev-dev, pstate);
 + if (IS_ERR(sc-pinctrl)) {
 + dev_err(dev, failed to setup pin configuration\n);
 + ret = -ENXIO;
 + goto err_req_regs;
 + }

   host-hw_name = samsung-hsmmc;
   host-ops = sdhci_s3c_ops;
 --
 1.6.6.rc2

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

--
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 04/11] ARM: EXYNOS: add interrupt definitions for EXYNOS5250

2012-03-07 Thread Kyungmin Park
On Wed, Mar 7, 2012 at 10:12 PM, Kukjin Kim kgene@samsung.com wrote:
 On 03/06/12 10:55, Olof Johansson wrote:

 Hi,

 On Tue, Feb 21, 2012 at 2:35 AM, Kukjin Kimkgene@samsung.com  wrote:

 Yes, as you said, it brakes single zImage for EXYNOS4 + EXYNOS5
 (mach-exynos). So I'm working on regarding resource for EXYNOS SoCs and I
 think, it can resolve the problem you said before v3.4 merge window.

 If any updates, let you know.


 Just a friendly reminder; the time is close to running out for staging
 new code for 3.4.

 Hi Olof,

 Thanks for your kindly reminder but I couldn't finish it yet because it is
 required to touch most of samsung stuff, and it's a big change. Frankly, I
 need more time...

 So how about sending current exynos5 stuff for now and then sorting out
 single kernel for exynos4 and exynos5 next time? Actually, this exynos5 arch
 part is _really_ needed for developing/contribution of drivers on exynos5.
No,

I heard too many times. we have plan to support ... but I didn't see
any progress.
it's general rules. you should fix it correctly and merged correctly
instead of not now

Thank you,
Kyungmin Park


 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v10 2/3] ARM: EXYNOS: Change System MMU platform device definitions

2012-03-06 Thread Kyungmin Park
Hi,

On 3/6/12, KyongHo Cho pullip@samsung.com wrote:
 Handling System MMUs with an identifier is not flexible to manage
 System MMU platform devices because of the following reasons:
 1. A device driver which needs to handle System MMU must know the ID.
 2. A System MMU may not present in some implementations of Exynos family.
 3. Handling System MMU with IOMMU API does not require an ID.

 This patch is the result of removing ID of System MMUs.
 Instead, a device driver that needs to handle its System MMU must
 use IOMMU API while its descriptor of platform device is given.

 This patch also includes the following enhanclements:
 - A System MMU device becomes a child if its power domain device.
 - clkdev

 Signed-off-by: KyongHo Cho pullip@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig|   11 +-
  arch/arm/mach-exynos/Makefile   |2 +-
  arch/arm/mach-exynos/clock-exynos4.c|   79 ++--
  arch/arm/mach-exynos/clock-exynos4.h|2 +
  arch/arm/mach-exynos/clock-exynos4210.c |   11 +
  arch/arm/mach-exynos/clock-exynos4212.c |   28 ++-
  arch/arm/mach-exynos/clock-exynos5.c|   90 +
  arch/arm/mach-exynos/dev-sysmmu.c   |  457
 --
  arch/arm/mach-exynos/include/mach/irqs.h|  179 +-
  arch/arm/mach-exynos/include/mach/map.h |   38 ++
  arch/arm/mach-exynos/include/mach/regs-clock.h  |5 +
  arch/arm/mach-exynos/include/mach/regs-sysmmu.h |   28 --
  arch/arm/mach-exynos/include/mach/sysmmu.h  |   84 +++--
  arch/arm/mach-exynos/mach-armlex4210.c  |1 -
  arch/arm/mach-exynos/mach-smdkv310.c|1 -
  15 files changed, 612 insertions(+), 404 deletions(-)
  delete mode 100644 arch/arm/mach-exynos/include/mach/regs-sysmmu.h

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index c49d450..d5a6a29 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -88,10 +88,10 @@ config EXYNOS4_SETUP_FIMD0
   help
 Common setup code for FIMD0.

 -config EXYNOS4_DEV_SYSMMU
 +config EXYNOS_DEV_SYSMMU
   bool
   help
 -   Common setup code for SYSTEM MMU in EXYNOS4
 +   Common setup code for SYSTEM MMU in EXYNOS platforms

  config EXYNOS4_DEV_DWMCI
   bool
 @@ -201,12 +201,12 @@ config MACH_SMDKV310
   select S3C_DEV_HSMMC2
   select S3C_DEV_HSMMC3
   select SAMSUNG_DEV_BACKLIGHT
 + select EXYNOS_DEV_SYSMMU
   select EXYNOS4_DEV_AHCI
   select SAMSUNG_DEV_KEYPAD
   select EXYNOS4_DEV_DMA
   select SAMSUNG_DEV_PWM
   select EXYNOS4_DEV_USB_OHCI
 - select EXYNOS4_DEV_SYSMMU
   select EXYNOS4_SETUP_FIMD0
   select EXYNOS4_SETUP_I2C1
   select EXYNOS4_SETUP_KEYPAD
 @@ -225,7 +225,6 @@ config MACH_ARMLEX4210
   select S3C_DEV_HSMMC3
   select EXYNOS4_DEV_AHCI
   select EXYNOS4_DEV_DMA
 - select EXYNOS4_DEV_SYSMMU
   select EXYNOS4_SETUP_SDHCI
   help
 Machine support for Samsung ARMLEX4210 based on EXYNOS4210
 @@ -251,6 +250,7 @@ config MACH_UNIVERSAL_C210
   select S5P_DEV_MFC
   select S5P_DEV_ONENAND
   select S5P_DEV_TV
 + select EXYNOS_DEV_SYSMMU
   select EXYNOS4_DEV_DMA
   select EXYNOS4_SETUP_FIMD0
   select EXYNOS4_SETUP_I2C1
 @@ -320,6 +320,7 @@ config MACH_ORIGEN
   select S5P_DEV_USB_EHCI
   select SAMSUNG_DEV_BACKLIGHT
   select SAMSUNG_DEV_PWM
 + select EXYNOS_DEV_SYSMMU
   select EXYNOS4_DEV_DMA
   select EXYNOS4_DEV_USB_OHCI
   select EXYNOS4_SETUP_FIMD0
 @@ -343,6 +344,7 @@ config MACH_SMDK4212
   select SAMSUNG_DEV_BACKLIGHT
   select SAMSUNG_DEV_KEYPAD
   select SAMSUNG_DEV_PWM
 + select EXYNOS_DEV_SYSMMU
   select EXYNOS4_SETUP_I2C1
   select EXYNOS4_SETUP_I2C3
   select EXYNOS4_SETUP_I2C7
 @@ -368,6 +370,7 @@ comment EXYNOS5250 Boards
  config MACH_SMDK5250
   bool SMDK5250
   select SOC_EXYNOS5250
 + select EXYNOS_DEV_SYSMMU
   help
 Machine support for Samsung SMDK5250
  endif
 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index 6fd8dd9..8b655e9 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -52,7 +52,7 @@ obj-$(CONFIG_MACH_SMDK5250) += mach-smdk5250.o
  obj-y+= dev-uart.o
  obj-$(CONFIG_ARCH_EXYNOS4)   += dev-audio.o
  obj-$(CONFIG_EXYNOS4_DEV_AHCI)   += dev-ahci.o
 -obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
 +obj-$(CONFIG_EXYNOS_DEV_SYSMMU)  += dev-sysmmu.o
  obj-$(CONFIG_EXYNOS4_DEV_DWMCI)  += dev-dwmci.o
  obj-$(CONFIG_EXYNOS4_DEV_DMA)+= dma.o
  obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI)   += dev-ohci.o
 diff --git a/arch/arm/mach-exynos/clock-exynos4.c
 b/arch/arm/mach-exynos/clock-exynos4.c
 index d72a1fe..18c48f0 100644
 --- a/arch/arm/mach-exynos/clock-exynos4.c
 +++ 

Re: [PATCH 2/3] ARM: Exynos: fix SDHCI device names in regulator definitions

2012-03-06 Thread Kyungmin Park
On 3/6/12, Kukjin Kim kgene@samsung.com wrote:
 On 03/01/12 00:40, Marek Szyprowski wrote:
 Patch 189eb7407 ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci
 controllers changed the names of the SDHCI devices, but the author forgot
 to update the definitions for the regulator subsystem. This patch fixes
 this issue.

 Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
 Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
 ---
   arch/arm/mach-exynos/mach-nuri.c   |4 ++--
   arch/arm/mach-exynos/mach-universal_c210.c |2 +-
   2 files changed, 3 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-nuri.c
 b/arch/arm/mach-exynos/mach-nuri.c
 index 8c0479f..dd26581 100644
 --- a/arch/arm/mach-exynos/mach-nuri.c
 +++ b/arch/arm/mach-exynos/mach-nuri.c
 @@ -117,7 +117,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
 __initdata = {
   };

   static struct regulator_consumer_supply emmc_supplies[] = {
 -REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
 +REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
  REGULATOR_SUPPLY(vmmc, dw_mmc),
   };

 @@ -417,7 +417,7 @@ static struct regulator_consumer_supply __initdata
 max8997_ldo12_[] = {
  REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
   };
   static struct regulator_consumer_supply __initdata max8997_ldo13_[] = {
 -REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
 +REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
   };
   static struct regulator_consumer_supply __initdata max8997_ldo14_[] = {
  REGULATOR_SUPPLY(inmotor, max8997-haptic),
 diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
 b/arch/arm/mach-exynos/mach-universal_c210.c
 index 908624c..7cd738c 100644
 --- a/arch/arm/mach-exynos/mach-universal_c210.c
 +++ b/arch/arm/mach-exynos/mach-universal_c210.c
 @@ -750,7 +750,7 @@ static struct s3c_sdhci_platdata universal_hsmmc0_data
 __initdata = {
   };

   static struct regulator_consumer_supply mmc0_supplies[] = {
 -REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
 +REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
   };

   static struct regulator_init_data mmc0_fixed_voltage_init_data = {

 (Cc'ed Jaehoon Chung)

 Oops, I looked at same patch from Jaehoon Chung just now and it could
 be. However, including same Signed-off-by from Kyungmin Park, it seems
 wrong. What's happened in your side?

As your delayed work, we did the same thing from both side.

Most of all, exynos4-sdhci patchset should contains these change also.
as wrong merge, it breaks all sdhci support at least exynos4 series.

Thank you,
Kyungmin 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


Re: [PATCH 2/3] ARM: Exynos: fix SDHCI device names in regulator definitions

2012-03-06 Thread Kyungmin Park
On 3/6/12, Kukjin Kim kgene@samsung.com wrote:
 On 03/06/12 02:13, Kyungmin Park wrote:
 On 3/6/12, Kukjin Kimkgene@samsung.com  wrote:
 On 03/01/12 00:40, Marek Szyprowski wrote:
 Patch 189eb7407 ARM: EXYNOS: use 'exynos4-sdhci' as device name for
 sdhci
 controllers changed the names of the SDHCI devices, but the author
 forgot
 to update the definitions for the regulator subsystem. This patch fixes
 this issue.

 Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
 Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
 ---
arch/arm/mach-exynos/mach-nuri.c   |4 ++--
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-nuri.c
 b/arch/arm/mach-exynos/mach-nuri.c
 index 8c0479f..dd26581 100644
 --- a/arch/arm/mach-exynos/mach-nuri.c
 +++ b/arch/arm/mach-exynos/mach-nuri.c
 @@ -117,7 +117,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
 __initdata = {
};

static struct regulator_consumer_supply emmc_supplies[] = {
 -  REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
 +  REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
REGULATOR_SUPPLY(vmmc, dw_mmc),
};

 @@ -417,7 +417,7 @@ static struct regulator_consumer_supply __initdata
 max8997_ldo12_[] = {
REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
};
static struct regulator_consumer_supply __initdata max8997_ldo13_[] =
 {
 -  REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
 +  REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
};
static struct regulator_consumer_supply __initdata max8997_ldo14_[] =
 {
REGULATOR_SUPPLY(inmotor, max8997-haptic),
 diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
 b/arch/arm/mach-exynos/mach-universal_c210.c
 index 908624c..7cd738c 100644
 --- a/arch/arm/mach-exynos/mach-universal_c210.c
 +++ b/arch/arm/mach-exynos/mach-universal_c210.c
 @@ -750,7 +750,7 @@ static struct s3c_sdhci_platdata
 universal_hsmmc0_data
 __initdata = {
};

static struct regulator_consumer_supply mmc0_supplies[] = {
 -  REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
 +  REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
};

static struct regulator_init_data mmc0_fixed_voltage_init_data = {

 (Cc'ed Jaehoon Chung)

 Oops, I looked at same patch from Jaehoon Chung just now and it could
 be. However, including same Signed-off-by from Kyungmin Park, it seems
 wrong. What's happened in your side?

 As your delayed work, we did the same thing from both side.

 NO! As I remember, there was same case from your side before. My concern
 is still how your sign can be added in duplication same patches but
 other author?

 Most of all, exynos4-sdhci patchset should contains these change also.
 as wrong merge, it breaks all sdhci support at least exynos4 series.

 Wrong merge? what's that?
That's problem. you don't know what you did. Did you test the
exynos4-sdhci patchset from Thomas?

and think why this patch is required.

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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 v10 3/3] iommu/exynos: Add iommu driver for Exynos Platforms

2012-03-06 Thread Kyungmin Park
Hi,

some not critical comments.

Thank you,
Kyungmin Park

On Tue, Mar 6, 2012 at 5:31 PM, KyongHo Cho pullip@samsung.com wrote:
 HAALgBjAGgAbwBAAHMAYQBtAHMAdQBuAGcALgBjAG8AbQA=;Tue,
  06 Mar 2012 08:31:29 
 GMT;WwBQAEEAVABDAEgAIAB2ADEAMAAgADMALwAzAF0AIABpAG8AbQBtAHUALwBlAHgAeQBuAG8AcwA6ACAAQQBkAGQAIABpAG8AbQBtAHUAIABkAHIAaQB2AGUAcgAgAGYAbwByACAARQB4AHkAbgBvAHMAIABQAGwAYQB0AGYAbwByAG0AcwA=
 x-cr-puzzleid: {CF0AAF04-8639-4D69-B4E1-BF71EA1B0A70}
What's this?

 This is the System MMU driver and IOMMU API implementation for
 Exynos SOC platforms. Exynos platforms has more than 10 System
 MMUs dedicated for each multimedia accellerators.

 The System MMU driver is already in arc/arm/plat-s5p but it is
 moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers
 there

 Any device driver in Exynos platforms that needs to control its
 System MMU must call platform_set_sysmmu() to inform System MMU
 driver who will control it.
 platform_set_sysmmu() is defined in mach/sysmmu.h
Does it really required? if we can remove it. it can be compiled
without arch dependency.

 Cc: Joerg Roedel joerg.roe...@amd.com
 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: KyongHo Cho pullip@samsung.com
 ---
  drivers/iommu/Kconfig        |   21 +
  drivers/iommu/Makefile       |    1 +
  drivers/iommu/exynos-iommu.c | 1088 
 ++
  3 files changed, 1110 insertions(+), 0 deletions(-)
  create mode 100644 drivers/iommu/exynos-iommu.c

 diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
 index 6bea696..25d3eed 100644
 --- a/drivers/iommu/Kconfig
 +++ b/drivers/iommu/Kconfig
 @@ -142,4 +142,25 @@ config OMAP_IOMMU_DEBUG

          Say N unless you know you need this.

 +config EXYNOS_IOMMU
 +       bool Exynos IOMMU Support
 +       depends on EXYNOS_DEV_SYSMMU
 +       select IOMMU_API
 +       help
 +         Support for the IOMMU(System MMU) of Samsung Exynos application
 +         processor family. This enables H/W multimedia accellerators to see
 +         non-linear physical memory chunks as a linear memory in their
 +         address spaces
 +
 +         If unsure, say N here.
 +
 +config EXYNOS_IOMMU_DEBUG
 +       bool Debugging log for Exynos IOMMU
 +       depends on EXYNOS_IOMMU
 +       help
 +         Select this to see the detailed log message that shows what
 +         happens in the IOMMU driver
 +
 +         Say N unless you need kernel log message for IOMMU debugging
 +
  endif # IOMMU_SUPPORT
 diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
 index 0e36b49..5a8fd97 100644
 --- a/drivers/iommu/Makefile
 +++ b/drivers/iommu/Makefile
 @@ -8,3 +8,4 @@ obj-$(CONFIG_IRQ_REMAP) += intr_remapping.o
  obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
  obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
  obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
 +obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
 diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
 new file mode 100644
 index 000..4c1c48a
 --- /dev/null
 +++ b/drivers/iommu/exynos-iommu.c
 @@ -0,0 +1,1088 @@
 +/* linux/drivers/iommu/exynos_iommu.c
 + *
 + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
 + *             http://www.samsung.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.
 + */
 +
 +#ifdef CONFIG_EXYNOS_IOMMU_DEBUG
 +#define DEBUG
 +#endif
If it's used only at here. you can add it at Makefile.

ifeq ($(CONFIG_EXYNOS_IOMMU_DEBUG),y)
 CFLAGS-exynos-iommu+= -DDEBUG
endif

Of course you can select as your preference.
 +
 +#include linux/io.h
 +#include linux/interrupt.h
 +#include linux/platform_device.h
 +#include linux/slab.h
 +#include linux/pm_runtime.h
 +#include linux/clk.h
 +#include linux/err.h
 +#include linux/mm.h
 +#include linux/iommu.h
 +#include linux/errno.h
 +#include linux/list.h
 +#include linux/memblock.h
 +#include linux/export.h
 +
 +#include asm/cacheflush.h
 +#include asm/pgtable.h
 +
 +#include mach/sysmmu.h
 +
 +#define S5P_MMU_CTRL                   0x000
 +#define S5P_MMU_CFG                    0x004
 +#define S5P_MMU_STATUS                 0x008
 +#define S5P_MMU_FLUSH                  0x00C
 +#define S5P_PT_BASE_ADDR               0x014
 +#define S5P_INT_STATUS                 0x018
 +#define S5P_INT_CLEAR                  0x01C
 +#define S5P_PAGE_FAULT_ADDR            0x024
 +#define S5P_AW_FAULT_ADDR              0x028
 +#define S5P_AR_FAULT_ADDR              0x02C
 +#define S5P_DEFAULT_SLAVE_ADDR         0x030
 +#define S5P_MMU_VERSION                        0x034
 +#define S5P_PB0_SADDR                  0x04C
 +#define S5P_PB0_EADDR                  0x050
 +#define S5P_PB1_SADDR                  0x054
 +#define S5P_PB1_EADDR                  0x058
 +
 +#define SECT_ORDER 20
 +#define LPAGE_ORDER 16
 +#define SPAGE_ORDER 12
 +
 +#define SECT_SIZE (1  SECT_ORDER)
 +#define

Re: [PATCH v9 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos

2012-02-27 Thread Kyungmin Park
Hi,

Some comments.
1. It's not same patch series. since it has additional feature,
exynos5 series support which don't covered at previous time.
2. It assumes that name conversion is based on exynos5 as default. now
you use gsc at exynos4 even though there's no gsc block. It should be
fimc.

So I suggest to send exynos4 series patch as before and send
additional exynos5 patch series next.

Thank you,
Kyungmin Park

On 2/28/12, KyongHo Cho pullip@samsung.com wrote:
 Changes since v8:
 - exynos_iommu_map/unmap() just works for the page sizes
that System MMU supports. (Joerg's comment)
 - 1 platform device for 1 H/W though a multimedia accelerator
with several System MMUs attached.
This make controlling System MMU simpler.
 - Information between System MMU and the accelerators:
Shifted to accelerator's device structure from System MMU's

 Changes since v7:
 - Rebased with the recent commits of the following git branches
   * git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/next
   * git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/for-next
 - Changed magic numbers into macros
 - Setting owner of a System MMU in 'iommu' field of dev_archdata
 - Verbose message in the default fault handler
 - Some bug fixes.

 Changes since v6:
 - Totally rewrite exynos_iommu_map() and exynos_iommu_unmap() according
   to the change in iommu_map() and iommu_unmap().
 - Change special slab for Lv2 page table to kmalloc().

 Changes since v5:
 - Relation between device and a domain become n:1 (Joerg's comment)
 - Implements iommu_commit(). -- Removed

 Changes since v4:
 - exynos_iommu_unmap()returns unmapped size in page order
   (Ohad Ben-Cohen's comment)
 - Fixed typo error of resource names
 - Fixed missing #includemach/sysmmu.h
   in arch/arm/mach-exynos4/mach-armlex4210.c

 Changes since v3:
 - Used DEFINE_RES_MEM and DEFINE_RES_IRQ macros
   to define resources of System MMU (Russell King's comment)
 - Fixed removal of CONFIG_S5P_SLEEP definition
  (Sylwester Nawrocki's comment)

 Changes since v2:
 - Add lock for System MMU private data.
   And fixes the following problems pointed by Joerg Rodel:
 - Fix wrong argument to kmalloc() and get_free_pages()
 - Merged patches into 2 due to bisectability

 Changes since v1:
 Fixes of the following problems pointed by Russell King.:
  - Missing unlocking a spinlock in exynos_iommu_attach_dev().
  - atomic_t - int in sysmmu_drvdata.activations
  - sysmmu_platdata - sysmmu_drvdata
  - Change in error messages in irq handler
  - Removed casting in format of error message
  - omap_iommu_ops - exynos_iommu_ops in the last patch

 Patch Summary:
 [PATCH v8 1/2] ARM: EXYNOS: Change System MMU platform device definitions
 [PATCH v8 2/2] iommu/exynos: Add iommu driver for Exynos Platforms

 The first patche enhances System MMU platform device definition:
  - Removed System MMU for MDMA0 in TOP block because it is not
used. Use MDMA2 in LCD block.
  - Removed System MMU ID. Instead, a System MMU is bound to a device
that the System MMU is dedicated during machin initialization.
If a device driver wants to handle System MMU, it must bind its
device with System MMU with sysmmu_set_owner().
  - clkdev

 The last patch implements IOMMU API:
  - System MMU device driver is removed from arch/arm/plat-s5p
 to move it to driver/iommu directory.
  - Implements IOMMU API and System MMU driver that is moved from
 arch/arm/plat-s5p.

 Diffstats:
 arch/arm/mach-exynos/Kconfig|   11 +-
  arch/arm/mach-exynos/Makefile   |2 +-
  arch/arm/mach-exynos/clock-exynos4.c|   74 +-
  arch/arm/mach-exynos/clock-exynos4.h|2 +
  arch/arm/mach-exynos/clock-exynos4210.c |   11 +
  arch/arm/mach-exynos/clock-exynos4212.c |   28 +-
  arch/arm/mach-exynos/clock-exynos5.c|   85 ++
  arch/arm/mach-exynos/dev-sysmmu.c   |  454 ++-
  arch/arm/mach-exynos/include/mach/irqs.h|  179 ++--
  arch/arm/mach-exynos/include/mach/map.h |   38 +
  arch/arm/mach-exynos/include/mach/memory.h  |1 +
  arch/arm/mach-exynos/include/mach/regs-clock.h  |5 +
  arch/arm/mach-exynos/include/mach/regs-sysmmu.h |   28 -
  arch/arm/mach-exynos/include/mach/sysmmu.h  |   83 +-
  arch/arm/mach-exynos/mach-armlex4210.c  |1 -
  arch/arm/mach-exynos/mach-smdkv310.c|1 -
  arch/arm/plat-s5p/Kconfig   |8 -
  arch/arm/plat-s5p/Makefile  |1 -
  arch/arm/plat-s5p/sysmmu.c  |  313 ---
  arch/arm/plat-samsung/include/plat/devs.h   |1 -
  arch/arm/plat-samsung/include/plat/sysmmu.h |   95 --
  drivers/iommu/Kconfig   |   22 +
  drivers/iommu/Makefile  |1 +
  drivers/iommu/exynos-iommu.c| 1076
 +++
  24 files changed, 1698 insertions(+), 822 deletions

Re: [PATCH v9 1/2] ARM: EXYNOS: Change System MMU platform device definitions

2012-02-27 Thread Kyungmin Park
Hi,

On 2/28/12, KyongHo Cho pullip@samsung.com wrote:
 Handling System MMUs with an identifier is not flexible to manage
 System MMU platform devices because of the following reasons:
 1. A device driver which needs to handle System MMU must know the ID.
 2. A System MMU may not present in some implementations of Exynos family.
 3. Handling System MMU with IOMMU API does not require an ID.

 This patch is the result of removing ID of System MMUs.
 Instead, a device driver that needs to handle its System MMU must
 use IOMMU API while its descriptor of platform device is given.

 This patch also includes the following enhancements:
 - A System MMU device becomes a child if its power domain device.
 - clkdev

 Signed-off-by: KyongHo Cho pullip@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig|   11 +-
  arch/arm/mach-exynos/Makefile   |2 +-
  arch/arm/mach-exynos/clock-exynos4.c|   79 ++--
  arch/arm/mach-exynos/clock-exynos4.h|2 +
  arch/arm/mach-exynos/clock-exynos4210.c |   11 +
  arch/arm/mach-exynos/clock-exynos4212.c |   28 ++-
  arch/arm/mach-exynos/clock-exynos5.c|   90 +
  arch/arm/mach-exynos/dev-sysmmu.c   |  451
 ---
  arch/arm/mach-exynos/include/mach/irqs.h|  179 +-
  arch/arm/mach-exynos/include/mach/map.h |   38 ++
  arch/arm/mach-exynos/include/mach/regs-clock.h  |5 +
  arch/arm/mach-exynos/include/mach/regs-sysmmu.h |   28 --
  arch/arm/mach-exynos/include/mach/sysmmu.h  |   84 +++--
  arch/arm/mach-exynos/mach-armlex4210.c  |1 -
  arch/arm/mach-exynos/mach-smdkv310.c|1 -
  arch/arm/plat-s5p/sysmmu.c  |   13 +-
  arch/arm/plat-samsung/include/plat/devs.h   |1 -
  17 files changed, 618 insertions(+), 406 deletions(-)
It's too big to cover these changes. Can you make it more small changes.
1. Remove existing ones since no user at this time.
2. Add new define and data structures.
3. Support new system mmu features based on generic iommu.

  delete mode 100644 arch/arm/mach-exynos/include/mach/regs-sysmmu.h

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index 40ad6b4..f7eabaf 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -95,10 +95,10 @@ config EXYNOS4_DEV_PD
   help
 Compile in platform device definitions for Power Domain

 -config EXYNOS4_DEV_SYSMMU
 +config EXYNOS_DEV_SYSMMU
It's simple example. The renaming is one candidate patch.
   bool
   help
 -   Common setup code for SYSTEM MMU in EXYNOS4
 +   Common setup code for SYSTEM MMU in EXYNOS platforms

  config EXYNOS4_DEV_DWMCI
   bool
 @@ -212,9 +212,9 @@ config MACH_SMDKV310
   select SAMSUNG_DEV_KEYPAD
   select SAMSUNG_DEV_PWM
   select EXYNOS_DEV_DMA
 + select EXYNOS_DEV_SYSMMU
   select EXYNOS4_DEV_PD
   select EXYNOS4_DEV_USB_OHCI
 - select EXYNOS4_DEV_SYSMMU
   select EXYNOS4_SETUP_FIMD0
   select EXYNOS4_SETUP_I2C1
   select EXYNOS4_SETUP_KEYPAD
 @@ -233,7 +233,6 @@ config MACH_ARMLEX4210
   select S3C_DEV_HSMMC3
   select EXYNOS_DEV_DMA
   select EXYNOS4_DEV_AHCI
 - select EXYNOS4_DEV_SYSMMU
   select EXYNOS4_SETUP_SDHCI
   help
 Machine support for Samsung ARMLEX4210 based on EXYNOS4210
 @@ -259,6 +258,7 @@ config MACH_UNIVERSAL_C210
   select S5P_DEV_ONENAND
   select S5P_DEV_TV
   select EXYNOS_DEV_DMA
 + select EXYNOS_DEV_SYSMMU
   select EXYNOS4_DEV_PD
   select EXYNOS4_SETUP_FIMD0
   select EXYNOS4_SETUP_I2C1
 @@ -326,6 +326,7 @@ config MACH_ORIGEN
   select SAMSUNG_DEV_BACKLIGHT
   select SAMSUNG_DEV_PWM
   select EXYNOS_DEV_DMA
 + select EXYNOS_DEV_SYSMMU
   select EXYNOS4_DEV_PD
   select EXYNOS4_DEV_USB_OHCI
   select EXYNOS4_SETUP_FIMD0
 @@ -350,6 +351,7 @@ config MACH_SMDK4212
   select SAMSUNG_DEV_KEYPAD
   select SAMSUNG_DEV_PWM
   select EXYNOS_DEV_DMA
 + select EXYNOS_DEV_SYSMMU
   select EXYNOS4_SETUP_I2C1
   select EXYNOS4_SETUP_I2C3
   select EXYNOS4_SETUP_I2C7
 @@ -376,6 +378,7 @@ config MACH_SMDK5250
   bool SMDK5250
   select SOC_EXYNOS5250
   select EXYNOS_DEV_DMA
 + select EXYNOS_DEV_SYSMMU
   help
 Machine support for Samsung SMDK5250
  endif
 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index 08b4eb1..aac02a8 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -52,7 +52,7 @@ obj-y   += dev-uart.o
  obj-$(CONFIG_ARCH_EXYNOS4)   += dev-audio.o
  obj-$(CONFIG_EXYNOS4_DEV_AHCI)   += dev-ahci.o
  obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
 -obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
 +obj-$(CONFIG_EXYNOS_DEV_SYSMMU)  += dev-sysmmu.o
  

Re: Subject: [PATCH] MAINTAINERS: add maintainer entry for SAMSUNG EXYNOS DeviceTree

2012-02-21 Thread Kyungmin Park
Hi,

I agree adding Thomas as DT maintainer. but I didn't see any activity
with Mr. Kim at least DT area.

Partially Ack.

On 2/22/12, Kukjin Kim kgene@samsung.com wrote:
 Add Samsung EXYNOS DT maintainer

 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Grant Likely grant.lik...@secretlab.ca
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  MAINTAINERS |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 9a648eb..5ac5aaf 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -1065,6 +1065,16 @@ S: Maintained
  F:   arch/arm/mach-s5p*/
  F:   arch/arm/mach-exynos*/

 +ARM/SAMSUNG EXYNOS DEVICE TREE
 +M:   Thomas Abraham thomas.abra...@linaro.org
 +M:   Kukjin Kim kgene@samsung.com
 +L:   devicetree-disc...@lists.ozlabs.org (moderated for non-subscribers)
 +L:   linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
 +S:   Maintained
 +F:   arch/arm/boot/dts/exynos*
 +F:   arch/arm/mach-exynos/*dt.c
 +F:   Documentation/devicetree/*/*/*samsung*
 +
  ARM/SAMSUNG MOBILE MACHINE SUPPORT
  M:   Kyungmin Park kyungmin.p...@samsung.com
  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 --
 1.7.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

--
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 08/11] ARM: EXYNOS: add support for ARCH_EXYNOS5 and EXYNOS5250

2012-02-15 Thread Kyungmin Park

  #define EXYNOS4_PA_COREPERI  0x1050
  #define EXYNOS4_PA_TWD   0x10500600
 @@ -91,7 +104,6 @@
  #define EXYNOS4_PA_SPI1  0x1393
  #define EXYNOS4_PA_SPI2  0x1394

 -
  #define EXYNOS4_PA_GPIO1 0x1140
  #define EXYNOS4_PA_GPIO2 0x1100
  #define EXYNOS4_PA_GPIO3 0x0386
 @@ -109,6 +121,7 @@
  #define EXYNOS4_PA_SATAPHY_CTRL  0x126B

  #define EXYNOS4_PA_SROMC 0x1257
 +#define EXYNOS5_PA_SROMC 0x1225

  #define EXYNOS4_PA_EHCI  0x1258
  #define EXYNOS4_PA_OHCI  0x1259
 @@ -116,6 +129,7 @@
  #define EXYNOS4_PA_MFC   0x1340

  #define EXYNOS4_PA_UART  0x1380
 +#define EXYNOS5_PA_UART  0x12C0

  #define EXYNOS4_PA_VP0x12C0
  #define EXYNOS4_PA_MIXER 0x12C1
 @@ -124,6 +138,7 @@
  #define EXYNOS4_PA_IIC_HDMIPHY   0x138E

  #define EXYNOS4_PA_IIC(x)(0x1386 + ((x) * 0x1))
 +#define EXYNOS5_PA_IIC(x)(0x12C6 + ((x) * 0x1))

  #define EXYNOS4_PA_ADC   0x1391
  #define EXYNOS4_PA_ADC1  0x13911000
 @@ -133,8 +148,10 @@
  #define EXYNOS4_PA_SPDIF 0x139B

  #define EXYNOS4_PA_TIMER 0x139D
 +#define EXYNOS5_PA_TIMER 0x12DD

  #define EXYNOS4_PA_SDRAM 0x4000
 +#define EXYNOS5_PA_SDRAM 0x4000

  /* Compatibiltiy Defines */

 diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h
 b/arch/arm/mach-exynos/include/mach/regs-pmu.h
 index 4fff8e9..4c53f38 100644
 --- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
 +++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
 @@ -31,6 +31,7 @@
  #define S5P_USE_STANDBYWFE_ISP_ARM   (1  26)

  #define S5P_SWRESET  S5P_PMUREG(0x0400)
 +#define EXYNOS_SWRESET   S5P_PMUREG(0x0400)
Please use just one.

Thank you,
Kyungmin Park

  #define S5P_WAKEUP_STAT  S5P_PMUREG(0x0600)
  #define S5P_EINT_WAKEUP_MASK S5P_PMUREG(0x0604)
 diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
 index 10e235cc7..88795ea 100644
 --- a/arch/arm/plat-s5p/Kconfig
 +++ b/arch/arm/plat-s5p/Kconfig
 @@ -9,8 +9,8 @@ config PLAT_S5P
   bool
   depends on (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
   default y
 - select ARM_VIC if !ARCH_EXYNOS4
 - select ARM_GIC if ARCH_EXYNOS4
 + select ARM_VIC if !ARCH_EXYNOS
 + select ARM_GIC if ARCH_EXYNOS
   select GIC_NON_BANKED if ARCH_EXYNOS4
   select NO_IOPORT
   select ARCH_REQUIRE_GPIOLIB
 diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
 b/arch/arm/plat-samsung/include/plat/cpu.h
 index 73cb3cf..787ceac 100644
 --- a/arch/arm/plat-samsung/include/plat/cpu.h
 +++ b/arch/arm/plat-samsung/include/plat/cpu.h
 @@ -42,6 +42,9 @@ extern unsigned long samsung_cpu_id;
  #define EXYNOS4412_CPU_ID0xE4412200
  #define EXYNOS4_CPU_MASK 0xFFFE

 +#define EXYNOS5250_SOC_ID0x4352
 +#define EXYNOS5_SOC_MASK 0xF000
 +
  #define IS_SAMSUNG_CPU(name, id, mask)   \
  static inline int is_samsung_##name(void)\
  {\
 @@ -58,6 +61,7 @@ IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_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)
 +IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)

  #if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2412) || \
  defined(CONFIG_CPU_S3C2416) || defined(CONFIG_CPU_S3C2440) || \
 @@ -120,6 +124,12 @@ IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID,
 EXYNOS4_CPU_MASK)
  #define EXYNOS4210_REV_1_0   (0x10)
  #define EXYNOS4210_REV_1_1   (0x11)

 +#if defined(CONFIG_SOC_EXYNOS5250)
 +# define soc_is_exynos5250() is_samsung_exynos5250()
 +#else
 +# define soc_is_exynos5250() 0
 +#endif
 +
  #define IODESC_ENT(x) { (unsigned long)S3C24XX_VA_##x,
 __phys_to_pfn(S3C24XX_PA_##x), S3C24XX_SZ_##x, MT_DEVICE }

  #ifndef MHZ
 --
 1.7.4.4

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

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


Re: [PATCH] ARM: EXYNOS: Adds Samsung TRATS board support

2012-02-10 Thread Kyungmin Park
+ Karol for DT support later

On Fri, Feb 10, 2012 at 3:58 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
 Dear Mr. HeungJun Kim,

 On 27 January 2012 00:21, HeungJun, Kim riverful@samsung.com wrote:
 This patch adds Samsung Mobile TRATS board support.

 Signed-off-by: HeungJun, Kim riverful@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig      |   11 ++
  arch/arm/mach-exynos/Makefile     |    1 +
  arch/arm/mach-exynos/mach-trats.c |  344 
 +
  3 files changed, 356 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-exynos/mach-trats.c

 The exynos4 dt-enabled board file can support most of the features
 added in this board file. The other option that could be considered
 here would be to add DT support for this board file, and use AUX_DATA
 to supply platform data for drivers that do not have dt support yet.
 It would be better to use dt support for new board support that we
 add.

 Thanks,
 Thomas.

 (snip)
 --
 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
--
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: SAMSUNG: Add support for EXYNOS SS USB 3.0 DRD controller

2012-02-06 Thread Kyungmin Park
On Mon, Feb 6, 2012 at 5:11 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
 Cc: Kukjin Kim kgene.kim at samsung.com
 Cc: Greg Kroah-Hartman gregkh at suse.de
 Cc: Felipe Balbi balbi at ti.com

 Adds DRD global register definitions and related platform data.

 Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com
Hi,

 ---
  .../include/plat/regs-usb3-exynos-drd.h            |  305 
 

If special reason, please move to the proper drivers/usb.

Thank you,
Kyungmin Park

  arch/arm/plat-samsung/include/plat/udc-ss.h        |   21 ++
  arch/arm/plat-samsung/include/plat/usb-phy.h       |    1 +
  3 files changed, 327 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h
  create mode 100644 arch/arm/plat-samsung/include/plat/udc-ss.h

 diff --git a/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h 
 b/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h
 new file mode 100644
 index 000..7006dc4
 --- /dev/null
 +++ b/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h
 @@ -0,0 +1,305 @@
 +/* arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h
 + *
 + * Copyright (c) 2011 Samsung Electronics Co. Ltd
 + * Author: Anton Tikhomirov av.tikhomi...@samsung.com
 + *
 + * Exynos SuperSpeed USB 3.0 DRD Controller Global registers
 + *
 + * 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.
 + */
 +
 +#ifndef __SAMSUNG_PLAT_REGS_USB3_EXYNOS_DRD_H
 +#define __SAMSUNG_PLAT_REGS_USB3_EXYNOS_DRD_H __FILE__
 +
 +#define EXYNOS_USB3_REG(x) (x)
 +
 +#define EXYNOS_USB3_GSBUSCFG0          EXYNOS_USB3_REG(0xC100)
 +#define EXYNOS_USB3_GSBUSCFG0_SBusStoreAndForward      (1  12)
 +#define EXYNOS_USB3_GSBUSCFG0_DatBigEnd                        (1  11)
 +#define EXYNOS_USB3_GSBUSCFG0_INCR256BrstEna           (1  7)
 +#define EXYNOS_USB3_GSBUSCFG0_INCR128BrstEna           (1  6)
 +#define EXYNOS_USB3_GSBUSCFG0_INCR64BrstEna            (1  5)
 +#define EXYNOS_USB3_GSBUSCFG0_INCR32BrstEna            (1  4)
 +#define EXYNOS_USB3_GSBUSCFG0_INCR16BrstEna            (1  3)
 +#define EXYNOS_USB3_GSBUSCFG0_INCR8BrstEna             (1  2)
 +#define EXYNOS_USB3_GSBUSCFG0_INCR4BrstEna             (1  1)
 +#define EXYNOS_USB3_GSBUSCFG0_INCRBrstEna              (1  0)
 +
 +#define EXYNOS_USB3_GSBUSCFG1          EXYNOS_USB3_REG(0xC104)
 +#define EXYNOS_USB3_GSBUSCFG1_EN1KPAGE                 (1  12)
 +#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT_MASK           (0xf  8)
 +#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT_SHIFT          8
 +#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT(_x)            ((_x)  8)
 +
 +
 +#define EXYNOS_USB3_GTXTHRCFG          EXYNOS_USB3_REG(0xC108)
 +#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCntSel           (1  29)
 +#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt_MASK         (0xf  24)
 +#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt_SHIFT                24
 +#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt(_x)          ((_x)  24)
 +#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize_MASK   (0xff  16)
 +#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize_SHIFT  16
 +#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize(_x)    ((_x)  16)
 +
 +
 +#define EXYNOS_USB3_GRXTHRCFG          EXYNOS_USB3_REG(0xC10C)
 +#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCntSel           (1  29)
 +#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt_MASK         (0xf  24)
 +#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt_SHIFT                24
 +#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt(_x)          ((_x)  24)
 +#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize_MASK   (0x1f  19)
 +#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize_SHIFT  19
 +#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize(_x)    ((_x)  19)
 +
 +
 +#define EXYNOS_USB3_GCTL               EXYNOS_USB3_REG(0xC110)
 +#define EXYNOS_USB3_GCTL_PwrDnScale_MASK               (0x1fff  19)
 +#define EXYNOS_USB3_GCTL_PwrDnScale_SHIFT              19
 +#define EXYNOS_USB3_GCTL_PwrDnScale(_x)                        ((_x)  19)
 +#define EXYNOS_USB3_GCTL_U2RSTECN                      (1  16)
 +#define EXYNOS_USB3_GCTL_FRMSCLDWN_MASK                        (0x3  14)
 +#define EXYNOS_USB3_GCTL_FRMSCLDWN_SHIFT               14
 +#define EXYNOS_USB3_GCTL_FRMSCLDWN(_x)                 ((_x)  14)
 +#define EXYNOS_USB3_GCTL_PrtCapDir_MASK                        (0x3  12)
 +#define EXYNOS_USB3_GCTL_PrtCapDir_SHIFT               12
 +#define EXYNOS_USB3_GCTL_PrtCapDir(_x)                 ((_x)  12)
 +#define EXYNOS_USB3_GCTL_CoreSoftReset                 (1  11)
 +#define EXYNOS_USB3_GCTL_LocalLpBkEn                   (1  10)
 +#define EXYNOS_USB3_GCTL_LpbkEn                                (1  9)
 +#define EXYNOS_USB3_GCTL_DebugAttach                   (1  8)
 +#define EXYNOS_USB3_GCTL_RAMClkSel_MASK                        (0x3  6)
 +#define EXYNOS_USB3_GCTL_RAMClkSel_SHIFT               6
 +#define EXYNOS_USB3_GCTL_RAMClkSel(_x

Re: [PATCH 1/2] ARM: EXYNOS: Add files about definition of C2C

2012-02-04 Thread Kyungmin Park
On Sat, Feb 4, 2012 at 5:13 PM, Kisang Lee kisang80@samsung.com wrote:
 Cc: Arnd Bergmann arnd at arndb.de
 Cc: Greg Kroah-Hartman greg at kroah.com

 Following files are added for C2C driver
 c2c.h : Definition of C2C platform data and mode
 regs-c2c.h : Definition of C2C registers

 Signed-off-by: Kisang Lee kisang80@samsung.com
 ---
Hi,
  arch/arm/mach-exynos/include/mach/c2c.h      |   65 +++
One nit. some parts are c2c common and gpio and platform setup codes
are exynos specific.
  arch/arm/mach-exynos/include/mach/regs-c2c.h |   71 
 ++
Are there any reason to put here? I think you can merge with 2/2
patch. I mean you can move it under drivers/misc/c2c.

Thank you,
Kyungmin Park
  2 files changed, 136 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-exynos/include/mach/c2c.h
  create mode 100644 arch/arm/mach-exynos/include/mach/regs-c2c.h

 diff --git a/arch/arm/mach-exynos/include/mach/c2c.h 
 b/arch/arm/mach-exynos/include/mach/c2c.h
 new file mode 100644
 index 000..c3d6131
 --- /dev/null
 +++ b/arch/arm/mach-exynos/include/mach/c2c.h
 @@ -0,0 +1,65 @@
 +/* linux/arch/arm/mach-exynos/include/mach/c2c.h
 + *
 + * Copyright 2011 Samsung Electronics Co., Ltd.
 + *             http://www.samsung.com/
 + *
 + * Platform header file for Samsung C2C Interface driver
 + *
 + * 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.
 +*/
 +#ifndef __ASM_PLAT_C2C_H
 +#define __ASM_PLAT_C2C_H __FILE__
 +
 +#define C2C_SHAREDMEM_BASE 0x6000
 +
 +enum c2c_opp_mode {
 +       C2C_OPP0 = 0,
 +       C2C_OPP25 = 1,
 +       C2C_OPP50 = 2,
 +       C2C_OPP100 = 3,
 +};
 +
 +enum c2c_buswidth {
 +       C2C_BUSWIDTH_8 = 0,
 +       C2C_BUSWIDTH_10 = 1,
 +       C2C_BUSWIDTH_16 = 2,
 +};
 +
 +enum c2c_shrdmem_size {
 +       C2C_MEMSIZE_4 = 0,
 +       C2C_MEMSIZE_8 = 1,
 +       C2C_MEMSIZE_16 = 2,
 +       C2C_MEMSIZE_32 = 3,
 +       C2C_MEMSIZE_64 = 4,
 +       C2C_MEMSIZE_128 = 5,
 +       C2C_MEMSIZE_256 = 6,
 +       C2C_MEMSIZE_512 = 7,
 +};
 +
 +struct exynos_c2c_platdata {
 +       void (*setup_gpio)(enum c2c_buswidth rx_width,
 +                       enum c2c_buswidth tx_width);
 +
 +       u32 shdmem_addr;
 +       enum c2c_shrdmem_size shdmem_size;
 +
 +       void __iomem *ap_sscm_addr;
 +       void __iomem *cp_sscm_addr;
 +
 +       enum c2c_buswidth rx_width;
 +       enum c2c_buswidth tx_width;
 +       u32 clk_opp100; /* clock of OPP100 mode */
 +       u32 clk_opp50;  /* clock of OPP50 mode */
 +       u32 clk_opp25;  /* clock of OPP25 */
 +       enum c2c_opp_mode default_opp_mode;
 +
 +       void __iomem *c2c_sysreg;       /* System Register address for C2C */
 +       char *c2c_clk;
 +};
 +
 +extern void exynos_c2c_set_platdata(struct exynos_c2c_platdata *pd);
 +extern void exynos_c2c_cfg_gpio(enum c2c_buswidth rx_width,
 +                               enum c2c_buswidth tx_width);
 +#endif /*__ASM_PLAT_C2C_H */
 diff --git a/arch/arm/mach-exynos/include/mach/regs-c2c.h 
 b/arch/arm/mach-exynos/include/mach/regs-c2c.h
 new file mode 100644
 index 000..0c3d005
 --- /dev/null
 +++ b/arch/arm/mach-exynos/include/mach/regs-c2c.h
 @@ -0,0 +1,71 @@
 +/* linux/arch/arm/mach-exynos/include/mach/regs-c2c.h
 + *
 + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
 + * http://www.samsung.com/
 + *
 + * Register definition file for Samsung C2C
 + *
 + * 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.
 +*/
 +
 +#ifndef __ASM_ARM_REGS_S5P_C2C_H
 +#define __ASM_ARM_REGS_S5P_C2C_H
 +
 +/***/
 +/* C2C Registers part                          */
 +/***/
 +#define EXYNOS_C2C_REVISION            0x0
 +#define EXYNOS_C2C_SYSCONFIG           0x4
 +#define EXYNOS_C2C_SYSSTATUS           0x8
 +#define EXYNOS_C2C_PORTCONFIG          0xc
 +#define EXYNOS_C2C_MIRRORMODE          0x10
 +#define EXYNOS_C2C_IRQ_RAW_STAT0       0x14
 +#define EXYNOS_C2C_IRQ_RAW_STAT1       0x18
 +#define EXYNOS_C2C_IRQ_EN_STAT0        0x1c
 +#define EXYNOS_C2C_IRQ_EN_STAT1        0x20
 +#define EXYNOS_C2C_IRQ_EN_SET0         0x24
 +#define EXYNOS_C2C_IRQ_EN_SET1         0x28
 +#define EXYNOS_C2C_IRQ_EN_CLEAR0       0x2c
 +#define EXYNOS_C2C_IRQ_EN_CLEAR1       0x30
 +#define EXYNOS_C2C_IRQ_EOI             0x34
 +
 +#define EXYNOS_C2C_FCLK_FREQ           0x40
 +#define EXYNOS_C2C_RX_MAX_FREQ         0x44
 +#define EXYNOS_C2C_TX_MAX_FREQ         0x48
 +#define EXYNOS_C2C_RX_MAX_FREQ_ACK     0x4c
 +#define EXYNOS_C2C_WAKE_REQ            0x50
 +#define EXYNOS_C2C_WAKE_ACK            0x54
 +#define EXYNOS_C2C_STANDBY             0x60
 +#define EXYNOS_C2C_STANDBY_IN

Re: [PATCH 2/2] ARM: Exynos4: Convert exynos4-dt to CONFIG_MULTI_IRQ_HANDLER

2012-01-31 Thread Kyungmin Park
restart is also required.

On 1/31/12, Karol Lewandowski k.lewando...@samsung.com wrote:
 Commit 4e44d2cb95bd (ARM: exynos4: convert to CONFIG_MULTI_IRQ_HANDLER)
 converted all exynos boards but exynos4-dt.c.

 This commit fixes that omission.

 Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Kukjin Kim kgene@samsung.com
 Cc: Marc Zyngier marc.zyng...@arm.com
 ---
  arch/arm/mach-exynos/mach-exynos4-dt.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
 b/arch/arm/mach-exynos/mach-exynos4-dt.c
 index 98e79c9..8aef6aa 100644
 --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
 +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
 @@ -15,6 +15,7 @@
  #include linux/serial_core.h

  #include asm/mach/arch.h
 +#include asm/hardware/gic.h
  #include mach/map.h

  #include plat/cpu.h
 @@ -83,4 +84,5 @@ DT_MACHINE_START(EXYNOS4210_DT, Samsung Exynos4
 (Flattened Device Tree))
   .init_machine   = exynos4210_dt_machine_init,
   .timer  = exynos4_timer,
   .dt_compat  = exynos4210_dt_compat,
 + .handle_irq = gic_handle_irq,
  MACHINE_END
 --
 1.7.8.3

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

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


Re: [PATCH 1/2] ARM: EXYNOS: add support GPIO for EXYNOS5250

2012-01-31 Thread Kyungmin Park
On 2/1/12, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
 On Wed, Feb 01, 2012 at 12:50:39AM +0900, Kukjin Kim wrote:
 From: Sangsu Park sangsu4u.p...@samsung.com

 This patch adds follwing.
 - IO-map for EXYNOS5250 GPIO support
 - EXYNOS5250 GPIO bank size/number definitions
 - memory map definition for S5P GPIO4

 Signed-off-by: Sangsu Park sangsu4u.p...@samsung.com
 Signed-off-by: Kukjin Kim kgene@samsung.com

 Do you actually need these static mapping definitions?  The samsung
 gpiolib initialization is called from a core_initcall(), and at this
 time ioremap() is fully capable of working.

If it assumes it has 8 gpios, you can make it simple calculate it like this.

enum exynos5_gpios {
 EXYNOS5_GPIO_A,
 ...
};

EXYNOS5_GPIO_A_START(n)  (EXYNOS5_GPIO_A * 8)

with this one, it can make a simple gpio driver when using irq domain for GPIO.

Thank you,
Kyungmin 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

--
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/9] ARM: EXYNOS: use exynos_init_uarts() instead of exynos4_init_uarts()

2012-01-31 Thread Kyungmin Park
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
 Since exynos4_init_uarts() can be used for EXYNOS5 SoCs,
 this patch changes the name of function to exynos_init_uarts().

 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/common.c |8 
  arch/arm/mach-exynos/common.h |8 
  2 files changed, 8 insertions(+), 8 deletions(-)

 diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
 index c59e188..a168533 100644
 --- a/arch/arm/mach-exynos/common.c
 +++ b/arch/arm/mach-exynos/common.c
 @@ -56,7 +56,7 @@ static struct cpu_table cpu_ids[] __initdata = {
   .idmask = EXYNOS4_CPU_MASK,
   .map_io = exynos4_map_io,
   .init_clocks= exynos4_init_clocks,
 - .init_uarts = exynos4_init_uarts,
 + .init_uarts = exynos_init_uarts,
   .init   = exynos_init,
   .name   = name_exynos4210,
   }, {
 @@ -64,7 +64,7 @@ static struct cpu_table cpu_ids[] __initdata = {
   .idmask = EXYNOS4_CPU_MASK,
   .map_io = exynos4_map_io,
   .init_clocks= exynos4_init_clocks,
 - .init_uarts = exynos4_init_uarts,
 + .init_uarts = exynos_init_uarts,
   .init   = exynos_init,
   .name   = name_exynos4212,
   }, {
 @@ -72,7 +72,7 @@ static struct cpu_table cpu_ids[] __initdata = {
   .idmask = EXYNOS4_CPU_MASK,
   .map_io = exynos4_map_io,
   .init_clocks= exynos4_init_clocks,
 - .init_uarts = exynos4_init_uarts,
 + .init_uarts = exynos_init_uarts,
   .init   = exynos_init,
   .name   = name_exynos4412,
   },
 @@ -476,7 +476,7 @@ int __init exynos_init(void)

  /* uart registration process */

 -void __init exynos4_init_uarts(struct s3c2410_uartcfg *cfg, int no)
 +void __init exynos_init_uarts(struct s3c2410_uartcfg *cfg, int no)
  {
   struct s3c2410_uartcfg *tcfg = cfg;
   u32 ucnt;
 diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
 index 8c1efe6..2d79aba 100644
 --- a/arch/arm/mach-exynos/common.h
 +++ b/arch/arm/mach-exynos/common.h
 @@ -36,15 +36,15 @@ extern struct sys_timer exynos4_timer;

  #ifdef CONFIG_ARCH_EXYNOS
  extern  int exynos_init(void);
 +extern void exynos_init_uarts(struct s3c2410_uartcfg *cfg, int no);
  extern void exynos4_map_io(void);
  extern void exynos4_init_clocks(int xtal);
 -extern void exynos4_init_uarts(struct s3c2410_uartcfg *cfg, int no);

Are there any cases build without CONFIG_ARCH_EXYNOS?
I think it's always defined CONFIG_ARCH_EXYNOS.

Thank you,
Kyungmin Park

  #else
 -#define exynos4_init_clocks NULL
 -#define exynos4_init_uarts NULL
 -#define exynos4_map_io NULL
  #define exynos_init NULL
 +#define exynos_init_uarts NULL
 +#define exynos4_map_io NULL
 +#define exynos4_init_clocks NULL
  #endif

  #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
 --
 1.7.4.4

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

--
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/9] ARM: EXYNOS: add clock part for EXYNOS5250 SoC

2012-01-31 Thread Kyungmin Park
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/clock-exynos5.c   | 1258
 
  arch/arm/mach-exynos/include/mach/regs-clock.h |   62 ++
Doesn't it better split the three header files?
regs-clock.h as wrapper. regs-clock-exynos4.h, regs-clock-exynos5.h
like clock C files.

  arch/arm/plat-s5p/clock.c  |   36 +
  arch/arm/plat-samsung/include/plat/s5p-clock.h |6 +
  4 files changed, 1362 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-exynos/clock-exynos5.c

 diff --git a/arch/arm/mach-exynos/clock-exynos5.c
 b/arch/arm/mach-exynos/clock-exynos5.c
 new file mode 100644
 index 000..b0c4478
 --- /dev/null
 +++ b/arch/arm/mach-exynos/clock-exynos5.c
 @@ -0,0 +1,1258 @@
 +/* linux/arch/arm/mach-exynos/clock-exynos5.c
 + *
 + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
 + *   http://www.samsung.com
 + *
 + * EXYNOS5 - Clock support
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 +*/
 +
 +#include linux/kernel.h
 +#include linux/err.h
 +#include linux/io.h
 +#include linux/syscore_ops.h
 +
 +#include plat/cpu-freq.h
 +#include plat/clock.h
 +#include plat/cpu.h
 +#include plat/pll.h
 +#include plat/s5p-clock.h
 +#include plat/clock-clksrc.h
 +#include plat/pm.h
 +
 +#include mach/map.h
 +#include mach/regs-clock.h
 +#include mach/sysmmu.h
 +
 +#include common.h
 +
 +#ifdef CONFIG_PM_SLEEP
 +static struct sleep_save exynos5_clock_save[] = {
 + /* will be implemented */
 +};
 +#endif
 +
 +static struct clk exynos5_clk_sclk_dptxphy = {
 + .name   = sclk_dptx,
 +};
 +
 +static struct clk exynos5_clk_sclk_hdmi24m = {
 + .name   = sclk_hdmi24m,
 + .rate   = 2400,
 +};
 +
 +static struct clk exynos5_clk_sclk_hdmi27m = {
 + .name   = sclk_hdmi27m,
 + .rate   = 2700,
 +};
 +
 +static struct clk exynos5_clk_sclk_hdmiphy = {
 + .name   = sclk_hdmiphy,
 +};
 +
 +static struct clk exynos5_clk_sclk_usbphy = {
 + .name   = sclk_usbphy,
 + .rate   = 4800,
 +};
 +
 +static int exynos5_clksrc_mask_top_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_TOP, clk, enable);
 +}
 +
 +static int exynos5_clksrc_mask_disp1_0_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_DISP1_0, clk, enable);
 +}
 +
 +static int exynos5_clksrc_mask_fsys_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_FSYS, clk, enable);
 +}
 +
 +static int exynos5_clksrc_mask_gscl_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_GSCL, clk, enable);
 +}
 +
 +static int exynos5_clksrc_mask_peric0_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_PERIC0, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_acp_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_ACP, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_core_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_CORE, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_disp1_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_DISP1, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_fsys_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_FSYS, clk, enable);
 +}
 +
 +static int exynos5_clk_gate_block(struct clk *clk, int enable)
exynos5_clk_block_ctrl?
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_BLOCK, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_gen_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_GEN, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_gps_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_GPS, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_mfc_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_MFC, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_peric_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_PERIC, clk, enable);
 +}
 +
 +static int exynos5_clk_ip_peris_ctrl(struct clk *clk, int enable)
 +{
 + return s5p_gatectrl(EXYNOS5_CLKGATE_IP_PERIS, clk, enable);
 +}
 +
 +/* Core list of CMU_CPU side */
 +
 +static struct clksrc_clk exynos5_clk_mout_apll = {
 + .clk= {
 + .name   = mout_apll,
 + },
 + .sources = clk_src_apll,
 + .reg_src = { .reg = EXYNOS5_CLKSRC_CPU, .shift = 0, .size = 1 },
 +};
 +
 +static struct clksrc_clk exynos5_clk_sclk_apll = {
 + .clk= {
 + .name   = sclk_apll,
 + .parent = exynos5_clk_mout_apll.clk,
 + },
 + .reg_div 

Re: [PATCH 3/9] ARM: EXYNOS: add initial setup-i2c0 for EXYNOS5

2012-01-31 Thread Kyungmin Park
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/Makefile |2 +-
  arch/arm/mach-exynos/setup-i2c0.c |   13 +
  2 files changed, 10 insertions(+), 5 deletions(-)

 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index 995e7cc..2117f02 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -52,7 +52,7 @@ obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
  obj-$(CONFIG_EXYNOS4_DEV_DMA)+= dma.o
  obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI)   += dev-ohci.o

 -obj-$(CONFIG_ARCH_EXYNOS4)   += setup-i2c0.o
 +obj-$(CONFIG_ARCH_EXYNOS)+= setup-i2c0.o
  obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
  obj-$(CONFIG_EXYNOS4_SETUP_FIMD0)+= setup-fimd0.o
  obj-$(CONFIG_EXYNOS4_SETUP_I2C1) += setup-i2c1.o
 diff --git a/arch/arm/mach-exynos/setup-i2c0.c
 b/arch/arm/mach-exynos/setup-i2c0.c
 index d395bd1..3244f3e 100644
 --- a/arch/arm/mach-exynos/setup-i2c0.c
 +++ b/arch/arm/mach-exynos/setup-i2c0.c
 @@ -1,7 +1,7 @@
  /*
 - * linux/arch/arm/mach-exynos4/setup-i2c0.c
 + * linux/arch/arm/mach-exynos/setup-i2c0.c
   *
 - * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
 + * Copyright (c) 2009-2012 Samsung Electronics Co., Ltd.
   *   http://www.samsung.com/
   *
   * I2C0 GPIO configuration.
 @@ -18,9 +18,14 @@ struct platform_device; /* don't need the contents */
  #include linux/gpio.h
  #include plat/iic.h
  #include plat/gpio-cfg.h
 +#include plat/cpu.h

  void s3c_i2c0_cfg_gpio(struct platform_device *dev)
  {
 - s3c_gpio_cfgall_range(EXYNOS4_GPD1(0), 2,
 -   S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
 + if (soc_is_exynos5250())
 + ;
 + /* will be implemented with gpio function */
Do you want to include both exynos4-gpio and exynos5-gpio?
 + else
 + s3c_gpio_cfgall_range(EXYNOS4_GPD1(0), 2,
 +   S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
  }
 --
 1.7.4.4

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

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


Re: [PATCH 4/9] ARM: EXYNOS: add support for ARCH_EXYNOS5 and EXYNOS5250

2012-01-31 Thread Kyungmin Park
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/Makefile|1 +
  arch/arm/mach-exynos/Kconfig |   13 ++
  arch/arm/mach-exynos/Makefile|1 +
  arch/arm/mach-exynos/common.c|  163
 --
  arch/arm/mach-exynos/common.h|   19 +++
  arch/arm/mach-exynos/include/mach/map.h  |   21 +++-
  arch/arm/mach-exynos/include/mach/regs-pmu.h |1 +
  arch/arm/plat-s5p/Kconfig|4 +-
  arch/arm/plat-samsung/include/plat/cpu.h |   10 ++
  9 files changed, 217 insertions(+), 16 deletions(-)

 diff --git a/arch/arm/Makefile b/arch/arm/Makefile
 index 40319d9..a0a5031 100644
 --- a/arch/arm/Makefile
 +++ b/arch/arm/Makefile
 @@ -181,6 +181,7 @@ machine-$(CONFIG_ARCH_S5P64X0):= s5p64x0
  machine-$(CONFIG_ARCH_S5PC100)   := s5pc100
  machine-$(CONFIG_ARCH_S5PV210)   := s5pv210
  machine-$(CONFIG_ARCH_EXYNOS4)   := exynos
 +machine-$(CONFIG_ARCH_EXYNOS5)   := exynos
It already has CONFIG_ARCH_EXYNOS so it's enough
machine-$(CONFIG_ARCH_EXYNOS) := exynos
  machine-$(CONFIG_ARCH_SA1100):= sa1100
  machine-$(CONFIG_ARCH_SHARK) := shark
  machine-$(CONFIG_ARCH_SHMOBILE)  := shmobile
 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index 5d602f6..60905d5 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -22,6 +22,12 @@ config ARCH_EXYNOS4
   help
 Samsung EXYNOS4 SoCs based systems

 +config ARCH_EXYNOS5
 + bool SAMSUNG EXYNOS5
 + select HAVE_SMP
 + help
 +   Samsung EXYNOS5 SoCs based systems
It's helpful to add which ARM core is used. in case of exynos4 has
CA9, exynos5 has CA15.
 +
  endchoice

  comment EXYNOS SoCs
 @@ -53,6 +59,13 @@ config SOC_EXYNOS4412
   help
 Enable EXYNOS4412 SoC support

 +config SOC_EXYNOS5250
 + bool SAMSUNG EXYNOS5250
 + default y
default y?
 + depends on ARCH_EXYNOS5
 + help
 +   Enable EXYNOS5250 SoC support
 +
  config EXYNOS4_MCT
   bool
   default y
 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index 2117f02..33d27d4 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -14,6 +14,7 @@ obj-:=

  obj-$(CONFIG_ARCH_EXYNOS)+= common.o
  obj-$(CONFIG_ARCH_EXYNOS4)   += clock-exynos4.o
 +obj-$(CONFIG_ARCH_EXYNOS5)   += clock-exynos5.o
  obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
  obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o

 diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
 index a168533..6ab3c5a 100644
 --- a/arch/arm/mach-exynos/common.c
 +++ b/arch/arm/mach-exynos/common.c
 @@ -49,6 +49,7 @@
  static const char name_exynos4210[] = EXYNOS4210;
  static const char name_exynos4212[] = EXYNOS4212;
  static const char name_exynos4412[] = EXYNOS4412;
 +static const char name_exynos5250[] = EXYNOS5250;

  static struct cpu_table cpu_ids[] __initdata = {
   {
 @@ -75,6 +76,14 @@ static struct cpu_table cpu_ids[] __initdata = {
   .init_uarts = exynos_init_uarts,
   .init   = exynos_init,
   .name   = name_exynos4412,
 + }, {
 + .idcode = EXYNOS5250_SOC_ID,
 + .idmask = EXYNOS5_SOC_MASK,
 + .map_io = exynos5_map_io,
 + .init_clocks= exynos5_init_clocks,
 + .init_uarts = exynos_init_uarts,
 + .init   = exynos_init,
 + .name   = name_exynos5250,
   },
  };

 @@ -83,10 +92,14 @@ static struct cpu_table cpu_ids[] __initdata = {
  static struct map_desc exynos_iodesc[] __initdata = {
   {
   .virtual= (unsigned long)S5P_VA_CHIPID,
 - .pfn= __phys_to_pfn(EXYNOS4_PA_CHIPID),
 + .pfn= __phys_to_pfn(EXYNOS_PA_CHIPID),
   .length = SZ_4K,
   .type   = MT_DEVICE,
 - }, {
 + },
 +};
 +
 +static struct map_desc exynos4_iodesc[] __initdata = {
 + {
   .virtual= (unsigned long)S3C_VA_SYS,
   .pfn= __phys_to_pfn(EXYNOS4_PA_SYSCON),
   .length = SZ_64K,
 @@ -136,11 +149,7 @@ static struct map_desc exynos_iodesc[] __initdata = {
   .pfn= __phys_to_pfn(EXYNOS4_PA_UART),
   .length = SZ_512K,
   .type   = MT_DEVICE,
 - },
 -};
 -
 -static struct map_desc exynos4_iodesc[] __initdata = {
 - {
 + }, {
   .virtual= (unsigned long)S5P_VA_CMU,
   .pfn= __phys_to_pfn(EXYNOS4_PA_CMU),
   .length = SZ_128K,
 @@ -201,6 +210,70 @@ static struct map_desc 

Re: [PATCH 5/9] ARM: EXYNOS: add board file for SMDK5250

2012-01-31 Thread Kyungmin Park
As I remember only DT based board file is acceptable for mainline?

On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig |   11 
  arch/arm/mach-exynos/Makefile|2 +
  arch/arm/mach-exynos/mach-smdk5250.c |   94
 ++
  3 files changed, 107 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-exynos/mach-smdk5250.c

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index 60905d5..89b8e17 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -364,6 +364,17 @@ config MACH_SMDK4412
 Machine support for Samsung SMDK4412
  endif

 +if ARCH_EXYNOS5
 +
 +comment EXYNOS5250 Boards
 +
 +config MACH_SMDK5250
 + bool SMDK5250
 + select SOC_EXYNOS5250
 + help
 +   Machine support for Samsung SMDK4412
 +endif
 +
  comment Flattened Device Tree based board for Exynos4 based SoC

  config MACH_EXYNOS4_DT
 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index 33d27d4..1b12345 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -43,6 +43,8 @@ obj-$(CONFIG_MACH_SMDK4412) += mach-smdk4x12.o

  obj-$(CONFIG_MACH_EXYNOS4_DT)+= mach-exynos4-dt.o

 +obj-$(CONFIG_MACH_SMDK5250)  += mach-smdk5250.o
 +
  # device support

  obj-$(CONFIG_ARCH_EXYNOS4)   += dev-audio.o
 diff --git a/arch/arm/mach-exynos/mach-smdk5250.c
 b/arch/arm/mach-exynos/mach-smdk5250.c
 new file mode 100644
 index 000..0fe4a0b
 --- /dev/null
 +++ b/arch/arm/mach-exynos/mach-smdk5250.c
 @@ -0,0 +1,94 @@
 +/*
 + * linux/arch/arm/mach-exynos/mach-smdk5250.c
 + *
 + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
 + *   http://www.samsung.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/platform_device.h
 +#include linux/serial_core.h
 +
 +#include asm/mach/arch.h
 +#include asm/hardware/gic.h
 +#include asm/mach-types.h
 +
 +#include plat/clock.h
 +#include plat/cpu.h
 +#include plat/regs-serial.h
 +
 +#include mach/map.h
 +
 +#include common.h
 +
 +/* Following are default values for UCON, ULCON and UFCON UART registers */
 +#define SMDK5250_UCON_DEFAULT(S3C2410_UCON_TXILEVEL |\
 +  S3C2410_UCON_RXILEVEL |\
 +  S3C2410_UCON_TXIRQMODE |   \
 +  S3C2410_UCON_RXIRQMODE |   \
 +  S3C2410_UCON_RXFIFO_TOI |  \
 +  S3C2443_UCON_RXERR_IRQEN)
 +
 +#define SMDK5250_ULCON_DEFAULT   S3C2410_LCON_CS8
 +
 +#define SMDK5250_UFCON_DEFAULT   (S3C2410_UFCON_FIFOMODE |   \
 +  S5PV210_UFCON_TXTRIG4 |\
 +  S5PV210_UFCON_RXTRIG4)
 +
 +static struct s3c2410_uartcfg smdk5250_uartcfgs[] __initdata = {
 + [0] = {
 + .hwport = 0,
 + .flags  = 0,
 + .ucon   = SMDK5250_UCON_DEFAULT,
 + .ulcon  = SMDK5250_ULCON_DEFAULT,
 + .ufcon  = SMDK5250_UFCON_DEFAULT,
 + },
 + [1] = {
 + .hwport = 1,
 + .flags  = 0,
 + .ucon   = SMDK5250_UCON_DEFAULT,
 + .ulcon  = SMDK5250_ULCON_DEFAULT,
 + .ufcon  = SMDK5250_UFCON_DEFAULT,
 + },
 + [2] = {
 + .hwport = 2,
 + .flags  = 0,
 + .ucon   = SMDK5250_UCON_DEFAULT,
 + .ulcon  = SMDK5250_ULCON_DEFAULT,
 + .ufcon  = SMDK5250_UFCON_DEFAULT,
 + },
 + [3] = {
 + .hwport = 3,
 + .flags  = 0,
 + .ucon   = SMDK5250_UCON_DEFAULT,
 + .ulcon  = SMDK5250_ULCON_DEFAULT,
 + .ufcon  = SMDK5250_UFCON_DEFAULT,
 + },
 +};
 +
 +static void __init smdk5250_map_io(void)
 +{
 + clk_xusbxti.rate = 2400;
 +
 + exynos_init_io(NULL, 0);
 + s3c24xx_init_clocks(clk_xusbxti.rate);
 + s3c24xx_init_uarts(smdk5250_uartcfgs, ARRAY_SIZE(smdk5250_uartcfgs));
 +}
 +
 +static void __init smdk5250_machine_init(void)
 +{
 + /* nothing here yet */
 +}
 +
 +MACHINE_START(SMDK5250, SMDK5250)
 + .atag_offset= 0x100,
 + .init_irq   = exynos5_init_irq,
 + .map_io = smdk5250_map_io,
 + .handle_irq = gic_handle_irq,
 + .init_machine   = smdk5250_machine_init,
 + .timer  = exynos4_timer,
 + .restart= exynos5_restart,
 +MACHINE_END
 --
 1.7.4.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
 in
 the body of 

Re: [PATCH 6/9] serial: samsung: Add support for EXYNOS5250

2012-01-31 Thread Kyungmin Park
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Greg Kroah-Hartman gre...@suse.de
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  drivers/tty/serial/samsung.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
 index 3b07fb9..c55e5fb 100644
 --- a/drivers/tty/serial/samsung.c
 +++ b/drivers/tty/serial/samsung.c
 @@ -1594,7 +1594,7 @@ static struct s3c24xx_serial_drv_data
 s5pv210_serial_drv_data = {
  #endif

  #if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212) || \
 - defined(CONFIG_SOC_EXYNOS4412)
 + defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
I think you can make it simple just use #ifdef CONFIG_ARCH_EXYNOS 
  static struct s3c24xx_serial_drv_data exynos4210_serial_drv_data = {
   .info = (struct s3c24xx_uart_info) {
   .name   = Samsung Exynos4 UART,
 --
 1.7.4.4

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

--
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 8/9] ARM: EXYNOS: temporary add map definitions for uart

2012-01-31 Thread Kyungmin Park
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/include/mach/map.h |   13 +++--
  1 files changed, 11 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/include/mach/map.h
 b/arch/arm/mach-exynos/include/mach/map.h
 index f88acaf..300ed7e 100644
 --- a/arch/arm/mach-exynos/include/mach/map.h
 +++ b/arch/arm/mach-exynos/include/mach/map.h
 @@ -167,9 +167,10 @@
  #define S3C_PA_IIC5  EXYNOS4_PA_IIC(5)
  #define S3C_PA_IIC6  EXYNOS4_PA_IIC(6)
  #define S3C_PA_IIC7  EXYNOS4_PA_IIC(7)
 +
  #define S3C_PA_RTC   EXYNOS4_PA_RTC
  #define S3C_PA_WDT   EXYNOS4_PA_WATCHDOG
 -#define S3C_PA_UART  EXYNOS4_PA_UART
 +
  #define S3C_PA_SPI0  EXYNOS4_PA_SPI0
  #define S3C_PA_SPI1  EXYNOS4_PA_SPI1
  #define S3C_PA_SPI2  EXYNOS4_PA_SPI2
 @@ -198,9 +199,17 @@

  /* Compatibility UART */

 +#ifdef CONFIG_ARCH_EXYNOS4
 +#define S3C_PA_UART  EXYNOS4_PA_UART
 +#endif
 +
 +#ifdef CONFIG_ARCH_EXYNOS5
 +#define S3C_PA_UART  EXYNOS5_PA_UART
 +#endif
If it selects the both ARCH_EXYNOS4 and ARCH_EXYNOS5, how to handle
this one? I think it's time to clean up these macro magic.
 +
  #define S3C_VA_UARTx(x)  (S3C_VA_UART + ((x) * 
 S3C_UART_OFFSET))

 -#define S5P_PA_UART(x)   (EXYNOS4_PA_UART + ((x) * 
 S3C_UART_OFFSET))
 +#define S5P_PA_UART(x)   (S3C_PA_UART + ((x) * 
 S3C_UART_OFFSET))
  #define S5P_PA_UART0 S5P_PA_UART(0)
  #define S5P_PA_UART1 S5P_PA_UART(1)
  #define S5P_PA_UART2 S5P_PA_UART(2)
 --
 1.7.4.4

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

--
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 9/9] ARM: EXYNOS: temporary fixup regarding get_core_count()

2012-01-31 Thread Kyungmin Park
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/platsmp.c |9 ++---
  1 files changed, 6 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
 index 683aec7..dfb4630 100644
 --- a/arch/arm/mach-exynos/platsmp.c
 +++ b/arch/arm/mach-exynos/platsmp.c
 @@ -165,7 +165,10 @@ void __init smp_init_cpus(void)
   void __iomem *scu_base = scu_base_addr();
   unsigned int i, ncores;

 - ncores = scu_base ? scu_get_core_count(scu_base) : 1;
 + if (soc_is_exynos5250())
 + ncores = 2;
I saw the related mail thread, I wonder then how to handle this at
other A15 board? Device Tree?
 + else
 + ncores = scu_base ? scu_get_core_count(scu_base) : 1;

   /* sanity check */
   if (ncores  nr_cpu_ids) {
 @@ -182,8 +185,8 @@ void __init smp_init_cpus(void)

  void __init platform_smp_prepare_cpus(unsigned int max_cpus)
  {
 -
 - scu_enable(scu_base_addr());
 + if (!soc_is_exynos5250())
 + scu_enable(scu_base_addr());

   /*
* Write the address of secondary startup into the
 --
 1.7.4.4

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

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


Re: [PATCH] ARM: EXYNOS: Add alias name of 'fimd' clock for 'lcd' clock

2012-01-19 Thread Kyungmin Park
On 1/19/12, Jingoo Han jg1@samsung.com wrote:
 This patch adds alias name of 'fimd' clock for 'lcd' clock. While 'lcd'
 clock is used for s3c-fb driver, 'fimd' clock is defined for Exynos fimd
 ip. Therefore, 'fimd' clock can be called by using clk_add_alias().
Hi,

Doesn't it better to add common.c?
Are there any reason to add each board files?

Thank you,
Kyungmin Park

 Cc: Jonghwan Choi jhbird.c...@samsung.com
 Signed-off-by: Jingoo Han jg1@samsung.com
 ---
  arch/arm/mach-exynos/mach-nuri.c   |2 ++
  arch/arm/mach-exynos/mach-origen.c |2 ++
  arch/arm/mach-exynos/mach-smdkv310.c   |2 ++
  arch/arm/mach-exynos/mach-universal_c210.c |3 +++
  4 files changed, 9 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-nuri.c
 b/arch/arm/mach-exynos/mach-nuri.c
 index 3df8bf4..06c22e0 100644
 --- a/arch/arm/mach-exynos/mach-nuri.c
 +++ b/arch/arm/mach-exynos/mach-nuri.c
 @@ -1310,6 +1310,8 @@ static void __init nuri_machine_init(void)
   i2c9_devs[I2C9_MAX17042].irq = gpio_to_irq(EXYNOS4_GPX2(3));
   i2c_register_board_info(9, i2c9_devs, ARRAY_SIZE(i2c9_devs));

 + dev_set_name(s5p_device_fimd0.dev, exynos4-fb.0);
 + clk_add_alias(lcd, exynos4-fb.0, fimd, s5p_device_fimd0.dev);
   s5p_fimd0_set_platdata(nuri_fb_pdata);

   nuri_camera_init();
 diff --git a/arch/arm/mach-exynos/mach-origen.c
 b/arch/arm/mach-exynos/mach-origen.c
 index b453464..7cea0be 100644
 --- a/arch/arm/mach-exynos/mach-origen.c
 +++ b/arch/arm/mach-exynos/mach-origen.c
 @@ -722,6 +722,8 @@ static void __init origen_machine_init(void)
   s5p_tv_setup();
   s5p_i2c_hdmiphy_set_platdata(NULL);

 + dev_set_name(s5p_device_fimd0.dev, exynos4-fb.0);
 + clk_add_alias(lcd, exynos4-fb.0, fimd, s5p_device_fimd0.dev);
   s5p_fimd0_set_platdata(origen_lcd_pdata);

   platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
 diff --git a/arch/arm/mach-exynos/mach-smdkv310.c
 b/arch/arm/mach-exynos/mach-smdkv310.c
 index bf2094e..eccd96d 100644
 --- a/arch/arm/mach-exynos/mach-smdkv310.c
 +++ b/arch/arm/mach-exynos/mach-smdkv310.c
 @@ -370,6 +370,8 @@ static void __init smdkv310_machine_init(void)
   samsung_keypad_set_platdata(smdkv310_keypad_data);

   samsung_bl_set(smdkv310_bl_gpio_info, smdkv310_bl_data);
 + dev_set_name(s5p_device_fimd0.dev, exynos4-fb.0);
 + clk_add_alias(lcd, exynos4-fb.0, fimd, s5p_device_fimd0.dev);
   s5p_fimd0_set_platdata(smdkv310_lcd0_pdata);

   smdkv310_ehci_init();
 diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
 b/arch/arm/mach-exynos/mach-universal_c210.c
 index c38e18d..fe554f1 100644
 --- a/arch/arm/mach-exynos/mach-universal_c210.c
 +++ b/arch/arm/mach-exynos/mach-universal_c210.c
 @@ -31,6 +31,7 @@
  #include plat/cpu.h
  #include plat/devs.h
  #include plat/iic.h
 +#include plat/clock.h
  #include plat/gpio-cfg.h
  #include plat/fb.h
  #include plat/mfc.h
 @@ -1029,6 +1030,8 @@ static void __init universal_machine_init(void)
   s5p_i2c_hdmiphy_set_platdata(NULL);
   i2c_register_board_info(5, i2c5_devs, ARRAY_SIZE(i2c5_devs));

 + dev_set_name(s5p_device_fimd0.dev, exynos4-fb.0);
 + clk_add_alias(lcd, exynos4-fb.0, fimd, s5p_device_fimd0.dev);
   s5p_fimd0_set_platdata(universal_lcd_pdata);

   universal_touchkey_init();
 --
 1.7.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

--
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/2] ARM: Exynos: Hook up power domains to generic power domain infrastructure

2012-01-08 Thread Kyungmin Park
On 1/7/12, Thomas Abraham thomas.abra...@linaro.org wrote:
 Add support for generic power domain for Exynos4 platforms and remove the
 Samsung specific power domain control for Exynos4.

 The generic power domain infrastructure is used to control the power domains
 available on Exynos4. For non-dt platforms, the power domains are statically
 instantiated. For dt platforms, the power domain nodes found in the device
 tree are instantiated.

 Cc: Rafael J. Wysocki r...@sisk.pl
 Cc: Kukjin Kim kgene@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Rob Herring rob.herr...@calxeda.com
 Cc: Grant Likely grant.lik...@secretlab.ca
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
 This patch is mainly derived from Mark Brown's work on generic power domain
 support for s3c64xx platforms.

  arch/arm/mach-exynos/Kconfig   |   10 +--
  arch/arm/mach-exynos/Makefile  |2 +-
  arch/arm/mach-exynos/dev-pd.c  |  139 -
  arch/arm/mach-exynos/mach-nuri.c   |   11 --
  arch/arm/mach-exynos/mach-origen.c |   14 --
  arch/arm/mach-exynos/mach-smdkv310.c   |   12 --
  arch/arm/mach-exynos/mach-universal_c210.c |   17 ---
  arch/arm/mach-exynos/pm_domains.c  |  183
 
  8 files changed, 185 insertions(+), 203 deletions(-)
  delete mode 100644 arch/arm/mach-exynos/dev-pd.c
  create mode 100644 arch/arm/mach-exynos/pm_domains.c

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index e931924..5dec134 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -32,6 +32,7 @@ config CPU_EXYNOS4210
   select ARM_CPU_SUSPEND if PM
   select S5P_PM if PM
   select S5P_SLEEP if PM
 + select PM_GENERIC_DOMAINS
   help
 Enable EXYNOS4210 CPU support

 @@ -72,11 +73,6 @@ config EXYNOS4_SETUP_FIMD0
   help
 Common setup code for FIMD0.

 -config EXYNOS4_DEV_PD
 - bool
 - help
 -   Compile in platform device definitions for Power Domain
 -
  config EXYNOS4_DEV_SYSMMU
   bool
   help
 @@ -194,7 +190,6 @@ config MACH_SMDKV310
   select EXYNOS4_DEV_AHCI
   select SAMSUNG_DEV_KEYPAD
   select EXYNOS4_DEV_DMA
 - select EXYNOS4_DEV_PD
   select SAMSUNG_DEV_PWM
   select EXYNOS4_DEV_USB_OHCI
   select EXYNOS4_DEV_SYSMMU
 @@ -243,7 +238,6 @@ config MACH_UNIVERSAL_C210
   select S5P_DEV_ONENAND
   select S5P_DEV_TV
   select EXYNOS4_DEV_DMA
 - select EXYNOS4_DEV_PD
   select EXYNOS4_SETUP_FIMD0
   select EXYNOS4_SETUP_I2C1
   select EXYNOS4_SETUP_I2C3
 @@ -277,7 +271,6 @@ config MACH_NURI
   select S5P_DEV_USB_EHCI
   select S5P_SETUP_MIPIPHY
   select EXYNOS4_DEV_DMA
 - select EXYNOS4_DEV_PD
   select EXYNOS4_SETUP_FIMC
   select EXYNOS4_SETUP_FIMD0
   select EXYNOS4_SETUP_I2C1
 @@ -310,7 +303,6 @@ config MACH_ORIGEN
   select SAMSUNG_DEV_BACKLIGHT
   select SAMSUNG_DEV_PWM
   select EXYNOS4_DEV_DMA
 - select EXYNOS4_DEV_PD
   select EXYNOS4_DEV_USB_OHCI
   select EXYNOS4_SETUP_FIMD0
   select EXYNOS4_SETUP_SDHCI
 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index db527ab..b7e4eca 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_EXYNOS4)  += irq-eint.o pmu.o
  obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
  obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
  obj-$(CONFIG_PM) += pm.o
 +obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
  obj-$(CONFIG_CPU_IDLE)   += cpuidle.o

  obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
 @@ -43,7 +44,6 @@ obj-$(CONFIG_MACH_EXYNOS4_DT)   += 
 mach-exynos4-dt.o

  obj-$(CONFIG_ARCH_EXYNOS4)   += dev-audio.o
  obj-$(CONFIG_EXYNOS4_DEV_AHCI)   += dev-ahci.o
 -obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
  obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
  obj-$(CONFIG_EXYNOS4_DEV_DWMCI)  += dev-dwmci.o
  obj-$(CONFIG_EXYNOS4_DEV_DMA)+= dma.o
 diff --git a/arch/arm/mach-exynos/dev-pd.c b/arch/arm/mach-exynos/dev-pd.c
 deleted file mode 100644
 index 3273f25..000
 --- a/arch/arm/mach-exynos/dev-pd.c
 +++ /dev/null
 @@ -1,139 +0,0 @@
 -/* linux/arch/arm/mach-exynos4/dev-pd.c
 - *
 - * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
 - *   http://www.samsung.com
 - *
 - * EXYNOS4 - Power Domain support
 - *
 - * This program is free software; you can redistribute it and/or modify
 - * it under the terms of the GNU General Public License version 2 as
 - * published by the Free Software Foundation.
 -*/
 -
 -#include linux/io.h
 -#include linux/kernel.h
 -#include linux/platform_device.h
 -#include linux/delay.h
 -
 -#include mach/regs-pmu.h
 -
 -#include plat/pd.h
 -
 -static int exynos4_pd_enable(struct device *dev)
 -{
 - struct

Re: [PATCH] ARM: EXYNOS: Fix build error which was from common.c and old cpu.c

2012-01-08 Thread Kyungmin Park
On 1/9/12, Kukjin Kim kgene@samsung.com wrote:
 This fixes build error and wrong merge conflicts.
 arch/arm/mach-exynos/common.c: In function 'exynos4_gic_irq_fix_base':
 arch/arm/mach-exynos/common.c:393: error: dereferencing pointer to
 incomplete type
 arch/arm/mach-exynos/common.c:396: error: dereferencing pointer to
 incomplete type

 Following A and B have been created from different base and the build
 error was casued in the process of merging and should be fixed in this
 merge window.

Acked-by: Kyungmin Park kyungmin.p...@samsung.com

Do the same job. boot tested.

 A. commit db0d4db (ARM: gic: allow GIC to support non-banked setups),
   commit 4e44d2c (ARM: exynos4: convert to CONFIG_MULTI_IRQ_HANDLER)
   and commit 69676c3 (ARM: exynos4: Fix build error due to
   'gic_bank_offset' undeclared)

 B. commit cc511b8 (ARM: 7257/1: EXYNOS: introduce arch/arm/mach-exynos/
   common.[ch]) introduced common.[ch])

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Axel Lin axel@gmail.com
 Cc: Russell King rmk+ker...@arm.linux.org.uk
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
 Hi Russell,

 This should be fixed, I'm sending this to patch system.
 If you're ok with this, please pick it up for this merge window.

 Thanks.

  arch/arm/mach-exynos/common.c |   20 +++-
  1 files changed, 3 insertions(+), 17 deletions(-)

 diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
 index b6ac6ee..647c843 100644
 --- a/arch/arm/mach-exynos/common.c
 +++ b/arch/arm/mach-exynos/common.c
 @@ -19,6 +19,7 @@
  #include linux/serial_core.h

  #include asm/proc-fns.h
 +#include asm/exception.h
Not needed.
  #include asm/hardware/cache-l2x0.h
  #include asm/hardware/gic.h
  #include asm/mach/map.h
 @@ -43,8 +44,6 @@

  #include common.h

 -unsigned int gic_bank_offset __read_mostly;
 -
  static const char name_exynos4210[] = EXYNOS4210;
  static const char name_exynos4212[] = EXYNOS4212;
  static const char name_exynos4412[] = EXYNOS4412;
 @@ -386,27 +385,14 @@ static void __init combiner_init(unsigned int
 combiner_nr, void __iomem *base,
   }
  }

 -static void exynos4_gic_irq_fix_base(struct irq_data *d)
 -{
 - struct gic_chip_data *gic_data = irq_data_get_irq_chip_data(d);
 -
 - gic_data-cpu_base = S5P_VA_GIC_CPU +
 - (gic_bank_offset * smp_processor_id());
 -
 - gic_data-dist_base = S5P_VA_GIC_DIST +
 - (gic_bank_offset * smp_processor_id());
 -}
 -
  void __init exynos4_init_irq(void)
  {
   int irq;
 + unsigned int gic_bank_offset;

   gic_bank_offset = soc_is_exynos4412() ? 0x4000 : 0x8000;

 - gic_init(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU);
 - gic_arch_extn.irq_eoi = exynos4_gic_irq_fix_base;
 - gic_arch_extn.irq_unmask = exynos4_gic_irq_fix_base;
 - gic_arch_extn.irq_mask = exynos4_gic_irq_fix_base;
 + gic_init_bases(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU,
 gic_bank_offset);

   for (irq = 0; irq  MAX_COMBINER_NR; irq++) {

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

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


Re: [PATCH] ARM: EXYNOS: Adds Samsung TRATS board support

2011-12-26 Thread Kyungmin Park
On 12/27/11, Kukjin Kim kgene@samsung.com wrote:
 Kyungmin Park wrote:

 On 12/24/11, Kukjin Kim kgene@samsung.com wrote:
  HeungJun, Kim wrote:
 
  This patch adds Samsung Mobile TRATS board support.
 
  Signed-off-by: HeungJun, Kim riverful@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   arch/arm/mach-exynos/Kconfig   |   11 ++
   arch/arm/mach-exynos/Makefile  |1 +
   arch/arm/mach-exynos/board-trats.c |  340
  
   3 files changed, 352 insertions(+), 0 deletions(-)
   create mode 100644 arch/arm/mach-exynos/board-trats.c
 
 
  If this is for v3.3, unfortunately, it's a little late to add board file
 and
  since many things have changed I don't want to cause the conflicts with
  others now.
 
  BTW, why is the name board-xxx not mach-xxx like others?

 It's mentioned several times,
 How do you talk with other when talk about the smdk?
 I'm using the smdk machine and it's based on smdk machine?
 As board is more proper word and it's easy to know when find the board
 at source code.
 So hope to use the board if it's not big deal.

 Yes, we say 'SMDK board blah blah' so it can be no big deal, but I don't
 want to make a confusion between CONFIG_MACH_XXX and mach-xxx.c yet even
 though there is a similar situation of arch/arm/mach-xxx/ directory and
 CONFIG_ARCH_XXX. In addition, the machine_is_xxx() is used to distinguish
 board in the kernel.

 Anyway, I think, if to use board-xxx.c is required, we can change it all at
 once and let me think again.

Don't think, use the current way.

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.

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

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


Re: [PATCH] ARM: EXYNOS: Adds Samsung TRATS board support

2011-12-26 Thread Kyungmin Park
On 12/27/11, Kukjin Kim kgene@samsung.com wrote:
 Kyungmin Park wrote:

 On 12/27/11, Kukjin Kim kgene@samsung.com wrote:
  Kyungmin Park wrote:
 
  On 12/24/11, Kukjin Kim kgene@samsung.com wrote:
   HeungJun, Kim wrote:
  
   This patch adds Samsung Mobile TRATS board support.
  
   Signed-off-by: HeungJun, Kim riverful@samsung.com
   Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
   ---
arch/arm/mach-exynos/Kconfig   |   11 ++
arch/arm/mach-exynos/Makefile  |1 +
arch/arm/mach-exynos/board-trats.c |  340
   
3 files changed, 352 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos/board-trats.c
  
  
   If this is for v3.3, unfortunately, it's a little late to add board
 file
  and
   since many things have changed I don't want to cause the conflicts
 with
   others now.
  
   BTW, why is the name board-xxx not mach-xxx like others?
 
  It's mentioned several times,
  How do you talk with other when talk about the smdk?
  I'm using the smdk machine and it's based on smdk machine?
  As board is more proper word and it's easy to know when find the board
  at source code.
  So hope to use the board if it's not big deal.
 
  Yes, we say 'SMDK board blah blah' so it can be no big deal, but I don't
  want to make a confusion between CONFIG_MACH_XXX and mach-xxx.c yet even
  though there is a similar situation of arch/arm/mach-xxx/ directory and
  CONFIG_ARCH_XXX. In addition, the machine_is_xxx() is used to
 distinguish
  board in the kernel.
 
  Anyway, I think, if to use board-xxx.c is required, we can change it all
 at
  once and let me think again.

 Don't think, use the current way.

 You seem not to have the common courtesy to discuss something here.

I also have same opinion on you. Discussion(?) with you is meaningless
and don't see any progress.

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


Re: [PATCH] ARM: EXYNOS: Adds Samsung TRATS board support

2011-12-25 Thread Kyungmin Park
On 12/24/11, Kukjin Kim kgene@samsung.com wrote:
 HeungJun, Kim wrote:

 This patch adds Samsung Mobile TRATS board support.

 Signed-off-by: HeungJun, Kim riverful@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig   |   11 ++
  arch/arm/mach-exynos/Makefile  |1 +
  arch/arm/mach-exynos/board-trats.c |  340
 
  3 files changed, 352 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-exynos/board-trats.c


 If this is for v3.3, unfortunately, it's a little late to add board file and
 since many things have changed I don't want to cause the conflicts with
 others now.

 BTW, why is the name board-xxx not mach-xxx like others?

It's mentioned several times,
How do you talk with other when talk about the smdk?
I'm using the smdk machine and it's based on smdk machine?
As board is more proper word and it's easy to know when find the board
at source code.
So hope to use the board if it's not big deal.

BR,
Kyungmin Park

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index 0afcc3b..3bbbef8 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -304,6 +304,17 @@ config MACH_ORIGEN
  help
Machine support for ORIGEN based on Samsung EXYNOS4210

 +config MACH_TRATS
 +bool Mobile TRATS Board
 +select CPU_EXYNOS4210
 +select S3C_DEV_WDT
 +select S3C_DEV_HSMMC
 +select S3C_DEV_I2C5
 +select EXYNOS4_SETUP_I2C5
 +select EXYNOS4_SETUP_SDHCI
 +help
 +  Machine support for Samsung Mobile TRATS Board.
 +
  comment EXYNOS4212 Boards

  config MACH_SMDK4212
 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index 57e5296..f3bdda9 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_ARMLEX4210)  += mach-
 armlex4210.o
  obj-$(CONFIG_MACH_UNIVERSAL_C210)   += mach-universal_c210.o
  obj-$(CONFIG_MACH_NURI) += mach-nuri.o
  obj-$(CONFIG_MACH_ORIGEN)   += mach-origen.o
 +obj-$(CONFIG_MACH_TRATS)+= board-trats.o

  obj-$(CONFIG_MACH_SMDK4212) += mach-smdk4x12.o
  obj-$(CONFIG_MACH_SMDK4412) += mach-smdk4x12.o
 diff --git a/arch/arm/mach-exynos/board-trats.c b/arch/arm/mach-
 exynos/board-trats.c
 new file mode 100644
 index 000..4c13dfc
 --- /dev/null
 +++ b/arch/arm/mach-exynos/board-trats.c
 @@ -0,0 +1,340 @@
 +/*
 + * linux/arch/arm/mach-exynos4/board-trats.c
 + *
 + * Copyright (c) 2011 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.
 + */
 +
 +#include linux/platform_device.h
 +#include linux/serial_core.h
 +#include linux/i2c.h
 +#include linux/gpio.h
 +#include linux/regulator/machine.h
 +#include linux/regulator/fixed.h
 +#include linux/mfd/max8997.h
 +#include linux/mfd/max8997-private.h
 +#include linux/mmc/host.h
 +
 +#include asm/mach/arch.h
 +#include asm/mach-types.h
 +
 +#include plat/regs-serial.h
 +#include plat/exynos4.h
 +#include plat/cpu.h
 +#include plat/devs.h
 +#include plat/sdhci.h
 +#include plat/clock.h
 +#include plat/gpio-cfg.h
 +#include plat/iic.h
 +
 +#include mach/map.h
 +
 +/* Following are default values for UCON, ULCON and UFCON UART registers
 */
 +#define TRATS_UCON_DEFAULT  (S3C2410_UCON_TXILEVEL |\
 + S3C2410_UCON_RXILEVEL |\
 + S3C2410_UCON_TXIRQMODE |   \
 + S3C2410_UCON_RXIRQMODE |   \
 + S3C2410_UCON_RXFIFO_TOI |  \
 + S3C2443_UCON_RXERR_IRQEN)
 +
 +#define TRATS_ULCON_DEFAULT S3C2410_LCON_CS8
 +
 +#define TRATS_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE |   \
 + S5PV210_UFCON_TXTRIG256 |  \
 + S5PV210_UFCON_RXTRIG256)
 +
 +enum fixed_regulator_id {
 +FIXED_REG_ID_MMC = 0,
 +};
 +
 +static struct s3c2410_uartcfg trats_uartcfgs[] __initdata = {
 +{
 +.hwport = 0,
 +.ucon   = TRATS_UCON_DEFAULT,
 +.ulcon  = TRATS_ULCON_DEFAULT,
 +.ufcon  = TRATS_UFCON_DEFAULT,
 +},
 +{
 +.hwport = 1,
 +.ucon   = TRATS_UCON_DEFAULT,
 +.ulcon  = TRATS_ULCON_DEFAULT,
 +.ufcon  = TRATS_UFCON_DEFAULT,
 +},
 +{
 +.hwport = 2,
 +.ucon   = TRATS_UCON_DEFAULT,
 +.ulcon  = TRATS_ULCON_DEFAULT,
 +.ufcon  = TRATS_UFCON_DEFAULT,
 +},
 +{
 +.hwport = 3,
 +.ucon   = TRATS_UCON_DEFAULT,
 +.ulcon

Re: [PATCH 1/4] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.

2011-12-16 Thread Kyungmin Park
Hi Mr. Kim,

It's maybe missing for v3.3 merge at samsung soc.
Please give your opinion, how to handle it?

If you don't mind it, it can merge it by devfreq.

Thank you,
Kyungmin Park


On 12/1/11, MyungJoo Ham myungjoo@samsung.com wrote:
 - Add DMC1
 - Enlarge address space for DMC from 4k to 64k so that PPMU registers
   may be accessed.

 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/cpu.c  |7 ++-
  arch/arm/mach-exynos/include/mach/map.h |1 +
  2 files changed, 7 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
 index 90ec247..8bdcba9 100644
 --- a/arch/arm/mach-exynos/cpu.c
 +++ b/arch/arm/mach-exynos/cpu.c
 @@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata = {
   }, {
   .virtual= (unsigned long)S5P_VA_DMC0,
   .pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
 - .length = SZ_4K,
 + .length = SZ_64K,
 + .type   = MT_DEVICE,
 + }, {
 + .virtual= (unsigned long)S5P_VA_DMC1,
 + .pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
 + .length = SZ_64K,
   .type   = MT_DEVICE,
   }, {
   .virtual= (unsigned long)S5P_VA_SROMC,
 diff --git a/arch/arm/mach-exynos/include/mach/map.h
 b/arch/arm/mach-exynos/include/mach/map.h
 index 058541d..870a980 100644
 --- a/arch/arm/mach-exynos/include/mach/map.h
 +++ b/arch/arm/mach-exynos/include/mach/map.h
 @@ -57,6 +57,7 @@
  #define EXYNOS4_PA_KEYPAD0x100A

  #define EXYNOS4_PA_DMC0  0x1040
 +#define EXYNOS4_PA_DMC1  0x1041

  #define EXYNOS4_PA_COMBINER  0x1044

 --
 1.7.4.1

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

--
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/3] s5p-g2d: add G2D to mach-nuri

2011-12-12 Thread Kyungmin Park
On 12/12/11, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
 On Fri, Dec 09, 2011 at 05:04:41PM +0100, Kamil Debski wrote:

 index 236bbe1..5251e91 100644
 --- a/arch/arm/mach-exynos/mach-nuri.c
 +++ b/arch/arm/mach-exynos/mach-nuri.c
 @@ -1262,6 +1262,7 @@ static struct platform_device *nuri_devices[]
 __initdata = {
  s3c_device_i2c3,
  i2c9_gpio,
  s3c_device_adc,
 +s5p_device_g2d,

 For devices like g2d which are always part of the SoC and which don't
 require any external wiring on the board I was thinking we should just
 have the core code for the SoC register the device rather than including
 it in each board individually.  It'd save effort and ensure that people
 automatically get to use the feature.
I'm welcome to use these scheme. make a common.c and register it automatically.
but I'm not sure we're ready to use this scheme. and I hope to start
these work at smdk board instead of this patch.

Thank you,
Kyungmin Park

 The crypto accelerators are another example of this - it's not really
 board specific if they're useful.
 --
 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

--
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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos

2011-12-06 Thread Kyungmin Park
On Tue, Dec 6, 2011 at 9:13 PM, KyongHo Cho pullip@samsung.com wrote:
 On Tue, Dec 6, 2011 at 8:24 AM, Kyungmin Park kmp...@infradead.org wrote:
 On 12/6/11, Joerg Roedel joerg.roe...@amd.com wrote:
 On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote:
 Patch Summary:
 [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions
 [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms

 Okay, I merged it into arm/exynos, but it is not pushed yet. Actually
 there were conflicts while merging, which I resolved. What I failed
 to find is a config for Exynos that actually builds for upstream Linux.
 Probably I havn't tried hard enough to find one... Can you provide a
 kernel config that I can use for my testing and that builds a current
 3.2-rc4 kernel for Exynos?
 and I hope to see the real example how to use it with exynos platform.

 Now I can't find the interface between exynos platform and generic exynos 
 iommu.
 In [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device
 definitions patch,
 you can find sysmmu_init().
 It stores associations between a system MMU and a peripheral device in
 platform data of platform device descriptor.
 If Exynos IOMMU driver finds the association while probing, then the
 driver can control the system MMU.
Maybe it's still call the function directly instead of using struct
dev field as OMAP did.
Even though generic DMA mapping IOMMU doesn't used, you can connect
the iommu field at arch/arm/include/asm/device.h

BR,
Kyungmin Park

 BTW, how do you test it at mainline kernel?

 I merged IOMMU mainline branch to our kernel branch and tested it with
 our FIMC, MFC, JPEG, 2D.
--
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] backlight: add regulator support for platform_lcd driver

2011-12-05 Thread Kyungmin Park
On 12/5/11, Thomas Abraham thomas.abra...@linaro.org wrote:
 The power source to the lcd panel or the lcd interface such as lvds
 transmitters could be controlled by a regulator supply. Add support
 for enabling/disabling the regulator when switching power to lcd.

 Two new elements 'min_uV' and 'max_uV' in the platform data are added
 to allow platform code to specifiy the desired output voltage from the
 regulator.

 Cc: Ben Dooks ben-li...@fluff.org
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  drivers/video/backlight/platform_lcd.c |   29 +
  include/video/platform_lcd.h   |7 +++
  2 files changed, 36 insertions(+), 0 deletions(-)

 diff --git a/drivers/video/backlight/platform_lcd.c
 b/drivers/video/backlight/platform_lcd.c
 index 302330a..ffa8108 100644
 --- a/drivers/video/backlight/platform_lcd.c
 +++ b/drivers/video/backlight/platform_lcd.c
 @@ -17,6 +17,8 @@
  #include linux/backlight.h
  #include linux/lcd.h
  #include linux/slab.h
 +#include linux/regulator/consumer.h
 +#include linux/regulator/machine.h

  #include video/platform_lcd.h

 @@ -44,11 +46,38 @@ static int platform_lcd_get_power(struct lcd_device
 *lcd)
  static int platform_lcd_set_power(struct lcd_device *lcd, int power)
  {
   struct platform_lcd *plcd = to_our_lcd(lcd);
 + struct regulator *lcd_regulator;
   int lcd_power = 1;

   if (power == FB_BLANK_POWERDOWN || plcd-suspended)
   lcd_power = 0;

 + /*
 +  * If power to lcd and/or lcd interface is controlled using a regulator,
 +  * enable or disable the regulator based in the power setting.
 +  */
 + lcd_regulator = regulator_get(plcd-us, vcc_lcd);
 + if (IS_ERR(lcd_regulator)) {
 + dev_info(plcd-us, could not get regulator\n);
 + goto set_power;
 + }

Recent regulator discussion. it should be failed instead fall through
gracefully.
 +
 + if (lcd_power) {
 + if (plcd-pdata-min_uV || plcd-pdata-max_uV)
 + if (regulator_set_voltage(lcd_regulator,
 + plcd-pdata-min_uV, plcd-pdata-max_uV))
 + dev_info(plcd-us,
 + regulator voltage set failed\n);
Are there case to change the voltage? Doesn't it easy to set the
voltage at board file? I mean don't need to setup at drivers?

Thank you,
Kyungmin Park
 +
 + if (regulator_enable(lcd_regulator))
 + dev_info(plcd-us, failed to enable regulator\n);
 + } else {
 + regulator_disable(lcd_regulator);
 + }
 +
 + regulator_put(lcd_regulator);
 +
 +set_power:
   plcd-pdata-set_power(plcd-pdata, lcd_power);
   plcd-power = power;

 diff --git a/include/video/platform_lcd.h b/include/video/platform_lcd.h
 index ad3bdfe..acd5d21 100644
 --- a/include/video/platform_lcd.h
 +++ b/include/video/platform_lcd.h
 @@ -14,8 +14,15 @@
  struct plat_lcd_data;
  struct fb_info;

 +/**
 + * struct plat_lcd_data - platform data for platform_lcd driver.
 + * @min_uV: Minimum required voltage output from the regulator.
 + * @max_uV: Maximum acceptable voltage output from the regulator.
 + */
  struct plat_lcd_data {
   void(*set_power)(struct plat_lcd_data *, unsigned int power);
   int (*match_fb)(struct plat_lcd_data *, struct fb_info *);
 + int min_uV;
 + int max_uV;
  };

 --
 1.6.6.rc2

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

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


Re: [PATCH 2/2] arm: exynos: allow platform-lcd driver to control lcd regulator source on origen

2011-12-05 Thread Kyungmin Park
On 12/5/11, Thomas Abraham thomas.abra...@linaro.org wrote:
 The buck7 regulator of max8997 pmic which provides the power source to lcd
 panel
 and the lvds transmitter is allowed to be controlled by the platform-lcd
 driver.
 It is not required to apply the voltage source by default. Also, the voltage
 range for buck7 regulator is modified as the per the values in the
 datasheet.

 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  arch/arm/mach-exynos/mach-origen.c |   12 +++-
  1 files changed, 7 insertions(+), 5 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-origen.c
 b/arch/arm/mach-exynos/mach-origen.c
 index f56d027..5456254 100644
 --- a/arch/arm/mach-exynos/mach-origen.c
 +++ b/arch/arm/mach-exynos/mach-origen.c
 @@ -126,7 +126,7 @@ static struct regulator_consumer_supply __initdata
 buck3_consumer[] = {
   REGULATOR_SUPPLY(vdd_g3d, mali_drm), /* G3D */
  };
  static struct regulator_consumer_supply __initdata buck7_consumer[] = {
 - REGULATOR_SUPPLY(vcc, platform-lcd), /* LCD */
 + REGULATOR_SUPPLY(vcc_lcd, platform-lcd.0), /* LCD */
  };

  static struct regulator_init_data __initdata max8997_ldo1_data = {
 @@ -379,11 +379,11 @@ static struct regulator_init_data __initdata
 max8997_buck5_data = {
  static struct regulator_init_data __initdata max8997_buck7_data = {
   .constraints= {
   .name   = VDD_LCD_3.3V,
 - .min_uV = 330,
 - .max_uV = 330,
 + .min_uV = 75,
 + .max_uV = 390,
It can support the voltage change at buck itself, but in board it's
fixed. I'm not sure it's correct usage at board file.

I think original code is better to understand and use it as name, it's
fixed v3.3 voltage.

Thank you,
Kyungmin Park
   .boot_on= 1,
 - .apply_uV   = 1,
 - .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 + .valid_ops_mask = REGULATOR_CHANGE_STATUS |
 + REGULATOR_CHANGE_VOLTAGE,
   .state_mem  = {
   .disabled   = 1
   },
 @@ -562,6 +562,8 @@ static void lcd_hv070wsa_set_power(struct plat_lcd_data
 *pd, unsigned int power)

  static struct plat_lcd_data origen_lcd_hv070wsa_data = {
   .set_power = lcd_hv070wsa_set_power,
 + .min_uV = 330,
 + .max_uV = 330,
  };

  static struct platform_device origen_lcd_hv070wsa = {
 --
 1.6.6.rc2

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

--
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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos

2011-12-05 Thread Kyungmin Park
On 12/6/11, Joerg Roedel joerg.roe...@amd.com wrote:
 On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote:
 Patch Summary:
 [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions
 [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms

 Okay, I merged it into arm/exynos, but it is not pushed yet. Actually
 there were conflicts while merging, which I resolved. What I failed
 to find is a config for Exynos that actually builds for upstream Linux.
 Probably I havn't tried hard enough to find one... Can you provide a
 kernel config that I can use for my testing and that builds a current
 3.2-rc4 kernel for Exynos?
and I hope to see the real example how to use it with exynos platform.

Now I can't find the interface between exynos platform and generic exynos iommu.
BTW, how do you test it at mainline kernel?

Thank you,
Kyungmin Park


 Thanks,

   Joerg

 --
 AMD Operating System Research Center

 Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
 General Managers: Alberto Bozzo, Andrew Bowd
 Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr.
 43632

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

--
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: EXYNOS4: Add DMC1, allow PPMU access for DMC.

2011-12-02 Thread Kyungmin Park
On 12/2/11, Kukjin Kim kgene@samsung.com wrote:
 MyungJoo Ham wrote:

 - Add DMC1
 - Enlarge address space for DMC from 4k to 64k so that PPMU registers
   may be accessed.

 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/cpu.c  |7 ++-
  arch/arm/mach-exynos/include/mach/map.h |1 +
  2 files changed, 7 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
 index 90ec247..8bdcba9 100644
 --- a/arch/arm/mach-exynos/cpu.c
 +++ b/arch/arm/mach-exynos/cpu.c
 @@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata =
 {
  }, {
  .virtual= (unsigned long)S5P_VA_DMC0,
  .pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
 -.length = SZ_4K,
 +.length = SZ_64K,
 +.type   = MT_DEVICE,
 +}, {
 +.virtual= (unsigned long)S5P_VA_DMC1,
 +.pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
 +.length = SZ_64K,
  .type   = MT_DEVICE,
  }, {
  .virtual= (unsigned long)S5P_VA_SROMC,
 diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
 exynos/include/mach/map.h
 index 058541d..870a980 100644
 --- a/arch/arm/mach-exynos/include/mach/map.h
 +++ b/arch/arm/mach-exynos/include/mach/map.h
 @@ -57,6 +57,7 @@
  #define EXYNOS4_PA_KEYPAD   0x100A

  #define EXYNOS4_PA_DMC0 0x1040
 +#define EXYNOS4_PA_DMC1 0x1041

 If required, so just '.length = SZ_128K'?...
Doesn't it more confuse and difficult to use?

Even though there's not much definitions. it defines the offset concept.
arch/arm/mach-exynos/include/mach/regs-mem.h

BR,

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.

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

--
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/3] ARM: S3C64XX: Implement basic power domain support

2011-12-01 Thread Kyungmin Park
Hi Mark,

I'm not sure what's the next step at s3c64xx for generic power domain.
Related with exysno4 series, it's helpful to read following threads.
http://68.183.106.108/lists/linux-pm/msg26291.html

I don't think we should control/gate the clocks with regarding power
domain from Mr. Kim

Thank you,
Kyungmin Park

On 12/2/11, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
 The S3C64xx SoCs contain a set of gateable power domains which can be
 enabled and disabled at runtime in order to save power.  Use the generic
 power domain code to implement support for these in software, enabling
 runtime control of most domains:

  - ETM (not supported in mainline).
  - Domain G: 3D acceleration (no mainline support).
  - Domain V: MFC (no mainline support).
  - Domain I: JPEG and camera interface (no mainline support).
  - Domain P: 2D acceleration, TV encoder and scaler (no mainline support)
  - Domain S: Security (no mainline support).
  - Domain F: LCD (driver already uses runtime PM), post processing and
rotation (no mainline support).

 The IROM domain is marked as always enabled as we should arrange for it
 to be enabled when we suspend which will need a bit more work.

 Due to all the conditional device registration that the platform does
 wrap s3c_pm_init() with s3c64xx_pm_init() which actually puts the device
 into the power domain after the machines have registered, looking for
 platform data to tell if the device was registered. Since currently only
 Cragganmore actually sets up PM that is the only machine updated.

 Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
 ---

 Kikjin, this superceeds my previous patch unconditionally disabling some
 of the domains.  I've given it quite a bit of testing and it appears to
 be working well on my systems though I'm not sure the power saving is
 really all that much to write home about.

  arch/arm/mach-s3c64xx/Kconfig   |1 +
  arch/arm/mach-s3c64xx/mach-crag6410.c   |2 +-
  arch/arm/mach-s3c64xx/pm.c  |  173
 ++-
  arch/arm/plat-samsung/include/plat/pm.h |6 +
  4 files changed, 179 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
 index 4d8c489..5c6c22e 100644
 --- a/arch/arm/mach-s3c64xx/Kconfig
 +++ b/arch/arm/mach-s3c64xx/Kconfig
 @@ -8,6 +8,7 @@ config PLAT_S3C64XX
   bool
   depends on ARCH_S3C64XX
   select SAMSUNG_WAKEMASK
 + select PM_GENERIC_DOMAINS
   default y
   help
 Base platform code for any Samsung S3C64XX device
 diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
 b/arch/arm/mach-s3c64xx/mach-crag6410.c
 index 98d42b3..4ce4a74 100644
 --- a/arch/arm/mach-s3c64xx/mach-crag6410.c
 +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
 @@ -743,7 +743,7 @@ static void __init crag6410_machine_init(void)

   regulator_has_full_constraints();

 - s3c_pm_init();
 + s3c64xx_pm_init();
  }

  MACHINE_START(WLF_CRAGG_6410, Wolfson Cragganmore 6410)
 diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
 index b375cd5..aa7b5d1 100644
 --- a/arch/arm/mach-s3c64xx/pm.c
 +++ b/arch/arm/mach-s3c64xx/pm.c
 @@ -17,10 +17,12 @@
  #include linux/serial_core.h
  #include linux/io.h
  #include linux/gpio.h
 +#include linux/pm_domain.h

  #include mach/map.h
  #include mach/irqs.h

 +#include plat/devs.h
  #include plat/pm.h
  #include plat/wakeup-mask.h

 @@ -31,6 +33,145 @@
  #include mach/regs-gpio-memport.h
  #include mach/regs-modem.h

 +struct s3c64xx_pm_domain {
 + char *const name;
 + u32 ena;
 + u32 pwr_stat;
 + struct generic_pm_domain pd;
 +};
 +
 +static int s3c64xx_pd_off(struct generic_pm_domain *domain)
 +{
 + struct s3c64xx_pm_domain *pd;
 + u32 val;
 +
 + pd = container_of(domain, struct s3c64xx_pm_domain, pd);
 +
 + val = __raw_readl(S3C64XX_NORMAL_CFG);
 + val = ~(pd-ena);
 + __raw_writel(val, S3C64XX_NORMAL_CFG);
 +
 + return 0;
 +}
 +
 +static int s3c64xx_pd_on(struct generic_pm_domain *domain)
 +{
 + struct s3c64xx_pm_domain *pd;
 + u32 val;
 + long retry = 100L;
 +
 + pd = container_of(domain, struct s3c64xx_pm_domain, pd);
 +
 + val = __raw_readl(S3C64XX_NORMAL_CFG);
 + val |= pd-ena;
 + __raw_writel(val, S3C64XX_NORMAL_CFG);
 +
 + /* Not all domains provide power status readback */
 + if (pd-pwr_stat) {
 + while (retry--)
 + if (__raw_readl(S3C64XX_BLK_PWR_STAT)  pd-pwr_stat)
 + break;
 + if (!retry) {
 + pr_err(Failed to start domain %s\n, pd-name);
 + return -EBUSY;
 + }
 + }
 +
 + return 0;
 +}
 +
 +static struct s3c64xx_pm_domain s3c64xx_pm_irom = {
 + .name = IROM,
 + .ena = S3C64XX_NORMALCFG_IROM_ON,
 + .pd = {
 + .power_off = s3c64xx_pd_off,
 + .power_on = s3c64xx_pd_on,
 + },
 +};
 +
 +static

  1   2   3   >