[PATCHv2 2/6] OMAP3: PM: Added support for INACTIVE and ON states for powerdomains
From: Tero Kristo tero.kri...@nokia.com
Previously omap_sram_idle() did not know about the difference between ON and
INACTIVE states, which complicated the state handling in these cases. Now,
the following changes are done in the idle logic:
- Check for IO-chain arming is changed to reflect desired state (RET)
- UART clocks will be disabled if we attempt to enter INACTIVE (this allows
the state change to actually happen)
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3b62c96..574492e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -391,6 +391,7 @@ void omap_sram_idle(void)
mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
switch (mpu_next_state) {
case PWRDM_POWER_ON:
+ case PWRDM_POWER_INACTIVE:
case PWRDM_POWER_RET:
/* No need to save context */
save_state = 0;
@@ -460,9 +461,11 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
- /* Enable IO-PAD and IO-CHAIN wakeups */
- prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
- omap3_enable_io_chain();
+ if (core_next_state = PWRDM_POWER_RET) {
+ /* Enable IO-PAD and IO-CHAIN wakeups */
+ prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
+ omap3_enable_io_chain();
+ }
}
omap3_intc_prepare_idle();
@@ -561,15 +564,13 @@ void omap_sram_idle(void)
}
/* Disable IO-PAD and IO-CHAIN wakeup */
- if (core_next_state PWRDM_POWER_ON) {
+ if (core_next_state = PWRDM_POWER_RET) {
prm_clear_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
omap3_disable_io_chain();
}
pwrdm_post_transition();
-
- omap2_clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
int omap3_can_sleep(void)
@@ -617,7 +618,6 @@ int set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
}
if (sleep_switch) {
- omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
pwrdm_wait_transition(pwrdm);
pwrdm_state_switch(pwrdm);
}
--
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
[PATCHv2 0/6] Idle status patches revisited
From: Tero Kristo tero.kri...@nokia.com Improvements compared to previous set: - Fixed wrong pwrdm state check on IO chain arming on patch 2 - Improved changelog on patch 2 4 - Moved FCLK checks inside clockdomain code from powerdomain code in patch 5 - Some style changes on patch 6 Still, I believe there is no simple way of implementing the idle status check by using the usecounts inside clock framework. It would probably be possible by adding a new usecount variable that would be updated according to slightly different rules, but this also looks bit complicated compared to the need. -Tero -- 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 1/6] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level
From: Tero Kristo tero.kri...@nokia.com
Currently only ON, RET and OFF are supported, and ON is arguably broken as it
allows the powerdomain to enter INACTIVE state unless idle is prevented.
Now, pwrdm code prevents idle if ON is selected, and also adds support for
INACTIVE. This simplifies the control needed inside sleep code.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/powerdomain.c | 32 +
arch/arm/mach-omap2/powerdomains34xx.h| 26 ++--
arch/arm/plat-omap/include/plat/powerdomain.h |6 -
3 files changed, 45 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index b6990e3..1237717 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -112,8 +112,8 @@ static struct powerdomain *_pwrdm_deps_lookup(struct
powerdomain *pwrdm,
static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
{
- int prev;
- int state;
+ u8 prev;
+ u8 state;
if (pwrdm == NULL)
return -EINVAL;
@@ -220,7 +220,7 @@ int pwrdm_register(struct powerdomain *pwrdm)
pr_debug(powerdomain: registered %s\n, pwrdm-name);
ret = 0;
-
+ pwrdm-next_state = -1;
pr_unlock:
write_unlock_irqrestore(pwrdm_rwlock, flags);
@@ -701,19 +701,38 @@ int pwrdm_get_mem_bank_count(struct powerdomain *pwrdm)
*/
int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
{
+ u8 prg_pwrst;
+
if (!pwrdm)
return -EINVAL;
+ if (pwrdm-next_state == pwrst)
+ return 0;
+
if (!(pwrdm-pwrsts (1 pwrst)))
return -EINVAL;
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
pwrdm-name, pwrst);
+ /* INACTIVE is reserved, so we program pwrdm as ON */
+ if (pwrst == PWRDM_POWER_INACTIVE)
+ prg_pwrst = PWRDM_POWER_ON;
+ else
+ prg_pwrst = pwrst;
+
prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
-(pwrst OMAP_POWERSTATE_SHIFT),
+(prg_pwrst OMAP_POWERSTATE_SHIFT),
pwrdm-prcm_offs, PM_PWSTCTRL);
+ /* If next state is ON, prevent idle */
+ if (pwrst == PWRDM_POWER_ON)
+ omap2_clkdm_deny_idle(pwrdm-pwrdm_clkdms[0]);
+ else
+ omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+
+ pwrdm-next_state = pwrst;
+
return 0;
}
@@ -730,8 +749,11 @@ int pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
if (!pwrdm)
return -EINVAL;
+ if (pwrdm-next_state -1)
+ return pwrdm-next_state;
+
return prm_read_mod_bits_shift(pwrdm-prcm_offs, PM_PWSTCTRL,
- OMAP_POWERSTATE_MASK);
+ OMAP_POWERSTATE_MASK);
}
/**
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index fd09b08..9eb2dc5 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -165,7 +165,7 @@ static struct powerdomain iva2_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
.dep_bit = OMAP3430_PM_WKDEP_MPU_EN_IVA2_SHIFT,
.wkdep_srcs = iva2_wkdeps,
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 4,
.pwrsts_mem_ret = {
@@ -188,7 +188,7 @@ static struct powerdomain mpu_34xx_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
.dep_bit = OMAP3430_EN_MPU_SHIFT,
.wkdep_srcs = mpu_34xx_wkdeps,
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
.pwrsts_mem_ret = {
@@ -206,7 +206,7 @@ static struct powerdomain core_34xx_pre_es3_1_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.dep_bit = OMAP3430_EN_CORE_SHIFT,
.banks= 2,
.pwrsts_mem_ret = {
@@ -214,8 +214,8 @@ static struct powerdomain core_34xx_pre_es3_1_pwrdm = {
[1] = PWRSTS_OFF_RET,/* MEM2RETSTATE */
},
.pwrsts_mem_on= {
- [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
- [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
+ [0] = PWRSTS_OFF_RET_INA_ON, /* MEM1ONSTATE */
+ [1] = PWRSTS_OFF_RET_INA_ON, /* MEM2ONSTATE */
},
};
[PATCHv2 4/6] OMAP3: PM: Removed pwrdm state hacking from omap_sram_idle
From: Tero Kristo tero.kri...@nokia.com
Following hacks will be moved inside cpuidle in subsequent patch:
- CAM domain prevents idle completely
- PER should not go OFF if core remains active
This simplifies the design and allows cpuidle to keep better track of which
power states system will actually enter.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 18 ++
1 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 574492e..d77fc88 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -81,7 +81,6 @@ 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 prm_setup_times_vc prm_setup_times_default = {
.clksetup = 0xff,
@@ -378,7 +377,6 @@ void omap_sram_idle(void)
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- int per_state_modified = 0;
if (!_omap_sram_idle)
return;
@@ -421,19 +419,10 @@ void omap_sram_idle(void)
if (per_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
- if (per_next_state == PWRDM_POWER_OFF) {
- if (core_next_state == PWRDM_POWER_ON) {
- per_next_state = PWRDM_POWER_RET;
- pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
- per_state_modified = 1;
- } else
- omap3_per_save_context();
- }
+ if (per_next_state == PWRDM_POWER_OFF)
+ omap3_per_save_context();
}
- if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
- omap2_clkdm_deny_idle(mpu_pwrdm-pwrdm_clkdms[0]);
-
/*
* Disable smartreflex before entering WFI.
* Only needed if we are going to enter retention or off.
@@ -559,8 +548,6 @@ void omap_sram_idle(void)
}
omap2_gpio_resume_after_idle();
omap_uart_resume_idle(2);
- if (per_state_modified)
- pwrdm_set_next_pwrst(per_pwrdm, PWRDM_POWER_OFF);
}
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -1174,7 +1161,6 @@ static int __init omap3_pm_init(void)
neon_pwrdm = pwrdm_lookup(neon_pwrdm);
per_pwrdm = pwrdm_lookup(per_pwrdm);
core_pwrdm = pwrdm_lookup(core_pwrdm);
- cam_pwrdm = pwrdm_lookup(cam_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
[PATCHv2 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
From: Tero Kristo tero.kri...@nokia.com
pwrdm_can_idle(pwrdm) will check if the specified powerdomain can enter
idle. This is done by checking all clockdomains under the powerdomain
if they can idle also.
omap2_clkdm_can_idle(clkdm) will check if the specified clockdomain can
enter idle. This checks the functional clock status in the clockdomain.
These calls can be used e.g. inside cpuidle to decide which power states
core and mpu should enter during idle, as there are certain dependencies
between wakeup capabilities and reset logic.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/clockdomain.c | 24
arch/arm/mach-omap2/clockdomains.h| 14 ++
arch/arm/mach-omap2/powerdomain.c | 25 +
arch/arm/plat-omap/include/plat/clockdomain.h | 12
arch/arm/plat-omap/include/plat/powerdomain.h |1 +
5 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index fcd8232..9ddeb96 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -474,6 +474,30 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
return 0;
}
+
+/**
+ * omap2_clkdm_can_idle - check if clockdomain has any active clocks or not
+ * @clkdm: struct clockdomain *
+ *
+ * Checks if the clockdomain has any active clock or not, i.e. whether it
+ * can enter idle. Returns -EINVAL if clkdm is NULL; 0 if unable to idle;
+ * 1 if can idle.
+ */
+int omap2_clkdm_can_idle(struct clockdomain *clkdm)
+{
+ int i;
+ const int fclk_regs[] = { CM_FCLKEN, OMAP3430ES2_CM_FCLKEN3 };
+
+ if (!clkdm)
+ return -EINVAL;
+
+ for (i = 0; i clkdm-fclk_reg_amt; i++)
+ if (cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
+ fclk_regs[i]) ~clkdm-fclk_masks[i])
+ return 0;
+ return 1;
+}
+
/**
* omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
* @clkdm: struct clockdomain *
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index c4ee076..2cde82a 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -167,6 +167,7 @@ static struct clockdomain iva2_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_IVA2_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .fclk_reg_amt = 1,
};
static struct clockdomain gfx_3430es1_clkdm = {
@@ -183,6 +184,7 @@ static struct clockdomain sgx_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_SGX_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
+ .fclk_reg_amt = 1,
};
/*
@@ -206,6 +208,11 @@ static struct clockdomain core_l3_34xx_clkdm = {
.flags = CLKDM_CAN_HWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_L3_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .fclk_reg_amt = 2,
+ .fclk_masks = {
+ [0] = OMAP3430_EN_UART2 | OMAP3430_EN_UART1,
+ [1] = 0,
+ },
};
static struct clockdomain core_l4_34xx_clkdm = {
@@ -222,6 +229,7 @@ static struct clockdomain dss_34xx_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_DSS_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .fclk_reg_amt = 1,
};
static struct clockdomain cam_clkdm = {
@@ -230,6 +238,7 @@ static struct clockdomain cam_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_CAM_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .fclk_reg_amt = 1,
};
static struct clockdomain usbhost_clkdm = {
@@ -238,6 +247,7 @@ static struct clockdomain usbhost_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_USBHOST_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
+ .fclk_reg_amt = 1,
};
static struct clockdomain per_clkdm = {
@@ -246,6 +256,10 @@ static struct clockdomain per_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_PER_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .fclk_reg_amt = 1,
+ .fclk_masks = {
+ [0] = OMAP3430_EN_UART3,
+ },
};
/*
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 1237717..2bef099 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1217,6 +1217,31 @@ int pwrdm_wait_transition(struct powerdomain *pwrdm)
return 0;
}
+/**
+ * pwrdm_can_idle - check if the powerdomain can enter idle
+ * @pwrdm: struct
[PATCHv2 3/6] OMAP3: CPUidle: Fixed support for ON / INACTIVE states
From: Tero Kristo tero.kri...@nokia.com
New powerdomain code support for INACTIVE state removes the need to control
clockdomains directly from cpuidle. Also, cpuidle state definitions can now
directly support ON / INACTIVE simplifying the implementation.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 32
1 files changed, 4 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1cfa5a6..4a81ef1 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -91,20 +91,6 @@ static int omap3_idle_bm_check(void)
return 0;
}
-static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- omap2_clkdm_allow_idle(clkdm);
- return 0;
-}
-
-static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- omap2_clkdm_deny_idle(clkdm);
- return 0;
-}
-
/**
* omap3_enter_idle - Programs OMAP3 to enter the specified state
* @dev: cpuidle device
@@ -141,19 +127,9 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
- if (cx-type == OMAP3_STATE_C1) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
- }
-
/* Execute ARM wfi */
omap_sram_idle();
- if (cx-type == OMAP3_STATE_C1) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
- }
-
return_sleep_time:
getnstimeofday(ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
@@ -246,8 +222,8 @@ void omap_init_power_states(void)
cpuidle_params_table[OMAP3_STATE_C2].wake_latency;
omap3_power_states[OMAP3_STATE_C2].threshold =
cpuidle_params_table[OMAP3_STATE_C2].threshold;
- omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
- omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
+ omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_INACTIVE;
+ omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_INACTIVE;
omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID;
/* C3 . MPU CSWR + Core inactive */
@@ -261,7 +237,7 @@ void omap_init_power_states(void)
omap3_power_states[OMAP3_STATE_C3].threshold =
cpuidle_params_table[OMAP3_STATE_C3].threshold;
omap3_power_states[OMAP3_STATE_C3].mpu_state = PWRDM_POWER_RET;
- omap3_power_states[OMAP3_STATE_C3].core_state = PWRDM_POWER_ON;
+ omap3_power_states[OMAP3_STATE_C3].core_state = PWRDM_POWER_INACTIVE;
omap3_power_states[OMAP3_STATE_C3].flags = CPUIDLE_FLAG_TIME_VALID |
CPUIDLE_FLAG_CHECK_BM;
@@ -276,7 +252,7 @@ void omap_init_power_states(void)
omap3_power_states[OMAP3_STATE_C4].threshold =
cpuidle_params_table[OMAP3_STATE_C4].threshold;
omap3_power_states[OMAP3_STATE_C4].mpu_state = PWRDM_POWER_OFF;
- omap3_power_states[OMAP3_STATE_C4].core_state = PWRDM_POWER_ON;
+ omap3_power_states[OMAP3_STATE_C4].core_state = PWRDM_POWER_INACTIVE;
omap3_power_states[OMAP3_STATE_C4].flags = CPUIDLE_FLAG_TIME_VALID |
CPUIDLE_FLAG_CHECK_BM;
--
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
[PATCHv2 6/6] OMAP3: CPUidle: Added peripheral pwrdm checks into bm check
From: Tero Kristo tero.kri...@nokia.com
Following checks are made (and their reasoning):
- If CAM domain is active, prevent idle completely
* CAM pwrdm does not have HW wakeup capability
- If PER is likely to remain on, prevent PER off
* Saves on unnecessary context save/restore
- If CORE domain is active, prevent PER off-mode
* PER off in this case would prevent wakeups from PER completely
- Only allow CORE off, if all peripheral domains are off
* CORE off will cause a chipwide reset
Also, enabled CHECK_BM flag for C2, as this is needed for the camera case.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 118 ++--
1 files changed, 111 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 4a81ef1..dad64a9 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -58,7 +58,8 @@ struct omap3_processor_cx {
struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
-struct powerdomain *mpu_pd, *core_pd;
+struct powerdomain *mpu_pd, *core_pd, *per_pd, *iva2_pd;
+struct powerdomain *sgx_pd, *usb_pd, *cam_pd, *dss_pd;
/*
* The latencies/thresholds for various C states have
@@ -92,6 +93,22 @@ static int omap3_idle_bm_check(void)
}
/**
+ * pwrdm_get_idle_state - Get the power state a pwrdm will enter during idle
+ * @pwrdm: powerdomain to check state for
+ *
+ * Checks if the powerdomain can enter idle or not, if yes, will return
+ * the programmed target state for the domain. Otherwise will indicate
+ * that the domain will stay on.
+ * Returns the power state the pwrdm will enter.
+ */
+static int pwrdm_get_idle_state(struct powerdomain *pwrdm)
+{
+ if (pwrdm_can_idle(pwrdm))
+ return pwrdm_read_next_pwrst(pwrdm);
+ return PWRDM_POWER_ON;
+}
+
+/**
* omap3_enter_idle - Programs OMAP3 to enter the specified state
* @dev: cpuidle device
* @state: The target state to be programmed
@@ -153,14 +170,94 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
struct cpuidle_state *state)
{
struct cpuidle_state *new_state = state;
-
- if ((state-flags CPUIDLE_FLAG_CHECK_BM) omap3_idle_bm_check()) {
- BUG_ON(!dev-safe_state);
- new_state = dev-safe_state;
+ u32 per_state = 0, saved_per_state = 0, cam_state, usb_state;
+ u32 iva2_state, sgx_state, dss_state, new_core_state;
+ struct omap3_processor_cx *cx;
+ int ret;
+
+ if (state-flags CPUIDLE_FLAG_CHECK_BM) {
+ if (omap3_idle_bm_check()) {
+ BUG_ON(!dev-safe_state);
+ new_state = dev-safe_state;
+ goto select_state;
+ }
+ cx = cpuidle_get_statedata(state);
+ new_core_state = cx-core_state;
+
+ /* Check if CORE is active, if yes, fallback to inactive */
+ if (!pwrdm_can_idle(core_pd))
+ new_core_state = PWRDM_POWER_INACTIVE;
+
+ /*
+* Prevent idle completely if CAM is active.
+* CAM does not have wakeup capability in OMAP3.
+*/
+ cam_state = pwrdm_get_idle_state(cam_pd);
+ if (cam_state == PWRDM_POWER_ON) {
+ new_state = dev-safe_state;
+ goto select_state;
+ }
+
+ /*
+* Check if PER can idle or not. If we are not likely
+* to idle, deny PER off. This prevents unnecessary
+* context save/restore.
+*/
+ saved_per_state = pwrdm_read_next_pwrst(per_pd);
+ if (pwrdm_can_idle(per_pd)) {
+ per_state = saved_per_state;
+ /*
+* Prevent PER off if CORE is active as this
+* would disable PER wakeups completely
+*/
+ if (per_state == PWRDM_POWER_OFF
+ new_core_state PWRDM_POWER_RET)
+ per_state = PWRDM_POWER_RET;
+
+ } else if (saved_per_state == PWRDM_POWER_OFF)
+ per_state = PWRDM_POWER_RET;
+
+ /*
+* If we are attempting CORE off, check if any other
+* powerdomains are at retention or higher. CORE off causes
+* chipwide reset which would reset these domains also.
+*/
+ if (new_core_state == PWRDM_POWER_OFF) {
+ dss_state = pwrdm_get_idle_state(dss_pd);
+ iva2_state = pwrdm_get_idle_state(iva2_pd);
+ sgx_state = pwrdm_get_idle_state(sgx_pd);
+ usb_state =
[PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
From: Shweta Gulati shweta.gul...@ti.com
DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs
running DSP codec was earlier restricted as DSP crashed.
The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
The workaround is:
For DPLL2 (DSP) select CORECLK/4 as DPLL2 bypass clock for 3430.
Select CORECLK/2 as DPLL2 bypass clock for 3630.
During DPLL2 relock phase, DSP clock will be 83MHz/200MHz which is always OK
irrespective of Vdd1 voltage.
For DPLL1 (MPU), prior to any DVFS transition to OPP1, select CORECLK/4
(CORECLK/2 for 3630) as DPLL1 bypass clock.
For other OPPs select CORECLK/2 (CORECLK/1 for 3630) as DPLL1 bypass
clock.
These configurations are typically set in bootloader. However bootloaders may
mess up configuration and kernel with this chang ensures that system is in a
known state.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++--
arch/arm/mach-omap2/pm34xx.c | 19 +++
arch/arm/mach-omap2/resource34xx.c| 20
3 files changed, 41 insertions(+), 2 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/cm-regbits-34xx.h
mode change 100644 = 100755 arch/arm/mach-omap2/pm34xx.c
mode change 100644 = 100755 arch/arm/mach-omap2/resource34xx.c
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6f2802b..0cf9a5d
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -81,7 +81,7 @@
/* CM_CLKSEL1_PLL_IVA2 */
#define OMAP3430_IVA2_CLK_SRC_SHIFT19
-#define OMAP3430_IVA2_CLK_SRC_MASK (0x3 19)
+#define OMAP3430_IVA2_CLK_SRC_MASK (0x7 19)
#define OMAP3430_IVA2_DPLL_MULT_SHIFT 8
#define OMAP3430_IVA2_DPLL_MULT_MASK (0x7ff 8)
#define OMAP3430_IVA2_DPLL_DIV_SHIFT 0
@@ -126,7 +126,7 @@
/* CM_CLKSEL1_PLL_MPU */
#define OMAP3430_MPU_CLK_SRC_SHIFT 19
-#define OMAP3430_MPU_CLK_SRC_MASK (0x3 19)
+#define OMAP3430_MPU_CLK_SRC_MASK (0x7 19)
#define OMAP3430_MPU_DPLL_MULT_SHIFT 8
#define OMAP3430_MPU_DPLL_MULT_MASK(0x7ff 8)
#define OMAP3430_MPU_DPLL_DIV_SHIFT0
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c328164..f260072
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -802,6 +802,25 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
+ u32 cm_clksel1_mpu, cm_clksel1_iva2;
+
+ /*set Bypass clock dividers for MPU and IVA */
+ cm_clksel1_mpu = cm_read_mod_reg(MPU_MOD, CM_CLKSEL1);
+ cm_clksel1_iva2 = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSEL1);
+ if (cpu_is_omap3630()) {
+ cm_clksel1_iva2 = (cm_clksel1_iva2
~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+ (0x2 OMAP3430_IVA2_CLK_SRC_SHIFT);
+ cm_clksel1_mpu = (cm_clksel1_mpu
~(OMAP3430_MPU_CLK_SRC_MASK)) |
+ (0x1 OMAP3430_MPU_CLK_SRC_SHIFT);
+ } else if (cpu_is_omap34xx()) {
+ cm_clksel1_iva2 = (cm_clksel1_iva2
~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+ (0x4 OMAP3430_IVA2_CLK_SRC_SHIFT);
+ cm_clksel1_mpu = (cm_clksel1_mpu
~(OMAP3430_MPU_CLK_SRC_MASK)) |
+ (0x2 OMAP3430_MPU_CLK_SRC_SHIFT);
+ }
+ cm_write_mod_reg(cm_clksel1_iva2, OMAP3430_IVA2_MOD, CM_CLKSEL1);
+ cm_write_mod_reg(cm_clksel1_mpu, MPU_MOD, CM_CLKSEL1);
+
/* XXX Reset all wkdeps. This should be done when initializing
* powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 04be4d2..8c3f2b3
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -242,9 +242,29 @@ static int program_opp_freq(int res, int target_level, int
current_level)
{
int ret = 0, l3_div;
int *curr_opp;
+ u32 cm_clksel1_mpu;
lock_scratchpad_sem();
if (res == VDD1_OPP) {
+ if (target_level == VDD1_OPP1) {
+ cm_clksel1_mpu = cm_read_mod_reg(MPU_MOD, CM_CLKSEL1);
+ if (cpu_is_omap3630())
+ cm_clksel1_mpu = (cm_clksel1_mpu
~(OMAP3430_MPU_CLK_SRC_MASK)) |
+ (0x2
OMAP3430_MPU_CLK_SRC_SHIFT);
+ else if (cpu_is_omap34xx())
+ cm_clksel1_mpu = (cm_clksel1_mpu
~(OMAP3430_MPU_CLK_SRC_MASK)) |
+ (0x4
OMAP3430_MPU_CLK_SRC_SHIFT);
+
RE: [PATCH 0/8] OMAP clock: convert static definitions in header files to C files
Hi Paul,
Some patches in this series seem to be missing, specifically 5/8 and 6/8.
Can you please re-post?
regards,
Rajendra
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Thursday, December 03, 2009 3:37 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: [PATCH 0/8] OMAP clock: convert static definitions in
header files to C files
The OMAP clock code has traditionally defined its clock nodes
statically in header files (e.g., mach-omap1/clock.h). This violates
the general guideline that including a header file should be
side-effect free, or at least as side-effect free as possible. This
series moves all of the statically-allocated data from header files
into C files that are linked into kernels. It moves OPP data (or at
least the proto-OPP data in OMAP1 and OMAP2xxx) into separate files.
It also resolves all of the checkpatch errors that appear as a result
of the move.
This series has been boot-tested on OMAP1 (on a 5912 OSK),
OMAP2 (on N800 and
2430 SDP), and OMAP3 (BeagleBoard).
This series was prompted by a comment from Russell King
rmk+ker...@arm.linux.org.uk, who suggested the basic layout
that these
patches implement.
- Paul
---
size:
text data bss dec hex filename
3582959 199264 107176 3889399 3b58f7 vmlinux.beagle.orig
3583063 199264 107176 3889503 3b595f vmlinux.beagle
Paul Walmsley (8):
OMAP1/2/3 clock: remove paranoid checks in preparation
for clock{,2xxx,3xxx}_data.c
OMAP2 clock: APLL code shouldn't rely on static clocks
in its local namespace
OMAP2/3: move SDRC macros to mach-omap2/sdrc.h
OMAP2xxx clock: remove implicit dependency between rate
CPU flag and clkdev_omap CPU flag
OMAP3 clock: convert clock34xx.h to clock34xx_data.c
OMAP2 clock: convert clock24xx.h to clock2xxx_data.c, opp2xxx*
OMAP1 clock: convert test in disable_unused() to use
ENABLE_ON_INIT
OMAP1 clock: convert mach-omap1/clock.h to
mach-omap1/clock_data.c
arch/arm/mach-omap1/Makefile |3
arch/arm/mach-omap1/clock.c | 415 ---
arch/arm/mach-omap1/clock.h | 652 -
arch/arm/mach-omap1/clock_data.c | 443 +++-
arch/arm/mach-omap1/io.c |3
arch/arm/mach-omap1/opp.h | 28
arch/arm/mach-omap1/opp_data.c| 59
arch/arm/mach-omap2/Makefile |8
arch/arm/mach-omap2/clock.h | 30
arch/arm/mach-omap2/clock24xx.c | 805 ---
arch/arm/mach-omap2/clock2xxx.c | 564 +
arch/arm/mach-omap2/clock2xxx.h | 44
arch/arm/mach-omap2/clock2xxx_data.c | 844 ++-
arch/arm/mach-omap2/clock34xx.c | 471
arch/arm/mach-omap2/clock34xx.h | 3013
-
arch/arm/mach-omap2/clock34xx_data.c | 364 +++
arch/arm/mach-omap2/clock_common_data.c | 39
arch/arm/mach-omap2/opp2420_data.c| 126 +
arch/arm/mach-omap2/opp2430_data.c| 133 +
arch/arm/mach-omap2/opp2xxx.h | 424
arch/arm/mach-omap2/sdrc.h| 19
arch/arm/plat-omap/include/plat/clkdev_omap.h | 41
arch/arm/plat-omap/include/plat/clock.h |2
23 files changed, 2592 insertions(+), 5938 deletions(-)
copy arch/arm/mach-omap1/{clock.h = clock_data.c} (58%)
create mode 100644 arch/arm/mach-omap1/opp.h
create mode 100644 arch/arm/mach-omap1/opp_data.c
delete mode 100644 arch/arm/mach-omap2/clock24xx.c
create mode 100644 arch/arm/mach-omap2/clock2xxx.c
create mode 100644 arch/arm/mach-omap2/clock2xxx.h
rename arch/arm/mach-omap2/{clock24xx.h = clock2xxx_data.c} (73%)
copy arch/arm/mach-omap2/{clock34xx.h = clock34xx_data.c} (86%)
create mode 100644 arch/arm/mach-omap2/clock_common_data.c
create mode 100644 arch/arm/mach-omap2/opp2420_data.c
create mode 100644 arch/arm/mach-omap2/opp2430_data.c
create mode 100644 arch/arm/mach-omap2/opp2xxx.h
create mode 100644 arch/arm/plat-omap/include/plat/clkdev_omap.h
--
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 0/8] OMAP clock: convert static definitions in header files to C files
On Fri, Dec 04, 2009 at 03:35:21PM +0530, Nayak, Rajendra wrote: Some patches in this series seem to be missing, specifically 5/8 and 6/8. Can you please re-post? Probably because they're on the large side. -- 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: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
Hi Vishwanath,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
From: Shweta Gulati shweta.gul...@ti.com
DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs
running DSP codec was earlier restricted as DSP crashed.
The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
The workaround is:
For DPLL2 (DSP) select CORECLK/4 as DPLL2 bypass clock for 3430.
Select CORECLK/2 as DPLL2 bypass clock for 3630.
During DPLL2 relock phase, DSP clock will be 83MHz/200MHz which is always
OK
irrespective of Vdd1 voltage.
For DPLL1 (MPU), prior to any DVFS transition to OPP1, select CORECLK/4
(CORECLK/2 for 3630) as DPLL1 bypass clock.
For other OPPs select CORECLK/2 (CORECLK/1 for 3630) as DPLL1 bypass
clock.
I think that you should not rely on the OMAP version to select the correct
bypass freq. Both 3430 and 3630 can support CORECLK/2 at OPP50. CORECLK/4
should be used only if OPP25 is selected. The fact that OPP25 will not be
used on 3630 should not be captured here.
The divider selection should be only based on the OPP. It will work the same
way for all OMAP3 variants.
Regards,
Benoit
These configurations are typically set in bootloader. However bootloaders
may
mess up configuration and kernel with this chang ensures that system is in
a
known state.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++--
arch/arm/mach-omap2/pm34xx.c | 19 +++
arch/arm/mach-omap2/resource34xx.c| 20
3 files changed, 41 insertions(+), 2 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/cm-regbits-34xx.h
mode change 100644 = 100755 arch/arm/mach-omap2/pm34xx.c
mode change 100644 = 100755 arch/arm/mach-omap2/resource34xx.c
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-
omap2/cm-regbits-34xx.h
index 6f2802b..0cf9a5d
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -81,7 +81,7 @@
/* CM_CLKSEL1_PLL_IVA2 */
#define OMAP3430_IVA2_CLK_SRC_SHIFT 19
-#define OMAP3430_IVA2_CLK_SRC_MASK(0x3 19)
+#define OMAP3430_IVA2_CLK_SRC_MASK(0x7 19)
#define OMAP3430_IVA2_DPLL_MULT_SHIFT 8
#define OMAP3430_IVA2_DPLL_MULT_MASK (0x7ff 8)
#define OMAP3430_IVA2_DPLL_DIV_SHIFT 0
@@ -126,7 +126,7 @@
/* CM_CLKSEL1_PLL_MPU */
#define OMAP3430_MPU_CLK_SRC_SHIFT19
-#define OMAP3430_MPU_CLK_SRC_MASK (0x3 19)
+#define OMAP3430_MPU_CLK_SRC_MASK (0x7 19)
#define OMAP3430_MPU_DPLL_MULT_SHIFT 8
#define OMAP3430_MPU_DPLL_MULT_MASK (0x7ff 8)
#define OMAP3430_MPU_DPLL_DIV_SHIFT 0
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c328164..f260072
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -802,6 +802,25 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
+ u32 cm_clksel1_mpu, cm_clksel1_iva2;
+
+ /*set Bypass clock dividers for MPU and IVA */
+ cm_clksel1_mpu = cm_read_mod_reg(MPU_MOD, CM_CLKSEL1);
+ cm_clksel1_iva2 = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSEL1);
+ if (cpu_is_omap3630()) {
+ cm_clksel1_iva2 = (cm_clksel1_iva2
~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+ (0x2 OMAP3430_IVA2_CLK_SRC_SHIFT);
+ cm_clksel1_mpu = (cm_clksel1_mpu
~(OMAP3430_MPU_CLK_SRC_MASK)) |
+ (0x1 OMAP3430_MPU_CLK_SRC_SHIFT);
+ } else if (cpu_is_omap34xx()) {
+ cm_clksel1_iva2 = (cm_clksel1_iva2
~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+ (0x4 OMAP3430_IVA2_CLK_SRC_SHIFT);
+ cm_clksel1_mpu = (cm_clksel1_mpu
~(OMAP3430_MPU_CLK_SRC_MASK)) |
+ (0x2 OMAP3430_MPU_CLK_SRC_SHIFT);
+ }
+ cm_write_mod_reg(cm_clksel1_iva2, OMAP3430_IVA2_MOD, CM_CLKSEL1);
+ cm_write_mod_reg(cm_clksel1_mpu, MPU_MOD, CM_CLKSEL1);
+
/* XXX Reset all wkdeps. This should be done when initializing
* powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-
omap2/resource34xx.c
index 04be4d2..8c3f2b3
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -242,9 +242,29 @@ static int program_opp_freq(int res, int target_level,
int current_level)
{
int ret = 0, l3_div;
int *curr_opp;
+ u32 cm_clksel1_mpu;
lock_scratchpad_sem();
if (res == VDD1_OPP) {
+ if (target_level == VDD1_OPP1) {
+ cm_clksel1_mpu = cm_read_mod_reg(MPU_MOD, CM_CLKSEL1);
+
RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
Benoit
-Original Message-
From: Cousson, Benoit
Sent: Friday, December 04, 2009 3:46 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR
operation
Hi Vishwanath,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
From: Shweta Gulati shweta.gul...@ti.com
DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs
running DSP codec was earlier restricted as DSP crashed.
The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
The workaround is:
For DPLL2 (DSP) select CORECLK/4 as DPLL2 bypass clock for 3430.
Select CORECLK/2 as DPLL2 bypass clock for 3630.
During DPLL2 relock phase, DSP clock will be 83MHz/200MHz which is always
OK
irrespective of Vdd1 voltage.
For DPLL1 (MPU), prior to any DVFS transition to OPP1, select CORECLK/4
(CORECLK/2 for 3630) as DPLL1 bypass clock.
For other OPPs select CORECLK/2 (CORECLK/1 for 3630) as DPLL1 bypass
clock.
I think that you should not rely on the OMAP version to select the correct
bypass freq. Both 3430 and 3630 can support CORECLK/2 at OPP50. CORECLK/4
should be used only if OPP25 is selected. The fact that OPP25 will not be
used on 3630 should not be captured here.
The divider selection should be only based on the OPP. It will work the same
way for all OMAP3 variants.
The problem is in 3430, OPP1 is OPP25 where as in 3630 OPP1 is OPP50 (as OPP25
is removed). So in the code, we still have to distinguish between 3430 and 3630.
Regards,
Benoit
These configurations are typically set in bootloader. However bootloaders
may
mess up configuration and kernel with this chang ensures that system is in
a
known state.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++--
arch/arm/mach-omap2/pm34xx.c | 19 +++
arch/arm/mach-omap2/resource34xx.c| 20
3 files changed, 41 insertions(+), 2 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/cm-regbits-34xx.h
mode change 100644 = 100755 arch/arm/mach-omap2/pm34xx.c
mode change 100644 = 100755 arch/arm/mach-omap2/resource34xx.c
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-
omap2/cm-regbits-34xx.h
index 6f2802b..0cf9a5d
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -81,7 +81,7 @@
/* CM_CLKSEL1_PLL_IVA2 */
#define OMAP3430_IVA2_CLK_SRC_SHIFT 19
-#define OMAP3430_IVA2_CLK_SRC_MASK (0x3 19)
+#define OMAP3430_IVA2_CLK_SRC_MASK (0x7 19)
#define OMAP3430_IVA2_DPLL_MULT_SHIFT 8
#define OMAP3430_IVA2_DPLL_MULT_MASK(0x7ff 8)
#define OMAP3430_IVA2_DPLL_DIV_SHIFT0
@@ -126,7 +126,7 @@
/* CM_CLKSEL1_PLL_MPU */
#define OMAP3430_MPU_CLK_SRC_SHIFT 19
-#define OMAP3430_MPU_CLK_SRC_MASK (0x3 19)
+#define OMAP3430_MPU_CLK_SRC_MASK (0x7 19)
#define OMAP3430_MPU_DPLL_MULT_SHIFT8
#define OMAP3430_MPU_DPLL_MULT_MASK (0x7ff 8)
#define OMAP3430_MPU_DPLL_DIV_SHIFT 0
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c328164..f260072
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -802,6 +802,25 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
+u32 cm_clksel1_mpu, cm_clksel1_iva2;
+
+/*set Bypass clock dividers for MPU and IVA */
+cm_clksel1_mpu = cm_read_mod_reg(MPU_MOD, CM_CLKSEL1);
+cm_clksel1_iva2 = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSEL1);
+if (cpu_is_omap3630()) {
+cm_clksel1_iva2 = (cm_clksel1_iva2
~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+(0x2 OMAP3430_IVA2_CLK_SRC_SHIFT);
+cm_clksel1_mpu = (cm_clksel1_mpu
~(OMAP3430_MPU_CLK_SRC_MASK)) |
+(0x1 OMAP3430_MPU_CLK_SRC_SHIFT);
+} else if (cpu_is_omap34xx()) {
+cm_clksel1_iva2 = (cm_clksel1_iva2
~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+(0x4 OMAP3430_IVA2_CLK_SRC_SHIFT);
+cm_clksel1_mpu = (cm_clksel1_mpu
~(OMAP3430_MPU_CLK_SRC_MASK)) |
+(0x2 OMAP3430_MPU_CLK_SRC_SHIFT);
+}
+cm_write_mod_reg(cm_clksel1_iva2, OMAP3430_IVA2_MOD, CM_CLKSEL1);
+cm_write_mod_reg(cm_clksel1_mpu, MPU_MOD, CM_CLKSEL1);
+
/* XXX Reset all wkdeps. This should be done when initializing
* powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-
omap2/resource34xx.c
index
Re: [PATCH] PM: Prevent direct cpufreq scaling during initialization
Sergey Lapin wrote: On Thu, Dec 3, 2009 at 9:29 AM, Dasgupta, Romit ro...@ti.com wrote: Signed-off-by: Romit Dasgupta ro...@ti.com --- diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu- omap.c index 449b6b6..f94df20 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -149,8 +149,6 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) VERY_HI_RATE) / 1000; } - clk_set_rate(mpu_clk, policy-cpuinfo.max_freq * 1000); - policy-min = policy-cpuinfo.min_freq; policy-max = policy-cpuinfo.max_freq; policy-cur = omap_getspeed(0); This patch leads to hang with current PM branch, SRF and CPU IDLE enabled on OMAP3525 rev C. Verified this to work on Zoom2 + SRF + CPUidle. Can you give some debug info if possible? Well, that looks like false alarm - I tried clean tree without local patches, and it seems to work. However, without this line removed, my system boots faster. Is it possible to limit initial speed for unstable setups, but to boot as fast as possible? Thanks a lot, S. omap_cpufreq_init is a lateinitcall. So quite some part of the kernel startup happens with whatever speed the bootloader passes control to kernel initialization code. Only after we invoke omap_cpufreq_init will the cpufreq framework try to call the offending code 'clk_set_rate'. Quite soon after this the cpufreq default governor (whatever it is for your system, performance, ondemand etc) is initialized. If you choose performance governor it will immediately scale the frequency to the highest available for the system. So the way to boot fast would be a) make your bootcode scale the voltage + freq to support the highest cpu freq. and/or b) make performance governor the default. -- 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: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
From: Sripathy, Vishwanath
Benoit
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: Cousson, Benoit
Sent: Friday, December 04, 2009 3:46 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under
DVFS+SR
operation
Hi Vishwanath,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
From: Shweta Gulati shweta.gul...@ti.com
DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs
running DSP codec was earlier restricted as DSP crashed.
The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
The workaround is:
For DPLL2 (DSP) select CORECLK/4 as DPLL2 bypass clock for 3430.
Select CORECLK/2 as DPLL2 bypass clock for 3630.
During DPLL2 relock phase, DSP clock will be 83MHz/200MHz which is
always
OK
irrespective of Vdd1 voltage.
For DPLL1 (MPU), prior to any DVFS transition to OPP1, select CORECLK/4
(CORECLK/2 for 3630) as DPLL1 bypass clock.
For other OPPs select CORECLK/2 (CORECLK/1 for 3630) as DPLL1 bypass
clock.
I think that you should not rely on the OMAP version to select the
correct
bypass freq. Both 3430 and 3630 can support CORECLK/2 at OPP50. CORECLK/4
should be used only if OPP25 is selected. The fact that OPP25 will not be
used on 3630 should not be captured here.
The divider selection should be only based on the OPP. It will work the
same
way for all OMAP3 variants.
The problem is in 3430, OPP1 is OPP25 where as in 3630 OPP1 is OPP50 (as
OPP25 is removed). So in the code, we still have to distinguish between
3430 and 3630.
Yes, but you do not have to care about the OMAP version at that level. In case
of 3630, the OPP25 will be removed from the OPP table, so you'll just have to
care about the OPP level. The fact that the OPP25 is there or not should not be
handled here. For the moment, you can just check the target level.
If VDD1_OPP1 is selected then you divide the CORE by 4 otherwise you divide the
CORE by 2.
Ideally you should not even rely on the OPP, but on the frequency.
Keep in mind, that since the OPP layer is being completely rewritten by
Nishanth and Kevin, it will have to change at that time to adapt that to the
new API, and to a frequency based selection.
Regards,
Benoit
Regards,
Benoit
These configurations are typically set in bootloader. However
bootloaders
may
mess up configuration and kernel with this chang ensures that system is
in
a
known state.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++--
arch/arm/mach-omap2/pm34xx.c | 19 +++
arch/arm/mach-omap2/resource34xx.c| 20
3 files changed, 41 insertions(+), 2 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/cm-regbits-34xx.h
mode change 100644 = 100755 arch/arm/mach-omap2/pm34xx.c
mode change 100644 = 100755 arch/arm/mach-omap2/resource34xx.c
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-
omap2/cm-regbits-34xx.h
index 6f2802b..0cf9a5d
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -81,7 +81,7 @@
/* CM_CLKSEL1_PLL_IVA2 */
#define OMAP3430_IVA2_CLK_SRC_SHIFT19
-#define OMAP3430_IVA2_CLK_SRC_MASK (0x3 19)
+#define OMAP3430_IVA2_CLK_SRC_MASK (0x7 19)
#define OMAP3430_IVA2_DPLL_MULT_SHIFT 8
#define OMAP3430_IVA2_DPLL_MULT_MASK (0x7ff 8)
#define OMAP3430_IVA2_DPLL_DIV_SHIFT 0
@@ -126,7 +126,7 @@
/* CM_CLKSEL1_PLL_MPU */
#define OMAP3430_MPU_CLK_SRC_SHIFT 19
-#define OMAP3430_MPU_CLK_SRC_MASK (0x3 19)
+#define OMAP3430_MPU_CLK_SRC_MASK (0x7 19)
#define OMAP3430_MPU_DPLL_MULT_SHIFT 8
#define OMAP3430_MPU_DPLL_MULT_MASK(0x7ff 8)
#define OMAP3430_MPU_DPLL_DIV_SHIFT0
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c328164..f260072
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -802,6 +802,25 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
+ u32 cm_clksel1_mpu, cm_clksel1_iva2;
+
+ /*set Bypass clock dividers for MPU and IVA */
+ cm_clksel1_mpu = cm_read_mod_reg(MPU_MOD, CM_CLKSEL1);
+ cm_clksel1_iva2 = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSEL1);
+ if (cpu_is_omap3630()) {
+ cm_clksel1_iva2 = (cm_clksel1_iva2
~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+ (0x2 OMAP3430_IVA2_CLK_SRC_SHIFT);
+ cm_clksel1_mpu = (cm_clksel1_mpu
RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
-Original Message- From: Cousson, Benoit Sent: Friday, December 04, 2009 4:27 PM To: Sripathy, Vishwanath; linux-omap@vger.kernel.org Subject: RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation From: Sripathy, Vishwanath Benoit 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: Cousson, Benoit Sent: Friday, December 04, 2009 3:46 PM To: Sripathy, Vishwanath; linux-omap@vger.kernel.org Subject: RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation Hi Vishwanath, From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath From: Shweta Gulati shweta.gul...@ti.com DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs running DSP codec was earlier restricted as DSP crashed. The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2. The workaround is: For DPLL2 (DSP) select CORECLK/4 as DPLL2 bypass clock for 3430. Select CORECLK/2 as DPLL2 bypass clock for 3630. During DPLL2 relock phase, DSP clock will be 83MHz/200MHz which is always OK irrespective of Vdd1 voltage. For DPLL1 (MPU), prior to any DVFS transition to OPP1, select CORECLK/4 (CORECLK/2 for 3630) as DPLL1 bypass clock. For other OPPs select CORECLK/2 (CORECLK/1 for 3630) as DPLL1 bypass clock. I think that you should not rely on the OMAP version to select the correct bypass freq. Both 3430 and 3630 can support CORECLK/2 at OPP50. CORECLK/4 should be used only if OPP25 is selected. The fact that OPP25 will not be used on 3630 should not be captured here. The divider selection should be only based on the OPP. It will work the same way for all OMAP3 variants. The problem is in 3430, OPP1 is OPP25 where as in 3630 OPP1 is OPP50 (as OPP25 is removed). So in the code, we still have to distinguish between 3430 and 3630. Yes, but you do not have to care about the OMAP version at that level. In case of 3630, the OPP25 will be removed from the OPP table, so you'll just have to care about the OPP level. The fact that the OPP25 is there or not should not be handled here. For the moment, you can just check the target level. If VDD1_OPP1 is selected then you divide the CORE by 4 otherwise you divide the CORE by 2. For 3630 I feel keeping Bypass divider at 4 @ OPP1 and 2 for others is suboptimal given that MPU can run at CORECLK/2...@opp1 and CORECLK for other OPPs. When we can get better performance with a additional cost of couple of comparisons, I feel that's better (Note that MPU enters and comes out of standby very frequently in the system which means number of times MPU is fed with DPLL bypass clock is high compared to IVA. So it's better MPU is fed with higher bypass clock frequency. Ideally you should not even rely on the OPP, but on the frequency. Keep in mind, that since the OPP layer is being completely rewritten by Nishanth and Kevin, it will have to change at that time to adapt that to the new API, and to a frequency based selection. Regards, Benoit Regards, Benoit These configurations are typically set in bootloader. However bootloaders may mess up configuration and kernel with this chang ensures that system is in a known state. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++-- arch/arm/mach-omap2/pm34xx.c | 19 +++ arch/arm/mach-omap2/resource34xx.c| 20 3 files changed, 41 insertions(+), 2 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/cm-regbits-34xx.h mode change 100644 = 100755 arch/arm/mach-omap2/pm34xx.c mode change 100644 = 100755 arch/arm/mach-omap2/resource34xx.c diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach- omap2/cm-regbits-34xx.h index 6f2802b..0cf9a5d --- a/arch/arm/mach-omap2/cm-regbits-34xx.h +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h @@ -81,7 +81,7 @@ /* CM_CLKSEL1_PLL_IVA2 */ #define OMAP3430_IVA2_CLK_SRC_SHIFT 19 -#define OMAP3430_IVA2_CLK_SRC_MASK (0x3 19) +#define OMAP3430_IVA2_CLK_SRC_MASK (0x7 19) #define OMAP3430_IVA2_DPLL_MULT_SHIFT8 #define OMAP3430_IVA2_DPLL_MULT_MASK (0x7ff 8) #define OMAP3430_IVA2_DPLL_DIV_SHIFT 0 @@ -126,7 +126,7 @@ /* CM_CLKSEL1_PLL_MPU */ #define OMAP3430_MPU_CLK_SRC_SHIFT 19 -#define OMAP3430_MPU_CLK_SRC_MASK(0x3 19) +#define OMAP3430_MPU_CLK_SRC_MASK(0x7 19) #define OMAP3430_MPU_DPLL_MULT_SHIFT 8 #define
RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
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: Sripathy, Vishwanath -Original Message- From: Cousson, Benoit Sent: Friday, December 04, 2009 4:27 PM To: Sripathy, Vishwanath; linux-omap@vger.kernel.org Subject: RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation From: Sripathy, Vishwanath Benoit 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: Cousson, Benoit Sent: Friday, December 04, 2009 3:46 PM To: Sripathy, Vishwanath; linux-omap@vger.kernel.org Subject: RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation Hi Vishwanath, From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath From: Shweta Gulati shweta.gul...@ti.com DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs running DSP codec was earlier restricted as DSP crashed. The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2. The workaround is: For DPLL2 (DSP) select CORECLK/4 as DPLL2 bypass clock for 3430. Select CORECLK/2 as DPLL2 bypass clock for 3630. During DPLL2 relock phase, DSP clock will be 83MHz/200MHz which is always OK irrespective of Vdd1 voltage. For DPLL1 (MPU), prior to any DVFS transition to OPP1, select CORECLK/4 (CORECLK/2 for 3630) as DPLL1 bypass clock. For other OPPs select CORECLK/2 (CORECLK/1 for 3630) as DPLL1 bypass clock. I think that you should not rely on the OMAP version to select the correct bypass freq. Both 3430 and 3630 can support CORECLK/2 at OPP50. CORECLK/4 should be used only if OPP25 is selected. The fact that OPP25 will not be used on 3630 should not be captured here. The divider selection should be only based on the OPP. It will work the same way for all OMAP3 variants. The problem is in 3430, OPP1 is OPP25 where as in 3630 OPP1 is OPP50 (as OPP25 is removed). So in the code, we still have to distinguish between 3430 and 3630. Yes, but you do not have to care about the OMAP version at that level. In case of 3630, the OPP25 will be removed from the OPP table, so you'll just have to care about the OPP level. The fact that the OPP25 is there or not should not be handled here. For the moment, you can just check the target level. If VDD1_OPP1 is selected then you divide the CORE by 4 otherwise you divide the CORE by 2. Forget about using the OPP, the current code is too broken to allow that, except if you keep OPP25 in the 3630 table and prevent it at CPUFreq policy level. I'm not even sure it will be enough. You'd better wait for the new OPP layer before doing that. For 3630 I feel keeping Bypass divider at 4 @ OPP1 and 2 for others is suboptimal given that MPU can run at CORECLK/2...@opp1 and CORECLK for other OPPs. When we can get better performance with a additional cost of couple of comparisons, I feel that's better (Note that MPU enters and comes out of standby very frequently in the system which means number of times MPU is fed with DPLL bypass clock is high compared to IVA. So it's better MPU is fed with higher bypass clock frequency. You're right for the MPU; I was just giving an example for the DSP. In anycase you should provide the higher bypass clock available for each processor. Note that the bypass frequency of the processor in idle is not really relevant considering that the processor is not running, and potentially the DPLL will be stopped. It is just useful during DVFS sequence. In that case the DPLL will go to bypass automatically while the processor is running. Regards, Benoit Ideally you should not even rely on the OPP, but on the frequency. Keep in mind, that since the OPP layer is being completely rewritten by Nishanth and Kevin, it will have to change at that time to adapt that to the new API, and to a frequency based selection. Regards, Benoit Regards, Benoit These configurations are typically set in bootloader. However bootloaders may mess up configuration and kernel with this chang ensures that system is in a known state. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++-- arch/arm/mach-omap2/pm34xx.c | 19 +++ arch/arm/mach-omap2/resource34xx.c| 20 3 files changed, 41 insertions(+), 2 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/cm-regbits-34xx.h mode change 100644 = 100755 arch/arm/mach-omap2/pm34xx.c mode change 100644 = 100755 arch/arm/mach-omap2/resource34xx.c diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach- omap2/cm-regbits-34xx.h index 6f2802b..0cf9a5d ---
Re: [PATCH 3/4 v4] OMAP: McBSP: Introduce caching in register write operations
Janusz Krzysztofik napisał(a):
Thursday 03 December 2009 21:03:02 Tony Lindgren napisał(a):
Hi,
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091203 04:29]:
Reserve space inside omap_mcbsp structure for storing cached copies of
McBSP register values.
Modify the MCBSP_WRITE() macro to update the cache with every register
write operation.
Introduce a new macro that reads from the cache instead of hardware.
Applies on top of patch 2 from this series:
[PATCH v3 2/4] OMAP: McBSP: Prepare register read/write macros API for
caching
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
commit 4421752e331cfb1d942b47ffdb26e451a8da58a0.
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Thursday 03 December 2009 08:49:21 Jarkko Nikula wrote:
On Tue, 1 Dec 2009 04:15:50 +0100
Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote:
#define MCBSP_WRITE(mcbsp, reg, val) \
- omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, val)
+ omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, \
+ mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
+ = val)
+#define MCBSP_READ_CACHE(mcbsp, reg) \
+ (mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1])
These divisions by DDR1 are confusing. Use rather sizeof:
reg_cache[OMAP_MCBSP_REG_##reg / sizeof(*mcbsp-reg_cache)]
Done.
Jarkko, many thanks for your cooperation :).
Janusz
arch/arm/plat-omap/include/plat/mcbsp.h |5 +
arch/arm/plat-omap/mcbsp.c |7 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
--- git/arch/arm/plat-omap/include/plat/mcbsp.h.orig2009-11-27
11:53:45.0 +0100 +++
git/arch/arm/plat-omap/include/plat/mcbsp.h 2009-12-01 03:37:21.0
+0100 @@ -415,6 +415,11 @@ struct omap_mcbsp {
u16 max_tx_thres;
u16 max_rx_thres;
#endif
+#ifdef CONFIG_ARCH_OMAP1
+ u16 reg_cache[OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1];
+#else
+ u32 reg_cache[OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1];
+#endif
};
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count;
How about rather set:
static u16 omap1_reg_cache[];
and
static u32 omap2_reg_cache[];
Hi Tony,
Let me understand more precisely what you mean before I submit next version.
Did you mean something like:
static u16 omap1_reg_cache[3][OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1];
static u32 omap2_reg_cache[5][OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1];
both put in arch/arm/plat-omap/mcbsp.c without any ifdefs?
Tony,
I think I've already found one part of the answer myself: you probably
mean putting each table definition in a corresponding
arch/arm/mach-omap[12]/mcbsp.c source file, don't you?
What remains unclear for me is if you really intend to reserve static
cache space for all McBSP ports supported by a machine, even if not
supported by a particular cpu or not used on a particular board.
--- git/arch/arm/plat-omap/mcbsp.c.orig 2009-12-01 03:19:56.0
+0100 +++ git/arch/arm/plat-omap/mcbsp.c2009-12-03 11:37:21.0
+0100 @@ -49,7 +49,12 @@ int omap_mcbsp_read(void __iomem *io_bas
#define MCBSP_READ(mcbsp, reg) \
omap_mcbsp_read(mcbsp-io_base, OMAP_MCBSP_REG_##reg)
#define MCBSP_WRITE(mcbsp, reg, val) \
- omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, val)
+ omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, \
+ mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / \
+sizeof(*mcbsp-reg_cache)] = val)
+#define MCBSP_READ_CACHE(mcbsp, reg) \
+ (mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / \
+ sizeof(*mcbsp-reg_cache)])
#define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count)
#define id_to_mcbsp_ptr(id)mcbsp_ptr[id];
Then rather than doing this cache manipulation in the macro, just
do it in the omap_mcbsp_read/write functions based on the
cpu_class_is_omap1() accessing omap1_reg_cache or omap2_reg_cache.
omap_mcbsp_wrtie() case seems clear to me, but:
Did you mean defining a new omap_mcbsp_read_cache() function, similiar to
omap_mcbsp_read(), but reading from cache instead of hardware?
Or do you prefere if I modify omap_mcbsp_read() to be able to read from both
hardware and cache, dependig on an additional argument, for example?
Thanks,
Janusz
This way you can get rid of the ifdef else.
But shouldn't declarations for both tables be placed in
arch/arm/plat-omap/include/plat/mcbsp.h withing an ifdef else block? If
yes, one ifdef else block would be replaced with another. Or did you
mean placing those declarations inside existing ifdef block with defines
for register offsets?
Thanks,
Janusz
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
Re: [PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Hi all,
Please ignore previous patch, it has a compilation error.
Correct patch is present below.
-vimal
From e024a2e6aa2051259ad904daff13bdac73b3b1b8 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 142
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 154 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..0621e39
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,142 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+
+#include plat/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 8;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+
Re: [PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Ahh.. this is my bad.
[...]
+ err = gpmc_nand_setup((void __iomem *)
+ gpmc_nand_data-gpmc_cs_baseaddr);
we just do not need casting here.
Apologies for making noise and confusion.
Please take this one.
-vimal
From e024a2e6aa2051259ad904daff13bdac73b3b1b8 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 141
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..0621e39
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,141 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+
+#include plat/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 8;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev =
Re: [PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
This patch got line wrapped.
--
---
Regards,
Govindraj.R
On Fri, Dec 4, 2009 at 6:44 PM, Vimal Singh vimal.neww...@gmail.com wrote:
Ahh.. this is my bad.
[...]
+ err = gpmc_nand_setup((void __iomem *)
+ gpmc_nand_data-gpmc_cs_baseaddr);
we just do not need casting here.
Apologies for making noise and confusion.
Please take this one.
-vimal
From e024a2e6aa2051259ad904daff13bdac73b3b1b8 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 141
arch/arm/plat-omap/include/plat/nand.h | 6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2) := gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X) := gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..0621e39
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,141 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+
+#include plat/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 8;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+
[PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 141
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..0621e39
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,141 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+
+#include plat/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 8;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_nand_setup(gpmc_nand_data-gpmc_cs_baseaddr);
+ if (err 0) {
+ dev_err(dev, NAND platform setup failed: %d\n, err);
+
What's in omap git tree for 2.6.33
Hi all, We now have separate mach/omap include directories for mach-omap1 and mach-omap2. The common headers are now in plat/omap. The omap730 and omap850 support has been merged into omap7xx support. We've reclaimend more address space by separately mapping the L3 and L4 buses for mach-omap2. Also tons of PM updates for omap34xx processors, and support for various new omap3 variants such as omap3630 AM35xx. Initial mailbox support for omap4430. Support for new omap boards, such as HTC Herald, IGEP v2, CM-T35, 3630SDP, Zoom3 and AM3517 EVM. Regards, Tony The git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus Has the following changes: Aaro Koskinen (2): OMAP: PM: Clear DMA channel state after a wakeup OMAP3: PM: Fix INTC context save/restore Ajay Kumar Gupta (2): omap3evm: Add board revision function omap3evm: ehci: Update EHCI support on OMAP3EVM (Rev = E) Alexander Shishkin (1): omap: Eliminate OMAP_MAX_NR_PORTS Alistair Buxton (16): OMAP7XX: Serial: Remove duplicate omap850 code OMAP7XX: GPIO: Remove duplicate omap850 code OMAP7XX: IO: Remove duplicate omap850 code OMAP7XX: Mux: Remove duplicate omap850 code OMAP7XX: USB: Remove duplicate omap850 code OMAP7XX: IRQ: Remove duplicate omap850 code OMAP7XX: PM: Add omap850 support OMAP7XX: Clocks: Add omap850 support OMAP7XX: McBSP: Add omap850 support OMAP7XX: Create omap7xx.h OMAP7XX: Update core omap1 files to use omap7xx.h OMAP7XX: Replace omap730 references in irqs.h and all users OMAP7XX: Rename all the rest of the omap730 references in omap1 core OMAP7XX: omap_uwire.c: Convert to omap7xx.h OMAP850: PM: Add an ARCH_OMAP850 check OMAP850: Fix zImage booting Anand Gadiyar (2): omap: update plat/usb.h to allow ehci driver to build omap3: Update 3430SDP defconfig Angelo Arrifano (1): OMAP7XX: Clocks: Add ck_ref and armxor C A Subramaniam (6): omap: mailbox: Add build specific changes to support omap mailbox omap: mailbox: Add resources and mailbox register base address for OMAP4 mailbox omap: mailbox: remove unnecessary arg for omap_mbox_msg_send omap: mailbox: Adds code changes to support OMAP4 mailbox omap: mailbox: OMAP4 Mailbox Patch to change the IRQ flag from IRQF_DISABLED to IRQF_SHARED omap: mailbox: OMAP4 Mailbox-driver Patch to support tasklet implementation Charulatha V (1): omap: GPIO module enable/disable Cory Maccarrone (4): omap1: mmc: Add platform init for omap7xx omap1: omap_udc: Add clocking and disable vbus sense for omap7xx omap1: Add board support and LCD for HTC Herald omap1: Add default kernel configuration for Herald Enric Balletbo i Serra (2): omap3: Add minimal IGEP v2 support omap3: Add defconfig for IGEP v2 board Felipe Balbi (2): omap: Add platform init code for EHCI driver omap: Cleanup the coding style in id.c Felipe Contreras (1): omap: iommu: reorganize Hiroshi DOYU (6): omap: iommu: avoid remapping if it's been mapped in MPU side omap: iovmm: remove cache flush operation omap: mailbox: remove sequence bit checking omap: mailbox: remove class interface omap: mailbox: remove disable_/enable_mbox_irq in isr omap: mailbox: Expose omap_mbox_enable()/disable_irq() Jani Nikula (2): Input: add new keycodes useful in mobile devices ARM OMAP3: RX-51 board - add initialization of gpio keys Jouni Hogander (2): OMAP3: PM: Save and restore also CM_CLKSEL1_PLL_IVA2 OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle loop Juha Yrjola (1): OMAP: Store reboot mode in scratchpad on OMAP34xx Julia Lawall (1): arch/arm/plat-omap: Drop an unnecessary NULL test Kalle Jokiniemi (6): OMAP3: PM: Fix secure SRAM context save/restore ARM: OMAP: SMS: save/restore of SMS_SYSCONFIG for off-mode OMAP3: PM: Fix PLL_MOD CLKEN offset in scratchpad PM: Disable usb host HW save and restore OMAP3: PM: Enable IO-CHAIN wakeup OMAP3: PM: CPUidle: fix init sequencing Kalle Valo (1): omap3: rx51: Add wl1251 wlan driver support Kevin Hilman (6): OMAP3: PM debug: allow runtime toggle of PM features PM debug: allow configurable wakeup from suspend on OMAP GPtimer OMAP3: PM: decouple PER and CORE context save and restore OMAP3: PM: CPUidle: obey enable_off_mode flag OMAP3: PM: CPUidle: check activity for C2, C3, correct accounting omap3: keep SoC features on the same line Madhu (4): omap3630: Add HSMMC related checks omap3630: Configure HSMMC1 to 4-bit omap3630: Set omap3630 MMC1 I/O speed to 52Mhz omap3: HSMMC2 8-bit mux configuration Mike Rapoport (3): omap3evm: Initialize vmmc and vmmc_aux regulators omap3: Add CompuLab CM-T35 board
Re: [PATCH v2] omap: serial: fix non-empty uart fifo read abort
* Vikram Pandita vikram.pand...@ti.com [091203 15:27]:
OMAP3xxx and OMAP4430 UART IP blocks have a restriction wrt RX FIFO.
Empty RX fifo read causes an abort.
OMAP3xxx:
UART IP revision = 0x52 have this issue
MVR register format is:
Bits Field Name Description Type Reset
31:8 RESERVED RO 0x0
7:4MAJORMajor revision number of the module.RO 0x--
3:0MINORMinor revision number of the module.RO 0x--
OMAP4xxx:
All revisions have this issue
Revision id check is not used as the format of MVR resigster has changed
For omap4 MVR register reads as: 0x50410602 = Revision id = 0x0602
Format of MVR register on omap4 is: (Courtesy: Cousson, Benoit)
Bits Field Name Description Type Reset
31:30 SCHEMEScheme revision number of moduleRO 0x1
29:28 RESERVED RO 0x1
27:16 FUNC Function revision number of module RO 0x041
15:11 RTL Rtl revision number of module RO 0x00
10:8 MAJOR Major revision number of the module.RO 0x6
7:6 CUSTOMCustom revision number of the module. RO 0x0
5:0 MINOR Minor revision number of the module.RO 0x02
Override the default 8250 read handler: mem_serial_in()
by a custom handler: serial_in_8250()
which makes sure that RX fifo is not read when empty
tested on zoom3(3630) board
Cc: Cousson, Benoit b-cous...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
History of Patch:
V1:
http://patchwork.kernel.org/patch/61671/
http://patchwork.kernel.org/patch/61672/
V2: Incorporate approach suggested by Tony L
Introduce IP version check in mach-omap2/serial.c file
arch/arm/mach-omap2/serial.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 2e17b57..bd646a2 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -33,6 +33,7 @@
#include pm.h
#include prm-regbits-34xx.h
+#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV 0x52
#define UART_OMAP_WER0x17/* Wake-up enable register */
#define DEFAULT_TIMEOUT (5 * HZ)
@@ -572,6 +573,23 @@ static struct omap_uart_state omap_uart[] = {
#endif
};
+/*
+ * Override the default 8250 read handler: mem_serial_in()
+ * Empty RX fifo read causes an abort on omap3630 and omap4
+ * This function makes sure that an empty rx fifo is not read on these
silicons
+ * (OMAP1/2/3 are not affected)
+ */
+static unsigned int serial_in_override(struct uart_port *up, int offset)
+{
+ if (UART_RX == offset) {
+ unsigned int lsr;
+ lsr = serial_read_reg(omap_uart[up-line].p, UART_LSR);
+ if (!(lsr UART_LSR_DR))
+ return -EPERM;
+ }
+ return serial_read_reg(omap_uart[up-line].p, offset);
+}
+
void __init omap_serial_early_init(void)
{
int i;
@@ -650,5 +668,16 @@ void __init omap_serial_init(void)
device_init_wakeup(dev, true);
DEV_CREATE_FILE(dev, dev_attr_sleep_timeout);
}
+
+#ifdef CONFIG_ARCH_OMAP4
+ /* Never read empty UART fifo on omap4 */
+ p-serial_in = serial_in_override;
+#else
+ /* OMAP2/3 */
+ /* Never read empty UART fifo on UARTs with IP rev =0x52 */
+ if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
+ = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart-p-serial_in = serial_in_override;
+#endif
}
}
We need to avoid ifdef else stuff, that just causes problems compiling
in support for many omaps. In theory, we should be able to compile in
support for all omaps starting with 16xx with v5 options..
Using cpu_is_omap() should do the trick here.
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]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
* Vishwanath BS vishwanath...@ti.com [091204 01:20]: From: Shweta Gulati shweta.gul...@ti.com DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs running DSP codec was earlier restricted as DSP crashed. The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2. The workaround is: For DPLL2 (DSP) select CORECLK/4 as DPLL2 bypass clock for 3430. Select CORECLK/2 as DPLL2 bypass clock for 3630. During DPLL2 relock phase, DSP clock will be 83MHz/200MHz which is always OK irrespective of Vdd1 voltage. For DPLL1 (MPU), prior to any DVFS transition to OPP1, select CORECLK/4 (CORECLK/2 for 3630) as DPLL1 bypass clock. For other OPPs select CORECLK/2 (CORECLK/1 for 3630) as DPLL1 bypass clock. These configurations are typically set in bootloader. However bootloaders may mess up configuration and kernel with this chang ensures that system is in a known state. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++-- arch/arm/mach-omap2/pm34xx.c | 19 +++ arch/arm/mach-omap2/resource34xx.c| 20 3 files changed, 41 insertions(+), 2 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/cm-regbits-34xx.h mode change 100644 = 100755 arch/arm/mach-omap2/pm34xx.c mode change 100644 = 100755 arch/arm/mach-omap2/resource34xx.c This mode change stuff does not look right. 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 v2] omap: serial: fix non-empty uart fifo read abort
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, December 04, 2009 1:04 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org; Cousson, Benoit Subject: Re: [PATCH v2] omap: serial: fix non-empty uart fifo read abort snip + +#ifdef CONFIG_ARCH_OMAP4 +/* Never read empty UART fifo on omap4 */ +p-serial_in = serial_in_override; +#else +/* OMAP2/3 */ +/* Never read empty UART fifo on UARTs with IP rev =0x52 */ +if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF) += UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) +uart-p-serial_in = serial_in_override; +#endif } } We need to avoid ifdef else stuff, that just causes problems compiling in support for many omaps. In theory, we should be able to compile in support for all omaps starting with 16xx with v5 options.. Using cpu_is_omap() should do the trick here. The intent was to have check entirely based of UART IP revision. That worked fine for omap3xxx. But omap4 has totally different IP revision register (as per commit message) But I can see the point, and v3 of patch I can replace: #ifdef CONFIG_ARCH_OMAP4 by cpu_is_omap44xx() I tried following what was done in current serial.c file of many #ifdef CONFIG_ARCH_OMAP4 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 3/4 v4] OMAP: McBSP: Introduce caching in register write operations
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091204 04:56]: Janusz Krzysztofik napisał(a): snip I think I've already found one part of the answer myself: you probably mean putting each table definition in a corresponding arch/arm/mach-omap[12]/mcbsp.c source file, don't you? Well I did not initially, but sounds like that's the cleanest way to go. What remains unclear for me is if you really intend to reserve static cache space for all McBSP ports supported by a machine, even if not supported by a particular cpu or not used on a particular board. No idea :) But please consider what happens if we want to compile in omap2 + omap3 into a single binary. Or what happens if some newer omaps add more McBSP registers. snip Did you mean defining a new omap_mcbsp_read_cache() function, similiar to omap_mcbsp_read(), but reading from cache instead of hardware? Yeah something like that. That is more future proof. Or do you prefere if I modify omap_mcbsp_read() to be able to read from both hardware and cache, dependig on an additional argument, for example? That actually sounds like the best way to solve it to me! But shouldn't declarations for both tables be placed in arch/arm/plat-omap/include/plat/mcbsp.h withing an ifdef else block? If yes, one ifdef else block would be replaced with another. Or did you mean placing those declarations inside existing ifdef block with defines for register offsets? Ifdefs are OK if they just optimize out code when some omap is not compiled in. But if you do ifdef else, then it means trouble sooner or later. In this case you should probably have the cache initialized separately in mach-omap1/mcbsp.c and mach-omap2/mcbsp.c. 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 v2] omap: serial: fix non-empty uart fifo read abort
Pandita, Vikram said the following on 12/04/2009 09:15 PM: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, December 04, 2009 1:04 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org; Cousson, Benoit Subject: Re: [PATCH v2] omap: serial: fix non-empty uart fifo read abort snip + +#ifdef CONFIG_ARCH_OMAP4 + /* Never read empty UART fifo on omap4 */ + p-serial_in = serial_in_override; +#else + /* OMAP2/3 */ + /* Never read empty UART fifo on UARTs with IP rev =0x52 */ + if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF) + = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) + uart-p-serial_in = serial_in_override; +#endif } } We need to avoid ifdef else stuff, that just causes problems compiling in support for many omaps. In theory, we should be able to compile in support for all omaps starting with 16xx with v5 options.. Using cpu_is_omap() should do the trick here. The intent was to have check entirely based of UART IP revision. That worked fine for omap3xxx. But omap4 has totally different IP revision register (as per commit message) But I can see the point, and v3 of patch I can replace: #ifdef CONFIG_ARCH_OMAP4 by cpu_is_omap44xx() I tried following what was done in current serial.c file of many #ifdef CONFIG_ARCH_OMAP4 a cleanup patch could be welcome as well :) 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 -- 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 v3 1/3] input:misc:driver support for Kionix kxte9 accelerometer
Hello all, Are there any comments for this driver? Do I need to re-submit? Please let me know. Thank you, Chris chud...@kionix.com wrote: From: Chris Hudson chud...@kionix.com This is a request for comments regarding adding driver support for the Kionix KXTE9 digital tri-axis accelerometer. This part features built-in tilt position (orientation), wake-up and back-to-sleep algorithms, which can trigger a user-configurable physical interrupt. The driver uses i2c for device communication, input nodes for reporting acceleration data and interrupt status information, and sysfs for userspace communication. Changes in this version: *added odr_table description *removed global misc structure *removed extraneous retries from i2c read and write functions *removed extraneous variable assignments *removed extraneous gpio_get_value conditional in irq_work function *combined data formatting lines in get_acceleration_data *migrated all ioctls to sysfs *removed validate_pdata function *renamed input_dev from accelerometer to kxte9_accel *switched to use kernel workqueue instead of creating a new one *added some documentation to kxte9.h Signed-off-by: Chris Hudson chud...@kionix.com --- drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile |1 + drivers/input/misc/kxte9.c | 910 +++ include/linux/kxte9.h | 95 + 4 files changed, 1016 insertions(+), 0 deletions(-) create mode 100644 drivers/input/misc/kxte9.c create mode 100644 include/linux/kxte9.h diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index a9bb254..a1afad1 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -317,4 +317,14 @@ config INPUT_PCAP To compile this driver as a module, choose M here: the module will be called pcap_keys. +config INPUT_KXTE9 + tristate Kionix KXTE9 digital tri-axis accelerometer + depends on I2C + help + If you say yes here you get support for the Kionix KXTE9 digital + tri-axis accelerometer. + + This driver can also be built as a module. If so, the module + will be called kxte9. + endif diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index a8b8485..67cae95 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_DM355EVM) += dm355evm_keys.o obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o +obj-$(CONFIG_INPUT_KXTE9) += kxte9.o obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o diff --git a/drivers/input/misc/kxte9.c b/drivers/input/misc/kxte9.c new file mode 100644 index 000..6e1962e --- /dev/null +++ b/drivers/input/misc/kxte9.c @@ -0,0 +1,910 @@ +/* + * Copyright (C) 2009 Kionix, Inc. + * Written by Chris Hudson chud...@kionix.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + * 02111-1307, USA + */ + +#include linux/err.h +#include linux/errno.h +#include linux/delay.h +#include linux/fs.h +#include linux/i2c.h +#include linux/input.h +#include linux/uaccess.h +#include linux/workqueue.h +#include linux/irq.h +#include linux/gpio.h +#include linux/interrupt.h +#include linux/kxte9.h + +#define NAME kxte9 +#define G_MAX 2000 +/* OUTPUT REGISTERS */ +#define XOUT 0x12 +#define INT_STATUS_REG 0x16 +#define INT_SRC_REG2 0x17 +#define TILT_POS_CUR 0x10 +#define TILT_POS_PRE 0x11 +#define INT_REL0x1A +/* CONTROL REGISTERS */ +#define CTRL_REG1 0x1B +#define CTRL_REG3 0x1D +#define INT_CTRL1 0x1E +#define TILT_TIMER 0x28 +#define WUF_TIMER 0x29 +#define B2S_TIMER 0x2A +#define WUF_THRESH 0x5A +#define B2S_THRESH 0x5B +/* CONTROL REGISTER 1 BITS */ +#define PC1_OFF0x00 +#define PC1_ON 0x80 +/* INTERRUPT SOURCE 1 BITS */ +#define TPS0x01 +#define WUFS 0x02 +#define B2SS 0x04 +/* INPUT_ABS
Re: [PATCH] omap3: zoom2/3: make MMC slot work again
On Wed, Nov 18, 2009 at 07:09:10PM +0530, Anand Gadiyar wrote: omap3: zoom2/3: make MMC slot work again Commit 12f8dfb56 accidentally broke MMC on zoom2/3. The .vmmc1 field of zoom_twldata was deleted. Restoring it allows the MMC slot to work again Hmm. This was posted 2 weeks ago and not applied yet. Tony? It regresses zoom2/3. Patchwork link: http://patchwork.kernel.org/patch/61013/ -Olof -- 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 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Hi,
Looks good, just one comment below.
* Govindraj.R govindraj.r...@ti.com [091204 05:37]:
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 141
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
snip
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
snip
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_nand_setup(gpmc_nand_data-gpmc_cs_baseaddr);
+ if (err 0) {
+ dev_err(dev, NAND platform setup failed: %d\n, err);
+ return err;
+ }
+
+ /* Enable RD PIN Monitoring Reg */
+ if (gpmc_nand_data-dev_ready) {
+ val = gpmc_cs_read_reg(gpmc_nand_data-cs,
+ GPMC_CS_CONFIG1);
+ val |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(gpmc_nand_data-cs,
+ GPMC_CS_CONFIG1, val);
+ }
Above looks OK..
+ val = gpmc_cs_read_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG7);
+ val = ~(0xf 8);
+ val |= (0xc 0xf) 8;
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG7, val);
..but this looks messy. Maybe use some GPMC defines for the
0xf 8 mask?
Then the 0xc 0xf part looks a bit redundant, what's the 0xf
there for?
I know it's all from the old code, but might as well clean it up
while at it :)
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
[APPLIED] [PATCH] omap3: zoom2/3: make MMC slot work again
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next-vol2 Initial commit ID (Likely to change): f75bfe73652315f984829aff15ea8f76a7970ff8 PatchWorks http://patchwork.kernel.org/patch/61013/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=f75bfe73652315f984829aff15ea8f76a7970ff8 -- 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 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
Hi,
* Vimal Singh vimal.neww...@gmail.com [091203 06:09]:
From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Thu, 26 Nov 2009 16:10:24 +0530
Subject: [PATCH] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
This patch adds 'board-sdp-flash.c', which could be utilized
by boards similar to 3430SDP. (For ex: 2430sdp, 36030sdp).
This file does initialization for all three flash devices present
in SDP boards (NOR, NAND, OneNAND), by finding there 'cs' number
dynamically using switch setting information (S8: 1-4).
This also expects partition information from core board files (for
ex: board-3430sdp.c). Which allows to choose different default
partitions for different boards.
A new structure is created for this purpose: 'flash_partitions'
in 'mach/board-sdp.h'. This has two members:
1. struct mtd_partition *parts
2. int nr_parts
A board file is expected to fill this structure and pass it to
'sdp-flsash-init'. Partition information should be passed in
structure array of 'flash_partitions'. Partition information should
be passed in below sequence in array:
NOR
OneNAND
NAND
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-sdp-flash.c| 246
++
arch/arm/mach-omap2/include/mach/board-sdp.h | 22 +++
arch/arm/plat-omap/include/plat/gpmc.h |2 +
3 files changed, 270 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c
create mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h
diff --git a/arch/arm/mach-omap2/board-sdp-flash.c
b/arch/arm/mach-omap2/board-sdp-flash.c
new file mode 100644
index 000..fbbcd0e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
snip
+__init board_nand_init(struct flash_partitions sdp_nand_parts, u8 cs)
+{
+ sdp_nand_data.cs= cs;
+ sdp_nand_data.parts = sdp_nand_parts.parts;
+ sdp_nand_data.nr_parts = sdp_nand_parts.nr_parts;
+
+ sdp_nand_data.gpmc_cs_baseaddr = (void *)(OMAP34XX_GPMC_VIRT +
+ GPMC_CS0_BASE +
+ cs * GPMC_CS_SIZE);
+ sdp_nand_data.gpmc_baseaddr = (void *) (OMAP34XX_GPMC_VIRT);
+
+ gpmc_nand_init(sdp_nand_data);
+}
This does not look right. You're supposed to use gpmc_cs_request()
for allocating the GPMC area based on the chip select and size.
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -27,6 +27,8 @@
#define GPMC_CONFIG 0x50
#define GPMC_STATUS 0x54
+#define GPMC_CS0_BASE0x60
+#define GPMC_CS_SIZE 0x30
The GPMC_CS0_BASE and GPMC_CS_SIZE seem to be values specic to
your board, not for the GPMC hardware.
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 1/4]: OMAP: ZOOM: Introducing 'board-zoom-flash.c' for NAND init in ZOOM boards
* Grazvydas Ignotas nota...@gmail.com [091203 08:05]:
On Thu, Dec 3, 2009 at 4:15 PM, Vimal Singh vimal.neww...@gmail.com wrote:
From 948584f4157a9eb99ba085968d23add28cbfd160 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 1 Dec 2009 11:36:56 +0530
Subject: [PATCH] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
This patch adds 'board-zoom-flash.c', which could be utilized
by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
So it's not really zoom specific, i.e. can be used by other boards
with NAND like beagleboard and pandora? If that's the case, perhaps
the file could be named something like omap3-nand.c or simply just
nand.c .
This does initialization for NAND device based on the 'cs' number
and partition information passed from board file (ex: board-zoom2.c).
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-zoom-flash.c | 59
+
arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +
2 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
b/arch/arm/mach-omap2/board-zoom-flash.c
new file mode 100644
index 000..b3e66ca
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-flash.c
snip
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int
cs)
+{
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ zoom_nand_data.cs = cs;
+ zoom_nand_data.parts = zoom_nand_parts[0].parts;
+ zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
+ zoom_nand_data.gpmc_baseaddr = (void *)(gpmc_base_add);
+ zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
+ GPMC_CS0_BASE +
+ cs * GPMC_CS_SIZE);
+ gpmc_nand_init(zoom_nand_data);
+}
And here too you should use gpmc_cs_request().
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
[APPLIED] [PATCH] Fix include problem. Signed-off-by: Marek Belisko
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: master Initial commit ID (Likely to change): 3929b04e6e48d1294376eac04e47bb7cdf6a085d PatchWorks http://patchwork.kernel.org/patch/64520/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=3929b04e6e48d1294376eac04e47bb7cdf6a085d -- 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] Fix include problem. Signed-off-by: Marek Belisko marek.beli...@gmail.com
* Cory Maccarrone darkstar6...@gmail.com [091203 07:28]: On Thu, Dec 3, 2009 at 5:28 AM, Belisko Marek marek.beli...@gmail.com wrote: Hi, when make htcherald_defconfig on current linux-omap tree (82f1d8f22f2c65e70206e40a6f17688bf64a892c) compilation fails in drivers/video/omap/lcd_htcherald.c. Following patch fixed this problem. Marek and I talked on IRC about this, and it turns out this is true on the linux-omap master branch, but for-next compiles without issue, possibly due to the header changes not having been done on the master branch yet. Looks like Tomi's DSS2 moved this around. The DSS2 code is merged into linux-omap master branch, but is not in omap for-next branch. I've applied this to linux-omap master branch for now. Tomi, can you please add this to your fixes queue? The patch in question is at: http://patchwork.kernel.org/patch/64520/ 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 v2] OMAP: DMA: move LCD related code from plat-omap to mach-omap1
* Paul Walmsley p...@pwsan.com [091129 22:44]: On Fri, 27 Nov 2009, Janusz Krzysztofik wrote: All of the LCD DMA code in plat-omap/dma.c appears to be OMAP1-only (and apparently only is available on a subset of OMAP1 chips). Looks good. Reviewed-by: Paul Walmsley p...@pwsan.com Tony, you want to take this one? Yes, adding to for-next-vol2 branch. 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
[APPLIED] [PATCH 1/3] [OMAP1] MUX: Add omap7xx-specific USB mux pins
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next-vol2 Initial commit ID (Likely to change): fde592f136f1bb5861121272a2530b781922936a PatchWorks http://patchwork.kernel.org/patch/62077/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=fde592f136f1bb5861121272a2530b781922936a -- 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
[APPLIED] [PATCH 2/3] [OMAP] USB: Add omap7xx-specific pin muxing
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next-vol2 Initial commit ID (Likely to change): dd1a4ddb989eded52aac34a85cea2f2b122fbc84 PatchWorks http://patchwork.kernel.org/patch/62078/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=dd1a4ddb989eded52aac34a85cea2f2b122fbc84 -- 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
[APPLIED] [PATCH 3/3] [OMAP] HTCHERALD: Add USB configuration to HTC Herald
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next-vol2 Initial commit ID (Likely to change): adbfd7019b24673f8d8210d610b10ac7bd3fad30 PatchWorks http://patchwork.kernel.org/patch/62079/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=adbfd7019b24673f8d8210d610b10ac7bd3fad30 -- 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
[APPLIED] [PATCH] [OMAP1] use gen_nand
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next-vol2 Initial commit ID (Likely to change): d6ebf3557861e5d023e11e027cd321b5e39f885b PatchWorks http://patchwork.kernel.org/patch/62142/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=d6ebf3557861e5d023e11e027cd321b5e39f885b -- 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
[APPLIED] [PATCH] OMAP3: id code detection 3525 vs 3515
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next-vol2 Initial commit ID (Likely to change): a216a2003b1822b3262510b575d65994013ece58 PatchWorks http://patchwork.kernel.org/patch/62207/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=a216a2003b1822b3262510b575d65994013ece58 -- 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] omap: serial: fix non-empty uart fifo read abort
OMAP3xxx and OMAP4430 UART IP blocks have a restriction wrt RX FIFO.
Empty RX fifo read causes an abort.
OMAP3xxx:
UART IP revision = 0x52 have this issue
MVR register format is:
Bits Field Name Description Type Reset
31:8 RESERVED RO 0x0
7:4MAJORMajor revision number of the module.RO 0x--
3:0MINORMinor revision number of the module.RO 0x--
OMAP4xxx:
All revisions have this issue
Revision id check is not used as the format of MVR resigster has changed
For omap4 MVR register reads as: 0x50410602 = Revision id = 0x0602
Format of MVR register on omap4 is: (Courtesy: Cousson, Benoit)
Bits Field Name Description Type Reset
31:30 SCHEMEScheme revision number of moduleRO 0x1
29:28 RESERVED RO 0x1
27:16 FUNC Function revision number of module RO 0x041
15:11 RTL Rtl revision number of module RO 0x00
10:8 MAJOR Major revision number of the module.RO 0x6
7:6 CUSTOMCustom revision number of the module. RO 0x0
5:0 MINOR Minor revision number of the module.RO 0x02
Override the default 8250 read handler: mem_serial_in()
by a custom handler: serial_in_8250()
which makes sure that RX fifo is not read when empty
tested on zoom3(3630) board
Cc: Cousson, Benoit b-cous...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
History of Patch:
V1:
http://patchwork.kernel.org/patch/61671/
http://patchwork.kernel.org/patch/61672/
V2: Incorporate approach suggested by Tony L
Introduce IP version check in mach-omap2/serial.c file
V3: Change #ifdef OMAP4 to cpu_is_omap44xx()
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 2e17b57..e853115 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -33,6 +33,7 @@
#include pm.h
#include prm-regbits-34xx.h
+#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
#define UART_OMAP_WER 0x17/* Wake-up enable register */
#define DEFAULT_TIMEOUT (5 * HZ)
@@ -572,6 +573,23 @@ static struct omap_uart_state omap_uart[] = {
#endif
};
+/*
+ * Override the default 8250 read handler: mem_serial_in()
+ * Empty RX fifo read causes an abort on omap3630 and omap4
+ * This function makes sure that an empty rx fifo is not read on these silicons
+ * (OMAP1/2/3430 are not affected)
+ */
+static unsigned int serial_in_override(struct uart_port *up, int offset)
+{
+ if (UART_RX == offset) {
+ unsigned int lsr;
+ lsr = serial_read_reg(omap_uart[up-line].p, UART_LSR);
+ if (!(lsr UART_LSR_DR))
+ return -EPERM;
+ }
+ return serial_read_reg(omap_uart[up-line].p, offset);
+}
+
void __init omap_serial_early_init(void)
{
int i;
@@ -650,5 +668,15 @@ void __init omap_serial_init(void)
device_init_wakeup(dev, true);
DEV_CREATE_FILE(dev, dev_attr_sleep_timeout);
}
+
+ /* omap44xx: Never read empty UART fifo
+* omap3xxx: Never read empty UART fifo on UARTs
+* with IP rev =0x52
+*/
+ if (cpu_is_omap44xx())
+ uart-p-serial_in = serial_in_override;
+ else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
+ = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart-p-serial_in = serial_in_override;
}
}
--
1.6.6.rc0.66.ge160d
--
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
