[GIT PULL 1/4] Samsung fixes for v3.7

2012-09-21 Thread Kukjin Kim

Hi Arnd, Olof

This is non-critical Samsung fixes for v3.7.

If any problems, please kindly let me know.

Thanks.

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

The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:

  Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
v3.7-samsung-fixes-1


Julia Lawall (1):
  ARM: S3C24xx: delete double assignment

Kukjin Kim (1):
  ARM: EXYNOS: fix address for EXYNOS4 MDMA1

Peter Senna Tschudin (1):
  ARM: S3C24XX: removes unnecessary semicolon

Seung-Woo Kim (1):
  ARM: EXYNOS: fixed SYSMMU setup definition to mate parameter name

Sylwester Nawrocki (1):
  ARM: SAMSUNG: Add missing variable declaration in 
s3c64xx_spi1_set_platdata()


 arch/arm/mach-exynos/include/mach/map.h|2 +-
 arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
 arch/arm/mach-s3c24xx/mach-h1940.c |4 ++--
 arch/arm/plat-samsung/devs.c   |2 ++
 4 files changed, 6 insertions(+), 4 deletions(-)
--
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


[GIT PULL 2/4] Samsung pinctrl-2 for v3.7

2012-09-21 Thread Kukjin Kim

Hi Arnd, Olof

This is for fix typo and correct fucntion for Samsung pinctrl and since 
this has a dependency with previous pinctrl branch I created this based 
on that.


If any problems, please kindly let me know.

Thanks.

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

The following changes since commit 011527b45f8e3092e1f3192e5aea94187a6ca269:

  ARM: EXYNOS: Enable pinctrl driver support for EXYNOS4 device tree 
enabled platform (2012-09-07 06:14:26 +0900)


are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
next/pinctrl-samsung-2


Tomasz Figa (7):
  pinctrl: exynos: Set pin function to EINT in irq_set_type of GPIO 
EINTa

  pinctrl: exynos: Fix typos in gpio/wkup _irq_mask
  pinctrl: exynos: Handle only unmasked wakeup interrupts
  pinctrl: exynos: Mark exynos_irq_demux_eint as inline
  pinctrl: exynos: Correct the detection of wakeup-eint node
  pinctrl: samsung: Uninline samsung_pinctrl_get_soc_data
  pinctrl: exynos: Fix wakeup IRQ domain registration check

 drivers/pinctrl/pinctrl-exynos.c  |   41 
+++--

 drivers/pinctrl/pinctrl-exynos.h  |1 +
 drivers/pinctrl/pinctrl-samsung.c |2 +-
 3 files changed, 32 insertions(+), 12 deletions(-)

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


[GIT PULL 3/4] Samsung devel for v3.7

2012-09-21 Thread Kukjin Kim

Hi Arnd, Olof

Here is Samsung development for v3.7 and most of them are updating.

If any problems, please kindly let me know.

Thanks.

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

The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:

  Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
next/devel-samsung


Chander Kashyap (3):
  ARM: EXYNOS: Turn off clocks for NAND, OneNAND and TSI controllers
  ARM: EXYNOS: Put PCM, Slimbus, Spdif clocks to off state
  ARM: SAMSUNG: Add check for NULL in clock interface

Leela Krishna Amudala (1):
  ARM: EXYNOS: Add bus clock for FIMD

Sachin Kamat (2):
  ARM: EXYNOS: Fix incorrect help text
  ARM: SAMSUNG: Fix HDMI related warnings

Sylwester Nawrocki (1):
  ARM: S3C24XX: Add .get_rate callback for camif-upll clock

 arch/arm/mach-exynos/Kconfig  |4 ++--
 arch/arm/mach-exynos/clock-exynos4.c  |   31 
+++
 arch/arm/mach-exynos/clock-exynos5.c  |   32 
++--

 arch/arm/mach-s3c24xx/clock-s3c2440.c |   14 ++
 arch/arm/plat-samsung/clock.c |8 
 arch/arm/plat-samsung/devs.c  |3 ++-
 6 files changed, 75 insertions(+), 17 deletions(-)

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


[GIT PULL 4/4] Samsung DT for v3.7

2012-09-21 Thread Kukjin Kim

Hi Arnd, Olof

This is for updating Samsung DT for v3.7.

But now this makes many conflicts with pinctrl dt because of moving file 
so I'm sorting them out to avoid useless conflicts.


I'll re-send this soon again.
This is jut for your information.

Thanks.

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

The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:

  Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
next/dt-samsung


Kukjin Kim (1):
  ARM: dts: use uart2 for console on smdkv310 and smdk5250

Tomasz Figa (6):
  ARM: dts: Move parts common to EXYNOS4 from exynos4210.dtsi to 
exynos4.dtsi

  ARM: EXYNOS: Use exynos4 prefix instead of exynos4210 on exynos4-dt
  ARM: dts: Assume status of all optional nodes as disabled for exynos4
  ARM: dts: Specify address and size cells for i2c controllers for 
EXYNOS4

  ARM: EXYNOS: Add OF compatibility lookups for EXYNOS4 i2c adapters
  ARM: dts: Add basic dts file for Samsung Trats board

Tushar Behera (1):
  ARM: dts: Enable on-board keys as wakeup source for exynos4210-origen

 arch/arm/boot/dts/exynos4.dtsi|  248 
+

 arch/arm/boot/dts/exynos4210-origen.dts   |   63 +---
 arch/arm/boot/dts/exynos4210-smdkv310.dts |   54 +--
 arch/arm/boot/dts/exynos4210-trats.dts|  237 
+++

 arch/arm/boot/dts/exynos4210.dtsi |  181 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts |2 +-
 arch/arm/mach-exynos/Makefile.boot|2 +-
 arch/arm/mach-exynos/mach-exynos4-dt.c|   32 +++-
 8 files changed, 523 insertions(+), 296 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos4.dtsi
 create mode 100644 arch/arm/boot/dts/exynos4210-trats.dts

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


[PATCH V2 0/3] Add device tree based discovery support for drm-fimd

2012-09-21 Thread Leela Krishna Amudala
This patch set adds arch side support for device tree based discovery
for drm-fimd.

The patches are created against for-next branch of Kukjin Kim's tree on 
3.6-rc6 at:
 git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git

This patchset has been tested on smdk5250 board and seen the bootup logo on LCD
using the patchset http://www.spinics.net/lists/arm-kernel/msg193348.html which 
was 
applied on inki-dae's next branch

Changes since V1:
- Renamed the compatible string from samsung,exynos5-drm to 
samsung,exynos5-fimd
- Renamed the macro from EXYNOS5_PA_FIMD to EXYNOS5_PA_FIMD1

Leela Krishna Amudala (3):
  ARM: EXYNOS5: Add fimd node to the exynos5250 dtsi file
  ARM: EXYNOS: add device tree based discovery support for FIMD
  ARM: EXYNOS: Add drm-device node to the dtsi file

 arch/arm/boot/dts/exynos5250-smdk5250.dts |   15 +++
 arch/arm/boot/dts/exynos5250.dtsi |   11 +++
 arch/arm/mach-exynos/include/mach/map.h   |1 +
 arch/arm/mach-exynos/mach-exynos5-dt.c|2 ++
 4 files changed, 29 insertions(+), 0 deletions(-)

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


[PATCH V2 1/3] ARM: EXYNOS5: Add fimd node to the exynos5250 dtsi file

2012-09-21 Thread Leela Krishna Amudala
This patch adds the fimd node with compatibility string, hardware address,
interrupt line numbers to the exynos5250 dtsi file.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 arch/arm/boot/dts/exynos5250.dtsi |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index b55794b..6401c94 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -488,4 +488,11 @@
reg = 0x13e3 0x1000;
interrupts = 0 88 0;
};
+
+   fimd {
+   compatible = samsung,exynos5-fimd;
+   interrupt-parent = combiner;
+   reg = 0x1440 0x4;
+   interrupts = 18 5, 18 4, 18 6;
+   };
 };
-- 
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


[PATCH V2 2/3] ARM: EXYNOS: add device tree based discovery support for FIMD

2012-09-21 Thread Leela Krishna Amudala
This patch adds support for device tree based discovery for Samsung's
display controller. Adds DRM-Fimd plat data for smdk5250
evt1 to the corresponding dts file

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |   15 +++
 arch/arm/mach-exynos/include/mach/map.h   |1 +
 arch/arm/mach-exynos/mach-exynos5-dt.c|2 ++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 8a5e348..2ebf993 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -109,4 +109,19 @@
spi_2: spi@12d4 {
status = disabled;
};
+
+   lcd_fimd0: lcd_panel0 {
+   lcd-htiming = 4 4 4 1280;
+   lcd-vtiming = 4 4 4 800;
+   };
+
+   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/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index 5aa77f9..76b4a68 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -174,6 +174,7 @@
 #define EXYNOS4_PA_MIPI_CSIS1  0x1189
 
 #define EXYNOS4_PA_FIMD0   0x11C0
+#define EXYNOS5_PA_FIMD1   0x1440
 
 #define EXYNOS4_PA_HSMMC(x)(0x1251 + ((x) * 0x1))
 #define EXYNOS4_PA_DWMCI   0x1255
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c 
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index e707eb1..5fd5068 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -64,6 +64,8 @@ static const struct of_dev_auxdata 
exynos5250_auxdata_lookup[] __initconst = {
exynos-gsc.2, NULL),
OF_DEV_AUXDATA(samsung,exynos5-gsc, EXYNOS5_PA_GSC3,
exynos-gsc.3, NULL),
+   OF_DEV_AUXDATA(samsung,exynos5-fimd, EXYNOS5_PA_FIMD1,
+   exynos5-fb.1, NULL),
{},
 };
 
-- 
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


[PATCH V2 3/3] ARM: EXYNOS: Add drm-device node to the dtsi file

2012-09-21 Thread Leela Krishna Amudala
This patch adds platform drm-device node to the dtsi file

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 arch/arm/boot/dts/exynos5250.dtsi |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 6401c94..f0cc06d 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -495,4 +495,8 @@
reg = 0x1440 0x4;
interrupts = 18 5, 18 4, 18 6;
};
+
+   drm-device {
+   compatible = samsung,exynos-drm-device;
+   };
 };
-- 
1.7.0.4

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


Re: [PATCH v3] ARM: EXYNOS: Add MFC device tree support

2012-09-21 Thread Arun Kumar K
Hi Karol,
Thank you for the review.
Please find my comments inline.

On Wed, Sep 19, 2012 at 3:08 PM, Karol Lewandowski k.lewando...@samsung.com 
wrote:
 On 09/14/2012 05:38 PM, Arun Kumar K wrote:

 This patch adds device tree entry for MFC v6 in the Exynos5
 SoC. Makes the required changes in the clock files and adds
 MFC to the DT device list.


 Hi!

 Thanks for working on this patch. Please allow me to add few
 comments.


 diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
 b/arch/arm/boot/dts/exynos5250.dtsi
 index b55794b..5df2f99 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -62,6 +62,12 @@
   interrupts = 0 42 0;
   };

 + mfc {


 Nitpick - shouldn't node names be generic?  MFC is strictly
 samsung specific, something like codec/video-codec would make
 more sense (IMVHO). I would prefer to see address too (e.g.
 codec@0x1100).

 However, I do see that rtc below doesn't specify address in node too,
 so maybe I'm missing something here.


Yes codec makes it more generic.
I too dont see the addresses used everywhere in node names.
If somebody can please suggest which one is better
mfc OR codec OR codec@0x1100 as node name.




 +struct mfc_dt_meminfo {
 + unsigned long loff;
 + unsigned long lsize;
 + unsigned long roff;
 + unsigned long rsize;


   char *compatible;

 +};
 +
 +int fdt_find_mfc_mem(unsigned long node, const char *uname, int depth,
 + void *data)
 +{
 + __be32 *prop;
 + unsigned long len;
 + struct mfc_dt_meminfo *mfc_mem = data;
 +
 + if (!of_flat_dt_is_compatible(node, samsung,mfc-v6))
 + return 0;


   if (!of_flat_dt_is_compatible(node, mfc_mem-compatible))
 return 0;

 +
 + prop = of_get_flat_dt_prop(node, samsung,mfc-l, len);
 + if (!prop)
 + return 0;
 + mfc_mem-loff = of_read_ulong(prop, len/4);
 +
 + prop = of_get_flat_dt_prop(node, samsung,mfc-l-size, len);
 + if (!prop)
 + return 0;
 + mfc_mem-lsize = of_read_ulong(prop, len/4);
 +
 + prop = of_get_flat_dt_prop(node, samsung,mfc-r, len);
 + if (!prop)
 + return 0;
 + mfc_mem-roff = of_read_ulong(prop, len/4);
 +
 + prop = of_get_flat_dt_prop(node, samsung,mfc-r-size, len);
 + if (!prop)
 + return 0;
 + mfc_mem-rsize = of_read_ulong(prop, len/4);
 +
 + return 1;
 +}


 Above function could be reused for mfc-v5 (exynos4-dt.c) if compatible
 string weren't hardcoded. Thus, please consider changing that and
 moving this function to some common(.c?) file - you can see one possible
 solution inline.


Yes I can move it to common.c file and the structure definition to common.h
file for function reusability. Will make this change.

 +
 +static void __init exynos5_reserve(void)
 +{
 + struct mfc_dt_meminfo mfc_mem;


 mfc_mem.compatible = samsung,mfc-v6;

 +
 + /* Reserve memory for MFC only if it's available */
 + if (of_scan_flat_dt(fdt_find_mfc_mem, mfc_mem))
 + s5p_mfc_reserve_mem(mfc_mem.roff, mfc_mem.rsize, mfc_mem.loff,
 + mfc_mem.lsize);
 +}
 +
  DT_MACHINE_START(EXYNOS5_DT, SAMSUNG EXYNOS5 (Flattened Device Tree))
   /* Maintainer: Kukjin Kim kgene@samsung.com */
   .init_irq   = exynos5_init_irq,
 @@ -94,4 +148,5 @@ DT_MACHINE_START(EXYNOS5_DT, SAMSUNG EXYNOS5 (Flattened 
 Device Tree))
   .timer  = exynos4_timer,
   .dt_compat  = exynos5250_dt_compat,
   .restart= exynos5_restart,
 + .reserve= exynos5_reserve,
  MACHINE_END


 Regards,
 --
 Karol Lewandowski | Samsung Poland RD Center | Linux/Platform
 --
 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 3/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume

2012-09-21 Thread Chris Ball
Hi Chander,

On Fri, Sep 21 2012, Chander Kashyap wrote:
 From: Chander Kashyap chander.kash...@gmail.com

 Perform clock disable/enable in runtime suspend/resume.

 Signed-off-by: Chander Kashyap chander.kash...@linaro.org
 Acked-by: Jaehoon Chung jh80.ch...@samsung.com
 ---
 Changelog:
 v2:
 - Wrapped clk_disable in probe and clk_enable in remove with
   #ifdef CONFIG_PM_RUNTIME conditional check.

Thanks, pushed to mmc-next for 3.7.

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
One Laptop Per Child
--
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 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Inki Dae
2012/9/21 Stephen Warren swar...@wwwdotorg.org:
 On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
 This patch adds device tree based discovery support for exynos DRM-FIMD
 driver which includes driver modification to handle platform data in
 both the cases with DT and non-DT, Also adds the documentation for bindings.

 diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
 b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
 ...
 + - 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.

 Should this not use the new videomode timings that are under discussion at:

 http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html


ok, I agree with you. then the videomode helper is going to be merged
to mainline(3.6)? if so, this patch should be reworked based on the
videomode helper.


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


[PATCH 1/2] m5mols: Remove unneeded control ops assignments

2012-09-21 Thread Sylwester Nawrocki
Since all host drivers using this subdev are already using
the control framework these compatibility ops can be removed.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols_core.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols_core.c 
b/drivers/media/video/m5mols/m5mols_core.c
index ac7d28b..cbb6381 100644
--- a/drivers/media/video/m5mols/m5mols_core.c
+++ b/drivers/media/video/m5mols/m5mols_core.c
@@ -822,13 +822,6 @@ static int m5mols_log_status(struct v4l2_subdev *sd)
 
 static const struct v4l2_subdev_core_ops m5mols_core_ops = {
.s_power= m5mols_s_power,
-   .g_ctrl = v4l2_subdev_g_ctrl,
-   .s_ctrl = v4l2_subdev_s_ctrl,
-   .queryctrl  = v4l2_subdev_queryctrl,
-   .querymenu  = v4l2_subdev_querymenu,
-   .g_ext_ctrls= v4l2_subdev_g_ext_ctrls,
-   .try_ext_ctrls  = v4l2_subdev_try_ext_ctrls,
-   .s_ext_ctrls= v4l2_subdev_s_ext_ctrls,
.log_status = m5mols_log_status,
 };
 
-- 
1.7.11.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


[PATCH 2/2] m5mols: Protect driver data with a mutex

2012-09-21 Thread Sylwester Nawrocki
Without the locking the driver's data could get corrupted when the subdev
is accessed from user space and from host driver by multiple processes.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols.h  | 18 +---
 drivers/media/video/m5mols/m5mols_core.c | 77 +---
 2 files changed, 62 insertions(+), 33 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols.h 
b/drivers/media/video/m5mols/m5mols.h
index bb58991..15d3a4f 100644
--- a/drivers/media/video/m5mols/m5mols.h
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -155,8 +155,6 @@ struct m5mols_version {
  * @pdata: platform data
  * @sd: v4l-subdev instance
  * @pad: media pad
- * @ffmt: current fmt according to resolution type
- * @res_type: current resolution type
  * @irq_waitq: waitqueue for the capture
  * @irq_done: set to 1 in the interrupt handler
  * @handle: control handler
@@ -174,6 +172,10 @@ struct m5mols_version {
  * @wdr: wide dynamic range control
  * @stabilization: image stabilization control
  * @jpeg_quality: JPEG compression quality control
+ * @set_power: optional power callback to the board code
+ * @lock: mutex protecting the structure fields below
+ * @ffmt: current fmt according to resolution type
+ * @res_type: current resolution type
  * @ver: information of the version
  * @cap: the capture mode attributes
  * @isp_ready: 1 when the ISP controller has completed booting
@@ -181,14 +183,11 @@ struct m5mols_version {
  * @ctrl_sync: 1 when the control handler state is restored in H/W
  * @resolution:register value for current resolution
  * @mode: register value for current operation mode
- * @set_power: optional power callback to the board code
  */
 struct m5mols_info {
const struct m5mols_platform_data *pdata;
struct v4l2_subdev sd;
struct media_pad pad;
-   struct v4l2_mbus_framefmt ffmt[M5MOLS_RESTYPE_MAX];
-   int res_type;
 
wait_queue_head_t irq_waitq;
atomic_t irq_done;
@@ -216,6 +215,13 @@ struct m5mols_info {
struct v4l2_ctrl *stabilization;
struct v4l2_ctrl *jpeg_quality;
 
+   int (*set_power)(struct device *dev, int on);
+
+   struct mutex lock;
+
+   struct v4l2_mbus_framefmt ffmt[M5MOLS_RESTYPE_MAX];
+   int res_type;
+
struct m5mols_version ver;
struct m5mols_capture cap;
 
@@ -225,8 +231,6 @@ struct m5mols_info {
 
u8 resolution;
u8 mode;
-
-   int (*set_power)(struct device *dev, int on);
 };
 
 #define is_available_af(__info)(__info-ver.af)
diff --git a/drivers/media/video/m5mols/m5mols_core.c 
b/drivers/media/video/m5mols/m5mols_core.c
index cbb6381..5d108fe 100644
--- a/drivers/media/video/m5mols/m5mols_core.c
+++ b/drivers/media/video/m5mols/m5mols_core.c
@@ -551,13 +551,18 @@ static int m5mols_get_fmt(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh,
 {
struct m5mols_info *info = to_m5mols(sd);
struct v4l2_mbus_framefmt *format;
+   int ret = 0;
+
+   mutex_lock(info-lock);
 
format = __find_format(info, fh, fmt-which, info-res_type);
if (!format)
-   return -EINVAL;
+   fmt-format = *format;
+   else
+   ret = -EINVAL;
 
-   fmt-format = *format;
-   return 0;
+   mutex_unlock(info-lock);
+   return ret;
 }
 
 static int m5mols_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
@@ -578,6 +583,7 @@ static int m5mols_set_fmt(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh,
if (!sfmt)
return 0;
 
+   mutex_lock(info-lock);
 
format-code = m5mols_default_ffmt[type].code;
format-colorspace = V4L2_COLORSPACE_JPEG;
@@ -589,7 +595,8 @@ static int m5mols_set_fmt(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh,
info-res_type = type;
}
 
-   return 0;
+   mutex_unlock(info-lock);
+   return ret;
 }
 
 static int m5mols_enum_mbus_code(struct v4l2_subdev *sd,
@@ -661,20 +668,25 @@ static int m5mols_start_monitor(struct m5mols_info *info)
 static int m5mols_s_stream(struct v4l2_subdev *sd, int enable)
 {
struct m5mols_info *info = to_m5mols(sd);
-   u32 code = info-ffmt[info-res_type].code;
+   u32 code;
+   int ret;
 
-   if (enable) {
-   int ret = -EINVAL;
+   mutex_lock(info-lock);
+   code = info-ffmt[info-res_type].code;
 
+   if (enable) {
if (is_code(code, M5MOLS_RESTYPE_MONITOR))
ret = m5mols_start_monitor(info);
if (is_code(code, M5MOLS_RESTYPE_CAPTURE))
ret = m5mols_start_capture(info);
-
-   return ret;
+   else
+   ret = -EINVAL;
+   } else {
+   ret = m5mols_set_mode(info, REG_PARAMETER);
}
 
-   return m5mols_set_mode(info, REG_PARAMETER);
+   

Re: [PATCH V2] drm/exynos: Add match table for drm platform device

2012-09-21 Thread Srinivas KANDAGATLA
On 21/09/12 19:37, Leela Krishna Amudala wrote:
 This patch is a part of moving the driver to support DT style probing
 of exynos drm device. The compatible name should match with the
 entry in the dtsi file.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index d070719..495be89 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -294,12 +294,23 @@ static int exynos_drm_platform_remove(struct 
 platform_device *pdev)
   return 0;
  }
  
 +#ifdef CONFIG_OF
 +static const struct of_device_id drm_device_dt_match[] = {
 + { .compatible = samsung,exynos-drm-device},
 + {},
 +};
 +MODULE_DEVICE_TABLE(of, drm_device_dt_match);
 +#else
 +#define drm_device_dt_match NULL
 +#endif

No need of else here as you are using of_match_ptr.

 +
  static struct platform_driver exynos_drm_platform_driver = {
   .probe  = exynos_drm_platform_probe,
   .remove = __devexit_p(exynos_drm_platform_remove),
   .driver = {
   .owner  = THIS_MODULE,
   .name   = exynos-drm,
 + .of_match_table = of_match_ptr(drm_device_dt_match),
   },
  };
  

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


[RFC PATCH 0/6] pinctrl: samsung: Convert the driver to use per-bank GPIO and interrupt specifiers

2012-09-21 Thread Tomasz Figa
This is a continuation of work focused on improving the pinctrl-samsung
driver.

First part on which this one depends:
[RFC 0/6] pinctrl: samsung: Remove static platform-specific data
http://article.gmane.org/gmane.linux.kernel.samsung-soc/12759

This series 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.

Any comments are welcome.

To do:
  - Bindings documentation
  - Per-bank interrupt specifiers for wake-up interrupts
  - Configuration of pins used as wake-up interrupts to EINT function

Tomasz Figa (6):
  pinctrl: samsung: Hold OF node of pin bank in bank struct
  pinctrl: samsung: Hold pointer to driver data in bank struct
  pinctrl: exynos: Use one IRQ domain per pin bank
  pinctrl: samsung: Do not pass gpio_chip to pin_to_reg_bank
  pinctrl: samsung: Use one GPIO chip per pin bank
  ARM: dts: exynos4210: Update pin bank nodes to reflect per-bank GPIO
chips and IRQ domains

 arch/arm/boot/dts/exynos4210-pinctrl-banks.dtsi |  72 ++
 arch/arm/boot/dts/exynos4210.dtsi   |   4 -
 drivers/pinctrl/pinctrl-exynos.c| 118 +
 drivers/pinctrl/pinctrl-exynos.h|  12 --
 drivers/pinctrl/pinctrl-samsung.c   | 168 ++--
 drivers/pinctrl/pinctrl-samsung.h   |  18 ++-
 6 files changed, 220 insertions(+), 172 deletions(-)

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


[RFC PATCH 3/6] pinctrl: exynos: Use one IRQ domain per pin bank

2012-09-21 Thread Tomasz Figa
Instead of registering one IRQ domain for all pin banks of a pin
controller, this patch implements registration of per-bank domains.

At a cost of a little memory overhead (~2.5KiB for all GPIO interrupts
of Exynos4x12) it simplifies driver code and device tree sources,
because GPIO interrupts can be now specified per banks.

Example:
device {
/* ... */
interrupt-parent = gpa1;
interrupts = 3 0;
/* ... */
};

Signed-off-by: Tomasz Figa t.f...@samsung.com
---
 drivers/pinctrl/pinctrl-exynos.c  | 118 +++---
 drivers/pinctrl/pinctrl-exynos.h  |  12 
 drivers/pinctrl/pinctrl-samsung.c |   4 +-
 drivers/pinctrl/pinctrl-samsung.h |   5 +-
 4 files changed, 37 insertions(+), 102 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-exynos.c b/drivers/pinctrl/pinctrl-exynos.c
index 340bfc2..2f8427f 100644
--- a/drivers/pinctrl/pinctrl-exynos.c
+++ b/drivers/pinctrl/pinctrl-exynos.c
@@ -40,46 +40,46 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
 
 static void exynos_gpio_irq_unmask(struct irq_data *irqd)
 {
-   struct samsung_pinctrl_drv_data *d = irqd-domain-host_data;
-   struct exynos_geint_data *edata = irq_data_get_irq_handler_data(irqd);
-   unsigned long reg_mask = d-ctrl-geint_mask + edata-eint_offset;
+   struct samsung_pin_bank *bank = irq_data_get_irq_handler_data(irqd);
+   struct samsung_pinctrl_drv_data *d = irq_data_get_irq_chip_data(irqd);
+   unsigned long reg_mask = d-ctrl-geint_mask + bank-eint_offset;
unsigned long mask;
 
mask = readl(d-virt_base + reg_mask);
-   mask = ~(1  edata-pin);
+   mask = ~(1  irqd-hwirq);
writel(mask, d-virt_base + reg_mask);
 }
 
 static void exynos_gpio_irq_mask(struct irq_data *irqd)
 {
-   struct samsung_pinctrl_drv_data *d = irqd-domain-host_data;
-   struct exynos_geint_data *edata = irq_data_get_irq_handler_data(irqd);
-   unsigned long reg_mask = d-ctrl-geint_mask + edata-eint_offset;
+   struct samsung_pin_bank *bank = irq_data_get_irq_handler_data(irqd);
+   struct samsung_pinctrl_drv_data *d = irq_data_get_irq_chip_data(irqd);
+   unsigned long reg_mask = d-ctrl-geint_mask + bank-eint_offset;
unsigned long mask;
 
mask = readl(d-virt_base + reg_mask);
-   mask |= 1  edata-pin;
+   mask |= 1  irqd-hwirq;
writel(mask, d-virt_base + reg_mask);
 }
 
 static void exynos_gpio_irq_ack(struct irq_data *irqd)
 {
-   struct samsung_pinctrl_drv_data *d = irqd-domain-host_data;
-   struct exynos_geint_data *edata = irq_data_get_irq_handler_data(irqd);
-   unsigned long reg_pend = d-ctrl-geint_pend + edata-eint_offset;
+   struct samsung_pin_bank *bank = irq_data_get_irq_handler_data(irqd);
+   struct samsung_pinctrl_drv_data *d = irq_data_get_irq_chip_data(irqd);
+   unsigned long reg_pend = d-ctrl-geint_pend + bank-eint_offset;
 
-   writel(1  edata-pin, d-virt_base + reg_pend);
+   writel(1  irqd-hwirq, d-virt_base + reg_pend);
 }
 
 static int exynos_gpio_irq_set_type(struct irq_data *irqd, unsigned int type)
 {
-   struct samsung_pinctrl_drv_data *d = irqd-domain-host_data;
+   struct samsung_pin_bank *bank = irq_data_get_irq_handler_data(irqd);
+   struct samsung_pinctrl_drv_data *d = irq_data_get_irq_chip_data(irqd);
struct samsung_pin_ctrl *ctrl = d-ctrl;
-   struct exynos_geint_data *edata = irq_data_get_irq_handler_data(irqd);
-   struct samsung_pin_bank *bank = edata-bank;
-   unsigned int shift = EXYNOS_EINT_CON_LEN * edata-pin;
+   unsigned int pin = irqd-hwirq;
+   unsigned int shift = EXYNOS_EINT_CON_LEN * pin;
unsigned int con, trig_type;
-   unsigned long reg_con = ctrl-geint_con + edata-eint_offset;
+   unsigned long reg_con = ctrl-geint_con + bank-eint_offset;
unsigned int mask;
 
switch (type) {
@@ -114,7 +114,7 @@ static int exynos_gpio_irq_set_type(struct irq_data *irqd, 
unsigned int type)
writel(con, d-virt_base + reg_con);
 
reg_con = bank-pctl_offset;
-   shift = edata-pin * bank-func_width;
+   shift = pin * bank-func_width;
mask = (1  bank-func_width) - 1;
 
con = readl(d-virt_base + reg_con);
@@ -136,81 +136,24 @@ static struct irq_chip exynos_gpio_irq_chip = {
.irq_set_type   = exynos_gpio_irq_set_type,
 };
 
-/*
- * given a controller-local external gpio interrupt number, prepare the handler
- * data for it.
- */
-static struct exynos_geint_data *exynos_get_eint_data(irq_hw_number_t hw,
-   struct samsung_pinctrl_drv_data *d)
-{
-   struct samsung_pin_bank *bank = d-ctrl-pin_banks;
-   struct exynos_geint_data *eint_data;
-   unsigned int nr_banks = d-ctrl-nr_banks, idx;
-   unsigned int irq_base = 0;
-
-   if (hw = d-ctrl-nr_gint) {
-   dev_err(d-dev, unsupported ext-gpio interrupt\n);
-   

[RFC PATCH 5/6] pinctrl: samsung: Use one GPIO chip per pin bank

2012-09-21 Thread Tomasz Figa
This patch modifies the pinctrl-samsung driver to register one GPIO chip
per pin bank, instead of a single chip for all pin banks of the
controller.

It simplifies GPIO accesses a lot (constant time instead of looping
through the list of banks to find the right one) and should have a good
effect on performance of any bit-banging driver.

In addition it allows to reference GPIO pins by a phandle to the bank
node and a local pin offset inside of the bank (similar to previous
gpiolib driver), which is more clear and readable than using indices
relative to the whole pin controller.

Example:
device {
/* ... */
gpios = gpk0 4 0;
/* ... */
};

Signed-off-by: Tomasz Figa t.f...@samsung.com
---
 drivers/pinctrl/pinctrl-samsung.c | 118 +++---
 drivers/pinctrl/pinctrl-samsung.h |   8 ++-
 2 files changed, 78 insertions(+), 48 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-samsung.c 
b/drivers/pinctrl/pinctrl-samsung.c
index eadcef7..426a13d 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -51,6 +51,11 @@ DEFINE_SPINLOCK(init_lock);
 
 static unsigned int pin_base = 0;
 
+static inline struct samsung_pin_bank *gc_to_pin_bank(struct gpio_chip *gc)
+{
+   return container_of(gc, struct samsung_pin_bank, gpio_chip);
+}
+
 /* check if the selector is a valid pin group selector */
 static int samsung_get_group_count(struct pinctrl_dev *pctldev)
 {
@@ -336,9 +341,12 @@ static int samsung_pinmux_gpio_set_direction(struct 
pinctrl_dev *pctldev,
void __iomem *reg;
u32 data, pin_offset, mask, shift;
 
+   bank = gc_to_pin_bank(range-gc);
drvdata = pinctrl_dev_get_drvdata(pctldev);
 
-   pin_to_reg_bank(drvdata, offset, reg, pin_offset, bank);
+   pin_offset = offset - bank-pin_base;
+   reg = drvdata-virt_base + bank-pctl_offset;
+
mask = (1  bank-func_width) - 1;
shift = pin_offset * bank-func_width;
 
@@ -469,17 +477,16 @@ static struct pinconf_ops samsung_pinconf_ops = {
 /* gpiolib gpio_set callback function */
 static void samsung_gpio_set(struct gpio_chip *gc, unsigned offset, int value)
 {
+   struct samsung_pin_bank *bank = gc_to_pin_bank(gc);
void __iomem *reg;
-   u32 pin_offset, data;
-   struct samsung_pinctrl_drv_data *drvdata;
+   u32 data;
 
-   drvdata = dev_get_drvdata(gc-dev);
+   reg = bank-drvdata-virt_base + bank-pctl_offset;
 
-   pin_to_reg_bank(drvdata, offset, reg, pin_offset, NULL);
data = readl(reg + DAT_REG);
-   data = ~(1  pin_offset);
+   data = ~(1  offset);
if (value)
-   data |= 1  pin_offset;
+   data |= 1  offset;
writel(data, reg + DAT_REG);
 }
 
@@ -487,14 +494,13 @@ static void samsung_gpio_set(struct gpio_chip *gc, 
unsigned offset, int value)
 static int samsung_gpio_get(struct gpio_chip *gc, unsigned offset)
 {
void __iomem *reg;
-   u32 pin_offset, data;
-   struct samsung_pinctrl_drv_data *drvdata;
+   u32 data;
+   struct samsung_pin_bank *bank = gc_to_pin_bank(gc);
 
-   drvdata = dev_get_drvdata(gc-dev);
+   reg = bank-drvdata-virt_base + bank-pctl_offset;
 
-   pin_to_reg_bank(drvdata, offset, reg, pin_offset, NULL);
data = readl(reg + DAT_REG);
-   data = pin_offset;
+   data = offset;
data = 1;
return data;
 }
@@ -726,12 +732,15 @@ static int __init samsung_pinctrl_register(struct 
platform_device *pdev,
return -EINVAL;
}
 
-   drvdata-grange.name = samsung-pctrl-gpio-range;
-   drvdata-grange.id = 0;
-   drvdata-grange.base = drvdata-ctrl-base;
-   drvdata-grange.npins = drvdata-ctrl-nr_pins;
-   drvdata-grange.gc = drvdata-gc;
-   pinctrl_add_gpio_range(drvdata-pctl_dev, drvdata-grange);
+   for (bank = 0; bank  drvdata-ctrl-nr_banks; ++bank) {
+   pin_bank = drvdata-ctrl-pin_banks[bank];
+   pin_bank-grange.name = pin_bank-name;
+   pin_bank-grange.id = bank;
+   pin_bank-grange.base = pin_bank-gpio_chip.base;
+   pin_bank-grange.npins = pin_bank-gpio_chip.ngpio;
+   pin_bank-grange.gc = pin_bank-gpio_chip;
+   pinctrl_add_gpio_range(drvdata-pctl_dev, pin_bank-grange);
+   }
 
ret = samsung_pinctrl_parse_dt(pdev, drvdata);
if (ret) {
@@ -742,49 +751,68 @@ static int __init samsung_pinctrl_register(struct 
platform_device *pdev,
return 0;
 }
 
+static const struct gpio_chip samsung_gpiolib_chip = {
+   .set = samsung_gpio_set,
+   .get = samsung_gpio_get,
+   .direction_input = samsung_gpio_direction_input,
+   .direction_output = samsung_gpio_direction_output,
+   .owner = THIS_MODULE,
+};
+
 /* register the gpiolib interface with the gpiolib subsystem */
 static int __init samsung_gpiolib_register(struct platform_device *pdev,

[RFC PATCH 6/6] ARM: dts: exynos4210: Update pin bank nodes to reflect per-bank GPIO chips and IRQ domains

2012-09-21 Thread Tomasz Figa
This patch modifies device tree sources of Exynos4210 to match the
changes done to pinctrl-samsung driver.

Signed-off-by: Tomasz Figa t.f...@samsung.com
---
 arch/arm/boot/dts/exynos4210-pinctrl-banks.dtsi | 72 +
 arch/arm/boot/dts/exynos4210.dtsi   |  4 --
 2 files changed, 72 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-pinctrl-banks.dtsi 
b/arch/arm/boot/dts/exynos4210-pinctrl-banks.dtsi
index cac7f71..c3795e4 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl-banks.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl-banks.dtsi
@@ -24,9 +24,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x00;
+   #interrupt-cells = 2;
};
 
gpa1: pin-bank@1 {
@@ -39,9 +41,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x04;
+   #interrupt-cells = 2;
};
 
gpb: pin-bank@2 {
@@ -54,9 +58,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x08;
+   #interrupt-cells = 2;
};
 
gpc0: pin-bank@3 {
@@ -69,9 +75,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x0C;
+   #interrupt-cells = 2;
};
 
gpc1: pin-bank@4 {
@@ -84,9 +92,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x10;
+   #interrupt-cells = 2;
};
 
gpd0: pin-bank@5 {
@@ -99,9 +109,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x14;
+   #interrupt-cells = 2;
};
 
gpd1: pin-bank@6 {
@@ -114,9 +126,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x18;
+   #interrupt-cells = 2;
};
 
gpe0: pin-bank@7 {
@@ -129,9 +143,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x1C;
+   #interrupt-cells = 2;
};
 
gpe1: pin-bank@8 {
@@ -144,9 +160,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x20;
+   #interrupt-cells = 2;
};
 
gpe2: pin-bank@9 {
@@ -159,9 +177,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 0x24;
+   #interrupt-cells = 2;
};
 
gpe3: pin-bank@10 {
@@ -174,9 +194,11 @@
samsung,drv-width = 2;
samsung,conpdn-width = 2;
samsung,pudpdn-width = 2;
+   #gpio-cells = 2;
 
interrupt-controller;
samsung,eint-offset = 

[RFC PATCH 1/6] pinctrl: samsung: Hold OF node of pin bank in bank struct

2012-09-21 Thread Tomasz Figa
The node pointer will be used in extensions added by patches that will
follow.

Signed-off-by: Tomasz Figa t.f...@samsung.com
---
 drivers/pinctrl/pinctrl-samsung.c | 2 ++
 drivers/pinctrl/pinctrl-samsung.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-samsung.c 
b/drivers/pinctrl/pinctrl-samsung.c
index 03bf743..846b277 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -825,6 +825,8 @@ static int samsung_pinctrl_parse_dt_bank(struct 
samsung_pin_bank *bank,
if (!ret)
bank-pudpdn_width = val;
 
+   bank-of_node = np;
+
if (!of_find_property(np, interrupt-controller, NULL)) {
bank-eint_type = EINT_TYPE_NONE;
return 0;
diff --git a/drivers/pinctrl/pinctrl-samsung.h 
b/drivers/pinctrl/pinctrl-samsung.h
index 72303f1..b7b74cc 100644
--- a/drivers/pinctrl/pinctrl-samsung.h
+++ b/drivers/pinctrl/pinctrl-samsung.h
@@ -111,6 +111,7 @@ struct samsung_pinctrl_drv_data;
  * @eint_type: type of the external interrupt supported by the bank.
  * @irq_base: starting controller local irq number of the bank.
  * @name: name to be prefixed for each pin in this pin bank.
+ * @of_node: node of pin bank in device tree
  */
 struct samsung_pin_bank {
u32 pctl_offset;
@@ -125,6 +126,8 @@ struct samsung_pin_bank {
u32 eint_offset;
u32 irq_base;
const char  *name;
+
+   struct device_node *of_node;
 };
 
 /**
-- 
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 V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Stephen Warren
On 09/21/2012 01:22 AM, Inki Dae wrote:
 2012/9/21 Stephen Warren swar...@wwwdotorg.org:
 On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
 This patch adds device tree based discovery support for exynos DRM-FIMD
 driver which includes driver modification to handle platform data in
 both the cases with DT and non-DT, Also adds the documentation for bindings.

 diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
 b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
 ...
 + - 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.

 Should this not use the new videomode timings that are under discussion at:

 http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html

 
 ok, I agree with you. then the videomode helper is going to be merged
 to mainline(3.6)? if so, this patch should be reworked based on the
 videomode helper.

I think the videomode helpers would be merged for 3.7 at the very
earliest; 3.6 is cooked already. Given there are still some comments on
the binding, perhaps it won't happen until 3.8, but it'd be best to ask
on that thread so that people more directly involved with the status can
answer.
--
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: [RFC 0/6] pinctrl: samsung: Remove static platform-specific data

2012-09-21 Thread Stephen Warren
On 09/20/2012 02:53 AM, Tomasz Figa wrote:
 This RFC series is a work on replacing static platform-specific data in
 pinctrl-samsung driver with data dynamically parsed from device tree.

Hmm. I tend to think this is exactly the opposite of the correct
direction; you end up wasting a whole ton of time during the boot
process parsing data out of the device tree only to end up with exactly
the same tables that you would have just put into the kernel anyway. Is
it really likely that future SoCs will change information such as the
width of the pullup/pulldown bitfield, but not change anything else
that's not already in this binding. If that isn't the case, the binding
won't be complete enough to describe any new features on future SoCs anyway.

 It aims at reducing the SoC-specific part of the driver and thus the
 amount of modifications to driver sources when adding support for next
 SoCs (like Exynos4x12).
 
 Furthermore, moving definitions of pin banks to device tree will allow
 to simplify GPIO and GEINT specification to a format similar to used
 previously by gpiolib-based implementation, using a phandle to the bank
 and pin index inside the bank, e.g.
   gpios = gpa1 4 0;
   interrupt-parent = gpa1;
   interrupts = 4 0;

I don't think those two are correlated; the GPIO specifier format could
just as easily be bank pin irrespective of whether the pinctrl driver
contains SoC-specific tables or not.

 Any comments are welcome.
 
 TODO:
  - bindings documentation

That's unfortunate; it would be the most interesting part to review. I
guess I'll try to work out the binding from the examples in patch 6.
--
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: [RFC 6/6] ARM: dts: exynos4210: Add platform-specific descriptions for pin controllers

2012-09-21 Thread Stephen Warren
On 09/20/2012 02:53 AM, Tomasz Figa wrote:
 The patch pinctrl: samsung: Parse pin banks from DT introduced
 platform-specific data parsing from DT.
 
 This patch adds all necessary nodes and properties to exynos4210 device
 tree sources.

 +++ b/arch/arm/boot/dts/exynos4210-pinctrl-banks.dtsi

 +/ {
 + pinctrl@1140 {
 + gpa0: pin-bank@0 {

If you're going to put a unit address (@0)into the DT node name, the
node should have a reg property containing the same value, and the
parent node should have #address-cells and #size-cells properties.

However, I believe you can actually get unique node names without using
a unit address; instead name the nodes after the object they represent,
so e.g. s/pin-bank@0/gpa0/ above.

 + gpio-controller;

You need a #gpio-cells property too.

 + samsung,pctl-offset = 0x000;
 + samsung,pin-bank = gpa0;
 + samsung,pin-count = 8;
 + samsung,func-width = 4;
 + samsung,pud-width = 2;
 + samsung,drv-width = 2;
 + samsung,conpdn-width = 2;
 + samsung,pudpdn-width = 2;

The properties above represent the width of the fields. Must all fields
always be packed together into say the LSB of the registers? What if
there are gaps between the fields in a future SoC variant, or the order
of the fields in the register changes? I think you want to add either a
samsung,func-bit/samsung,func-position property for each of the fields,
or change from samsung,func-width=4 to samsung,field-mask=0xf. IIRC,
the generic pinctrl binding used a mask for this purpose.

What if a future SoC variant adds more fields to the register? At that
point, you'd need to edit the driver anyway in order to define a new DT
property to represent the new field. Perhaps instead of having an
explicit named property per field in the register, you want a simple
list of fields:

samsung,pin-property-names = func, pud, drv, conpdn, pudpdn;
samsung,pin-propert-masks = 0xf 0x30 0xc0 0x300 0xc00;

That would allow a completely arbitrary number of fields and layouts to
be described.

I wonder if for absolute generality you want a samsung,pin-stride
property to represent the difference in register address per pin. I
assume that's hard-coded as 4 right now.

 + interrupt-controller;

You need a #interrupt-cells property too.

 + gpd0: pin-bank@5 {
 + gpio-controller;
 + samsung,pctl-offset = 0x0A0;

I think hex number are usually lower-case in DT, but I may be
extrapolating a generality from a limited set of examples.

 + gpy5: pin-bank@19{

Missing a space before the { there.

 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index ecbc707..0e93717 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -59,6 +59,10 @@
   reg = 0x1140 0x1000;
   interrupts = 0 47 0;
   interrupt-controller;
 + samsung,geint-con = 0x700;
 + samsung,geint-mask = 0x900;
 + samsung,geint-pend = 0xA00;
 + samsung,svc = 0xB08;

I assume those new properties represent register addresses within the
block. If not, I don't understand what they are.

It's unclear to me why those properties aren't all part of
exynos4210-pinctrl-banks.dtsi. Do you really have multiple SoCs where
the register addresses for the pinctrl registers are the same (hence can
be in a shared exynos4210-pinctrl-banks.dtsi), yet the register
addresses for the geint registers are different (hence must be in
non-shared exynos4210.dtsi)?

Do these properties interact with samsung,eint-offset at all? Oh,
perhaps these properties are defining a top-level interrupt controller
that aggregates all the banks together, whereas samsung,eint-offset is
per-bank?
--
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: [RFC 0/6] pinctrl: samsung: Remove static platform-specific data

2012-09-21 Thread Tomasz Figa
Hi Stephen,

Thanks for your comments.

On Friday 21 of September 2012 12:40:35 Stephen Warren wrote:
 On 09/20/2012 02:53 AM, Tomasz Figa wrote:
  This RFC series is a work on replacing static platform-specific data in
  pinctrl-samsung driver with data dynamically parsed from device tree.
 
 Hmm. I tend to think this is exactly the opposite of the correct
 direction; you end up wasting a whole ton of time during the boot
 process parsing data out of the device tree only to end up with exactly
 the same tables that you would have just put into the kernel anyway.

Yes, I'm aware that parsing all those information from device tree won't be 
free. I have even considering simplifying the binding to something like

samsung,pin-bank = offset count func pud drv conpdn pudpdn;

listing widths of fields in fixed order, with some fields allowed to be 
zero, meaning that given bank doesn't support this control. It would 
simplify the parsing to just iterating over a table under a single 
property. What do you think?

I have decided to post the original variant to get some comments earlier, 
as I already had all the rest of patches based on it.

 Is
 it really likely that future SoCs will change information such as the
 width of the pullup/pulldown bitfield, but not change anything else
 that's not already in this binding. If that isn't the case, the binding
 won't be complete enough to describe any new features on future SoCs
 anyway.

Looking at the history of Samsung SoCs and specifics of this subsystem, 
there isn't much likely to change other than the bindings already account 
for (and the binding represents whatever the driver accounts for).

  It aims at reducing the SoC-specific part of the driver and thus the
  amount of modifications to driver sources when adding support for next
  SoCs (like Exynos4x12).
  
  Furthermore, moving definitions of pin banks to device tree will allow
  to simplify GPIO and GEINT specification to a format similar to used
  previously by gpiolib-based implementation, using a phandle to the bank
  and pin index inside the bank, e.g.
  
  gpios = gpa1 4 0;
  interrupt-parent = gpa1;
  interrupts = 4 0;
 
 I don't think those two are correlated; the GPIO specifier format could
 just as easily be bank pin irrespective of whether the pinctrl driver
 contains SoC-specific tables or not.

Correct me if I'm wrong, but each bank needs to have its own subnode to be 
able to address pins like this. That was the starting point of the whole 
series and the idea that if all the banks (which are SoC-specific) have to 
be defined anyway, maybe it wouldn't be too bad to put all the SoC-specific 
parameters there too.

  Any comments are welcome.
  
  TODO:
   - bindings documentation
 
 That's unfortunate; it would be the most interesting part to review. I
 guess I'll try to work out the binding from the examples in patch 6.

Sorry about that. I thought the examples would be sufficient. Still, I was 
focused at getting comments about the idea of moving such data to DT in 
general, not the bindings, which are most likely to change, in particular.

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


Re: [RFC 6/6] ARM: dts: exynos4210: Add platform-specific descriptions for pin controllers

2012-09-21 Thread Tomasz Figa
Hi Stephen,

Thanks for your comments.

On Friday 21 of September 2012 12:56:41 Stephen Warren wrote:
 On 09/20/2012 02:53 AM, Tomasz Figa wrote:
  The patch pinctrl: samsung: Parse pin banks from DT introduced
  platform-specific data parsing from DT.
  
  This patch adds all necessary nodes and properties to exynos4210 device
  tree sources.
  
  +++ b/arch/arm/boot/dts/exynos4210-pinctrl-banks.dtsi
  
  +/ {
  +   pinctrl@1140 {
  +   gpa0: pin-bank@0 {
 
 If you're going to put a unit address (@0)into the DT node name, the
 node should have a reg property containing the same value, and the
 parent node should have #address-cells and #size-cells properties.
 
 However, I believe you can actually get unique node names without using
 a unit address; instead name the nodes after the object they represent,
 so e.g. s/pin-bank@0/gpa0/ above.

Good point. I wasn't aware of the relation between unit address and reg 
property. I thought it was just for readability.

 
  +   gpio-controller;
 
 You need a #gpio-cells property too.

It will be added in further patches that add per-bank GPIO addressing.

In this RFC, this property is just used to distinguish pin bank nodes from 
pin group nodes.
 
  +   samsung,pctl-offset = 0x000;
  +   samsung,pin-bank = gpa0;
  +   samsung,pin-count = 8;
  +   samsung,func-width = 4;
  +   samsung,pud-width = 2;
  +   samsung,drv-width = 2;
  +   samsung,conpdn-width = 2;
  +   samsung,pudpdn-width = 2;
 
 The properties above represent the width of the fields. Must all fields
 always be packed together into say the LSB of the registers? What if
 there are gaps between the fields in a future SoC variant, or the order
 of the fields in the register changes? I think you want to add either a
 samsung,func-bit/samsung,func-position property for each of the fields,
 or change from samsung,func-width=4 to samsung,field-mask=0xf. IIRC,
 the generic pinctrl binding used a mask for this purpose.
 
 What if a future SoC variant adds more fields to the register? At that
 point, you'd need to edit the driver anyway in order to define a new DT
 property to represent the new field. Perhaps instead of having an
 explicit named property per field in the register, you want a simple
 list of fields:
 
 samsung,pin-property-names = func, pud, drv, conpdn, pudpdn;
 samsung,pin-propert-masks = 0xf 0x30 0xc0 0x300 0xc00;
 
 That would allow a completely arbitrary number of fields and layouts to
 be described.
 
 I wonder if for absolute generality you want a samsung,pin-stride
 property to represent the difference in register address per pin. I
 assume that's hard-coded as 4 right now.

Hmm, considering so many different possible changes, maybe a more 
conservative solution would be better, like reducing the amount of 
information held in DT to bank type, e.g.

samsung,bank-type = exynos4;

or maybe

compatible = samsung,exynos4-pin-bank*;

and then define supported bank types in the driver. SoC-specific data would 
remain in DT, i.e. pctl-offset, pin-bank, pin-count, eint-offset, etc.

  +   interrupt-controller;
 You need a #interrupt-cells property too.

Just as with gpio-controller before, in this RFC this is just a mark to 
distinguish banks with interrupts from banks without interrupts.

Further patches will allow to use it properly (and will add #interrupt-
cells property too).

  +   gpd0: pin-bank@5 {
  +   gpio-controller;
  +   samsung,pctl-offset = 0x0A0;
 
 I think hex number are usually lower-case in DT, but I may be
 extrapolating a generality from a limited set of examples.

I have seen both variants, with upper-case being more popular across 
Samsung's dts files and so I have chosen to use it. (Personally I prefer 
lower-case, though, if it does matter.)

  +   gpy5: pin-bank@19{
 
 Missing a space before the { there.

Right.

  diff --git a/arch/arm/boot/dts/exynos4210.dtsi
  b/arch/arm/boot/dts/exynos4210.dtsi index ecbc707..0e93717 100644
  --- a/arch/arm/boot/dts/exynos4210.dtsi
  +++ b/arch/arm/boot/dts/exynos4210.dtsi
  @@ -59,6 +59,10 @@
  
  reg = 0x1140 0x1000;
  interrupts = 0 47 0;
  interrupt-controller;
  
  +   samsung,geint-con = 0x700;
  +   samsung,geint-mask = 0x900;
  +   samsung,geint-pend = 0xA00;
  +   samsung,svc = 0xB08;
 
 I assume those new properties represent register addresses within the
 block. If not, I don't understand what they are.

Yes, they do.

 It's unclear to me why those properties aren't all part of
 exynos4210-pinctrl-banks.dtsi. Do you really have multiple SoCs where
 the register addresses for the pinctrl registers are the same (hence can
 be in a shared exynos4210-pinctrl-banks.dtsi), yet the register
 addresses for the geint registers 

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

2012-09-21 Thread Olof Johansson
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?

 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


Re: [PATCH 2/5] ARM: Add interface for registering and calling firmware-specific operations

2012-09-21 Thread Olof Johansson
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.


-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


Re: [GIT PULL 4/4] Samsung DT for v3.7

2012-09-21 Thread Kukjin Kim

On 09/21/12 15:26, Kukjin Kim wrote:

Hi Arnd, Olof

This is for updating Samsung DT for v3.7.

But now this makes many conflicts with pinctrl dt because of moving file
so I'm sorting them out to avoid useless conflicts.

I'll re-send this soon again.
This is jut for your information.

I created following branch which is merged on top of Samsung pinctrl and 
board branches already are pulled into arm-soc.


This includes moving common exynos4 dt for supporting other exynos4 
SoCs easily and adding exynos43210-trats board support and some updates.


Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
next/dt-samsung-new


If any problems, please kindly let me know.

Thanks.

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


The following changes since commit
5698bd757d55b1bb87edd1a9744ab09c142abfc2:

Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)

are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next/dt-samsung

Kukjin Kim (1):
ARM: dts: use uart2 for console on smdkv310 and smdk5250

Tomasz Figa (6):
ARM: dts: Move parts common to EXYNOS4 from exynos4210.dtsi to exynos4.dtsi
ARM: EXYNOS: Use exynos4 prefix instead of exynos4210 on exynos4-dt
ARM: dts: Assume status of all optional nodes as disabled for exynos4
ARM: dts: Specify address and size cells for i2c controllers for EXYNOS4
ARM: EXYNOS: Add OF compatibility lookups for EXYNOS4 i2c adapters
ARM: dts: Add basic dts file for Samsung Trats board

Tushar Behera (1):
ARM: dts: Enable on-board keys as wakeup source for exynos4210-origen

arch/arm/boot/dts/exynos4.dtsi | 248 +
arch/arm/boot/dts/exynos4210-origen.dts | 63 +---
arch/arm/boot/dts/exynos4210-smdkv310.dts | 54 +--
arch/arm/boot/dts/exynos4210-trats.dts | 237 +++
arch/arm/boot/dts/exynos4210.dtsi | 181 +-
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
arch/arm/mach-exynos/Makefile.boot | 2 +-
arch/arm/mach-exynos/mach-exynos4-dt.c | 32 +++-
8 files changed, 523 insertions(+), 296 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4.dtsi
create mode 100644 arch/arm/boot/dts/exynos4210-trats.dts

--
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 Olof Johansson
On Fri, Sep 21, 2012 at 05:39:41PM +0900, Kyungmin Park wrote:
 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?

Hi,

There are still a few open questions to resolve on this before I think it
can be merged. And it doesn't make much sense to merge the infrastructure
without at least the first user of it.


-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


Re: [GIT PULL 1/4] Samsung fixes for v3.7

2012-09-21 Thread Olof Johansson
On Fri, Sep 21, 2012 at 03:21:37PM +0900, Kukjin Kim wrote:
 Hi Arnd, Olof
 
 This is non-critical Samsung fixes for v3.7.
 
 If any problems, please kindly let me know.
 
 Thanks.
 
 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.
 
 The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:
 
   Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)
 
 are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
 v3.7-samsung-fixes-1

Thanks, pulled into next/fixes-non-critical.


-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


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: [GIT PULL 2/4] Samsung pinctrl-2 for v3.7

2012-09-21 Thread Olof Johansson
On Fri, Sep 21, 2012 at 03:22:18PM +0900, Kukjin Kim wrote:
 Hi Arnd, Olof
 
 This is for fix typo and correct fucntion for Samsung pinctrl and
 since this has a dependency with previous pinctrl branch I created
 this based on that.
 
 If any problems, please kindly let me know.
 
 Thanks.
 
 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.
 
 The following changes since commit 011527b45f8e3092e1f3192e5aea94187a6ca269:
 
   ARM: EXYNOS: Enable pinctrl driver support for EXYNOS4 device tree
 enabled platform (2012-09-07 06:14:26 +0900)
 
 are available in the git repository at:

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

Thanks, I just pulled this into the existing samsung/pinctrl since it was
a fast-forward there.


-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