[PATCH] ARM: EXYNOS5: Fix kernel dump in AFTR idle mode

2013-04-29 Thread Inderpal Singh
The kernel crashes while resuming from AFTR idle mode. It happens
because L2 cache was not going into retention state.

This patch configures the USE_RETENTION bit of ARM_L2_OPTION register
so that it does not depend on MANUAL_L2RSTDISABLE_CONTROL of
ARM_COMMON_OPTION register for L2RSTDISABLE signal.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---

Tested on arndale board on arm-soc next/soc branch.

 arch/arm/mach-exynos/include/mach/regs-pmu.h |1 +
 arch/arm/mach-exynos/pmu.c   |5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h 
b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 3f30aa1..57344b7 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -344,6 +344,7 @@
 #define EXYNOS5_FSYS_ARM_OPTION
S5P_PMUREG(0x2208)
 #define EXYNOS5_ISP_ARM_OPTION 
S5P_PMUREG(0x2288)
 #define EXYNOS5_ARM_COMMON_OPTION  
S5P_PMUREG(0x2408)
+#define EXYNOS5_ARM_L2_OPTION  
S5P_PMUREG(0x2608)
 #define EXYNOS5_TOP_PWR_OPTION 
S5P_PMUREG(0x2C48)
 #define EXYNOS5_TOP_PWR_SYSMEM_OPTION  
S5P_PMUREG(0x2CC8)
 #define EXYNOS5_JPEG_MEM_OPTION
S5P_PMUREG(0x2F48)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index daebc1a..97d6885 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -228,6 +228,7 @@ static struct exynos_pmu_conf exynos5250_pmu_config[] = {
{ EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
{ EXYNOS5_ARM_COMMON_SYS_PWR_REG,   { 0x0, 0x0, 0x2} },
{ EXYNOS5_ARM_L2_SYS_PWR_REG,   { 0x3, 0x3, 0x3} },
+   { EXYNOS5_ARM_L2_OPTION,{ 0x10, 0x10, 0x0 } },
{ EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
{ EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
{ EXYNOS5_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
@@ -353,11 +354,9 @@ static void exynos5_init_pmu(void)
 
/*
 * SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
-* MANUAL_L2RSTDISABLE_CONTROL_BITFIELD Enable
 */
tmp = __raw_readl(EXYNOS5_ARM_COMMON_OPTION);
-   tmp |= (EXYNOS5_MANUAL_L2RSTDISABLE_CONTROL |
-   EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN);
+   tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
__raw_writel(tmp, EXYNOS5_ARM_COMMON_OPTION);
 
/*
-- 
1.7.9.5

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


Re: exynos4210 not booting

2013-03-16 Thread Inderpal Singh
Hi Daniel,

On 16 March 2013 12:51, Padma Venkat padma@gmail.com wrote:
 Hi,

 On Fri, Mar 15, 2013 at 10:01 PM, Daniel Lezcano
 daniel.lezc...@linaro.org wrote:

 Using the exynos4_defconfig and compiling the kernel from the samsung
 git tree at 3.9-rc1, I am stuck.

 Does anyone have any idea ?

 Thanks !

   -- Daniel

 

 U-Boot 2013.01.-rc1 (Dec 08 2012 - 12:15:17) for ORIGEN

 CPU:Exynos4210@1000MHz

 Board: ORIGEN
 DRAM:  1 GiB
 WARNING: Caches not enabled
 MMC:   SAMSUNG SDHCI: 0
 In:serial
 Out:   serial
 Err:   serial
 Hit any key to stop autoboot:  0
 reading uImage
 1385264 bytes read
 reading uInitrd
 3780878 bytes read
 reading board.dtb
 16717 bytes read
 ## Booting kernel from Legacy Image at 40007000 ...
Image Name:   Linux-3.9.0-rc1
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:1385200 Bytes = 1.3 MiB
Load Address: 40008000
Entry Point:  40008000
Verifying Checksum ... OK
 ## Loading init Ramdisk from Legacy Image at 4200 ...
Image Name:   initramfs
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:3780814 Bytes = 3.6 MiB
Load Address: 
Entry Point:  
Verifying Checksum ... OK
 ## Flattened Device Tree blob at 41f0
Booting using the fdt blob at 0x41f0
Loading Kernel Image ... OK
 OK
Using Device Tree in place at 41f0, end 41f0714c

 Starting kernel ...

 Can you please try with below patches?

 This is required for non-DT case and it is not yet merged.
 https://patchwork.kernel.org/patch/2218321/

 For DT case below patch is required and this got merged in kgene tree.
 https://patchwork.kernel.org/patch/2210621/


Also check CONFIG_S3C_LOWLEVEL_UART_PORT, it needs to be 2 for origen.

Hope it helps.

Thanks,
Inder

 Thanks
 Padma

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

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

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
 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: SMDKV210 support issue in kernel 3.8 (dma-pl330 and HDMI failed)

2013-02-27 Thread Inderpal Singh
On 27 February 2013 02:52, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
 On 02/22/2013 01:00 PM, Lonsn wrote:

 Hi,
 I have tested the kernel 3.8 with a SMDKV210 like board. But I failed
 with dma-pl330 and HDMI driver.
 For dma-pl330, kernel print:
 dma-pl330 dma-pl330.0: PERIPH_ID 0x0, PCELL_ID 0x0 !
 dma-pl330: probe of dma-pl330.0 failed with error -22
 dma-pl330 dma-pl330.1: PERIPH_ID 0x0, PCELL_ID 0x0 !
 dma-pl330: probe of dma-pl330.1 failed with error -22


 Maybe there is some issue with the PL330 DMA controller clocks and the
 read values are all 0 because the clocks are disabled ?

 It seems arch/arm/mach-s5pv210/clock.c might be missing apb_pclk clock
 supply names, which I suspect may be required after commits:

 commit 7c71b8eb268ee38235f7e924d943ea9d90e59469
 Author: Inderpal Singh inderpal.si...@linaro.org
 Date:   Fri Sep 7 12:14:48 2012 +0530

 DMA: PL330: Remove redundant runtime_suspend/resume functions

 The driver's  runtime_suspend/resume functions just disable/enable
 the clock which is already being managed at AMBA bus level
 runtime_suspend/resume functions.

 Hence, remove the driver's runtime_suspend/resume functions.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 Tested-by: Chander Kashyap chander.kash...@linaro.org
 Signed-off-by: Vinod Koul vinod.k...@linux.intel.com

 commit faf6fbc6f2ca3b34bf464a8bb079a998e571957c
 Author: Inderpal Singh inderpal.si...@linaro.org
 Date:   Fri Sep 7 12:14:47 2012 +0530

 DMA: PL330: Remove controller clock enable/disable

 The controller clock is being enabled/disabled in AMBA bus
 infrastructre in probe/remove functions. Hence, its not required
 at driver level probe/remove.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 Tested-by: Chander Kashyap chander.kash...@linaro.org
 Signed-off-by: Vinod Koul vinod.k...@linux.intel.com

 I have added people who made related changes at Cc, hopefully they
 can provide some help in debugging this.


The mentioned patches just removed the redundant clock enable/disable
from the driver as clock is already being managed at amba bus level in
the same code path. As per my understanding the issue should come even
without these patches.

@Lonsn: Can you please test without these patches?

Thanks,
Inder

 Please try the following change:

 8
 diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
 index fcdf52d..87c7d3f 100644
 --- a/arch/arm/mach-s5pv210/clock.c
 +++ b/arch/arm/mach-s5pv210/clock.c
 @@ -214,11 +214,6 @@ static struct clk clk_pcmcdclk2 = {
 .name   = pcmcdclk,
  };

 -static struct clk dummy_apb_pclk = {
 -   .name   = apb_pclk,
 -   .id = -1,
 -};
 -
  static struct clk *clkset_vpllsrc_list[] = {
 [0] = clk_fin_vpll,
 [1] = clk_sclk_hdmi27m,
 @@ -1333,6 +1328,8 @@ static struct clk_lookup s5pv210_clk_lookup[] = {
 CLKDEV_INIT(NULL, spi_busclk0, clk_p),
 CLKDEV_INIT(s5pv210-spi.0, spi_busclk1, clk_sclk_spi0.clk),
 CLKDEV_INIT(s5pv210-spi.1, spi_busclk1, clk_sclk_spi1.clk),
 +   CLKDEV_INIT(dma-pl330.0, apb_pclk, init_clocks_off[0]),
 +   CLKDEV_INIT(dma-pl330.1, apb_pclk, init_clocks_off[1]),
  };

  void __init s5pv210_register_clocks(void)
 @@ -1361,6 +1358,5 @@ void __init s5pv210_register_clocks(void)
 for (ptr = 0; ptr  ARRAY_SIZE(clk_cdev); ptr++)
 s3c_disable_clocks(clk_cdev[ptr], 1);

 -   s3c24xx_register_clock(dummy_apb_pclk);
 s3c_pwmclk_init();
  }
 8

 If it works then we could make some cleaner patch.


 For HDMI driver,
 I have added the following HDMI related code to
 arch/arm/mach-s5pv210/mach-smdkv210.c:
 /* I2C module and id for HDMIPHY */
 static struct i2c_board_info hdmiphy_info = {
 I2C_BOARD_INFO(hdmiphy-s5pv210, 0x38),
 };

 i2c_register_board_info(2, smdkv210_i2c_devs2,
 ARRAY_SIZE(smdkv210_i2c_devs2));

 s5p_i2c_hdmiphy_set_platdata(NULL);
 s5p_hdmi_set_platdata(hdmiphy_info, NULL, 0);

 s3c_ide_set_platdata(smdkv210_ide_pdata);

 then kernel print:
 s5p-hdmi s5pv210-hdmi: hdmiphy adapter request failed
 s5p-hdmi s5pv210-hdmi: probe failed
 Samsung TV Mixer driver, (c) 2010-2011 Samsung Electronics Co., Ltd.

 s5p-mixer s5p-mixer: probe start
 s5p-mixer s5p-mixer: resources acquired
 s5p-mixer s5p-mixer: module s5p-hdmi provides no subdev!
 s5p-mixer s5p-mixer: module s5p-sdo provides no subdev!
 s5p-mixer s5p-mixer: failed to register any output
 s5p-mixer s5p-mixer: probe failed

 Can anybody help me on how to config the HDMI output function in linux
 kernel 3.8? I mainly want to do video hardware decode using s5pv210 MFC
 and then display with HDMI.


 For video playback (video post-processing) you might also need at least one
 FIMC device. Please refer to arch/arm/mach-goni.c for an example on how to
 add related devices to your board. You don't need the camera stuff, just
 add

[PATCH v2] arm: plat-samsung: check processor type before cache restoration in resume

2013-02-26 Thread Inderpal Singh
Only cortex-a9 based samsung platforms have l2x0 cache controller. Hence check
the same before restoring the cache in resume.

This is needed for single kernel image.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
changes in v2:
- check processor midr instead of checking all soc ids as 
suggested by Kukjin

 arch/arm/mach-exynos/common.c   |4 
 arch/arm/plat-samsung/include/plat/pm.h |1 +
 arch/arm/plat-samsung/s5p-sleep.S   |   10 ++
 3 files changed, 15 insertions(+)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index c4b2071..5585325 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -31,6 +31,7 @@
 #include asm/mach/map.h
 #include asm/mach/irq.h
 #include asm/cacheflush.h
+#include asm/cputype.h
 
 #include mach/regs-irq.h
 #include mach/regs-pmu.h
@@ -53,6 +54,7 @@
 #include common.h
 #define L2_AUX_VAL 0x7C470001
 #define L2_AUX_MASK 0xC200
+#define CPU_MASK   0xff00
 
 static const char name_exynos4210[] = EXYNOS4210;
 static const char name_exynos4212[] = EXYNOS4212;
@@ -716,6 +718,8 @@ static int __init exynos4_l2x0_cache_init(void)
if (soc_is_exynos5250() || soc_is_exynos5440())
return 0;
 
+   cpu_midr = read_cpuid_id()  CPU_MASK;
+
ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
if (!ret) {
l2x0_regs_phys = virt_to_phys(l2x0_saved_regs);
diff --git a/arch/arm/plat-samsung/include/plat/pm.h 
b/arch/arm/plat-samsung/include/plat/pm.h
index f6fcade..532f5d7 100644
--- a/arch/arm/plat-samsung/include/plat/pm.h
+++ b/arch/arm/plat-samsung/include/plat/pm.h
@@ -184,3 +184,4 @@ extern void samsung_pm_save_gpios(void);
 
 extern void s3c_pm_save_core(void);
 extern void s3c_pm_restore_core(void);
+extern unsigned long cpu_midr;
diff --git a/arch/arm/plat-samsung/s5p-sleep.S 
b/arch/arm/plat-samsung/s5p-sleep.S
index bdf6dad..3b350d0 100644
--- a/arch/arm/plat-samsung/s5p-sleep.S
+++ b/arch/arm/plat-samsung/s5p-sleep.S
@@ -25,6 +25,8 @@
 #include asm/asm-offsets.h
 #include asm/hardware/cache-l2x0.h
 
+#define CPU_CORTEX_A9  0x410FC090
+
 /*
  *  The following code is located into the .data section. This is to
  *  allow l2x0_regs_phys to be accessed with a relative load while we
@@ -51,6 +53,11 @@
 
 ENTRY(s3c_cpu_resume)
 #ifdef CONFIG_CACHE_L2X0
+   adr r0, cpu_midr
+   ldr r1, [r0]
+   ldr r0, =CPU_CORTEX_A9
+   cmp r1, r0
+   bne resume_l2on
adr r0, l2x0_regs_phys
ldr r0, [r0]
ldr r1, [r0, #L2X0_R_PHY_BASE]
@@ -77,4 +84,7 @@ ENDPROC(s3c_cpu_resume)
.globl l2x0_regs_phys
 l2x0_regs_phys:
.long   0
+   .globl cpu_midr
+cpu_midr:
+   .long   0
 #endif
-- 
1.7.9.5

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


Re: [PATCH v2] arm: plat-samsung: check processor type before cache restoration in resume

2013-02-26 Thread Inderpal Singh
On 26 February 2013 15:32, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Tue, Feb 26, 2013 at 03:26:53PM +0530, Inderpal Singh wrote:
 Only cortex-a9 based samsung platforms have l2x0 cache controller. Hence 
 check
 the same before restoring the cache in resume.

 Why is this patch soo complicated?  Can't you read the CPUs MIDR register
 from assembly code?

I wanted to read MIDR only once thats why didn't read in resume
function in assembly as the same resume function gets used in cpuidle
path.

Regards,
Inder
--
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: plat-samsung: check soc ids before l2x0 cache restoration in resume

2013-02-12 Thread Inderpal Singh
Hi Kukjin,

Thanks for reviewing the patch.

On 13 February 2013 00:57, Kukjin Kim kgene@samsung.com wrote:
 Inderpal Singh wrote:

 Only exynos4 based platforms have l2x0 cache controller. Hence check
 the same before restoring the cache in resume.

 I think, the code can determine by checking ARM main ID cp15 register
 instead of Chip ID. Because if so, we don't need to do something for ahother
 EXYNOS4 SoCs next time.


Good point.
So the idea is that only cortex a9 based samsung platforms will have
l2x0 cache controller. Hence I should only check if its cortex a9 or
not from main ID reg.
Please confirm.

Thanks,
Inder

 This is needed for single kernel image.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  arch/arm/mach-exynos/common.c   |2 ++
  arch/arm/plat-samsung/include/plat/pm.h |1 +
  arch/arm/plat-samsung/s5p-sleep.S   |   28
 
  3 files changed, 31 insertions(+)

 diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-
 exynos/common.c
 index cdaa55f..ab7ca00 100644
 --- a/arch/arm/mach-exynos/common.c
 +++ b/arch/arm/mach-exynos/common.c
 @@ -796,6 +796,8 @@ static int __init exynos4_l2x0_cache_init(void)
   if (soc_is_exynos5250() || soc_is_exynos5440())
   return 0;

 + s5p_cpu = samsung_cpu_id  EXYNOS4_CPU_MASK;
 +
   ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
   if (!ret) {
   l2x0_regs_phys = virt_to_phys(l2x0_saved_regs);
 diff --git a/arch/arm/plat-samsung/include/plat/pm.h b/arch/arm/plat-
 samsung/include/plat/pm.h
 index 887a0c9..285c8c8 100644
 --- a/arch/arm/plat-samsung/include/plat/pm.h
 +++ b/arch/arm/plat-samsung/include/plat/pm.h
 @@ -190,3 +190,4 @@ extern void samsung_pm_save_gpios(void);

  extern void s3c_pm_save_core(void);
  extern void s3c_pm_restore_core(void);
 +extern unsigned long s5p_cpu;
 diff --git a/arch/arm/plat-samsung/s5p-sleep.S b/arch/arm/plat-
 samsung/s5p-sleep.S
 index bdf6dad..006d35f 100644
 --- a/arch/arm/plat-samsung/s5p-sleep.S
 +++ b/arch/arm/plat-samsung/s5p-sleep.S
 @@ -25,6 +25,15 @@
  #include asm/asm-offsets.h
  #include asm/hardware/cache-l2x0.h

 +#define EXYNOS4210_CPU_ID0x4321
 +#define EXYNOS4212_CPU_ID0x4322
 +#define EXYNOS4412_CPU_ID0xE4412200
 +#define EXYNOS4_CPU_MASK 0xFFFE
 +
 +#define EXYNOS4210_CPU   (EXYNOS4210_CPU_ID 
 EXYNOS4_CPU_MASK)
 +#define EXYNOS4212_CPU   (EXYNOS4212_CPU_ID 
 EXYNOS4_CPU_MASK)
 +#define EXYNOS4412_CPU   (EXYNOS4412_CPU_ID 
 EXYNOS4_CPU_MASK)
 +
  /*
   *The following code is located into the .data section. This is to
   *allow l2x0_regs_phys to be accessed with a relative load while we
 @@ -51,6 +60,22 @@

  ENTRY(s3c_cpu_resume)
  #ifdef CONFIG_CACHE_L2X0
 + adr r0, s5p_cpu
 + ldr r1, [r0]
 +
 + ldr r0, =EXYNOS4210_CPU
 + cmp r1, r0
 + beq continue
 +
 + ldr r0, =EXYNOS4212_CPU
 + cmp r1, r0
 + beq continue
 +
 + ldr r0, =EXYNOS4412_CPU
 + cmp r1, r0
 + bne resume_l2on
 +
 +continue:
   adr r0, l2x0_regs_phys
   ldr r0, [r0]
   ldr r1, [r0, #L2X0_R_PHY_BASE]
 @@ -77,4 +102,7 @@ ENDPROC(s3c_cpu_resume)
   .globl l2x0_regs_phys
  l2x0_regs_phys:
   .long   0
 + .globl s5p_cpu
 +s5p_cpu:
 + .long   0
  #endif
 --
 1.7.9.5

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


Re: [PATCH 3/3] dts: Add cpufreq controller node for Exynos5440 SoC

2013-02-11 Thread Inderpal Singh
On 12 February 2013 06:42, amit kachhap amit.kach...@gmail.com wrote:
 On Fri, Feb 8, 2013 at 8:49 AM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 On 8 February 2013 00:03, amit kachhap amit.kach...@gmail.com wrote:
 On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com 
 wrote:
 Add cpufreq controller device node for Exynos5440 SoC for passing
 parameters like controller base address, interrupt and cpufreq
 table.

 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  arch/arm/boot/dts/exynos5440.dtsi |9 +
  1 file changed, 9 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
 b/arch/arm/boot/dts/exynos5440.dtsi
 index 024269d..b20b517 100644
 --- a/arch/arm/boot/dts/exynos5440.dtsi
 +++ b/arch/arm/boot/dts/exynos5440.dtsi
 @@ -63,6 +63,15 @@

 };

 +   cpufreq@16 {
 +   compatible = samsung,exynos5440-cpufreq;
 +   reg = 0x16 0x1000;
 +   interrupts = 0 57 0;
 +   cpufreq_tbl =  120 1025000
 +   100 975000
 +   80  925000 ;
 +   };
 +

 I think cpufreq_tbl should be part of the cpu node as it's the
 property of the cpu.
 Please refer cpufreq-cpu0 and spear-cpufreq.

 http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15364.
 In this thread same discussion followed. I am not sure what is the
 correct way but looks like Kukjin concluded this with a timer node
 separate from the CPU code.


 I am only talking about cpufreq_tbl and its nothing but operating
 points for the cpus. It seems its agreed upon to add operating-points
 to cpu node as being done by all other platforms like imx6q, am33xx,
 cpufreq-cpu0 and spear.

 Even timer, GIC, cpufreq tbl, pmu etc are all cpu properties. But the
 problem is whether to put them in cpu0 or repeat same information in
 all cpu nodes as it is common to all cpu's  and not just cpu0. So as

You don't have to repeat the same cpufreq_tbl for all cpu nodes.
Having table in only cpu0 node is sufficient as being done in other platforms.

Thanks,
Inder

 Kukjin kim has put the timer node outside the cpu node so i also
 followed the same convention.

 Mr Kim,
 Any issue in this approach?

 Thanks,
 Amit Daniel

 Thanks,
 Inder

 Thanks,
 Amit Daniel

 serial@B {
 compatible = samsung,exynos4210-uart;
 reg = 0xB 0x1000;
 --
 1.7.10.4

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


Re: [PATCH 3/3] dts: Add cpufreq controller node for Exynos5440 SoC

2013-02-08 Thread Inderpal Singh
On 8 February 2013 00:03, amit kachhap amit.kach...@gmail.com wrote:
 On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com 
 wrote:
 Add cpufreq controller device node for Exynos5440 SoC for passing
 parameters like controller base address, interrupt and cpufreq
 table.

 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  arch/arm/boot/dts/exynos5440.dtsi |9 +
  1 file changed, 9 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
 b/arch/arm/boot/dts/exynos5440.dtsi
 index 024269d..b20b517 100644
 --- a/arch/arm/boot/dts/exynos5440.dtsi
 +++ b/arch/arm/boot/dts/exynos5440.dtsi
 @@ -63,6 +63,15 @@

 };

 +   cpufreq@16 {
 +   compatible = samsung,exynos5440-cpufreq;
 +   reg = 0x16 0x1000;
 +   interrupts = 0 57 0;
 +   cpufreq_tbl =  120 1025000
 +   100 975000
 +   80  925000 ;
 +   };
 +

 I think cpufreq_tbl should be part of the cpu node as it's the
 property of the cpu.
 Please refer cpufreq-cpu0 and spear-cpufreq.

 http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15364.
 In this thread same discussion followed. I am not sure what is the
 correct way but looks like Kukjin concluded this with a timer node
 separate from the CPU code.


I am only talking about cpufreq_tbl and its nothing but operating
points for the cpus. It seems its agreed upon to add operating-points
to cpu node as being done by all other platforms like imx6q, am33xx,
cpufreq-cpu0 and spear.

Thanks,
Inder

 Thanks,
 Amit Daniel

 serial@B {
 compatible = samsung,exynos4210-uart;
 reg = 0xB 0x1000;
 --
 1.7.10.4

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


Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440

2013-02-07 Thread Inderpal Singh
On 7 February 2013 16:49, Viresh Kumar viresh.ku...@linaro.org wrote:
 On Thu, Feb 7, 2013 at 10:39 AM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 +#define DRIVER_NAMEexynos5440_dvfs

 +static struct cpufreq_driver exynos_driver = {
 +   .name   = DRIVER_NAME,
 +};
 +

 Since this driver is only for exynos5440, having the same names as
 common exynos-cpufreq is misleading.

 Where is it same?

I meant hooks names (verify/get/target and init)

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


Re: [PATCH 3/3] dts: Add cpufreq controller node for Exynos5440 SoC

2013-02-06 Thread Inderpal Singh
On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
 Add cpufreq controller device node for Exynos5440 SoC for passing
 parameters like controller base address, interrupt and cpufreq
 table.

 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  arch/arm/boot/dts/exynos5440.dtsi |9 +
  1 file changed, 9 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
 b/arch/arm/boot/dts/exynos5440.dtsi
 index 024269d..b20b517 100644
 --- a/arch/arm/boot/dts/exynos5440.dtsi
 +++ b/arch/arm/boot/dts/exynos5440.dtsi
 @@ -63,6 +63,15 @@

 };

 +   cpufreq@16 {
 +   compatible = samsung,exynos5440-cpufreq;
 +   reg = 0x16 0x1000;
 +   interrupts = 0 57 0;
 +   cpufreq_tbl =  120 1025000
 +   100 975000
 +   80  925000 ;
 +   };
 +

I think cpufreq_tbl should be part of the cpu node as it's the
property of the cpu.
Please refer cpufreq-cpu0 and spear-cpufreq.

 serial@B {
 compatible = samsung,exynos4210-uart;
 reg = 0xB 0x1000;
 --
 1.7.10.4

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


Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440

2013-02-06 Thread Inderpal Singh
On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
 This patch adds dvfs support for exynos5440 SOC. The nature of exynos5440
 clock controller is different from previous exynos controllers so not using
 the common exynos cpufreq framework. Also, the device tree parsing is added
 to get different parameters like frequency, voltage etc.

 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  .../bindings/cpufreq/cpufreq-exynos5440.txt|   24 ++
  drivers/cpufreq/Kconfig.arm|8 +
  drivers/cpufreq/Makefile   |1 +
  drivers/cpufreq/exynos5440-cpufreq.c   |  448 
 
  4 files changed, 481 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
  create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c

 diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt 
 b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
 new file mode 100644
 index 000..96cb0ed
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
 @@ -0,0 +1,24 @@
 +
 +Exynos5440 cpufreq driver
 +---
 +
 +Exynos5440 SoC cpufreq driver for CPU frequency scaling.
 +
 +Required properties:
 +- interrupts: Interrupt to know the completion of cpu frequency change.
 +- cpufreq_tbl: Table of frequencies and voltage CPU could be transitioned 
 into,
 +   in the decreasing order. Frequency should be in KHZ units and voltage
 +   should be in microvolts.
 +
 +All the required listed above must be defined under node cpufreq.
 +
 +Example:
 +
 +   cpufreq@16 {
 +   compatible = samsung,exynos5440-cpufreq;
 +   reg = 0x16 0x1000;
 +   interrupts = 0 57 0;
 +   cpufreq_tbl =  120 1025000
 +   100 975000
 +   80  925000 ;
 +   };
 diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
 index a0b3661..554756f 100644
 --- a/drivers/cpufreq/Kconfig.arm
 +++ b/drivers/cpufreq/Kconfig.arm
 @@ -77,6 +77,14 @@ config ARM_EXYNOS5250_CPUFREQ
   This adds the CPUFreq driver for Samsung EXYNOS5250
   SoC.

 +config ARM_EXYNOS5440_CPUFREQ
 +   def_bool SOC_EXYNOS5440
 +   help
 + This adds the CPUFreq driver for Samsung EXYNOS5440
 + SoC. The nature of exynos5440 clock controller is
 + different than previous exynos controllers so not using
 + the common exynos framework.
 +
  config ARM_SPEAR_CPUFREQ
 bool SPEAr CPUFreq support
 depends on PLAT_SPEAR
 diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
 index fadc4d4..5159ba4 100644
 --- a/drivers/cpufreq/Makefile
 +++ b/drivers/cpufreq/Makefile
 @@ -50,6 +50,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)  += exynos-cpufreq.o
  obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
  obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
  obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
 +obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
  obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
  obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o

 diff --git a/drivers/cpufreq/exynos5440-cpufreq.c 
 b/drivers/cpufreq/exynos5440-cpufreq.c
 new file mode 100644
 index 000..41d39e2
 --- /dev/null
 +++ b/drivers/cpufreq/exynos5440-cpufreq.c
 @@ -0,0 +1,448 @@
 +/*
 + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
 + * http://www.samsung.com
 + *
 + * Amit Daniel Kachhap amit.dan...@samsung.com
 + *
 + * EXYNOS5440 - CPU frequency scaling support
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 +*/
 +
 +#include linux/clk.h
 +#include linux/cpufreq.h
 +#include linux/err.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/of_address.h
 +#include linux/of_irq.h
 +#include linux/slab.h
 +
 +/*Register definations*/
 +#define XMU_DVFS_CTRL  0x0060
 +#define XMU_PMU_P0_7   0x0064
 +#define XMU_C0_3_PSTATE0x0090
 +#define XMU_P_LIMIT0x00A0
 +#define XMU_P_STATUS   0x00A4
 +#define XMU_PMUEVTEN   0x00D0
 +#define XMU_PMUIRQEN   0x00D4
 +#define XMU_PMUIRQ 0x00D8
 +
 +/*PMU mask and shift definations*/
 +#define P_VALUE_MASK   0x7
 +
 +#define XMU_DVFS_CTRL_EN_SHIFT 0
 +
 +#define P0_7_CPUCLKDEV_SHIFT   21
 +#define P0_7_CPUCLKDEV_MASK0x7
 +#define P0_7_ATBCLKDEV_SHIFT   18
 +#define P0_7_ATBCLKDEV_MASK0x7
 +#define P0_7_CSCLKDEV_SHIFT15
 +#define P0_7_CSCLKDEV_MASK 0x7
 +#define P0_7_CPUEMA_SHIFT  28
 +#define P0_7_CPUEMA_MASK   0xf
 +#define P0_7_L2EMA_SHIFT   24
 +#define 

[PATCH] cpufreq: exynos: Show list of available frequencies

2013-01-08 Thread Inderpal Singh
Add freq_attr attribute to show list of available frequencies.

Signed-off-by: Donggeun Kim dg77@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: KyungMin Park kyungmin.p...@samsung.com
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/cpufreq/exynos-cpufreq.c |   13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 7012ea8..bc1e833 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -244,13 +244,26 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
return cpufreq_frequency_table_cpuinfo(policy, exynos_info-freq_table);
 }
 
+static int exynos_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+   cpufreq_frequency_table_put_attr(policy-cpu);
+   return 0;
+}
+
+static struct freq_attr *exynos_cpufreq_attr[] = {
+   cpufreq_freq_attr_scaling_available_freqs,
+   NULL,
+};
+
 static struct cpufreq_driver exynos_driver = {
.flags  = CPUFREQ_STICKY,
.verify = exynos_verify_speed,
.target = exynos_target,
.get= exynos_getspeed,
.init   = exynos_cpufreq_cpu_init,
+   .exit   = exynos_cpufreq_cpu_exit,
.name   = exynos_cpufreq,
+   .attr   = exynos_cpufreq_attr,
 #ifdef CONFIG_PM
.suspend= exynos_cpufreq_suspend,
.resume = exynos_cpufreq_resume,
-- 
1.7.9.5

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


Re: [PATCH] cpufreq: exynos: Show list of available frequencies

2013-01-08 Thread Inderpal Singh
+CC:
dg77@samsung.com, myungjoo@samsung.com, kyungmin.p...@samsung.com

On 8 January 2013 16:20, Inderpal Singh inderpal.si...@linaro.org wrote:
 Add freq_attr attribute to show list of available frequencies.

 Signed-off-by: Donggeun Kim dg77@samsung.com
 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: KyungMin Park kyungmin.p...@samsung.com
 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/cpufreq/exynos-cpufreq.c |   13 +
  1 file changed, 13 insertions(+)

 diff --git a/drivers/cpufreq/exynos-cpufreq.c 
 b/drivers/cpufreq/exynos-cpufreq.c
 index 7012ea8..bc1e833 100644
 --- a/drivers/cpufreq/exynos-cpufreq.c
 +++ b/drivers/cpufreq/exynos-cpufreq.c
 @@ -244,13 +244,26 @@ static int exynos_cpufreq_cpu_init(struct 
 cpufreq_policy *policy)
 return cpufreq_frequency_table_cpuinfo(policy, 
 exynos_info-freq_table);
  }

 +static int exynos_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 +{
 +   cpufreq_frequency_table_put_attr(policy-cpu);
 +   return 0;
 +}
 +
 +static struct freq_attr *exynos_cpufreq_attr[] = {
 +   cpufreq_freq_attr_scaling_available_freqs,
 +   NULL,
 +};
 +
  static struct cpufreq_driver exynos_driver = {
 .flags  = CPUFREQ_STICKY,
 .verify = exynos_verify_speed,
 .target = exynos_target,
 .get= exynos_getspeed,
 .init   = exynos_cpufreq_cpu_init,
 +   .exit   = exynos_cpufreq_cpu_exit,
 .name   = exynos_cpufreq,
 +   .attr   = exynos_cpufreq_attr,
  #ifdef CONFIG_PM
 .suspend= exynos_cpufreq_suspend,
 .resume = exynos_cpufreq_resume,
 --
 1.7.9.5

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


[PATCH] ARM: EXYNOS4: Add support for rtc wakeup

2012-12-26 Thread Inderpal Singh
Set the gic arch extension callback to support rtc wakeup.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 arch/arm/mach-exynos/common.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 578a610..bf2ee1d 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -747,6 +747,8 @@ void __init exynos4_init_irq(void)
 * uses GIC instead of VIC.
 */
s5p_init_irq(NULL, 0);
+
+   gic_arch_extn.irq_set_wake = s3c_irq_wake;
 }
 
 void __init exynos5_init_irq(void)
-- 
1.7.9.5

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


[PATCH 1/2] i2c: s3c2410: Initialize i2c-gpios[] with requested gpio lines

2012-12-26 Thread Inderpal Singh
i2c-gpios[] is being used to free_gpios but it's not getting initialized.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/i2c/busses/i2c-s3c2410.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index a290d08..f1d1f1e 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -875,6 +875,8 @@ static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c 
*i2c)
dev_err(i2c-dev, gpio [%d] request failed\n, gpio);
goto free_gpio;
}
+
+   i2c-gpios[idx] = gpio;
}
return 0;
 
-- 
1.7.9.5

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


[PATCH 2/2] i2c: s3c2410: free gpios in suspend function

2012-12-26 Thread Inderpal Singh
While resuming the gpios are being requested again, hence we need
to free the gpios before going to suspend otherwise it gives
gpio request failed errors while resuming.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/i2c/busses/i2c-s3c2410.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index f1d1f1e..55c1762 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1172,6 +1172,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
 
+   s3c24xx_i2c_dt_gpio_free(i2c);
i2c-suspended = 1;
 
return 0;
-- 
1.7.9.5

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


Re: [PATCH 2/2] i2c: s3c2410: free gpios in suspend function

2012-12-26 Thread Inderpal Singh
On 27 December 2012 09:39, Inderpal Singh inderpal.si...@linaro.org wrote:
 While resuming the gpios are being requested again, hence we need
 to free the gpios before going to suspend otherwise it gives
 gpio request failed errors while resuming.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/i2c/busses/i2c-s3c2410.c |1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/i2c/busses/i2c-s3c2410.c 
 b/drivers/i2c/busses/i2c-s3c2410.c
 index f1d1f1e..55c1762 100644
 --- a/drivers/i2c/busses/i2c-s3c2410.c
 +++ b/drivers/i2c/busses/i2c-s3c2410.c
 @@ -1172,6 +1172,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
 struct platform_device *pdev = to_platform_device(dev);
 struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);

 +   s3c24xx_i2c_dt_gpio_free(i2c);
 i2c-suspended = 1;

 return 0;
 --
 1.7.9.5


Please ignore this patch as this has been sent already at

http://dics.voicecontrol.ro/process_mails/arata_discutia/174658/%5BPATCH%5D_i2c:_s3c2410:_Add_fix_for_i2c_suspend_resume.html

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


Re: [PATCH 1/2] i2c: s3c2410: Initialize i2c-gpios[] with requested gpio lines

2012-12-26 Thread Inderpal Singh
On 27 December 2012 09:39, Inderpal Singh inderpal.si...@linaro.org wrote:
 i2c-gpios[] is being used to free_gpios but it's not getting initialized.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/i2c/busses/i2c-s3c2410.c |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/i2c/busses/i2c-s3c2410.c 
 b/drivers/i2c/busses/i2c-s3c2410.c
 index a290d08..f1d1f1e 100644
 --- a/drivers/i2c/busses/i2c-s3c2410.c
 +++ b/drivers/i2c/busses/i2c-s3c2410.c
 @@ -875,6 +875,8 @@ static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c 
 *i2c)
 dev_err(i2c-dev, gpio [%d] request failed\n, gpio);
 goto free_gpio;
 }
 +
 +   i2c-gpios[idx] = gpio;
 }
 return 0;

 --
 1.7.9.5


Please ignore this patch as this has been sent already at

http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg10781.html

Sorry for the noise !!!
--
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] regulator: s5m8767: Fix probe failure due to stack corruption

2012-12-11 Thread Inderpal Singh
The function sec_reg_read invokes regmap_read which expects unsigned int *
as the destination address. The existing driver is passing address of local
variable val which is u8. This causes the stack corruption and following
dump is observed during probe.

Hence change val from u8 to unsigned int.

Unable to handle kernel paging request at virtual address 02410020
pgd = c0004000
[02410020] *pgd=
Internal error: Oops: 8005 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0Not tainted  (3.6.0-00696-g98a28b18-dirty #27)
PC is at 0x2410020
LR is at _regulator_get_voltage+0x3c/0x70
pc : [02410020]lr : [c02395d4]psr: 2013
sp : cf839b68  ip :   fp : cf92d410
r10: cfd0  r9 : c06d9878  r8 : f0a0
r7 : cf839b70  r6 : cf92d400  r5 : 0011  r4 : cf00
r3 : 02410020  r2 :   r1 : 0048  r0 : cf00
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
...
.

[c02395d4] (_regulator_get_voltage+0x3c/0x70) from [c023ad80] 
(print_constraints+0x50/0x36c)
[c023ad80] (print_constraints+0x50/0x36c) from [c023e504] 
(set_machine_constraints+0xe8/0x2b0)
[c023e504] (set_machine_constraints+0xe8/0x2b0) from [c023e9c8] 
(regulator_register+0x2fc/0x604)
[c023e9c8] (regulator_register+0x2fc/0x604) from [c049d628] 
(s5m8767_pmic_probe+0x688/0x718)
[c049d628] (s5m8767_pmic_probe+0x688/0x718) from [c029915c] 
(platform_drv_probe+0x18/0x1c)
[c029915c] (platform_drv_probe+0x18/0x1c) from [c0297dd0] 
(really_probe+0x68/0x1f4)
[c0297dd0] (really_probe+0x68/0x1f4) from [c0298070] 
(driver_probe_device+0x30/0x48)

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/regulator/s5m8767.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 8ef5b33..9e6850f 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -214,7 +214,7 @@ static int s5m8767_reg_is_enabled(struct regulator_dev 
*rdev)
struct s5m8767_info *s5m8767 = rdev_get_drvdata(rdev);
int ret, reg;
int mask = 0xc0, enable_ctrl;
-   u8 val;
+   unsigned int val;
 
ret = s5m8767_get_register(rdev, reg, enable_ctrl);
if (ret == -EINVAL)
@@ -306,7 +306,7 @@ static int s5m8767_get_voltage_sel(struct regulator_dev 
*rdev)
struct s5m8767_info *s5m8767 = rdev_get_drvdata(rdev);
int reg, mask, ret;
int reg_id = rdev_get_id(rdev);
-   u8 val;
+   unsigned int val;
 
ret = s5m8767_get_voltage_register(rdev, reg);
if (ret)
-- 
1.7.9.5

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


Re: [PATCH v2 3/4] DMA: PL330: Balance module remove function with probe

2012-10-29 Thread Inderpal Singh
Hi Vinod,

On 29 October 2012 10:15, Vinod Koul vk...@infradead.org wrote:
 On Sat, 2012-10-27 at 15:50 +0530, Inderpal Singh wrote:
 Hi Vinod,

 On 26 October 2012 10:15, Vinod Koul vk...@infradead.org wrote:
  On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote:
 
  This code will get executed only in case of force removal of the
  module which was discussed in the first version of the patch at [1].
  Now, if we do not have to think about force removal then this patch
  will go back to the first version.
  But why are you doing force removal of driver even when client is
  holding a reference to you.
 
  What happens when client finally tries to free the channel?
 Since we return EBUSY so forced removal won't succeed. Client can free
 the channel eventually.
 And that is my concern. You have forcefully removed the dma module.
 What happens then? How will the free calll get executed, wont you hit a
 panic.

Yes, you are correct, It will hit a panic.
The return value from remove is not being checked in
__device_release_driver because of which dma module is forcefully
removed even if we return EBUSY from driver's remove. Hence returning
error from .remove is not useful at all.


 
  What is the problem you are trying to solve?
 

 There was a long discussion about it in the first version of the
 patch. Allow me to explain it to you.

 The existing driver does DMA_TERMINATE_ALL and frees resources for all
 the channels in the _remove function.
 Which for starters may not be right thing to do.


Please consider v1 patch which removes DMA_TERMINATE_ALL and freeing
of resources from .remove function because in normal scenario if
remove is reached it is sure that no client is holding any reference
to the driver hence no need to flush and free the channels.

 Shouldn't you first
 make sure client has freed all references to your driver and then only
 remove. Freeing resources in .remove without keeping client in sync
 doesn't sound to be good idea to me.

  The first version of patch
 removed this flushing and freeing of channel resources because they
 are not getting allocated in the probe. Jassi pointed out that manual
 flushing is needed if a force removal happens and some client is
 queued. Then it was agreed that flushing is not needed, instead we
 should return EBUSY if client is queued on some channel (this will
 happen only in force removal case). Hence this additional check in v2
 version so that force removal does not succeeds if any client is
 queued.

 If you think force removal is not a practical scenario and we should
 not be bothering about it, this check can be removed and the patch
 will go back to first version which just removes flushing and freeing
 of channels beacues they are not getting allocated in probe.

 Let me know your view.

 Regards,
 Inder


  Let me know your view.
 
  [1] https://patchwork.kernel.org/patch/1503171/
 
 
 
  --
  Vinod Koul
  Intel Corp.
 


 --
 Vinod Koul
 Intel Corp.

--
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/4] DMA: PL330: Balance module remove function with probe

2012-10-27 Thread Inderpal Singh
Hi Vinod,

On 26 October 2012 10:15, Vinod Koul vk...@infradead.org wrote:
 On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote:

 This code will get executed only in case of force removal of the
 module which was discussed in the first version of the patch at [1].
 Now, if we do not have to think about force removal then this patch
 will go back to the first version.
 But why are you doing force removal of driver even when client is
 holding a reference to you.

 What happens when client finally tries to free the channel?
Since we return EBUSY so forced removal won't succeed. Client can free
the channel eventually.


 What is the problem you are trying to solve?


There was a long discussion about it in the first version of the
patch. Allow me to explain it to you.

The existing driver does DMA_TERMINATE_ALL and frees resources for all
the channels in the _remove function. The first version of patch
removed this flushing and freeing of channel resources because they
are not getting allocated in the probe. Jassi pointed out that manual
flushing is needed if a force removal happens and some client is
queued. Then it was agreed that flushing is not needed, instead we
should return EBUSY if client is queued on some channel (this will
happen only in force removal case). Hence this additional check in v2
version so that force removal does not succeeds if any client is
queued.

If you think force removal is not a practical scenario and we should
not be bothering about it, this check can be removed and the patch
will go back to first version which just removes flushing and freeing
of channels beacues they are not getting allocated in probe.

Let me know your view.

Regards,
Inder


 Let me know your view.

 [1] https://patchwork.kernel.org/patch/1503171/



 --
 Vinod Koul
 Intel Corp.

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


Re: [PATCH v2 1/4] DMA: PL330: Free memory allocated for peripheral channels

2012-10-25 Thread Inderpal Singh
Hi Vinod,

Thanks for reviewing.

On 24 October 2012 09:35, Vinod Koul vk...@infradead.org wrote:
 On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
 The allocated memory for peripheral channels is not being freed upon
 failure in probe and in module's remove funtion. It will lead to memory
 leakage. Hence free the allocated memory.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/dma/pl330.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 2ebd4cd..10c6b6a 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -2962,7 +2962,7 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
   ret = dma_async_device_register(pd);
   if (ret) {
   dev_err(adev-dev, unable to register DMAC\n);
 - goto probe_err4;
 + goto probe_err5;
   }

   dev_info(adev-dev,
 @@ -2975,6 +2975,8 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)

   return 0;

 +probe_err5:
 + kfree(pdmac-peripherals);
  probe_err4:
   pl330_del(pi);
  probe_err3:
 @@ -3025,6 +3027,7 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)
   res = adev-res;
   release_mem_region(res-start, resource_size(res));

 + kfree(pdmac-peripherals);
   kfree(pdmac);

   return 0;

 This looks fine, but if you use devm_ functions then you dont need to do
 all this.
 Can you do that conversion instead?


Good point.
I will do the conversion and send it again.

Regards,
Inder

 --
 Vinod Koul
 Intel Corp.

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


Re: [PATCH v2 2/4] DMA: PL330: Change allocation method to properly free DMA descriptors

2012-10-25 Thread Inderpal Singh
On 24 October 2012 09:40, Vinod Koul vk...@infradead.org wrote:
 On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
 In probe, memory for multiple DMA descriptors were being allocated at once
 and then it was being split and added into DMA pool one by one. The address
 of this memory allocation is not being saved anywhere. To free this memory,
 the address is required. Initially the first node of the pool will be
 pointed by this address but as we use this pool the descs will shuffle and
 hence we will lose the track of the address.

 This patch does following:

 1. Allocates DMA descs one by one and then adds them to pool so that all
descs can be fetched and memory freed one by one. This way runtime
added descs can also be freed.
 2. Free DMA descs in case of error in probe and in module's remove function
 For probe, again you have cleaner code by using devm_kzalloc.

 On 1, if we use the devm_kzalloc then we don't need to allocate in
 chunks right?


Yes, if we use devm_kzalloc we wont have to allocate in chunks.
I will update this patch to use devm_kzalloc and send it again.



 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/dma/pl330.c |   35 +--
  1 file changed, 25 insertions(+), 10 deletions(-)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 10c6b6a..bf71ff7 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -2541,20 +2541,20 @@ static int add_desc(struct dma_pl330_dmac *pdmac, 
 gfp_t flg, int count)
   if (!pdmac)
   return 0;

 - desc = kmalloc(count * sizeof(*desc), flg);
 - if (!desc)
 - return 0;
 + for (i = 0; i  count; i++) {
 + desc = kmalloc(sizeof(*desc), flg);
 + if (!desc)
 + break;
 + _init_desc(desc);

 - spin_lock_irqsave(pdmac-pool_lock, flags);
 + spin_lock_irqsave(pdmac-pool_lock, flags);

 - for (i = 0; i  count; i++) {
 - _init_desc(desc[i]);
 - list_add_tail(desc[i].node, pdmac-desc_pool);
 - }
 + list_add_tail(desc-node, pdmac-desc_pool);

 - spin_unlock_irqrestore(pdmac-pool_lock, flags);
 + spin_unlock_irqrestore(pdmac-pool_lock, flags);
 + }

 - return count;
 + return i;
  }

  static struct dma_pl330_desc *
 @@ -2857,6 +2857,7 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
   struct dma_pl330_platdata *pdat;
   struct dma_pl330_dmac *pdmac;
   struct dma_pl330_chan *pch;
 + struct dma_pl330_desc *desc;
   struct pl330_info *pi;
   struct dma_device *pd;
   struct resource *res;
 @@ -2978,6 +2979,12 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
  probe_err5:
   kfree(pdmac-peripherals);
  probe_err4:
 + while (!list_empty(pdmac-desc_pool)) {
 + desc = list_entry(pdmac-desc_pool.next,
 + struct dma_pl330_desc, node);
 + list_del(desc-node);
 + kfree(desc);
 + }
   pl330_del(pi);
  probe_err3:
   free_irq(irq, pi);
 @@ -2994,6 +3001,7 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)
  {
   struct dma_pl330_dmac *pdmac = amba_get_drvdata(adev);
   struct dma_pl330_chan *pch, *_p;
 + struct dma_pl330_desc *desc;
   struct pl330_info *pi;
   struct resource *res;
   int irq;
 @@ -3015,6 +3023,13 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)
   pl330_free_chan_resources(pch-chan);
   }

 + while (!list_empty(pdmac-desc_pool)) {
 + desc = list_entry(pdmac-desc_pool.next,
 + struct dma_pl330_desc, node);
 + list_del(desc-node);
 + kfree(desc);
 + }
 +
   pi = pdmac-pif;

   pl330_del(pi);


 --
 Vinod Koul
 Intel Corp.

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


Re: [PATCH v2 4/4] DMA: PL330: unregister dma_device in module's remove function

2012-10-25 Thread Inderpal Singh
On 24 October 2012 09:49, Vinod Koul vk...@infradead.org wrote:
 On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
 unregister dma_device in module's remove function.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/dma/pl330.c |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 4b7a34d..e7dc040 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -3017,6 +3017,8 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)
   return -EBUSY;
   }

 + dma_async_device_unregister(pdmac-ddma);
 +
   amba_set_drvdata(adev, NULL);

   list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,

 Ok with this one :)

 Tried applying but didn't work out. You would need to regenerate this
 one.


I will regenerate this along with other patches and resend.

With Regards,
Inder

 Thanks
 --
 Vinod Koul
 Intel Corp.

--
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/4] DMA: PL330: Balance module remove function with probe

2012-10-25 Thread Inderpal Singh
Hi Vinod,

On 24 October 2012 09:44, Vinod Koul vk...@infradead.org wrote:
 On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
 Since peripheral channel resources are not being allocated at probe,
 no need to flush the channels and free the resources in remove function.
 In case, the channel is in use by some client, return EBUSY.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/dma/pl330.c |   13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index bf71ff7..4b7a34d 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -3009,18 +3009,21 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)
   if (!pdmac)
   return 0;

 + /* check if any client is using any channel */
 + list_for_each_entry(pch, pdmac-ddma.channels,
 + chan.device_node) {
 +
 + if (pch-chan.client_count)
 + return -EBUSY;
 + }
 +
   while (!list_empty(pdmac-desc_pool)) {

 Did you get this code executed?
 I think No.

 The dmaengine holds the reference to channels, so if they are in use and
 not freed by client your remove wont be called. So this check is
 redundant


This code will get executed only in case of force removal of the
module which was discussed in the first version of the patch at [1].
Now, if we do not have to think about force removal then this patch
will go back to the first version.

Let me know your view.

[1] https://patchwork.kernel.org/patch/1503171/

Regards,
Inder
 --
 Vinod Koul
 Intel Corp.

--
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] MFD: SEC: Fix reg_offset for interrupt registers

2012-10-17 Thread Inderpal Singh
reg_offset is offset of the status/mask registers. Now, since status_base
and mask_base are pointing to corresponding first registers, reg_offset
should start from 0 otheriwse regmap_add_irq_chip will fail during probe.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
It is based on Samuel's for-next-merge branch of mfd-2.6 tree. 

 drivers/mfd/sec-irq.c |  102 -
 1 file changed, 51 insertions(+), 51 deletions(-)

diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index c901fa5..0dd84e9 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -24,67 +24,67 @@
 
 static struct regmap_irq s2mps11_irqs[] = {
[S2MPS11_IRQ_PWRONF] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S2MPS11_IRQ_PWRONF_MASK,
},
[S2MPS11_IRQ_PWRONR] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S2MPS11_IRQ_PWRONR_MASK,
},
[S2MPS11_IRQ_JIGONBF] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S2MPS11_IRQ_JIGONBF_MASK,
},
[S2MPS11_IRQ_JIGONBR] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S2MPS11_IRQ_JIGONBR_MASK,
},
[S2MPS11_IRQ_ACOKBF] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S2MPS11_IRQ_ACOKBF_MASK,
},
[S2MPS11_IRQ_ACOKBR] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S2MPS11_IRQ_ACOKBR_MASK,
},
[S2MPS11_IRQ_PWRON1S] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S2MPS11_IRQ_PWRON1S_MASK,
},
[S2MPS11_IRQ_MRB] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S2MPS11_IRQ_MRB_MASK,
},
[S2MPS11_IRQ_RTC60S] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S2MPS11_IRQ_RTC60S_MASK,
},
[S2MPS11_IRQ_RTCA1] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S2MPS11_IRQ_RTCA1_MASK,
},
[S2MPS11_IRQ_RTCA2] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S2MPS11_IRQ_RTCA2_MASK,
},
[S2MPS11_IRQ_SMPL] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S2MPS11_IRQ_SMPL_MASK,
},
[S2MPS11_IRQ_RTC1S] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S2MPS11_IRQ_RTC1S_MASK,
},
[S2MPS11_IRQ_WTSR] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S2MPS11_IRQ_WTSR_MASK,
},
[S2MPS11_IRQ_INT120C] = {
-   .reg_offset = 3,
+   .reg_offset = 2,
.mask = S2MPS11_IRQ_INT120C_MASK,
},
[S2MPS11_IRQ_INT140C] = {
-   .reg_offset = 3,
+   .reg_offset = 2,
.mask = S2MPS11_IRQ_INT140C_MASK,
},
 };
@@ -92,146 +92,146 @@ static struct regmap_irq s2mps11_irqs[] = {
 
 static struct regmap_irq s5m8767_irqs[] = {
[S5M8767_IRQ_PWRR] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S5M8767_IRQ_PWRR_MASK,
},
[S5M8767_IRQ_PWRF] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S5M8767_IRQ_PWRF_MASK,
},
[S5M8767_IRQ_PWR1S] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S5M8767_IRQ_PWR1S_MASK,
},
[S5M8767_IRQ_JIGR] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S5M8767_IRQ_JIGR_MASK,
},
[S5M8767_IRQ_JIGF] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S5M8767_IRQ_JIGF_MASK,
},
[S5M8767_IRQ_LOWBAT2] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S5M8767_IRQ_LOWBAT2_MASK,
},
[S5M8767_IRQ_LOWBAT1] = {
-   .reg_offset = 1,
+   .reg_offset = 0,
.mask = S5M8767_IRQ_LOWBAT1_MASK,
},
[S5M8767_IRQ_MRB] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S5M8767_IRQ_MRB_MASK,
},
[S5M8767_IRQ_DVSOK2] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S5M8767_IRQ_DVSOK2_MASK,
},
[S5M8767_IRQ_DVSOK3] = {
-   .reg_offset = 2,
+   .reg_offset = 1,
.mask = S5M8767_IRQ_DVSOK3_MASK,
},
[S5M8767_IRQ_DVSOK4] = {
-   .reg_offset = 2

Re: [PATCH v2 0/4] DMA: PL330: Fix mem leaks and balance probe/remove

2012-10-16 Thread Inderpal Singh
On 13 October 2012 16:33, Jassi Brar jassisinghb...@gmail.com wrote:
 On Fri, Oct 5, 2012 at 3:47 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 The first 2 patches of this series fix memory leaks because the memory
 allocated for peripheral channels and DMA descriptors were not getting
 freed.

 The last 2 patches balance the module's remove function.

 This series depends on 61c6e7531d3b66b3 DMA: PL330: Check the
 pointer returned by kzalloc which is on slave-dma's fixes branch.
 Hence slave-dma tree's next branch was merged with fixes and
 applied patch at [1] to fix the build error.

 [1] http://permalink.gmane.org/gmane.linux.kernel.next/24274

 Changes since v1:
  - Protect only list_add_tail with spin_locks
  - Return EBUSY from remove if channel is in use
  - unregister dma_device in remove

 Inderpal Singh (4):
   DMA: PL330: Free memory allocated for peripheral channels
   DMA: PL330: Change allocation method to properly free  DMA
 descriptors
   DMA: PL330: Balance module remove function with probe
   DMA: PL330: unregister dma_device in module's remove function

  drivers/dma/pl330.c |   53 
 ---
  1 file changed, 38 insertions(+), 15 deletions(-)

 All seem fine.
 Acked-by: Jassi Brar jassisinghb...@gmail.com

Thanks Jassi.

Vinod,
I have tested this series against your latest slave-dma -fixes branch
which is based on 3.7-rc1.
The patchset applies cleanly and works fine.

Thanks,
Inder

 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


[PATCH] DMA: PL330: Add runtime pm support

2012-10-16 Thread Inderpal Singh
At the pl330's probe point the device is already in runtime resume state.
Hence to manage the device with runtime, the probe should do pm_runtime_put
and remove should do pm_runtime_get to balance with probe.

And in between, the device is being get/put at alloc_chan_resources and
free_chan_resources.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
This patch is based on slave-dma's next branch and on top
of the clean up patches at [1].

[1] https://lkml.org/lkml/2012/10/5/169

 drivers/dma/pl330.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 2ee1538..5ae19ea 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -25,6 +25,7 @@
 #include linux/amba/pl330.h
 #include linux/scatterlist.h
 #include linux/of.h
+#include linux/pm_runtime.h
 
 #include dmaengine.h
 #define PL330_MAX_CHAN 8
@@ -2384,6 +2385,8 @@ static int pl330_alloc_chan_resources(struct dma_chan 
*chan)
struct dma_pl330_dmac *pdmac = pch-dmac;
unsigned long flags;
 
+   pm_runtime_get_sync(pdmac-ddma.dev);
+
spin_lock_irqsave(pch-lock, flags);
 
dma_cookie_init(chan);
@@ -2392,6 +2395,7 @@ static int pl330_alloc_chan_resources(struct dma_chan 
*chan)
pch-pl330_chid = pl330_request_channel(pdmac-pif);
if (!pch-pl330_chid) {
spin_unlock_irqrestore(pch-lock, flags);
+   pm_runtime_put(pdmac-ddma.dev);
return -ENOMEM;
}
 
@@ -2470,6 +2474,8 @@ static void pl330_free_chan_resources(struct dma_chan 
*chan)
list_splice_tail_init(pch-work_list, pch-dmac-desc_pool);
 
spin_unlock_irqrestore(pch-lock, flags);
+
+   pm_runtime_put(pch-dmac-ddma.dev);
 }
 
 static enum dma_status
@@ -2974,6 +2980,8 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
pi-pcfg.data_bus_width / 8, pi-pcfg.num_chan,
pi-pcfg.num_peri, pi-pcfg.num_events);
 
+   pm_runtime_put(pd-dev);
+
return 0;
 
 probe_err5:
@@ -3017,6 +3025,8 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
return -EBUSY;
}
 
+   pm_runtime_get(pdmac-ddma.dev);
+
dma_async_device_unregister(pdmac-ddma);
 
amba_set_drvdata(adev, NULL);
-- 
1.7.9.5

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


Re: [PATCH v2 0/4] DMA: PL330: Fix mem leaks and balance probe/remove

2012-10-11 Thread Inderpal Singh
Hello,

On 5 October 2012 06:17, Inderpal Singh inderpal.si...@linaro.org wrote:
 The first 2 patches of this series fix memory leaks because the memory
 allocated for peripheral channels and DMA descriptors were not getting
 freed.

 The last 2 patches balance the module's remove function.

 This series depends on 61c6e7531d3b66b3 DMA: PL330: Check the
 pointer returned by kzalloc which is on slave-dma's fixes branch.
 Hence slave-dma tree's next branch was merged with fixes and
 applied patch at [1] to fix the build error.

 [1] http://permalink.gmane.org/gmane.linux.kernel.next/24274

 Changes since v1:
  - Protect only list_add_tail with spin_locks
  - Return EBUSY from remove if channel is in use
  - unregister dma_device in remove

 Inderpal Singh (4):
   DMA: PL330: Free memory allocated for peripheral channels
   DMA: PL330: Change allocation method to properly free  DMA
 descriptors
   DMA: PL330: Balance module remove function with probe
   DMA: PL330: unregister dma_device in module's remove function

  drivers/dma/pl330.c |   53 
 ---
  1 file changed, 38 insertions(+), 15 deletions(-)


Any comments on this v2 version of the patchset?

Thanks,
Inder

 --
 1.7.9.5

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


[PATCH v2 0/4] DMA: PL330: Fix mem leaks and balance probe/remove

2012-10-05 Thread Inderpal Singh
The first 2 patches of this series fix memory leaks because the memory
allocated for peripheral channels and DMA descriptors were not getting
freed.

The last 2 patches balance the module's remove function.

This series depends on 61c6e7531d3b66b3 DMA: PL330: Check the
pointer returned by kzalloc which is on slave-dma's fixes branch. 
Hence slave-dma tree's next branch was merged with fixes and 
applied patch at [1] to fix the build error.

[1] http://permalink.gmane.org/gmane.linux.kernel.next/24274

Changes since v1:
 - Protect only list_add_tail with spin_locks
 - Return EBUSY from remove if channel is in use
 - unregister dma_device in remove
 
Inderpal Singh (4):
  DMA: PL330: Free memory allocated for peripheral channels
  DMA: PL330: Change allocation method to properly free  DMA
descriptors
  DMA: PL330: Balance module remove function with probe
  DMA: PL330: unregister dma_device in module's remove function

 drivers/dma/pl330.c |   53 ---
 1 file changed, 38 insertions(+), 15 deletions(-)

-- 
1.7.9.5

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


[PATCH v2 3/4] DMA: PL330: Balance module remove function with probe

2012-10-05 Thread Inderpal Singh
Since peripheral channel resources are not being allocated at probe,
no need to flush the channels and free the resources in remove function.
In case, the channel is in use by some client, return EBUSY.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index bf71ff7..4b7a34d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3009,18 +3009,21 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
if (!pdmac)
return 0;
 
+   /* check if any client is using any channel */
+   list_for_each_entry(pch, pdmac-ddma.channels,
+   chan.device_node) {
+
+   if (pch-chan.client_count)
+   return -EBUSY;
+   }
+
amba_set_drvdata(adev, NULL);
 
-   /* Idle the DMAC */
list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
chan.device_node) {
 
/* Remove the channel */
list_del(pch-chan.device_node);
-
-   /* Flush the channel */
-   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
-   pl330_free_chan_resources(pch-chan);
}
 
while (!list_empty(pdmac-desc_pool)) {
-- 
1.7.9.5

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


[PATCH v2 4/4] DMA: PL330: unregister dma_device in module's remove function

2012-10-05 Thread Inderpal Singh
unregister dma_device in module's remove function.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 4b7a34d..e7dc040 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3017,6 +3017,8 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
return -EBUSY;
}
 
+   dma_async_device_unregister(pdmac-ddma);
+
amba_set_drvdata(adev, NULL);
 
list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
-- 
1.7.9.5

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


[PATCH v2 1/4] DMA: PL330: Free memory allocated for peripheral channels

2012-10-05 Thread Inderpal Singh
The allocated memory for peripheral channels is not being freed upon
failure in probe and in module's remove funtion. It will lead to memory
leakage. Hence free the allocated memory.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 2ebd4cd..10c6b6a 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2962,7 +2962,7 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
ret = dma_async_device_register(pd);
if (ret) {
dev_err(adev-dev, unable to register DMAC\n);
-   goto probe_err4;
+   goto probe_err5;
}
 
dev_info(adev-dev,
@@ -2975,6 +2975,8 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
 
return 0;
 
+probe_err5:
+   kfree(pdmac-peripherals);
 probe_err4:
pl330_del(pi);
 probe_err3:
@@ -3025,6 +3027,7 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
res = adev-res;
release_mem_region(res-start, resource_size(res));
 
+   kfree(pdmac-peripherals);
kfree(pdmac);
 
return 0;
-- 
1.7.9.5

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


[PATCH v2 2/4] DMA: PL330: Change allocation method to properly free DMA descriptors

2012-10-05 Thread Inderpal Singh
In probe, memory for multiple DMA descriptors were being allocated at once
and then it was being split and added into DMA pool one by one. The address
of this memory allocation is not being saved anywhere. To free this memory,
the address is required. Initially the first node of the pool will be
pointed by this address but as we use this pool the descs will shuffle and
hence we will lose the track of the address.

This patch does following:

1. Allocates DMA descs one by one and then adds them to pool so that all
   descs can be fetched and memory freed one by one. This way runtime
   added descs can also be freed.
2. Free DMA descs in case of error in probe and in module's remove function

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |   35 +--
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 10c6b6a..bf71ff7 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2541,20 +2541,20 @@ static int add_desc(struct dma_pl330_dmac *pdmac, gfp_t 
flg, int count)
if (!pdmac)
return 0;
 
-   desc = kmalloc(count * sizeof(*desc), flg);
-   if (!desc)
-   return 0;
+   for (i = 0; i  count; i++) {
+   desc = kmalloc(sizeof(*desc), flg);
+   if (!desc)
+   break;
+   _init_desc(desc);
 
-   spin_lock_irqsave(pdmac-pool_lock, flags);
+   spin_lock_irqsave(pdmac-pool_lock, flags);
 
-   for (i = 0; i  count; i++) {
-   _init_desc(desc[i]);
-   list_add_tail(desc[i].node, pdmac-desc_pool);
-   }
+   list_add_tail(desc-node, pdmac-desc_pool);
 
-   spin_unlock_irqrestore(pdmac-pool_lock, flags);
+   spin_unlock_irqrestore(pdmac-pool_lock, flags);
+   }
 
-   return count;
+   return i;
 }
 
 static struct dma_pl330_desc *
@@ -2857,6 +2857,7 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
struct dma_pl330_platdata *pdat;
struct dma_pl330_dmac *pdmac;
struct dma_pl330_chan *pch;
+   struct dma_pl330_desc *desc;
struct pl330_info *pi;
struct dma_device *pd;
struct resource *res;
@@ -2978,6 +2979,12 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
 probe_err5:
kfree(pdmac-peripherals);
 probe_err4:
+   while (!list_empty(pdmac-desc_pool)) {
+   desc = list_entry(pdmac-desc_pool.next,
+   struct dma_pl330_desc, node);
+   list_del(desc-node);
+   kfree(desc);
+   }
pl330_del(pi);
 probe_err3:
free_irq(irq, pi);
@@ -2994,6 +3001,7 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
 {
struct dma_pl330_dmac *pdmac = amba_get_drvdata(adev);
struct dma_pl330_chan *pch, *_p;
+   struct dma_pl330_desc *desc;
struct pl330_info *pi;
struct resource *res;
int irq;
@@ -3015,6 +3023,13 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
pl330_free_chan_resources(pch-chan);
}
 
+   while (!list_empty(pdmac-desc_pool)) {
+   desc = list_entry(pdmac-desc_pool.next,
+   struct dma_pl330_desc, node);
+   list_del(desc-node);
+   kfree(desc);
+   }
+
pi = pdmac-pif;
 
pl330_del(pi);
-- 
1.7.9.5

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


Re: [PATCH 3/3] DMA: PL330: Balance module remove function with probe

2012-09-27 Thread Inderpal Singh
On 27 September 2012 15:18, Vinod Koul vinod.k...@linux.intel.com wrote:
 On Wed, 2012-09-26 at 12:11 +0530, Inderpal Singh wrote:
 If we fail pl330_remove while some client is queued, the force unload
 will fail and the
 force unload will lose its purpose.
 How about conditionally DMA_TERMINATE_ALL and free resources like
 below ?
 Why would you want to remove the driver when it is doing something
 useful? You have to ensure driver is not doing anything.

 What is point here?

As mentioned by jassi,  if the pl330 module is forced unloaded while
some client is queued, we have to manually do DMA_TERMINATE_ALL.

If failing remove is a better option in case some client is queued, we
can do away with DMA_TERMINATE_ALL and free_chan_resources and simply
return a suitable error code from remove.

Kindly suggest.

Thanks,
Inder

 --
 ~Vinod

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


Re: [PATCH 3/3] DMA: PL330: Balance module remove function with probe

2012-09-26 Thread Inderpal Singh
On 25 September 2012 18:47, Jassi Brar jassisinghb...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 Since peripheral channel resources are not being allocated at probe,
 no need to flush the channels and free the resources in remove function.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/dma/pl330.c |8 +---
  1 file changed, 1 insertion(+), 7 deletions(-)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 04d83e6..6f06080 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -3012,16 +3012,10 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)

 /* Idle the DMAC */
 list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
 -   chan.device_node) {
 -
 +   chan.device_node)
 /* Remove the channel */
 list_del(pch-chan.device_node);

 -   /* Flush the channel */
 -   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
 -   pl330_free_chan_resources(pch-chan);
 -   }
 -
 while (!list_empty(pdmac-desc_pool)) {
 desc = list_entry(pdmac-desc_pool.next,
 struct dma_pl330_desc, node);

 I am not sure about this patch. The DMA_TERMINATE_ALL is only called
 by the client and if the pl330 module is forced unloaded while some
 client is queued, we have to manually do DMA_TERMINATE_ALL.
 A better option could be to simply fail pl330_remove if some client is
 queued on the DMAC.

If we fail pl330_remove while some client is queued, the force unload
will fail and the
force unload will lose its purpose.
How about conditionally DMA_TERMINATE_ALL and free resources like below ?

@@ -3017,9 +3017,11 @@ static int __devexit pl330_remove(struct
amba_device *adev)
/* Remove the channel */
list_del(pch-chan.device_node);

-   /* Flush the channel */
-   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
-   pl330_free_chan_resources(pch-chan);
+   if (pch-chan.client_count != 0) {
+   /* Flush the channel */
+   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
+   pl330_free_chan_resources(pch-chan);
+   }
}

while (!list_empty(pdmac-desc_pool)) {


Thanks,
Inder


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


Re: [PATCH 3/3] DMA: PL330: Balance module remove function with probe

2012-09-26 Thread Inderpal Singh
On 26 September 2012 15:02, Jassi Brar jassisinghb...@gmail.com wrote:
 On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:

 How about conditionally DMA_TERMINATE_ALL and free resources like below ?

 @@ -3017,9 +3017,11 @@ static int __devexit pl330_remove(struct
 amba_device *adev)
 /* Remove the channel */
 list_del(pch-chan.device_node);

 -   /* Flush the channel */
 -   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
 -   pl330_free_chan_resources(pch-chan);
 +   if (pch-chan.client_count != 0) {
 +   /* Flush the channel */
 +   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
 +   pl330_free_chan_resources(pch-chan);
 +   }
 }

 It is perfectly safe to flush the channels that have client_count == 0
 as well. Which is already the case.

As per my understanding, if client_count ==0, It may mean following:

1. This channel was never allocated to any client. Hence
alloc_chan_resources was not done for it.
So, no need to flush and free resources if it was never allocated at
the first place. If we free_chan_resources, it will not be balanced
against alloc_chan_resources. Scenario: insmod and then rmmod.

Or,

2. The channel was allocated to some client, alloc_chan_resource was
done, the work for the client is completed and free_chan_resources was
performed. Now  since resources have already been freed, no need to
flush and free_chan_resources again in remove.

The whole idea of this patch is to balance alloc_chan_resources and
free_chan_resources.

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


Re: [PATCH 3/3] DMA: PL330: Balance module remove function with probe

2012-09-26 Thread Inderpal Singh
On 26 September 2012 22:19, Jassi Brar jassisinghb...@gmail.com wrote:
 On Wed, Sep 26, 2012 at 4:25 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 On 26 September 2012 15:02, Jassi Brar jassisinghb...@gmail.com wrote:
 On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:

 How about conditionally DMA_TERMINATE_ALL and free resources like below ?

 @@ -3017,9 +3017,11 @@ static int __devexit pl330_remove(struct
 amba_device *adev)
 /* Remove the channel */
 list_del(pch-chan.device_node);

 -   /* Flush the channel */
 -   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
 -   pl330_free_chan_resources(pch-chan);
 +   if (pch-chan.client_count != 0) {
 +   /* Flush the channel */
 +   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
 +   pl330_free_chan_resources(pch-chan);
 +   }
 }

 It is perfectly safe to flush the channels that have client_count == 0
 as well. Which is already the case.

 As per my understanding, if client_count ==0, It may mean following:

 1. This channel was never allocated to any client. Hence
 alloc_chan_resources was not done for it.
 So, no need to flush and free resources if it was never allocated at
 the first place. If we free_chan_resources, it will not be balanced
 against alloc_chan_resources. Scenario: insmod and then rmmod.

 Or,

 2. The channel was allocated to some client, alloc_chan_resource was
 done, the work for the client is completed and free_chan_resources was
 performed. Now  since resources have already been freed, no need to
 flush and free_chan_resources again in remove.

 The whole idea of this patch is to balance alloc_chan_resources and
 free_chan_resources.

 Do you see any issue with channels that have zero client_count ?

As I explained in my previous mail, If the client_count is zero,
either the alloc_chan_resources is not done(or failed) for that
channel or the free_chan_resource have already been done. Please refer
below code from dmaengine.c

static void dma_chan_put(struct dma_chan *chan)
{
if (!chan-client_count)
return; /* this channel failed alloc_chan_resources */
chan-client_count--;
module_put(dma_chan_to_owner(chan));
if (chan-client_count == 0)
chan-device-device_free_chan_resources(chan);
}

As you mentioned channel flush is needed if some client is queued and
force unload happens.
I am not against flushing and freeing channels. I am __only__
suggesting to flush and free channels for which alloc_chan_resource
was successful, which can be decided by chan-client_count as being
done in above function.

Don't you think free_chan_resource should be done __only if__
alloc_chan_resource was successful ?

Thanks,
Inder

 AFAIU there are already enough checks in the path to weed out unused
 channels, so let us please not uglify the code by adding new
 unnecessary checks.

 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


Re: [PATCH 3/3] DMA: PL330: Balance module remove function with probe

2012-09-26 Thread Inderpal Singh
On 27 September 2012 10:35, Jassi Brar jassisinghb...@gmail.com wrote:
 On Thu, Sep 27, 2012 at 9:43 AM, Inderpal Singh
 inderpal.si...@linaro.org wrote:

 Don't you think free_chan_resource should be done __only if__
 alloc_chan_resource was successful ?

 No, I don't think so. Thanks.

Thanks for quick response.
Please elaborate more on this as I find it against the general rule
and against the dmaengine implementation which checks on the same
condition before proceeding for free_chan_resouces in dma_chan_put
function.

Thanks,
Inder
--
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/3] DMA: PL330: Change allocation method to properly free DMA descriptors

2012-09-25 Thread Inderpal Singh
In probe, memory for multiple DMA descriptors were being allocated at once
and then it was being split and added into DMA pool one by one. The address
of this memory allocation is not being saved anywhere. To free this memory,
the address is required. Initially the first node of the pool will be
pointed by this address but as we use this pool the descs will shuffle and
hence we will lose the track of the address.

This patch does following:

1. Allocates DMA descs one by one and then adds them to pool so that all
   descs can be fetched and memory freed one by one. This way runtime
   added descs can also be freed.
2. Free DMA descs in case of error in probe and in module's remove function

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |   28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 10c6b6a..04d83e6 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2541,20 +2541,19 @@ static int add_desc(struct dma_pl330_dmac *pdmac, gfp_t 
flg, int count)
if (!pdmac)
return 0;
 
-   desc = kmalloc(count * sizeof(*desc), flg);
-   if (!desc)
-   return 0;
-
spin_lock_irqsave(pdmac-pool_lock, flags);
 
for (i = 0; i  count; i++) {
-   _init_desc(desc[i]);
-   list_add_tail(desc[i].node, pdmac-desc_pool);
+   desc = kmalloc(sizeof(*desc), flg);
+   if (!desc)
+   break;
+   _init_desc(desc);
+   list_add_tail(desc-node, pdmac-desc_pool);
}
 
spin_unlock_irqrestore(pdmac-pool_lock, flags);
 
-   return count;
+   return i;
 }
 
 static struct dma_pl330_desc *
@@ -2857,6 +2856,7 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
struct dma_pl330_platdata *pdat;
struct dma_pl330_dmac *pdmac;
struct dma_pl330_chan *pch;
+   struct dma_pl330_desc *desc;
struct pl330_info *pi;
struct dma_device *pd;
struct resource *res;
@@ -2978,6 +2978,12 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
 probe_err5:
kfree(pdmac-peripherals);
 probe_err4:
+   while (!list_empty(pdmac-desc_pool)) {
+   desc = list_entry(pdmac-desc_pool.next,
+   struct dma_pl330_desc, node);
+   list_del(desc-node);
+   kfree(desc);
+   }
pl330_del(pi);
 probe_err3:
free_irq(irq, pi);
@@ -2994,6 +3000,7 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
 {
struct dma_pl330_dmac *pdmac = amba_get_drvdata(adev);
struct dma_pl330_chan *pch, *_p;
+   struct dma_pl330_desc *desc;
struct pl330_info *pi;
struct resource *res;
int irq;
@@ -3015,6 +3022,13 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
pl330_free_chan_resources(pch-chan);
}
 
+   while (!list_empty(pdmac-desc_pool)) {
+   desc = list_entry(pdmac-desc_pool.next,
+   struct dma_pl330_desc, node);
+   list_del(desc-node);
+   kfree(desc);
+   }
+
pi = pdmac-pif;
 
pl330_del(pi);
-- 
1.7.9.5

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


[PATCH 3/3] DMA: PL330: Balance module remove function with probe

2012-09-25 Thread Inderpal Singh
Since peripheral channel resources are not being allocated at probe,
no need to flush the channels and free the resources in remove function.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 04d83e6..6f06080 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3012,16 +3012,10 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
 
/* Idle the DMAC */
list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
-   chan.device_node) {
-
+   chan.device_node)
/* Remove the channel */
list_del(pch-chan.device_node);
 
-   /* Flush the channel */
-   pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
-   pl330_free_chan_resources(pch-chan);
-   }
-
while (!list_empty(pdmac-desc_pool)) {
desc = list_entry(pdmac-desc_pool.next,
struct dma_pl330_desc, node);
-- 
1.7.9.5

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


[PATCH 0/3] DMA: PL330: Fix mem leaks and balance probe/remove

2012-09-25 Thread Inderpal Singh
The first 2 patches of this series fix memory leaks because the memory
allocated for peripheral channels and DMA descriptors were not getting
freed.

The third patch balances the module's remove function.

This patchset is based on slave-dma tree's next branch merged with
fixes branch and applied patch at [1] to fix the build error.

[1] http://permalink.gmane.org/gmane.linux.kernel.next/24274

Inderpal Singh (3):
  DMA: PL330: Free memory allocated for peripheral channels
  DMA: PL330: Change allocation method to properly free DMA descriptors
  DMA: PL330: Balance module remove function with probe

 drivers/dma/pl330.c |   37 -
 1 file changed, 24 insertions(+), 13 deletions(-)

-- 
1.7.9.5

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



[PATCH 1/3] DMA: PL330: Free memory allocated for peripheral channels

2012-09-25 Thread Inderpal Singh
The allocated memory for peripheral channels is not being freed upon
failure in probe and in module's remove funtion. It will lead to memory
leakage. Hence free the allocated memory.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 2ebd4cd..10c6b6a 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2962,7 +2962,7 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
ret = dma_async_device_register(pd);
if (ret) {
dev_err(adev-dev, unable to register DMAC\n);
-   goto probe_err4;
+   goto probe_err5;
}
 
dev_info(adev-dev,
@@ -2975,6 +2975,8 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
 
return 0;
 
+probe_err5:
+   kfree(pdmac-peripherals);
 probe_err4:
pl330_del(pi);
 probe_err3:
@@ -3025,6 +3027,7 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
res = adev-res;
release_mem_region(res-start, resource_size(res));
 
+   kfree(pdmac-peripherals);
kfree(pdmac);
 
return 0;
-- 
1.7.9.5

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


Re: [PATCH 1/3] DMA: PL330: Free memory allocated for peripheral channels

2012-09-25 Thread Inderpal Singh
On 25 September 2012 18:17, Jassi Brar jassisinghb...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 The allocated memory for peripheral channels is not being freed upon
 failure in probe and in module's remove funtion. It will lead to memory
 leakage. Hence free the allocated memory.

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/dma/pl330.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 2ebd4cd..10c6b6a 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -2962,7 +2962,7 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
 ret = dma_async_device_register(pd);
 if (ret) {
 dev_err(adev-dev, unable to register DMAC\n);
 -   goto probe_err4;
 +   goto probe_err5;
 }

 Sorry this patch seems malformed. Against which tree did you prepare it ?

This patch depends on 61c6e7531d3b66b3 DMA: PL330: Check the
pointer returned by kzalloc which is on vinod's slave-dma's fixes
branch. So I merged slave-dma's next and fixes branches. Now after
merging, build error occurs due to some conflict so I had to apply the
patch sent by Sachin at [1]

Same had been mentioned in the cover letter.

[1] http://permalink.gmane.org/gmane.linux.kernel.next/24274

Thanks,
Inder

 -jassi



 dev_info(adev-dev,
 @@ -2975,6 +2975,8 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)

 return 0;

 +probe_err5:
 +   kfree(pdmac-peripherals);
  probe_err4:
 pl330_del(pi);
  probe_err3:
 @@ -3025,6 +3027,7 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)
 res = adev-res;
 release_mem_region(res-start, resource_size(res));

 +   kfree(pdmac-peripherals);
 kfree(pdmac);

 return 0;
 --
 1.7.9.5

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


Re: [PATCH 2/3] DMA: PL330: Change allocation method to properly free DMA descriptors

2012-09-25 Thread Inderpal Singh
On 25 September 2012 18:39, Jassi Brar jassisinghb...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
 inderpal.si...@linaro.org wrote:
 In probe, memory for multiple DMA descriptors were being allocated at once
 and then it was being split and added into DMA pool one by one. The address
 of this memory allocation is not being saved anywhere. To free this memory,
 the address is required. Initially the first node of the pool will be
 pointed by this address but as we use this pool the descs will shuffle and
 hence we will lose the track of the address.

 This patch does following:

 1. Allocates DMA descs one by one and then adds them to pool so that all
descs can be fetched and memory freed one by one. This way runtime
added descs can also be freed.
 2. Free DMA descs in case of error in probe and in module's remove function

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  drivers/dma/pl330.c |   28 +---
  1 file changed, 21 insertions(+), 7 deletions(-)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 10c6b6a..04d83e6 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -2541,20 +2541,19 @@ static int add_desc(struct dma_pl330_dmac *pdmac, 
 gfp_t flg, int count)
 if (!pdmac)
 return 0;

 -   desc = kmalloc(count * sizeof(*desc), flg);
 -   if (!desc)
 -   return 0;
 -
 spin_lock_irqsave(pdmac-pool_lock, flags);

 for (i = 0; i  count; i++) {
 -   _init_desc(desc[i]);
 -   list_add_tail(desc[i].node, pdmac-desc_pool);
 +   desc = kmalloc(sizeof(*desc), flg);
 +   if (!desc)
 +   break;
 +   _init_desc(desc);
 +   list_add_tail(desc-node, pdmac-desc_pool);
 }

 spin_unlock_irqrestore(pdmac-pool_lock, flags);

 -   return count;
 +   return i;
  }

 OK, but the kmalloc shouldn't be done with irqs disabled. Please
 protect only the list_add_tail()

Yes, I missed it. I will update and send it again.

Thanks,
Inder

 thanks.

  static struct dma_pl330_desc *
 @@ -2857,6 +2856,7 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
 struct dma_pl330_platdata *pdat;
 struct dma_pl330_dmac *pdmac;
 struct dma_pl330_chan *pch;
 +   struct dma_pl330_desc *desc;
 struct pl330_info *pi;
 struct dma_device *pd;
 struct resource *res;
 @@ -2978,6 +2978,12 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
  probe_err5:
 kfree(pdmac-peripherals);
  probe_err4:
 +   while (!list_empty(pdmac-desc_pool)) {
 +   desc = list_entry(pdmac-desc_pool.next,
 +   struct dma_pl330_desc, node);
 +   list_del(desc-node);
 +   kfree(desc);
 +   }
 pl330_del(pi);
  probe_err3:
 free_irq(irq, pi);
 @@ -2994,6 +3000,7 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)
  {
 struct dma_pl330_dmac *pdmac = amba_get_drvdata(adev);
 struct dma_pl330_chan *pch, *_p;
 +   struct dma_pl330_desc *desc;
 struct pl330_info *pi;
 struct resource *res;
 int irq;
 @@ -3015,6 +3022,13 @@ static int __devexit pl330_remove(struct amba_device 
 *adev)
 pl330_free_chan_resources(pch-chan);
 }

 +   while (!list_empty(pdmac-desc_pool)) {
 +   desc = list_entry(pdmac-desc_pool.next,
 +   struct dma_pl330_desc, node);
 +   list_del(desc-node);
 +   kfree(desc);
 +   }
 +
 pi = pdmac-pif;

 pl330_del(pi);
 --
 1.7.9.5

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


[PATCH] DMA: PL330: return ENOMEM instead of 0 from pl330_alloc_chan_resources

2012-09-16 Thread Inderpal Singh
Since 0 is not considered as error at dmaengine level, return ENOMEM
from pl330_alloc_chan_resources in case of failure.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index e4feba6..14d881c 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2393,7 +2393,7 @@ static int pl330_alloc_chan_resources(struct dma_chan 
*chan)
pch-pl330_chid = pl330_request_channel(pdmac-pif);
if (!pch-pl330_chid) {
spin_unlock_irqrestore(pch-lock, flags);
-   return 0;
+   return -ENOMEM;
}
 
tasklet_init(pch-task, pl330_tasklet, (unsigned long) pch);
-- 
1.7.9.5

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


Re: [PATCH] ARM: EXYNOS4: Fix soft reboot hang after suspend/resume

2012-09-13 Thread Inderpal Singh
Hi Kukjin,

On 15 May 2012 10:01, Inderpal Singh inderpal.si...@linaro.org wrote:
 Hi Kukjin,

 On 14 May 2012 19:13, Kukjin Kim kgene@samsung.com wrote:
 On 05/14/12 17:42, Inderpal Singh wrote:

 Hi Kukjin,

 On 14 May 2012 13:45, Kukjin Kimkgene@samsung.com  wrote:

 Inderpal Singh wrote:


 Upon wake-up, clear the sleep mode set in INFORM1 register.

 Is this for wake-up or _really_ software reset? And is this available on
 all
 of EXYNOS4 SoCs?


 This is for soft reboot hang after one cycle of suspend/resume is
 complete.
 And yes this is applicable for all exynos SOCs.

 Hi,

 As I know, we don't need it for all of EXYNOS SoCs but let me check about
 the situation you said with hardware engineer tomorrow. If any updates, let
 you know.



Any updates on this ?
As i mentioned below, Its applicable for Origen, Pegasus and 5250 as well.

 The issue happens because u-boot checks INFROM1 register to know if
 its wake-up from sleep. Hence if INFORM1 is not cleared, the soft
 reboot after one suspend/resume cycle will be understood by u-boot as
 wake-up from sleep, so it will try to resume and will hang up.

 I have faced this issue on Origen, Pegasus SMDK and 5250 SMDK.

 Thanks,
 Inder


 Thanks.

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

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


[PATCH 0/2] DMA: PL330: Clock and runtime cleanup

2012-09-07 Thread Inderpal Singh
The controller clock is being managed at AMBA bus level probe/remove and
pm_runtime/suspend functions. The existing driver does the clock enable/disable
again in the same code paths, which unneccessarily increments the usage count of
the clock for the same device. 

The following patches remove the redundant clock enable/disable from the driver.

Inderpal Singh (2):
  DMA: PL330: Remove controller clock enable/disable
  DMA: PL330: Remove redundant runtime_suspend/resume functions

 drivers/dma/pl330.c |   73 ---
 1 file changed, 5 insertions(+), 68 deletions(-)

-- 
1.7.9.5

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


[PATCH 1/2] DMA: PL330: Remove controller clock enable/disable

2012-09-07 Thread Inderpal Singh
The controller clock is being enabled/disabled in AMBA bus
infrastructre in probe/remove functions. Hence, its not required
at driver level probe/remove.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |   12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index e4feba6..f70e783 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2896,11 +2896,6 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
 
amba_set_drvdata(adev, pdmac);
 
-#ifndef CONFIG_PM_RUNTIME
-   /* enable dma clk */
-   clk_enable(pdmac-clk);
-#endif
-
irq = adev-irq[0];
ret = request_irq(irq, pl330_irq_handler, 0,
dev_name(adev-dev), pi);
@@ -2987,9 +2982,6 @@ probe_err5:
 probe_err4:
free_irq(irq, pi);
 probe_err3:
-#ifndef CONFIG_PM_RUNTIME
-   clk_disable(pdmac-clk);
-#endif
clk_put(pdmac-clk);
 probe_err2:
iounmap(pi-base);
@@ -3037,10 +3029,6 @@ static int __devexit pl330_remove(struct amba_device 
*adev)
res = adev-res;
release_mem_region(res-start, resource_size(res));
 
-#ifndef CONFIG_PM_RUNTIME
-   clk_disable(pdmac-clk);
-#endif
-
kfree(pdmac);
 
return 0;
-- 
1.7.9.5

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


[PATCH 2/2] DMA: PL330: Remove redundant runtime_suspend/resume functions

2012-09-07 Thread Inderpal Singh
The driver's  runtime_suspend/resume functions just disable/enable
the clock which is already being managed at AMBA bus level
runtime_suspend/resume functions.

Hence, remove the driver's runtime_suspend/resume functions.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 drivers/dma/pl330.c |   61 +--
 1 file changed, 5 insertions(+), 56 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index f70e783..d9e1433 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -23,7 +23,6 @@
 #include linux/dmaengine.h
 #include linux/amba/bus.h
 #include linux/amba/pl330.h
-#include linux/pm_runtime.h
 #include linux/scatterlist.h
 #include linux/of.h
 
@@ -586,8 +585,6 @@ struct dma_pl330_dmac {
 
/* Peripheral channels connected to this DMAC */
struct dma_pl330_chan *peripherals; /* keep at end */
-
-   struct clk *clk;
 };
 
 struct dma_pl330_desc {
@@ -2887,24 +2884,17 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
goto probe_err1;
}
 
-   pdmac-clk = clk_get(adev-dev, dma);
-   if (IS_ERR(pdmac-clk)) {
-   dev_err(adev-dev, Cannot get operation clock.\n);
-   ret = -EINVAL;
-   goto probe_err2;
-   }
-
amba_set_drvdata(adev, pdmac);
 
irq = adev-irq[0];
ret = request_irq(irq, pl330_irq_handler, 0,
dev_name(adev-dev), pi);
if (ret)
-   goto probe_err3;
+   goto probe_err2;
 
ret = pl330_add(pi);
if (ret)
-   goto probe_err4;
+   goto probe_err3;
 
INIT_LIST_HEAD(pdmac-desc_pool);
spin_lock_init(pdmac-pool_lock);
@@ -2964,7 +2954,7 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
ret = dma_async_device_register(pd);
if (ret) {
dev_err(adev-dev, unable to register DMAC\n);
-   goto probe_err5;
+   goto probe_err4;
}
 
dev_info(adev-dev,
@@ -2977,12 +2967,10 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
 
return 0;
 
-probe_err5:
-   pl330_del(pi);
 probe_err4:
-   free_irq(irq, pi);
+   pl330_del(pi);
 probe_err3:
-   clk_put(pdmac-clk);
+   free_irq(irq, pi);
 probe_err2:
iounmap(pi-base);
 probe_err1:
@@ -3044,49 +3032,10 @@ static struct amba_id pl330_ids[] = {
 
 MODULE_DEVICE_TABLE(amba, pl330_ids);
 
-#ifdef CONFIG_PM_RUNTIME
-static int pl330_runtime_suspend(struct device *dev)
-{
-   struct dma_pl330_dmac *pdmac = dev_get_drvdata(dev);
-
-   if (!pdmac) {
-   dev_err(dev, failed to get dmac\n);
-   return -ENODEV;
-   }
-
-   clk_disable(pdmac-clk);
-
-   return 0;
-}
-
-static int pl330_runtime_resume(struct device *dev)
-{
-   struct dma_pl330_dmac *pdmac = dev_get_drvdata(dev);
-
-   if (!pdmac) {
-   dev_err(dev, failed to get dmac\n);
-   return -ENODEV;
-   }
-
-   clk_enable(pdmac-clk);
-
-   return 0;
-}
-#else
-#define pl330_runtime_suspend  NULL
-#define pl330_runtime_resume   NULL
-#endif /* CONFIG_PM_RUNTIME */
-
-static const struct dev_pm_ops pl330_pm_ops = {
-   .runtime_suspend = pl330_runtime_suspend,
-   .runtime_resume = pl330_runtime_resume,
-};
-
 static struct amba_driver pl330_driver = {
.drv = {
.owner = THIS_MODULE,
.name = dma-pl330,
-   .pm = pl330_pm_ops,
},
.id_table = pl330_ids,
.probe = pl330_probe,
-- 
1.7.9.5

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


Re: [PATCH] ARM: EXYNOS4: Fix soft reboot hang after suspend/resume

2012-05-14 Thread Inderpal Singh
Hi Kukjin,

On 14 May 2012 13:45, Kukjin Kim kgene@samsung.com wrote:
 Inderpal Singh wrote:

 Upon wake-up, clear the sleep mode set in INFORM1 register.

 Is this for wake-up or _really_ software reset? And is this available on all
 of EXYNOS4 SoCs?

This is for soft reboot hang after one cycle of suspend/resume is complete.
And yes this is applicable for all exynos SOCs.

With Regards,
Inder


 Thanks.

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

 Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
 ---
  arch/arm/mach-exynos/pm.c |    4 
  1 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
 index f0bb467..16cba3f 100644
 --- a/arch/arm/mach-exynos/pm.c
 +++ b/arch/arm/mach-exynos/pm.c
 @@ -381,6 +381,10 @@ static void exynos4_pm_resume(void)
  #endif

  early_wakeup:
 +
 +     /* Clear SLEEP mode set in INFORM1 */
 +     __raw_writel(0x0, S5P_INFORM1);
 +
       return;
  }


 --
 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: EXYNOS4: Fix soft reboot hang after suspend/resume

2012-05-14 Thread Inderpal Singh
Hi Kukjin,

On 14 May 2012 19:13, Kukjin Kim kgene@samsung.com wrote:
 On 05/14/12 17:42, Inderpal Singh wrote:

 Hi Kukjin,

 On 14 May 2012 13:45, Kukjin Kimkgene@samsung.com  wrote:

 Inderpal Singh wrote:


 Upon wake-up, clear the sleep mode set in INFORM1 register.

 Is this for wake-up or _really_ software reset? And is this available on
 all
 of EXYNOS4 SoCs?


 This is for soft reboot hang after one cycle of suspend/resume is
 complete.
 And yes this is applicable for all exynos SOCs.

 Hi,

 As I know, we don't need it for all of EXYNOS SoCs but let me check about
 the situation you said with hardware engineer tomorrow. If any updates, let
 you know.


The issue happens because u-boot checks INFROM1 register to know if
its wake-up from sleep. Hence if INFORM1 is not cleared, the soft
reboot after one suspend/resume cycle will be understood by u-boot as
wake-up from sleep, so it will try to resume and will hang up.

I have faced this issue on Origen, Pegasus SMDK and 5250 SMDK.

Thanks,
Inder


 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


[PATCH] ARM: EXYNOS4: Fix soft reboot hang after suspend/resume

2012-03-28 Thread Inderpal Singh
Upon wake-up, clear the sleep mode set in INFORM1 register.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 arch/arm/mach-exynos/pm.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index f0bb467..16cba3f 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -381,6 +381,10 @@ static void exynos4_pm_resume(void)
 #endif
 
 early_wakeup:
+
+   /* Clear SLEEP mode set in INFORM1 */
+   __raw_writel(0x0, S5P_INFORM1);
+
return;
 }
 
-- 
1.7.5.4

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


[PATCH] ARM: EXYNOS4: Support Suspend/Resume for EXYNOS4412

2012-03-28 Thread Inderpal Singh
This patch provides the suspend/resume support for EXYNOS4412.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
 arch/arm/mach-exynos/include/mach/regs-pmu.h |   10 +-
 arch/arm/mach-exynos/pm.c|2 +-
 arch/arm/mach-exynos/pmu.c   |   24 
 3 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h 
b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 4c53f38..606b199 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -177,7 +177,7 @@
 
 #define S5P_PMU_LCD1_CONF  S5P_PMUREG(0x3CA0)
 
-/* Only for EXYNOS4212 */
+/* Only for EXYNOS4x12 */
 #define S5P_ISP_ARM_LOWPWR S5P_PMUREG(0x1050)
 #define S5P_DIS_IRQ_ISP_ARM_LOCAL_LOWPWR   S5P_PMUREG(0x1054)
 #define S5P_DIS_IRQ_ISP_ARM_CENTRAL_LOWPWR S5P_PMUREG(0x1058)
@@ -218,4 +218,12 @@
 #define S5P_SECSS_MEM_OPTION   S5P_PMUREG(0x2EC8)
 #define S5P_ROTATOR_MEM_OPTION S5P_PMUREG(0x2F48)
 
+/* Only for EXYNOS4412 */
+#define S5P_ARM_CORE2_LOWPWR   S5P_PMUREG(0x1020)
+#define S5P_DIS_IRQ_CORE2  S5P_PMUREG(0x1024)
+#define S5P_DIS_IRQ_CENTRAL2   S5P_PMUREG(0x1028)
+#define S5P_ARM_CORE3_LOWPWR   S5P_PMUREG(0x1030)
+#define S5P_DIS_IRQ_CORE3  S5P_PMUREG(0x1034)
+#define S5P_DIS_IRQ_CENTRAL3   S5P_PMUREG(0x1038)
+
 #endif /* __ASM_ARCH_REGS_PMU_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 428cfeb..f0bb467 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -313,7 +313,7 @@ static int exynos4_pm_suspend(void)
tmp = ~S5P_CENTRAL_LOWPWR_CFG;
__raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
 
-   if (soc_is_exynos4212()) {
+   if (soc_is_exynos4212() || soc_is_exynos4412()) {
tmp = __raw_readl(S5P_CENTRAL_SEQ_OPTION);
tmp = ~(S5P_USE_STANDBYWFI_ISP_ARM |
 S5P_USE_STANDBYWFE_ISP_ARM);
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index bba48f5..77c6815 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -94,7 +94,7 @@ static struct exynos4_pmu_conf exynos4210_pmu_config[] = {
{ PMU_TABLE_END,},
 };
 
-static struct exynos4_pmu_conf exynos4212_pmu_config[] = {
+static struct exynos4_pmu_conf exynos4x12_pmu_config[] = {
{ S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
{ S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
{ S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
@@ -202,6 +202,16 @@ static struct exynos4_pmu_conf exynos4212_pmu_config[] = {
{ PMU_TABLE_END,},
 };
 
+static struct exynos4_pmu_conf exynos4412_pmu_config[] = {
+   { S5P_ARM_CORE2_LOWPWR, { 0x0, 0x0, 0x2 } },
+   { S5P_DIS_IRQ_CORE2,{ 0x0, 0x0, 0x0 } },
+   { S5P_DIS_IRQ_CENTRAL2, { 0x0, 0x0, 0x0 } },
+   { S5P_ARM_CORE3_LOWPWR, { 0x0, 0x0, 0x2 } },
+   { S5P_DIS_IRQ_CORE3,{ 0x0, 0x0, 0x0 } },
+   { S5P_DIS_IRQ_CENTRAL3, { 0x0, 0x0, 0x0 } },
+   { PMU_TABLE_END,},
+};
+
 void exynos4_sys_powerdown_conf(enum sys_powerdown mode)
 {
unsigned int i;
@@ -209,6 +219,12 @@ void exynos4_sys_powerdown_conf(enum sys_powerdown mode)
for (i = 0; (exynos4_pmu_config[i].reg != PMU_TABLE_END) ; i++)
__raw_writel(exynos4_pmu_config[i].val[mode],
exynos4_pmu_config[i].reg);
+
+   if (soc_is_exynos4412()) {
+   for (i = 0; exynos4412_pmu_config[i].reg != PMU_TABLE_END ; i++)
+   __raw_writel(exynos4412_pmu_config[i].val[mode],
+   exynos4412_pmu_config[i].reg);
+   }
 }
 
 static int __init exynos4_pmu_init(void)
@@ -218,9 +234,9 @@ static int __init exynos4_pmu_init(void)
if (soc_is_exynos4210()) {
exynos4_pmu_config = exynos4210_pmu_config;
pr_info(EXYNOS4210 PMU Initialize\n);
-   } else if (soc_is_exynos4212()) {
-   exynos4_pmu_config = exynos4212_pmu_config;
-   pr_info(EXYNOS4212 PMU Initialize\n);
+   } else if (soc_is_exynos4212() || soc_is_exynos4412()) {
+   exynos4_pmu_config = exynos4x12_pmu_config;
+   pr_info(EXYNOS4x12 PMU Initialize\n);
} else {
pr_info(EXYNOS4: PMU not supported\n);
}
-- 
1.7.5.4

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


Re: [PATCH V3 1/6] ARM: exynos: Add AFTR mode cpuidle state on EXYNOS4210

2011-11-23 Thread Inderpal Singh
Hi Amit,

On 22 November 2011 15:05, Amit Daniel Kachhap amit.kach...@linaro.org wrote:

 This patch adds support AFTR(ARM OFF TOP RUNNING) mode in
 cpuidle driver. L2 cache keeps their data in this mode.
 This patch ports the code to the latest interfaces to
 save/restore CPU state inclusive of CPU PM notifiers, l2
 resume and cpu_suspend/resume.

 Signed-off-by: Jaecheol Lee jc@samsung.com
 Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
 Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
 ---
  arch/arm/mach-exynos/cpuidle.c          |  152 
 ++-
  arch/arm/mach-exynos/include/mach/pmu.h |    2 +
  2 files changed, 151 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
 index 21403c8..89afa93 100644
 --- a/arch/arm/mach-exynos/cpuidle.c
 +++ b/arch/arm/mach-exynos/cpuidle.c
 @@ -12,15 +12,37 @@
  #include linux/module.h
  #include linux/init.h
  #include linux/cpuidle.h
 +#include linux/cpu_pm.h
  #include linux/io.h
  #include linux/export.h
  #include linux/time.h

  #include asm/proc-fns.h
 +#include asm/smp_scu.h
 +#include asm/suspend.h
 +#include asm/unified.h
 +#include mach/regs-pmu.h
 +#include mach/pmu.h
 +
 +#include plat/exynos4.h
 +#include plat/cpu.h
 +
 +#define REG_DIRECTGO_ADDR      (samsung_rev() == EXYNOS4210_REV_1_1 ? \
 +                       S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
 +                       (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
 +#define REG_DIRECTGO_FLAG      (samsung_rev() == EXYNOS4210_REV_1_1 ? \
 +                       S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
 +                       (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
 +
 +#define S5P_CHECK_AFTR         (samsung_rev() == EXYNOS4210_REV_1_0 ? \
 +                               0xBAD0 : 0xFCBA0D10)

  static int exynos4_enter_idle(struct cpuidle_device *dev,
                        struct cpuidle_driver *drv,
                              int index);
 +static int exynos4_enter_lowpower(struct cpuidle_device *dev,
 +                               struct cpuidle_driver *drv,
 +                               int index);

  static struct cpuidle_state exynos4_cpuidle_set[] = {
        [0] = {
 @@ -28,9 +50,17 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
                .exit_latency           = 1,
                .target_residency       = 10,
                .flags                  = CPUIDLE_FLAG_TIME_VALID,
 -               .name                   = IDLE,
 +               .name                   = C0,
                .desc                   = ARM clock gating(WFI),
        },
 +       [1] = {
 +               .enter                  = exynos4_enter_lowpower,
 +               .exit_latency           = 300,
 +               .target_residency       = 10,
 +               .flags                  = CPUIDLE_FLAG_TIME_VALID,
 +               .name                   = C1,
 +               .desc                   = ARM power down,
 +       },
  };

  static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
 @@ -40,9 +70,101 @@ static struct cpuidle_driver exynos4_idle_driver = {
        .owner          = THIS_MODULE,
  };

 +/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
 +static void exynos4_set_wakeupmask(void)
 +{
 +       __raw_writel(0xff3e, S5P_WAKEUP_MASK);
 +}
 +
 +static unsigned int g_pwr_ctrl, g_diag_reg;
 +
 +static void save_cpu_arch_register(void)
 +{
 +       /*read power control register*/
 +       asm(mrc p15, 0, %0, c15, c0, 0 : =r(g_pwr_ctrl) : : cc);
 +       /*read diagnostic register*/
 +       asm(mrc p15, 0, %0, c15, c0, 1 : =r(g_diag_reg) : : cc);
 +       return;
 +}
 +
 +static void restore_cpu_arch_register(void)
 +{
 +       /*write power control register*/
 +       asm(mcr p15, 0, %0, c15, c0, 0 : : r(g_pwr_ctrl) : cc);
 +       /*write diagnostic register*/
 +       asm(mcr p15, 0, %0, c15, c0, 1 : : r(g_diag_reg) : cc);
 +       return;
 +}
 +
 +static int idle_finisher(unsigned long flags)
 +{
 +       cpu_do_idle();
 +       return 1;
 +}
 +
 +static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
 +                               struct cpuidle_driver *drv,
 +                               int index)
 +{
 +       struct timeval before, after;
 +       int idle_time;
 +       unsigned long tmp;
 +
 +       local_irq_disable();
 +       do_gettimeofday(before);
 +
 +       exynos4_set_wakeupmask();
 +
 +       /* Set value of power down register for aftr mode */
 +       exynos4_sys_powerdown_conf(SYS_AFTR);
 +
 +       __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)),
 +                                                REG_DIRECTGO_ADDR);
 +       __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
 +
 +       save_cpu_arch_register();
 +
 +       /* Setting Central Sequence Register for power down mode */
 +       tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
 +       tmp = 

[PATCH] ARM: SAMSUNG: Save/restore GPIO drive strength across suspend/resume

2011-11-11 Thread Inderpal Singh
GPIO driver strength settings are not preserved across suspend/resume
for s5pc100, s5pv210 and Exynos platforms which has been the cause of
mmc/sd card read/write failures after resume. Fix this by saving and
restoring the GPIO driver strength register settings across suspend/resume.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
1. This change is applicable only for s5pc100, s5pv210 and Exynos
platforms. For all other platforms, the driver strength registers are
part of special port configuration register (SPCON) and these
registers are saved and restored separately from the GPIO bank
registers. For s5pc100, s5pv210 and Exynos platforms, the driver
strength values are saved along with the GPIO bank registers.

2. An additional entry is added to the 'pm_save' array of 'struct
samsung_gpio_chip' for saving driver strength values.

3. Tested with v210 and v310 smdk boards

 arch/arm/plat-samsung/include/plat/gpio-core.h |2 +-
 arch/arm/plat-samsung/pm-gpio.c|   13 +++--
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/gpio-core.h 
b/arch/arm/plat-samsung/include/plat/gpio-core.h
index 1fe6917..8871b4c 100644
--- a/arch/arm/plat-samsung/include/plat/gpio-core.h
+++ b/arch/arm/plat-samsung/include/plat/gpio-core.h
@@ -69,7 +69,7 @@ struct samsung_gpio_chip {
int group;
spinlock_t   lock;
 #ifdef CONFIG_PM
-   u32 pm_save[4];
+   u32 pm_save[5];
 #endif
 };
 
diff --git a/arch/arm/plat-samsung/pm-gpio.c b/arch/arm/plat-samsung/pm-gpio.c
index 4be016e..5493f38 100644
--- a/arch/arm/plat-samsung/pm-gpio.c
+++ b/arch/arm/plat-samsung/pm-gpio.c
@@ -21,12 +21,14 @@
 
 #include plat/gpio-core.h
 #include plat/pm.h
+#include plat/cpu.h
 
 /* PM GPIO helpers */
 
 #define OFFS_CON   (0x00)
 #define OFFS_DAT   (0x04)
 #define OFFS_UP(0x08)
+#define OFFS_DRV_STRGTH(0x0C)
 
 static void samsung_gpio_pm_1bit_save(struct samsung_gpio_chip *chip)
 {
@@ -199,6 +201,9 @@ static void samsung_gpio_pm_4bit_save(struct 
samsung_gpio_chip *chip)
chip-pm_save[2] = __raw_readl(chip-base + OFFS_DAT);
chip-pm_save[3] = __raw_readl(chip-base + OFFS_UP);
 
+   if (soc_is_s5pc100() || soc_is_s5pv210() || soc_is_exynos4210())
+   chip-pm_save[4] = __raw_readl(chip-base + OFFS_DRV_STRGTH);
+
if (chip-chip.ngpio  8)
chip-pm_save[0] = __raw_readl(chip-base - 4);
 }
@@ -285,6 +290,9 @@ static void samsung_gpio_pm_4bit_resume(struct 
samsung_gpio_chip *chip)
__raw_writel(chip-pm_save[2], base + OFFS_DAT);
__raw_writel(chip-pm_save[3], base + OFFS_UP);
 
+   if (soc_is_s5pc100() || soc_is_s5pv210() || soc_is_exynos4210())
+   __raw_writel(chip-pm_save[4], base + OFFS_DRV_STRGTH);
+
if (chip-chip.ngpio  8) {
S3C_PMDBG(%s: CON4 %08x,%08x = %08x,%08x, DAT %08x = %08x\n,
  chip-chip.label, old_gpcon[0], old_gpcon[1],
@@ -338,12 +346,13 @@ void samsung_pm_save_gpios(void)
 
samsung_pm_save_gpio(ourchip);
 
-   S3C_PMDBG(%s: save %08x,%08x,%08x,%08x\n,
+   S3C_PMDBG(%s: save %08x,%08x,%08x,%08x,%08x\n,
  ourchip-chip.label,
  ourchip-pm_save[0],
  ourchip-pm_save[1],
  ourchip-pm_save[2],
- ourchip-pm_save[3]);
+ ourchip-pm_save[3],
+ ourchip-pm_save[4]);
 
gpio_nr += ourchip-chip.ngpio;
gpio_nr += CONFIG_S3C_GPIO_SPACE;
-- 
1.7.1

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


Re: [PATCH v2] ARM: EXYNOS4: Configure MAX8997 PMIC for Origen

2011-10-03 Thread Inderpal Singh
Hi Kukjin,

Thanks for applying.
I would like to use inderpal.si...@linaro.org
Have updated my .gitconfig accordingly as well.

Thanks,
Inder

On 3 October 2011 08:57, Kukjin Kim kgene@samsung.com wrote:
 Kukjin Kim wrote:

 Inderpal Singh wrote:
 
  From: Inderpal Singh inderpa...@samsung.com
                                     ^^^
 
  Configure MAX8997 PMIC and provide platform specific data
  for origen.
 
  Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
                                                  ^^

 Hi Inderpal,

 You need to change your e-mail address of author or sign. Basically they
 should be same. Which one do you want to use?
 Then you should make sure your .gitconfig has same e-mail address..

 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


[PATCH v2] ARM: EXYNOS4: Configure MAX8997 PMIC for Origen

2011-08-22 Thread Inderpal Singh
From: Inderpal Singh inderpa...@samsung.com

Configure MAX8997 PMIC and provide platform specific data
for origen.

Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
Changes from v1:
- Removed soc-audio
- Used macro for GPIO pin
- irq assigned statically 
- Rectified mismatches in constraints flags
- Removed assigning of array index

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

diff --git a/arch/arm/mach-exynos4/mach-origen.c 
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..ccd2a55 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,6 +14,9 @@
 #include linux/platform_device.h
 #include linux/io.h
 #include linux/input.h
+#include linux/i2c.h
+#include linux/regulator/machine.h
+#include linux/mfd/max8997.h
 
 #include asm/mach/arch.h
 #include asm/mach-types.h
@@ -24,6 +27,7 @@
 #include plat/devs.h
 #include plat/sdhci.h
 #include plat/iic.h
+#include plat/gpio-cfg.h
 
 #include mach/map.h
 
@@ -72,6 +76,378 @@ static struct s3c2410_uartcfg origen_uartcfgs[] __initdata 
= {
},
 };
 
+static struct regulator_consumer_supply __initdata ldo3_consumer[] = {
+   REGULATOR_SUPPLY(vdd11, s5p-mipi-csis.0), /* MIPI */
+};
+static struct regulator_consumer_supply __initdata ldo6_consumer[] = {
+   REGULATOR_SUPPLY(vdd18, s5p-mipi-csis.0), /* MIPI */
+};
+static struct regulator_consumer_supply __initdata ldo7_consumer[] = {
+   REGULATOR_SUPPLY(avdd, alc5625), /* Realtek ALC5625 */
+};
+static struct regulator_consumer_supply __initdata ldo8_consumer[] = {
+   REGULATOR_SUPPLY(vdd, s5p-adc), /* ADC */
+};
+static struct regulator_consumer_supply __initdata ldo9_consumer[] = {
+   REGULATOR_SUPPLY(dvdd, swb-a31), /* AR6003 WLAN  CSR 8810 BT */
+};
+static struct regulator_consumer_supply __initdata ldo11_consumer[] = {
+   REGULATOR_SUPPLY(dvdd, alc5625), /* Realtek ALC5625 */
+};
+static struct regulator_consumer_supply __initdata ldo14_consumer[] = {
+   REGULATOR_SUPPLY(avdd18, swb-a31), /* AR6003 WLAN  CSR 8810 BT */
+};
+static struct regulator_consumer_supply __initdata ldo17_consumer[] = {
+   REGULATOR_SUPPLY(vdd33, swb-a31), /* AR6003 WLAN  CSR 8810 BT */
+};
+static struct regulator_consumer_supply __initdata buck1_consumer[] = {
+   REGULATOR_SUPPLY(vdd_arm, NULL), /* CPUFREQ */
+};
+static struct regulator_consumer_supply __initdata buck2_consumer[] = {
+   REGULATOR_SUPPLY(vdd_int, NULL), /* CPUFREQ */
+};
+static struct regulator_consumer_supply __initdata buck3_consumer[] = {
+   REGULATOR_SUPPLY(vdd_g3d, mali_drm), /* G3D */
+};
+static struct regulator_consumer_supply __initdata buck7_consumer[] = {
+   REGULATOR_SUPPLY(vcc, platform-lcd), /* LCD */
+};
+
+static struct regulator_init_data __initdata max8997_ldo1_data = {
+   .constraints= {
+   .name   = VDD_ABB_3.3V,
+   .min_uV = 330,
+   .max_uV = 330,
+   .apply_uV   = 1,
+   .state_mem  = {
+   .disabled   = 1,
+   },
+   },
+};
+
+static struct regulator_init_data __initdata max8997_ldo2_data = {
+   .constraints= {
+   .name   = VDD_ALIVE_1.1V,
+   .min_uV = 110,
+   .max_uV = 110,
+   .apply_uV   = 1,
+   .always_on  = 1,
+   .state_mem  = {
+   .enabled= 1,
+   },
+   },
+};
+
+static struct regulator_init_data __initdata max8997_ldo3_data = {
+   .constraints= {
+   .name   = VMIPI_1.1V,
+   .min_uV = 110,
+   .max_uV = 110,
+   .apply_uV   = 1,
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   .state_mem  = {
+   .disabled   = 1,
+   },
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(ldo3_consumer),
+   .consumer_supplies  = ldo3_consumer,
+};
+
+static struct regulator_init_data __initdata max8997_ldo4_data = {
+   .constraints= {
+   .name   = VDD_RTC_1.8V,
+   .min_uV = 180,
+   .max_uV = 180,
+   .apply_uV   = 1,
+   .always_on  = 1,
+   .state_mem  = {
+   .disabled   = 1,
+   },
+   },
+};
+
+static struct regulator_init_data __initdata max8997_ldo6_data = {
+   .constraints= {
+   .name   = VMIPI_1.8V,
+   .min_uV = 180,
+   .max_uV = 180,
+   .apply_uV   = 1,
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   .state_mem

Re: [PATCH] ARM: EXYNOS4: Configure MAX8997 PMIC for Origen

2011-08-17 Thread Inderpal Singh
On 16 August 2011 20:49, Mark Brown broo...@opensource.wolfsonmicro.com wrote:

 On Tue, Aug 16, 2011 at 04:38:46PM +0530, Inderpal Singh wrote:
  On 14 August 2011 20:31, Mark Brown 
  broo...@opensource.wolfsonmicro.comwrote:
   On Thu, Aug 11, 2011 at 09:26:05AM +0530, Inderpal Singh wrote:

+static struct regulator_consumer_supply __initdata ldo7_consumer[] = {
+     REGULATOR_SUPPLY(avdd, soc-audio), /* Reatek ALC5625*/
+};

   Ick, no.  The soc-audio device is a virtual device within Linux and is
   being phased out, any driver adding new soc-audio devices will be
   rejected.  The CODEC driver should deal with its own power.

  Ok. So does it mean that sound cards will have their own devices? And those
  device names should be listed as consumers?

 As I said above The CODEC driver should deal with its own power.

Ok, will change accordingly.


+static struct i2c_board_info i2c0_devs[] __initdata = {
+[I2C0_MAX8997] = {
+     I2C_BOARD_INFO(max8997, (0xCC  1)),
+     .platform_data = origen_max8997_pdata,
+     },
+};

   Why are you assigning the array index?  That's very unusual.

  Have seen this kind of initialisation at few places. It looked more
  readable.
  If its not preferred, I will remove it.

 You shouldn't need to be looking up individual members in a board info
 array in the first place.

Ok, will remove array index assignment.


+     s3c_i2c0_set_platdata(NULL);
+     i2c0_devs[I2C0_MAX8997].irq = gpio_to_irq(EXYNOS4_GPX0(4));

   There should be defines to do this statically.

  What advantages do you see in using defines?

 It's non-idiomatic to modify the I2C board info at runtime, all the
 numbers are known at compile time anyway.

This line is External Interrupt line, so will use suitable IRQ_EINT
macro and resubmit the patch.


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


[PATCH] ARM: EXYNOS4: Fix secondary CPU boot after wake-up

2011-06-20 Thread Inderpal Singh
1. After wake-up, the system-wide flags register loses its value.
   Hence, write the address of secondary startup function to
   successfully boot the secondary CPU.

2. Changes SGI1 to SGI0 for secondary CPU boot up

Signed-off-by: Inderpal Singh inderpa...@samsung.com
---
1. The below patch is mandatory to boot secondary CPU after wake-up from sleep
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/4850

2. The change SGI1 to SGI0 for secondary CPU boot up is done as discussed 
at following link
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/4877

 arch/arm/mach-exynos4/platsmp.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
index c5e65a0..061260c 100644
--- a/arch/arm/mach-exynos4/platsmp.c
+++ b/arch/arm/mach-exynos4/platsmp.c
@@ -101,11 +101,18 @@ int __cpuinit boot_secondary(unsigned int cpu, struct 
task_struct *idle)
write_pen_release(cpu);
 
/*
+   * After wake-up, the system-wide flags register loses its value.
+   * Hence, write the address of secondary startup function again.
+   */ 
+   __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), 
S5P_VA_SYSRAM);
+
+
+   /*
 * Send the secondary CPU a soft interrupt, thereby causing
 * the boot monitor to read the system wide flags register,
 * and branch to the address found there.
 */
-   gic_raise_softirq(cpumask_of(cpu), 1);
+   gic_raise_softirq(cpumask_of(cpu), 0);
 
timeout = jiffies + (1 * HZ);
while (time_before(jiffies, timeout)) {
-- 
1.7.1

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


[PATCH] ARM: EXYNOS4: Fix secondary CPU boot after wake-up

2011-05-30 Thread Inderpal Singh
1. After wake-up, the system-wide flags register loses its value.
   Hence, write the address of secondary startup function to
   successfully boot the secondary CPU.

2. Fix to remove the Unknown IPI message 0x1 message when
   secondary CPU boots.

Signed-off-by: Inderpal Singh inderpa...@samsung.com
---
 arch/arm/mach-exynos4/platsmp.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
index 6d35878..11234c7 100644
--- a/arch/arm/mach-exynos4/platsmp.c
+++ b/arch/arm/mach-exynos4/platsmp.c
@@ -100,11 +100,17 @@ int __cpuinit boot_secondary(unsigned int cpu, struct 
task_struct *idle)
write_pen_release(cpu);
 
/*
+* After wake-up, the system-wide flags register loses its value.
+* Hence, write the address of secondary startup function again.
+*/ 
+__raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), 
S5P_VA_SYSRAM);
+
+   /*
 * Send the secondary CPU a soft interrupt, thereby causing
 * the boot monitor to read the system wide flags register,
 * and branch to the address found there.
 */
-   smp_cross_call(cpumask_of(cpu), 1);
+   smp_send_reschedule(cpu);
 
timeout = jiffies + (1 * HZ);
while (time_before(jiffies, timeout)) {
-- 
1.7.1

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


[PATCH] ARM: EXYNOS4: Enable SATA on SMDKV310

2011-05-24 Thread Inderpal Singh
Adds device definition to enable SATA on SMDKV310

Signed-off-by: Inderpal Singh inderpa...@samsung.com
---
 arch/arm/mach-exynos4/Kconfig |1 +
 arch/arm/mach-exynos4/mach-smdkv310.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 11b57a4..9cbf9b8 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -122,6 +122,7 @@ config MACH_SMDKV310
select S3C_DEV_HSMMC1
select S3C_DEV_HSMMC2
select S3C_DEV_HSMMC3
+   select EXYNOS4_DEV_AHCI
select SAMSUNG_DEV_KEYPAD
select EXYNOS4_DEV_PD
select EXYNOS4_DEV_SYSMMU
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c 
b/arch/arm/mach-exynos4/mach-smdkv310.c
index 1526764..666ebe5 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -188,6 +188,7 @@ static struct platform_device *smdkv310_devices[] 
__initdata = {
exynos4_device_sysmmu,
samsung_asoc_dma,
smdkv310_smsc911x,
+   exynos4_device_ahci,
 };
 
 static void __init smdkv310_smsc911x_init(void)
-- 
1.7.1

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


[PATCH] ARM: EXYNOS4: Suspend to RAM fix

2011-05-10 Thread Inderpal Singh
This patch caters to the case when there is no wake up source. The system 
should abort the suspend and resume properly.

1. It implements the pm_suspend function to save the core registers so  that 
they can be restored in pm_resume function.
   Earlier these resgisters were getting saved in pm_prepare, but pm_prepare 
never gets invoked when there is no wake up
   source enabled and restoration used to hang while resuming.

2. As per the L2 cache controller spec, the cache controller registers should 
not be modified if cache is already enabled.
   Hence have made restoration of cache controller registers conditional based 
on whether it is already enabled or not.

Signed-off-by: Inderpal Singh inderpa...@samsung.com
Signed-off-by: Jaecheol Lee jc@samsung.com
---
 arch/arm/mach-exynos4/pm.c |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos4/pm.c b/arch/arm/mach-exynos4/pm.c
index 10d917d..af4794b 100644
--- a/arch/arm/mach-exynos4/pm.c
+++ b/arch/arm/mach-exynos4/pm.c
@@ -323,8 +323,9 @@ static void exynos4_pm_prepare(void)
 {
u32 tmp;
 
-   s3c_pm_do_save(exynos4_core_save, ARRAY_SIZE(exynos4_core_save));
+#ifdef CONFIG_CACHE_L2X0
s3c_pm_do_save(exynos4_l2cc_save, ARRAY_SIZE(exynos4_l2cc_save));
+#endif
 
tmp = __raw_readl(S5P_INFORM1);
 
@@ -389,6 +390,10 @@ static int exynos4_pm_resume(struct sys_device *dev)
exynos4_scu_enable(S5P_VA_SCU);
 
 #ifdef CONFIG_CACHE_L2X0
+   /* Restore the cache controller registers only if it is not enabled 
already*/
+   if((__raw_readl(S5P_VA_L2CC + L2X0_CTRL)1))
+   return 0;
+
s3c_pm_do_restore_core(exynos4_l2cc_save, 
ARRAY_SIZE(exynos4_l2cc_save));
outer_inv_all();
/* enable L2X0*/
@@ -398,9 +403,16 @@ static int exynos4_pm_resume(struct sys_device *dev)
return 0;
 }
 
+static int exynos4_pm_suspend(struct sys_device *dev,pm_message_t state)
+{
+   s3c_pm_do_save(exynos4_core_save, ARRAY_SIZE(exynos4_core_save));
+   return 0;
+}
+
 static struct sysdev_driver exynos4_pm_driver = {
.add= exynos4_pm_add,
.resume = exynos4_pm_resume,
+   .suspend= exynos4_pm_suspend,
 };
 
 static __init int exynos4_pm_drvinit(void)
-- 
1.7.1

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


[PATCH] ARM: SAMSUNG: Enable watchdog parent clock for SMDKV310

2011-03-07 Thread Inderpal Singh
This patch adds the parent clock for watchdog timer for SMDKV310.

Signed-off-by: Inderpal Singh inderpa...@samsung.com
---
 arch/arm/mach-exynos4/clock.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 72d53d5..7bf3c4e 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -489,6 +489,7 @@ static struct clk init_clocks_off[] = {
}, {
.name   = watchdog,
.id = -1,
+   .parent = clk_aclk_100.clk,
.enable = exynos4_clk_ip_perir_ctrl,
.ctrlbit= (1  14),
}, {
-- 
1.7.1

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