[PATCH 2/3] ARM: EXYNOS4: Add clock for Exynos4210 asv feature

2011-11-10 Thread Jongpill Lee
This patch adds clock for exynos4210 asv feature
which name is sclk_pwi,sclk_hpm,dout_copy.
These clock is used for HPM devices.
Also These clock is always on.

Signed-off-by: Jongpill Lee boyko@samsung.com
---
 arch/arm/mach-exynos4/clock.c |   35 ++-
 1 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index db61691..230f851 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -306,6 +306,25 @@ static struct clksrc_clk clk_periphclk = {
.reg_div= { .reg = S5P_CLKDIV_CPU, .shift = 12, .size = 3 },
 };
 
+static struct clk *clkset_mout_hpm_list[] = {
+   [0] = clk_mout_apll.clk,
+   [1] = clk_mout_mpll.clk,
+};
+
+static struct clksrc_sources clkset_sclk_hpm = {
+   .sources= clkset_mout_hpm_list,
+   .nr_sources = ARRAY_SIZE(clkset_mout_hpm_list),
+};
+
+static struct clksrc_clk clk_dout_copy = {
+   .clk= {
+   .name   = dout_copy,
+   },
+   .sources = clkset_sclk_hpm,
+   .reg_src = { .reg = S5P_CLKSRC_CPU, .shift = 20, .size = 1 },
+   .reg_div = { .reg = S5P_CLKDIV_CPU1, .shift = 0, .size = 3 },
+};
+
 /* Core list of CMU_CORE side */
 
 struct clk *clkset_corebus_list[] = {
@@ -1239,7 +1258,20 @@ static struct clksrc_clk clksrcs[] = {
.ctrlbit= (1  16),
},
.reg_div = { .reg = S5P_CLKDIV_FSYS3, .shift = 8, .size = 8 },
-   }
+   }, {
+   .clk= {
+   .name   = sclk_hpm,
+   .parent = clk_dout_copy.clk,
+   },
+   .reg_div = { .reg = S5P_CLKDIV_CPU1, .shift = 4, .size = 3 },
+   }, {
+   .clk= {
+   .name   = sclk_pwi,
+   },
+   .sources = clkset_group,
+   .reg_src = { .reg = S5P_CLKSRC_DMC, .shift = 16, .size = 4 },
+   .reg_div = { .reg = S5P_CLKDIV_DMC1, .shift = 8, .size = 4 },
+   },
 };
 
 /* Clock initialization code */
@@ -1253,6 +1285,7 @@ static struct clksrc_clk *sysclks[] = {
clk_armclk,
clk_aclk_corem0,
clk_aclk_cores,
+   clk_dout_copy,
clk_aclk_corem1,
clk_periphclk,
clk_mout_corebus,
-- 
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 V2 0/3] ASV support for Exynos4 series

2011-11-10 Thread Jongpill Lee
Each SoC has specification.For example voltage or ids current.
These values are related to production process.
If you have a good specification SoC, you can supply lower voltage into SoC.
Also, If your SoC has bad specification, you have to supply higher voltage into 
SoC.
So, after get these SoC specification value on initialize time, we can use 
these value to fix voltage for running SoC.
Using by this patch set, Exynos4210 can get SoC specification and adjust 
voltage.

[PATCH V2 1/3] ARM: EXYNOS4: Add ASV feature for Exynos4 series
[PATCH V2 2/3] ARM: EXYNOS4: Add clock for Exynos4210 asv feature
[PATCH V2 3/3] ARM: EXYNOS4: Support ASV for Exynos4210
--
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] ARM: EXYNOS4: Add ASV feature for Exynos4 series

2011-11-10 Thread Jongpill Lee
This patch adds ASV feature for exynos4 series.
ASV(Adaptive support voltage) feature support to get spec of SoC.
And we can use to adjust voltage for operation SoC using by ASV result.

Signed-off-by: Jongpill Lee boyko@samsung.com
---
 arch/arm/mach-exynos4/Makefile   |1 +
 arch/arm/mach-exynos4/asv.c  |   66 ++
 arch/arm/mach-exynos4/include/mach/asv.h |   40 ++
 3 files changed, 107 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-exynos4/asv.c
 create mode 100644 arch/arm/mach-exynos4/include/mach/asv.h

diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 2bb18f4..587ce90 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_CPU_EXYNOS4210)  += clock-exynos4210.o
 obj-$(CONFIG_SOC_EXYNOS4212)   += clock-exynos4212.o
 obj-$(CONFIG_PM)   += pm.o
 obj-$(CONFIG_CPU_IDLE) += cpuidle.o
+obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += asv.o
 
 obj-$(CONFIG_SMP)  += platsmp.o headsmp.o
 
diff --git a/arch/arm/mach-exynos4/asv.c b/arch/arm/mach-exynos4/asv.c
new file mode 100644
index 000..b13d182
--- /dev/null
+++ b/arch/arm/mach-exynos4/asv.c
@@ -0,0 +1,66 @@
+/* linux/arch/arm/mach-exynos4/asv.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS4 - ASV(Adaptive Support Voltage) driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/init.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/err.h
+#include linux/io.h
+#include linux/slab.h
+
+#include mach/map.h
+#include mach/asv.h
+
+static struct samsung_asv *exynos_asv;
+
+static int __init exynos_asv_init(void)
+{
+   exynos_asv = kzalloc(sizeof(struct samsung_asv), GFP_KERNEL);
+   if (!exynos_asv)
+   return -ENOMEM;
+
+   /* I will add asv driver of exynos4 series to regist */
+
+   if (exynos_asv-check_vdd_arm) {
+   if (exynos_asv-check_vdd_arm())
+   goto out;
+   }
+
+   /* Get HPM Delay value */
+   if (exynos_asv-get_hpm) {
+   if (exynos_asv-get_hpm(exynos_asv))
+   goto out;
+   } else
+   goto out;
+
+   /* Get IDS ARM Value */
+   if (exynos_asv-get_ids) {
+   if (exynos_asv-get_ids(exynos_asv))
+   goto out;
+   } else
+   goto out;
+
+   if (exynos_asv-store_result) {
+   if (exynos_asv-store_result(exynos_asv))
+   goto out;
+   } else
+   goto out;
+
+   return 0;
+out:
+   pr_err(EXYNOS : Fail to initialize ASV\n);
+
+   kfree(exynos_asv);
+
+   return -EINVAL;
+}
+device_initcall_sync(exynos_asv_init);
diff --git a/arch/arm/mach-exynos4/include/mach/asv.h 
b/arch/arm/mach-exynos4/include/mach/asv.h
new file mode 100644
index 000..9a4a8f4
--- /dev/null
+++ b/arch/arm/mach-exynos4/include/mach/asv.h
@@ -0,0 +1,40 @@
+/* linux/arch/arm/mach-exynos4/include/mach/asv.h
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS4 - Adaptive Support Voltage Header file
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#ifndef __ASM_ARCH_ASV_H
+#define __ASM_ARCH_ASV_H __FILE__
+
+#define JUDGE_TABLE_ENDNULL
+
+struct asv_judge_table {
+   unsigned int hpm_limit; /* HPM value to decide group of target */
+   unsigned int ids_limit; /* IDS value to decide group of target */
+};
+
+struct samsung_asv {
+   unsigned int pkg_id;/* fused value for chip */
+   unsigned int ids_offset;/* ids_offset of chip */
+   unsigned int ids_mask;  /* ids_mask of chip */
+   unsigned int hpm_result;/* hpm value of chip */
+   unsigned int ids_result;/* ids value of chip */
+   int (*check_vdd_arm)(void); /* check vdd_arm value, this 
function is selectable */
+   int (*pre_clock_init)(void);/* clock init function to get 
hpm */
+   int (*pre_clock_setup)(void);   /* clock setup function to get 
hpm */
+   /* specific get ids function */
+   int (*get_ids)(struct samsung_asv *asv_info);
+   /* specific get hpm function */
+   int (*get_hpm)(struct samsung_asv *asv_info);
+   /* store into some repository to send result of asv */
+   int (*store_result)(struct samsung_asv *asv_info);
+};
+
+#endif /* __ASM_ARCH_ASV_H */
-- 
1.7.1

--
To unsubscribe from this list: send the line 

[PATCH 3/3] ARM: EXYNOS4: Support ASV for Exynos4210

2011-11-10 Thread Jongpill Lee
This patch adds function for exynos4210's asv driver.
On Exynos4210, we can get ASV result using by HPM and IDS value.
If you want to use asv result on your driver, please define
exynos_result_of_asv with extern.

Signed-off-by: Jongpill Lee boyko@samsung.com
---
 arch/arm/mach-exynos4/Makefile  |2 +-
 arch/arm/mach-exynos4/asv-4210.c|  339 +++
 arch/arm/mach-exynos4/asv.c |9 +-
 arch/arm/mach-exynos4/include/mach/asv.h|3 +
 arch/arm/mach-exynos4/include/mach/map.h|2 +
 arch/arm/mach-exynos4/include/mach/regs-clock.h |   18 ++
 arch/arm/mach-exynos4/include/mach/regs-iem.h   |   27 ++
 7 files changed, 397 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-exynos4/asv-4210.c
 create mode 100644 arch/arm/mach-exynos4/include/mach/regs-iem.h

diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 587ce90..5422b01 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_CPU_EXYNOS4210)  += clock-exynos4210.o
 obj-$(CONFIG_SOC_EXYNOS4212)   += clock-exynos4212.o
 obj-$(CONFIG_PM)   += pm.o
 obj-$(CONFIG_CPU_IDLE) += cpuidle.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += asv.o
+obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += asv.o asv-4210.o
 
 obj-$(CONFIG_SMP)  += platsmp.o headsmp.o
 
diff --git a/arch/arm/mach-exynos4/asv-4210.c b/arch/arm/mach-exynos4/asv-4210.c
new file mode 100644
index 000..1260ab8
--- /dev/null
+++ b/arch/arm/mach-exynos4/asv-4210.c
@@ -0,0 +1,339 @@
+/* linux/arch/arm/mach-exynos/asv-4210.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS4210 - ASV(Adaptive Support Voltage) driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/init.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+
+#include plat/clock.h
+
+#include mach/regs-iem.h
+#include mach/regs-clock.h
+#include mach/asv.h
+
+/*
+ * exynos_result_of_asv is result of ASV group.
+ * Using by this value, other driver can adjust voltage.
+ */
+unsigned int exynos_result_of_asv;
+
+enum target_asv {
+   EXYNOS4210_1200,
+   EXYNOS4210_1400,
+   EXYNOS4210_SINGLE_1200,
+};
+
+struct asv_judge_table exynos4210_1200_limit[] = {
+   /* HPM , IDS */
+   {8 , 4},
+   {11 , 8},
+   {14 , 12},
+   {18 , 17},
+   {21 , 27},
+   {23 , 45},
+   {25 , 55},
+};
+
+static struct asv_judge_table exynos4210_1400_limit[] = {
+   /* HPM , IDS */
+   {13 , 8},
+   {17 , 12},
+   {22 , 32},
+   {26 , 52},
+};
+
+static struct asv_judge_table exynos4210_single_1200_limit[] = {
+   /* HPM , IDS */
+   {8 , 4},
+   {14 , 12},
+   {21 , 27},
+   {25 , 55},
+};
+
+static int exynos4210_asv_pre_clock_init(void)
+{
+   struct clk *clk_hpm;
+   struct clk *clk_copy;
+   struct clk *clk_parent;
+
+   /* PWI clock setting */
+   clk_copy = clk_get(NULL, sclk_pwi);
+   if (IS_ERR(clk_copy))
+   goto clock_fail;
+   else {
+   clk_parent = clk_get(NULL, xusbxti);
+
+   if (IS_ERR(clk_parent)) {
+   clk_put(clk_copy);
+
+   goto clock_fail;
+   }
+   if (clk_set_parent(clk_copy, clk_parent))
+   goto clock_fail;
+
+   clk_put(clk_parent);
+   }
+   clk_set_rate(clk_copy, (48 * MHZ));
+
+   clk_put(clk_copy);
+
+   /* HPM clock setting */
+   clk_copy = clk_get(NULL, dout_copy);
+   if (IS_ERR(clk_copy))
+   goto clock_fail;
+   else {
+   clk_parent = clk_get(NULL, mout_mpll);
+   if (IS_ERR(clk_parent)) {
+   clk_put(clk_copy);
+
+   goto clock_fail;
+   }
+   if (clk_set_parent(clk_copy, clk_parent))
+   goto clock_fail;
+
+   clk_put(clk_parent);
+   }
+
+   clk_set_rate(clk_copy, (400 * MHZ));
+
+   clk_put(clk_copy);
+
+   clk_hpm = clk_get(NULL, sclk_hpm);
+   if (IS_ERR(clk_hpm))
+   goto clock_fail;
+
+   clk_set_rate(clk_hpm, (200 * MHZ));
+
+   clk_put(clk_hpm);
+
+   return 0;
+
+clock_fail:
+   pr_err(EXYNOS4210: ASV: Clock init fail\n);
+
+   return -EBUSY;
+}
+
+static int exynos4210_asv_pre_clock_setup(void)
+{
+   /* APLL_CON0 level register */
+   __raw_writel(0x80FA0601, S5P_APLL_CON0L8);
+   __raw_writel(0x80C80601, S5P_APLL_CON0L7);
+   __raw_writel(0x80C80602, S5P_APLL_CON0L6);
+   __raw_writel(0x80C80604, S5P_APLL_CON0L5);
+   __raw_writel(0x80C80601, 

Re: [PATCH] DMA: PL330: Fix build warning

2011-11-10 Thread Vinod Koul
On Thu, 2011-11-03 at 15:48 +0900, Boojin Kim wrote:
 This patch adds to fix the build warning as following.
 
 drivers/dma/pl330.c: In function 'pl330_probe':
 drivers/dma/pl330.c:859: warning: comparison of distinct pointer types lacks 
 a cast
 
 Signed-off-by: Boojin Kim boojin@samsung.com
 ---
  drivers/dma/pl330.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 621134f..379d928 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -856,7 +856,8 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
   INIT_LIST_HEAD(pd-channels);
  
   /* Initialize channel parameters */
 - num_chan = max(pdat ? pdat-nr_valid_peri : 0, (u8)pi-pcfg.num_chan);
 + num_chan = max(pdat ? (int)pdat-nr_valid_peri : 0,
 + (int)pi-pcfg.num_chan);
   pdmac-peripherals = kzalloc(num_chan * sizeof(*pch), GFP_KERNEL);
  
   for (i = 0; i  num_chan; i++) {

Applied Thanks

-- 
~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] DMA: PL330: Fix build warning

2011-11-10 Thread Joe Perches
On Thu, 2011-11-10 at 15:14 +0530, Vinod Koul wrote:
 On Thu, 2011-11-03 at 15:48 +0900, Boojin Kim wrote:
  This patch adds to fix the build warning as following.
  
  drivers/dma/pl330.c: In function 'pl330_probe':
  drivers/dma/pl330.c:859: warning: comparison of distinct pointer types 
  lacks a cast
  
  Signed-off-by: Boojin Kim boojin@samsung.com
  ---
   drivers/dma/pl330.c |3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
  index 621134f..379d928 100644
  --- a/drivers/dma/pl330.c
  +++ b/drivers/dma/pl330.c
  @@ -856,7 +856,8 @@ pl330_probe(struct amba_device *adev, const struct 
  amba_id *id)
  INIT_LIST_HEAD(pd-channels);
   
  /* Initialize channel parameters */
  -   num_chan = max(pdat ? pdat-nr_valid_peri : 0, (u8)pi-pcfg.num_chan);
  +   num_chan = max(pdat ? (int)pdat-nr_valid_peri : 0,
  +   (int)pi-pcfg.num_chan);
  pdmac-peripherals = kzalloc(num_chan * sizeof(*pch), GFP_KERNEL);
   
  for (i = 0; i  num_chan; i++) {
 
 Applied Thanks

Perhaps
max_t(int, pdat ? pdat-nr_valid_peri : 0, pi-pcfg.num_chan);


--
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] MAINTAINERS: Extend Samsung patterns to cover SPI and ASoC drivers

2011-11-10 Thread Mark Brown
Help people find the overall architecture.

Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
 MAINTAINERS |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a21d4fb..9eca526 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1054,6 +1054,8 @@ F:arch/arm/plat-s3c24xx/
 F: arch/arm/plat-s5p/
 F: drivers/*/*s3c2410*
 F: drivers/*/*/*s3c2410*
+F: drivers/spi/spi-s3c*
+F: sound/soc/samsung/*
 
 ARM/S3C2410 ARM ARCHITECTURE
 M: Ben Dooks ben-li...@fluff.org
-- 
1.7.7.2

--
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] MAINTAINERS: Add linux-samsung-soc mailing list for Samsung

2011-11-10 Thread Mark Brown
There's a Samsung-specific mailing list but it's not advertised in
MAINTAINERS - add it to the overall architecture to make it more
discoverable.

Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
 MAINTAINERS |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c18b278..a21d4fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1046,6 +1046,7 @@ ARM/SAMSUNG ARM ARCHITECTURES
 M: Ben Dooks ben-li...@fluff.org
 M: Kukjin Kim kgene@samsung.com
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+L: linux-samsung-soc@vger.kernel.org
 W: http://www.fluff.org/ben/linux/
 S: Maintained
 F: arch/arm/plat-samsung/
-- 
1.7.7.2

--
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] mmc: core: Support packed command for eMMC4.5 device

2011-11-10 Thread merez
On Thu, Nov 10, 2011 Maya Erez wrote:
 S, Venkatraman svenk...@ti.com wrote:
 On Thu, Nov 3, 2011 at 7:23 AM, Seungwon Jeon tgih@samsung.com
wrote:
   +static u8 mmc_blk_chk_packable(struct mmc_queue *mq, struct
 request *req)

The function prepares the checkable list and not only checks if packing is
possible, therefore I think its name should change to reflect its real
action.

   +       if (!(md-flags  MMC_BLK_CMD23) 
   +                       !card-ext_csd.packed_event_en)
   +               goto no_packed;

Having the condition with a  can lead to cases where CMD23 is not 
supported and we send packed commands. Therfore the condition should be
changed to || or be splitted to 2 separate checks.
Also, according to the standard the generic error flag in
PACKED_COMMAND_STATUS is set in case of any error and having
PACKED_EVENT_EN is only optional. Therefore, I don't think that setting
the packed_event_en should be a mandatory condition for using packed
coammnds.

   +       if (mmc_req_rel_wr(cur) 
   +                       (md-flags  MMC_BLK_REL_WR) 
   +                       !en_rel_wr) {
   +               goto no_packed;
   +       }

Can you please explain this condition and its purpose?

   +               phys_segments +=  next-nr_phys_segments;
   +               if (phys_segments  max_phys_segs) {
   +                       blk_requeue_request(q, next);
   +                       break;
   +               }
  I mentioned this before - if the next request is not packable and
 requeued,
  blk_fetch_request will retrieve it again and this while loop will
never terminate.
 
  If next request is not packable, it is requeued and 'break'
terminates
 this loop.
  So it not infinite.
 Right !! But that doesn't help finding the commands that are packable.
Ideally, you'd need to pack all neighbouring requests into one packed
command.
 The way CFQ works, it is not necessary that the fetch would return all
outstanding
 requests that are packable (unless you invoke a forced dispatch) It
would be good to see some numbers on the number of pack hits /
misses
 that
 you would encounter with this logic, on a typical usecase.
 Is it considered only for CFQ scheduler? How about other I/O scheduler?
If all requests are drained from scheduler queue forcedly,
 the number of candidate to be packed can be increased.
 However we may lose the unique CFQ's strength and MMC D/D may take the
CFQ's duty.
 Basically, this patch accommodates the origin order requests from I/O
scheduler.


In order to better utilize the packed commands feature and achieve the
best performance improvements I think that the command packing should be
done in the block layer, according to the scheduler policy.
That is, the scheduler should be aware of the capability of the device to
receive a request list and its constrains (such as maximum number of
requests, max number of sectors etc) and use this information as a  factor
to its algorithm.
This way you keep the decision making in the hands of the scheduler while
the MMC layer will only have to send this list as a packed command.

   +       if (rqc)
   +               reqs = mmc_blk_chk_packable(mq, rqc);

It would be best to keep all the calls to blk_fetch_request in the same
location. Therefore, I suggest to move the call to mmc_blk_chk_packable to
mmc/card/queue.c after the first request is fetched.

    cmd_abort:
   -       spin_lock_irq(md-lock);
   -       while (ret)
   -               ret = __blk_end_request(req, -EIO,
 blk_rq_cur_bytes(req));
   -       spin_unlock_irq(md-lock);
   +       if (mq_rq-packed_cmd != MMC_PACKED_NONE) {

This should be the case for MMC_PACKED_NONE.

   +               spin_lock_irq(md-lock);
   +               while (ret)
   +                       ret = __blk_end_request(req, -EIO,
 blk_rq_cur_bytes(req));

Do we need the while or should it be an if? In other cases where
__blk_end_request is called there is no such while.

Thanks,
Maya Erez
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum




--
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: [PATCHv4 07/13] ARM: s3c64xx: convert to MULTI_IRQ_HANDLER

2011-11-10 Thread Jamie Iles
On Wed, Nov 09, 2011 at 06:00:20PM +0530, Thomas Abraham wrote:
 On 9 November 2011 17:24, Jamie Iles ja...@jamieiles.com wrote:
  On Wed, Nov 09, 2011 at 04:55:06PM +0530, Thomas Abraham wrote:
  Hi Jamie,
 
  On 4 November 2011 06:40, Jamie Iles ja...@jamieiles.com wrote:
   Now that there is a generic IRQ handler for multiple VIC devices use it
   for s3c64xx to help building multi platform kernels.
  
   Cc: Ben Dooks ben-li...@fluff.org
   Signed-off-by: Jamie Iles ja...@jamieiles.com
   ---
    arch/arm/Kconfig                                 |    1 +
    arch/arm/mach-s3c64xx/include/mach/entry-macro.S |    7 ---
    arch/arm/mach-s3c64xx/mach-anw6410.c             |    2 ++
    arch/arm/mach-s3c64xx/mach-crag6410.c            |    2 ++
    arch/arm/mach-s3c64xx/mach-hmt.c                 |    2 ++
    arch/arm/mach-s3c64xx/mach-mini6410.c            |    2 ++
    arch/arm/mach-s3c64xx/mach-ncp.c                 |    2 ++
    arch/arm/mach-s3c64xx/mach-real6410.c            |    2 ++
    arch/arm/mach-s3c64xx/mach-smartq5.c             |    2 ++
    arch/arm/mach-s3c64xx/mach-smartq7.c             |    2 ++
    arch/arm/mach-s3c64xx/mach-smdk6400.c            |    2 ++
    arch/arm/mach-s3c64xx/mach-smdk6410.c            |    2 ++
    12 files changed, 25 insertions(+), 3 deletions(-)
  
 
  I have tested this patch series on smdk6410 board (s3c64xx) using the
  following repositorty and branch
 
  https://github.com/jamieiles/linux-2.6-ji.git  branch: vic-dt
 
  There is a crash while booting. Am I using the right tree and branch?
  The following is the boot log. Is there any other config option to be
  enabled?
 
  Hmm, could you please try with the patch below applied?
[...]
 
 This patch solves the issue and both smdk6410 and smdkv210 works fine.

Brilliant, thanks Thomas.  Mind if I add a Tested-by from you providing 
the fixup patch is applied first?

Jamie
--
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: s3c2440 / s3c2416 broken

2011-11-10 Thread Paul Schilling
Here is my boot log including some u-boot stuff.  The trace in my boot
log is concerning a
still broken GPIO bank M access that appears broken.

Thanks,
Paul Schilling

dm9000 i/o: 0x2300, id: 0x9a46

DM9000: running in 16 bit mode

MAC: 12:23:34:88:99:00

BOOTP broadcast 1

BOOTP broadcast 2

BOOTP broadcast 3

DHCP client bound to address 10.5.16.68

TFTP from server 10.5.16.63; our IP address is 10.5.16.68

Filename 'schilpa/uImage-dev.bin'.

Load address: 0xc0008000

Loading: *#

 #

 #

 #

 #

 #

 #

 ##

done

Bytes transferred = 2501760 (0x262c80)

get_format

 1 

## Booting kernel from Legacy Image at c0008000 ...

   Image Name:   Linux-3.2.0-rc1+

   Created:  2011-11-09  23:23:05 UTC

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:2501696 Bytes =  2.4 MB

   Load Address: 30008000

   Entry Point:  30008000

   Verifying Checksum ... OK

get_format

 1 

   Loading Kernel Image ... OK

OK



Starting kernel ...



Uncompressing Linux... done, booting the kernel.

Linux version 3.2.0-rc1+ () (gcc version 4.3.3 (GCC) ) #53 PREEMPT
Wed Nov 9 17:23:00 CST 2011

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

CPU: VIVT data cache, VIVT instruction cache

Machine: CONDOR2416

Memory policy: ECC disabled, Data cache writeback

CPU S3C2416/S3C2450 (id 0x32450003)

S3C24XX Clocks, Copyright 2004 Simtec Electronics

CPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 MHz

CPU: EPLL on 96.000 MHz, usb-bus 48.000 MHz

On node 0 totalpages: 32768

free_area_init_node: node 0, pgdat c050955c, node_mem_map c053e000

  Normal zone: 384 pages used for memmap

  Normal zone: 0 pages reserved

  Normal zone: 32384 pages, LIFO batch:7

pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768

pcpu-alloc: [0] 0

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32384

Kernel command line: console=ttySAC0,115200 loglevel=8
s3cfb=dev:0,depth:16,xres:480,yres:272,vslen:60,hslen:17,left:41,right:68,upper:26,lower:6,pixclock:0
root=/dev/mtdblock4 rw rootfstype=jffs2 ethaddr=12:23:34:88:99:00

PID hash table entries: 512 (order: -1, 2048 bytes)

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

Memory: 64MB 64MB = 128MB total

Memory: 124544k/124544k available, 6528k reserved, 0K highmem

Virtual kernel memory layout:

vector  : 0x - 0x1000   (   4 kB)

fixmap  : 0xfff0 - 0xfffe   ( 896 kB)

vmalloc : 0xcc80 - 0xf600   ( 664 MB)

lowmem  : 0xc000 - 0xcc00   ( 192 MB)

modules : 0xbf00 - 0xc000   (  16 MB)

  .text : 0xc0008000 - 0xc04992b8   (4677 kB)

  .init : 0xc049a000 - 0xc04dd000   ( 268 kB)

  .data : 0xc04de000 - 0xc0509c00   ( 175 kB)

   .bss : 0xc0509c24 - 0xc053d764   ( 207 kB)

SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

NR_IRQS:99

irq: clearing subpending status 0003

irq: clearing subpending status 0002

timer tcon=0050, tcnt 2b66, tcfg 0200,, usec 170a

Console: colour dummy device 80x30

Calibrating delay loop... 197.88 BogoMIPS (lpj=98944)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

pinctrl core: initialized pinctrl subsystem

NET: Registered protocol family 16

[ cut here ]

WARNING: at arch/arm/mach-s3c2416/mach-condor2416.c:875
condor2416_machine_init+0xbc/0x700()

Modules linked in:

[c000de08] (unwind_backtrace+0x0/0xec) from [c001f6e0]
(warn_slowpath_common+0x48/0x60)

[c001f6e0] (warn_slowpath_common+0x48/0x60) from [c001f714]
(warn_slowpath_null+0x1c/0x24)

[c001f714] (warn_slowpath_null+0x1c/0x24) from [c049ea9c]
(condor2416_machine_init+0xbc/0x700)

[c049ea9c] (condor2416_machine_init+0xbc/0x700) from [c049bd64]
(customize_machine+0x20/0x30)

[c049bd64] (customize_machine+0x20/0x30) from [c00087c0]
(do_one_initcall+0xa4/0x16c)

[c00087c0] (do_one_initcall+0xa4/0x16c) from [c049a21c]
(kernel_init+0x7c/0x11c)

[c049a21c] (kernel_init+0x7c/0x11c) from [c0009d94]
(kernel_thread_exit+0x0/0x8)

---[ end trace 1b75b31a2719ed1c ]---

s3c_fb_setup: option dev:0

s3c_fb_setup: option depth:16

s3c_fb_setup: option xres:480

s3c_fb_setup: option yres:272

s3c_fb_setup: option vslen:60

s3c_fb_setup: option hslen:17

s3c_fb_setup: option left:41


Re: [PATCHv4 07/13] ARM: s3c64xx: convert to MULTI_IRQ_HANDLER

2011-11-10 Thread Thomas Abraham
On 10 November 2011 20:23, Jamie Iles ja...@jamieiles.com wrote:
 On Wed, Nov 09, 2011 at 06:00:20PM +0530, Thomas Abraham wrote:
 On 9 November 2011 17:24, Jamie Iles ja...@jamieiles.com wrote:
  On Wed, Nov 09, 2011 at 04:55:06PM +0530, Thomas Abraham wrote:
  Hi Jamie,
 
  On 4 November 2011 06:40, Jamie Iles ja...@jamieiles.com wrote:
   Now that there is a generic IRQ handler for multiple VIC devices use it
   for s3c64xx to help building multi platform kernels.
  
   Cc: Ben Dooks ben-li...@fluff.org
   Signed-off-by: Jamie Iles ja...@jamieiles.com
   ---
    arch/arm/Kconfig                                 |    1 +
    arch/arm/mach-s3c64xx/include/mach/entry-macro.S |    7 ---
    arch/arm/mach-s3c64xx/mach-anw6410.c             |    2 ++
    arch/arm/mach-s3c64xx/mach-crag6410.c            |    2 ++
    arch/arm/mach-s3c64xx/mach-hmt.c                 |    2 ++
    arch/arm/mach-s3c64xx/mach-mini6410.c            |    2 ++
    arch/arm/mach-s3c64xx/mach-ncp.c                 |    2 ++
    arch/arm/mach-s3c64xx/mach-real6410.c            |    2 ++
    arch/arm/mach-s3c64xx/mach-smartq5.c             |    2 ++
    arch/arm/mach-s3c64xx/mach-smartq7.c             |    2 ++
    arch/arm/mach-s3c64xx/mach-smdk6400.c            |    2 ++
    arch/arm/mach-s3c64xx/mach-smdk6410.c            |    2 ++
    12 files changed, 25 insertions(+), 3 deletions(-)
  
 
  I have tested this patch series on smdk6410 board (s3c64xx) using the
  following repositorty and branch
 
  https://github.com/jamieiles/linux-2.6-ji.git  branch: vic-dt
 
  There is a crash while booting. Am I using the right tree and branch?
  The following is the boot log. Is there any other config option to be
  enabled?
 
  Hmm, could you please try with the patch below applied?
 [...]

 This patch solves the issue and both smdk6410 and smdkv210 works fine.

 Brilliant, thanks Thomas.  Mind if I add a Tested-by from you providing
 the fixup patch is applied first?

Sure. You can add
Tested-by: Thomas Abraham thomas.abra...@linaro.org

for patches 01, 02. 03, 07, 11 and 13 of your patch series.

Regards,
Thomas.


 Jamie

--
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: s3c2440 / s3c2416 broken

2011-11-10 Thread Thomas Abraham
Hi Paul,

On 10 November 2011 21:27, Paul Schilling paul.s.schill...@gmail.com wrote:
 Here is my boot log including some u-boot stuff.  The trace in my boot
 log is concerning a
 still broken GPIO bank M access that appears broken.

Thanks for the log. But I could find out the cause of this issue. I
will check again tomorrow with linux-3.2.0-rc1 on smdk2416. Any luck
when using ramdisk or any clue with git bisect?

Thanks,
Thomas.


 Thanks,
 Paul Schilling

 dm9000 i/o: 0x2300, id: 0x9a46

 DM9000: running in 16 bit mode

 MAC: 12:23:34:88:99:00

 BOOTP broadcast 1

 BOOTP broadcast 2

 BOOTP broadcast 3

 DHCP client bound to address 10.5.16.68

 TFTP from server 10.5.16.63; our IP address is 10.5.16.68

 Filename 'schilpa/uImage-dev.bin'.

 Load address: 0xc0008000

 Loading: * #

         #

         #

         #

         #

         #

         #

         ##

 done

 Bytes transferred = 2501760 (0x262c80)

 get_format

  1 

 ## Booting kernel from Legacy Image at c0008000 ...

   Image Name:   Linux-3.2.0-rc1+

   Created:      2011-11-09  23:23:05 UTC

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    2501696 Bytes =  2.4 MB

   Load Address: 30008000

   Entry Point:  30008000

   Verifying Checksum ... OK

 get_format

  1 

   Loading Kernel Image ... OK

 OK



 Starting kernel ...



 Uncompressing Linux... done, booting the kernel.

 Linux version 3.2.0-rc1+ () (gcc version 4.3.3 (GCC) ) #53 PREEMPT
 Wed Nov 9 17:23:00 CST 2011

 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

 CPU: VIVT data cache, VIVT instruction cache

 Machine: CONDOR2416

 Memory policy: ECC disabled, Data cache writeback

 CPU S3C2416/S3C2450 (id 0x32450003)

 S3C24XX Clocks, Copyright 2004 Simtec Electronics

 CPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 MHz

 CPU: EPLL on 96.000 MHz, usb-bus 48.000 MHz

 On node 0 totalpages: 32768

 free_area_init_node: node 0, pgdat c050955c, node_mem_map c053e000

  Normal zone: 384 pages used for memmap

  Normal zone: 0 pages reserved

  Normal zone: 32384 pages, LIFO batch:7

 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768

 pcpu-alloc: [0] 0

 Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32384

 Kernel command line: console=ttySAC0,115200 loglevel=8
 s3cfb=dev:0,depth:16,xres:480,yres:272,vslen:60,hslen:17,left:41,right:68,upper:26,lower:6,pixclock:0
 root=/dev/mtdblock4 rw rootfstype=jffs2 ethaddr=12:23:34:88:99:00

 PID hash table entries: 512 (order: -1, 2048 bytes)

 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

 Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

 Memory: 64MB 64MB = 128MB total

 Memory: 124544k/124544k available, 6528k reserved, 0K highmem

 Virtual kernel memory layout:

    vector  : 0x - 0x1000   (   4 kB)

    fixmap  : 0xfff0 - 0xfffe   ( 896 kB)

    vmalloc : 0xcc80 - 0xf600   ( 664 MB)

    lowmem  : 0xc000 - 0xcc00   ( 192 MB)

    modules : 0xbf00 - 0xc000   (  16 MB)

      .text : 0xc0008000 - 0xc04992b8   (4677 kB)

      .init : 0xc049a000 - 0xc04dd000   ( 268 kB)

      .data : 0xc04de000 - 0xc0509c00   ( 175 kB)

       .bss : 0xc0509c24 - 0xc053d764   ( 207 kB)

 SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

 NR_IRQS:99

 irq: clearing subpending status 0003

 irq: clearing subpending status 0002

 timer tcon=0050, tcnt 2b66, tcfg 0200,, usec 170a

 Console: colour dummy device 80x30

 Calibrating delay loop... 197.88 BogoMIPS (lpj=98944)

 pid_max: default: 32768 minimum: 301

 Mount-cache hash table entries: 512

 CPU: Testing write buffer coherency: ok

 pinctrl core: initialized pinctrl subsystem

 NET: Registered protocol family 16

 [ cut here ]

 WARNING: at arch/arm/mach-s3c2416/mach-condor2416.c:875
 condor2416_machine_init+0xbc/0x700()

 Modules linked in:

 [c000de08] (unwind_backtrace+0x0/0xec) from [c001f6e0]
 (warn_slowpath_common+0x48/0x60)

 [c001f6e0] (warn_slowpath_common+0x48/0x60) from [c001f714]
 (warn_slowpath_null+0x1c/0x24)

 [c001f714] (warn_slowpath_null+0x1c/0x24) from [c049ea9c]
 (condor2416_machine_init+0xbc/0x700)

 [c049ea9c] (condor2416_machine_init+0xbc/0x700) from [c049bd64]
 (customize_machine+0x20/0x30)

 [c049bd64] (customize_machine+0x20/0x30) from [c00087c0]
 (do_one_initcall+0xa4/0x16c)

 [c00087c0] (do_one_initcall+0xa4/0x16c) from [c049a21c]
 

[PATCH] ARM: OMAP: Introduce local common.h files

2011-11-10 Thread Tony Lindgren
As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
there's no need to keep local prototypes in non-local headers.

Add mach-omap1/common.h and mach-omap2/common.h and move the
local prototypes there from plat/common.h and mach/omap4-common.h.

Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index 51bae31..1b37400 100644
---
Here's a patch that fixes the locality issues for MACHINE_START/END
functions at least.
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -35,7 +35,7 @@
 #include plat/mux.h
 #include plat/usb.h
 #include plat/board.h
-#include plat/common.h
+#include common.h
 #include mach/camera.h
 
 #include mach/ams-delta-fiq.h
diff --git a/arch/arm/mach-omap1/board-fsample.c 
b/arch/arm/mach-omap1/board-fsample.c
index 2317827..b9c4c0f 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -32,7 +32,7 @@
 #include plat/flash.h
 #include plat/fpga.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 #include plat/board.h
 
 /* fsample is pretty close to p2-sample */
diff --git a/arch/arm/mach-omap1/board-generic.c 
b/arch/arm/mach-omap1/board-generic.c
index dc5b75d..7f41d7a 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -25,7 +25,7 @@
 #include plat/mux.h
 #include plat/usb.h
 #include plat/board.h
-#include plat/common.h
+#include common.h
 
 /* assume no Mini-AB port */
 
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index b334b14..7933b97 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -43,7 +43,7 @@
 #include plat/irda.h
 #include plat/usb.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 #include plat/flash.h
 
 #include board-h2.h
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 74ebe72..04be2f8 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -45,7 +45,7 @@
 #include plat/usb.h
 #include plat/keypad.h
 #include plat/dma.h
-#include plat/common.h
+#include common.h
 #include plat/flash.h
 
 #include board-h3.h
diff --git a/arch/arm/mach-omap1/board-htcherald.c 
b/arch/arm/mach-omap1/board-htcherald.c
index 3e91baa..46fcfeb 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -41,7 +41,7 @@
 #include asm/mach/arch.h
 
 #include plat/omap7xx.h
-#include plat/common.h
+#include common.h
 #include plat/board.h
 #include plat/keypad.h
 #include plat/usb.h
diff --git a/arch/arm/mach-omap1/board-innovator.c 
b/arch/arm/mach-omap1/board-innovator.c
index 273153d..f99d11d 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -37,7 +37,7 @@
 #include plat/tc.h
 #include plat/usb.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 #include plat/mmc.h
 
 /* At OMAP1610 Innovator the Ethernet is directly connected to CS1 */
diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index 6798b84..c643423 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -30,7 +30,7 @@
 #include plat/usb.h
 #include plat/board.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 #include plat/hwa742.h
 #include plat/lcd_mipid.h
 #include plat/mmc.h
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index c385927..a409dfc 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -51,7 +51,7 @@
 #include plat/usb.h
 #include plat/mux.h
 #include plat/tc.h
-#include plat/common.h
+#include common.h
 
 /* At OMAP5912 OSK the Ethernet is directly connected to CS1 */
 #define OMAP_OSK_ETHR_START0x04800300
diff --git a/arch/arm/mach-omap1/board-palmte.c 
b/arch/arm/mach-omap1/board-palmte.c
index f9c44cb..105292d 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -41,7 +41,7 @@
 #include plat/board.h
 #include plat/irda.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 
 #define PALMTE_USBDETECT_GPIO  0
 #define PALMTE_USB_OR_DC_GPIO  1
diff --git a/arch/arm/mach-omap1/board-palmtt.c 
b/arch/arm/mach-omap1/board-palmtt.c
index 11a9853..387a900 100644
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@ -39,7 +39,7 @@
 #include plat/board.h
 #include plat/irda.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 
 #include linux/spi/spi.h
 #include linux/spi/ads7846.h
diff --git a/arch/arm/mach-omap1/board-palmz71.c 
b/arch/arm/mach-omap1/board-palmz71.c
index 4206157..df6d15e 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -41,7 +41,7 @@
 #include plat/board.h
 #include plat/irda.h
 #include plat/keypad.h

Re: [PATCH] ARM: OMAP: Introduce local common.h files

2011-11-10 Thread Russell King - ARM Linux
On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
 As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
 there's no need to keep local prototypes in non-local headers.
 
 Add mach-omap1/common.h and mach-omap2/common.h and move the
 local prototypes there from plat/common.h and mach/omap4-common.h.
 
 Signed-off-by: Tony Lindgren t...@atomide.com

Great, looks fine, thanks.  I suspect the chance of conflicts on this are
about the same as the chance of conflicts with the rest of the restart
series (in that, new platforms will need to be fixed for both these
changes.)

So, I suggest that I add it to my series so I can fix the OMAP changes
there so stuff still builds - and then I can see about publishing a more
stable branch in a couple of weeks for new platforms to base on.

If you agree, could you put it in the patch system please?  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] ARM: OMAP: Introduce local common.h files

2011-11-10 Thread Tony Lindgren
* Russell King - ARM Linux li...@arm.linux.org.uk [10 11:49]:
 On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
  As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
  there's no need to keep local prototypes in non-local headers.
  
  Add mach-omap1/common.h and mach-omap2/common.h and move the
  local prototypes there from plat/common.h and mach/omap4-common.h.
  
  Signed-off-by: Tony Lindgren t...@atomide.com
 
 Great, looks fine, thanks.  I suspect the chance of conflicts on this are
 about the same as the chance of conflicts with the rest of the restart
 series (in that, new platforms will need to be fixed for both these
 changes.)
 
 So, I suggest that I add it to my series so I can fix the OMAP changes
 there so stuff still builds - and then I can see about publishing a more
 stable branch in a couple of weeks for new platforms to base on.

OK, a stable branch is needed badly for this.. If possible please
publish some minimal stable base branch as soon as you can as pretty
much all omap patches need to be updated for this one.
 
 If you agree, could you put it in the patch system please?  Thanks.

Sounds good to me, it there now as patch 7159/1.

Regards,

Tony
--
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: OMAP: Introduce local common.h files

2011-11-10 Thread Russell King - ARM Linux
On Thu, Nov 10, 2011 at 01:50:09PM -0800, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [10 11:49]:
  On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
   As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
   there's no need to keep local prototypes in non-local headers.
   
   Add mach-omap1/common.h and mach-omap2/common.h and move the
   local prototypes there from plat/common.h and mach/omap4-common.h.
   
   Signed-off-by: Tony Lindgren t...@atomide.com
  
  Great, looks fine, thanks.  I suspect the chance of conflicts on this are
  about the same as the chance of conflicts with the rest of the restart
  series (in that, new platforms will need to be fixed for both these
  changes.)
  
  So, I suggest that I add it to my series so I can fix the OMAP changes
  there so stuff still builds - and then I can see about publishing a more
  stable branch in a couple of weeks for new platforms to base on.
 
 OK, a stable branch is needed badly for this.. If possible please
 publish some minimal stable base branch as soon as you can as pretty
 much all omap patches need to be updated for this one.

I want to give it something between a week and two before closing the
window for acked-bys etc (amongst other reasons).

  If you agree, could you put it in the patch system please?  Thanks.
 
 Sounds good to me, it there now as patch 7159/1.

Thanks, merged that into the series.  The updated OMAP patch updated is
below, which has been moved to part 2.  Lastly, the final patch of part
2 has been updated to delete the empty arch_reset(), so OMAP is now
entirely free of arch_reset() references.  This leaves a total of 12
references left to nobble.

8---
From: Russell King - ARM Linux li...@arm.linux.org.uk
Subject: [PATCH] ARM: restart: omap: use new restart hook

Hook these platforms restart code into the new restart hook rather
than using arch_reset().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 arch/arm/mach-omap1/board-ams-delta.c  |1 +
 arch/arm/mach-omap1/board-fsample.c|1 +
 arch/arm/mach-omap1/board-generic.c|1 +
 arch/arm/mach-omap1/board-h2.c |1 +
 arch/arm/mach-omap1/board-h3.c |1 +
 arch/arm/mach-omap1/board-htcherald.c  |1 +
 arch/arm/mach-omap1/board-innovator.c  |1 +
 arch/arm/mach-omap1/board-nokia770.c   |1 +
 arch/arm/mach-omap1/board-osk.c|1 +
 arch/arm/mach-omap1/board-palmte.c |1 +
 arch/arm/mach-omap1/board-palmtt.c |1 +
 arch/arm/mach-omap1/board-palmz71.c|1 +
 arch/arm/mach-omap1/board-perseus2.c   |1 +
 arch/arm/mach-omap1/board-sx1.c|1 +
 arch/arm/mach-omap1/board-voiceblue.c  |5 ++---
 arch/arm/mach-omap1/common.h   |1 +
 arch/arm/mach-omap1/reset.c|4 +---
 arch/arm/mach-omap2/board-2430sdp.c|1 +
 arch/arm/mach-omap2/board-3430sdp.c|1 +
 arch/arm/mach-omap2/board-3630sdp.c|1 +
 arch/arm/mach-omap2/board-4430sdp.c|1 +
 arch/arm/mach-omap2/board-am3517crane.c|1 +
 arch/arm/mach-omap2/board-am3517evm.c  |1 +
 arch/arm/mach-omap2/board-apollon.c|1 +
 arch/arm/mach-omap2/board-cm-t35.c |2 ++
 arch/arm/mach-omap2/board-cm-t3517.c   |1 +
 arch/arm/mach-omap2/board-devkit8000.c |1 +
 arch/arm/mach-omap2/board-generic.c|4 
 arch/arm/mach-omap2/board-h4.c |1 +
 arch/arm/mach-omap2/board-igep0020.c   |2 ++
 arch/arm/mach-omap2/board-ldp.c|1 +
 arch/arm/mach-omap2/board-n8x0.c   |3 +++
 arch/arm/mach-omap2/board-omap3beagle.c|1 +
 arch/arm/mach-omap2/board-omap3evm.c   |1 +
 arch/arm/mach-omap2/board-omap3logic.c |2 ++
 arch/arm/mach-omap2/board-omap3pandora.c   |1 +
 arch/arm/mach-omap2/board-omap3stalker.c   |1 +
 arch/arm/mach-omap2/board-omap3touchbook.c |1 +
 arch/arm/mach-omap2/board-omap4panda.c |1 +
 arch/arm/mach-omap2/board-overo.c  |1 +
 arch/arm/mach-omap2/board-rm680.c  |1 +
 arch/arm/mach-omap2/board-rx51.c   |1 +
 arch/arm/mach-omap2/board-ti8168evm.c  |1 +
 arch/arm/mach-omap2/board-zoom.c   |2 ++
 arch/arm/mach-omap2/common.h   |1 +
 arch/arm/mach-omap2/prcm.c |4 +---
 arch/arm/plat-omap/include/plat/system.h   |4 +++-
 47 files changed, 59 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index 1b37400..2120369 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -382,6 +382,7 @@ MACHINE_START(AMS_DELTA, Amstrad E3 (Delta))
.init_irq   = omap1_init_irq,
.init_machine   = ams_delta_init,
.timer  = omap1_timer,
+   .restart= omap1_restart,
 

Re: Pet Peaves about Platform code, and arch_reset

2011-11-10 Thread Shawn Guo
On Wed, Nov 09, 2011 at 01:46:52PM -0800, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [07 16:11]:
  * Russell King - ARM Linux li...@arm.linux.org.uk [06 05:18]:
   Here's a list of my peaves about current platform code - which are
   causing me great issue when trying to clean up the arch_reset() stuff:
   
   1. Lack of trailing ',' on structure initializers
  This makes it much harder to add additional initializers at the end
  of existing initializers, and increases the risks of conflicts being
  caused due to more lines having to be modified.
   
   (This won't work directly because the tabs have been converted to space.
   The empty-looking [] contain a space plus a tab.)
   $ grep '[   ][  ]*\.[[:alnum:]_][[:alnum:]_]*[  ]*=[
   ]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm -r|wc -l
   768
   $ grep '[   ][  ]*\.[[:alnum:]_][[:alnum:]_]*[  ]*=[
   ]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm/*omap* -r|wc -l
   325
   
  Note that this is _far_ too big a problem - and trivial - to fix in
  a set of silly churn generating patches - it's a problem to be fixed
  as a part of _other_ changes to the files.
   
  But most importantly _stop_ introducing versions of this problem.
  
  Sounds like we need a spatch for this issue?
 
 I guess spatch would need some patching to deal with this.. I tried
 with something like:
 
 @r@
 identifier I, s, fld;
 position p0,p;
 expression E;
 @@
 
 struct I s =@p0 {
 ...
 -   .fld@p = E,
 +   .fld = E,
 ...
 };
 
 That catches them, but adds an extra comma in the beginning :)
 
 --- a/ams-delta-fiq.c 2011-11-08 18:03:20.110707512 -0800
 +++ b/ams-delta-fiq.c 2011-11-08 18:04:36.094948038 -0800
 @@ -25,7 +25,7 @@
  #include mach/ams-delta-fiq.h
  
  static struct fiq_handler fh = {
 - .name   = ams-delta-fiq
 + ,.name = ams-delta-fiq,
  };
  
  /*
 
 And it also messes up the formatting for other structs..
 
 Anyways, I think I got most of these fixed for all ARM subarchitectures
 in a pile of 72 patches, the stats are: 
 
 486 files changed, 2296 insertions(+), 2296 deletions(-)
 
 This is something people can then use as a base to start chipping away at
 the problem. I'm thinking it may be possible to use this as a base for
 search and replacement type work and then hopefully git mergetool will
 pick the relevant changes when rebasing a working branch to the mainline.
 
 I can also post the patches here if people want, but sounds like we're
 not going to merge them as they are, but instead will slowly fix the
 issue in other related patches?
 
 I've pushed the patches into a git branch at:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap formatting:
 
 Web interface at:
 
 http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=shortlog;h=refs/heads/formatting
 

For record, we may not want to do this for cases below, since we should
never add entry after sentinel.

 static const struct of_device_id imx53_iomuxc_of_match[] __initconst = {
@@ -75,7 +75,7 @@ static const struct of_device_id imx53_iomuxc_of_match[] 
__initconst = {
{ .compatible = fsl,imx53-iomuxc-evk, .data = imx53_evk_common_init, 
},
{ .compatible = fsl,imx53-iomuxc-qsb, .data = imx53_qsb_common_init, 
},
{ .compatible = fsl,imx53-iomuxc-smd, .data = imx53_smd_common_init, 
},
-   { /* sentinel */ }
+   { /* sentinel */ },
 };
 
 static void __init imx53_dt_init(void)
@@ -112,7 +112,7 @@ static const char *imx53_dt_board_compat[] __initdata = {
fsl,imx53-evk,
fsl,imx53-qsb,
fsl,imx53-smd,
-   NULL
+   NULL,
 };

-- 
Regards,
Shawn

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


Re: [PATCH 3/3] ARM: EXYNOS4: Support ASV for Exynos4210

2011-11-10 Thread MyungJoo Ham
On Thu, Nov 10, 2011 at 2:48 PM, Jongpill Lee boyko@samsung.com wrote:
 This patch adds function for exynos4210's asv driver.
 On Exynos4210, we can get ASV result using by HPM and IDS value.
 If you want to use asv result on your driver, please define
 exynos_result_of_asv with extern.

Thank you! Looks much better with a variable than a register.
At least, it's now fully compatible with DVFS drivers. :)
I'll add a devfreq driver for Exynos4210 bus soon.


 Signed-off-by: Jongpill Lee boyko@samsung.com
 ---
  arch/arm/mach-exynos4/Makefile                  |    2 +-
  arch/arm/mach-exynos4/asv-4210.c                |  339 
 +++
  arch/arm/mach-exynos4/asv.c                     |    9 +-
  arch/arm/mach-exynos4/include/mach/asv.h        |    3 +
  arch/arm/mach-exynos4/include/mach/map.h        |    2 +
  arch/arm/mach-exynos4/include/mach/regs-clock.h |   18 ++
  arch/arm/mach-exynos4/include/mach/regs-iem.h   |   27 ++
  7 files changed, 397 insertions(+), 3 deletions(-)
  create mode 100644 arch/arm/mach-exynos4/asv-4210.c
  create mode 100644 arch/arm/mach-exynos4/include/mach/regs-iem.h

 diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
 index 587ce90..5422b01 100644
 --- a/arch/arm/mach-exynos4/Makefile
 +++ b/arch/arm/mach-exynos4/Makefile
 @@ -18,7 +18,7 @@ obj-$(CONFIG_CPU_EXYNOS4210)  += clock-exynos4210.o
  obj-$(CONFIG_SOC_EXYNOS4212)   += clock-exynos4212.o
  obj-$(CONFIG_PM)               += pm.o
  obj-$(CONFIG_CPU_IDLE)         += cpuidle.o
 -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += asv.o
 +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += asv.o asv-4210.o

  obj-$(CONFIG_SMP)              += platsmp.o headsmp.o

 diff --git a/arch/arm/mach-exynos4/asv-4210.c 
 b/arch/arm/mach-exynos4/asv-4210.c
 new file mode 100644
 index 000..1260ab8
 --- /dev/null
 +++ b/arch/arm/mach-exynos4/asv-4210.c
 @@ -0,0 +1,339 @@
 +/* linux/arch/arm/mach-exynos/asv-4210.c
 + *
 + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
 + *             http://www.samsung.com/
 + *
 + * EXYNOS4210 - ASV(Adaptive Support Voltage) driver
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 +*/
 +
 +#include linux/init.h
 +#include linux/types.h
 +#include linux/kernel.h
 +#include linux/err.h
 +#include linux/clk.h
 +#include linux/io.h
 +
 +#include plat/clock.h
 +
 +#include mach/regs-iem.h
 +#include mach/regs-clock.h
 +#include mach/asv.h
 +
 +/*
 + * exynos_result_of_asv is result of ASV group.
 + * Using by this value, other driver can adjust voltage.
 + */
 +unsigned int exynos_result_of_asv;
 +
 +enum target_asv {
 +       EXYNOS4210_1200,
 +       EXYNOS4210_1400,
 +       EXYNOS4210_SINGLE_1200,
 +};
 +
 +struct asv_judge_table exynos4210_1200_limit[] = {
 +       /* HPM , IDS */
 +       {8 , 4},
 +       {11 , 8},
 +       {14 , 12},
 +       {18 , 17},
 +       {21 , 27},
 +       {23 , 45},
 +       {25 , 55},
 +};
 +
 +static struct asv_judge_table exynos4210_1400_limit[] = {
 +       /* HPM , IDS */
 +       {13 , 8},
 +       {17 , 12},
 +       {22 , 32},
 +       {26 , 52},
 +};
 +
 +static struct asv_judge_table exynos4210_single_1200_limit[] = {
 +       /* HPM , IDS */
 +       {8 , 4},
 +       {14 , 12},
 +       {21 , 27},
 +       {25 , 55},
 +};
 +
 +static int exynos4210_asv_pre_clock_init(void)
 +{
 +       struct clk *clk_hpm;
 +       struct clk *clk_copy;
 +       struct clk *clk_parent;
 +
 +       /* PWI clock setting */
 +       clk_copy = clk_get(NULL, sclk_pwi);
 +       if (IS_ERR(clk_copy))
 +               goto clock_fail;
 +       else {
 +               clk_parent = clk_get(NULL, xusbxti);
 +
 +               if (IS_ERR(clk_parent)) {
 +                       clk_put(clk_copy);
 +
 +                       goto clock_fail;
 +               }
 +               if (clk_set_parent(clk_copy, clk_parent))
 +                       goto clock_fail;
 +
 +               clk_put(clk_parent);
 +       }
 +       clk_set_rate(clk_copy, (48 * MHZ));
 +
 +       clk_put(clk_copy);
 +
 +       /* HPM clock setting */
 +       clk_copy = clk_get(NULL, dout_copy);
 +       if (IS_ERR(clk_copy))
 +               goto clock_fail;
 +       else {
 +               clk_parent = clk_get(NULL, mout_mpll);
 +               if (IS_ERR(clk_parent)) {
 +                       clk_put(clk_copy);
 +
 +                       goto clock_fail;
 +               }
 +               if (clk_set_parent(clk_copy, clk_parent))
 +                       goto clock_fail;
 +
 +               clk_put(clk_parent);
 +       }
 +
 +       clk_set_rate(clk_copy, (400 * MHZ));
 +
 +       clk_put(clk_copy);
 +
 +       clk_hpm = clk_get(NULL, sclk_hpm);
 +       if (IS_ERR(clk_hpm))
 +               goto clock_fail;
 +
 +       clk_set_rate(clk_hpm, (200 * MHZ));
 +
 +       clk_put(clk_hpm);
 +
 +       return 0;
 +
 +clock_fail:
 +  

[PATCH V2 0/5] ARM: exynos4: Add l2 retention mode cpuidle state

2011-11-10 Thread Amit Daniel Kachhap
Changes since V1:
*rebased the whole patch against 3.2-rc1 tree
*removed GIC save/restore in AFTR cpuidle state as it is external 
to cpu powerdomain
*Added L2 setup code through device tree
*Removed only l2 save/restore registers in sleep

This Patch series adds support for AFTR mode cpuidle state based on 
patch (http://www.spinics.net/lists/arm-kernel/msg132243.html) earlier
submitted by Jaecheol Lee jc@samsung.com.

This patch uses CPU PM notifiers , common l2 save/restore and 
new cpu_suspend/resume interfaces and is based on the tip of 
for-next branch of samsung tree.
(git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
for-next). 

Amit Daniel Kachhap (5):
  ARM: exynos4: Add support for AFTR mode cpuidle state
  ARM: exynos4: remove useless churn in sleep.S
  ARM: exynos4: add L2 early resume code
  ARM: exynos4: remove useless code to save/restore L2
  ARM: exynos4: Enable l2 configuration through device tree

 arch/arm/mach-exynos/cpu.c  |   60 +
 arch/arm/mach-exynos/cpuidle.c  |  148 ++-
 arch/arm/mach-exynos/include/mach/pmu.h |2 +
 arch/arm/mach-exynos/pm.c   |   15 ---
 arch/arm/plat-s5p/sleep.S   |   32 +++-
 5 files changed, 221 insertions(+), 36 deletions(-)

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


[PATCH V2 1/5] ARM: exynos4: Add support for AFTR mode cpuidle state

2011-11-10 Thread Amit Daniel Kachhap
This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode.
This patch adds 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  |  148 ++-
 arch/arm/mach-exynos/include/mach/pmu.h |2 +
 2 files changed, 146 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index c6485d3..857ccc6 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -12,13 +12,31 @@
 #include linux/module.h
 #include linux/init.h
 #include linux/cpuidle.h
+#include linux/cpu_pm.h
 #include linux/io.h
-
+#include linux/suspend.h
+#include linux/err.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 : (S5P_VA_SYSRAM + 0x24))
+#define REG_DIRECTGO_FLAG  (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+   S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20))
 
 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] = {
@@ -26,9 +44,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);
@@ -38,9 +64,95 @@ 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);
+
+   save_cpu_arch_register();
+
+   /* Setting Central Sequence Register for power down mode */
+   tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+   tmp = ~S5P_CENTRAL_LOWPWR_CFG;
+   __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+
+   cpu_suspend(0, idle_finisher);
+
+   scu_enable(S5P_VA_SCU);
+
+   restore_cpu_arch_register();
+
+   /*
+* If PMU failed while entering sleep mode, WFI will be
+* ignored by PMU and then exiting cpu_do_idle().
+* S5P_CENTRAL_LOWPWR_CFG bit will not be set automatically
+* in this situation.
+*/
+   tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+   if (!(tmp  S5P_CENTRAL_LOWPWR_CFG)) {
+   tmp |= S5P_CENTRAL_LOWPWR_CFG;
+   __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+   

[PATCH V2 2/5] ARM: exynos4: remove useless churn in sleep.S

2011-11-10 Thread Amit Daniel Kachhap
This patch cleans up sleep code in preparation for L2 resume code
and hotplug functions

Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
 arch/arm/plat-s5p/sleep.S |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-s5p/sleep.S b/arch/arm/plat-s5p/sleep.S
index 0fd591b..c371ba2 100644
--- a/arch/arm/plat-s5p/sleep.S
+++ b/arch/arm/plat-s5p/sleep.S
@@ -23,7 +23,6 @@
 */
 
 #include linux/linkage.h
-#include asm/assembler.h
 
.text
 
@@ -44,6 +43,9 @@
 * other way of restoring the stack pointer after sleep, and we
 * must not write to the code segment (code is read-only)
 */
+   .align
+   .data
 
 ENTRY(s3c_cpu_resume)
b   cpu_resume
+ENDPROC(s3c_cpu_resume)
-- 
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 V2 4/5] ARM: exynos4: remove useless code to save/restore L2

2011-11-10 Thread Amit Daniel Kachhap
Following the merge of CPU PM notifiers and L2 resume code, this patch
removes useless code to save and restore L2 registers.

This is now automatically covered by suspend calls which integrated
CPU PM notifiers and new sleep code that allows to resume L2 before MMU
is turned on.

Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
 arch/arm/mach-exynos/pm.c |   15 ---
 1 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 509a435..0c264e1 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -154,13 +154,6 @@ static struct sleep_save exynos4_core_save[] = {
SAVE_ITEM(S5P_SROM_BC3),
 };
 
-static struct sleep_save exynos4_l2cc_save[] = {
-   SAVE_ITEM(S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL),
-   SAVE_ITEM(S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL),
-   SAVE_ITEM(S5P_VA_L2CC + L2X0_PREFETCH_CTRL),
-   SAVE_ITEM(S5P_VA_L2CC + L2X0_POWER_CTRL),
-   SAVE_ITEM(S5P_VA_L2CC + L2X0_AUX_CTRL),
-};
 
 /* For Cortex-A9 Diagnostic and Power control register */
 static unsigned int save_arm_register[2];
@@ -181,7 +174,6 @@ static void exynos4_pm_prepare(void)
u32 tmp;
 
s3c_pm_do_save(exynos4_core_save, ARRAY_SIZE(exynos4_core_save));
-   s3c_pm_do_save(exynos4_l2cc_save, ARRAY_SIZE(exynos4_l2cc_save));
s3c_pm_do_save(exynos4_epll_save, ARRAY_SIZE(exynos4_epll_save));
s3c_pm_do_save(exynos4_vpll_save, ARRAY_SIZE(exynos4_vpll_save));
 
@@ -404,13 +396,6 @@ static void exynos4_pm_resume(void)
 
exynos4_scu_enable(S5P_VA_SCU);
 
-#ifdef CONFIG_CACHE_L2X0
-   s3c_pm_do_restore_core(exynos4_l2cc_save, 
ARRAY_SIZE(exynos4_l2cc_save));
-   outer_inv_all();
-   /* enable L2X0*/
-   writel_relaxed(1, S5P_VA_L2CC + L2X0_CTRL);
-#endif
-
 early_wakeup:
return;
 }
-- 
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 V2 5/5] ARM: exynos4: Enable l2 configuration through device tree

2011-11-10 Thread Amit Daniel Kachhap
This patch enables calling generic l2 setup functions if device tree is used.

Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
 arch/arm/mach-exynos/cpu.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index 252e346..b62a90f 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -37,6 +37,9 @@
 #include mach/regs-pmu.h
 #include mach/pmu.h
 
+#define L2_AUX_VAL 0x7C470001
+#define L2_AUX_MASK 0xC200
+
 unsigned int gic_bank_offset __read_mostly;
 
 extern int combiner_init(unsigned int combiner_nr, void __iomem *base,
@@ -299,6 +302,7 @@ core_initcall(exynos4_core_init);
 #ifdef CONFIG_CACHE_L2X0
 static int __init exynos4_l2x0_cache_init(void)
 {
+#ifndef CONFIG_OF
if (!(__raw_readl(S5P_VA_L2CC + L2X0_CTRL)  0x1)) {
l2x0_saved_regs.phy_base = EXYNOS4_PA_L2CC;
/* TAG, Data Latency Control: 2 cycles */
@@ -332,8 +336,12 @@ static int __init exynos4_l2x0_cache_init(void)
clean_dcache_area(l2x0_saved_regs, sizeof(struct l2x0_regs));
}
 
-   l2x0_init(S5P_VA_L2CC, 0x7C470001, 0xC200);
-
+   l2x0_init(S5P_VA_L2CC, L2_AUX_VAL, L2_AUX_MASK);
+#else
+   l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
+   l2x0_regs_phys = virt_to_phys(l2x0_saved_regs);
+   clean_dcache_area(l2x0_regs_phys, sizeof(unsigned long));
+#endif
return 0;
 }
 
-- 
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 V2 3/5] ARM: exynos4: add L2 early resume code

2011-11-10 Thread Amit Daniel Kachhap
This patch adds code to save L2 register configuration at boot, and to
resume L2 before MMU is enabled in suspend and cpuidle resume paths.

Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
 arch/arm/mach-exynos/cpu.c |   42 +++---
 arch/arm/plat-s5p/sleep.S  |   28 
 2 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index 8e09f34..252e346 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -19,6 +19,7 @@
 #include asm/proc-fns.h
 #include asm/hardware/cache-l2x0.h
 #include asm/hardware/gic.h
+#include asm/cacheflush.h
 
 #include plat/cpu.h
 #include plat/clock.h
@@ -34,6 +35,7 @@
 
 #include mach/regs-irq.h
 #include mach/regs-pmu.h
+#include mach/pmu.h
 
 unsigned int gic_bank_offset __read_mostly;
 
@@ -297,20 +299,38 @@ core_initcall(exynos4_core_init);
 #ifdef CONFIG_CACHE_L2X0
 static int __init exynos4_l2x0_cache_init(void)
 {
-   /* TAG, Data Latency Control: 2cycle */
-   __raw_writel(0x110, S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL);
+   if (!(__raw_readl(S5P_VA_L2CC + L2X0_CTRL)  0x1)) {
+   l2x0_saved_regs.phy_base = EXYNOS4_PA_L2CC;
+   /* TAG, Data Latency Control: 2 cycles */
+   l2x0_saved_regs.tag_latency = 0x110;
 
-   if (soc_is_exynos4210())
-   __raw_writel(0x110, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
-   else if (soc_is_exynos4212() || soc_is_exynos4412())
-   __raw_writel(0x120, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
+   if (soc_is_exynos4212() || soc_is_exynos4412())
+   l2x0_saved_regs.data_latency = 0x120;
+   else
+   l2x0_saved_regs.data_latency = 0x110;
+
+   l2x0_saved_regs.prefetch_ctrl = 0x3007;
+   l2x0_saved_regs.pwr_ctrl =
+   (L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN);
+
+   l2x0_regs_phys = virt_to_phys(l2x0_saved_regs);
 
-   /* L2X0 Prefetch Control */
-   __raw_writel(0x3007, S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
+   __raw_writel(l2x0_saved_regs.tag_latency,
+   S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL);
+   __raw_writel(l2x0_saved_regs.data_latency,
+   S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
 
-   /* L2X0 Power Control */
-   __raw_writel(L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN,
-S5P_VA_L2CC + L2X0_POWER_CTRL);
+   /* L2X0 Prefetch Control */
+   __raw_writel(l2x0_saved_regs.prefetch_ctrl,
+   S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
+
+   /* L2X0 Power Control */
+   __raw_writel(l2x0_saved_regs.pwr_ctrl,
+   S5P_VA_L2CC + L2X0_POWER_CTRL);
+
+   clean_dcache_area(l2x0_regs_phys, sizeof(unsigned long));
+   clean_dcache_area(l2x0_saved_regs, sizeof(struct l2x0_regs));
+   }
 
l2x0_init(S5P_VA_L2CC, 0x7C470001, 0xC200);
 
diff --git a/arch/arm/plat-s5p/sleep.S b/arch/arm/plat-s5p/sleep.S
index c371ba2..40bd9bf 100644
--- a/arch/arm/plat-s5p/sleep.S
+++ b/arch/arm/plat-s5p/sleep.S
@@ -23,6 +23,8 @@
 */
 
 #include linux/linkage.h
+#include asm/asm-offsets.h
+#include asm/hardware/cache-l2x0.h
 
.text
 
@@ -47,5 +49,31 @@
.data
 
 ENTRY(s3c_cpu_resume)
+#ifdef CONFIG_CACHE_L2X0
+   adr r0, l2x0_regs_phys
+   ldr r0, [r0]
+   ldr r1, [r0, #L2X0_R_PHY_BASE]
+   ldr r2, [r1, #L2X0_CTRL]
+   tst r2, #0x1
+   bne resume_l2on
+   ldr r2, [r0, #L2X0_R_AUX_CTRL]
+   str r2, [r1, #L2X0_AUX_CTRL]
+   ldr r2, [r0, #L2X0_R_TAG_LATENCY]
+   str r2, [r1, #L2X0_TAG_LATENCY_CTRL]
+   ldr r2, [r0, #L2X0_R_DATA_LATENCY]
+   str r2, [r1, #L2X0_DATA_LATENCY_CTRL]
+   ldr r2, [r0, #L2X0_R_PREFETCH_CTRL]
+   str r2, [r1, #L2X0_PREFETCH_CTRL]
+   ldr r2, [r0, #L2X0_R_PWR_CTRL]
+   str r2, [r1, #L2X0_POWER_CTRL]
+   mov r2, #1
+   str r2, [r1, #L2X0_CTRL]
+resume_l2on:
+#endif
b   cpu_resume
 ENDPROC(s3c_cpu_resume)
+#ifdef CONFIG_CACHE_L2X0
+   .globl l2x0_regs_phys
+l2x0_regs_phys:
+   .long   0
+#endif
-- 
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: [PATCHv2 1/2] arm: samsung: support the second capability for samsung-soc

2011-11-10 Thread Jae hoon Chung
Hi kgene

How about this patch? this patch must add the platform data.

Thanks,
Jaehoon Chung

2011/11/3 Jaehoon Chung jh80.ch...@samsung.com:
 In mmc, there are capabilities and use the host_caps.
 That capability is expressed with bit[0:31].
 But now..already filled the bit[0:31]...
 so we need to denote with the other capability field.
 (if we want to use the cache, powerclass, etc for eMMC..this field is 
 necessary)

 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 Changelog v2:
   - based-on samsung-soc's for-next tree.

  arch/arm/plat-samsung/include/plat/sdhci.h |    2 ++
  arch/arm/plat-samsung/platformdata.c       |    2 ++
  2 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h 
 b/arch/arm/plat-samsung/include/plat/sdhci.h
 index dcff7dd..bf33ea1 100644
 --- a/arch/arm/plat-samsung/include/plat/sdhci.h
 +++ b/arch/arm/plat-samsung/include/plat/sdhci.h
 @@ -40,6 +40,7 @@ enum clk_types {
  * struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
  * @max_width: The maximum number of data bits supported.
  * @host_caps: Standard MMC host capabilities bit field.
 + * @host_caps2: The Second Standard MMC host capabilities bit field.
  * @cd_type: Type of Card Detection method (see cd_types enum above)
  * @clk_type: Type of clock divider method (see clk_types enum above)
  * @ext_cd_init: Initialize external card detect subsystem. Called on
 @@ -63,6 +64,7 @@ enum clk_types {
  struct s3c_sdhci_platdata {
        unsigned int    max_width;
        unsigned int    host_caps;
 +       unsigned int    host_caps2;
        enum cd_types   cd_type;
        enum clk_types  clk_type;

 diff --git a/arch/arm/plat-samsung/platformdata.c 
 b/arch/arm/plat-samsung/platformdata.c
 index 4c9a207..5ffcf46 100644
 --- a/arch/arm/plat-samsung/platformdata.c
 +++ b/arch/arm/plat-samsung/platformdata.c
 @@ -54,4 +54,6 @@ void s3c_sdhci_set_platdata(struct s3c_sdhci_platdata *pd,
                set-host_caps |= pd-host_caps;
        if (pd-clk_type)
                set-clk_type = pd-clk_type;
 +       if (pd-host_caps2)
 +               set-host_caps2 |= pd-host_caps2;
  }
 --
 To unsubscribe from this list: send the line unsubscribe linux-mmc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


RE: [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device

2011-11-10 Thread Seungwon Jeon
Maya Erez wrote:
 On Thu, Nov 10, 2011 Maya Erez wrote:
  S, Venkatraman svenk...@ti.com wrote:
  On Thu, Nov 3, 2011 at 7:23 AM, Seungwon Jeon tgih@samsung.com
 wrote:
+static u8 mmc_blk_chk_packable(struct mmc_queue *mq, struct
  request *req)
 
 The function prepares the checkable list and not only checks if packing is
 possible, therefore I think its name should change to reflect its real
 action
I labored at naming. Isn't it proper? :)
Do you have any recommendation?
group_pack_req?

 
+       if (!(md-flags  MMC_BLK_CMD23) 
+                       !card-ext_csd.packed_event_en)
+               goto no_packed;
 
 Having the condition with a  can lead to cases where CMD23 is not
 supported and we send packed commands. Therfore the condition should be
 changed to || or be splitted to 2 separate checks.
 Also, according to the standard the generic error flag in
 PACKED_COMMAND_STATUS is set in case of any error and having
 PACKED_EVENT_EN is only optional. Therefore, I don't think that setting
 the packed_event_en should be a mandatory condition for using packed
 coammnds.
... cases where CMD23 is not supported and we send packed commands?
Packed command must not be allowed in such a case.
It works only with predefined mode which is essential fator.
And spec doesn't mentioned PACKED_EVENT_EN must be set.
So Packed command can be sent regardless PACKED_EVENT_EN,
but it's not complete without reporting of error.
Then host driver may suffer error recovery.
Why packed command is used without error reporting?

 
+       if (mmc_req_rel_wr(cur) 
+                       (md-flags  MMC_BLK_REL_WR) 
+                       !en_rel_wr) {
+               goto no_packed;
+       }
 
 Can you please explain this condition and its purpose?
 
In the case where reliable write is request but enhanced reliable write
is not supported, write access must be partial according to
reliable write sector count. Because even a single request can be split,
packed command is not allowed in this case.

+               phys_segments +=  next-nr_phys_segments;
+               if (phys_segments  max_phys_segs) {
+                       blk_requeue_request(q, next);
+                       break;
+               }
   I mentioned this before - if the next request is not packable and
  requeued,
   blk_fetch_request will retrieve it again and this while loop will
 never terminate.
  
   If next request is not packable, it is requeued and 'break'
 terminates
  this loop.
   So it not infinite.
  Right !! But that doesn't help finding the commands that are packable.
 Ideally, you'd need to pack all neighbouring requests into one packed
 command.
  The way CFQ works, it is not necessary that the fetch would return all
 outstanding
  requests that are packable (unless you invoke a forced dispatch) It
 would be good to see some numbers on the number of pack hits /
 misses
  that
  you would encounter with this logic, on a typical usecase.
  Is it considered only for CFQ scheduler? How about other I/O scheduler?
 If all requests are drained from scheduler queue forcedly,
  the number of candidate to be packed can be increased.
  However we may lose the unique CFQ's strength and MMC D/D may take the
 CFQ's duty.
  Basically, this patch accommodates the origin order requests from I/O
 scheduler.
 
 
 In order to better utilize the packed commands feature and achieve the
 best performance improvements I think that the command packing should be
 done in the block layer, according to the scheduler policy.
 That is, the scheduler should be aware of the capability of the device to
 receive a request list and its constrains (such as maximum number of
 requests, max number of sectors etc) and use this information as a  factor
 to its algorithm.
 This way you keep the decision making in the hands of the scheduler while
 the MMC layer will only have to send this list as a packed command.
 
Yes, it would be another interesting approach.
Command packing you mentioned means gathering request among same 
direction(read/write)?
Currently I/O scheduler may know device constrains which MMC driver informs
with the exception of order information for packed command.
But I think the dependency of I/O scheduler may be able to come up.
How can MMC layer treat packed command with I/O scheduler which doesn't support 
this?

+       if (rqc)
+               reqs = mmc_blk_chk_packable(mq, rqc);
 
 It would be best to keep all the calls to blk_fetch_request in the same
 location. Therefore, I suggest to move the call to mmc_blk_chk_packable to
 mmc/card/queue.c after the first request is fetched.

At the first time, I considered that way.
I'll do more, if possible.
 
 cmd_abort:
-       spin_lock_irq(md-lock);
-       while (ret)
-               ret = __blk_end_request(req, -EIO,
  blk_rq_cur_bytes(req));
-       spin_unlock_irq(md-lock);
+       if (mq_rq-packed_cmd != 

Re: [PATCH 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state

2011-11-10 Thread MyungJoo Ham
On Sat, Nov 5, 2011 at 2:03 AM,  amit.kach...@linaro.org wrote:
 From: Amit Daniel Kachhap amit.kach...@linaro.org

 This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
 cpuidle driver for EXYNOS4210. 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
 ---
[]
 +#define REG_DIRECTGO_ADDR  (samsung_rev() == EXYNOS4210_REV_1_1 ? \
 +   S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24))
 +#define REG_DIRECTGO_FLAG  (samsung_rev() == EXYNOS4210_REV_1_1 ? \
 +   S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20))

[]
 +
 +   __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)),
 +REG_DIRECTGO_ADDR);
 +   __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG);
 +
return 0;

Hello,


Why are you using INFORM6 and 7 registers in order to save resume
address and power-mode flags?

INFORM0 and 1 have been used in pm.c for the exactly same purpose.
Please use the same registers in cpuidle.c as well.

The same part in bootloader (IPL) can handle whether it's
suspend-to-RAM or AFTR and the both modes are mutually exclusive and
you only need one value for resume PC.

Therefore, you can keep the value at the same location, which is the
method we have been using.

Besides, the Exynos4210 chipmaker (S.LSI) has told that INFORM6 and 7
registers are used by in-chip code (iROM or iRAM).


Cheers!
MyungJoo



-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
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