[PATCH] ARM: S3C24XX: Fix Section mismatch

2012-03-07 Thread Kukjin Kim
Fixes following:

WARNING: arch/arm/mach-s3c24xx/built-in.o(.text+0x4464): Section mismatch in 
reference
from the function usb_simtec_init() to the (unknown reference) 
.init.data:(unknown)
The function usb_simtec_init() references
the (unknown reference) __initdata (unknown).
This is often because usb_simtec_init lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-s3c24xx/built-in.o(.data+0xf44): Section mismatch in 
reference
from the variable s3c2416_irq_interface to the function 
.init.text:s3c2416_irq_add()
The variable s3c2416_irq_interface references
the function __init s3c2416_irq_add()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: arch/arm/mach-s3c24xx/built-in.o(.data+0x1b80): Section mismatch in 
reference
from the variable s3c2443_irq_interface to the function 
.init.text:s3c2443_irq_add()
The variable s3c2443_irq_interface references
the function __init s3c2443_irq_add()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

Signed-off-by: Kukjin Kim kgene@samsung.com
---
 arch/arm/mach-s3c24xx/irq-s3c2416.c |2 +-
 arch/arm/mach-s3c24xx/irq-s3c2443.c |2 +-
 arch/arm/mach-s3c24xx/simtec-usb.c  |2 +-
 arch/arm/mach-s3c24xx/simtec.h  |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/irq-s3c2416.c 
b/arch/arm/mach-s3c24xx/irq-s3c2416.c
index b8a5836..59b7632 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c2416.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c2416.c
@@ -310,7 +310,7 @@ static int __init s3c2416_irq_add(struct device *dev)
return 0;
 }
 
-static struct subsys_interface s3c2416_irq_interface = {
+static struct subsys_interface s3c2416_irq_interface __initdata = {
.name   = s3c2416_irq,
.subsys = s3c2416_subsys,
.add_dev= s3c2416_irq_add,
diff --git a/arch/arm/mach-s3c24xx/irq-s3c2443.c 
b/arch/arm/mach-s3c24xx/irq-s3c2443.c
index 35e4ff2..439f186 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c2443.c
@@ -265,7 +265,7 @@ static int __init s3c2443_irq_add(struct device *dev)
return 0;
 }
 
-static struct subsys_interface s3c2443_irq_interface = {
+static struct subsys_interface s3c2443_irq_interface __initdata = {
.name   = s3c2443_irq,
.subsys = s3c2443_subsys,
.add_dev= s3c2443_irq_add,
diff --git a/arch/arm/mach-s3c24xx/simtec-usb.c 
b/arch/arm/mach-s3c24xx/simtec-usb.c
index d91c1a7..c303d1b 100644
--- a/arch/arm/mach-s3c24xx/simtec-usb.c
+++ b/arch/arm/mach-s3c24xx/simtec-usb.c
@@ -104,7 +104,7 @@ static struct s3c2410_hcd_info usb_simtec_info __initdata = 
{
 };
 
 
-int usb_simtec_init(void)
+int __init usb_simtec_init(void)
 {
int ret;
 
diff --git a/arch/arm/mach-s3c24xx/simtec.h b/arch/arm/mach-s3c24xx/simtec.h
index ae8f4f9..f514cd5 100644
--- a/arch/arm/mach-s3c24xx/simtec.h
+++ b/arch/arm/mach-s3c24xx/simtec.h
@@ -15,7 +15,7 @@ struct s3c24xx_audio_simtec_pdata;
 
 extern void nor_simtec_init(void);
 
-extern int usb_simtec_init(void);
+extern int __init usb_simtec_init(void);
 
 extern int simtec_audio_add(const char *codec_name, bool has_lr_routing,
struct s3c24xx_audio_simtec_pdata *pdata);
-- 
1.7.4.4

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


Re: [PATCH 0/4] Use clock functions also for clk_h and clk_p on S3C2443/2416

2012-03-07 Thread Kukjin Kim

On 03/03/12 13:14, Heiko Stübner wrote:

This series modifies the clock init in common-s3c2443 to use the
struct clk operations also for clk_p and clk_h whose values were until
now set statically in s3c24xx_setup_clocks - a function more suited to
the earlier S3C-SoCs.

In the end it makes the code (hopefully) easier to read, as strange
divisions through register values get replaced by simply clk_get_rate
calls.

To apply on top of the current s3c24xx consolidation.


OK, applied.

Thanks.

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


Re: [PATCH 0/3] S3C24XX: Enable DMA on S3C2416 by sharing S3C2443-DMA

2012-03-07 Thread Kukjin Kim

On 03/04/12 09:42, Heiko Stübner wrote:

The S3C2416/2450 contains the same DMA register layout as the S3C2443.
Therefore it can simply share this dma selection definition.

As we use the S3C2443_DMA the S3C2416_DMA is no longer necessary. The
third patch removes this remnant of the S3C24XX merge.

The whole series was made on top of the recent S3C24XX merge.


Good, applied.

Thanks.

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


Re: [PATCH 0/4] S3C24XX: Another move of code to the new mach directory

2012-03-07 Thread Kukjin Kim

On 03/06/12 01:57, Heiko Stübner wrote:

This series contains the easy moves of common code for the SMDKs,
Simtec boards and device setup from plat-s3c24xx to mach-s3c24xx.

It also contains an extra patch to keep the Simtec code more together.

Changes to the Kconfig and Makefile will probably conflict with the
S3C2416-SPI series posted sunday, but this is ok, as the SPI series
will probably have to wait for 3.5 anyway and can be redone then.


OK, I agree so applied this whole series.

Thanks.

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


Re: [PATCH] ARM: S3C24XX: Fix Section mismatch

2012-03-07 Thread Russell King - ARM Linux
On Wed, Mar 07, 2012 at 02:36:52AM -0800, Kukjin Kim wrote:
 WARNING: arch/arm/mach-s3c24xx/built-in.o(.data+0xf44): Section mismatch in 
 reference
 from the variable s3c2416_irq_interface to the function 
 .init.text:s3c2416_irq_add()
 The variable s3c2416_irq_interface references
 the function __init s3c2416_irq_add()
 If the reference is valid then annotate the
 variable with __init* or __refdata (see linux/init.h) or name the variable:
 *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
 
 WARNING: arch/arm/mach-s3c24xx/built-in.o(.data+0x1b80): Section mismatch in 
 reference
 from the variable s3c2443_irq_interface to the function 
 .init.text:s3c2443_irq_add()
 The variable s3c2443_irq_interface references
 the function __init s3c2443_irq_add()
 If the reference is valid then annotate the
 variable with __init* or __refdata (see linux/init.h) or name the variable:
 *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

 diff --git a/arch/arm/mach-s3c24xx/irq-s3c2416.c 
 b/arch/arm/mach-s3c24xx/irq-s3c2416.c
 index b8a5836..59b7632 100644
 --- a/arch/arm/mach-s3c24xx/irq-s3c2416.c
 +++ b/arch/arm/mach-s3c24xx/irq-s3c2416.c
 @@ -310,7 +310,7 @@ static int __init s3c2416_irq_add(struct device *dev)
   return 0;
  }
  
 -static struct subsys_interface s3c2416_irq_interface = {
 +static struct subsys_interface s3c2416_irq_interface __initdata = {
   .name   = s3c2416_irq,
   .subsys = s3c2416_subsys,
   .add_dev= s3c2416_irq_add,
 diff --git a/arch/arm/mach-s3c24xx/irq-s3c2443.c 
 b/arch/arm/mach-s3c24xx/irq-s3c2443.c
 index 35e4ff2..439f186 100644
 --- a/arch/arm/mach-s3c24xx/irq-s3c2443.c
 +++ b/arch/arm/mach-s3c24xx/irq-s3c2443.c
 @@ -265,7 +265,7 @@ static int __init s3c2443_irq_add(struct device *dev)
   return 0;
  }
  
 -static struct subsys_interface s3c2443_irq_interface = {
 +static struct subsys_interface s3c2443_irq_interface __initdata = {
   .name   = s3c2443_irq,
   .subsys = s3c2443_subsys,
   .add_dev= s3c2443_irq_add,

You register these structures with some other bit of code.  That other
bit of code adds these structures to a list. You then mark them as
__initdata, which means they get freed and the memory reused.  That
corrupts the list beneath the other code.

So, clearly, both of these are wrong.
--
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] fix to use static declarations for samsung stuff

2012-03-07 Thread Kukjin Kim

On 02/10/12 04:55, Kukjin Kim wrote:

Hi Russell, Arnd and Olof,

Please pull following branch which is including fix to use static
declarations for samsung stuff.
  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next/cleanup-use-static

I'm not sure it can be sent to upstream for v3.3 but if so, would be better.


Hi Arnd, Olof,

I can't see this series in arm-soc yet. If missed, please pull from:
 http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
next/cleanup-use-static


As a note, I rebased it on top of arm-soc/depends/rmk/for-armsoc because 
this touches same points(dma declaration part).


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

  Merge tag 'v3.3-rc2' into depends/rmk/for-armsoc (2012-02-07 15:05:20 
-0800)


are available in the git repository at:


http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
next/cleanup-use-static


Kukjin Kim (8):
  ARM: EXYNOS: use static declaration when it is not used in other 
files
  ARM: S3C24XX: use static declaration when it is not used in other 
files
  ARM: S3C64XX: use static declaration when it is not used in other 
files
  ARM: S5P64X0: use static declaration when it is not used in other 
files
  ARM: S5PC100: use static declaration when it is not used in other 
files
  ARM: S5PV210: use static declaration when it is not used in other 
files
  ARM: SAMSUNG: use static declaration when it is not used in other 
files

  Merge branch 'topic/cleanup-use-static' into next/cleanup-use-static

 arch/arm/mach-exynos/clock-exynos4210.c|2 +-
 arch/arm/mach-exynos/clock-exynos4212.c|2 +-
 arch/arm/mach-exynos/clock.c   |2 +-
 arch/arm/mach-exynos/common.c  |2 +-
 arch/arm/mach-exynos/dma.c |   16 +-
 arch/arm/mach-exynos/mach-origen.c |2 +-
 arch/arm/mach-exynos/mach-universal_c210.c |2 +-
 arch/arm/mach-s3c2410/mach-h1940.c |   12 
 arch/arm/mach-s3c2416/clock.c  |6 
 arch/arm/mach-s3c2416/mach-smdk2416.c  |8 +++---
 arch/arm/mach-s3c2440/mach-gta02.c |4 +-
 arch/arm/mach-s3c2440/mach-rx1950.c|   12 
 arch/arm/mach-s3c64xx/common.c |2 +-
 arch/arm/mach-s3c64xx/common.h |2 -
 arch/arm/mach-s3c64xx/irq-pm.c |2 +-
 arch/arm/mach-s5p64x0/clock.c  |   11 ---
 arch/arm/mach-s5p64x0/dma.c|   12 
 arch/arm/mach-s5p64x0/include/mach/s5p64x0-clock.h |7 -
 arch/arm/mach-s5pc100/clock.c  |   28 
++--

 arch/arm/mach-s5pc100/dma.c|   16 +-
 arch/arm/mach-s5pv210/dma.c|   16 +-
 arch/arm/mach-s5pv210/mach-goni.c  |2 +-
 arch/arm/mach-s5pv210/mach-smdkv210.c  |2 +-
 arch/arm/plat-s3c24xx/s3c2443-clock.c  |2 +-
 arch/arm/plat-s5p/irq-eint.c   |2 +-
 arch/arm/plat-s5p/irq-gpioint.c|2 +-
 arch/arm/plat-samsung/devs.c   |   13 +
 arch/arm/plat-samsung/dma-ops.c|2 +-
 28 files changed, 83 insertions(+), 108 deletions(-)


As a note, conflicts have been occurred when merge
arm-soc/depends/rmk/for-armsoc.
Following is my preferred resolution.

If any problems, please kindly let me know.

diff --cc arch/arm/mach-exynos/dma.c
index 8dec3db,91370de..000
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@@ -74,23 -74,10 +74,10 @@@ static struct dma_pl330_platdata exynos
.peri_id = pdma0_peri,
   };

- static struct amba_device exynos4_device_pdma0 = {
-   .dev = {
-   .init_name = dma-pl330.0,
-   .dma_mask =dma_dmamask,
-   .coherent_dma_mask = DMA_BIT_MASK(32),
-   .platform_data =exynos4_pdma0_pdata,
-   },
-   .res = {
-   .start = EXYNOS4_PA_PDMA0,
-   .end = EXYNOS4_PA_PDMA0 + SZ_4K,
-   .flags = IORESOURCE_MEM,
-   },
-   .irq = {IRQ_PDMA0, NO_IRQ},
-   .periphid = 0x00041330,
- };
  -AMBA_AHB_DEVICE(exynos4_pdma0, dma-pl330.0, 0x00041330,
EXYNOS4_PA_PDMA0,
  - {IRQ_PDMA0},exynos4_pdma0_pdata);
++static AMBA_AHB_DEVICE(exynos4_pdma0, dma-pl330.0, 0x00041330,
++  EXYNOS4_PA_PDMA0, {IRQ_PDMA0},exynos4_pdma0_pdata);

  -u8 pdma1_peri[] = {
  +static u8 pdma1_peri[] = {
DMACH_PCM0_RX,
DMACH_PCM0_TX,
DMACH_PCM1_RX,
@@@ -123,21 -110,8 +110,8 @@@ static struct 

Re: [PATCH v2 2/3] gpio/samsung: add support GPIOlib for EXYNOS5250

2012-03-07 Thread Kukjin Kim

On 02/15/12 13:37, Kukjin Kim wrote:

From: Sangsu Parksangsu4u.p...@samsung.com

This patch adds gpio_chips for EXYNOS5250 and replaces
exynos4_xxx() with exynos_xxx() and variables to support
exynos4 and exynos5 together.
In addition, use ioreamp() for base address of gpios.

Signed-off-by: Sangsu Parksangsu4u.p...@samsung.com
Cc: Grant Likelygrant.lik...@secretlab.ca


Hi Grant,

How about upstreaming this via samsung tree when sending EXYNOS5 stuff, 
I think, gpio-samsung needs still cleanup though? If any comments, 
please kindly let me know.



Signed-off-by: Kukjin Kimkgene@samsung.com
---
  drivers/gpio/gpio-samsung.c |  439 +--
  1 files changed, 411 insertions(+), 28 deletions(-)


Thanks.

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


Re: [GIT PULL] fix to use static declarations for samsung stuff

2012-03-07 Thread Arnd Bergmann
On Wednesday 07 March 2012, Kukjin Kim wrote:
 im wrote:
  Hi Russell, Arnd and Olof,
 
  Please pull following branch which is including fix to use static
  declarations for samsung stuff.
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
  next/cleanup-use-static
 
  I'm not sure it can be sent to upstream for v3.3 but if so, would be better.
 
 Hi Arnd, Olof,
 
 I can't see this series in arm-soc yet. If missed, please pull from:
   http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
 next/cleanup-use-static
 
 As a note, I rebased it on top of arm-soc/depends/rmk/for-armsoc because 
 this touches same points(dma declaration part).
 
 If any problems, please kindly let me know.
 

Sorry, I must have missed this request, I can't remember seeing it before.
The patches all look good, Olof will take care of getting them in.

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


Re: [PATCH 1/6] ARM: S3C64XX: Add usb otg phy control

2012-03-07 Thread Kukjin Kim

On 02/10/12 10:26, Mark Brown wrote:

On Fri, Feb 10, 2012 at 11:35:41AM +0100, Lukasz Majewski wrote:

From: Joonyoung Shimjy0922.s...@samsung.com

This patch supports to control usb otg phy of S3C64XX. Currently, the
driver for usb otg controls usb otg phy but it can be removed by this
patch.


Acked-by: Mark Brownbroo...@opensource.wolfsonmicro.com


Applied, thanks.

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


Re: [PATCH] ARM: EXYNOS: Fix compilation error.

2012-03-07 Thread Kukjin Kim

On 03/06/12 22:09, Sachin Kamat wrote:

Commit 734b5bb7375 (Merge branch 'next/soc-exynos5250-arch-wip' into for-next)
on for-next branch of Kukjin's tree gives the following build errors:

arch/arm/mach-exynos/clock-exynos4.c:1328:2: error: ‘clk_sclk_mmc0’
undeclared here (not in a function)
arch/arm/mach-exynos/clock-exynos4.c:1329:2: error: ‘clk_sclk_mmc1’
undeclared here (not in a function)
arch/arm/mach-exynos/clock-exynos4.c:1330:2: error: ‘clk_sclk_mmc2’
undeclared here (not in a function)
arch/arm/mach-exynos/clock-exynos4.c:1331:2: error: ‘clk_sclk_mmc3’
undeclared here (not in a function)

This commit fixes the same.

Signed-off-by: Sachin Kamatsachin.ka...@linaro.org
---
  arch/arm/mach-exynos/clock-exynos4.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/clock-exynos4.c 
b/arch/arm/mach-exynos/clock-exynos4.c
index d72a1fe..bcb59e7 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -1325,10 +1325,10 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT(exynos4210-uart.1, 
clk_uart_baud0,exynos4_clk_sclk_uart1.clk),
CLKDEV_INIT(exynos4210-uart.2, 
clk_uart_baud0,exynos4_clk_sclk_uart2.clk),
CLKDEV_INIT(exynos4210-uart.3, 
clk_uart_baud0,exynos4_clk_sclk_uart3.clk),
-   CLKDEV_INIT(exynos4-sdhci.0, mmc_busclk.2,clk_sclk_mmc0.clk),
-   CLKDEV_INIT(exynos4-sdhci.1, mmc_busclk.2,clk_sclk_mmc1.clk),
-   CLKDEV_INIT(exynos4-sdhci.2, mmc_busclk.2,clk_sclk_mmc2.clk),
-   CLKDEV_INIT(exynos4-sdhci.3, mmc_busclk.2,clk_sclk_mmc3.clk),
+   CLKDEV_INIT(exynos4-sdhci.0, 
mmc_busclk.2,exynos4_clk_sclk_mmc0.clk),
+   CLKDEV_INIT(exynos4-sdhci.1, 
mmc_busclk.2,exynos4_clk_sclk_mmc1.clk),
+   CLKDEV_INIT(exynos4-sdhci.2, 
mmc_busclk.2,exynos4_clk_sclk_mmc2.clk),
+   CLKDEV_INIT(exynos4-sdhci.3, 
mmc_busclk.2,exynos4_clk_sclk_mmc3.clk),
CLKDEV_INIT(dma-pl330.0, apb_pclk,exynos4_clk_pdma0),
CLKDEV_INIT(dma-pl330.1, apb_pclk,exynos4_clk_pdma1),
CLKDEV_INIT(s3c64xx-spi.0, spi_busclk0,exynos4_clk_sclk_spi0.clk),


Yes, should be fixed. will apply.
Thanks.

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


Re: [PATCH v2 04/11] ARM: EXYNOS: add interrupt definitions for EXYNOS5250

2012-03-07 Thread Kukjin Kim

On 03/06/12 10:55, Olof Johansson wrote:

Hi,

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


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

If any updates, let you know.


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


Hi Olof,

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


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


Thanks.

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


Re: [PATCH] ARM: SAMSUNG: change the name from s3c-sdhci to exynos4-sdhci

2012-03-07 Thread Kukjin Kim

On 03/06/12 01:51, Kukjin Kim wrote:

On 03/05/12 18:29, Jaehoon Chung wrote:

Hi Kukjin.

Is it merged?

Best Regards,
Jaehoon Chung

On 02/24/2012 06:56 PM, Thomas Abraham wrote:


On 23 February 2012 11:18, Jaehoon Chungjh80.ch...@samsung.com wrote:

Thomas Arbrahams's patchset have changed the device name in sdhci-s3c.c
(mmc: sdhci-s3c: Rework platform data and add device tree support)
But didn't change the regulator_consumer name.
So maybe didn't initialize the mmc/sd card for exynos4.

This patch is fixed that (based-on linux-samsung for-next branch)

Signed-off-by: Jaehoon Chungjh80.ch...@samsung.com
Signed-off-by: kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c | 4 ++--
arch/arm/mach-exynos/mach-universal_c210.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index a6b9162..251dd7a 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -116,7 +116,7 @@ static struct s3c_sdhci_platdata
nuri_hsmmc0_data __initdata = {
};

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

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

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

static struct regulator_init_data mmc0_fixed_voltage_init_data = {


Reviewed-by: Thomas Abrahamthomas.abra...@linaro.org


Looks OK, will apply.



(Cc'ed Marek)

Hi Kyungmin, Marek and Jaehoon,

As you know, same patches have been submitted duplicated and this should 
be fixed. Which one would be better to send upstream?


Thanks.

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


RE: [PATCH] ARM: SAMSUNG: change the name from s3c-sdhci to exynos4-sdhci

2012-03-07 Thread Marek Szyprowski
Hello,

On Wednesday, March 07, 2012 2:20 PM Kukjin Kim wrote:

 On 03/06/12 01:51, Kukjin Kim wrote:
  On 03/05/12 18:29, Jaehoon Chung wrote:
  Hi Kukjin.
 
  Is it merged?
 
  Best Regards,
  Jaehoon Chung
 
  On 02/24/2012 06:56 PM, Thomas Abraham wrote:
 
  On 23 February 2012 11:18, Jaehoon Chungjh80.ch...@samsung.com wrote:
  Thomas Arbrahams's patchset have changed the device name in sdhci-s3c.c
  (mmc: sdhci-s3c: Rework platform data and add device tree support)
  But didn't change the regulator_consumer name.
  So maybe didn't initialize the mmc/sd card for exynos4.
 
  This patch is fixed that (based-on linux-samsung for-next branch)
 
  Signed-off-by: Jaehoon Chungjh80.ch...@samsung.com
  Signed-off-by: kyungmin Parkkyungmin.p...@samsung.com
  ---
  arch/arm/mach-exynos/mach-nuri.c | 4 ++--
  arch/arm/mach-exynos/mach-universal_c210.c | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)
 
  diff --git a/arch/arm/mach-exynos/mach-nuri.c
  b/arch/arm/mach-exynos/mach-nuri.c
  index a6b9162..251dd7a 100644
  --- a/arch/arm/mach-exynos/mach-nuri.c
  +++ b/arch/arm/mach-exynos/mach-nuri.c
  @@ -116,7 +116,7 @@ static struct s3c_sdhci_platdata
  nuri_hsmmc0_data __initdata = {
  };
 
  static struct regulator_consumer_supply emmc_supplies[] = {
  - REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
  + REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
  REGULATOR_SUPPLY(vmmc, dw_mmc),
  };
 
  @@ -415,7 +415,7 @@ static struct regulator_consumer_supply
  __initdata max8997_ldo12_[] = {
  REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
  };
  static struct regulator_consumer_supply __initdata max8997_ldo13_[] = {
  - REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
  + REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
  };
  static struct regulator_consumer_supply __initdata max8997_ldo14_[] = {
  REGULATOR_SUPPLY(inmotor, max8997-haptic),
  diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
  b/arch/arm/mach-exynos/mach-universal_c210.c
  index 6017a21..320cb1d 100644
  --- a/arch/arm/mach-exynos/mach-universal_c210.c
  +++ b/arch/arm/mach-exynos/mach-universal_c210.c
  @@ -749,7 +749,7 @@ static struct s3c_sdhci_platdata
  universal_hsmmc0_data __initdata = {
  };
 
  static struct regulator_consumer_supply mmc0_supplies[] = {
  - REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
  + REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
  };
 
  static struct regulator_init_data mmc0_fixed_voltage_init_data = {
 
  Reviewed-by: Thomas Abrahamthomas.abra...@linaro.org
 
  Looks OK, will apply.
 
 
 (Cc'ed Marek)
 
 Hi Kyungmin, Marek and Jaehoon,
 
 As you know, same patches have been submitted duplicated and this should
 be fixed. Which one would be better to send upstream?

For me it doesn't matter, I just need this fix to get merged, because otherwise
the Universal C210 and Nuri boards are dysfunctional. 

You can select the one prepared by Jaehoon if You like.

Best regards
-- 
Marek Szyprowski
Samsung Poland RD Center


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


Re: [PATCH v2 04/11] ARM: EXYNOS: add interrupt definitions for EXYNOS5250

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

 Hi,

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

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

 If any updates, let you know.


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

 Hi Olof,

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

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

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

Thank you,
Kyungmin Park


 Thanks.

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


Re: [PATCH] ARM: SAMSUNG: change the name from s3c-sdhci to exynos4-sdhci

2012-03-07 Thread Kukjin Kim

On 03/07/12 06:01, Marek Szyprowski wrote:

Hello,

On Wednesday, March 07, 2012 2:20 PM Kukjin Kim wrote:


On 03/06/12 01:51, Kukjin Kim wrote:

On 03/05/12 18:29, Jaehoon Chung wrote:

Hi Kukjin.

Is it merged?

Best Regards,
Jaehoon Chung

On 02/24/2012 06:56 PM, Thomas Abraham wrote:


On 23 February 2012 11:18, Jaehoon Chungjh80.ch...@samsung.com  wrote:

Thomas Arbrahams's patchset have changed the device name in sdhci-s3c.c
(mmc: sdhci-s3c: Rework platform data and add device tree support)
But didn't change the regulator_consumer name.
So maybe didn't initialize the mmc/sd card for exynos4.

This patch is fixed that (based-on linux-samsung for-next branch)

Signed-off-by: Jaehoon Chungjh80.ch...@samsung.com
Signed-off-by: kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c | 4 ++--
arch/arm/mach-exynos/mach-universal_c210.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index a6b9162..251dd7a 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -116,7 +116,7 @@ static struct s3c_sdhci_platdata
nuri_hsmmc0_data __initdata = {
};

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

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

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

static struct regulator_init_data mmc0_fixed_voltage_init_data = {


Reviewed-by: Thomas Abrahamthomas.abra...@linaro.org


Looks OK, will apply.



(Cc'ed Marek)

Hi Kyungmin, Marek and Jaehoon,

As you know, same patches have been submitted duplicated and this should
be fixed. Which one would be better to send upstream?


For me it doesn't matter, I just need this fix to get merged, because otherwise
the Universal C210 and Nuri boards are dysfunctional.

You can select the one prepared by Jaehoon if You like.


OK, thanks :)

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


RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper

2012-03-07 Thread Marek Szyprowski
Hello,

On Wednesday, March 07, 2012 12:22 AM Russell King - ARM Linux wrote:

 On Wed, Feb 29, 2012 at 04:04:22PM +0100, Marek Szyprowski wrote:
  +static int arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct 
  *vma,
  +   void *cpu_addr, dma_addr_t dma_addr, size_t size,
  +   struct dma_attrs *attrs)
  +{
  +   struct arm_vmregion *c;
  +
  +   vma-vm_page_prot = __get_dma_pgprot(attrs, vma-vm_page_prot);
  +   c = arm_vmregion_find(consistent_head, (unsigned long)cpu_addr);
 
 What protects this against other insertions/removals from the list?

arm_vmregion_* functions have their own spinlock.

(snipped)

  +   if (c) {
  +   struct page **pages = c-priv;
  +   __dma_free_remap(cpu_addr, size);
  +   __iommu_remove_mapping(dev, handle, size);
  +   __iommu_free_buffer(dev, pages, size);
  +   }
  +}
  +
  +/*
  + * Map a part of the scatter-gather list into contiguous io address space
  + */
  +static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
  + size_t size, dma_addr_t *handle,
  + enum dma_data_direction dir)
  +{
  +   struct dma_iommu_mapping *mapping = dev-archdata.mapping;
  +   dma_addr_t iova, iova_base;
  +   int ret = 0;
  +   unsigned int count;
  +   struct scatterlist *s;
  +
  +   size = PAGE_ALIGN(size);
  +   *handle = ARM_DMA_ERROR;
  +
  +   iova_base = iova = __alloc_iova(mapping, size);
  +   if (iova == ARM_DMA_ERROR)
  +   return -ENOMEM;
  +
  +   for (count = 0, s = sg; count  (size  PAGE_SHIFT); s = sg_next(s))
  +   {
  +   phys_addr_t phys = page_to_phys(sg_page(s));
  +   unsigned int len = PAGE_ALIGN(s-offset + s-length);
  +
  +   if (!arch_is_coherent())
  +   __dma_page_cpu_to_dev(sg_page(s), s-offset, s-length, 
  dir);
  +
  +   ret = iommu_map(mapping-domain, iova, phys, len, 0);
 
 Dealing with phys addresses on one part and pages + offset + length
 in a different part doesn't look like a good idea.  Why can't there
 be some consistency?

Well, I have no idea how to be more consistent here. scatter-lists operates on 
pages + offsets + length parameters. iommu api operates on the whole pages, but
they are referred with physical address. Right now I cannot change any of it, 
at least not it the near future.

Best regards
-- 
Marek Szyprowski
Samsung Poland RD Center


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


RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper

2012-03-07 Thread Marek Szyprowski
Hello,

On Wednesday, March 07, 2012 8:16 AM Hiroshi Doyu wrote:

 From: Hiroshi DOYU hd...@nvidia.com
 Subject: Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
 Date: Wed, 07 Mar 2012 08:37:06 +0200 (EET)
 Message-ID: 20120307.083706.2087121294965856946.hd...@nvidia.com
 
  From: Hiroshi DOYU hd...@nvidia.com
  Subject: Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
  Date: Wed, 07 Mar 2012 08:09:52 +0200 (EET)
  Message-ID: 20120307.080952.2152478004740487196.hd...@nvidia.com
 
   From: Krishna Reddy vdu...@nvidia.com
   Subject: RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
   Date: Tue, 6 Mar 2012 23:48:42 +0100
   Message-ID: 
   401e54ce964cd94bae1eb4a729c7087e3797011...@hqmail04.nvidia.com
  
  +struct dma_iommu_mapping *
  +arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, 
  size_t size,
  +int order)
  +{
  +   unsigned int count = (size  PAGE_SHIFT) - order;
  +   unsigned int bitmap_size = BITS_TO_LONGS(count) * 
  sizeof(long);
   
The count calculation doesn't seem correct. order is log2 number and
 size  PAGE_SHIFT is number of pages.
   
If size is passed as 64*4096(256KB) and order is 6(allocation 
granularity is 2^6
 pages=256KB),
 just 1 bit is enough to manage allocations.  So it should be 4 bytes 
or one long.
  
   Good catch!
  
But the calculation gives count = 64 - 6 = 58 and
Bitmap_size gets set to (58/(4*8)) * 4 = 8 bytes, which is incorrect.
  
   order isn't the order of size passed, which is minimal *page*
   allocation order which client decides whatever, just in case.
  
It should be as follows.
unsigned int count = 1  get_order(size) - order;
 
  To be precise, as below?
 
   unsigned int count = 1  (get_order(size) - order);
 
 This could be:
 
 From fd40740ef4bc4a3924fe1188ea6dd785be0fe859 Mon Sep 17 00:00:00 2001
 From: Hiroshi DOYU hd...@nvidia.com
 Date: Wed, 7 Mar 2012 08:14:38 +0200
 Subject: [PATCH 1/1] dma-mapping: Fix count calculation of iova space
 
 Fix count calculation of iova space.
 Pointed by Krishna Reddy vdu...@nvidia.com
 
 Signed-off-by: Hiroshi DOYU hd...@nvidia.com
 ---
  arch/arm/mm/dma-mapping.c |   11 +--
  1 files changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
 index 6c2f104..56f0af5 100644
 --- a/arch/arm/mm/dma-mapping.c
 +++ b/arch/arm/mm/dma-mapping.c
 @@ -1483,11 +1483,18 @@ struct dma_iommu_mapping *
  arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
int order)
  {
 - unsigned int count = (size  PAGE_SHIFT) - order;
 - unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
 + unsigned int n, count;
 + unsigned int bitmap_size;
   struct dma_iommu_mapping *mapping;
   int err = -ENOMEM;
 
 + n = get_order(size);
 + if (n  order)
 + return ERR_PTR(-EINVAL);
 +
 + count = 1  (n - order);
 + bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
 +
   mapping = kzalloc(sizeof(struct dma_iommu_mapping), GFP_KERNEL);
   if (!mapping)
   goto err;

Thanks again for finding another bug. I thought that I've checked that code more
than twice, but it looks that I've missed something again.

IMHO the size of virtual memory area doesn't need to be aligned to the power of
two, so I will simplify it to the following code:

unsigned int count = size  (PAGE_SHIFT + order);
unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);

if (!count)
return ERR_PTR(-EINVAL);

...

Best regards
-- 
Marek Szyprowski
Samsung Poland RD Center


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


Re: [PATCH v3 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file

2012-03-07 Thread Mark Brown
On Wed, Mar 07, 2012 at 12:03:31PM +0900, Jaehoon Chung wrote:
 On 03/07/2012 01:30 AM, Mark Brown wrote:

  The same IP is present and used with the same driver on other Samsung
  SoCs.

 I know that used with the same driver on other 
 Samsung-SoCs(S3C64XX/S3C24XX..etc)
 I just only used the interface in sdhci-pltfm.c. Nothing difference..
 Why do you think that will break the other SoC?

 Header file(/plat/regs-sdhci.h) also is only used in sdhci-s3c.c.
 And the least portion is moved into /linux/mmc/. 
 Then included linux/mmc/sdhci-s3c.h in plat/sdhci.h.

 What's difference? 
 If you can explain the more detail, i can understand.
 But sorry, now i didn't accept your opinion.

To be honest I didn't read the series, the diffstat looks so obviously
problematic as you're touching the setup-gpio- files for only a subset
of Samsung architectures - there's been quite regular issues with
updates for newer SoCs breaking support for s3c64xx.

I also notice that this will conflict with the series I've previously
posted for runtime PM support which would push us even further back from
being able to use the lower power WFI modes in mainline :(  Though
hopefully that'll be easier to fix.


signature.asc
Description: Digital signature


Re: [GIT PULL] fix to use static declarations for samsung stuff

2012-03-07 Thread Olof Johansson
On Wed, Mar 7, 2012 at 4:15 AM, Arnd Bergmann a...@arndb.de wrote:
 On Wednesday 07 March 2012, Kukjin Kim wrote:
 im wrote:
  Hi Russell, Arnd and Olof,
 
  Please pull following branch which is including fix to use static
  declarations for samsung stuff.
    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
  next/cleanup-use-static
 
  I'm not sure it can be sent to upstream for v3.3 but if so, would be 
  better.
 
 Hi Arnd, Olof,

 I can't see this series in arm-soc yet. If missed, please pull from:
   http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
 next/cleanup-use-static

 As a note, I rebased it on top of arm-soc/depends/rmk/for-armsoc because
 this touches same points(dma declaration part).

 If any problems, please kindly let me know.


 Sorry, I must have missed this request, I can't remember seeing it before.
 The patches all look good, Olof will take care of getting them in.

Yep, pulled now. Apologies for missing it earlier.


-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/6] ARM: SAMSUNG: Fix memory size for hsotg

2012-03-07 Thread Tushar Behera
On 03/01/2012 10:10 AM, Kukjin Kim wrote:
 Lukasz Majewski wrote:

 From: Joonyoung Shim jy0922.s...@samsung.com

 The device link core registers for hsotg is base + h ~ base +
 11000h.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 [Rebased on the newest git/kgene/linux-samsung #for-next]
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  arch/arm/plat-samsung/devs.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
 index 21168ea..7ca0875 100644
 --- a/arch/arm/plat-samsung/devs.c
 +++ b/arch/arm/plat-samsung/devs.c
 @@ -1436,7 +1436,7 @@ void __init s5p_ehci_set_platdata(struct
 s5p_ehci_platdata *pd)

  #ifdef CONFIG_S3C_DEV_USB_HSOTG
  static struct resource s3c_usb_hsotg_resources[] = {
 -[0] = DEFINE_RES_MEM(S3C_PA_USB_HSOTG, SZ_16K),
 +[0] = DEFINE_RES_MEM(S3C_PA_USB_HSOTG, SZ_128K),
  [1] = DEFINE_RES_IRQ(IRQ_OTG),

As defined in arch/arm/mach-exynos/include/mach/irqs.h, should the IRQ
resource be DEFINE_RES_IRQ(IRQ_USB_HSOTG)?

  };

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


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


Re: [PATCH v3 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file

2012-03-07 Thread Jaehoon Chung
Hi Mark.

On 03/08/2012 03:48 AM, Mark Brown wrote:

 On Wed, Mar 07, 2012 at 12:03:31PM +0900, Jaehoon Chung wrote:
 On 03/07/2012 01:30 AM, Mark Brown wrote:
 
 The same IP is present and used with the same driver on other Samsung
 SoCs.
 
 I know that used with the same driver on other 
 Samsung-SoCs(S3C64XX/S3C24XX..etc)
 I just only used the interface in sdhci-pltfm.c. Nothing difference..
 Why do you think that will break the other SoC?
 
 Header file(/plat/regs-sdhci.h) also is only used in sdhci-s3c.c.
 And the least portion is moved into /linux/mmc/. 
 Then included linux/mmc/sdhci-s3c.h in plat/sdhci.h.
 
 What's difference? 
 If you can explain the more detail, i can understand.
 But sorry, now i didn't accept your opinion.
 
 To be honest I didn't read the series, the diffstat looks so obviously
 problematic as you're touching the setup-gpio- files for only a subset
 of Samsung architectures - there's been quite regular issues with
 updates for newer SoCs breaking support for s3c64xx.

Is there problem that move the s3c_sdhci_platdata struct into linux/mmc/?
In setup-gpio- files, you can see that included regs-sdhci.h.
But defined macro in regs-sdhci.h only used in sdhci-s3c.c.
So i think no problem that removed #include plat/regs-sdhci.h. is it wrong?
Just touching the setup-gpio- files is problem?
If i have moved the defined as extern, it's problem.
But i didn't move them.

For example, When i want to add the second capability for sdhci-s3c,
need to change code in samsung-soc and mmc stack.
if one of both didn't be merged, it's conflict or should not be work fine.
(Now, in mmc-next tree, mmc for Samsung-SoC didn't work fine during long time.)
There are reason that move the s3c_sdhci_platdata into linux/mmc/.
Then we can work at only mmc-next repository for sdhci-s3c.c.

 
 I also notice that this will conflict with the series I've previously
 posted for runtime PM support which would push us even further back from
 being able to use the lower power WFI modes in mainline :(  Though
 hopefully that'll be easier to fix.

Right, it should be conflicted with your patch. but it will be fixed.
It's not big problem.

Thanks for your opinion.

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


Re: [PATCH v2 04/11] ARM: EXYNOS: add interrupt definitions for EXYNOS5250

2012-03-07 Thread Olof Johansson
Hi,

On Wed, Mar 7, 2012 at 5:12 AM, Kukjin Kim kgene@samsung.com wrote:

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

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

I suggest that you work on the code until it's in shape to go in. If
we pick it up half-finished it just causes extra churn.

We have been pushing back on v6/v7 additions that are not multi-board
and multi-soc within the same machine type. Not being able to build a
combined binary with exynos 4 and 5 support in one would be a step
backwards on that effort.

I'm not sure I understand the argument about drivers -- they should
mostly be possible to submit and get included without the core SoC
patches such that when those land, you'll have a fully functional
system.


-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