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

2012-09-22 Thread Olof Johansson
On Fri, Sep 21, 2012 at 03:22:43PM +0900, Kukjin Kim wrote:
 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
 

Pulled into next/soc.


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

[PATCH] serial: samsung: Add poll_get_char poll_put_char

2012-09-22 Thread Doug Anderson
From: Julien Pichon pichon@gmail.com

The following patch allows users to use KGDB over serial console on
board based on Samsung SOC. It has been tested on a board using
exynos5.

Signed-off-by: Julien Pichon pichon@gmail.com
Signed-off-by: Doug Anderson diand...@chromium.org
(dianders changed poll to return NO_POLL_CHAR, which appears to
fix 'help' in kgdb; also updated commit message)
---
This is pulled from an email on linux-samsung-soc@vger.kernel.org
from Feb 18, 2012. It's never landed anywhere. I've made a small modification
that make it so that kgdb's help doesn't crash.

See: http://comments.gmane.org/gmane.linux.kernel.samsung-soc/9477

 drivers/tty/serial/samsung.c |   47 ++
 1 files changed, 47 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 8eef114..7f04717 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -876,11 +876,24 @@ s3c24xx_serial_verify_port(struct uart_port *port, struct 
serial_struct *ser)
 
 static struct console s3c24xx_serial_console;
 
+static int __init s3c24xx_serial_console_init(void)
+{
+   register_console(s3c24xx_serial_console);
+   return 0;
+}
+console_initcall(s3c24xx_serial_console_init);
+
 #define S3C24XX_SERIAL_CONSOLE s3c24xx_serial_console
 #else
 #define S3C24XX_SERIAL_CONSOLE NULL
 #endif
 
+#ifdef CONFIG_CONSOLE_POLL
+static int s3c24xx_serial_get_poll_char(struct uart_port *port);
+static void s3c24xx_serial_put_poll_char(struct uart_port *port,
+unsigned char c);
+#endif
+
 static struct uart_ops s3c24xx_serial_ops = {
.pm = s3c24xx_serial_pm,
.tx_empty   = s3c24xx_serial_tx_empty,
@@ -899,6 +912,10 @@ static struct uart_ops s3c24xx_serial_ops = {
.request_port   = s3c24xx_serial_request_port,
.config_port= s3c24xx_serial_config_port,
.verify_port= s3c24xx_serial_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+   .poll_get_char = s3c24xx_serial_get_poll_char,
+   .poll_put_char = s3c24xx_serial_put_poll_char,
+#endif
 };
 
 static struct uart_driver s3c24xx_uart_drv = {
@@ -1316,6 +1333,36 @@ s3c24xx_serial_console_txrdy(struct uart_port *port, 
unsigned int ufcon)
return (utrstat  S3C2410_UTRSTAT_TXE) ? 1 : 0;
 }
 
+#ifdef CONFIG_CONSOLE_POLL
+/*
+ * Console polling routines for writing and reading from the uart while
+ * in an interrupt or debug context.
+ */
+
+static int s3c24xx_serial_get_poll_char(struct uart_port *port)
+{
+   struct s3c24xx_uart_port *ourport = to_ourport(port);
+   unsigned int ufstat;
+
+   ufstat = rd_regl(port, S3C2410_UFSTAT);
+   if (s3c24xx_serial_rx_fifocnt(ourport, ufstat) == 0)
+   return NO_POLL_CHAR;
+
+   return rd_regb(port, S3C2410_URXH);
+}
+
+static void s3c24xx_serial_put_poll_char(struct uart_port *port,
+   unsigned char c)
+{
+   unsigned int ufcon = rd_regl(cons_uart, S3C2410_UFCON);
+
+   while (!s3c24xx_serial_console_txrdy(port, ufcon))
+   cpu_relax();
+   wr_regb(cons_uart, S3C2410_UTXH, c);
+}
+
+#endif /* CONFIG_CONSOLE_POLL */
+
 static void
 s3c24xx_serial_console_putchar(struct uart_port *port, int ch)
 {
-- 
1.7.7.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


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

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


 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.


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


[PATCH v4] Add MFC device tree support

2012-09-22 Thread Arun Kumar K
This patch adds the device tree entries for MFC on Exynos5.
This is rebased to the linux-samsung for-next branch.

Changelog v4
- Addressed review comments from Karol Lewandowski
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/12703

Changelog v3
- Addressed review comments given by Sylwester Nawrocki
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12340.html

Changelog v2
- Use fdt functions to parse dtsi file for mfc memory info

Changelog v1
- Moved board specific DT information to different dtsi file
- Changed compatible name for the device
- Addressed other review comments

Arun Kumar K (1):
  ARM: EXYNOS: Add MFC device tree support

 .../devicetree/bindings/media/s5p-mfc.txt  |   27 ++
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |7 
 arch/arm/boot/dts/exynos5250.dtsi  |6 +++
 arch/arm/mach-exynos/Kconfig   |1 +
 arch/arm/mach-exynos/clock-exynos5.c   |2 +-
 arch/arm/mach-exynos/common.c  |   37 
 arch/arm/mach-exynos/common.h  |   10 +
 arch/arm/mach-exynos/mach-exynos5-dt.c |   16 
 8 files changed, 105 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt

--
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 v4] ARM: EXYNOS: Add MFC device tree support

2012-09-22 Thread Arun Kumar K
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.

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 .../devicetree/bindings/media/s5p-mfc.txt  |   27 ++
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |7 
 arch/arm/boot/dts/exynos5250.dtsi  |6 +++
 arch/arm/mach-exynos/Kconfig   |1 +
 arch/arm/mach-exynos/clock-exynos5.c   |2 +-
 arch/arm/mach-exynos/common.c  |   37 
 arch/arm/mach-exynos/common.h  |   10 +
 arch/arm/mach-exynos/mach-exynos5-dt.c |   16 
 8 files changed, 105 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
new file mode 100644
index 000..f95e775
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -0,0 +1,27 @@
+* Samsung Multi Format Codec (MFC)
+
+Multi Format Codec (MFC) is the IP present in Samsung SoCs which
+supports high resolution decoding and encoding functionalities.
+The MFC device driver is a v4l2 driver which can encode/decode
+video raw/elementary streams and has support for all popular
+video codecs.
+
+Required properties:
+  - compatible : value should be either one among the following
+   (a) samsung,mfc-v5 for MFC v5 present in Exynos4 SoCs
+   (b) samsung,mfc-v6 for MFC v6 present in Exynos5 SoCs
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : MFC interrupt number to the CPU.
+
+  - samsung,mfc-r : Base address of the first memory bank used by MFC
+   for DMA contiguous memory allocation.
+
+  - samsung,mfc-r-size : Size of the first memory bank.
+
+  - samsung,mfc-l : Base address of the second memory bank used by MFC
+   for DMA contiguous memory allocation.
+
+  - samsung,mfc-l-size : Size of the second memory bank.
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 8a5e348..99890ec 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -109,4 +109,11 @@
spi_2: spi@12d4 {
status = disabled;
};
+
+   codec@1100 {
+   samsung,mfc-r = 0x4300;
+   samsung,mfc-r-size = 8388608;
+   samsung,mfc-l = 0x5100;
+   samsung,mfc-l-size = 8388608;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index b55794b..d2ae4ff 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -62,6 +62,12 @@
interrupts = 0 42 0;
};
 
+   codec@1100 {
+   compatible = samsung,mfc-v6;
+   reg = 0x1100 0x1;
+   interrupts = 0 96 0;
+   };
+
rtc {
compatible = samsung,s3c6410-rtc;
reg = 0x101E 0x100;
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 4372075..a0677f6 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -64,6 +64,7 @@ config SOC_EXYNOS5250
select SAMSUNG_DMADEV
select S5P_PM if PM
select S5P_SLEEP if PM
+   select S5P_DEV_MFC
help
  Enable EXYNOS5250 SoC support
 
diff --git a/arch/arm/mach-exynos/clock-exynos5.c 
b/arch/arm/mach-exynos/clock-exynos5.c
index f3171c3..452316b 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -669,7 +669,7 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit= (1  25),
}, {
.name   = mfc,
-   .devname= s5p-mfc,
+   .devname= s5p-mfc-v6,
.enable = exynos5_clk_ip_mfc_ctrl,
.ctrlbit= (1  0),
}, {
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 715b690..90e484e 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -22,6 +22,7 @@
 #include linux/export.h
 #include linux/irqdomain.h
 #include linux/of_address.h
+#include linux/of_fdt.h
 
 #include asm/proc-fns.h
 #include asm/exception.h
@@ -1043,3 +1044,39 @@ static int __init exynos_init_irq_eint(void)
return 0;
 }
 arch_initcall(exynos_init_irq_eint);
+
+int exynos_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 (!data)
+   

Re: [PATCH] spi: s3c64xx: Don't free controller_data on non-dt platforms

2012-09-22 Thread Mark Brown
On Thu, Sep 13, 2012 at 04:31:30PM +0200, Sylwester Nawrocki wrote:
 When s3c64xx-spi is instantiated from device tree an instance of
 struct s3c64xx_spi_csinfo is dynamically allocated in the driver.

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