RE: [PATCH v2 2/2] OMAP3: PM: Configure CPUidle latencies/thresholds from board file

2009-10-16 Thread Nayak, Rajendra
I missed updating omap_init_power_states() to look into cpuidle_params_table
at init, as part of this patch. Will send a fixed patch shortly.
Thanks to Thara for catching this.

-Original Message-
From: Nayak, Rajendra 
Sent: Thursday, October 15, 2009 8:19 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; Nayak, Rajendra
Subject: [PATCH v2 2/2] OMAP3: PM: Configure CPUidle 
latencies/thresholds from board file

The CPUidle C state latencies and thresholds are dependent
on various board specific details.
This patch makes it possible to configure these values from the
respective board files.

omap3_pm_init_cpuidle() can now be optionally called from board
files to pass board specific cpuidle parameters.
If the board files do not use this function to pass the params
default values are used which might cause higher consumption
dur to wrong state selection by the governor.

This patch only updates the 3430sdp board files to use
omap3_pm_init_cpuidle().

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/mach-omap2/board-3430sdp.c |   19 +++
 arch/arm/mach-omap2/cpuidle34xx.c   |   42 
+++
 arch/arm/mach-omap2/pm.h|8 ++
 3 files changed, 69 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 0f1975c..d2b2f8f 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -73,6 +73,24 @@ static struct prm_setup_vc omap3_setuptime_table = {
   .vdd1_off = 0x00,
 };
 
+/* FIXME: These values need to be updated based on more 
profiling on 3430sdp*/
+static struct cpuidle_params omap3_cpuidle_params_table[] = {
+  /* C1 */
+  {2, 2, 5},
+  /* C2 */
+  {10, 10, 30},
+  /* C3 */
+  {50, 50, 300},
+  /* C4 */
+  {1500, 1800, 4000},
+  /* C5 */
+  {2500, 7500, 12000},
+  /* C6 */
+  {3000, 8500, 15000},
+  /* C7 */
+  {1, 3, 30},
+};
+
 static int board_keymap[] = {
   KEY(0, 0, KEY_LEFT),
   KEY(0, 1, KEY_RIGHT),
@@ -203,6 +221,7 @@ static void __init omap_3430sdp_init_irq(void)
   omap_board_config = sdp3430_config;
   omap_board_config_size = ARRAY_SIZE(sdp3430_config);
   omap3_pm_init_vc(omap3_setuptime_table);
+  omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
   omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL, 
omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
   omap_init_irq();
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index c44a942..f5d8f55 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -60,6 +60,30 @@ struct omap3_processor_cx 
omap3_power_states[OMAP3_MAX_STATES];
 struct omap3_processor_cx current_cx_state;
 struct powerdomain *mpu_pd, *core_pd, *per_pd;
 
+/*
+ * The latencies/thresholds for various C states have
+ * to be configured from the respective board files.
+ * These are some default values (which might not provide
+ * the best power savings) used on boards which do not
+ * pass these details from the board file.
+ */
+static struct cpuidle_params cpuidle_params_table[] = {
+  /* C1 */
+  {2, 2, 5},
+  /* C2 */
+  {10, 10, 30},
+  /* C3 */
+  {50, 50, 300},
+  /* C4 */
+  {1500, 1800, 4000},
+  /* C5 */
+  {2500, 7500, 12000},
+  /* C6 */
+  {3000, 8500, 15000},
+  /* C7 */
+  {1, 3, 30},
+};
+
 static int omap3_idle_bm_check(void)
 {
   if (!omap3_can_sleep())
@@ -165,6 +189,24 @@ static int omap3_enter_idle_bm(struct 
cpuidle_device *dev,
 
 DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 
+void omap3_pm_init_cpuidle(struct cpuidle_params 
*cpuidle_board_params)
+{
+  int i;
+
+  if (!cpuidle_board_params)
+  return;
+
+  for (i = OMAP3_STATE_C1; i  OMAP3_MAX_STATES; i++) {
+  cpuidle_params_table[i].sleep_latency =
+  cpuidle_board_params[i].sleep_latency;
+  cpuidle_params_table[i].wake_latency =
+  cpuidle_board_params[i].wake_latency;
+  cpuidle_params_table[i].threshold =
+  cpuidle_board_params[i].threshold;
+  }
+  return;
+}
+
 /* omap3_init_power_states - Initialises the OMAP3 specific C states.
  *
  * Below is the desciption of each C state.
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ca673c5..0b814ab 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -41,7 +41,15 @@ struct prm_setup_vc {
   u16 vdd1_ret;
   u16 vdd1_off;
 };
+
+struct cpuidle_params {
+  u32 sleep_latency;
+  u32 wake_latency;
+  u32 threshold;
+};
+
 extern void omap3_pm_init_vc(struct prm_setup_vc *setup_vc);
+extern void omap3_pm_init_cpuidle(struct cpuidle_params 
*cpuidle_board_params);
 
 extern int 

Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread Dirk Behme

John Rigby wrote:

I have seen several discussions about lack of sdio irq support in the
hsmmc driver but no patches.  Has anyone on this list implemented this
and/or can anyone point me to patches?


What a coincidence ;)

I'm currently working on this. See attachment what I currently have. 
It is compile tested only against recent omap linux head. I don't have 
a board using SDIO at the moment, so no real testing possible :(


Some background, maybe it helps people to step in:

Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by 
MMC port 2 in 4 bit configuration [1]. The wifi performance is quite 
bad (~100kB/s). There is some rumor that this might be SDIO irq 
related [2]. There was an attempt to fix this [3] already, but this 
doesn't work [4]. Having this, I started to look into it.


I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO 
Simplified Specification [6] and the OMAP35x TRM [7] as starting points.


Unfortunately, the Davinci MMC registers and irqs are different 
(Davinci has a dedicated SDIO irq). But combining [3] and [5] helps to 
get an idea what has to be done.


I think the main issues of [3] were that it doesn't enable IBG for 4 
bit mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the 
irq bits.


Topics I still open:

- Is it always necessary to deal with IE _and_ ISE register? I'm not 
totally clear what the difference between these two registers are ;) 
And in which order they have to be set.


- Davinci driver [5] in line 1115 checks for data line to call 
mmc_signal_sdio_irq() for irq enable.


- Davinci driver deals with SDIO in xfer_done() (line 873)

- Davinci driver sets block size to 64 if SDIO in line 701

It would be quite nice if anybody likes to comment on attachment and 
help testing.


Many thanks and best regards

Dirk

[1] http://gumstix.net/wiki/index.php?title=Overo_Wifi

[2] http://groups.google.com/group/beagleboard/msg/14e822778c5eeb56

[3] http://groups.google.com/group/beagleboard/msg/d0eb69f4c20673be

[4] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937

[5] 
http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD


[6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/

[7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf

Subject: [PATCH][RFC] OMAP HSMMC: Add SDIO interrupt support
Form: Dirk Behme dirk.be...@googlemail.com

At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor
performance. Add support for SDIO interrupt handling. 

Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---

Patch against recent omap-linux head Linux omap got rebuilt from scratch
274c94b29ee7c53609a756acca974e4742c59559

Compile tested only. Please comment and help testing.

 drivers/mmc/host/omap_hsmmc.c |   48 +-
 1 file changed, 43 insertions(+), 5 deletions(-)

Index: linux-beagle/drivers/mmc/host/omap_hsmmc.c
===
--- linux-beagle.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-beagle/drivers/mmc/host/omap_hsmmc.c
@@ -27,6 +27,7 @@
 #include linux/timer.h
 #include linux/clk.h
 #include linux/mmc/host.h
+#include linux/mmc/card.h
 #include linux/mmc/core.h
 #include linux/io.h
 #include linux/semaphore.h
@@ -65,6 +66,7 @@
 #define SDVSDET0x0400
 #define AUTOIDLE   0x1
 #define SDBP   (1  8)
+#define IBG(1  19)
 #define DTO0xe
 #define ICE0x1
 #define ICS0x2
@@ -76,6 +78,7 @@
 #define INT_EN_MASK0x307F0033
 #define BWR_ENABLE (1  4)
 #define BRR_ENABLE (1  5)
+#define CIRQ_ENABLE(1  8)
 #define INIT_STREAM(1  1)
 #define DP_SELECT  (1  21)
 #define DDIR   (1  4)
@@ -87,6 +90,7 @@
 #define CC 0x1
 #define TC 0x02
 #define OD 0x1
+#define CIRQ   (1   8)
 #define ERR(1  15)
 #define CMD_TIMEOUT(1  16)
 #define DATA_TIMEOUT   (1  20)
@@ -653,6 +657,15 @@ static irqreturn_t omap_hsmmc_irq(int ir
status = OMAP_HSMMC_READ(host-base, STAT);
dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
 
+   if (status  CIRQ) {
+   dev_dbg(mmc_dev(host-mmc), SDIO interrupt);
+   OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
+ ~(CIRQ_ENABLE));
+   mmc_signal_sdio_irq(host-mmc);
+   spin_unlock(host-irq_lock);
+   return IRQ_HANDLED;
+   }
+
if (status  ERR) {
 #ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
   

[PATCH 01/17] PM: fix suspend control for IVA2

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

IVA2 controls its target power state individually, thus suspend should not
touch IVA2. Without this patch DSP suspend always fails.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
Acked-by: Ameya Palande ameya.pala...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a3e3729..5e2ef63 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -81,7 +81,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
 
 static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
 static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm;
+static struct powerdomain *cam_pwrdm, *iva2_pwrdm;
 
 static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -676,6 +676,12 @@ static int omap3_pm_suspend(void)
pwrst-saved_state = pwrdm_read_next_pwrst(pwrst-pwrdm);
/* Set ones wanted by suspend */
list_for_each_entry(pwrst, pwrst_list, node) {
+   /* Special handling for IVA2, just use current sleep state */
+   if (pwrst-pwrdm == iva2_pwrdm) {
+   state = pwrdm_read_pwrst(pwrst-pwrdm);
+   if (state  PWRDM_POWER_ON)
+   pwrst-next_state = state;
+   }
if (set_pwrdm_state(pwrst-pwrdm, pwrst-next_state))
goto restore;
if (pwrdm_clear_all_prev_pwrst(pwrst-pwrdm))
@@ -1183,6 +1189,7 @@ static int __init omap3_pm_init(void)
per_pwrdm = pwrdm_lookup(per_pwrdm);
core_pwrdm = pwrdm_lookup(core_pwrdm);
cam_pwrdm = pwrdm_lookup(cam_pwrdm);
+   iva2_pwrdm = pwrdm_lookup(iva2_pwrdm);
 
omap_push_sram_idle();
 #ifdef CONFIG_SUSPEND
-- 
1.5.4.3

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


[PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB and PER into idle loop

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

This is needed to prevent core from entering off mode if one of the IVA2,
USB or PER powerdomains are going to stay at least in retention state.
If this is not done, a powerdomain waking from RET may access core
domain which has just been reset.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |   36 +++-
 1 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 588ab79..3e5ae14 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -85,6 +85,13 @@ u32 voltage_off_while_idle;
OMAP3430_ST_DES1_MASK)
 #define CORE_IDLEST3_ALL   (\
OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
+#define PER_IDLEST_ALL (\
+   OMAP3430_ST_WDT3_MASK|OMAP3430_ST_MCBSP4_MASK|\
+   OMAP3430_ST_MCBSP3_MASK|OMAP3430_ST_MCBSP2_MASK|\
+   OMAP3430_ST_GPT9_MASK|OMAP3430_ST_GPT8_MASK|\
+   OMAP3430_ST_GPT7_MASK|OMAP3430_ST_GPT6_MASK|\
+   OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
+   OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
 
 struct power_state {
struct powerdomain *pwrdm;
@@ -103,7 +110,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
 
 static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
 static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm, *usb_pwrdm;
 
 static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -428,6 +435,8 @@ void omap_sram_idle(void)
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
int dss_state = PWRDM_POWER_ON;
+   int iva2_state = PWRDM_POWER_ON;
+   int usb_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
@@ -463,14 +472,28 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
 
+   /* Get powerdomain state data */
+   core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+   dss_state = pwrdm_read_pwrst(dss_pwrdm);
+   iva2_state = pwrdm_read_pwrst(iva2_pwrdm);
+   usb_state = pwrdm_read_pwrst(usb_pwrdm);
+   per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
+
+   /* Check if PER domain can enter OFF or not */
+   if (per_next_state == PWRDM_POWER_OFF) {
+   if ((cm_read_mod_reg(OMAP3430_PER_MOD, CM_IDLEST) 
+   PER_IDLEST_ALL) != PER_IDLEST_ALL) {
+   per_next_state = PWRDM_POWER_RET;
+   pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
+   per_state_modified = 1;
+   }
+   }
/*
 * Check whether core will enter idle or not. This is needed
 * because I/O pad wakeup will fail if core stays on and PER
 * enters off. This will also prevent unnecessary core context
 * save / restore.
 */
-   core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
-   dss_state = pwrdm_read_pwrst(dss_pwrdm);
if (core_next_state  PWRDM_POWER_ON) {
core_saved_state = core_next_state;
if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1)  CORE_IDLEST1_ALL)
@@ -482,14 +505,16 @@ void omap_sram_idle(void)
core_next_state = PWRDM_POWER_ON;
pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
} else if (core_next_state == PWRDM_POWER_OFF 
-dss_state == PWRDM_POWER_ON) {
+(dss_state == PWRDM_POWER_ON ||
+ iva2_state = PWRDM_POWER_RET ||
+ usb_state = PWRDM_POWER_RET ||
+ per_next_state = PWRDM_POWER_RET)) {
core_next_state = PWRDM_POWER_RET;
pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
}
}
 
/* PER */
-   per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
if (per_next_state  PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
@@ -1240,6 +1265,7 @@ static int __init omap3_pm_init(void)
cam_pwrdm = pwrdm_lookup(cam_pwrdm);
iva2_pwrdm = pwrdm_lookup(iva2_pwrdm);
dss_pwrdm = pwrdm_lookup(dss_pwrdm);
+   usb_pwrdm = pwrdm_lookup(usbhost_pwrdm);
 
omap_push_sram_idle();
 #ifdef CONFIG_SUSPEND
-- 
1.5.4.3

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

[PATCH 07/17] OMAP3: Disable Smartreflex before pwrdm enters RET

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

Smartreflex for the corresponding powerdomain (MPU/CORE) must be disabled
before the domain enters retention, otherwise the device may hang. This is
caused by overlapping smartreflex / auto retention command on the voltage
channel resulting in incorrect voltage.

This fix has been confirmed from TI.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |   23 ++-
 1 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3e5ae14..5854fa7 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -531,11 +531,17 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
omap2_clkdm_deny_idle(mpu_pwrdm-pwrdm_clkdms[0]);
 
-   /* CORE */
-   if (core_next_state  PWRDM_POWER_ON) {
-   /* Disable smartreflex before entering WFI */
+   /*
+* Disable smartreflex before entering WFI.
+* Only needed if we are going to enter retention or off.
+*/
+   if (mpu_next_state = PWRDM_POWER_RET)
disable_smartreflex(SR1);
+   if (core_next_state = PWRDM_POWER_RET)
disable_smartreflex(SR2);
+
+   /* CORE */
+   if (core_next_state  PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
@@ -608,10 +614,17 @@ void omap_sram_idle(void)
prm_clear_mod_reg_bits(OMAP3430_AUTO_RET,
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
-   /* Enable smartreflex after WFI */
+   }
+
+   /*
+* Enable smartreflex after WFI. Only needed if we
+* entered retention or off.
+*/
+   if (mpu_next_state = PWRDM_POWER_RET)
enable_smartreflex(SR1);
+   if (core_next_state = PWRDM_POWER_RET)
enable_smartreflex(SR2);
-   }
+
if (core_saved_state != core_next_state)
pwrdm_set_next_pwrst(core_pwrdm, core_saved_state);
 
-- 
1.5.4.3

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


[PATCH 09/17] OMAP3: PM: Ack pending interrupts before entering suspend

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

Suspending drivers may still generate interrupts just before their suspend is
completed. Any pending interrupts here will prevent sleep.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/irq.c  |2 +-
 arch/arm/mach-omap2/pm34xx.c   |2 ++
 arch/arm/plat-omap/include/mach/irqs.h |1 +
 3 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index aceedd8..4ed05e9 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -101,7 +101,7 @@ static int omap_check_spurious(unsigned int irq)
 }
 
 /* XXX: FIQ and additional INTC support (only MPU at the moment) */
-static void omap_ack_irq(unsigned int irq)
+void omap_ack_irq(unsigned int irq)
 {
intc_bank_write_reg(0x1, irq_banks[0], INTC_CONTROL);
 }
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 5854fa7..6a41811 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -778,6 +778,8 @@ static int omap3_pm_suspend(void)
 
omap_uart_prepare_suspend();
 
+   /* Ack pending IRQs, as a pending IRQ will cause the suspend to fail */
+   omap_ack_irq(0);
regset_save_on_suspend = 1;
omap_sram_idle();
regset_save_on_suspend = 0;
diff --git a/arch/arm/plat-omap/include/mach/irqs.h 
b/arch/arm/plat-omap/include/mach/irqs.h
index 2473910..d56be1c 100644
--- a/arch/arm/plat-omap/include/mach/irqs.h
+++ b/arch/arm/plat-omap/include/mach/irqs.h
@@ -483,6 +483,7 @@
 #ifndef __ASSEMBLY__
 extern void omap_init_irq(void);
 extern int omap_irq_pending(void);
+extern void omap_ack_irq(unsigned int irq);
 void omap3_intc_save_context(void);
 void omap3_intc_restore_context(void);
 #endif
-- 
1.5.4.3

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


[PATCH 02/17] OMAP3: PM: Dynamic check for CORE target state

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

Sleep code will now check if core will actually enter power save state or
not. This is needed so that PER domain does not enter retention / off while
core stays on and thus preventing I/O pad wakeups.

This also optimizes core context save and restore logic, it will skip
saving / restoring core context when this is requested but not needed.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/cm.h |1 +
 arch/arm/mach-omap2/pm34xx.c |   46 +-
 2 files changed, 46 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h
index a2fcfcc..715ab14 100644
--- a/arch/arm/mach-omap2/cm.h
+++ b/arch/arm/mach-omap2/cm.h
@@ -76,6 +76,7 @@
 #define OMAP3430ES2_CM_CLKEN2  0x0004
 #define OMAP3430ES2_CM_FCLKEN3 0x0008
 #define OMAP3430_CM_IDLEST_PLL CM_IDLEST2
+#define OMAP3430_CM_IDLEST30x0028
 #define OMAP3430_CM_AUTOIDLE_PLL   CM_AUTOIDLE2
 #define OMAP3430ES2_CM_AUTOIDLE2_PLL   CM_AUTOIDLE2
 #define OMAP3430_CM_CLKSEL1CM_CLKSEL
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 5e2ef63..e8704a6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -64,6 +64,28 @@ u32 sleep_while_idle;
 u32 wakeup_timer_seconds;
 u32 voltage_off_while_idle;
 
+/* IDLEST bitmasks for core status checks */
+#define CORE_IDLEST1_ALL   (\
+   OMAP3430ES2_ST_MMC3_MASK|OMAP3430_ST_ICR_MASK|\
+   OMAP3430_ST_AES2_MASK|OMAP3430_ST_SHA12_MASK|\
+   OMAP3430_ST_DES2_MASK|OMAP3430_ST_MMC2_MASK|\
+   OMAP3430_ST_MMC1_MASK|OMAP3430_ST_MSPRO_MASK|\
+   OMAP3430_ST_HDQ_MASK|OMAP3430_ST_MCSPI4_MASK|\
+   OMAP3430_ST_MCSPI3_MASK|OMAP3430_ST_MCSPI2_MASK|\
+   OMAP3430_ST_MCSPI1_MASK|OMAP3430_ST_I2C3_MASK|\
+   OMAP3430_ST_I2C2_MASK|OMAP3430_ST_I2C1_MASK|\
+   OMAP3430_ST_GPT11_MASK|OMAP3430_ST_GPT10_MASK|\
+   OMAP3430_ST_MCBSP5_MASK|OMAP3430_ST_MCBSP1_MASK|\
+   OMAP3430ES2_ST_HSOTGUSB_STDBY_MASK|\
+   OMAP3430ES2_ST_SSI_IDLE_MASK|OMAP3430_ST_SDMA_MASK|\
+   OMAP3430_ST_SSI_STDBY_MASK|OMAP3430_ST_D2D_MASK)
+#define CORE_IDLEST2_ALL   (\
+   OMAP3430_ST_PKA_MASK|OMAP3430_ST_AES1_MASK|\
+   OMAP3430_ST_RNG_MASK|OMAP3430_ST_SHA11_MASK|\
+   OMAP3430_ST_DES1_MASK)
+#define CORE_IDLEST3_ALL   (\
+   OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
+
 struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -408,6 +430,7 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
+   int core_saved_state = PWRDM_POWER_ON;
 
if (!_omap_sram_idle)
return;
@@ -439,9 +462,28 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
 
+   /*
+* Check whether core will enter idle or not. This is needed
+* because I/O pad wakeup will fail if core stays on and PER
+* enters off. This will also prevent unnecessary core context
+* save / restore.
+*/
+   core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+   if (core_next_state  PWRDM_POWER_ON) {
+   core_saved_state = core_next_state;
+   if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1)  CORE_IDLEST1_ALL)
+   != CORE_IDLEST1_ALL ||
+   (cm_read_mod_reg(CORE_MOD, CM_IDLEST2)  CORE_IDLEST2_ALL)
+   != CORE_IDLEST2_ALL ||
+   (cm_read_mod_reg(CORE_MOD, OMAP3430_CM_IDLEST3) 
+   CORE_IDLEST3_ALL) != CORE_IDLEST3_ALL) {
+   core_next_state = PWRDM_POWER_ON;
+   pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
+   }
+   }
+
/* PER */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
-   core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
if (per_next_state  PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
@@ -539,6 +581,8 @@ void omap_sram_idle(void)
enable_smartreflex(SR1);
enable_smartreflex(SR2);
}
+   if (core_saved_state != core_next_state)
+   pwrdm_set_next_pwrst(core_pwrdm, core_saved_state);
 
/* PER */
if (per_next_state  PWRDM_POWER_ON) {
-- 
1.5.4.3

--
To unsubscribe from this list: send the line unsubscribe 

[PATCH 14/17] OMAP3: PM: Disabled I2C4 repeated start operation mode

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

Repeated start forces I2C4 pads low during idle, which increases power
consumption through external pull-ups. On the other hand, this change
increases I2C4 command latencies a bit.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 1fa778f..f492142 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -1375,7 +1375,7 @@ static void __init configure_vc(void)
prm_write_mod_reg(OMAP3430_CMD1 | OMAP3430_RAV1, OMAP3430_GR_MOD,
  OMAP3_PRM_VC_CH_CONF_OFFSET);
 
-   prm_write_mod_reg(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN | OMAP3430_SREN,
+   prm_write_mod_reg(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN,
  OMAP3430_GR_MOD,
  OMAP3_PRM_VC_I2C_CFG_OFFSET);
 
-- 
1.5.4.3

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


[PATCH 03/17] PM: Block CORE off when DSS is active

2009-10-16 Thread Tero Kristo
From: Kalle Jokiniemi kalle.jokini...@digia.com

If CORE power domain is allowed to reach off state
while display is active, the display will go blank.
Fixed by adding a check in idle loop.

Signed-off-by: Kalle Jokiniemi ext-kalle.jokini...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e8704a6..52a3f2b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -103,7 +103,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
 
 static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
 static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm, *iva2_pwrdm;
+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
 
 static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -427,6 +427,7 @@ void omap_sram_idle(void)
int mpu_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
+   int dss_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
@@ -469,6 +470,7 @@ void omap_sram_idle(void)
 * save / restore.
 */
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+   dss_state = pwrdm_read_pwrst(dss_pwrdm);
if (core_next_state  PWRDM_POWER_ON) {
core_saved_state = core_next_state;
if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1)  CORE_IDLEST1_ALL)
@@ -479,6 +481,10 @@ void omap_sram_idle(void)
CORE_IDLEST3_ALL) != CORE_IDLEST3_ALL) {
core_next_state = PWRDM_POWER_ON;
pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
+   } else if (core_next_state == PWRDM_POWER_OFF 
+dss_state == PWRDM_POWER_ON) {
+   core_next_state = PWRDM_POWER_RET;
+   pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
}
}
 
@@ -1234,6 +1240,7 @@ static int __init omap3_pm_init(void)
core_pwrdm = pwrdm_lookup(core_pwrdm);
cam_pwrdm = pwrdm_lookup(cam_pwrdm);
iva2_pwrdm = pwrdm_lookup(iva2_pwrdm);
+   dss_pwrdm = pwrdm_lookup(dss_pwrdm);
 
omap_push_sram_idle();
 #ifdef CONFIG_SUSPEND
-- 
1.5.4.3

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


[PATCH 11/17] Make USBHOST powerdomain go to sleep after warm reset.

2009-10-16 Thread Tero Kristo
From: Peter De-Schrijver peter.de-schrij...@nokia.com

This patch makes sure the USBHOST and SGX powerdomains can go to any sleep
state after a warm reset.

Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/cm-regbits-34xx.h |1 +
 arch/arm/mach-omap2/pm34xx.c  |   18 ++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h 
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..3152553 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -680,6 +680,7 @@
 #define OMAP3430_CLKSEL_GPT2_SHIFT 0
 
 /* CM_SLEEPDEP_PER specific bits */
+#define OMAP3430_CM_SLEEPDEP_PER_EN_MPU(1  1)
 #define OMAP3430_CM_SLEEPDEP_PER_EN_IVA2   (1  2)
 
 /* CM_CLKSTCTRL_PER */
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 47f5738..1fa778f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -26,6 +26,7 @@
 #include linux/err.h
 #include linux/gpio.h
 #include linux/clk.h
+#include linux/delay.h
 
 #include mach/sram.h
 #include mach/prcm.h
@@ -934,6 +935,24 @@ static void __init prcm_setup_regs(void)
prm_write_mod_reg(0, OMAP3430_CAM_MOD, PM_WKDEP);
prm_write_mod_reg(0, OMAP3430_PER_MOD, PM_WKDEP);
if (omap_rev()  OMAP3430_REV_ES1_0) {
+
+   /*
+* This workaround is needed to prevent SGX and USBHOST from
+* failing to transition to RET/OFF after a warm reset in OFF
+* mode. Workaround sets a sleepdep of each of these domains
+* with MPU, waits for a min 2 sysclk cycles and clears the
+* sleepdep.
+*/
+   cm_write_mod_reg(OMAP3430_CM_SLEEPDEP_PER_EN_MPU,
+   OMAP3430ES2_USBHOST_MOD, OMAP3430_CM_SLEEPDEP);
+   cm_write_mod_reg(OMAP3430_CM_SLEEPDEP_PER_EN_MPU,
+   OMAP3430ES2_SGX_MOD, OMAP3430_CM_SLEEPDEP);
+   udelay(100);
+   cm_write_mod_reg(0, OMAP3430ES2_USBHOST_MOD,
+   OMAP3430_CM_SLEEPDEP);
+   cm_write_mod_reg(0, OMAP3430ES2_SGX_MOD,
+   OMAP3430_CM_SLEEPDEP);
+
prm_write_mod_reg(0, OMAP3430ES2_SGX_MOD, PM_WKDEP);
prm_write_mod_reg(0, OMAP3430ES2_USBHOST_MOD, PM_WKDEP);
} else
-- 
1.5.4.3

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


[PATCH 10/17] OMAP3: PM: Enable system control module autoidle

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

This saves some power.

Signed-off-by: Mika Westerberg ext-mika.1.westerb...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 6a41811..47f5738 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -1039,6 +1039,8 @@ static void __init prcm_setup_regs(void)
CM_AUTOIDLE);
}
 
+   omap_ctrl_writel(OMAP3430_AUTOIDLE, OMAP2_CONTROL_SYSCONFIG);
+
/*
 * Set all plls to autoidle. This is needed until autoidle is
 * enabled by clockfw
-- 
1.5.4.3

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


[PATCH 13/17] OMAP3: Fixed ARM aux ctrl register save/restore

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

Current value is stored on SDRAM and it is written back during wakeup.
Previously a static value of 0x72 was written there.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/control.c   |1 +
 arch/arm/mach-omap2/sleep34xx.S |   23 ---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 296f2c2..730fc53 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -94,6 +94,7 @@ void *omap3_secure_ram_storage;
  * during the restore path.
  */
 u32 omap3_arm_context[128];
+u32 omap3_aux_ctrl[2] = { 0x1, 0x0 };
 
 struct omap3_control_regs {
u32 sysconfig;
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index f4f5ebe..0b03bf9 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -26,6 +26,7 @@
  */
 #include linux/linkage.h
 #include asm/assembler.h
+#include asm/memory.h
 #include mach/io.h
 #include mach/control.h
 
@@ -278,7 +279,11 @@ restore:
mov r1, #0  @ set task id for ROM code in r1
mov r2, #4  @ set some flags in r2, r6
mov r6, #0xff
-   adr r3, write_aux_control_params@ r3 points to parameters
+   ldr r3, write_aux_control_params@ r3 points to parameters
+   ldr r4, phys_offset
+   addsr3, r3, r4
+   ldr r4, page_offset
+   subsr3, r3, r4
mcr p15, 0, r0, c7, c10, 4  @ data write barrier
mcr p15, 0, r0, c7, c10, 5  @ data memory barrier
.word   0xE1600071  @ call SMI monitor (smi #1)
@@ -287,13 +292,18 @@ restore:
 l2_inv_api_params:
.word   0x1, 0x00
 write_aux_control_params:
-   .word   0x1, 0x72
+   .word   omap3_aux_ctrl
 l2_inv_gp:
/* Execute smi to invalidate L2 cache */
mov r12, #0x1 @ set up to invalide L2
 smi:.word 0xE1600070   @ Call SMI monitor (smieq)
/* Write to Aux control register to set some bits */
-   mov r0, #0x72
+   ldr r1, write_aux_control_params
+   ldr r0, phys_offset
+   addsr1, r1, r0
+   ldr r0, page_offset
+   subsr1, r1, r0
+   ldr r0, [r1, #4]
mov r12, #0x3
.word 0xE1600070@ Call SMI monitor (smieq)
 logic_l1_restore:
@@ -420,6 +430,9 @@ usettbr0:
 save_context_wfi:
/*b save_context_wfi*/  @ enable to debug save code
mov r8, r0 /* Store SDRAM address in r8 */
+   mrc p15, 0, r4, c1, c0, 1   @ Read Auxiliary Control Register
+   ldr r5, write_aux_control_params
+   str r4, [r5, #4]
 /* Check what that target sleep state is:stored in r1*/
 /* 1 - Only L1 and logic lost */
 /* 2 - Only L2 lost */
@@ -605,6 +618,10 @@ wait_dll_lock:
 bne wait_dll_lock
 bx  lr
 
+phys_offset:
+   .word   PHYS_OFFSET
+page_offset:
+   .word   PAGE_OFFSET
 cm_idlest1_core:
.word   CM_IDLEST1_CORE_V
 sdrc_dlla_status:
-- 
1.5.4.3

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


[PATCH 05/17] OMAP:PM: Precedence fix

2009-10-16 Thread Tero Kristo
From: Carlos Chinea carlos.chi...@nokia.com

Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 4addc41..588ab79 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -225,8 +225,8 @@ static void omap3_core_save_context(void)
control_padconf_off |= START_PADCONF_SAVE;
omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
/* wait for the save to complete */
-   while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
-PADCONF_SAVE_DONE)
+   while (!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
+PADCONF_SAVE_DONE))
;
/* Save the Interrupt controller context */
omap3_intc_save_context();
-- 
1.5.4.3

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


[PATCH 15/17] OMAP3: PM: Added support for L2 aux ctrl register save and restore

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

This patch adds a save and restore mechanism for ARM L2 auxiliary control
register. This feature is enabled via Kconfig option
OMAP3_L2_AUX_SECURE_SAVE_RESTORE and the service ID for PPA can be provided
via option OMAP3_L2_AUX_SECURE_SERVICE_SET_ID. If bootloader does not modify
L2 aux register, using this save and restore logic for it is not needed.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/control.c   |1 +
 arch/arm/mach-omap2/sleep34xx.S |   31 +++
 arch/arm/plat-omap/Kconfig  |   17 +
 3 files changed, 49 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 730fc53..82d8f1a 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -95,6 +95,7 @@ void *omap3_secure_ram_storage;
  */
 u32 omap3_arm_context[128];
 u32 omap3_aux_ctrl[2] = { 0x1, 0x0 };
+u32 omap3_l2_aux_ctrl[2] = { 0x1, 0x0 };
 
 struct omap3_control_regs {
u32 sysconfig;
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 0b03bf9..e291d6d 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -288,11 +288,30 @@ restore:
mcr p15, 0, r0, c7, c10, 5  @ data memory barrier
.word   0xE1600071  @ call SMI monitor (smi #1)
 
+#ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+   /* Restore L2 aux control register */
+   @ set service ID for PPA
+   mov r0, #CONFIG_OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
+   mov r12, r0 @ copy service ID in r12
+   mov r1, #0  @ set task ID for ROM code in r1
+   mov r2, #4  @ set some flags in r2, r6
+   mov r6, #0xff
+   ldr r3, write_l2_aux_control_params @ r3 points to parameters
+   ldr r4, phys_offset
+   addsr3, r3, r4
+   ldr r4, page_offset
+   subsr3, r3, r4
+   mcr p15, 0, r0, c7, c10, 4  @ data write barrier
+   mcr p15, 0, r0, c7, c10, 5  @ data memory barrier
+   .word   0xE1600071  @ call SMI monitor (smi #1)
+#endif
b   logic_l1_restore
 l2_inv_api_params:
.word   0x1, 0x00
 write_aux_control_params:
.word   omap3_aux_ctrl
+write_l2_aux_control_params:
+   .word   omap3_l2_aux_ctrl
 l2_inv_gp:
/* Execute smi to invalidate L2 cache */
mov r12, #0x1 @ set up to invalide L2
@@ -306,6 +325,15 @@ smi:.word 0xE1600070   @ Call SMI monitor 
(smieq)
ldr r0, [r1, #4]
mov r12, #0x3
.word 0xE1600070@ Call SMI monitor (smieq)
+   /* Restore L2 AUX control register */
+   ldr r1, write_l2_aux_control_params
+   ldr r0, phys_offset
+   addsr1, r1, r0
+   ldr r0, page_offset
+   subsr1, r1, r0
+   ldr r0, [r1, #4]
+   mov r12, #0x2
+   .word 0xE1600070@ Call SMI monitor (smieq)
 logic_l1_restore:
mov r1, #0
/* Invalidate all instruction caches to PoU
@@ -433,6 +461,9 @@ save_context_wfi:
mrc p15, 0, r4, c1, c0, 1   @ Read Auxiliary Control Register
ldr r5, write_aux_control_params
str r4, [r5, #4]
+   mrc p15, 1, r4, c9, c0, 2   @ Read L2 AUX ctrl register
+   ldr r5, write_l2_aux_control_params
+   str r4, [r5, #4]
 /* Check what that target sleep state is:stored in r1*/
 /* 1 - Only L1 and logic lost */
 /* 2 - Only L2 lost */
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 2143db5..3ff1a5f 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -185,6 +185,23 @@ config OMAP3_DEBOBS
help
  Use ETK pads for debug observability
 
+config OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+   bool OMAP3 HS/EMU save and restore for L2 AUX control register
+   depends on ARCH_OMAP3  PM
+   default n
+   help
+ Without this option, L2 Auxiliary control register contents are
+ lost during off-mode entry on HS/EMU devices. This feature
+ requires support from PPA / boot-loader in HS/EMU devices, which
+ currently does not exist by default.
+
+config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
+   int Service ID for the support routine to set L2 AUX control
+   depends on OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+   default 43
+   help
+ PPA routine service ID for setting L2 auxiliary control register.
+
 config OMAP_32K_TIMER_HZ
int Kernel internal timer frequency for 32KHz timer
range 32 1024
-- 
1.5.4.3

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


[PATCH 17/17] OMAP3: PM: Force disable OTG autoidle

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

OMAP3 sleep can be prevented in some cases where OTG autoidle is enabled.
This patch force disables autoidle during boot and after wakeup from off-mode.
See omap erratas 1.164 and 1.165.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ae83121..5f351f2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -94,6 +94,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
 
+#define OTG_SYSCONFIG  (OMAP34XX_HSUSB_OTG_BASE + 0x404)
+
 struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -423,6 +425,16 @@ static void restore_table_entry(void)
restore_control_register(control_reg_value);
 }
 
+static inline void disable_otg_autoidle(void)
+{
+   /*
+* OTG autoidle can prevent core domain sleep in some cases, thus
+* disable it. See omap erratas 1.164 and 1.165.
+*/
+   cm_set_mod_reg_bits(OMAP3430_EN_HSOTGUSB, CORE_MOD, CM_ICLKEN1);
+   omap_writel(0x0, OTG_SYSCONFIG);
+}
+
 void omap_sram_idle(void)
 {
/* Variable to tell what needs to be saved and restored
@@ -628,6 +640,7 @@ void omap_sram_idle(void)
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+   disable_otg_autoidle();
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
@@ -1417,6 +1430,7 @@ static int __init omap3_pm_early_init(void)
OMAP3_PRM_POLCTRL_OFFSET);
 
configure_vc();
+   disable_otg_autoidle();
 
return 0;
 }
-- 
1.5.4.3

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


[PATCH 04/17] OMAP3: PM: Do not enable IO wake-up on boot

2009-10-16 Thread Tero Kristo
From: Jouni Hogander jouni.hogan...@nokia.com

IO wake-ups are enabled/disabled in idle loop. No need to enable them on boot.

Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 52a3f2b..4addc41 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -1027,9 +1027,8 @@ static void __init prcm_setup_regs(void)
 OMAP3_PRM_CLKSRC_CTRL_OFFSET);
 
/* setup wakup source */
-   prm_write_mod_reg(OMAP3430_EN_IO | OMAP3430_EN_GPIO1 |
- OMAP3430_EN_GPT1 | OMAP3430_EN_GPT12,
- WKUP_MOD, PM_WKEN);
+   prm_write_mod_reg(OMAP3430_EN_GPIO1 | OMAP3430_EN_GPT1 |
+ OMAP3430_EN_GPT12, WKUP_MOD, PM_WKEN);
/* No need to write EN_IO, that is always enabled */
prm_write_mod_reg(OMAP3430_EN_GPIO1 | OMAP3430_EN_GPT1 |
  OMAP3430_EN_GPT12,
-- 
1.5.4.3

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


[PATCH 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

It is suggested by TI (SWPA152 February 2009) to write clksetup,
voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in idle loop.

Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |   36 +---
 1 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f492142..ae83121 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -575,6 +575,30 @@ void omap_sram_idle(void)
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
 
+   /* Write voltage setup times which are changed dynamically */
+   if (core_next_state == PWRDM_POWER_OFF) {
+   prm_write_mod_reg(0, OMAP3430_GR_MOD,
+   OMAP3_PRM_VOLTSETUP1_OFFSET);
+   prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
+   OMAP3_PRM_VOLTSETUP2_OFFSET);
+   prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
+   OMAP3_PRM_CLKSETUP_OFFSET);
+   } else {
+   prm_write_mod_reg((prm_setup.voltsetup_time2 
+   OMAP3430_SETUP_TIME2_SHIFT) |
+   (prm_setup.voltsetup_time1 
+   OMAP3430_SETUP_TIME1_SHIFT),
+   OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
+   prm_write_mod_reg(0, OMAP3430_GR_MOD,
+   OMAP3_PRM_VOLTSETUP2_OFFSET);
+   /*
+* Use static 1 as only HF_CLKOUT is turned off.
+* Value taken from application note SWPA152
+*/
+   prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
+   OMAP3_PRM_CLKSETUP_OFFSET);
+   }
+
/*
 * omap3_arm_context is the location where ARM registers
 * get saved. The restore path then reads from this
@@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
  OMAP3430_GR_MOD,
  OMAP3_PRM_VC_I2C_CFG_OFFSET);
 
-   /* Write setup times */
-   prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
-   OMAP3_PRM_CLKSETUP_OFFSET);
-   prm_write_mod_reg((prm_setup.voltsetup_time2 
-   OMAP3430_SETUP_TIME2_SHIFT) |
-   (prm_setup.voltsetup_time1 
-   OMAP3430_SETUP_TIME1_SHIFT),
-   OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
-
+   /* Write static setup times */
prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTOFFSET_OFFSET);
-   prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
-   OMAP3_PRM_VOLTSETUP2_OFFSET);
 
pm_dbg_regset_init(1);
pm_dbg_regset_init(2);
-- 
1.5.4.3

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


[PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller

2009-10-16 Thread Tero Kristo
From: Jouni Hogander jouni.hogan...@nokia.com

OMAP interrupt controller goes to unknown state when there is right
combination of l3,l4 sleep/wake-up transitions, l4 autoidle in
interrupt controller and some interrupt. When this happens, interrupts
are not delivered to ARM anymore and ARM will remain in WFI (wait for
interrupt) until interrupt controller is forced to wake-up
(i.e. lauterbach). Disable AUTOIDLE in INTC for now.

Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/irq.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 4ed05e9..76179a2 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -167,8 +167,10 @@ static void __init omap_irq_bank_init_one(struct 
omap_irq_bank *bank)
while (!(intc_bank_read_reg(bank, INTC_SYSSTATUS)  0x1))
/* Wait for reset to complete */;
 
-   /* Enable autoidle */
+   /* Do not enable autoidle as it seems to cause problems */
+#if 0
intc_bank_write_reg(1  0, bank, INTC_SYSCONFIG);
+#endif
 }
 
 int omap_irq_pending(void)
-- 
1.5.4.3

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


RE: [PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration

2009-10-16 Thread Gopinath, Thara


-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Sripathy, Vishwanath
Sent: Friday, October 16, 2009 4:45 AM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org; Kevin Hilman
Subject: [PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM 
configration

As part of Core domain context restoration while coming out of off mode
there are some registers being restored which are not required to be restored.
ROM code should have restored them already. Overwriting some of them can have
potential side effect. Eg: CM_CLKEN_PLL register should not be written while 
dpll is locked.

Signed-off-by: Vishwanath BS vishwanath...@ti.com
---

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index fb864cc..da16804 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -279,7 +279,6 @@ void omap3_prcm_save_context(void)
  prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG);
  prcm_context.sgx_cm_clksel =
   cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL);
- prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
  prcm_context.dss_cm_clksel =
   cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL);
  prcm_context.cam_cm_clksel =
@@ -296,8 +295,6 @@ void omap3_prcm_save_context(void)
  cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4);
  prcm_context.pll_cm_clksel5 =
   cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
- prcm_context.pll_cm_clken =
- cm_read_mod_reg(PLL_MOD, CM_CLKEN);
  prcm_context.pll_cm_clken2 =
  cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
  prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
@@ -343,8 +340,6 @@ void omap3_prcm_save_context(void)
   cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2);
  prcm_context.mpu_cm_autoidle2 =
   cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2);
- prcm_context.pll_cm_autoidle =
-  cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
  prcm_context.iva2_cm_clkstctrl =
   cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
  prcm_context.mpu_cm_clkstctrl =
@@ -436,7 +431,6 @@ void omap3_prcm_restore_context(void)
  __raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG);
  cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD,
   CM_CLKSEL);
- cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL);
  cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD,
   CM_CLKSEL);
  cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD,
@@ -453,7 +447,6 @@ void omap3_prcm_restore_context(void)
  OMAP3430ES2_CM_CLKSEL4);
  cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
   OMAP3430ES2_CM_CLKSEL5);
- cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
  cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
  OMAP3430ES2_CM_CLKEN2);
  __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
@@ -492,7 +485,6 @@ void omap3_prcm_restore_context(void)
  cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD,
  CM_AUTOIDLE2);
  cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2);
- cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE);
  cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD,
  CM_CLKSTCTRL);
  cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL);

Why not remove these unwanted variables wkup_cm_clksel, pll_cm_clken, 
pll_cm_autoidle from the structure omap3_prcm_regs also?

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


[PATCH] OMAP3: GPIO: Added dynamic control logic for pad wakeups

2009-10-16 Thread Tero Kristo
From: Tero Kristo tero.kri...@nokia.com

Pad wakeups are now enabled if the corresponding GPIO interrupt is enabled.

Applies on top of PM branch.

Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/plat-omap/gpio.c |   22 +-
 1 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index e242112..fa79db2 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -267,6 +267,7 @@ static struct gpio_bank gpio_bank_34xx[6] = {
 #define OMAP34XX_PAD_SAFE_MODE 0x7
 #define OMAP34XX_PAD_IN_PU_GPIO 0x11c
 #define OMAP34XX_PAD_IN_PD_GPIO 0x10c
+#define OMAP34XX_PAD_WAKE_EN (1  14)
 
 struct omap3_gpio_regs {
u32 sysconfig;
@@ -713,6 +714,8 @@ static inline void set_24xx_gpio_triggering(struct 
gpio_bank *bank, int gpio,
 {
void __iomem *base = bank-base;
u32 gpio_bit = 1  gpio;
+   struct gpio_pad *pad;
+   int gpio_num;
u32 val;
 
if (cpu_is_omap44xx()) {
@@ -750,6 +753,23 @@ static inline void set_24xx_gpio_triggering(struct 
gpio_bank *bank, int gpio,
 * GPIO wakeup request can only be generated on edge
 * transitions
 */
+   pad = gpio_pads;
+
+   gpio_num = bank-virtual_irq_start - IH_GPIO_BASE +
+   gpio;
+   /* Find the pad corresponding the GPIO */
+   while (pad-gpio = 0  pad-gpio != gpio_num)
+   pad++;
+   /* Enable / disable pad wakeup */
+   if (pad-gpio == gpio_num) {
+   val = omap_ctrl_readw(pad-offset);
+   if (trigger  IRQ_TYPE_EDGE_BOTH)
+   val |= OMAP34XX_PAD_WAKE_EN;
+   else
+   val = ~(u16)OMAP34XX_PAD_WAKE_EN;
+   omap_ctrl_writew(val, pad-offset);
+   }
+
if (trigger  IRQ_TYPE_EDGE_BOTH)
__raw_writel(1  gpio, bank-base
+ OMAP24XX_GPIO_SETWKUENA);
@@ -1654,7 +1674,7 @@ static int __init omap3_gpio_pads_init(void)
gpio_pads[gpio_amt].gpio = -1;
return 0;
 }
-late_initcall(omap3_gpio_pads_init);
+early_initcall(omap3_gpio_pads_init);
 #endif
 
 /* This lock class tells lockdep that GPIO irqs are in a different
-- 
1.5.4.3

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


RE: [PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration

2009-10-16 Thread Sripathy, Vishwanath
Yes it can be removed. I will repost the patch with them removed.

Vishwa

-Original Message-
From: Gopinath, Thara 
Sent: Friday, October 16, 2009 6:16 AM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org; Kevin Hilman
Subject: RE: [PATCH] OMAP3: PM: Removing redundant and potentially dangerous 
PRCM configration



-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Sripathy, Vishwanath
Sent: Friday, October 16, 2009 4:45 AM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org; Kevin Hilman
Subject: [PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM 
configration

As part of Core domain context restoration while coming out of off mode
there are some registers being restored which are not required to be restored.
ROM code should have restored them already. Overwriting some of them can have
potential side effect. Eg: CM_CLKEN_PLL register should not be written while 
dpll is locked.

Signed-off-by: Vishwanath BS vishwanath...@ti.com
---

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index fb864cc..da16804 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -279,7 +279,6 @@ void omap3_prcm_save_context(void)
  prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG);
  prcm_context.sgx_cm_clksel =
   cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL);
- prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
  prcm_context.dss_cm_clksel =
   cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL);
  prcm_context.cam_cm_clksel =
@@ -296,8 +295,6 @@ void omap3_prcm_save_context(void)
  cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4);
  prcm_context.pll_cm_clksel5 =
   cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
- prcm_context.pll_cm_clken =
- cm_read_mod_reg(PLL_MOD, CM_CLKEN);
  prcm_context.pll_cm_clken2 =
  cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
  prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
@@ -343,8 +340,6 @@ void omap3_prcm_save_context(void)
   cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2);
  prcm_context.mpu_cm_autoidle2 =
   cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2);
- prcm_context.pll_cm_autoidle =
-  cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
  prcm_context.iva2_cm_clkstctrl =
   cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
  prcm_context.mpu_cm_clkstctrl =
@@ -436,7 +431,6 @@ void omap3_prcm_restore_context(void)
  __raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG);
  cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD,
   CM_CLKSEL);
- cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL);
  cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD,
   CM_CLKSEL);
  cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD,
@@ -453,7 +447,6 @@ void omap3_prcm_restore_context(void)
  OMAP3430ES2_CM_CLKSEL4);
  cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
   OMAP3430ES2_CM_CLKSEL5);
- cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
  cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
  OMAP3430ES2_CM_CLKEN2);
  __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
@@ -492,7 +485,6 @@ void omap3_prcm_restore_context(void)
  cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD,
  CM_AUTOIDLE2);
  cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2);
- cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE);
  cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD,
  CM_CLKSTCTRL);
  cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL);

Why not remove these unwanted variables wkup_cm_clksel, pll_cm_clken, 
pll_cm_autoidle from the structure omap3_prcm_regs also?

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


[PATCH v3 2/2] OMAP3: PM: Configure CPUidle latencies/thresholds from board file

2009-10-16 Thread Rajendra Nayak
The CPUidle C state latencies and thresholds are dependent
on various board specific details.
This patch makes it possible to configure these values from the
respective board files.

omap3_pm_init_cpuidle() can now be optionally called from board
files to pass board specific cpuidle parameters.
If the board files do not use this function to pass the params
default values are used which might cause higher consumption
dur to wrong state selection by the governor.

This patch only updates the 3430sdp board files to use
omap3_pm_init_cpuidle().

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/mach-omap2/board-3430sdp.c |   19 ++
 arch/arm/mach-omap2/cpuidle34xx.c   |  105 ---
 arch/arm/mach-omap2/pm.h|8 +++
 3 files changed, 111 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 0f1975c..d2b2f8f 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -73,6 +73,24 @@ static struct prm_setup_vc omap3_setuptime_table = {
.vdd1_off = 0x00,
 };
 
+/* FIXME: These values need to be updated based on more profiling on 3430sdp*/
+static struct cpuidle_params omap3_cpuidle_params_table[] = {
+   /* C1 */
+   {2, 2, 5},
+   /* C2 */
+   {10, 10, 30},
+   /* C3 */
+   {50, 50, 300},
+   /* C4 */
+   {1500, 1800, 4000},
+   /* C5 */
+   {2500, 7500, 12000},
+   /* C6 */
+   {3000, 8500, 15000},
+   /* C7 */
+   {1, 3, 30},
+};
+
 static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -203,6 +221,7 @@ static void __init omap_3430sdp_init_irq(void)
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap3_pm_init_vc(omap3_setuptime_table);
+   omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL, 
omap3_mpu_rate_table,
 omap3_dsp_rate_table, omap3_l3_rate_table);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index c44a942..f1ae474 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -60,6 +60,30 @@ struct omap3_processor_cx 
omap3_power_states[OMAP3_MAX_STATES];
 struct omap3_processor_cx current_cx_state;
 struct powerdomain *mpu_pd, *core_pd, *per_pd;
 
+/*
+ * The latencies/thresholds for various C states have
+ * to be configured from the respective board files.
+ * These are some default values (which might not provide
+ * the best power savings) used on boards which do not
+ * pass these details from the board file.
+ */
+static struct cpuidle_params cpuidle_params_table[] = {
+   /* C1 */
+   {2, 2, 5},
+   /* C2 */
+   {10, 10, 30},
+   /* C3 */
+   {50, 50, 300},
+   /* C4 */
+   {1500, 1800, 4000},
+   /* C5 */
+   {2500, 7500, 12000},
+   /* C6 */
+   {3000, 8500, 15000},
+   /* C7 */
+   {1, 3, 30},
+};
+
 static int omap3_idle_bm_check(void)
 {
if (!omap3_can_sleep())
@@ -165,6 +189,24 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 
 DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 
+void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params)
+{
+   int i;
+
+   if (!cpuidle_board_params)
+   return;
+
+   for (i = OMAP3_STATE_C1; i  OMAP3_MAX_STATES; i++) {
+   cpuidle_params_table[i].sleep_latency =
+   cpuidle_board_params[i].sleep_latency;
+   cpuidle_params_table[i].wake_latency =
+   cpuidle_board_params[i].wake_latency;
+   cpuidle_params_table[i].threshold =
+   cpuidle_board_params[i].threshold;
+   }
+   return;
+}
+
 /* omap3_init_power_states - Initialises the OMAP3 specific C states.
  *
  * Below is the desciption of each C state.
@@ -181,9 +223,12 @@ void omap_init_power_states(void)
/* C1 . MPU WFI + Core active */
omap3_power_states[OMAP3_STATE_C1].valid = 1;
omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
-   omap3_power_states[OMAP3_STATE_C1].sleep_latency = 2;
-   omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 2;
-   omap3_power_states[OMAP3_STATE_C1].threshold = 5;
+   omap3_power_states[OMAP3_STATE_C1].sleep_latency =
+   cpuidle_params_table[OMAP3_STATE_C1].sleep_latency;
+   omap3_power_states[OMAP3_STATE_C1].wakeup_latency =
+   cpuidle_params_table[OMAP3_STATE_C1].wake_latency;
+   omap3_power_states[OMAP3_STATE_C1].threshold =
+   cpuidle_params_table[OMAP3_STATE_C1].threshold;
omap3_power_states[OMAP3_STATE_C1].mpu_state = PWRDM_POWER_ON;

RE: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB and PER into idle loop

2009-10-16 Thread Sripathy, Vishwanath

 
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero Kristo
 Sent: Friday, October 16, 2009 5:49 AM
 To: linux-omap@vger.kernel.org
 Subject: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB and 
 PER into idle loop
 
 From: Tero Kristo tero.kri...@nokia.com
 
 This is needed to prevent core from entering off mode if one of the IVA2,
 USB or PER powerdomains are going to stay at least in retention state.
 If this is not done, a powerdomain waking from RET may access core
 domain which has just been reset.
 
From PRCM HW point of view, if any of non core domains do not enter OFF mode, 
then Core cannot enter off mode. So I do not understand why you want to do 
this change.

 Signed-off-by: Tero Kristo tero.kri...@nokia.com
 ---
  arch/arm/mach-omap2/pm34xx.c |   36 +++-
  1 files changed, 31 insertions(+), 5 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index 588ab79..3e5ae14 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -85,6 +85,13 @@ u32 voltage_off_while_idle;
   OMAP3430_ST_DES1_MASK)
  #define CORE_IDLEST3_ALL (\
   OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
 +#define PER_IDLEST_ALL   (\
 + OMAP3430_ST_WDT3_MASK|OMAP3430_ST_MCBSP4_MASK|\
 + OMAP3430_ST_MCBSP3_MASK|OMAP3430_ST_MCBSP2_MASK|\
 + OMAP3430_ST_GPT9_MASK|OMAP3430_ST_GPT8_MASK|\
 + OMAP3430_ST_GPT7_MASK|OMAP3430_ST_GPT6_MASK|\
 + OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
 + OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
  
  struct power_state {
   struct powerdomain *pwrdm;
 @@ -103,7 +110,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
  
  static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
  static struct powerdomain *core_pwrdm, *per_pwrdm;
 -static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
 +static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm, *usb_pwrdm;
  
  static struct prm_setup_vc prm_setup = {
   .clksetup = 0xff,
 @@ -428,6 +435,8 @@ void omap_sram_idle(void)
   int per_next_state = PWRDM_POWER_ON;
   int core_next_state = PWRDM_POWER_ON;
   int dss_state = PWRDM_POWER_ON;
 + int iva2_state = PWRDM_POWER_ON;
 + int usb_state = PWRDM_POWER_ON;
   int core_prev_state, per_prev_state;
   u32 sdrc_pwr = 0;
   int per_state_modified = 0;
 @@ -463,14 +472,28 @@ void omap_sram_idle(void)
   if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
   pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
  
 + /* Get powerdomain state data */
 + core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
 + dss_state = pwrdm_read_pwrst(dss_pwrdm);
 + iva2_state = pwrdm_read_pwrst(iva2_pwrdm);
 + usb_state = pwrdm_read_pwrst(usb_pwrdm);
 + per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
 +
 + /* Check if PER domain can enter OFF or not */
 + if (per_next_state == PWRDM_POWER_OFF) {
 + if ((cm_read_mod_reg(OMAP3430_PER_MOD, CM_IDLEST) 
 + PER_IDLEST_ALL) != PER_IDLEST_ALL) {
 + per_next_state = PWRDM_POWER_RET;
 + pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
 + per_state_modified = 1;
 + }
 + }
   /*
* Check whether core will enter idle or not. This is needed
* because I/O pad wakeup will fail if core stays on and PER
* enters off. This will also prevent unnecessary core context
* save / restore.
*/
 - core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
 - dss_state = pwrdm_read_pwrst(dss_pwrdm);
   if (core_next_state  PWRDM_POWER_ON) {
   core_saved_state = core_next_state;
   if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1)  CORE_IDLEST1_ALL)
 @@ -482,14 +505,16 @@ void omap_sram_idle(void)
   core_next_state = PWRDM_POWER_ON;
   pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
   } else if (core_next_state == PWRDM_POWER_OFF 
 -  dss_state == PWRDM_POWER_ON) {
 +  (dss_state == PWRDM_POWER_ON ||
 +   iva2_state = PWRDM_POWER_RET ||
 +   usb_state = PWRDM_POWER_RET ||
 +   per_next_state = PWRDM_POWER_RET)) {
   core_next_state = PWRDM_POWER_RET;
   pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
   }
   }
  
   /* PER */
 - per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
   if (per_next_state  PWRDM_POWER_ON) {
   omap_uart_prepare_idle(2);
   omap2_gpio_prepare_for_idle(per_next_state);
 @@ -1240,6 +1265,7 @@ 

RE: [PATCH 1/2] twl4030: Do not dereference null pointer in error path

2009-10-16 Thread ilkka.koskinen

Hi Samuel,

What is the status of this patch and the other one:
[PATCH 2/2] twl4030: Enable low-power mode to 32KHz oscillator

Cheers, Ilkka

-Original Message-
From: Koskinen Ilkka (Nokia-D/Tampere) 
Sent: 30 September, 2009 18:12
To: linux-ker...@vger.kernel.org; sa...@linux.intel.com
Cc: linux-omap@vger.kernel.org; Koskinen Ilkka (Nokia-D/Tampere)
Subject: [PATCH 1/2] twl4030: Do not dereference null pointer 
in error path

Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
 drivers/mfd/twl4030-core.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index e424cf6..8cf0a02 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -792,7 +792,7 @@ twl4030_probe(struct i2c_client *client, 
const struct i2c_device_id *id)
   twl-client = i2c_new_dummy(client-adapter,
   twl-address);
   if (!twl-client) {
-  dev_err(twl-client-dev,
+  dev_err(client-dev,
   can't attach client %d\n, i);
   status = -ENOMEM;
   goto fail;
-- 
1.6.0.4

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


RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller

2009-10-16 Thread Woodruff, Richard

 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Tero Kristo
 Sent: Friday, October 16, 2009 5:49 AM

 OMAP interrupt controller goes to unknown state when there is right
 combination of l3,l4 sleep/wake-up transitions, l4 autoidle in
 interrupt controller and some interrupt. When this happens, interrupts
 are not delivered to ARM anymore and ARM will remain in WFI (wait for
 interrupt) until interrupt controller is forced to wake-up
 (i.e. lauterbach). Disable AUTOIDLE in INTC for now.

Optimal work around enables and disables this around WFI.

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


Re: stable kernel version

2009-10-16 Thread Janosch Machowinski



I will try out the 2.6.31 mainline kernel tommorw.


I just tried 2.6.31.4 kernel from kernel.org
same result as with the 2.6.31-omap head:
2271096 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 8200 ...
  Image Name:   Linux-2.6.31.4
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:2271032 Bytes =  2.2 MB
  Load Address: 80008000
  Entry Point:  80008000
  Verifying Checksum ... OK
  Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing 
Linux 
done, booting the kernel.


-- after this message it stops doing anything

Any ideas, what's wrong, or how to debug this ?

Regards
   Janosch


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


RE: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB and PER into idle loop

2009-10-16 Thread Cousson, Benoit

From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
Sent: Friday, October 16, 2009 3:16 PM
To: Tero Kristo; linux-omap@vger.kernel.org
Subject: RE: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB
and PER into idle loop

 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
 Sent: Friday, October 16, 2009 5:49 AM
 To: linux-omap@vger.kernel.org
 Subject: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB
and PER into idle loop
 
 From: Tero Kristo tero.kri...@nokia.com
 
 This is needed to prevent core from entering off mode if one of the IVA2,
 USB or PER powerdomains are going to stay at least in retention state.
 If this is not done, a powerdomain waking from RET may access core
 domain which has just been reset.
 
From PRCM HW point of view, if any of non core domains do not enter OFF
mode, then Core cannot enter off mode. So I do not understand why you want
to do this change.

This is perfectly valid for the PRCM point of view to have the CORE OFF while 
another power domain is ON. The sleep dependency is at the clock domains level. 
It means that all initiators need to be mute and all targets must be in idle, 
but the power domain can be ON.

Regards,
Benoit


 Signed-off-by: Tero Kristo tero.kri...@nokia.com
 ---
  arch/arm/mach-omap2/pm34xx.c |   36 +++-
  1 files changed, 31 insertions(+), 5 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index 588ab79..3e5ae14 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -85,6 +85,13 @@ u32 voltage_off_while_idle;
  OMAP3430_ST_DES1_MASK)
  #define CORE_IDLEST3_ALL(\
  OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
 +#define PER_IDLEST_ALL  (\
 +OMAP3430_ST_WDT3_MASK|OMAP3430_ST_MCBSP4_MASK|\
 +OMAP3430_ST_MCBSP3_MASK|OMAP3430_ST_MCBSP2_MASK|\
 +OMAP3430_ST_GPT9_MASK|OMAP3430_ST_GPT8_MASK|\
 +OMAP3430_ST_GPT7_MASK|OMAP3430_ST_GPT6_MASK|\
 +OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
 +OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
 
  struct power_state {
  struct powerdomain *pwrdm;
 @@ -103,7 +110,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
 
  static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
  static struct powerdomain *core_pwrdm, *per_pwrdm;
 -static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
 +static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm,
*usb_pwrdm;
 
  static struct prm_setup_vc prm_setup = {
  .clksetup = 0xff,
 @@ -428,6 +435,8 @@ void omap_sram_idle(void)
  int per_next_state = PWRDM_POWER_ON;
  int core_next_state = PWRDM_POWER_ON;
  int dss_state = PWRDM_POWER_ON;
 +int iva2_state = PWRDM_POWER_ON;
 +int usb_state = PWRDM_POWER_ON;
  int core_prev_state, per_prev_state;
  u32 sdrc_pwr = 0;
  int per_state_modified = 0;
 @@ -463,14 +472,28 @@ void omap_sram_idle(void)
  if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
  pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
 
 +/* Get powerdomain state data */
 +core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
 +dss_state = pwrdm_read_pwrst(dss_pwrdm);
 +iva2_state = pwrdm_read_pwrst(iva2_pwrdm);
 +usb_state = pwrdm_read_pwrst(usb_pwrdm);
 +per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
 +
 +/* Check if PER domain can enter OFF or not */
 +if (per_next_state == PWRDM_POWER_OFF) {
 +if ((cm_read_mod_reg(OMAP3430_PER_MOD, CM_IDLEST) 
 +PER_IDLEST_ALL) != PER_IDLEST_ALL) {
 +per_next_state = PWRDM_POWER_RET;
 +pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
 +per_state_modified = 1;
 +}
 +}
  /*
   * Check whether core will enter idle or not. This is needed
   * because I/O pad wakeup will fail if core stays on and PER
   * enters off. This will also prevent unnecessary core context
   * save / restore.
   */
 -core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
 -dss_state = pwrdm_read_pwrst(dss_pwrdm);
  if (core_next_state  PWRDM_POWER_ON) {
  core_saved_state = core_next_state;
  if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1)  CORE_IDLEST1_ALL)
 @@ -482,14 +505,16 @@ void omap_sram_idle(void)
  core_next_state = PWRDM_POWER_ON;
  pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
  } else if (core_next_state == PWRDM_POWER_OFF 
 - dss_state == PWRDM_POWER_ON) {
 + (dss_state == PWRDM_POWER_ON ||
 +  iva2_state = PWRDM_POWER_RET ||
 +  usb_state = 

Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread Dirk Behme

John,

John Rigby wrote:

Dirk,

Many thanks, after sending the request yesterday I made my own attempt
which failed miserably.  My patch looks like a subset of yours so that
is to be expected.  I'll try yours out today and report back my
experience.


I got already some (private) feedback (thanks!):

- Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null 
pointer :( Seems that mmc-card isn't set yet while calling 
omap_hsmmc_set_ios().


As workaround, for testing only, I hard coded setting IBG with 
something like


case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
-   OMAP_HSMMC_WRITE(host-base, HCTL,
-   OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+   OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, 
HCTL) | IBG | FOUR_BIT);

   break;

If you test this, be careful that this doesn't hurt any other 4 bit 
cards except the SDIO you want to test.


Later, we have to find a way how to detect that we are in SDIO mode. 
We want to set IBG only if in SDIO and 4 bit mode.


-  After this, I got the report that null pointer crash is gone. But 
SDIO doesn't seem to work any more:


libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#1)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#2)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#3)
libertas: command 0x0003 timed out
libertas: Excessive timeouts submitting command 0x0003
libertas: PREP_CMD: command 0x0003 failed: -110
libertas_sdio: probe of mmc1:0001:1 failed with error -110

I now start to think about it ;)

Again, any help would be appreciated!

Best regards

Dirk


On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com wrote:

John Rigby wrote:

I have seen several discussions about lack of sdio irq support in the
hsmmc driver but no patches.  Has anyone on this list implemented this
and/or can anyone point me to patches?

What a coincidence ;)

I'm currently working on this. See attachment what I currently have. It is
compile tested only against recent omap linux head. I don't have a board
using SDIO at the moment, so no real testing possible :(

Some background, maybe it helps people to step in:

Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by MMC
port 2 in 4 bit configuration [1]. The wifi performance is quite bad
(~100kB/s). There is some rumor that this might be SDIO irq related [2].
There was an attempt to fix this [3] already, but this doesn't work [4].
Having this, I started to look into it.

I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO
Simplified Specification [6] and the OMAP35x TRM [7] as starting points.

Unfortunately, the Davinci MMC registers and irqs are different (Davinci has
a dedicated SDIO irq). But combining [3] and [5] helps to get an idea what
has to be done.

I think the main issues of [3] were that it doesn't enable IBG for 4 bit
mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the irq bits.

Topics I still open:

- Is it always necessary to deal with IE _and_ ISE register? I'm not totally
clear what the difference between these two registers are ;) And in which
order they have to be set.

- Davinci driver [5] in line 1115 checks for data line to call
mmc_signal_sdio_irq() for irq enable.

- Davinci driver deals with SDIO in xfer_done() (line 873)

- Davinci driver sets block size to 64 if SDIO in line 701

It would be quite nice if anybody likes to comment on attachment and help
testing.

Many thanks and best regards

Dirk

[1] http://gumstix.net/wiki/index.php?title=Overo_Wifi

[2] http://groups.google.com/group/beagleboard/msg/14e822778c5eeb56

[3] http://groups.google.com/group/beagleboard/msg/d0eb69f4c20673be

[4] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937

[5]
http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD

[6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/

[7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf


Subject: [PATCH][RFC] OMAP HSMMC: Add SDIO interrupt support
Form: Dirk Behme dirk.be...@googlemail.com

At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in
poor
performance. Add support for SDIO interrupt handling.

Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---

Patch against recent omap-linux head Linux omap got rebuilt from scratch
274c94b29ee7c53609a756acca974e4742c59559

Compile tested only. Please comment and help testing.

 drivers/mmc/host/omap_hsmmc.c |   48

Re: [RFC][Patch V1] OMAP3: Mux Changes.

2009-10-16 Thread Nishanth Menon

Cory Maccarrone had written, on 10/16/2009 09:15 AM, the following:
On Thu, Oct 15, 2009 at 9:53 PM, Nishanth Menon n...@ti.com 
mailto:n...@ti.com wrote:


Pais, Allen had written, on 10/15/2009 11:53 PM, the following:

a) A simple comment to all my comments: why cant we have these
in bootloader and just simply leave the mux file alone?
[Allen] Yes Nishanth, this would be a much cleaner approach.
Even Santosh had suggested
The same, if we can conclude on a approach here, I can go ahead
and do the Mux Change it accordingly.

Then lets please fix the bootloader and drop this patch.



[...]
Maybe I'm missing something, but why is it more desirable to add the mux 
code to the bootloader instead of the kernel?  Wouldn't adding it to the 
kernel guarantee it works regardless of the bootloader?
adding mux in kernel guarentees that it is independent of the bootloader 
- yes - no questions on that. There are two strategies that can be taken:


A) Ensure that kernel is independent from bootloader variances
  - this is desirable and would adhere to the rules of an entity uses 
the resources(muxes) ONLY what it is required for itself to work - e.g. 
bootloader would use the minimal set that is required for itself to 
function.


B) Divide the load - always assume that kernel and bootloaders work 
together.
   - Do all the static muxes in u-boot - since the u-boot dies off 
once the kernel starts up, the memory is completely freed up.
   - Only the dynamic muxes (e.g. pins being used in two modes by two 
drivers) are handled by the kernel.


The current strategy that is implemented for OMAP3 is (B), but once the 
kernel infrastructure for mux handling improves we should be able to 
arrive at a compromise between A and B as far as execution latencies Vs 
memory usage Vs independence issues are concerned. we are not there yet 
unfortunately.



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


Re: stable kernel version

2009-10-16 Thread Janosch Machowinski



I will try out the 2.6.31 mainline kernel tommorw.


I just tried 2.6.31.4 kernel from kernel.org
same result as with the 2.6.31-omap head:
2271096 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 8200 ...
  Image Name:   Linux-2.6.31.4
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:2271032 Bytes =  2.2 MB
  Load Address: 80008000
  Entry Point:  80008000
  Verifying Checksum ... OK
  Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing 
Linux 
done, booting the kernel.


-- after this message it stops doing anything

Any ideas, what's wrong, or how to debug this ?

Regards
   Janosch


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


RE: [PATCH 03/17] PM: Block CORE off when DSS is active

2009-10-16 Thread Cousson, Benoit
Hi Tero,


Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 
036 420 040 R.C.S Antibes. Capital de EUR 753.920

-Original Message-

From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Friday, October 16, 2009 12:49 PM
To: linux-omap@vger.kernel.org
Cc: Kalle Jokiniemi
Subject: [PATCH 03/17] PM: Block CORE off when DSS is active

From: Kalle Jokiniemi kalle.jokini...@digia.com

If CORE power domain is allowed to reach off state
while display is active, the display will go blank.
Fixed by adding a check in idle loop.

What is root cause? I guess it is due to extra latency required to wakeup from 
OFF?
In that case, it should be better to use the omap_pm_set_max_dev_wakeup_lat() 
function and set a latency constraint to the CORE.

On the other hand, I remember a discussion between Kevin and Tomi saying that 
this API might not be fully functional yet.

Regards,
Benoit


Signed-off-by: Kalle Jokiniemi ext-kalle.jokini...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
 arch/arm/mach-omap2/pm34xx.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e8704a6..52a3f2b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -103,7 +103,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);

 static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
 static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm, *iva2_pwrdm;
+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;

 static struct prm_setup_vc prm_setup = {
   .clksetup = 0xff,
@@ -427,6 +427,7 @@ void omap_sram_idle(void)
   int mpu_next_state = PWRDM_POWER_ON;
   int per_next_state = PWRDM_POWER_ON;
   int core_next_state = PWRDM_POWER_ON;
+  int dss_state = PWRDM_POWER_ON;
   int core_prev_state, per_prev_state;
   u32 sdrc_pwr = 0;
   int per_state_modified = 0;
@@ -469,6 +470,7 @@ void omap_sram_idle(void)
* save / restore.
*/
   core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+  dss_state = pwrdm_read_pwrst(dss_pwrdm);
   if (core_next_state  PWRDM_POWER_ON) {
   core_saved_state = core_next_state;
   if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1)  CORE_IDLEST1_ALL)
@@ -479,6 +481,10 @@ void omap_sram_idle(void)
   CORE_IDLEST3_ALL) != CORE_IDLEST3_ALL) {
   core_next_state = PWRDM_POWER_ON;
   pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
+  } else if (core_next_state == PWRDM_POWER_OFF 
+   dss_state == PWRDM_POWER_ON) {
+  core_next_state = PWRDM_POWER_RET;
+  pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
   }
   }

@@ -1234,6 +1240,7 @@ static int __init omap3_pm_init(void)
   core_pwrdm = pwrdm_lookup(core_pwrdm);
   cam_pwrdm = pwrdm_lookup(cam_pwrdm);
   iva2_pwrdm = pwrdm_lookup(iva2_pwrdm);
+  dss_pwrdm = pwrdm_lookup(dss_pwrdm);

   omap_push_sram_idle();
 #ifdef CONFIG_SUSPEND
--
1.5.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: stable kernel version

2009-10-16 Thread Tony Lindgren
* Janosch Machowinski sco...@tzi.de [091016 08:05]:

 I will try out the 2.6.31 mainline kernel tommorw.
 
 I just tried 2.6.31.4 kernel from kernel.org
 same result as with the 2.6.31-omap head:
 2271096 bytes read
 Booting from mmc ...
 ## Booting kernel from Legacy Image at 8200 ...
   Image Name:   Linux-2.6.31.4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:2271032 Bytes =  2.2 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
 OK

 Starting kernel ...

 Uncompressing  
 Linux
  
 done, booting the kernel.

 -- after this message it stops doing anything

 Any ideas, what's wrong, or how to debug this ?

Can you try it with the omap-debug branch, and enable
the CONFIG_DEBUG_LL option in your .config?

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


Re: [RFC][Patch V1] OMAP3: Mux Changes.

2009-10-16 Thread Tony Lindgren
* Nishanth Menon n...@ti.com [091016 08:04]:
 Cory Maccarrone had written, on 10/16/2009 09:15 AM, the following:
 On Thu, Oct 15, 2009 at 9:53 PM, Nishanth Menon n...@ti.com  
 mailto:n...@ti.com wrote:

 Pais, Allen had written, on 10/15/2009 11:53 PM, the following:

 a) A simple comment to all my comments: why cant we have these
 in bootloader and just simply leave the mux file alone?
 [Allen] Yes Nishanth, this would be a much cleaner approach.
 Even Santosh had suggested
 The same, if we can conclude on a approach here, I can go ahead
 and do the Mux Change it accordingly.

 Then lets please fix the bootloader and drop this patch.


 [...]
 Maybe I'm missing something, but why is it more desirable to add the 
 mux code to the bootloader instead of the kernel?  Wouldn't adding it 
 to the kernel guarantee it works regardless of the bootloader?
 adding mux in kernel guarentees that it is independent of the bootloader  
 - yes - no questions on that. There are two strategies that can be taken:

Muxing in the bootloader only leads to impossible to debug bugs of type
my device does not work where the kernel has no clue what's going on.

In addition, at least the GPIO pins need to be dynamically remuxed
during the off-while-idle.

Also, if CONFIG_MUX is not set, the code is optimized out.

See the earlier discussion on the muxing. Basically we are going to move
to init time muxing in board-*.c files hopefully this coming merge window.
I'll post some patches probably next week on this.

Meanwhile, the current mux system works just fine, but is not suitable
for what we need for the dynamic GPIO pin muxing.


 A) Ensure that kernel is independent from bootloader variances
   - this is desirable and would adhere to the rules of an entity uses  
 the resources(muxes) ONLY what it is required for itself to work - e.g.  
 bootloader would use the minimal set that is required for itself to  
 function.

 B) Divide the load - always assume that kernel and bootloaders work  
 together.
- Do all the static muxes in u-boot - since the u-boot dies off once 
 the kernel starts up, the memory is completely freed up.
- Only the dynamic muxes (e.g. pins being used in two modes by two  
 drivers) are handled by the kernel.

 The current strategy that is implemented for OMAP3 is (B), but once the  
 kernel infrastructure for mux handling improves we should be able to  
 arrive at a compromise between A and B as far as execution latencies Vs  
 memory usage Vs independence issues are concerned. we are not there yet  
 unfortunately.

Once we have all the mux stuff reworked, we should move to model where
we mux all the pins during boot. This is with CONFIG_MUX set, without
that it will be all optimized out.

Regards,

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


Re: stable kernel version

2009-10-16 Thread Phil Carmody
On Fri, 2009-10-16 at 17:05 +0200, ext Janosch Machowinski wrote:
 
  I will try out the 2.6.31 mainline kernel tommorw.
  
 I just tried 2.6.31.4 kernel from kernel.org
 same result as with the 2.6.31-omap head:
 2271096 bytes read
 Booting from mmc ...
 ## Booting kernel from Legacy Image at 8200 ...
Image Name:   Linux-2.6.31.4
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:2271032 Bytes =  2.2 MB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
 OK
 
 Starting kernel ...
 
 Uncompressing 
 Linux
  
 done, booting the kernel.
 
 -- after this message it stops doing anything
 
 Any ideas, what's wrong, or how to debug this ?

DEBUG_LL often helps with problems at that point.

Phil
-- 
They weren't designed to run on a computer, they were designed
to run on a Powerpoint slide projector. -- Peter Gutmann

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


[PATCHV2] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration

2009-10-16 Thread Sripathy, Vishwanath
As part of Core domain context restoration while coming out of off mode
there are some registers being restored which are not required to be restored.
ROM code should have restored them already. Overwriting some of them can have
potential side effect. Eg: CM_CLKEN_PLL register should not be written while 
dpll is locked.

Signed-off-by: Vishwanath BS vishwanath...@ti.com
---

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index fb864cc..88182a8 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -43,7 +43,6 @@ struct omap3_prcm_regs {
u32 iva2_cm_clksel2;
u32 cm_sysconfig;
u32 sgx_cm_clksel;
-   u32 wkup_cm_clksel;
u32 dss_cm_clksel;
u32 cam_cm_clksel;
u32 per_cm_clksel;
@@ -52,7 +51,6 @@ struct omap3_prcm_regs {
u32 pll_cm_autoidle2;
u32 pll_cm_clksel4;
u32 pll_cm_clksel5;
-   u32 pll_cm_clken;
u32 pll_cm_clken2;
u32 cm_polctrl;
u32 iva2_cm_fclken;
@@ -76,7 +74,6 @@ struct omap3_prcm_regs {
u32 usbhost_cm_iclken;
u32 iva2_cm_autiidle2;
u32 mpu_cm_autoidle2;
-   u32 pll_cm_autoidle;
u32 iva2_cm_clkstctrl;
u32 mpu_cm_clkstctrl;
u32 core_cm_clkstctrl;
@@ -279,7 +276,6 @@ void omap3_prcm_save_context(void)
prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG);
prcm_context.sgx_cm_clksel =
 cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL);
-   prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
prcm_context.dss_cm_clksel =
 cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL);
prcm_context.cam_cm_clksel =
@@ -296,8 +292,6 @@ void omap3_prcm_save_context(void)
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4);
prcm_context.pll_cm_clksel5 =
 cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
-   prcm_context.pll_cm_clken =
-   cm_read_mod_reg(PLL_MOD, CM_CLKEN);
prcm_context.pll_cm_clken2 =
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
@@ -343,8 +337,6 @@ void omap3_prcm_save_context(void)
 cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2);
prcm_context.mpu_cm_autoidle2 =
 cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2);
-   prcm_context.pll_cm_autoidle =
-cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
prcm_context.iva2_cm_clkstctrl =
 cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
prcm_context.mpu_cm_clkstctrl =
@@ -436,7 +428,6 @@ void omap3_prcm_restore_context(void)
__raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG);
cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD,
 CM_CLKSEL);
-   cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL);
cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD,
 CM_CLKSEL);
cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD,
@@ -453,7 +444,6 @@ void omap3_prcm_restore_context(void)
OMAP3430ES2_CM_CLKSEL4);
cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
 OMAP3430ES2_CM_CLKSEL5);
-   cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
OMAP3430ES2_CM_CLKEN2);
__raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
@@ -492,7 +482,6 @@ void omap3_prcm_restore_context(void)
cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD,
CM_AUTOIDLE2);
cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2);
-   cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE);
cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD,
CM_CLKSTCTRL);
cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread John Rigby
Dirk,

Thanks for the update.  After looking more closely at your patch I
found that the only thing my attempt was missing was the IBG setting.
I added that to mine with the result that the system hangs on loading
the libertas modules.  The last thing i see is the firmware request
message.  I will continue to work on this and let you know what I
find.

John

On Fri, Oct 16, 2009 at 9:02 AM, Dirk Behme dirk.be...@googlemail.com wrote:
 John,

 John Rigby wrote:

 Dirk,

 Many thanks, after sending the request yesterday I made my own attempt
 which failed miserably.  My patch looks like a subset of yours so that
 is to be expected.  I'll try yours out today and report back my
 experience.

 I got already some (private) feedback (thanks!):

 - Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null
 pointer :( Seems that mmc-card isn't set yet while calling
 omap_hsmmc_set_ios().

 As workaround, for testing only, I hard coded setting IBG with something
 like

        case MMC_BUS_WIDTH_4:
                OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
 -               OMAP_HSMMC_WRITE(host-base, HCTL,
 -                       OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
 +                       OMAP_HSMMC_WRITE(host-base, HCTL,
 +                                        OMAP_HSMMC_READ(host-base, HCTL) |
 IBG | FOUR_BIT);
               break;

 If you test this, be careful that this doesn't hurt any other 4 bit cards
 except the SDIO you want to test.

 Later, we have to find a way how to detect that we are in SDIO mode. We want
 to set IBG only if in SDIO and 4 bit mode.

 -  After this, I got the report that null pointer crash is gone. But SDIO
 doesn't seem to work any more:

 libertas_sdio: Libertas SDIO driver
 libertas_sdio: Copyright Pierre Ossman
 libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
 libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
 libertas: command 0x0003 timed out
 libertas: requeueing command 0x0003 due to timeout (#1)
 libertas: command 0x0003 timed out
 libertas: requeueing command 0x0003 due to timeout (#2)
 libertas: command 0x0003 timed out
 libertas: requeueing command 0x0003 due to timeout (#3)
 libertas: command 0x0003 timed out
 libertas: Excessive timeouts submitting command 0x0003
 libertas: PREP_CMD: command 0x0003 failed: -110
 libertas_sdio: probe of mmc1:0001:1 failed with error -110

 I now start to think about it ;)

 Again, any help would be appreciated!

 Best regards

 Dirk

 On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com
 wrote:

 John Rigby wrote:

 I have seen several discussions about lack of sdio irq support in the
 hsmmc driver but no patches.  Has anyone on this list implemented this
 and/or can anyone point me to patches?

 What a coincidence ;)

 I'm currently working on this. See attachment what I currently have. It
 is
 compile tested only against recent omap linux head. I don't have a board
 using SDIO at the moment, so no real testing possible :(

 Some background, maybe it helps people to step in:

 Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by MMC
 port 2 in 4 bit configuration [1]. The wifi performance is quite bad
 (~100kB/s). There is some rumor that this might be SDIO irq related [2].
 There was an attempt to fix this [3] already, but this doesn't work [4].
 Having this, I started to look into it.

 I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO
 Simplified Specification [6] and the OMAP35x TRM [7] as starting points.

 Unfortunately, the Davinci MMC registers and irqs are different (Davinci
 has
 a dedicated SDIO irq). But combining [3] and [5] helps to get an idea
 what
 has to be done.

 I think the main issues of [3] were that it doesn't enable IBG for 4 bit
 mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the irq
 bits.

 Topics I still open:

 - Is it always necessary to deal with IE _and_ ISE register? I'm not
 totally
 clear what the difference between these two registers are ;) And in which
 order they have to be set.

 - Davinci driver [5] in line 1115 checks for data line to call
 mmc_signal_sdio_irq() for irq enable.

 - Davinci driver deals with SDIO in xfer_done() (line 873)

 - Davinci driver sets block size to 64 if SDIO in line 701

 It would be quite nice if anybody likes to comment on attachment and help
 testing.

 Many thanks and best regards

 Dirk

 [1] http://gumstix.net/wiki/index.php?title=Overo_Wifi

 [2] http://groups.google.com/group/beagleboard/msg/14e822778c5eeb56

 [3] http://groups.google.com/group/beagleboard/msg/d0eb69f4c20673be

 [4] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937

 [5]

 http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD

 [6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/

 [7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf


 Subject: 

Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread Dirk Behme

John Rigby wrote:

Dirk,

Thanks for the update.  After looking more closely at your patch I
found that the only thing my attempt was missing was the IBG setting.
I added that to mine with the result that the system hangs on loading
the libertas modules.


On which board are you working? libertas does mean you are working on 
wifi connected via SDIO?



The last thing i see is the firmware request
message. 


Ok, you see a hang. Below we have a timeout.

I would vote for some interrupt issues. For timeouts I would vote for 
missing interrupts, while system hang might be infinite interrupts 
(something like this was reported in [1]).


Could you add some debug code in omap_hsmmc_enable_sdio_irq() to trace 
if enable/disable is called in the correct order? And in 
omap_hsmmc_irq() in if (status  CIRQ) { to check if and how often it 
is called?


Best regards

Dirk

[1] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937


On Fri, Oct 16, 2009 at 9:02 AM, Dirk Behme dirk.be...@googlemail.com wrote:

John,

John Rigby wrote:

Dirk,

Many thanks, after sending the request yesterday I made my own attempt
which failed miserably.  My patch looks like a subset of yours so that
is to be expected.  I'll try yours out today and report back my
experience.

I got already some (private) feedback (thanks!):

- Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null
pointer :( Seems that mmc-card isn't set yet while calling
omap_hsmmc_set_ios().

As workaround, for testing only, I hard coded setting IBG with something
like

   case MMC_BUS_WIDTH_4:
   OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
-   OMAP_HSMMC_WRITE(host-base, HCTL,
-   OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+   OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL) |
IBG | FOUR_BIT);
  break;

If you test this, be careful that this doesn't hurt any other 4 bit cards
except the SDIO you want to test.

Later, we have to find a way how to detect that we are in SDIO mode. We want
to set IBG only if in SDIO and 4 bit mode.

-  After this, I got the report that null pointer crash is gone. But SDIO
doesn't seem to work any more:

libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#1)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#2)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#3)
libertas: command 0x0003 timed out
libertas: Excessive timeouts submitting command 0x0003
libertas: PREP_CMD: command 0x0003 failed: -110
libertas_sdio: probe of mmc1:0001:1 failed with error -110

I now start to think about it ;)

Again, any help would be appreciated!

Best regards

Dirk


On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com
wrote:

John Rigby wrote:

I have seen several discussions about lack of sdio irq support in the
hsmmc driver but no patches.  Has anyone on this list implemented this
and/or can anyone point me to patches?

What a coincidence ;)

I'm currently working on this. See attachment what I currently have. It
is
compile tested only against recent omap linux head. I don't have a board
using SDIO at the moment, so no real testing possible :(

Some background, maybe it helps people to step in:

Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by MMC
port 2 in 4 bit configuration [1]. The wifi performance is quite bad
(~100kB/s). There is some rumor that this might be SDIO irq related [2].
There was an attempt to fix this [3] already, but this doesn't work [4].
Having this, I started to look into it.

I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO
Simplified Specification [6] and the OMAP35x TRM [7] as starting points.

Unfortunately, the Davinci MMC registers and irqs are different (Davinci
has
a dedicated SDIO irq). But combining [3] and [5] helps to get an idea
what
has to be done.

I think the main issues of [3] were that it doesn't enable IBG for 4 bit
mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the irq
bits.

Topics I still open:

- Is it always necessary to deal with IE _and_ ISE register? I'm not
totally
clear what the difference between these two registers are ;) And in which
order they have to be set.

- Davinci driver [5] in line 1115 checks for data line to call
mmc_signal_sdio_irq() for irq enable.

- Davinci driver deals with SDIO in xfer_done() (line 873)

- Davinci driver sets block size to 64 if SDIO in line 701

It would be quite nice if anybody likes to comment on attachment and help
testing.

Many thanks and best regards

Dirk

[1] http://gumstix.net/wiki/index.php?title=Overo_Wifi

[2] 

Re: [alsa-devel] [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies

2009-10-16 Thread Tony Lindgren
* Mark Brown broo...@opensource.wolfsonmicro.com [091015 02:01]:
 On Wed, Oct 14, 2009 at 10:15:48AM -0700, Tony Lindgren wrote:
  * Mark Brown broo...@opensource.wolfsonmicro.com [091012 02:18]:
   On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote:
 
I'm afraid using dev_name is not that easy. The mmc driver generates 
device
name at runtime. That's why this board file setups .dev at runtime as 
well.
 
 ...
 
So, changing this supply to something static using .dev_name it is not
possible with current code. That would need refactoring the whole mmc 
and
hsmmc setup. And the device naming procedure is dependent on cpu as 
well.
Check arch/arm/mach-omap2/device.c:omap2_init_mmc.
 
   same answer each time it's run?  How does this work with the clock API?
 
  The clocks are matched using clkdev. Basically the driver just requests
  functional clock (fck) and interface clock (ick):
 
  $ grep mmci arch/arm/*omap*/clock*.c
  arch/arm/mach-omap1/clock.c:CLK(mmci-omap.0, fck,   
  mmc1_ck,   CK_16XX | CK_1510 | CK_310),
  arch/arm/mach-omap1/clock.c:CLK(mmci-omap.0, ick,   
  armper_ck.clk, CK_16XX | CK_1510 | CK_310),
 
 So this is using the standard dev_name based clkdev matching which
 Eduardo said was impossible for the regulators.  Is it just that this
 will actually work fine for the regulators or is there some other magic
 in the OMAP code that joins things up?

Well the mmc regulators are just passed from board-*.c files to
mmc-twl4030.c which does all the low-level init needed. No other
special magic going on.

Eduardro, care to check the dev_name issue one more time?

Regards,

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


Re: [PATCH] omap: Use getnstimeofday for omap_device

2009-10-16 Thread Paul Walmsley
On Wed, 7 Oct 2009, Tony Lindgren wrote:

 Don't know if this generic solution is accurate enough?

Looks fine to me.  Thanks -

Acked-by: Paul Walmsley p...@pwsan.com

 
 Tony
 
 
 From 4b059c50262954ae4ce466983b5cf088851eab19 Mon Sep 17 00:00:00 2001
 From: Tony Lindgren t...@atomide.com
 Date: Wed, 7 Oct 2009 17:10:18 -0700
 Subject: [PATCH] omap: Use getnstimeofday for omap_device
 
 Otherwise we cannot remove OMAP2_IO_ADDRESS.
 
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 diff --git a/arch/arm/plat-omap/omap_device.c 
 b/arch/arm/plat-omap/omap_device.c
 index 2c409fc..12513f4 100644
 --- a/arch/arm/plat-omap/omap_device.c
 +++ b/arch/arm/plat-omap/omap_device.c
 @@ -103,21 +103,6 @@
  /* Private functions */
  
  /**
 - * _read_32ksynct - read the OMAP 32K sync timer
 - *
 - * Returns the current value of the 32KiHz synchronization counter.
 - * XXX this should be generalized to simply read the system clocksource.
 - * XXX this should be moved to a separate synctimer32k.c file
 - */
 -static u32 _read_32ksynct(void)
 -{
 - if (!cpu_class_is_omap2())
 - BUG();
 -
 - return __raw_readl(OMAP2_IO_ADDRESS(OMAP_32KSYNCT_BASE + 0x010));
 -}
 -
 -/**
   * _omap_device_activate - increase device readiness
   * @od: struct omap_device *
   * @ignore_lat: increase to latency target (0) or full readiness (1)?
 @@ -133,13 +118,13 @@ static u32 _read_32ksynct(void)
   */
  static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
  {
 - u32 a, b;
 + struct timespec a, b, c;
  
   pr_debug(omap_device: %s: activating\n, od-pdev.name);
  
   while (od-pm_lat_level  0) {
   struct omap_device_pm_latency *odpl;
 - int act_lat = 0;
 + unsigned long long act_lat = 0;
  
   od-pm_lat_level--;
  
 @@ -149,20 +134,22 @@ static int _omap_device_activate(struct omap_device 
 *od, u8 ignore_lat)
   (od-dev_wakeup_lat = od-_dev_wakeup_lat_limit))
   break;
  
 - a = _read_32ksynct();
 + getnstimeofday(a);
  
   /* XXX check return code */
   odpl-activate_func(od);
  
 - b = _read_32ksynct();
 + getnstimeofday(b);
  
 - act_lat = (b - a)  15; /* 32KiHz cycles to microseconds */
 + c = timespec_sub(b, a);
 + act_lat = timespec_to_ns(c) * NSEC_PER_USEC;
  
   pr_debug(omap_device: %s: pm_lat %d: activate: elapsed time 
 -  %d usec\n, od-pdev.name, od-pm_lat_level, act_lat);
 +  %llu usec\n, od-pdev.name, od-pm_lat_level,
 +  act_lat);
  
   WARN(act_lat  odpl-activate_lat, omap_device: %s.%d: 
 -  activate step %d took longer than expected (%d  %d)\n,
 +  activate step %d took longer than expected (%llu  %d)\n,
od-pdev.name, od-pdev.id, od-pm_lat_level,
act_lat, odpl-activate_lat);
  
 @@ -188,13 +175,13 @@ static int _omap_device_activate(struct omap_device 
 *od, u8 ignore_lat)
   */
  static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
  {
 - u32 a, b;
 + struct timespec a, b, c;
  
   pr_debug(omap_device: %s: deactivating\n, od-pdev.name);
  
   while (od-pm_lat_level  od-pm_lats_cnt) {
   struct omap_device_pm_latency *odpl;
 - int deact_lat = 0;
 + unsigned long long deact_lat = 0;
  
   odpl = od-pm_lats + od-pm_lat_level;
  
 @@ -203,23 +190,24 @@ static int _omap_device_deactivate(struct omap_device 
 *od, u8 ignore_lat)
od-_dev_wakeup_lat_limit))
   break;
  
 - a = _read_32ksynct();
 + getnstimeofday(a);
  
   /* XXX check return code */
   odpl-deactivate_func(od);
  
 - b = _read_32ksynct();
 + getnstimeofday(b);
  
 - deact_lat = (b - a)  15; /* 32KiHz cycles to microseconds */
 + c = timespec_sub(b, a);
 + deact_lat = timespec_to_ns(c) * NSEC_PER_USEC;
  
   pr_debug(omap_device: %s: pm_lat %d: deactivate: elapsed time 
 -  %d usec\n, od-pdev.name, od-pm_lat_level,
 +  %llu usec\n, od-pdev.name, od-pm_lat_level,
deact_lat);
  
   WARN(deact_lat  odpl-deactivate_lat, omap_device: %s.%d: 
 -  deactivate step %d took longer than expected (%d  %d)\n,
 -  od-pdev.name, od-pdev.id, od-pm_lat_level,
 -  deact_lat, odpl-deactivate_lat);
 +  deactivate step %d took longer than expected 
 +  (%llu  %d)\n, od-pdev.name, od-pdev.id,
 +  od-pm_lat_level, deact_lat, odpl-deactivate_lat);
  
   od-dev_wakeup_lat += odpl-activate_lat;
  
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap 

Re: [PATCH] omap: Use ioremap for omap_hwmod instead of OMAP2_IO_ADDRESS

2009-10-16 Thread Paul Walmsley
On Wed, 7 Oct 2009, Tony Lindgren wrote:

 From f05ba4e3427bc0dc216f2fca32a9b1e8f0e38695 Mon Sep 17 00:00:00 2001
 From: Tony Lindgren t...@atomide.com
 Date: Wed, 7 Oct 2009 17:10:18 -0700
 Subject: [PATCH] omap: Use ioremap for omap_hwmod instead of OMAP2_IO_ADDRESS
 
 Otherwise we cannot get rid of OMAP2_IO_ADDRESS.

Acked-by: Paul Walmsley p...@pwsan.com



 
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
 b/arch/arm/mach-omap2/omap_hwmod.c
 index d2e0f1c..8ac8798 100644
 --- a/arch/arm/mach-omap2/omap_hwmod.c
 +++ b/arch/arm/mach-omap2/omap_hwmod.c
 @@ -496,6 +496,7 @@ static void __iomem *_find_mpu_rt_base(struct omap_hwmod 
 *oh, u8 index)
   struct omap_hwmod_addr_space *mem;
   int i;
   int found = 0;
 + void __iomem *va_start;
  
   if (!oh || oh-slaves_cnt == 0)
   return NULL;
 @@ -509,16 +510,20 @@ static void __iomem *_find_mpu_rt_base(struct 
 omap_hwmod *oh, u8 index)
   }
   }
  
 - /* XXX use ioremap() instead? */
 -
 - if (found)
 + if (found) {
 + va_start = ioremap(mem-pa_start, mem-pa_end - mem-pa_start);
 + if (!va_start) {
 + pr_err(omap_hwmod: %s: Could not ioremap\n, oh-name);
 + return NULL;
 + }
   pr_debug(omap_hwmod: %s: MPU register target at va %p\n,
 -  oh-name, OMAP2_IO_ADDRESS(mem-pa_start));
 - else
 +  oh-name, va_start);
 + } else {
   pr_debug(omap_hwmod: %s: no MPU register target found\n,
oh-name);
 + }
  
 - return (found) ? OMAP2_IO_ADDRESS(mem-pa_start) : NULL;
 + return (found) ? va_start : NULL;
  }
  
  /**
 @@ -1148,6 +1153,7 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
   pr_debug(omap_hwmod: %s: unregistering\n, oh-name);
  
   mutex_lock(omap_hwmod_mutex);
 + iounmap(oh-_rt_va);
   list_del(oh-node);
   mutex_unlock(omap_hwmod_mutex);
  
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 


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


Re: [PATCH] CPUidle: always return with interrupts enabled

2009-10-16 Thread Martin Michlmayr
* Andrew Morton a...@linux-foundation.org [2009-10-06 13:34]:
 Rigor mortis is setting in on this one.

 The patch seems correct to me.

Can someone put this patch in now?  The problem has also been reported
on Marvell's Kirkwood platform (ARM) by a number of users and the
patch fixes it.

Tested-by: Martin Michlmayr t...@cyrius.com

Please CC stable when you commit the patch since it also needs to go
in for 2.6.31.

Reference with the patch: http://patchwork.kernel.org/patch/50728/
-- 
Martin Michlmayr
http://www.cyrius.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 01/17] PM: fix suspend control for IVA2

2009-10-16 Thread Girish S G


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero
 Kristo
 
 From: Tero Kristo tero.kri...@nokia.com
 
 IVA2 controls its target power state individually, thus suspend should not
 touch IVA2. Without this patch DSP suspend always fails.
 
 Signed-off-by: Tero Kristo tero.kri...@nokia.com
 Acked-by: Ameya Palande ameya.pala...@nokia.com
 ---
  arch/arm/mach-omap2/pm34xx.c |9 -
  1 files changed, 8 insertions(+), 1 deletions(-)
 
  static struct prm_setup_vc prm_setup = {
   .clksetup = 0xff,
 @@ -676,6 +676,12 @@ static int omap3_pm_suspend(void)
   pwrst-saved_state = pwrdm_read_next_pwrst(pwrst-pwrdm);
   /* Set ones wanted by suspend */
   list_for_each_entry(pwrst, pwrst_list, node) {
 + /* Special handling for IVA2, just use current sleep state */
 + if (pwrst-pwrdm == iva2_pwrdm) {
 + state = pwrdm_read_pwrst(pwrst-pwrdm);
 + if (state  PWRDM_POWER_ON)
 + pwrst-next_state = state;
 + }

Agree, IVA2 pwrdm is handled autonomously by bridge. I think this needs some 
additional change to remove all the redundant
configuration of iva pwdm. There are some inconsistencies like, 
- Say enable_off_mode is disabled. Before doing system wide suspend if 
DSP hibernates then IVA2 will be put to OFF. In that
case we have IVA2 going to OFF and other domains in RET. This might not be an 
issue, but it's bad from sytem PM framework integrity
perspective.
- enable_off_mode-omap3_pm_off_mode_enable will also touch IVA2 power 
domain next state. This we don't want to do if dsp
bridge is already taking care of IVA2.

IMO, we need to have some mechanism wherein if bridge PM takes care of IVA then 
PM framework should not configure the IVA
powerstate. It should only do if bridge PM is disabled.


-Girish

  


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


Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread Madhusudhan Chikkature
Hi Dirk,

I am inlining the patch so that it helps review.



Subject: [PATCH][RFC] OMAP HSMMC: Add SDIO interrupt support
Form: Dirk Behme dirk.be...@googlemail.com

At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor
performance. Add support for SDIO interrupt handling.

Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---

Patch against recent omap-linux head Linux omap got rebuilt from scratch
274c94b29ee7c53609a756acca974e4742c59559

Compile tested only. Please comment and help testing.

 drivers/mmc/host/omap_hsmmc.c |   48 +-
 1 file changed, 43 insertions(+), 5 deletions(-)

Index: linux-beagle/drivers/mmc/host/omap_hsmmc.c
===
--- linux-beagle.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-beagle/drivers/mmc/host/omap_hsmmc.c
@@ -27,6 +27,7 @@
 #include linux/timer.h
 #include linux/clk.h
 #include linux/mmc/host.h
+#include linux/mmc/card.h
 #include linux/mmc/core.h
 #include linux/io.h
 #include linux/semaphore.h
@@ -65,6 +66,7 @@
 #define SDVSDET0x0400
 #define AUTOIDLE   0x1
 #define SDBP   (1  8)
+#define IBG(1  19)
 #define DTO0xe
 #define ICE0x1
 #define ICS0x2
@@ -76,6 +78,7 @@
 #define INT_EN_MASK0x307F0033
 #define BWR_ENABLE (1  4)
 #define BRR_ENABLE (1  5)
+#define CIRQ_ENABLE(1  8)
 #define INIT_STREAM(1  1)
 #define DP_SELECT  (1  21)
 #define DDIR   (1  4)
@@ -87,6 +90,7 @@
 #define CC 0x1
 #define TC 0x02
 #define OD 0x1
+#define CIRQ   (1   8)
 #define ERR(1  15)
 #define CMD_TIMEOUT(1  16)
 #define DATA_TIMEOUT   (1  20)
@@ -653,6 +657,15 @@ static irqreturn_t omap_hsmmc_irq(int ir
status = OMAP_HSMMC_READ(host-base, STAT);
dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);

+   if (status  CIRQ) {
+   dev_dbg(mmc_dev(host-mmc), SDIO interrupt);
+   OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
+ ~(CIRQ_ENABLE));
+   mmc_signal_sdio_irq(host-mmc);
+   spin_unlock(host-irq_lock);
+   return IRQ_HANDLED;
+   }
+
if (status  ERR) {
 #ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
-   OMAP_HSMMC_WRITE(host-base, HCTL,
-   OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+   if (mmc_card_sdio(host-mmc-card)) {

I wish it could be moved to enable_sdio_irq so that we can avoid inclusion of
card.h and checking the type of card in the host controller driver. But the
dependancy on 4-bit seems to be a problem here.

On the problems being discussed on testing is the interrupt source geting
cleared at the SDIO card level upon genaration of the CIRQ? If not it remains
asserted.

+   OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| IBG | FOUR_BIT);
+   } else {
+   OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| FOUR_BIT);
+   }
break;
case MMC_BUS_WIDTH_1:
OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
@@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
return 0;
 }

+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+   struct omap_hsmmc_host *host = mmc_priv(mmc);
+   u32 ie, ise;
+
+   ise = OMAP_HSMMC_READ(host-base, ISE);
+   ie  = OMAP_HSMMC_READ(host-base, IE);
+
+   if (enable) {
+   OMAP_HSMMC_WRITE(host-base, ISE, ise | CIRQ_ENABLE);
+   OMAP_HSMMC_WRITE(host-base, IE,  ie  | CIRQ_ENABLE);
+   } else {
+   OMAP_HSMMC_WRITE(host-base, ISE, ise  ~CIRQ_ENABLE);
+   OMAP_HSMMC_WRITE(host-base, IE,  ie   ~CIRQ_ENABLE);
+   }
+
+}
+
 static const struct mmc_host_ops omap_hsmmc_ops = {
.enable = omap_hsmmc_enable_fclk,
.disable = omap_hsmmc_disable_fclk,
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hs
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
-   /* NYET -- enable_sdio_irq */
+   .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
 };

 static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ 

RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller

2009-10-16 Thread Girish S G


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
 Woodruff, Richard
 Sent: Friday, October 16, 2009 9:40 AM
 To: Tero Kristo; linux-omap@vger.kernel.org
 Cc: Jouni Hogander
 Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt 
 controller
 
 
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Tero Kristo
  Sent: Friday, October 16, 2009 5:49 AM
 
  OMAP interrupt controller goes to unknown state when there is right
  combination of l3,l4 sleep/wake-up transitions, l4 autoidle in
  interrupt controller and some interrupt. When this happens, interrupts
  are not delivered to ARM anymore and ARM will remain in WFI (wait for
  interrupt) until interrupt controller is forced to wake-up
  (i.e. lauterbach). Disable AUTOIDLE in INTC for now.
 
 Optimal work around enables and disables this around WFI.

On one of the custom board the power measured didn't show any major impact, 
with just one time disabling of INTC-AUTOIDL. However,
optimizing this WA looks good though. I did give it a try,
Disabling/enabling INTC autoidle around WFI on custom board, works well but 
didn't get chance to
measure the numbers.

Regards,
-Girish


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


RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller

2009-10-16 Thread Woodruff, Richard

 From: Ghongdemath, Girish
 Sent: Friday, October 16, 2009 12:48 PM

 On one of the custom board the power measured didn't show any major impact,
 with just one time disabling of INTC-AUTOIDL. However,
 optimizing this WA looks good though. I did give it a try,
 Disabling/enabling INTC autoidle around WFI on custom board, works well but
 didn't get chance to
 measure the numbers.

There was one report from a custom board when it made a difference.  I've not 
tried to double check this data.  I don't have the reporters setup so there is 
no guarantee I could reproduce anyway.  In general optimization seemed to make 
sense.

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


RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller

2009-10-16 Thread Girish S G


 -Original Message-
 From: Woodruff, Richard [mailto:r-woodru...@ti.com]
 Sent: Friday, October 16, 2009 1:04 PM
 To: Ghongdemath, Girish; 'Tero Kristo'; linux-omap@vger.kernel.org
 Cc: 'Jouni Hogander'
 Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt 
 controller


 
 There was one report from a custom board when it made a difference.  I've not 
 tried to double check
 this data.  I don't have the reporters setup so there is no guarantee I could 
 reproduce anyway.  In
 general optimization seemed to make sense.

I second it.


Regards,
Girish

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


[PATCH] omapfb: Wrong test on unsigned?

2009-10-16 Thread Roel Kluin
Only if the test is signed negative values can be spotted.

Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Is this correct? please review.

diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 0d0c8c8..cc7dd93 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -286,7 +286,7 @@ static int _setcolreg(struct fb_info *info, u_int regno, 
u_int red, u_int green,
if (r != 0)
break;
 
-   if (regno  0) {
+   if ((int)regno  0) {
r = -EINVAL;
break;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread John Rigby
First the disclaimers:
The board is new board that has had hardware mmc/sdio problems before.
 It is based closely on beagle but uses a different package which has
some package specific issues.  We think we have found them all but who
knows.

My kernel is a few months old 2.6.29.

Ok, given the above issues, it looks to me like I am getting
interrupted every time  CIRQ is enabled.  Nor sure if the libertas
driver is not disabling as it should or what.  So I end up in this
death spiral:

irq handler is called and status indicates CIRQ is pending

mmc_signal_sdio_irq is called which calls omap_hsmmc_enable_sdio_irq
with via mmc_host_ops, en is zero so CIRQ gets disabled

mmc_signal_sdio_irq then wakes up sdio_irq_thread which does its thing
then before going to sleep calls omap_hsmmc_enable_irq with en set to
1 so CIRC gets turned back on

with CIRC enabled the irq handler gets called and we are back where we started.

Looks like either the libertas driver is not disabling the irq or the
CIRQ irq is somehow getting stuck or I have a hw problem.

One thing I did try was to have the sdio_irq_thread basically ignore
the MMC_CAP_SDIO_IRQ flag except for calling
host-ops-enable_sdio_irq(host, 1) and I changed mmc_signal_sdio_irq
to not reschedule sdio_irq_thread.  In shows that the mere act of
enabling CIRQ does not break anything.  In this mode I get one CIRQ
irq for each time around the sdio_irq_thread loop.

I guess I should try checking the CIRQ bit in the status register
after calling the libertas handler which should clear the irq?


John


On Fri, Oct 16, 2009 at 10:06 AM, Dirk Behme dirk.be...@googlemail.com wrote:
 John Rigby wrote:

 Dirk,

 Thanks for the update.  After looking more closely at your patch I
 found that the only thing my attempt was missing was the IBG setting.
 I added that to mine with the result that the system hangs on loading
 the libertas modules.

 On which board are you working? libertas does mean you are working on wifi
 connected via SDIO?

 The last thing i see is the firmware request
 message.

 Ok, you see a hang. Below we have a timeout.

 I would vote for some interrupt issues. For timeouts I would vote for
 missing interrupts, while system hang might be infinite interrupts
 (something like this was reported in [1]).

 Could you add some debug code in omap_hsmmc_enable_sdio_irq() to trace if
 enable/disable is called in the correct order? And in omap_hsmmc_irq() in if
 (status  CIRQ) { to check if and how often it is called?

 Best regards

 Dirk

 [1] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937

 On Fri, Oct 16, 2009 at 9:02 AM, Dirk Behme dirk.be...@googlemail.com
 wrote:

 John,

 John Rigby wrote:

 Dirk,

 Many thanks, after sending the request yesterday I made my own attempt
 which failed miserably.  My patch looks like a subset of yours so that
 is to be expected.  I'll try yours out today and report back my
 experience.

 I got already some (private) feedback (thanks!):

 - Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null
 pointer :( Seems that mmc-card isn't set yet while calling
 omap_hsmmc_set_ios().

 As workaround, for testing only, I hard coded setting IBG with something
 like

       case MMC_BUS_WIDTH_4:
               OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
 -               OMAP_HSMMC_WRITE(host-base, HCTL,
 -                       OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
 +                       OMAP_HSMMC_WRITE(host-base, HCTL,
 +                                        OMAP_HSMMC_READ(host-base,
 HCTL) |
 IBG | FOUR_BIT);
              break;

 If you test this, be careful that this doesn't hurt any other 4 bit cards
 except the SDIO you want to test.

 Later, we have to find a way how to detect that we are in SDIO mode. We
 want
 to set IBG only if in SDIO and 4 bit mode.

 -  After this, I got the report that null pointer crash is gone. But SDIO
 doesn't seem to work any more:

 libertas_sdio: Libertas SDIO driver
 libertas_sdio: Copyright Pierre Ossman
 libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
 libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
 libertas: command 0x0003 timed out
 libertas: requeueing command 0x0003 due to timeout (#1)
 libertas: command 0x0003 timed out
 libertas: requeueing command 0x0003 due to timeout (#2)
 libertas: command 0x0003 timed out
 libertas: requeueing command 0x0003 due to timeout (#3)
 libertas: command 0x0003 timed out
 libertas: Excessive timeouts submitting command 0x0003
 libertas: PREP_CMD: command 0x0003 failed: -110
 libertas_sdio: probe of mmc1:0001:1 failed with error -110

 I now start to think about it ;)

 Again, any help would be appreciated!

 Best regards

 Dirk

 On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com
 wrote:

 John Rigby wrote:

 I have seen several discussions about lack of sdio irq support in the
 hsmmc driver but no patches.  Has anyone on this list implemented this
 and/or can anyone 

[RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use Constraint Framework

2009-10-16 Thread Sripathy, Vishwanath
Sysfs entry vdd_opp currently does not use constraint framework. 
Because of this, even if you set the opp via this entry, it has no effect 
since it can be overridden by on demand governor any time.
This patch has changes to make vdd_opp to use constraint framework. 
vdd_lock variable has to be used when application wants to disable DVFS
altogether. This will override any other constraints and will lock the
OPP to given value.

Signed-off-by: Vishwanath BS vishwanath...@ti.com
---

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 13783f3..bcdc00d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -47,6 +47,8 @@ static ssize_t idle_store(struct kobject *k, struct 
kobj_attribute *,
 static ssize_t vdd_opp_show(struct kobject *, struct kobj_attribute *, char *);
 static ssize_t vdd_opp_store(struct kobject *k, struct kobj_attribute *,
  const char *buf, size_t n);
+static ssize_t vdd_opp_lock_store(struct kobject *k, struct kobj_attribute *,
+ const char *buf, size_t n);
 static struct kobj_attribute vdd1_opp_attr =
__ATTR(vdd1_opp, 0644, vdd_opp_show, vdd_opp_store);
 
@@ -103,6 +105,41 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct 
kobj_attribute *attr,
  const char *buf, size_t n)
 {
unsigned short value;
+   struct omap_opp *opp_table;
+
+   if (sscanf(buf, %hu, value) != 1)
+   return -EINVAL;
+
+   if (attr == vdd1_opp_attr) {
+   if (value  MIN_VDD1_OPP || value  MAX_VDD1_OPP) {
+   printk(KERN_ERR vdd_opp_store: Invalid value\n);
+   return -EINVAL;
+   }
+   opp_table = omap_get_mpu_rate_table();
+   omap_pm_cpu_set_freq(sysfs_cpufreq_dev,
+   opp_table[value].rate);
+   } else if (attr == vdd2_opp_attr) {
+   if (value  MIN_VDD2_OPP || (value  MAX_VDD2_OPP)) {
+   printk(KERN_ERR vdd_opp_store: Invalid value\n);
+   return -EINVAL;
+   }
+   if (value == VDD2_OPP2)
+   omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+   OCP_INITIATOR_AGENT, 83*1000*4);
+   else if (value == VDD2_OPP3)
+   omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+   OCP_INITIATOR_AGENT, 166*1000*4);
+
+   } else {
+   return -EINVAL;
+   }
+   return n;
+}
+
+static ssize_t vdd_opp_lock_store(struct kobject *kobj,
+   struct kobj_attribute *attr, const char *buf, size_t n)
+{
+   unsigned short value;
int flags = 0;
 
if (sscanf(buf, %hu, value) != 1)
@@ -121,6 +158,11 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct 
kobj_attribute *attr,
if (vdd1_locked == 0  value != 0) {
resource_lock_opp(VDD1_OPP);
vdd1_locked = 1;
+   if (value  MIN_VDD1_OPP || value  MAX_VDD1_OPP) {
+   printk(KERN_ERR vdd_opp_store: Invalid 
value\n);
+   return -EINVAL;
+   }
+   resource_set_opp_level(VDD1_OPP, value, flags);
}
} else if (attr == vdd2_lock_attr) {
flags = OPP_IGNORE_LOCK;
@@ -134,21 +176,12 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct 
kobj_attribute *attr,
if (vdd2_locked == 0  value != 0) {
resource_lock_opp(VDD2_OPP);
vdd2_locked = 1;
+   if (value  MIN_VDD2_OPP || value  MAX_VDD2_OPP) {
+   printk(KERN_ERR vdd_opp_store: Invalid 
value\n);
+   return -EINVAL;
+   }
+   resource_set_opp_level(VDD2_OPP, value, flags);
}
-   }
-
-   if (attr == vdd1_opp_attr) {
-   if (value  1 || value  5) {
-   printk(KERN_ERR vdd_opp_store: Invalid value\n);
-   return -EINVAL;
-   }
-   resource_set_opp_level(VDD1_OPP, value, flags);
-   } else if (attr == vdd2_opp_attr) {
-   if (value  2 || value  3) {
-   printk(KERN_ERR vdd_opp_store: Invalid value\n);
-   return -EINVAL;
-   }
-   resource_set_opp_level(VDD2_OPP, value, flags);
} else {
return -EINVAL;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use Constraint Framework

2009-10-16 Thread Sripathy, Vishwanath
Note that this patch has dependency on Patch sent by Romit (in attached email).

Vishwanath

-Original Message-
From: Sripathy, Vishwanath 
Sent: Friday, October 16, 2009 2:26 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org; Hilman, Kevin
Subject: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use Constraint Framework

Sysfs entry vdd_opp currently does not use constraint framework. 
Because of this, even if you set the opp via this entry, it has no effect 
since it can be overridden by on demand governor any time.
This patch has changes to make vdd_opp to use constraint framework. 
vdd_lock variable has to be used when application wants to disable DVFS
altogether. This will override any other constraints and will lock the
OPP to given value.

Signed-off-by: Vishwanath BS vishwanath...@ti.com
---

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 13783f3..bcdc00d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -47,6 +47,8 @@ static ssize_t idle_store(struct kobject *k, struct 
kobj_attribute *,
 static ssize_t vdd_opp_show(struct kobject *, struct kobj_attribute *, char *);
 static ssize_t vdd_opp_store(struct kobject *k, struct kobj_attribute *,
  const char *buf, size_t n);
+static ssize_t vdd_opp_lock_store(struct kobject *k, struct kobj_attribute *,
+ const char *buf, size_t n);
 static struct kobj_attribute vdd1_opp_attr =
__ATTR(vdd1_opp, 0644, vdd_opp_show, vdd_opp_store);
 
@@ -103,6 +105,41 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct 
kobj_attribute *attr,
  const char *buf, size_t n)
 {
unsigned short value;
+   struct omap_opp *opp_table;
+
+   if (sscanf(buf, %hu, value) != 1)
+   return -EINVAL;
+
+   if (attr == vdd1_opp_attr) {
+   if (value  MIN_VDD1_OPP || value  MAX_VDD1_OPP) {
+   printk(KERN_ERR vdd_opp_store: Invalid value\n);
+   return -EINVAL;
+   }
+   opp_table = omap_get_mpu_rate_table();
+   omap_pm_cpu_set_freq(sysfs_cpufreq_dev,
+   opp_table[value].rate);
+   } else if (attr == vdd2_opp_attr) {
+   if (value  MIN_VDD2_OPP || (value  MAX_VDD2_OPP)) {
+   printk(KERN_ERR vdd_opp_store: Invalid value\n);
+   return -EINVAL;
+   }
+   if (value == VDD2_OPP2)
+   omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+   OCP_INITIATOR_AGENT, 83*1000*4);
+   else if (value == VDD2_OPP3)
+   omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+   OCP_INITIATOR_AGENT, 166*1000*4);
+
+   } else {
+   return -EINVAL;
+   }
+   return n;
+}
+
+static ssize_t vdd_opp_lock_store(struct kobject *kobj,
+   struct kobj_attribute *attr, const char *buf, size_t n)
+{
+   unsigned short value;
int flags = 0;
 
if (sscanf(buf, %hu, value) != 1)
@@ -121,6 +158,11 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct 
kobj_attribute *attr,
if (vdd1_locked == 0  value != 0) {
resource_lock_opp(VDD1_OPP);
vdd1_locked = 1;
+   if (value  MIN_VDD1_OPP || value  MAX_VDD1_OPP) {
+   printk(KERN_ERR vdd_opp_store: Invalid 
value\n);
+   return -EINVAL;
+   }
+   resource_set_opp_level(VDD1_OPP, value, flags);
}
} else if (attr == vdd2_lock_attr) {
flags = OPP_IGNORE_LOCK;
@@ -134,21 +176,12 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct 
kobj_attribute *attr,
if (vdd2_locked == 0  value != 0) {
resource_lock_opp(VDD2_OPP);
vdd2_locked = 1;
+   if (value  MIN_VDD2_OPP || value  MAX_VDD2_OPP) {
+   printk(KERN_ERR vdd_opp_store: Invalid 
value\n);
+   return -EINVAL;
+   }
+   resource_set_opp_level(VDD2_OPP, value, flags);
}
-   }
-
-   if (attr == vdd1_opp_attr) {
-   if (value  1 || value  5) {
-   printk(KERN_ERR vdd_opp_store: Invalid value\n);
-   return -EINVAL;
-   }
-   resource_set_opp_level(VDD1_OPP, value, flags);
-   } else if (attr == vdd2_opp_attr) {
-   if (value  2 || value  3) {
-   printk(KERN_ERR vdd_opp_store: Invalid value\n);
-   return -EINVAL;
-   }
-   resource_set_opp_level(VDD2_OPP, value, flags);
} else {
return -EINVAL;
   

Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread Dirk Behme

Madhusudhan Chikkature wrote:

Hi Dirk,

I am inlining the patch so that it helps review.

...

@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
-   OMAP_HSMMC_WRITE(host-base, HCTL,
-   OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
+   if (mmc_card_sdio(host-mmc-card)) {

I wish it could be moved to enable_sdio_irq so that we can avoid inclusion of
card.h and checking the type of card in the host controller driver. 


Yes, this would be the real clean way. But ...


But the
dependancy on 4-bit seems to be a problem here.


... most probably we have to find a workaround until (if ever?) above 
clean implementation is available.


What we need is after SDIO mode and bus width is known, and before the 
first interrupt comes, to set IBG.



On the problems being discussed on testing is the interrupt source geting
cleared at the SDIO card level upon genaration of the CIRQ? If not it remains
asserted.


Yes, this seems to be exactly the problem John reports in his follow 
up mail.


Any hint how to clear SDIO interrupt?

Many thanks

Dirk


+   OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| IBG | FOUR_BIT);
+   } else {
+   OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL)
+| FOUR_BIT);
+   }
break;
case MMC_BUS_WIDTH_1:
OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
@@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
return 0;
 }

+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+   struct omap_hsmmc_host *host = mmc_priv(mmc);
+   u32 ie, ise;
+
+   ise = OMAP_HSMMC_READ(host-base, ISE);
+   ie  = OMAP_HSMMC_READ(host-base, IE);
+
+   if (enable) {
+   OMAP_HSMMC_WRITE(host-base, ISE, ise | CIRQ_ENABLE);
+   OMAP_HSMMC_WRITE(host-base, IE,  ie  | CIRQ_ENABLE);
+   } else {
+   OMAP_HSMMC_WRITE(host-base, ISE, ise  ~CIRQ_ENABLE);
+   OMAP_HSMMC_WRITE(host-base, IE,  ie   ~CIRQ_ENABLE);
+   }
+
+}
+
 static const struct mmc_host_ops omap_hsmmc_ops = {
.enable = omap_hsmmc_enable_fclk,
.disable = omap_hsmmc_disable_fclk,
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hs
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
-   /* NYET -- enable_sdio_irq */
+   .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
 };

 static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hs
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
-   /* NYET -- enable_sdio_irq */
+   .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
 };

 #ifdef CONFIG_DEBUG_FS
@@ -1734,7 +1772,7 @@ static int __init omap_hsmmc_probe(struc
mmc-max_seg_size = mmc-max_req_size;

mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_WAIT_WHILE_BUSY;
+MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_SDIO_IRQ;

if (mmc_slot(host).wires = 8)
mmc-caps |= MMC_CAP_8_BIT_DATA;






John Rigby wrote:

I have seen several discussions about lack of sdio irq support in the
hsmmc driver but no patches.  Has anyone on this list implemented this
and/or can anyone point me to patches?

What a coincidence ;)

I'm currently working on this. See attachment what I currently have.
It is compile tested only against recent omap linux head. I don't have
a board using SDIO at the moment, so no real testing possible :(

Some background, maybe it helps people to step in:

Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by
MMC port 2 in 4 bit configuration [1]. The wifi performance is quite
bad (~100kB/s). There is some rumor that this might be SDIO irq
related [2]. There was an attempt to fix this [3] already, but this
doesn't work [4]. Having this, I started to look into it.

I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO
Simplified Specification [6] and the OMAP35x TRM [7] as starting points.

Unfortunately, the Davinci MMC registers and irqs are different
(Davinci has a dedicated SDIO irq). But combining [3] and [5] helps to
get an idea what has to be done.

I think the main issues of [3] were that it doesn't enable IBG for 4
bit mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the
irq bits.

Topics I still open:

- Is it always necessary to deal with IE _and_ ISE register? I'm not
totally clear what the difference between these two 

hrtimer_nanosleep() weirdness...

2009-10-16 Thread Peter Barada
I'm using an hrtimer in my tsc2004 touch driver to sleep between samples
for 7.5mSec.  Here's the essence of the inner loop that grabs samples:

for (;;) {
// Get a point, pass it to input_report_abs...
pen_is_down = tsc2004_get_point(d);

// If pen is up up, then break out
if (!pen_is_down || signal_pending(tsk))
break;

{
struct timespec timeout;
// sleep for 7.5 mSec (giving max 133 touch/sec)
timeout = ns_to_timespec(75 * 100 * 1000);
hrtimer_nanosleep(timeout, NULL, HRTIMER_MODE_REL, 
CLOCK_MONOTONIC);
}
}

What's really strange is when I use ts_test to measure sample rate, I
see:
OMAP-Torpedo# export TSLIB_TSDEVICE=/dev/input/event0
OMAP-Torpedo# export TSLIB_CONSOLEDEVICE=none
OMAP-Torpedo# ts_test
717.804687:176161234
717.813446:176161234
717.822265:176160234
717.993255:178159234
718.002014:179158234
718.188537:180158234
719.015441:181157234
719.165100:181157234
719.360412:182157234
719.369079:182157234
719.438537:182156234
719.555725:182156234
719.564392:182156234
719.751037:180155234
719.768432:179155234
719.777099:178154234
719.946350:174150234
720.000976:175144234
720.141662:184140234
720.336975:189138234
720.490722:195137234
720.499420:198138234
720.858123:198139234
720.922912:198139234
721.126922:198139234
721.135620:198139234
721.144317:198139234
721.152984:198139234
721.161682:198139234
721.313537:198139234
721.438537:198138  0

Which shows over 3.63 seconds 33 samples, or only 9.08 samples/second,
including a max delay of .827 seconds (719.015441 - 718.188537).  

But if I ifup eth0 to bring the networking up (and nothing else is
running), I get:

OMAP-Torpedo# ifup eth0
[sleeping 5s]...net eth0: SMSC911x/921x identified at 0xc8858000, IRQ:
289
eth0: link down
eth0: link up, 100Mbps, full-duplex
udhcpc (v1.15.1) started
Sending discover...
Sending select for 192.168.3.151...
Lease of 192.168.3.151 obtained, lease time 86400
deleting routers
route: SIOCDELRT: No such process
adding dns 192.168.3.1
OMAP-Torpedo# ts_test
735.615905:263140234
735.615905:263140234
735.625152:261141234
735.634277:260141234
735.643463:260141234
735.652648:260142234
735.661865:261142234
735.671081:262141234
735.680267:263141234
735.689453:264140234
735.698669:265139234
735.707885:266139234
735.717102:267138234
735.726318:268138234
735.735534:268138234
735.744751:269137234
735.762725:269137234
735.771942:270137234
735.790344:270136234
735.799560:270136234
735.808746:270136234
735.817962:270136234
735.845611:270136234
735.910217:270136234
735.919403:270136234
735.928588:271136234
735.937866:271136234
735.947082:271136234
735.955871:271136234
735.974334:271136234
735.983551:270136234
736.001220:270136234
736.010467:270136234
736.047302:270136234
736.056488:270136234
736.074951:270137234
736.093383:269137234
736.102600:269137  0

Or 36 samples in 0.486695  seconds - ~74 samples per second with an
average/deviation that is much more acceptable.

This is completely reproducible.

Any ideas why firing up the SMSC911x driver would cause
hrtimer_nanosleep() to be much more predictable?

-- 
Peter Barada pet...@logicpd.com
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread Dirk Behme

John Rigby wrote:

First the disclaimers:
The board is new board that has had hardware mmc/sdio problems before.
 It is based closely on beagle but uses a different package which has
some package specific issues.  We think we have found them all but who
knows.

My kernel is a few months old 2.6.29.


Then you can't apply my patch 1:1. Steve already found that there are 
a lot of differences between recent git head and 2.6.31. A lot of 
omap_hsmmc changes were done since 2.6.31.



Ok, given the above issues, it looks to me like I am getting
interrupted every time  CIRQ is enabled.


Infinite interrupts. This is what I assumed :(


Nor sure if the libertas
driver is not disabling as it should or what.  


I'm not sure if libertas has to do something with this.


So I end up in this
death spiral:

irq handler is called and status indicates CIRQ is pending

mmc_signal_sdio_irq is called which calls omap_hsmmc_enable_sdio_irq
with via mmc_host_ops, en is zero so CIRQ gets disabled

mmc_signal_sdio_irq then wakes up sdio_irq_thread which does its thing
then before going to sleep calls omap_hsmmc_enable_irq with en set to
1 so CIRC gets turned back on


Sounds ok. And thanks for giving the call stack. As mentioned, I did 
only compile check ;)



with CIRC enabled the irq handler gets called and we are back where we started.


The issue then is not acknowledging the interrupt correctly. The TRM 
(spruf98.c) tells us:


-- cut --
Card interrupt Enable
A clear of this bit also clears the corresponding status bit.
During 1-bit mode, if the interrupt routine does not remove the
source of a card interrupt in the SDIO card, the status bit is
reasserted when this bit is set to 1.
-- cut --

The clear card interrupt enable should be done by ~(CIRQ_ENABLE) in

+if (status  CIRQ) {
+   dev_dbg(mmc_dev(host-mmc), SDIO interrupt);
+   OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
+ ~(CIRQ_ENABLE));
+   mmc_signal_sdio_irq(host-mmc);
+   spin_unlock(host-irq_lock);
+   return IRQ_HANDLED;
+}

Anybody sees anything wrong here? Maybe we missed something?

I assume that we are not in 1-bit mode. We should be in 4 bit mode. It 
could be checked by some test code that we are in 4 bit mode and IBG 
is set.


Additionally, what I wonder regarding this, is the davinci driver [1] 
additionally checking for DAT1 level in enable_sdio_irq


1114 if (enable) {
1115 if (!((readl(host-base + DAVINCI_SDIOST0))
1116  SDIOST0_DAT1_HI)) {
1117 writel(SDIOIST_IOINT,
1118 host-base + 
DAVINCI_SDIOIST);

1119 mmc_signal_sdio_irq(host-mmc);
1120 } else {
... enable int
1124 }
1125 } else {
... disable int
1129 }

And it does similar stuff in xfer_done

 873 if (host-mmc-caps  MMC_CAP_SDIO_IRQ) {
 874 if (host-sdio_int  (!((readl(host-base + 
DAVINCI_SDIOST0))

 875  SDIOST0_DAT1_HI))) {
 876 writel(SDIOIST_IOINT, host-base + 
DAVINCI_SDIOIST);

 877 mmc_signal_sdio_irq(host-mmc);
 878 }
 879 }

Most probably there is a reason for doing so?

Best regards

Dirk

[1] 
http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD



Looks like either the libertas driver is not disabling the irq or the
CIRQ irq is somehow getting stuck or I have a hw problem.

One thing I did try was to have the sdio_irq_thread basically ignore
the MMC_CAP_SDIO_IRQ flag except for calling
host-ops-enable_sdio_irq(host, 1) and I changed mmc_signal_sdio_irq
to not reschedule sdio_irq_thread.  In shows that the mere act of
enabling CIRQ does not break anything.  In this mode I get one CIRQ
irq for each time around the sdio_irq_thread loop.

I guess I should try checking the CIRQ bit in the status register
after calling the libertas handler which should clear the irq?


John


On Fri, Oct 16, 2009 at 10:06 AM, Dirk Behme dirk.be...@googlemail.com wrote:

John Rigby wrote:

Dirk,

Thanks for the update.  After looking more closely at your patch I
found that the only thing my attempt was missing was the IBG setting.
I added that to mine with the result that the system hangs on loading
the libertas modules.

On which board are you working? libertas does mean you are working on wifi
connected via SDIO?


The last thing i see is the firmware request
message.

Ok, you see a hang. Below we have a timeout.

I would vote for some interrupt issues. For timeouts I would vote for
missing interrupts, while system hang might be infinite interrupts
(something like this was reported in [1]).

Could you add some debug code in omap_hsmmc_enable_sdio_irq() to trace if
enable/disable is called in the correct order? And in 

Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread John Rigby
cc'ing list after responding only to Dirk.

On Fri, Oct 16, 2009 at 2:37 PM, John Rigby jcri...@gmail.com wrote:
 On Fri, Oct 16, 2009 at 1:55 PM, Dirk Behme dirk.be...@googlemail.com wrote:
 John Rigby wrote:

 First the disclaimers:
 The board is new board that has had hardware mmc/sdio problems before.
  It is based closely on beagle but uses a different package which has
 some package specific issues.  We think we have found them all but who
 knows.

 My kernel is a few months old 2.6.29.

 Then you can't apply my patch 1:1. Steve already found that there are a lot
 of differences between recent git head and 2.6.31. A lot of omap_hsmmc
 changes were done since 2.6.31.

 I applied your patch in spirit:) thus the disclaimer.

 .



 Additionally, what I wonder regarding this, is the davinci driver [1]
 additionally checking for DAT1 level in enable_sdio_irq

 1114         if (enable) {
 1115                 if (!((readl(host-base + DAVINCI_SDIOST0))
 1116                              SDIOST0_DAT1_HI)) {
 1117                         writel(SDIOIST_IOINT,
 1118                                         host-base + DAVINCI_SDIOIST);
 1119                         mmc_signal_sdio_irq(host-mmc);
 1120                 } else {
 ... enable int
 1124                 }
 1125         } else {
 ... disable int
 1129         }

 And it does similar stuff in xfer_done

  873         if (host-mmc-caps  MMC_CAP_SDIO_IRQ) {
  874                 if (host-sdio_int  (!((readl(host-base +
 DAVINCI_SDIOST0))
  875                                          SDIOST0_DAT1_HI))) {
  876                         writel(SDIOIST_IOINT, host-base +
 DAVINCI_SDIOIST);
  877                         mmc_signal_sdio_irq(host-mmc);
  878                 }
  879         }

 Most probably there is a reason for doing so?

 This looks to me like it is detecting the irq where the hw may not
 otherwise do so.  It is basically saying if the line is low signal an
 sdio irq.  Sort of the opposite of the problem we have.




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


RE: [PATCH] omapfb: Wrong test on unsigned?

2009-10-16 Thread Aguirre Rodriguez, Sergio Alberto
 

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Roel Kluin
 Sent: Friday, October 16, 2009 1:24 PM
 To: Imre Deak; linux-fbdev-de...@lists.sourceforge.net; 
 linux-omap@vger.kernel.org; Andrew Morton
 Subject: [PATCH] omapfb: Wrong test on unsigned?
 
 Only if the test is signed negative values can be spotted.
 
 Signed-off-by: Roel Kluin roel.kl...@gmail.com
 ---
 Is this correct? please review.
 
 diff --git a/drivers/video/omap/omapfb_main.c 
 b/drivers/video/omap/omapfb_main.c
 index 0d0c8c8..cc7dd93 100644
 --- a/drivers/video/omap/omapfb_main.c
 +++ b/drivers/video/omap/omapfb_main.c
 @@ -286,7 +286,7 @@ static int _setcolreg(struct fb_info 
 *info, u_int regno, u_int red, u_int green,
   if (r != 0)
   break;
  
 - if (regno  0) {
 + if ((int)regno  0) {

Hmm...

Isn't regno unsigned integer from the start?

2 things here:

- regno will never be negative.
- Casting won't make a difference in the meaning., it'll make a negative only 
when:

regno  ((2^32) / 2)

Which doesn't make any sense IMHO.

Isn't it?

Regards,
Sergio
   r = -EINVAL;
   break;
   }
 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-omap 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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] CPUidle: always return with interrupts enabled

2009-10-16 Thread Andrew Morton
On Fri, 16 Oct 2009 17:25:04 +0100
Martin Michlmayr t...@cyrius.com wrote:

 * Andrew Morton a...@linux-foundation.org [2009-10-06 13:34]:
  Rigor mortis is setting in on this one.
 
  The patch seems correct to me.
 
 Can someone put this patch in now?  The problem has also been reported
 on Marvell's Kirkwood platform (ARM) by a number of users and the
 patch fixes it.
 
 Tested-by: Martin Michlmayr t...@cyrius.com

I have it in my for-2.6.32 queue.

 Please CC stable when you commit the patch since it also needs to go
 in for 2.6.31.

hm, I didn't know that.  So noted, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread Madhusudhan


 -Original Message-
 From: Dirk Behme [mailto:dirk.be...@googlemail.com]
 Sent: Friday, October 16, 2009 2:28 PM
 To: Madhusudhan Chikkature
 Cc: linux-...@vger.kernel.org; John Rigby; linux-omap@vger.kernel.org;
 Steve Sakoman
 Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
 
 Madhusudhan Chikkature wrote:
  Hi Dirk,
 
  I am inlining the patch so that it helps review.
 ...
  @@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
  break;
  case MMC_BUS_WIDTH_4:
  OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
  -   OMAP_HSMMC_WRITE(host-base, HCTL,
  -   OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
  +   if (mmc_card_sdio(host-mmc-card)) {
 
  I wish it could be moved to enable_sdio_irq so that we can avoid
 inclusion of
  card.h and checking the type of card in the host controller driver.
 
 Yes, this would be the real clean way. But ...
 
  But the
  dependancy on 4-bit seems to be a problem here.
 
 ... most probably we have to find a workaround until (if ever?) above
 clean implementation is available.
 
 What we need is after SDIO mode and bus width is known, and before the
 first interrupt comes, to set IBG.
 
  On the problems being discussed on testing is the interrupt source
 geting
  cleared at the SDIO card level upon genaration of the CIRQ? If not it
 remains
  asserted.
 
 Yes, this seems to be exactly the problem John reports in his follow
 up mail.
 
 Any hint how to clear SDIO interrupt?
 
On the controller side I guess it is cleared when you pass disable in the
enable_sdio_irq fn. This happens when you call mmc_signal_sdio_irq.

I am not too sure about how it gets disabled from the card side. I see that
SDIO core has a function sdio_release_irq which is used by the sdio uart
driver. The usage of this could give a clue.

Regards,
Madhu

 Many thanks
 
 Dirk
 
  +   OMAP_HSMMC_WRITE(host-base, HCTL,
  +OMAP_HSMMC_READ(host-base, HCTL)
  +| IBG | FOUR_BIT);
  +   } else {
  +   OMAP_HSMMC_WRITE(host-base, HCTL,
  +OMAP_HSMMC_READ(host-base, HCTL)
  +| FOUR_BIT);
  +   }
  break;
  case MMC_BUS_WIDTH_1:
  OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
  @@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
  return 0;
   }
 
  +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
 enable)
  +{
  +   struct omap_hsmmc_host *host = mmc_priv(mmc);
  +   u32 ie, ise;
  +
  +   ise = OMAP_HSMMC_READ(host-base, ISE);
  +   ie  = OMAP_HSMMC_READ(host-base, IE);
  +
  +   if (enable) {
  +   OMAP_HSMMC_WRITE(host-base, ISE, ise | CIRQ_ENABLE);
  +   OMAP_HSMMC_WRITE(host-base, IE,  ie  | CIRQ_ENABLE);
  +   } else {
  +   OMAP_HSMMC_WRITE(host-base, ISE, ise  ~CIRQ_ENABLE);
  +   OMAP_HSMMC_WRITE(host-base, IE,  ie   ~CIRQ_ENABLE);
  +   }
  +
  +}
  +
   static const struct mmc_host_ops omap_hsmmc_ops = {
  .enable = omap_hsmmc_enable_fclk,
  .disable = omap_hsmmc_disable_fclk,
  @@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hs
  .set_ios = omap_hsmmc_set_ios,
  .get_cd = omap_hsmmc_get_cd,
  .get_ro = omap_hsmmc_get_ro,
  -   /* NYET -- enable_sdio_irq */
  +   .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
   };
 
   static const struct mmc_host_ops omap_hsmmc_ps_ops = {
  @@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hs
  .set_ios = omap_hsmmc_set_ios,
  .get_cd = omap_hsmmc_get_cd,
  .get_ro = omap_hsmmc_get_ro,
  -   /* NYET -- enable_sdio_irq */
  +   .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
   };
 
   #ifdef CONFIG_DEBUG_FS
  @@ -1734,7 +1772,7 @@ static int __init omap_hsmmc_probe(struc
  mmc-max_seg_size = mmc-max_req_size;
 
  mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
  -MMC_CAP_WAIT_WHILE_BUSY;
  +MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_SDIO_IRQ;
 
  if (mmc_slot(host).wires = 8)
  mmc-caps |= MMC_CAP_8_BIT_DATA;
 
 
 
 
 
  John Rigby wrote:
  I have seen several discussions about lack of sdio irq support in the
  hsmmc driver but no patches.  Has anyone on this list implemented this
  and/or can anyone point me to patches?
  What a coincidence ;)
 
  I'm currently working on this. See attachment what I currently have.
  It is compile tested only against recent omap linux head. I don't have
  a board using SDIO at the moment, so no real testing possible :(
 
  Some background, maybe it helps people to step in:
 
  Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by
  MMC port 2 in 4 bit configuration [1]. The wifi performance is quite
  bad (~100kB/s). There is some rumor that this might be SDIO irq
  related [2]. There was an attempt to fix this [3] already, but this
  doesn't work [4]. Having 

Re: MMC_CAP_SDIO_IRQ for omap 3430

2009-10-16 Thread John Rigby
It appears to never get cleared in the status register.

I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.

It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it.  I'll try that.

John

On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:


 -Original Message-
 From: Dirk Behme [mailto:dirk.be...@googlemail.com]
 Sent: Friday, October 16, 2009 2:28 PM
 To: Madhusudhan Chikkature
 Cc: linux-...@vger.kernel.org; John Rigby; linux-omap@vger.kernel.org;
 Steve Sakoman
 Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430

 Madhusudhan Chikkature wrote:
  Hi Dirk,
 
  I am inlining the patch so that it helps review.
 ...
  @@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
              break;
      case MMC_BUS_WIDTH_4:
              OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
  -           OMAP_HSMMC_WRITE(host-base, HCTL,
  -                   OMAP_HSMMC_READ(host-base, HCTL) | FOUR_BIT);
  +           if (mmc_card_sdio(host-mmc-card)) {
 
  I wish it could be moved to enable_sdio_irq so that we can avoid
 inclusion of
  card.h and checking the type of card in the host controller driver.

 Yes, this would be the real clean way. But ...

  But the
  dependancy on 4-bit seems to be a problem here.

 ... most probably we have to find a workaround until (if ever?) above
 clean implementation is available.

 What we need is after SDIO mode and bus width is known, and before the
 first interrupt comes, to set IBG.

  On the problems being discussed on testing is the interrupt source
 geting
  cleared at the SDIO card level upon genaration of the CIRQ? If not it
 remains
  asserted.

 Yes, this seems to be exactly the problem John reports in his follow
 up mail.

 Any hint how to clear SDIO interrupt?

 On the controller side I guess it is cleared when you pass disable in the
 enable_sdio_irq fn. This happens when you call mmc_signal_sdio_irq.

 I am not too sure about how it gets disabled from the card side. I see that
 SDIO core has a function sdio_release_irq which is used by the sdio uart
 driver. The usage of this could give a clue.

 Regards,
 Madhu

 Many thanks

 Dirk

  +                   OMAP_HSMMC_WRITE(host-base, HCTL,
  +                                    OMAP_HSMMC_READ(host-base, HCTL)
  +                                    | IBG | FOUR_BIT);
  +           } else {
  +                   OMAP_HSMMC_WRITE(host-base, HCTL,
  +                                    OMAP_HSMMC_READ(host-base, HCTL)
  +                                    | FOUR_BIT);
  +           }
              break;
      case MMC_BUS_WIDTH_1:
              OMAP_HSMMC_WRITE(host-base, CON, con  ~DW8);
  @@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
      return 0;
   }
 
  +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
 enable)
  +{
  +   struct omap_hsmmc_host *host = mmc_priv(mmc);
  +   u32 ie, ise;
  +
  +   ise = OMAP_HSMMC_READ(host-base, ISE);
  +   ie  = OMAP_HSMMC_READ(host-base, IE);
  +
  +   if (enable) {
  +           OMAP_HSMMC_WRITE(host-base, ISE, ise | CIRQ_ENABLE);
  +           OMAP_HSMMC_WRITE(host-base, IE,  ie  | CIRQ_ENABLE);
  +   } else {
  +           OMAP_HSMMC_WRITE(host-base, ISE, ise  ~CIRQ_ENABLE);
  +           OMAP_HSMMC_WRITE(host-base, IE,  ie   ~CIRQ_ENABLE);
  +   }
  +
  +}
  +
   static const struct mmc_host_ops omap_hsmmc_ops = {
      .enable = omap_hsmmc_enable_fclk,
      .disable = omap_hsmmc_disable_fclk,
  @@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hs
      .set_ios = omap_hsmmc_set_ios,
      .get_cd = omap_hsmmc_get_cd,
      .get_ro = omap_hsmmc_get_ro,
  -   /* NYET -- enable_sdio_irq */
  +   .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
   };
 
   static const struct mmc_host_ops omap_hsmmc_ps_ops = {
  @@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hs
      .set_ios = omap_hsmmc_set_ios,
      .get_cd = omap_hsmmc_get_cd,
      .get_ro = omap_hsmmc_get_ro,
  -   /* NYET -- enable_sdio_irq */
  +   .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
   };
 
   #ifdef CONFIG_DEBUG_FS
  @@ -1734,7 +1772,7 @@ static int __init omap_hsmmc_probe(struc
      mmc-max_seg_size = mmc-max_req_size;
 
      mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
  -                MMC_CAP_WAIT_WHILE_BUSY;
  +                MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_SDIO_IRQ;
 
      if (mmc_slot(host).wires = 8)
              mmc-caps |= MMC_CAP_8_BIT_DATA;
 
 
 
 
 
  John Rigby wrote:
  I have seen several discussions about lack of sdio irq support in the
  hsmmc driver but no patches.  Has anyone on this list implemented this
  and/or can anyone point me to patches?
  What a coincidence ;)
 
  I'm currently working on this. See attachment what I currently have.
  It is compile tested only against recent omap linux head. I 

[PATCH 00/14] Use ioremap for omap, split OMAP2_IO_ADDRESS for more space

2009-10-16 Thread Tony Lindgren
Hi all,

This series intended for the merge window after 2.6.32 removes
OMAP2_IO_ADDRESS to reclaim more address space.

OMAP2_IO_ADDRESS is replaced with ioremap where possible, and
the remaining usage is split into OMAP2_L3_IO_ADDRESS and
OMAP2_L4_IO_ADDRESS.

Some usage still remains in *.S files and headers. Eventually we should
be able to remove the usage and only define it locally.

Note that after this series omap4 no longer uses these macros.
Other omaps will need more work still.

Regards,

Tony

---

Santosh Shilimkar (5):
  omap: Add OMAP4 L3 and L4 peripherals.
  omap: Fix DEBUG_LL UART io address
  omap: Move SRAM map to claim more io space
  omap: Remap L3, L4 to get more kernel io address space
  omap: Split OMAP2_IO_ADDRESS to L3 and L4

Tony Lindgren (9):
  omap: Use ioremap in dispc.c
  omap: Use ioremap for omap4 L4 code
  omap: Use getnstimeofday for omap_device
  omap: Use ioremap in omap_hwmod.c
  omap: Use ioremap in gpio.c
  omap: Use ioremap in dmtimer.c
  omap: Use ioremap in dma.c
  omap: Use ioremap in irq.c
  omap: Change low-level serial init to use ioremap


 arch/arm/mach-omap1/serial.c  |   11 +
 arch/arm/mach-omap2/board-2430sdp.c   |2 
 arch/arm/mach-omap2/board-3430sdp.c   |2 
 arch/arm/mach-omap2/board-4430sdp.c   |   15 +-
 arch/arm/mach-omap2/board-apollon.c   |2 
 arch/arm/mach-omap2/board-generic.c   |2 
 arch/arm/mach-omap2/board-h4.c|2 
 arch/arm/mach-omap2/board-ldp.c   |2 
 arch/arm/mach-omap2/board-n8x0.c  |6 -
 arch/arm/mach-omap2/board-omap3beagle.c   |2 
 arch/arm/mach-omap2/board-omap3evm.c  |2 
 arch/arm/mach-omap2/board-omap3pandora.c  |2 
 arch/arm/mach-omap2/board-overo.c |2 
 arch/arm/mach-omap2/board-rx51.c  |2 
 arch/arm/mach-omap2/board-zoom2.c |2 
 arch/arm/mach-omap2/cm.h  |6 -
 arch/arm/mach-omap2/io.c  |   18 ++
 arch/arm/mach-omap2/irq.c |   12 +
 arch/arm/mach-omap2/omap-smp.c|   28 ++-
 arch/arm/mach-omap2/omap_hwmod.c  |   18 +-
 arch/arm/mach-omap2/pm-debug.c|3 
 arch/arm/mach-omap2/prm.h |6 -
 arch/arm/mach-omap2/sdrc.h|9 +
 arch/arm/mach-omap2/serial.c  |   15 +-
 arch/arm/mach-omap2/sram242x.S|4 
 arch/arm/mach-omap2/sram243x.S|4 
 arch/arm/mach-omap2/timer-gp.c|3 
 arch/arm/plat-omap/common.c   |   44 ++---
 arch/arm/plat-omap/dma.c  |   34 +++-
 arch/arm/plat-omap/dmtimer.c  |   16 +-
 arch/arm/plat-omap/gpio.c |  222 ++---
 arch/arm/plat-omap/include/mach/control.h |   15 +-
 arch/arm/plat-omap/include/mach/debug-macro.S |4 
 arch/arm/plat-omap/include/mach/entry-macro.S |6 -
 arch/arm/plat-omap/include/mach/io.h  |  124 ++
 arch/arm/plat-omap/include/mach/omap44xx.h|8 -
 arch/arm/plat-omap/include/mach/sdrc.h|6 -
 arch/arm/plat-omap/include/mach/vmalloc.h |2 
 arch/arm/plat-omap/io.c   |   20 ++
 arch/arm/plat-omap/omap_device.c  |   50 ++
 arch/arm/plat-omap/sram.c |   24 +--
 drivers/video/omap/dispc.c|   20 ++
 42 files changed, 479 insertions(+), 298 deletions(-)

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


[PATCH 02/14] omap: Use ioremap in irq.c

2009-10-16 Thread Tony Lindgren
Use ioremap in irq.c

Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/irq.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index b828638..1db121f 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -178,12 +178,20 @@ void __init omap_init_irq(void)
int i;
 
for (i = 0; i  ARRAY_SIZE(irq_banks); i++) {
+   unsigned long base;
struct omap_irq_bank *bank = irq_banks + i;
 
if (cpu_is_omap24xx())
-   bank-base_reg = OMAP2_IO_ADDRESS(OMAP24XX_IC_BASE);
+   base = OMAP24XX_IC_BASE;
else if (cpu_is_omap34xx())
-   bank-base_reg = OMAP2_IO_ADDRESS(OMAP34XX_IC_BASE);
+   base = OMAP34XX_IC_BASE;
+
+   /* Static mapping, never released */
+   bank-base_reg = ioremap(base, SZ_4K);
+   if (!bank-base_reg) {
+   printk(KERN_ERR Could not ioremap irq bank%i\n, i);
+   continue;
+   }
 
omap_irq_bank_init_one(bank);
 

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


[PATCH 03/14] omap: Use ioremap in dma.c

2009-10-16 Thread Tony Lindgren
Use ioremap in dma.c

Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/dma.c |   34 --
 1 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 0eb676d..034686d 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2347,40 +2347,46 @@ EXPORT_SYMBOL(omap_stop_lcd_dma);
 
 static int __init omap_init_dma(void)
 {
+   unsigned long base;
int ch, r;
 
if (cpu_class_is_omap1()) {
-   omap_dma_base = OMAP1_IO_ADDRESS(OMAP1_DMA_BASE);
+   base = OMAP1_DMA_BASE;
dma_lch_count = OMAP1_LOGICAL_DMA_CH_COUNT;
} else if (cpu_is_omap24xx()) {
-   omap_dma_base = OMAP2_IO_ADDRESS(OMAP24XX_DMA4_BASE);
+   base = OMAP24XX_DMA4_BASE;
dma_lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT;
} else if (cpu_is_omap34xx()) {
-   omap_dma_base = OMAP2_IO_ADDRESS(OMAP34XX_DMA4_BASE);
+   base = OMAP34XX_DMA4_BASE;
dma_lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT;
} else if (cpu_is_omap44xx()) {
-   omap_dma_base = OMAP2_IO_ADDRESS(OMAP44XX_DMA4_BASE);
+   base = OMAP44XX_DMA4_BASE;
dma_lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT;
} else {
pr_err(DMA init failed for unsupported omap\n);
return -ENODEV;
}
 
+   omap_dma_base = ioremap(base, SZ_4K);
+   BUG_ON(!omap_dma_base);
+
if (cpu_class_is_omap2()  omap_dma_reserve_channels
 (omap_dma_reserve_channels = dma_lch_count))
dma_lch_count = omap_dma_reserve_channels;
 
dma_chan = kzalloc(sizeof(struct omap_dma_lch) * dma_lch_count,
GFP_KERNEL);
-   if (!dma_chan)
-   return -ENOMEM;
+   if (!dma_chan) {
+   r = -ENOMEM;
+   goto out_unmap;
+   }
 
if (cpu_class_is_omap2()) {
dma_linked_lch = kzalloc(sizeof(struct dma_link_info) *
dma_lch_count, GFP_KERNEL);
if (!dma_linked_lch) {
-   kfree(dma_chan);
-   return -ENOMEM;
+   r = -ENOMEM;
+   goto out_free;
}
}
 
@@ -2454,7 +2460,7 @@ static int __init omap_init_dma(void)
for (i = 0; i  ch; i++)
free_irq(omap1_dma_irq[i],
 (void *) (i + 1));
-   return r;
+   goto out_free;
}
}
}
@@ -2496,11 +2502,19 @@ static int __init omap_init_dma(void)
   (error %d)\n, r);
for (i = 0; i  dma_chan_count; i++)
free_irq(omap1_dma_irq[i], (void *) (i + 1));
-   return r;
+   goto out_free;
}
}
 
return 0;
+
+out_free:
+   kfree(dma_chan);
+
+out_unmap:
+   iounmap(omap_dma_base);
+
+   return r;
 }
 
 arch_initcall(omap_init_dma);

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


[PATCH 04/14] omap: Use ioremap in dmtimer.c

2009-10-16 Thread Tony Lindgren
Use ioremap in dmtimer.c

Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/dmtimer.c |   16 +---
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d325b54..e4e848e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -742,16 +742,17 @@ EXPORT_SYMBOL_GPL(omap_dm_timers_active);
 int __init omap_dm_timer_init(void)
 {
struct omap_dm_timer *timer;
-   int i;
+   int i, map_size = SZ_8K;/* Module 4KB + L4 4KB except on omap1 
*/
 
if (!(cpu_is_omap16xx() || cpu_class_is_omap2()))
return -ENODEV;
 
spin_lock_init(dm_timer_lock);
 
-   if (cpu_class_is_omap1())
+   if (cpu_class_is_omap1()) {
dm_timers = omap1_dm_timers;
-   else if (cpu_is_omap24xx()) {
+   map_size = SZ_2K;
+   } else if (cpu_is_omap24xx()) {
dm_timers = omap2_dm_timers;
dm_source_names = omap2_dm_source_names;
dm_source_clocks = omap2_dm_source_clocks;
@@ -774,10 +775,11 @@ int __init omap_dm_timer_init(void)
 
for (i = 0; i  dm_timer_count; i++) {
timer = dm_timers[i];
-   if (cpu_class_is_omap1())
-   timer-io_base = OMAP1_IO_ADDRESS(timer-phys_base);
-   else
-   timer-io_base = OMAP2_IO_ADDRESS(timer-phys_base);
+
+   /* Static mapping, never released */
+   timer-io_base = ioremap(timer-phys_base, map_size);
+   BUG_ON(!timer-io_base);
+
 #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
defined(CONFIG_ARCH_OMAP4)
if (cpu_class_is_omap2()) {

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


[PATCH 05/14] omap: Use ioremap in gpio.c

2009-10-16 Thread Tony Lindgren
Use ioremap in gpio.c

Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/gpio.c |  222 ++---
 1 files changed, 128 insertions(+), 94 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index b0c7361..30b93ff 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -45,10 +45,10 @@
 /*
  * OMAP1610 specific GPIO registers
  */
-#define OMAP1610_GPIO1_BASEOMAP1_IO_ADDRESS(0xfffbe400)
-#define OMAP1610_GPIO2_BASEOMAP1_IO_ADDRESS(0xfffbec00)
-#define OMAP1610_GPIO3_BASEOMAP1_IO_ADDRESS(0xfffbb400)
-#define OMAP1610_GPIO4_BASEOMAP1_IO_ADDRESS(0xfffbbc00)
+#define OMAP1610_GPIO1_BASE0xfffbe400
+#define OMAP1610_GPIO2_BASE0xfffbec00
+#define OMAP1610_GPIO3_BASE0xfffbb400
+#define OMAP1610_GPIO4_BASE0xfffbbc00
 #define OMAP1610_GPIO_REVISION 0x
 #define OMAP1610_GPIO_SYSCONFIG0x0010
 #define OMAP1610_GPIO_SYSSTATUS0x0014
@@ -70,12 +70,12 @@
 /*
  * OMAP7XX specific GPIO registers
  */
-#define OMAP7XX_GPIO1_BASE OMAP1_IO_ADDRESS(0xfffbc000)
-#define OMAP7XX_GPIO2_BASE OMAP1_IO_ADDRESS(0xfffbc800)
-#define OMAP7XX_GPIO3_BASE OMAP1_IO_ADDRESS(0xfffbd000)
-#define OMAP7XX_GPIO4_BASE OMAP1_IO_ADDRESS(0xfffbd800)
-#define OMAP7XX_GPIO5_BASE OMAP1_IO_ADDRESS(0xfffbe000)
-#define OMAP7XX_GPIO6_BASE OMAP1_IO_ADDRESS(0xfffbe800)
+#define OMAP7XX_GPIO1_BASE 0xfffbc000
+#define OMAP7XX_GPIO2_BASE 0xfffbc800
+#define OMAP7XX_GPIO3_BASE 0xfffbd000
+#define OMAP7XX_GPIO4_BASE 0xfffbd800
+#define OMAP7XX_GPIO5_BASE 0xfffbe000
+#define OMAP7XX_GPIO6_BASE 0xfffbe800
 #define OMAP7XX_GPIO_DATA_INPUT0x00
 #define OMAP7XX_GPIO_DATA_OUTPUT   0x04
 #define OMAP7XX_GPIO_DIR_CONTROL   0x08
@@ -83,21 +83,21 @@
 #define OMAP7XX_GPIO_INT_MASK  0x10
 #define OMAP7XX_GPIO_INT_STATUS0x14
 
-#define OMAP1_MPUIO_VBASE  OMAP1_IO_ADDRESS(OMAP1_MPUIO_BASE)
+#define OMAP1_MPUIO_VBASE  OMAP1_MPUIO_BASE
 
 /*
  * omap24xx specific GPIO registers
  */
-#define OMAP242X_GPIO1_BASEOMAP2_IO_ADDRESS(0x48018000)
-#define OMAP242X_GPIO2_BASEOMAP2_IO_ADDRESS(0x4801a000)
-#define OMAP242X_GPIO3_BASEOMAP2_IO_ADDRESS(0x4801c000)
-#define OMAP242X_GPIO4_BASEOMAP2_IO_ADDRESS(0x4801e000)
+#define OMAP242X_GPIO1_BASE0x48018000
+#define OMAP242X_GPIO2_BASE0x4801a000
+#define OMAP242X_GPIO3_BASE0x4801c000
+#define OMAP242X_GPIO4_BASE0x4801e000
 
-#define OMAP243X_GPIO1_BASEOMAP2_IO_ADDRESS(0x4900C000)
-#define OMAP243X_GPIO2_BASEOMAP2_IO_ADDRESS(0x4900E000)
-#define OMAP243X_GPIO3_BASEOMAP2_IO_ADDRESS(0x4901)
-#define OMAP243X_GPIO4_BASEOMAP2_IO_ADDRESS(0x49012000)
-#define OMAP243X_GPIO5_BASEOMAP2_IO_ADDRESS(0x480B6000)
+#define OMAP243X_GPIO1_BASE0x4900C000
+#define OMAP243X_GPIO2_BASE0x4900E000
+#define OMAP243X_GPIO3_BASE0x4901
+#define OMAP243X_GPIO4_BASE0x49012000
+#define OMAP243X_GPIO5_BASE0x480B6000
 
 #define OMAP24XX_GPIO_REVISION 0x
 #define OMAP24XX_GPIO_SYSCONFIG0x0010
@@ -154,24 +154,25 @@
  * omap34xx specific GPIO registers
  */
 
-#define OMAP34XX_GPIO1_BASEOMAP2_IO_ADDRESS(0x4831)
-#define OMAP34XX_GPIO2_BASEOMAP2_IO_ADDRESS(0x4905)
-#define OMAP34XX_GPIO3_BASEOMAP2_IO_ADDRESS(0x49052000)
-#define OMAP34XX_GPIO4_BASEOMAP2_IO_ADDRESS(0x49054000)
-#define OMAP34XX_GPIO5_BASEOMAP2_IO_ADDRESS(0x49056000)
-#define OMAP34XX_GPIO6_BASEOMAP2_IO_ADDRESS(0x49058000)
+#define OMAP34XX_GPIO1_BASE0x4831
+#define OMAP34XX_GPIO2_BASE0x4905
+#define OMAP34XX_GPIO3_BASE0x49052000
+#define OMAP34XX_GPIO4_BASE0x49054000
+#define OMAP34XX_GPIO5_BASE0x49056000
+#define OMAP34XX_GPIO6_BASE0x49058000
 
 /*
  * OMAP44XX  specific GPIO registers
  */
-#define OMAP44XX_GPIO1_BASE OMAP2_IO_ADDRESS(0x4a31)
-#define OMAP44XX_GPIO2_BASE OMAP2_IO_ADDRESS(0x48055000)
-#define OMAP44XX_GPIO3_BASE OMAP2_IO_ADDRESS(0x48057000)
-#define OMAP44XX_GPIO4_BASE OMAP2_IO_ADDRESS(0x48059000)
-#define OMAP44XX_GPIO5_BASE OMAP2_IO_ADDRESS(0x4805B000)
-#define OMAP44XX_GPIO6_BASE OMAP2_IO_ADDRESS(0x4805D000)
+#define OMAP44XX_GPIO1_BASE 0x4a31
+#define OMAP44XX_GPIO2_BASE 0x48055000
+#define OMAP44XX_GPIO3_BASE 0x48057000
+#define OMAP44XX_GPIO4_BASE 0x48059000
+#define OMAP44XX_GPIO5_BASE 

[PATCH 06/14] omap: Use ioremap in omap_hwmod.c

2009-10-16 Thread Tony Lindgren
Use ioremap in omap_hwmod.c

Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/omap_hwmod.c |   18 --
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d2e0f1c..8ac8798 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -496,6 +496,7 @@ static void __iomem *_find_mpu_rt_base(struct omap_hwmod 
*oh, u8 index)
struct omap_hwmod_addr_space *mem;
int i;
int found = 0;
+   void __iomem *va_start;
 
if (!oh || oh-slaves_cnt == 0)
return NULL;
@@ -509,16 +510,20 @@ static void __iomem *_find_mpu_rt_base(struct omap_hwmod 
*oh, u8 index)
}
}
 
-   /* XXX use ioremap() instead? */
-
-   if (found)
+   if (found) {
+   va_start = ioremap(mem-pa_start, mem-pa_end - mem-pa_start);
+   if (!va_start) {
+   pr_err(omap_hwmod: %s: Could not ioremap\n, oh-name);
+   return NULL;
+   }
pr_debug(omap_hwmod: %s: MPU register target at va %p\n,
-oh-name, OMAP2_IO_ADDRESS(mem-pa_start));
-   else
+oh-name, va_start);
+   } else {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
 oh-name);
+   }
 
-   return (found) ? OMAP2_IO_ADDRESS(mem-pa_start) : NULL;
+   return (found) ? va_start : NULL;
 }
 
 /**
@@ -1148,6 +1153,7 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: unregistering\n, oh-name);
 
mutex_lock(omap_hwmod_mutex);
+   iounmap(oh-_rt_va);
list_del(oh-node);
mutex_unlock(omap_hwmod_mutex);
 

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


[PATCH 07/14] omap: Use getnstimeofday for omap_device

2009-10-16 Thread Tony Lindgren
Use getnstimeofday for omap_device

Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/omap_device.c |   50 ++
 1 files changed, 19 insertions(+), 31 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 2c409fc..12513f4 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -103,21 +103,6 @@
 /* Private functions */
 
 /**
- * _read_32ksynct - read the OMAP 32K sync timer
- *
- * Returns the current value of the 32KiHz synchronization counter.
- * XXX this should be generalized to simply read the system clocksource.
- * XXX this should be moved to a separate synctimer32k.c file
- */
-static u32 _read_32ksynct(void)
-{
-   if (!cpu_class_is_omap2())
-   BUG();
-
-   return __raw_readl(OMAP2_IO_ADDRESS(OMAP_32KSYNCT_BASE + 0x010));
-}
-
-/**
  * _omap_device_activate - increase device readiness
  * @od: struct omap_device *
  * @ignore_lat: increase to latency target (0) or full readiness (1)?
@@ -133,13 +118,13 @@ static u32 _read_32ksynct(void)
  */
 static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
 {
-   u32 a, b;
+   struct timespec a, b, c;
 
pr_debug(omap_device: %s: activating\n, od-pdev.name);
 
while (od-pm_lat_level  0) {
struct omap_device_pm_latency *odpl;
-   int act_lat = 0;
+   unsigned long long act_lat = 0;
 
od-pm_lat_level--;
 
@@ -149,20 +134,22 @@ static int _omap_device_activate(struct omap_device *od, 
u8 ignore_lat)
(od-dev_wakeup_lat = od-_dev_wakeup_lat_limit))
break;
 
-   a = _read_32ksynct();
+   getnstimeofday(a);
 
/* XXX check return code */
odpl-activate_func(od);
 
-   b = _read_32ksynct();
+   getnstimeofday(b);
 
-   act_lat = (b - a)  15; /* 32KiHz cycles to microseconds */
+   c = timespec_sub(b, a);
+   act_lat = timespec_to_ns(c) * NSEC_PER_USEC;
 
pr_debug(omap_device: %s: pm_lat %d: activate: elapsed time 
-%d usec\n, od-pdev.name, od-pm_lat_level, act_lat);
+%llu usec\n, od-pdev.name, od-pm_lat_level,
+act_lat);
 
WARN(act_lat  odpl-activate_lat, omap_device: %s.%d: 
-activate step %d took longer than expected (%d  %d)\n,
+activate step %d took longer than expected (%llu  %d)\n,
 od-pdev.name, od-pdev.id, od-pm_lat_level,
 act_lat, odpl-activate_lat);
 
@@ -188,13 +175,13 @@ static int _omap_device_activate(struct omap_device *od, 
u8 ignore_lat)
  */
 static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
 {
-   u32 a, b;
+   struct timespec a, b, c;
 
pr_debug(omap_device: %s: deactivating\n, od-pdev.name);
 
while (od-pm_lat_level  od-pm_lats_cnt) {
struct omap_device_pm_latency *odpl;
-   int deact_lat = 0;
+   unsigned long long deact_lat = 0;
 
odpl = od-pm_lats + od-pm_lat_level;
 
@@ -203,23 +190,24 @@ static int _omap_device_deactivate(struct omap_device 
*od, u8 ignore_lat)
 od-_dev_wakeup_lat_limit))
break;
 
-   a = _read_32ksynct();
+   getnstimeofday(a);
 
/* XXX check return code */
odpl-deactivate_func(od);
 
-   b = _read_32ksynct();
+   getnstimeofday(b);
 
-   deact_lat = (b - a)  15; /* 32KiHz cycles to microseconds */
+   c = timespec_sub(b, a);
+   deact_lat = timespec_to_ns(c) * NSEC_PER_USEC;
 
pr_debug(omap_device: %s: pm_lat %d: deactivate: elapsed time 
-%d usec\n, od-pdev.name, od-pm_lat_level,
+%llu usec\n, od-pdev.name, od-pm_lat_level,
 deact_lat);
 
WARN(deact_lat  odpl-deactivate_lat, omap_device: %s.%d: 
-deactivate step %d took longer than expected (%d  %d)\n,
-od-pdev.name, od-pdev.id, od-pm_lat_level,
-deact_lat, odpl-deactivate_lat);
+deactivate step %d took longer than expected 
+(%llu  %d)\n, od-pdev.name, od-pdev.id,
+od-pm_lat_level, deact_lat, odpl-deactivate_lat);
 
od-dev_wakeup_lat += odpl-activate_lat;
 

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


[PATCH 08/14] omap: Use ioremap for omap4 L4 code

2009-10-16 Thread Tony Lindgren
Use ioremap for omap4 L4 code

Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-4430sdp.c   |   13 ++--
 arch/arm/mach-omap2/omap-smp.c|   28 -
 arch/arm/mach-omap2/timer-gp.c|3 ++-
 arch/arm/plat-omap/include/mach/entry-macro.S |2 ++
 arch/arm/plat-omap/include/mach/omap44xx.h|5 
 5 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index eb37c40..2a7b901 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -52,8 +52,17 @@ static struct omap_board_config_kernel sdp4430_config[] 
__initdata = {
 
 static void __init gic_init_irq(void)
 {
-   gic_dist_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_DIST_BASE), 29);
-   gic_cpu_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE));
+   void __iomem *base;
+
+   /* Static mapping, never released */
+   base = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
+   BUG_ON(!base);
+   gic_dist_init(0, base, 29);
+
+   /* Static mapping, never released */
+   base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_256);
+   BUG_ON(!base);
+   gic_cpu_init(0, OMAP44XX_GIC_CPU_BASE);
 }
 
 static void __init omap_4430sdp_init_irq(void)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 48ee295..a1b618c 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -26,11 +26,11 @@
 #include mach/hardware.h
 
 /* Registers used for communicating startup information */
-#define OMAP4_AUXCOREBOOT_REG0 (OMAP44XX_VA_WKUPGEN_BASE + 0x800)
-#define OMAP4_AUXCOREBOOT_REG1 (OMAP44XX_VA_WKUPGEN_BASE + 0x804)
+static void __iomem *omap4_auxcoreboot_reg0;
+static void __iomem *omap4_auxcoreboot_reg1;
 
 /* SCU base address */
-static void __iomem *scu_base = OMAP44XX_VA_SCU_BASE;
+static void __iomem *scu_base;
 
 /*
  * Use SCU config register to count number of cores
@@ -46,6 +46,8 @@ static DEFINE_SPINLOCK(boot_lock);
 
 void __cpuinit platform_secondary_init(unsigned int cpu)
 {
+   void __iomem *gic_cpu_base;
+
trace_hardirqs_off();
 
/*
@@ -54,7 +56,10 @@ void __cpuinit platform_secondary_init(unsigned int cpu)
 * for us: do so
 */
 
-   gic_cpu_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE));
+   /* Static mapping, never released */
+   gic_cpu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_256);
+   BUG_ON(!gic_cpu_base);
+   gic_cpu_init(0, gic_cpu_base);
 
/*
 * Synchronise with the boot thread.
@@ -79,7 +84,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 * the AuxCoreBoot1 register is updated with cpu state
 * A barrier is added to ensure that write buffer is drained
 */
-   __raw_writel(cpu, OMAP4_AUXCOREBOOT_REG1);
+   __raw_writel(cpu, omap4_auxcoreboot_reg1);
smp_wmb();
 
timeout = jiffies + (1 * HZ);
@@ -104,7 +109,7 @@ static void __init wakeup_secondary(void)
 * A barrier is added to ensure that write buffer is drained
 */
__raw_writel(virt_to_phys(omap_secondary_startup), \
-   OMAP4_AUXCOREBOOT_REG0);
+   omap4_auxcoreboot_reg0);
smp_wmb();
 
/*
@@ -130,6 +135,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 {
unsigned int ncores = get_core_count();
unsigned int cpu = smp_processor_id();
+   void __iomem *omap4_wkupgen_base;
int i;
 
/* sanity check */
@@ -161,6 +167,16 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
for (i = 0; i  max_cpus; i++)
set_cpu_present(i, true);
 
+   /* Never released */
+   omap4_wkupgen_base = ioremap(OMAP44XX_WKUPGEN_BASE, SZ_4K);
+   BUG_ON(!omap4_wkupgen_base);
+   omap4_auxcoreboot_reg0 = omap4_wkupgen_base + 0x800;
+   omap4_auxcoreboot_reg0 = omap4_wkupgen_base + 0x804;
+
+   /* Never released */
+   scu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_256);
+   BUG_ON(!scu_base);
+
if (max_cpus  1) {
/*
 * Enable the local timer or broadcast device for the
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index e2338c0..cd72970 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -231,7 +231,8 @@ static void __init omap2_gp_clocksource_init(void)
 static void __init omap2_gp_timer_init(void)
 {
 #ifdef CONFIG_LOCAL_TIMERS
-   twd_base = OMAP2_IO_ADDRESS(OMAP44XX_LOCAL_TWD_BASE);
+   twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
+   BUG_ON(!twd_base);
 #endif
omap_dm_timer_init();
 
diff --git a/arch/arm/plat-omap/include/mach/entry-macro.S 

[PATCH 09/14] omap: Use ioremap in dispc.c

2009-10-16 Thread Tony Lindgren
Use ioremap in dispc.c

Cc: Imre Deak imre.d...@nokia.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 drivers/video/omap/dispc.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index f16e421..6f957ce 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -204,6 +204,7 @@ static u32 inline dispc_read_reg(int idx)
 /* Select RFBI or bypass mode */
 static void enable_rfbi_mode(int enable)
 {
+   void __iomem *rfbi_control;
u32 l;
 
l = dispc_read_reg(DISPC_CONTROL);
@@ -216,9 +217,15 @@ static void enable_rfbi_mode(int enable)
dispc_write_reg(DISPC_CONTROL, l);
 
/* Set bypass mode in RFBI module */
-   l = __raw_readl(OMAP2_IO_ADDRESS(RFBI_CONTROL));
+   rfbi_control = ioremap(RFBI_CONTROL, SZ_1K);
+   if (!rfbi_control) {
+   pr_err(Unable to ioremap rfbi_control\n);
+   return;
+   }
+   l = __raw_readl(rfbi_control);
l |= enable ? 0 : (1  1);
-   __raw_writel(l, OMAP2_IO_ADDRESS(RFBI_CONTROL));
+   __raw_writel(l, rfbi_control);
+   iounmap(rfbi_control);
 }
 
 static void set_lcd_data_lines(int data_lines)
@@ -1367,6 +1374,7 @@ static int omap_dispc_init(struct omapfb_device *fbdev, 
int ext_mode,
int r;
u32 l;
struct lcd_panel *panel = fbdev-panel;
+   void __iomem *ram_fw_base;
int tmo = 1;
int skip_init = 0;
int i;
@@ -1441,7 +1449,13 @@ static int omap_dispc_init(struct omapfb_device *fbdev, 
int ext_mode,
}
 
/* L3 firewall setting: enable access to OCM RAM */
-   __raw_writel(0x402000b0, OMAP2_IO_ADDRESS(0x680050a0));
+   ram_fw_base = ioremap(0x68005000, SZ_1K);
+   if (!ram_fw_base) {
+   dev_err(dispc.fbdev-dev, Cannot ioremap to enable OCM RAM\n);
+   goto fail1;
+   }
+   __raw_writel(0x402000b0, ram_fw_base + 0xa0);
+   iounmap(ram_fw_base);
 
if ((r = alloc_palette_ram())  0)
goto fail2;

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


[PATCH 10/14] omap: Split OMAP2_IO_ADDRESS to L3 and L4

2009-10-16 Thread Tony Lindgren
From: Santosh Shilimkar santosh.shilim...@ti.com

This patch splits OMAP2_IO_ADDRESS to OMAP2_L3_IO_ADDRESS and
OMAP2_L4_IO_ADDRESS to reclaim more IO space.

The omap_read*() and omap_write*() functions will work only over
L4 address space. Current omap kernel stack uses these functions
only to access registers over L4 io address space

Note that these macros should only be used when ioremap does
not work. Please use ioremap instead in all new code.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/cm.h  |6 ++-
 arch/arm/mach-omap2/pm-debug.c|3 +-
 arch/arm/mach-omap2/prm.h |6 ++-
 arch/arm/mach-omap2/sdrc.h|9 +++--
 arch/arm/mach-omap2/sram242x.S|4 +-
 arch/arm/mach-omap2/sram243x.S|4 +-
 arch/arm/plat-omap/common.c   |   44 +
 arch/arm/plat-omap/include/mach/control.h |   15 +
 arch/arm/plat-omap/include/mach/entry-macro.S |6 ++-
 arch/arm/plat-omap/include/mach/io.h  |6 ++-
 arch/arm/plat-omap/include/mach/sdrc.h|6 ++-
 arch/arm/plat-omap/io.c   |   12 +++
 arch/arm/plat-omap/sram.c |   20 ++-
 13 files changed, 75 insertions(+), 66 deletions(-)

diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h
index cfd0b72..a2fcfcc 100644
--- a/arch/arm/mach-omap2/cm.h
+++ b/arch/arm/mach-omap2/cm.h
@@ -17,11 +17,11 @@
 #include prcm-common.h
 
 #define OMAP2420_CM_REGADDR(module, reg)   \
-   OMAP2_IO_ADDRESS(OMAP2420_CM_BASE + (module) + (reg))
+   OMAP2_L4_IO_ADDRESS(OMAP2420_CM_BASE + (module) + (reg))
 #define OMAP2430_CM_REGADDR(module, reg)   \
-   OMAP2_IO_ADDRESS(OMAP2430_CM_BASE + (module) + (reg))
+   OMAP2_L4_IO_ADDRESS(OMAP2430_CM_BASE + (module) + (reg))
 #define OMAP34XX_CM_REGADDR(module, reg)   \
-   OMAP2_IO_ADDRESS(OMAP3430_CM_BASE + (module) + (reg))
+   OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE + (module) + (reg))
 
 /*
  * Architecture-specific global CM registers
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 2fc4d6a..deed1dd 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -51,7 +51,8 @@ int omap2_pm_debug;
regs[reg_count++].val = __raw_readl(reg)
 #define DUMP_INTC_REG(reg, off) \
regs[reg_count].name = #reg; \
-   regs[reg_count++].val = __raw_readl(OMAP2_IO_ADDRESS(0x480fe000 + 
(off)))
+   regs[reg_count++].val = \
+__raw_readl(OMAP2_L4_IO_ADDRESS(0x480fe000 + (off)))
 
 static int __init pm_dbg_init(void);
 
diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h
index 03c467c..a117f85 100644
--- a/arch/arm/mach-omap2/prm.h
+++ b/arch/arm/mach-omap2/prm.h
@@ -17,11 +17,11 @@
 #include prcm-common.h
 
 #define OMAP2420_PRM_REGADDR(module, reg)  \
-   OMAP2_IO_ADDRESS(OMAP2420_PRM_BASE + (module) + (reg))
+   OMAP2_L4_IO_ADDRESS(OMAP2420_PRM_BASE + (module) + (reg))
 #define OMAP2430_PRM_REGADDR(module, reg)  \
-   OMAP2_IO_ADDRESS(OMAP2430_PRM_BASE + (module) + (reg))
+   OMAP2_L4_IO_ADDRESS(OMAP2430_PRM_BASE + (module) + (reg))
 #define OMAP34XX_PRM_REGADDR(module, reg)  \
-   OMAP2_IO_ADDRESS(OMAP3430_PRM_BASE + (module) + (reg))
+   OMAP2_L4_IO_ADDRESS(OMAP3430_PRM_BASE + (module) + (reg))
 
 /*
  * Architecture-specific global PRM registers
diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h
index 0837eda..345183d 100644
--- a/arch/arm/mach-omap2/sdrc.h
+++ b/arch/arm/mach-omap2/sdrc.h
@@ -48,9 +48,12 @@ static inline u32 sms_read_reg(u16 reg)
return __raw_readl(OMAP_SMS_REGADDR(reg));
 }
 #else
-#define OMAP242X_SDRC_REGADDR(reg) OMAP2_IO_ADDRESS(OMAP2420_SDRC_BASE + 
(reg))
-#define OMAP243X_SDRC_REGADDR(reg) OMAP2_IO_ADDRESS(OMAP243X_SDRC_BASE + 
(reg))
-#define OMAP34XX_SDRC_REGADDR(reg) OMAP2_IO_ADDRESS(OMAP343X_SDRC_BASE + 
(reg))
+#define OMAP242X_SDRC_REGADDR(reg) \
+   OMAP2_L3_IO_ADDRESS(OMAP2420_SDRC_BASE + (reg))
+#define OMAP243X_SDRC_REGADDR(reg) \
+   OMAP2_L3_IO_ADDRESS(OMAP243X_SDRC_BASE + (reg))
+#define OMAP34XX_SDRC_REGADDR(reg) \
+   OMAP2_L3_IO_ADDRESS(OMAP343X_SDRC_BASE + (reg))
 #endif /* __ASSEMBLER__ */
 
 #endif
diff --git a/arch/arm/mach-omap2/sram242x.S b/arch/arm/mach-omap2/sram242x.S
index 

[PATCH 11/14] omap: Remap L3, L4 to get more kernel io address space

2009-10-16 Thread Tony Lindgren
From: Santosh Shilimkar santosh.shilim...@ti.com

This patch remap L3 and L4 io space to get more kernel address space.
With this patch, 512 MB of IO space is reclaimed.
Some more combinations are possible but to make it uniform across
OMAP24XX, OMAP34XX and OMAP4430, these io combinations are chosen

Once this is reviewed and tested sufficiently, a documentation entry can
be created to ease up reading and debugging.
Like Documentation/arm/omap/io_map.txt

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/include/mach/io.h  |   97 ++---
 arch/arm/plat-omap/include/mach/vmalloc.h |2 -
 2 files changed, 60 insertions(+), 39 deletions(-)

diff --git a/arch/arm/plat-omap/include/mach/io.h 
b/arch/arm/plat-omap/include/mach/io.h
index c475be7..a8f931a 100644
--- a/arch/arm/plat-omap/include/mach/io.h
+++ b/arch/arm/plat-omap/include/mach/io.h
@@ -66,8 +66,18 @@
 #define OMAP2_L3_IO_OFFSET 0x9000
 #define OMAP2_L3_IO_ADDRESS(pa)IOMEM((pa) + OMAP2_L3_IO_OFFSET) /* L3 
*/
 
-#define OMAP2_L4_IO_OFFSET 0x9000
+#define OMAP4_L3_IO_OFFSET 0xb400
+#define OMAP4_L3_IO_ADDRESS(pa)IOMEM((pa) + OMAP4_L3_IO_OFFSET) /* L3 
*/
+
+#define OMAP4_GPMC_IO_OFFSET   0xa900
+#define OMAP4_GPMC_IO_ADDRESS(pa)  IOMEM((pa) + OMAP4_GPMC_IO_OFFSET)
+
+#define OMAP2_L4_IO_OFFSET 0xb200
 #define OMAP2_L4_IO_ADDRESS(pa)IOMEM((pa) + OMAP2_L4_IO_OFFSET) /* L4 
*/
+
+#define OMAP2_EMU_IO_OFFSET0xaa80  /* Emulation */
+#define OMAP2_EMU_IO_ADDRESS(pa)   IOMEM((pa) + OMAP2_EMU_IO_OFFSET)
+
 /*
  * 
  * Omap1 specific IO mapping
@@ -85,24 +95,27 @@
  */
 
 /* We map both L3 and L4 on OMAP2 */
-#define L3_24XX_PHYS   L3_24XX_BASE/* 0x6800 */
-#define L3_24XX_VIRT   0xf800
+#define L3_24XX_PHYS   L3_24XX_BASE/* 0x6800 -- 0xf800*/
+#define L3_24XX_VIRT   (L3_24XX_PHYS + OMAP2_L3_IO_OFFSET)
 #define L3_24XX_SIZE   SZ_1M   /* 44kB of 128MB used, want 1MB sect */
-#define L4_24XX_PHYS   L4_24XX_BASE/* 0x4800 */
-#define L4_24XX_VIRT   0xd800
+#define L4_24XX_PHYS   L4_24XX_BASE/* 0x4800 -- 0xfa00 */
+#define L4_24XX_VIRT   (L4_24XX_PHYS + OMAP2_L4_IO_OFFSET)
 #define L4_24XX_SIZE   SZ_1M   /* 1MB of 128MB used, want 1MB sect */
 
-#define L4_WK_243X_PHYSL4_WK_243X_BASE /* 0x4900 */
-#define L4_WK_243X_VIRT0xd900
+#define L4_WK_243X_PHYSL4_WK_243X_BASE /* 0x4900 -- 
0xfb00 */
+#define L4_WK_243X_VIRT(L4_WK_243X_PHYS + OMAP2_L4_IO_OFFSET)
 #define L4_WK_243X_SIZESZ_1M
-#define OMAP243X_GPMC_PHYS OMAP243X_GPMC_BASE  /* 0x4900 */
-#define OMAP243X_GPMC_VIRT 0xFE00
+#define OMAP243X_GPMC_PHYS OMAP243X_GPMC_BASE
+#define OMAP243X_GPMC_VIRT (OMAP243X_GPMC_PHYS + OMAP2_L3_IO_OFFSET)
+   /* 0x6e00 -- 0xfe00 */
 #define OMAP243X_GPMC_SIZE SZ_1M
 #define OMAP243X_SDRC_PHYS OMAP243X_SDRC_BASE
-#define OMAP243X_SDRC_VIRT 0xFD00
+   /* 0x6D00 -- 0xfd00 */
+#define OMAP243X_SDRC_VIRT (OMAP243X_SDRC_PHYS + OMAP2_L3_IO_OFFSET)
 #define OMAP243X_SDRC_SIZE SZ_1M
 #define OMAP243X_SMS_PHYS  OMAP243X_SMS_BASE
-#define OMAP243X_SMS_VIRT  0xFC00
+   /* 0x6c00 -- 0xfc00 */
+#define OMAP243X_SMS_VIRT  (OMAP243X_SMS_PHYS + OMAP2_L3_IO_OFFSET)
 #define OMAP243X_SMS_SIZE  SZ_1M
 
 /* DSP */
@@ -123,12 +136,12 @@
  */
 
 /* We map both L3 and L4 on OMAP3 */
-#define L3_34XX_PHYS   L3_34XX_BASE/* 0x6800 */
-#define L3_34XX_VIRT   0xf800
+#define L3_34XX_PHYS   L3_34XX_BASE/* 0x6800 -- 0xf800 */
+#define L3_34XX_VIRT   (L3_34XX_PHYS + OMAP2_L3_IO_OFFSET)
 #define L3_34XX_SIZE   SZ_1M   /* 44kB of 128MB used, want 1MB sect */
 
-#define L4_34XX_PHYS   L4_34XX_BASE/* 0x4800 */
-#define L4_34XX_VIRT   0xd800
+#define L4_34XX_PHYS   L4_34XX_BASE/* 0x4800 -- 0xfa00 */
+#define L4_34XX_VIRT   (L4_34XX_PHYS + OMAP2_L4_IO_OFFSET)
 #define L4_34XX_SIZE   SZ_4M   /* 1MB of 128MB used, want 1MB sect */
 
 /*
@@ -136,28 +149,33 @@
  * VPOM3430 was not working for Int controller
  */
 
-#define L4_WK_34XX_PHYSL4_WK_34XX_BASE /* 0x4830 */
-#define L4_WK_34XX_VIRT0xd830
+#define L4_WK_34XX_PHYSL4_WK_34XX_BASE /* 0x4830 -- 
0xfa30 */
+#define L4_WK_34XX_VIRT(L4_WK_34XX_PHYS + OMAP2_L4_IO_OFFSET)
 #define L4_WK_34XX_SIZESZ_1M
 
-#define L4_PER_34XX_PHYS   L4_PER_34XX_BASE /* 0x4900 */
-#define 

[PATCH 12/14] omap: Move SRAM map to claim more io space

2009-10-16 Thread Tony Lindgren
From: Santosh Shilimkar santosh.shilim...@ti.com

This patch moves SRAM map to free up more kernel address io space.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/sram.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 93bdbaf..4144f81 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -41,14 +41,14 @@
 #define OMAP1_SRAM_VA  VMALLOC_END
 #define OMAP2_SRAM_PA  0x4020
 #define OMAP2_SRAM_PUB_PA  0x4020f800
-#define OMAP2_SRAM_VA  0xe300
+#define OMAP2_SRAM_VA  0xfe40
 #define OMAP2_SRAM_PUB_VA  (OMAP2_SRAM_VA + 0x800)
 #define OMAP3_SRAM_PA   0x4020
-#define OMAP3_SRAM_VA   0xe300
+#define OMAP3_SRAM_VA   0xfe40
 #define OMAP3_SRAM_PUB_PA   0x40208000
 #define OMAP3_SRAM_PUB_VA   (OMAP3_SRAM_VA + 0x8000)
 #define OMAP4_SRAM_PA  0x4020  /*0x402f*/
-#define OMAP4_SRAM_VA  0xd700  /*0xd70f*/
+#define OMAP4_SRAM_VA  0xfe40  /*0xfe4f*/
 
 #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
 #define SRAM_BOOTLOADER_SZ 0x00

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


[PATCH 13/14] omap: Fix DEBUG_LL UART io address

2009-10-16 Thread Tony Lindgren
From: Santosh Shilimkar santosh.shilim...@ti.com

This patch fixes the low level debug UART io address as per this series.
The change is essential to have CONFIG_DEBUG_LL working.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-2430sdp.c   |2 +-
 arch/arm/mach-omap2/board-3430sdp.c   |2 +-
 arch/arm/mach-omap2/board-4430sdp.c   |2 +-
 arch/arm/mach-omap2/board-apollon.c   |2 +-
 arch/arm/mach-omap2/board-generic.c   |2 +-
 arch/arm/mach-omap2/board-h4.c|2 +-
 arch/arm/mach-omap2/board-ldp.c   |2 +-
 arch/arm/mach-omap2/board-n8x0.c  |6 +++---
 arch/arm/mach-omap2/board-omap3beagle.c   |2 +-
 arch/arm/mach-omap2/board-omap3evm.c  |2 +-
 arch/arm/mach-omap2/board-omap3pandora.c  |2 +-
 arch/arm/mach-omap2/board-overo.c |2 +-
 arch/arm/mach-omap2/board-rx51.c  |2 +-
 arch/arm/mach-omap2/board-zoom2.c |2 +-
 arch/arm/plat-omap/include/mach/debug-macro.S |4 ++--
 15 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 42217b3..e032a33 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -221,7 +221,7 @@ static void __init omap_2430sdp_map_io(void)
 MACHINE_START(OMAP_2430SDP, OMAP2430 sdp2430 board)
/* Maintainer: Syed Khasim - Texas Instruments Inc */
.phys_io= 0x4800,
-   .io_pg_offst= ((0xd800)  18)  0xfffc,
+   .io_pg_offst= ((0xfa00)  18)  0xfffc,
.boot_params= 0x8100,
.map_io = omap_2430sdp_map_io,
.init_irq   = omap_2430sdp_init_irq,
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index efaf053..364ce7e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -511,7 +511,7 @@ static void __init omap_3430sdp_map_io(void)
 MACHINE_START(OMAP_3430SDP, OMAP3430 3430SDP board)
/* Maintainer: Syed Khasim - Texas Instruments Inc */
.phys_io= 0x4800,
-   .io_pg_offst= ((0xd800)  18)  0xfffc,
+   .io_pg_offst= ((0xfa00)  18)  0xfffc,
.boot_params= 0x8100,
.map_io = omap_3430sdp_map_io,
.init_irq   = omap_3430sdp_init_irq,
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 2a7b901..50a62f2 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -93,7 +93,7 @@ static void __init omap_4430sdp_map_io(void)
 MACHINE_START(OMAP_4430SDP, OMAP4430 4430SDP board)
/* Maintainer: Santosh Shilimkar - Texas Instruments Inc */
.phys_io= 0x4800,
-   .io_pg_offst= ((0xd800)  18)  0xfffc,
+   .io_pg_offst= ((0xfa00)  18)  0xfffc,
.boot_params= 0x8100,
.map_io = omap_4430sdp_map_io,
.init_irq   = omap_4430sdp_init_irq,
diff --git a/arch/arm/mach-omap2/board-apollon.c 
b/arch/arm/mach-omap2/board-apollon.c
index a113228..e8a0e56 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -333,7 +333,7 @@ static void __init omap_apollon_map_io(void)
 MACHINE_START(OMAP_APOLLON, OMAP24xx Apollon)
/* Maintainer: Kyungmin Park kyungmin.p...@samsung.com */
.phys_io= 0x4800,
-   .io_pg_offst= ((0xd800)  18)  0xfffc,
+   .io_pg_offst= ((0xfa00)  18)  0xfffc,
.boot_params= 0x8100,
.map_io = omap_apollon_map_io,
.init_irq   = omap_apollon_init_irq,
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 2e09a1c..1a139c0 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -56,7 +56,7 @@ static void __init omap_generic_map_io(void)
 MACHINE_START(OMAP_GENERIC, Generic OMAP24xx)
/* Maintainer: Paul Mundt paul.mu...@nokia.com */
.phys_io= 0x4800,
-   .io_pg_offst= ((0xd800)  18)  0xfffc,
+   .io_pg_offst= ((0xfa00)  18)  0xfffc,
.boot_params= 0x8100,
.map_io = omap_generic_map_io,
.init_irq   = omap_generic_init_irq,
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index eaa02d0..86f78f3 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -376,7 +376,7 @@ static void __init omap_h4_map_io(void)
 MACHINE_START(OMAP_H4, OMAP2420 H4 board)
/* Maintainer: Paul Mundt paul.mu...@nokia.com */
.phys_io= 0x4800,
-   .io_pg_offst= ((0xd800)  18)  0xfffc,
+   .io_pg_offst= ((0xfa00)  18)  0xfffc,
   

[PATCH 14/14] omap: Add OMAP4 L3 and L4 peripherals.

2009-10-16 Thread Tony Lindgren
From: Santosh Shilimkar santosh.shilim...@ti.com

This patch adds few necessary peripherals for OMAP4.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/io.c   |   18 +
 arch/arm/plat-omap/include/mach/io.h   |   29 +---
 arch/arm/plat-omap/include/mach/omap44xx.h |3 +++
 arch/arm/plat-omap/io.c|8 
 4 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e3a3bad..fc62953 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -203,6 +203,24 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
.type   = MT_DEVICE,
},
{
+   .virtual= OMAP44XX_EMIF1_VIRT,
+   .pfn= __phys_to_pfn(OMAP44XX_EMIF1_PHYS),
+   .length = OMAP44XX_EMIF1_SIZE,
+   .type   = MT_DEVICE,
+   },
+   {
+   .virtual= OMAP44XX_EMIF2_VIRT,
+   .pfn= __phys_to_pfn(OMAP44XX_EMIF2_PHYS),
+   .length = OMAP44XX_EMIF2_SIZE,
+   .type   = MT_DEVICE,
+   },
+   {
+   .virtual= OMAP44XX_DMM_VIRT,
+   .pfn= __phys_to_pfn(OMAP44XX_DMM_PHYS),
+   .length = OMAP44XX_DMM_SIZE,
+   .type   = MT_DEVICE,
+   },
+   {
.virtual= L4_PER_44XX_VIRT,
.pfn= __phys_to_pfn(L4_PER_44XX_PHYS),
.length = L4_PER_44XX_SIZE,
diff --git a/arch/arm/plat-omap/include/mach/io.h 
b/arch/arm/plat-omap/include/mach/io.h
index a8f931a..7e5319f 100644
--- a/arch/arm/plat-omap/include/mach/io.h
+++ b/arch/arm/plat-omap/include/mach/io.h
@@ -66,15 +66,19 @@
 #define OMAP2_L3_IO_OFFSET 0x9000
 #define OMAP2_L3_IO_ADDRESS(pa)IOMEM((pa) + OMAP2_L3_IO_OFFSET) /* L3 
*/
 
+
+#define OMAP2_L4_IO_OFFSET 0xb200
+#define OMAP2_L4_IO_ADDRESS(pa)IOMEM((pa) + OMAP2_L4_IO_OFFSET) /* L4 
*/
+
 #define OMAP4_L3_IO_OFFSET 0xb400
 #define OMAP4_L3_IO_ADDRESS(pa)IOMEM((pa) + OMAP4_L3_IO_OFFSET) /* L3 
*/
 
+#define OMAP4_L3_PER_IO_OFFSET 0xb110
+#define OMAP4_L3_PER_IO_ADDRESS(pa)IOMEM((pa) + OMAP4_L3_PER_IO_OFFSET)
+
 #define OMAP4_GPMC_IO_OFFSET   0xa900
 #define OMAP4_GPMC_IO_ADDRESS(pa)  IOMEM((pa) + OMAP4_GPMC_IO_OFFSET)
 
-#define OMAP2_L4_IO_OFFSET 0xb200
-#define OMAP2_L4_IO_ADDRESS(pa)IOMEM((pa) + OMAP2_L4_IO_OFFSET) /* L4 
*/
-
 #define OMAP2_EMU_IO_OFFSET0xaa80  /* Emulation */
 #define OMAP2_EMU_IO_ADDRESS(pa)   IOMEM((pa) + OMAP2_EMU_IO_OFFSET)
 
@@ -214,6 +218,11 @@
 #define L4_PER_44XX_VIRT   (L4_PER_44XX_PHYS + OMAP2_L4_IO_OFFSET)
 #define L4_PER_44XX_SIZE   SZ_4M
 
+#define L4_ABE_44XX_PHYS   L4_ABE_44XX_BASE
+   /* 0x4900 -- 0xfb00 */
+#define L4_ABE_44XX_VIRT   (L4_ABE_44XX_PHYS + OMAP2_L4_IO_OFFSET)
+#define L4_ABE_44XX_SIZE   SZ_1M
+
 #define L4_EMU_44XX_PHYS   L4_EMU_44XX_BASE
/* 0x5400 -- 0xfe80 */
 #define L4_EMU_44XX_VIRT   (L4_EMU_44XX_PHYS + OMAP2_EMU_IO_OFFSET)
@@ -225,6 +234,20 @@
 #define OMAP44XX_GPMC_SIZE SZ_1M
 
 
+#define OMAP44XX_EMIF1_PHYSOMAP44XX_EMIF1_BASE
+   /* 0x4c00 -- 0xfd10 */
+#define OMAP44XX_EMIF1_VIRT(OMAP44XX_EMIF1_PHYS + OMAP4_L3_PER_IO_OFFSET)
+#define OMAP44XX_EMIF1_SIZESZ_1M
+
+#define OMAP44XX_EMIF2_PHYSOMAP44XX_EMIF2_BASE
+   /* 0x4d00 -- 0xfd20 */
+#define OMAP44XX_EMIF2_VIRT(OMAP44XX_EMIF2_PHYS + OMAP4_L3_PER_IO_OFFSET)
+#define OMAP44XX_EMIF2_SIZESZ_1M
+
+#define OMAP44XX_DMM_PHYS  OMAP44XX_DMM_BASE
+   /* 0x4e00 -- 0xfd30 */
+#define OMAP44XX_DMM_VIRT  (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET)
+#define OMAP44XX_DMM_SIZE  SZ_1M
 /*
  * 
  * Omap specific register access
diff --git a/arch/arm/plat-omap/include/mach/omap44xx.h 
b/arch/arm/plat-omap/include/mach/omap44xx.h
index 8b4a578..3361897 100644
--- a/arch/arm/plat-omap/include/mach/omap44xx.h
+++ b/arch/arm/plat-omap/include/mach/omap44xx.h
@@ -22,6 +22,9 @@
 #define L4_PER_44XX_BASE   0x4800
 #define L4_EMU_44XX_BASE   0x5400
 #define L3_44XX_BASE   0x4400
+#define OMAP44XX_EMIF1_BASE0x4c00
+#define OMAP44XX_EMIF2_BASE0x4d00
+#define OMAP44XX_DMM_BASE  0x4e00
 #define OMAP4430_32KSYNCT_BASE 0x4a304000
 #define 

Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code

2009-10-16 Thread Tony Lindgren
* Tony Lindgren t...@atomide.com [091016 16:42]:
 Use ioremap for omap4 L4 code

Santosh, can you please check and ack this patch?

Especially some of the ioremap sizes may be wrong. Also, this one
I cannot boot test, so it's just compile tested.

Regards,

Tony
 
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/board-4430sdp.c   |   13 ++--
  arch/arm/mach-omap2/omap-smp.c|   28 
 -
  arch/arm/mach-omap2/timer-gp.c|3 ++-
  arch/arm/plat-omap/include/mach/entry-macro.S |2 ++
  arch/arm/plat-omap/include/mach/omap44xx.h|5 
  5 files changed, 37 insertions(+), 14 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
 b/arch/arm/mach-omap2/board-4430sdp.c
 index eb37c40..2a7b901 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -52,8 +52,17 @@ static struct omap_board_config_kernel sdp4430_config[] 
 __initdata = {
  
  static void __init gic_init_irq(void)
  {
 - gic_dist_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_DIST_BASE), 29);
 - gic_cpu_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE));
 + void __iomem *base;
 +
 + /* Static mapping, never released */
 + base = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
 + BUG_ON(!base);
 + gic_dist_init(0, base, 29);
 +
 + /* Static mapping, never released */
 + base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_256);
 + BUG_ON(!base);
 + gic_cpu_init(0, OMAP44XX_GIC_CPU_BASE);
  }
  
  static void __init omap_4430sdp_init_irq(void)
 diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
 index 48ee295..a1b618c 100644
 --- a/arch/arm/mach-omap2/omap-smp.c
 +++ b/arch/arm/mach-omap2/omap-smp.c
 @@ -26,11 +26,11 @@
  #include mach/hardware.h
  
  /* Registers used for communicating startup information */
 -#define OMAP4_AUXCOREBOOT_REG0   (OMAP44XX_VA_WKUPGEN_BASE + 
 0x800)
 -#define OMAP4_AUXCOREBOOT_REG1   (OMAP44XX_VA_WKUPGEN_BASE + 
 0x804)
 +static void __iomem *omap4_auxcoreboot_reg0;
 +static void __iomem *omap4_auxcoreboot_reg1;
  
  /* SCU base address */
 -static void __iomem *scu_base = OMAP44XX_VA_SCU_BASE;
 +static void __iomem *scu_base;
  
  /*
   * Use SCU config register to count number of cores
 @@ -46,6 +46,8 @@ static DEFINE_SPINLOCK(boot_lock);
  
  void __cpuinit platform_secondary_init(unsigned int cpu)
  {
 + void __iomem *gic_cpu_base;
 +
   trace_hardirqs_off();
  
   /*
 @@ -54,7 +56,10 @@ void __cpuinit platform_secondary_init(unsigned int cpu)
* for us: do so
*/
  
 - gic_cpu_init(0, OMAP2_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE));
 + /* Static mapping, never released */
 + gic_cpu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_256);
 + BUG_ON(!gic_cpu_base);
 + gic_cpu_init(0, gic_cpu_base);
  
   /*
* Synchronise with the boot thread.
 @@ -79,7 +84,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct 
 task_struct *idle)
* the AuxCoreBoot1 register is updated with cpu state
* A barrier is added to ensure that write buffer is drained
*/
 - __raw_writel(cpu, OMAP4_AUXCOREBOOT_REG1);
 + __raw_writel(cpu, omap4_auxcoreboot_reg1);
   smp_wmb();
  
   timeout = jiffies + (1 * HZ);
 @@ -104,7 +109,7 @@ static void __init wakeup_secondary(void)
* A barrier is added to ensure that write buffer is drained
*/
   __raw_writel(virt_to_phys(omap_secondary_startup), \
 - OMAP4_AUXCOREBOOT_REG0);
 + omap4_auxcoreboot_reg0);
   smp_wmb();
  
   /*
 @@ -130,6 +135,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
  {
   unsigned int ncores = get_core_count();
   unsigned int cpu = smp_processor_id();
 + void __iomem *omap4_wkupgen_base;
   int i;
  
   /* sanity check */
 @@ -161,6 +167,16 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
   for (i = 0; i  max_cpus; i++)
   set_cpu_present(i, true);
  
 + /* Never released */
 + omap4_wkupgen_base = ioremap(OMAP44XX_WKUPGEN_BASE, SZ_4K);
 + BUG_ON(!omap4_wkupgen_base);
 + omap4_auxcoreboot_reg0 = omap4_wkupgen_base + 0x800;
 + omap4_auxcoreboot_reg0 = omap4_wkupgen_base + 0x804;
 +
 + /* Never released */
 + scu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_256);
 + BUG_ON(!scu_base);
 +
   if (max_cpus  1) {
   /*
* Enable the local timer or broadcast device for the
 diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
 index e2338c0..cd72970 100644
 --- a/arch/arm/mach-omap2/timer-gp.c
 +++ b/arch/arm/mach-omap2/timer-gp.c
 @@ -231,7 +231,8 @@ static void __init omap2_gp_clocksource_init(void)
  static void __init omap2_gp_timer_init(void)
  {
  #ifdef CONFIG_LOCAL_TIMERS
 - twd_base = 

Re: 24xx/n8x0 booting again, linux-omap updated to -rc5

2009-10-16 Thread Tony Lindgren
* Tony Lindgren t...@atomide.com [091015 18:34]:
 Hi all,
 
 Thanks to Paul's OMAP2xxx clock: set up clockdomain pointer in struct clk
 patch, we got 24xx booting again both in mainline and in linux-omap.
 
 The following patch is also needed to change the n8x0 serial console CMDLINE
 from ttyS0 to ttyS2 as the port numbering now matches the physical ports.
 The patch is already in linux-omap, but not yet in mainline.
 
 Also, I've rebuilt linux-omap again on top of -rc5. Will merge in the plat
 header patches tomorrow.

Well I did not quite get all that stuff integrated yet as I ended up doing
some more ioremap changes under split l3/l4 patches.

Also fixed the mach-omap1/serial.c that got broken with the earlier
Eliminate OMAP_MAX_NR_PORTS patch.

Omap1 still had the old unused null terminator in the
serial_platform_data array that had to be removed to keep things
booting.
 
 Cheers,
 
 Tony

 From 71d3bff80f77cdd286303f19308058c6c844458f Mon Sep 17 00:00:00 2001
 From: Tony Lindgren t...@atomide.com
 Date: Thu, 15 Oct 2009 18:13:28 -0700
 Subject: [PATCH] omap: Fix console serial port number for n8x0
 
 With the recent changes omap serial ports match the physical
 numbering like they should. Fix the kernel CMDLINE accordingly
 so console works.
 
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 diff --git a/arch/arm/configs/n8x0_defconfig b/arch/arm/configs/n8x0_defconfig
 index 8da75de..264f52b 100644
 --- a/arch/arm/configs/n8x0_defconfig
 +++ b/arch/arm/configs/n8x0_defconfig
 @@ -304,7 +304,7 @@ CONFIG_ALIGNMENT_TRAP=y
  CONFIG_ZBOOT_ROM_TEXT=0x10C08000
  CONFIG_ZBOOT_ROM_BSS=0x1020
  # CONFIG_ZBOOT_ROM is not set
 -CONFIG_CMDLINE=root=1f03 rootfstype=jffs2 console=ttyS0,115200n8
 +CONFIG_CMDLINE=root=1f03 rootfstype=jffs2 console=ttyS2,115200n8
  # CONFIG_XIP_KERNEL is not set
  # CONFIG_KEXEC is not set
  

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