Re: [PATCHv9 00/18] omap PRCM chain handler
Hi Valdis.Kletnieks, On Sat, Sep 24, 2011 at 3:53 AM, valdis.kletni...@vt.edu wrote: On Fri, 23 Sep 2011 15:46:08 +0300, Tero Kristo said: Following set contains the version 9 of this work. This patch set contains a number of patches tagged as 'TEMP', they are only meant for testing purposes and to provide proof of concept. Most of the 'TEMP' patches are related to UART runtime handling and they will be replaced by work done by Govindraj Raja. What do we do with these TEMP patches if the UART patches don't make the same merge window, or have other issues? I'm always leery of will be replaced code, because I've seen too many times when it *didn't* get replaced. (I really don't care what the 'Plan B' is, as long as we have one...) UART Runtime patches are already posted for review and it's also targeted for next merge window. Our intention is to push both the features together for next merge window. Regards Vishwa ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, October 05, 2010 8:48 PM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org; Premi, Sanjeev Subject: Re: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset On Tue, 5 Oct 2010, Vishwanath BS wrote: This patch adds comments on precatution to be taken if Global Warm reset is used as the means to trigger sysem reset. Signed-off-by: Vishwanath BS vishwanath...@ti.com Cc: Paul Walmsley p...@pwsan.com Thanks, queued for 2.6.38 with Sanjeev's spelling fix. Do you intend to merge this patch for 2.6.38? I did not see this in your pull request. Vishwa - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy
Nishant, On Fri, Nov 19, 2010 at 7:24 AM, Nishanth Menon n...@ti.com wrote: From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Errata i581 impacts OMAP3 platforms. PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing the DPLL not to be locked at times. IMPORTANT: this is not a complete workaround implementation as recommended by the silicon errata. this is a support logic for detecting lockups and attempting to recover where possible and is known to provide stability in multiple platforms. How does this WA work when Core enters off mode? SRAM contents are lost when Core enters off. So how this code is copied to SRAM upon wakeup? Where is this code placed when Core entered off mode? Vishwa Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com --- arch/arm/mach-omap2/sleep34xx.S | 52 +++--- 1 files changed, 47 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 8f207b2..5a4468f 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -42,6 +42,7 @@ OMAP3430_PM_PREPWSTST) #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) +#define CM_IDLEST_CKGEN_V OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST) #define SRAM_BASE_P 0x4020 #define CONTROL_STAT 0x480022F0 #define SCRATCHPAD_MEM_OFFS 0x310 /* Move this as correct place is @@ -554,31 +555,67 @@ skip_l2_inval: /* Make sure SDRC accesses are ok */ wait_sdrc_ok: + +/* DPLL3 must be locked before accessing the SDRC. Maybe the HW ensures this. */ + ldr r4, cm_idlest_ckgen +wait_dpll3_lock: + ldr r5, [r4] + tst r5, #1 + beq wait_dpll3_lock + ldr r4, cm_idlest1_core +wait_sdrc_ready: ldr r5, [r4] - and r5, r5, #0x2 - cmp r5, #0 - bne wait_sdrc_ok + tst r5, #0x2 + bne wait_sdrc_ready + /* allow DLL powerdown upon hw idle req */ ldr r4, sdrc_power ldr r5, [r4] bic r5, r5, #0x40 str r5, [r4] -wait_dll_lock: +is_dll_in_lock_mode: + /* Is dll in lock mode? */ ldr r4, sdrc_dlla_ctrl ldr r5, [r4] tst r5, #0x4 bxne lr /* wait till dll locks */ - ldr r4, sdrc_dlla_status +wait_dll_lock_timed: + ldr r4, wait_dll_lock_counter + add r4, r4, #1 + str r4, wait_dll_lock_counter + ldr r4, sdrc_dlla_status + mov r6, #8 /* Wait 20uS for lock */ +wait_dll_lock: + subs r6, r6, #0x1 + beq kick_dll ldr r5, [r4] and r5, r5, #0x4 cmp r5, #0x4 bne wait_dll_lock bx lr + /* disable/reenable DLL if not locked */ +kick_dll: + ldr r4, sdrc_dlla_ctrl + ldr r5, [r4] + mov r6, r5 + bic r6, #(13) /* disable dll */ + str r6, [r4] + dsb + orr r6, r6, #(13) /* enable dll */ + str r6, [r4] + dsb + ldr r4, kick_counter + add r4, r4, #1 + str r4, kick_counter + b wait_dll_lock_timed + cm_idlest1_core: .word CM_IDLEST1_CORE_V +cm_idlest_ckgen: + .word CM_IDLEST_CKGEN_V sdrc_dlla_status: .word SDRC_DLLA_STATUS_V sdrc_dlla_ctrl: @@ -615,5 +652,10 @@ control_stat: .word CONTROL_STAT kernel_flush: .word v7_flush_dcache_all + /* these 2 words need to be at the end !!! */ +kick_counter: + .word 0 +wait_dll_lock_counter: + .word 0 ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy
Nishant, On Wed, Nov 24, 2010 at 10:54 PM, Nishanth Menon n...@ti.com wrote: Sripathy, Vishwanath had written, on 11/24/2010 10:51 AM, the following: On Fri, Nov 19, 2010 at 7:24 AM, Nishanth Menon n...@ti.com wrote: From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Errata i581 impacts OMAP3 platforms. PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing the DPLL not to be locked at times. IMPORTANT: this is not a complete workaround implementation as recommended by the silicon errata. this is a support logic for detecting lockups and attempting to recover where possible and is known to provide stability in multiple platforms. How does this WA work when Core enters off mode? SRAM contents are lost when Core enters off. So how this code is copied to SRAM upon wakeup? Where is this code placed when Core entered off mode? It depends on the location of wait_sdram_ok - ideally speaking yep, you are right the current wait_sdram_ok for OFF makes no sense at all as it wakes off the ddr. For retention though, it makes sense. after the discussion we had on Jean's series http://marc.info/?t=12853255524r=1w=2, I am pretty sure that refactor that Jean is doing will help us clean this mess up. Then I do not find any need to keep this code in SRAM as we anyway know that it does not help when Core enters off mode. As you know already, in Jean's ASM clean up code, we are moving all these ASM code to DDR. Vishwa Maybe we can refactor this as part of Jean's cleanups. Vishwa Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com --- arch/arm/mach-omap2/sleep34xx.S | 52 +++--- 1 files changed, 47 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 8f207b2..5a4468f 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -42,6 +42,7 @@ OMAP3430_PM_PREPWSTST) #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) +#define CM_IDLEST_CKGEN_V OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST) #define SRAM_BASE_P 0x4020 #define CONTROL_STAT 0x480022F0 #define SCRATCHPAD_MEM_OFFS 0x310 /* Move this as correct place is @@ -554,31 +555,67 @@ skip_l2_inval: /* Make sure SDRC accesses are ok */ wait_sdrc_ok: + +/* DPLL3 must be locked before accessing the SDRC. Maybe the HW ensures this. */ + ldr r4, cm_idlest_ckgen +wait_dpll3_lock: + ldr r5, [r4] + tst r5, #1 + beq wait_dpll3_lock + ldr r4, cm_idlest1_core +wait_sdrc_ready: ldr r5, [r4] - and r5, r5, #0x2 - cmp r5, #0 - bne wait_sdrc_ok + tst r5, #0x2 + bne wait_sdrc_ready + /* allow DLL powerdown upon hw idle req */ ldr r4, sdrc_power ldr r5, [r4] bic r5, r5, #0x40 str r5, [r4] -wait_dll_lock: +is_dll_in_lock_mode: + /* Is dll in lock mode? */ ldr r4, sdrc_dlla_ctrl ldr r5, [r4] tst r5, #0x4 bxne lr /* wait till dll locks */ - ldr r4, sdrc_dlla_status +wait_dll_lock_timed: + ldr r4, wait_dll_lock_counter + add r4, r4, #1 + str r4, wait_dll_lock_counter + ldr r4, sdrc_dlla_status + mov r6, #8 /* Wait 20uS for lock */ +wait_dll_lock: + subs r6, r6, #0x1 + beq kick_dll ldr r5, [r4] and r5, r5, #0x4 cmp r5, #0x4 bne wait_dll_lock bx lr + /* disable/reenable DLL if not locked */ +kick_dll: + ldr r4, sdrc_dlla_ctrl + ldr r5, [r4] + mov r6, r5 + bic r6, #(13) /* disable dll */ + str r6, [r4] + dsb + orr r6, r6, #(13) /* enable dll */ + str r6, [r4] + dsb + ldr r4, kick_counter + add r4, r4, #1 + str r4, kick_counter + b wait_dll_lock_timed + cm_idlest1_core: .word CM_IDLEST1_CORE_V +cm_idlest_ckgen: + .word CM_IDLEST_CKGEN_V sdrc_dlla_status: .word SDRC_DLLA_STATUS_V sdrc_dlla_ctrl: @@ -615,5 +652,10 @@ control_stat: .word CONTROL_STAT kernel_flush: .word v7_flush_dcache_all + /* these 2 words need to be at the end !!! */ +kick_counter: + .word 0 +wait_dll_lock_counter: + .word 0 ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend -- 1.6.3.3 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
NIshant,
On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon n...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Thursday, November 18, 2010 8:52 AM
To: linux-omap@vger.kernel.org
Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
Sorry, But I disagree with this patch.
There is a silicon errata which cannot be handled with this - RTA disable
- errata i608
You need to disable RTA while coming out of OFF - we cannot handle this on
GP devices if this is not done.
When you come out of Core off, SRAM contents are anyway lost. So you
have to run from DDR after ROM Code completes. This behavior has not
changed with this patch. I fail to understand your concern here.
Vishwa
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Changed the commit comments.
Cc: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..035ca47 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -65,8 +65,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -346,9 +344,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -422,7 +417,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
/* Restore normal SDRC POWER settings */
@@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain
*clkdm, void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram =
omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] McBSP: Fix the free variable update at remove.
Shubro, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Datta, Shubhrajyoti Sent: Friday, October 29, 2010 4:19 AM To: linux-omap@vger.kernel.org Cc: Pandita, Vikram; Datta, Shubhrajyoti; ABRAHAM, KISHON VIJAY Subject: [PATCH] McBSP: Fix the free variable update at remove. From: Shubhrajyoti D shubhrajy...@ti.com At remove the free variable is wrongly updated.Attempting to solve the same. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Reported-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index eac4b97..6802ed1 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -1845,7 +1845,7 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev) mcbsp-fclk = NULL; mcbsp-iclk = NULL; - mcbsp-free = 0; + mcbsp-free = 1; Isn't it better to use TRUE/FALSE instead of 1/0 if it's a Boolean variable? Vishwa mcbsp-dev = NULL; } -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 2/2] OMAP3: CPUidle: trigger early idle notification call chain
Kevin,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Thursday, October 21, 2010 5:09 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: [RFC/PATCH 2/2] OMAP3: CPUidle: trigger early idle notification call
chain
During the early part of the CPUidle path (state selection by the
governer, checking for device activity, etc.) there is no (good)
reason to have interrupts disabled.
Therefore, enable interrupts early in the CPUidle path and then
trigger the early idle notifier call chain after device activity
checks and the next power states have been programmed. Interrupts are
then (re)disabled after the final state is selected.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 27 --
-
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
omap2/cpuidle34xx.c
index 0d50b45..8c57360 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -30,6 +30,7 @@
#include plat/powerdomain.h
#include plat/clockdomain.h
#include plat/serial.h
+#include plat/common.h
#include pm.h
#include control.h
@@ -128,12 +129,14 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
/* Used to keep track of the total time in idle */
getnstimeofday(ts_preidle);
- local_irq_disable();
- local_fiq_disable();
-
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
+ omap_early_idle_notifier_start();
+
+ local_irq_disable();
+ local_fiq_disable();
+
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
@@ -157,6 +160,8 @@ return_sleep_time:
local_irq_enable();
local_fiq_enable();
+ omap_early_idle_notifier_end();
It appears that idle notifiers (for restore path) are called after
getnstimeofday is called which means time spent in idle callbacks are not
accounted in cpuidle time.
Will it not impact the cpuidle c state prediction and latency computation?
Regards
Vishwa
+
return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
}
@@ -459,6 +464,21 @@ struct cpuidle_driver omap3_idle_driver = {
.owner =THIS_MODULE,
};
+static int omap3_idle_prepare(struct cpuidle_device *dev)
+{
+ /*
+ * Enable interrupts during the early part of the CPUidle path.
+ * They are later (re)disabled when the final state is selected.
+ *
+ * The primary reason for this is to enable non-atomic idle
+ * notifications to drivers that want to coordinate device
+ * idle transitions with CPU idle transitions.
+ */
+ local_irq_enable();
+
+ return 0;
+}
+
/**
* omap3_idle_init - Init routine for OMAP3 idle
*
@@ -482,6 +502,7 @@ int __init omap3_idle_init(void)
dev = per_cpu(omap3_idle_dev, smp_processor_id());
+ dev-prepare = omap3_idle_prepare;
for (i = OMAP3_STATE_C1; i OMAP3_MAX_STATES; i++) {
cx = omap3_power_states[i];
state = dev-states[count];
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3 PM: sleep code clean up
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, September 25, 2010 1:35 AM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org
Subject: Re: [PATCH 2/2] OMAP3 PM: sleep code clean up
Vishwanath BS vishwanath...@ti.com writes:
This patch has done some clean up of omap3 sleep code.
Basically all possible hardcodings are removed and code is Reorganized
into more logical buckets for better readability and instrumentation.
Tested on ZOOM3.
Again, please describe more about how it was tested. idle? suspend?
retention? off?
This has been tested for both RET and OFF mode in Idle and suspend path. Will
update the change log for the same.
Also please fix long-line checkpatch warnings.
OK.
While breaking this up in to subroutines, why not just call them all
from the C-code instead of assembly?
I thought about that. But unfortunately, while saving CPU registers (in
save_context_wfi), LR also gets saved. So if I call wfi routine
(omap34xx_do_wfi ) from C code itself, then LR would have pointed to
omap34xx_do_wfi while saving
the registers which is not correct.
But this also makes me wonder, if we're going to clean this up, the bulk
of it could be re-written in C, with some inline asm helpers as needed.
Probably yes. But as this code is specific to OMAP3, do you think it's worth
spending time on rewriting the entire code in C? It might be a significant
effort and it will not be reusable for other ARM SOCs.
Vishwa
Kevin
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Cc: Linaro linaro-...@lists.linaro.org
---
arch/arm/mach-omap2/sleep34xx.S | 377 ++---
arch/arm/plat-omap/include/plat/control.h |2 +
2 files changed, 189 insertions(+), 190 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
omap2/sleep34xx.S
index ba53191..734f82a
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -33,17 +33,20 @@
#include prm.h
#include sdrc.h
-#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c
+#define SDRC_SCRATCHPAD_SEM_OFFS 0xc
+#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR \
+
(SDRC_SCRATCHPAD_SEM_OFFS)
#define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \
- OMAP3430_PM_PREPWSTST)
-#define PM_PREPWSTST_CORE_P0x48306AE8
+ OMAP3430_PM_PREPWSTST)
+#define PM_PREPWSTST_CORE_POMAP3430_PRM_BASE + CORE_MOD + \
+
OMAP3430_PM_PREPWSTST
#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \
OMAP3430_PM_PREPWSTST)
#define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD +
OMAP2_PM_PWSTCTRL
#define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD,
CM_IDLEST1)
-#define SRAM_BASE_P0x4020
-#define CONTROL_STAT 0x480022F0
+#define SRAM_BASE_P0x4020
+#define CONTROL_STAT OMAP343X_CTRL_BASE +
OMAP343X_CONTROL_STATUS
#define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is
* available */
#define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE +
OMAP343X_CONTROL_MEM_WKUP\
@@ -184,29 +187,16 @@ api_params:
ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
-/*
- * Forces OMAP into idle state
- *
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
- *
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- * wakes up it continues execution at the point it went to sleep.
- */
-ENTRY(omap34xx_cpu_suspend)
+/* Function to execute WFI. When the MPU wakes up from retention
+ * or inactive mode, it continues execution just after wfi */
fix multi-line comment style
+ENTRY(omap34xx_do_wfi)
stmfd sp!, {r0-r12, lr} @ save registers on stack
-loop:
- /*b loop*/ @Enable to debug by stepping through code
- /* r0 contains restore pointer in sdram */
- /* r1 contains information about saving context */
+
ldr r4, sdrc_power @ read the SDRC_POWER register
ldr r5, [r4]@ read the contents of SDRC_POWER
orr r5, r5, #0x40 @ enable self refresh on idle req
str r5, [r4]@ write back to SDRC_POWER register
- cmp r1, #0x0
- /* If context save is required, do that and execute wfi */
- bne save_context_wfi
/* Data memory barrier and Data sync barrier */
mov r1, #0
mcr p15, 0, r1, c7, c10, 4
@@ -225,8 +215,182 @@ loop:
nop
nop
bl
RE: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, September 25, 2010 1:28 AM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org
Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
Vishwanath BS vishwanath...@ti.com writes:
There is no need to keep omap3 sleep code in SRAM.
This code can be run very well on DDR.
/me remains skeptical
This would help us to instrument CPUIdle latencies.
Indeed, but...
I'm afraid we will need a much more descriptive changelog here,
describing in detail why this will still work, and what about the
previous motiviations for running SRAM has changed such that this will
work out of SRAM.
Running the code from SRAM for CPUIdle was more of legacy from OMAP2 and there
was no technical reason why it cannot be run from DDR. Also note that, once MPU
enters off mode, wake up code used to run from DDR earlier (w/o these changes)
as well. I will put more details in the change log.
Tested on ZOOM3.
Tested in what way? This path is used for both idle and suspend, and
needs to be validated for retention and off mode.
I have tested for both retention and off mode in both CPU idle and suspend
path. I will update the changelog in next version.
Vishwa
Kevin
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Cc: Linaro linaro-...@lists.linaro.org
---
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 85ef245..ed9d12c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -79,8 +79,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -360,9 +358,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -438,7 +433,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
if (is_suspending())
@@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain
*clkdm,
void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram =
omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
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: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, September 22, 2010 6:37 AM To: Sripathy, Vishwanath Cc: Reddy, Teerth; linux-omap@vger.kernel.org Subject: RE: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset Hello Vishwa, Thanks for the info. a few quick questions: On Thu, 16 Sep 2010, Sripathy, Vishwanath wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, September 16, 2010 3:05 AM On Tue, 25 May 2010, Reddy, Teerth wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, May 19, 2010 6:03 AM To: Reddy, Teerth On Fri, 23 Apr 2010, Reddy, Teerth wrote: From: Teerth Reddy tee...@ti.com This patch has the workaround for errata 1.176. What's the current status of this patch? Still waiting for an updated version. We have realized that this errata is not applicable if reset is triggered via dpll3 reset. The rootcasuse of the issues was that incase of warm reset, SDRC is not sensitive to the warm reset, but the interconect is reset on the fly, thus causing a misalignment between SDRC logic, interconect logic and DDR memory state. Hence the workaround was proposed. However, incase of dpll3 reset, sdrc also gets reset. In omap_prcm_arch_reset, system reset is triggered via dpll3 reset, so this WA is not applicable. 1. So by warm reset, are you referring to the software warm reset triggered by GLOBAL_SW_RST, or by another mechanism? Yes, warm reset by means of GLOBAL_SW_RST. 2. If GLOBAL_SW_RST, what do you think about adding a brief comment in the code warning people not to use GLOBAL_SW_RST unless they implement the Errata 1.176 sequence? Yes, a note can be added. I will send a patch with this comment. Vishwa - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3630 PM: Update C state latencies
Hi Sanjeev,
-Original Message-
From: Premi, Sanjeev
Sent: Friday, September 17, 2010 7:57 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Cc: Sripathy, Vishwanath; Chalhoub, Nicole
Subject: RE: [PATCH] OMAP3630 PM: Update C state latencies
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Vishwanath BS
Sent: Friday, September 17, 2010 7:43 PM
To: linux-omap@vger.kernel.org
Cc: Sripathy, Vishwanath; Chalhoub, Nicole
Subject: [PATCH] OMAP3630 PM: Update C state latencies
This patch has changes to update the C state latencies for OMAP3630
and removes the useless C-States, keeping only the optimized
ones with
their corresponding measured latencies.
Only 4 C-states are kept instead of 7 C-States:
* C1 . MPU WFI clock gated + Core autogating
* C3 . MPU CSWR + Core inactive
* C5 . MPU CSWR + Core CSWR
* C7 . MPU OFF + Core OFF
A new C-State C1 is created which is the same as the
existing C1 but clocks
gated. It will be the default state. When calling the safe
state, the clocks
gating is denied as it was the case previously. With these
changes, gain is
in power consumption is observed on some use cases.
Thanks to Nicole Chaloubn-chalh...@ti.com and Vincent Bour
v-b...@ti.com
for their investigation.
Tested on ZOOM3 board using latest pm branch.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Nicole Chalhoub n-chalh...@ti.com
---
arch/arm/mach-omap2/board-zoom3.c | 19 +++
arch/arm/mach-omap2/cpuidle34xx.c |9 ++---
2 files changed, 25 insertions(+), 3 deletions(-)
[sp] Are these latencies board specific?
Same question for applicability of C-States.
Just wanted to understand if the same patch will/
applies for other boards using 36x as well.
Latency has 2 components associated with it namely SW sleep and wake up
latencies and HW sleep and wkup latencies. I believe that HW sleep and wkup
latency would be pretty same across various OMAP36xx platforms.
However I am not sure if the SW latency will also be similar across different
variants of 36xx since they might have different memory parts impacting DDR
access time. As long as SW execution time is similar, I think these values/C
states can be reused across.
Vishwa
~sanjeev
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 03411b2..c47b2a3 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -25,10 +25,28 @@
#include mux.h
#include sdram-hynix-h8mbx00u0mer-0em.h
#include smartreflex-class3.h
+#include pm.h
static struct omap_board_config_kernel zoom_config[] __initdata = {
};
+static struct cpuidle_params omap3_cpuidle_params_table[] = {
+ /* C1 */
+ {1, 74, 78, 152},
+ /* C2 */
+ {0, 165, 90, 255},
+ /* C3 */
+ {1, 163, 180, 345},
+ /* C4 */
+ {0, 2852, 605, 3457},
+ /* C5 */
+ {1, 800, 366, 2120},
+ /* C6 */
+ {0, 4080, 801, 4881},
+ /* C7 */
+ {1, 4300, 8794, 159000},
+};
+
static struct mtd_partition zoom_nand_partitions[] = {
/* All the partition sizes are listed in terms of NAND
block size */
{
@@ -74,6 +92,7 @@ static void __init omap_zoom_init_irq(void)
{
omap_board_config = zoom_config;
omap_board_config_size = ARRAY_SIZE(zoom_config);
+ omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..2bbfc43 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -136,7 +136,8 @@ 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) {
+ /* deny idle only if we are entering safe state */
+ if (dev-last_state != state) {
pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
}
@@ -144,7 +145,7 @@ static int omap3_enter_idle(struct
cpuidle_device *dev,
/* Execute ARM wfi */
omap_sram_idle();
- if (cx-type == OMAP3_STATE_C1) {
+ if (dev-last_state != state) {
pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
}
@@ -233,14 +234,16 @@ static int omap3_enter_idle_bm(struct
cpuidle_device *dev,
struct cpuidle_state *state)
{
struct cpuidle_state *new_state = next_valid_state(dev, state);
+ int t;
if ((state-flags CPUIDLE_FLAG_CHECK_BM)
omap3_idle_bm_check
RE: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, September 16, 2010 3:05 AM To: Reddy, Teerth Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath Subject: RE: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset Teerth, Vishwa, On Tue, 25 May 2010, Reddy, Teerth wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, May 19, 2010 6:03 AM To: Reddy, Teerth Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath Subject: Re: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset On Fri, 23 Apr 2010, Reddy, Teerth wrote: From: Teerth Reddy tee...@ti.com This patch has the workaround for errata 1.176. What's the current status of this patch? Still waiting for an updated version. We have realized that this errata is not applicable if reset is triggered via dpll3 reset. The rootcasuse of the issues was that incase of warm reset, SDRC is not sensitive to the warm reset, but the interconect is reset on the fly, thus causing a misalignment between SDRC logic, interconect logic and DDR memory state. Hence the workaround was proposed. However, incase of dpll3 reset, sdrc also gets reset. In omap_prcm_arch_reset, system reset is triggered via dpll3 reset, so this WA is not applicable. Regards Vishwa - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Hi Jean, -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Monday, September 06, 2010 9:53 PM To: Sripathy, Vishwanath Cc: Shilimkar, Santosh; Amit Kucheria; Kevin Hilman; linaro-...@lists.linaro.org; linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Vishwa, On Mon, Sep 6, 2010 at 1:15 PM, Sripathy, Vishwanath vishwanath...@ti.com wrote: I did some profiling of assembly code on OMAP3630 board (ZOOM3). In worst case it takes around 3.28ms and best case around 2.93ms for mpu off mode. Can you give a bit more details? Which measurement has been taken (ASM only, sleep, wake-up ...?) and what are the significant figures? Measurement has been done for save (as part of sleep sequence) and restore routine (part of wake up sequence) in assembly code. The above number indicates total time spent in save and restore of ARM context. For MPU INACTIVE/RET, it is less than 30us. Mmh that is the resolution of the 32kHz timer, so I guess you get either 0 or 1 timer cycle depending when you start the measurement. IMO the 32kHz timer is too slow to measure those fast events. Yes I agree. When we use trace events, I believe it would be more accurate as it is based on ARM perf counters. Vishwa However as Kevin mentioned in other email, it would be better to find out a way to trace inside assembly code as well. OK that could be done but first I would like to make sure such a complication is needed. Regards Vishwa Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Jean, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jean Pihet Sent: Thursday, September 02, 2010 2:39 PM To: Shilimkar, Santosh Cc: Amit Kucheria; Kevin Hilman; linaro-...@lists.linaro.org; linux- o...@vger.kernel.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Amit, Santosh, On Thu, Sep 2, 2010 at 10:11 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: ... The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. Kevin, I agree. We discussed this a little in our weekly meeting. Vishwa's main concern was the lack of ability to instrument the last bit of SRAM code. I have a feeling that even with caches on when we enter this code, we won't see too much variance in the latency to execute this bit of code. Vishwa is going to confirm that now. If that hypothesis is true, we can indeed move to using tracepoints in the idle path and use external tools to track latency. I agree. Can you confirm this asap? I did some profiling of assembly code on OMAP3630 board (ZOOM3). In worst case it takes around 3.28ms and best case around 2.93ms for mpu off mode. For MPU INACTIVE/RET, it is less than 30us. However as Kevin mentioned in other email, it would be better to find out a way to trace inside assembly code as well. Regards Vishwa I am looking at the instrumentation tracepoints now. I think it would be ideal to provide multiple tracepoints in both sleep and wake-up paths. There will be difference with and without caches but the delta latency will be constant with caches and without caches. Another important point is he lowest level code should be just profiled once and for worst CPU/BUS clock speed. Ok. Even if it isn't true, the rest of the idle path could still contain tracepoints. I am looking at the best way to introduce tracepoints in the low level code, in case it is needed. I also think this would be better approach considering a generic solution. Good! Regards, Santosh Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] I2C: Fix for suspend/resume issue in i2c-core
-Original Message-
From: Jean Delvare [mailto:kh...@linux-fr.org]
Sent: Wednesday, September 01, 2010 2:11 PM
To: Rafael J. Wysocki
Cc: Mark Brown; Kevin Hilman; Sripathy, Vishwanath; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org; Basak, Partha; Ben Dooks
Subject: Re: [PATCH] I2C: Fix for suspend/resume issue in i2c-core
On Wed, 1 Sep 2010 01:12:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, August 31, 2010, Mark Brown wrote:
On Mon, Aug 30, 2010 at 11:43:23AM -0700, Kevin Hilman wrote:
Vishwanath BS vishwanath...@ti.com writes:
In current i2c core driver, pm_runtime_set_active call from
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from
i2c_device_pm_suspend.
pm_runtime_set_active called from resume path will increase the
child_count of
the device's parent. However, matching pm_runtime_set_suspended is not
called
in suspend routine because of which child_count of the device's parent
is not balanced, preventing the parent device to idle.
Issue has been fixed by adding pm_runtime_set_suspended call inside
suspend
reoutine which will make sure that child_counts are balanced.
This fix has been tested on OMAP4430.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
Also Cc'ing Mark Brown as original author of runtime PM for i2-core.
Also Jean Delvare who maintains the I2C core. To be honest Rafael did
all the actual work here (and has since rewritten the code anyway).
Sorry for the delay.
The fix looks reasonable to me.
I take this as an Acked-by. Patch applied, thanks.
Hi,
We are seeing one more issue even after making this fix. In summary, after
first suspend/resume, CPU Idle no longer works since i2c module is active.
Basically when the system resumed from the suspend, dpm layer (dpm_resume_end)
calls device_resume which intern calls i2c_device_pm_resume (among many other
calls).
i2c_device_pm_resume calls pm_runtime_set_active which brings device to Active
state and increases child_count of it's parent. Since the device is active and
also it's parent child_count is non 0, these modules will prevent corresponding
clock domains to go idle. This will break CPU Idle. This issue happens even if
the module was in idle state before performing suspend/resume. In summary, the
flow is
1. i2c module is idle (let's assume system is idle)
2. system suspend is initiated by user
3. i2c_device_pm_suspend gets called which tries to idle i2c, but it's already
idled.
4. system is suspended
5. system resumed (because of user event/timers)
6. dpm layer will call i2c_device_pm_resume
7. i2c_device_pm_resume will enable i2c device by calling pm_runtime_set_active
So at the end of suspend/resume, a device that was idled before is getting
enabled unnecessarily at the end.
SO I am just wondering is there any real need to call pm_runtime_set_active in
resume and pm_runtime_set_suspened in suspend functions?
I just tried suspend/resume and CPU Idle after removing these calls in i2c and
it seems to function perfectly fine on OMAP4.
Regards
Vishwa
I
---
drivers/i2c/i2c-core.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 6649176..3146bff
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -196,14 +196,22 @@ static int i2c_legacy_resume(struct device *dev)
static int i2c_device_pm_suspend(struct device *dev)
{
const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm :
NULL;
+ int ret;
if (pm_runtime_suspended(dev))
return 0;
if (pm)
- return pm-suspend ? pm-suspend(dev) : 0;
+ ret = pm-suspend ? pm-suspend(dev) : 0;
+ else
+ ret = i2c_legacy_suspend(dev, PMSG_SUSPEND);
- return i2c_legacy_suspend(dev, PMSG_SUSPEND);
+ if (!ret) {
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+ }
+ return ret;
}
static int i2c_device_pm_resume(struct device *dev)
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP PM: MPU/DMA Latency constraints
Kevin, Paul,
Do you have any comments on this patch?
Regards
Vishwa
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
Sent: Tuesday, August 10, 2010 10:43 AM
To: Kevin Hilman
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH] OMAP PM: MPU/DMA Latency constraints
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, August 09, 2010 11:59 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP PM: MPU/DMA Latency constraints
Vishwanath Sripathy vishwanath...@ti.com writes:
This patch has implementation for OMAP MPU/DMA Latency constraints using
PM
QOS.
Changelog is missing description of the problem being solved and the
motivation for the solution.
In particular, a system-wide API is being changed here with no
description of the problem or the reason for this particular solution.
On first glance, the idea here seems wrong. In getting rid of the device
pointer, how do you plan to handle per-device constraints?
Sorry for not being a very descriptive.
The motivation here is to remove the dependency on SRF for implementing
mpu/dma
latency constraints. Instead they have been implemented using pm_qos
infrastructure.
Latest pm_qos apis take pm_qos handle to distinguish different pm_qos
requests (or
use counting mechanism). Hence drivers need to pass pm_qos handle instead of
device pointer. Drivers just to define a handle and this handle gets
initialized when
they make the first request. So from driver's point of view, it's an opaque
handle.
That's why you see the change in signature of the api.
Regards
Vishwa
Kevin
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
---
arch/arm/plat-omap/Kconfig|3 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h |9 +-
arch/arm/plat-omap/omap-pm-noop.c | 20 +--
arch/arm/plat-omap/omap-pm.c | 309
+
6 files changed, 328 insertions(+), 17 deletions(-)
create mode 100755 arch/arm/plat-omap/omap-pm.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 286b606..ce544b0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -194,6 +194,9 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool No-op/debug PM layer
+config OMAP_PM
+ depends on PM
+ bool OMAP PM layer implementation
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 2a15191..fad2475 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM) += omap-pm.o
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..29dc45a
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -145,7 +145,8 @@ static inline int omap1_i2c_add_bus(struct
platform_device
*pdev, int bus_id)
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev,
long
t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ struct pm_qos_request_list *qos_handle = NULL;
+ omap_pm_set_max_mpu_wakeup_lat(qos_handle, t);
}
static inline int omap2_i2c_add_bus(struct platform_device *pdev, int
bus_id)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-
omap/include/plat/omap-pm.h
index 728fbb9..47ba9e6 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,6 +19,7 @@
#include linux/clk.h
#include powerdomain.h
+#include linux/pm_qos_params.h
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
@@ -86,7 +87,7 @@ void omap_pm_if_exit(void);
/**
* omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup
latency
- * @dev: struct device * requesting the constraint
+ * @qos_request: handle for the constraint. The pointer should be
initialized to
NULL
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
@@ -118,7 +119,7 @@ void omap_pm_if_exit(void);
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list
**qos_request, long t);
/**
@@ -185,7 +186,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev
RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
-Original Message- From: sailes...@gmail.com [mailto:sailes...@gmail.com] On Behalf Of C V, Silesh Sent: Tuesday, August 31, 2010 12:27 PM To: Sripathy, Vishwanath Cc: Kevin Hilman; vishwanath.sripa...@linaro.org; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement On Tue, Aug 31, 2010 at 10:28 AM, Sripathy, Vishwanath vishwanath...@ti.com wrote: -Original Message- From: Silesh C V [mailto:sailes...@gmail.com] Sent: Tuesday, August 31, 2010 9:53 AM To: Sripathy, Vishwanath Cc: Kevin Hilman; vishwanath.sripa...@linaro.org; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Vishwa, On Mon, Aug 30, 2010 at 6:29 PM, Sripathy, Vishwanath vishwanath...@ti.com wrote: Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, August 28, 2010 12:45 AM To: vishwanath.sripa...@linaro.org Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. The challenge here is that we need to take time stamp at the fag end of CPU Idle which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3). So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose to exclude assembly code part for measurement, then we will be omitting major contributor to CPU Idle latency namely ARM context save/restoration part. Also these calculations are done only when we enable CPUIDLE profiling feature. In the normal production system, these will not come into picture at all. So I am not sure latencies involved in these calculations are still an issue when we are just doing profiling. There are two other issues when we use 32k timer for latency measurement. snip + + /* take care of overflow */ + if (postidle_time preidle_time) + postidle_time += (u32) 0x; + if (wkup_time sleep_time) + wkup_time += (u32) 0x; + snip 1.We are checking postidle_time preidle_time to find out whether there had been an over flow or not. There can be situations in which the timer overflows and still we have a greater postidle_time. 2. We are doing the correction for one overflow. What happens if the timer overflows for a second or third time. Can we keep track of the number of overflows and then do the correction accordingly? Unfortunately
RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, August 28, 2010 12:45 AM To: vishwanath.sripa...@linaro.org Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. The challenge here is that we need to take time stamp at the fag end of CPU Idle which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3). So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose to exclude assembly code part for measurement, then we will be omitting major contributor to CPU Idle latency namely ARM context save/restoration part. Also these calculations are done only when we enable CPUIDLE profiling feature. In the normal production system, these will not come into picture at all. So I am not sure latencies involved in these calculations are still an issue when we are just doing profiling. Regards Vishwa Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
-Original Message- From: Silesh C V [mailto:sailes...@gmail.com] Sent: Tuesday, August 31, 2010 9:53 AM To: Sripathy, Vishwanath Cc: Kevin Hilman; vishwanath.sripa...@linaro.org; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Vishwa, On Mon, Aug 30, 2010 at 6:29 PM, Sripathy, Vishwanath vishwanath...@ti.com wrote: Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, August 28, 2010 12:45 AM To: vishwanath.sripa...@linaro.org Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. The challenge here is that we need to take time stamp at the fag end of CPU Idle which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3). So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose to exclude assembly code part for measurement, then we will be omitting major contributor to CPU Idle latency namely ARM context save/restoration part. Also these calculations are done only when we enable CPUIDLE profiling feature. In the normal production system, these will not come into picture at all. So I am not sure latencies involved in these calculations are still an issue when we are just doing profiling. There are two other issues when we use 32k timer for latency measurement. snip + + /* take care of overflow */ + if (postidle_time preidle_time) + postidle_time += (u32) 0x; + if (wkup_time sleep_time) + wkup_time += (u32) 0x; + snip 1.We are checking postidle_time preidle_time to find out whether there had been an over flow or not. There can be situations in which the timer overflows and still we have a greater postidle_time. 2. We are doing the correction for one overflow. What happens if the timer overflows for a second or third time. Can we keep track of the number of overflows and then do the correction accordingly? Unfortunately, there is no way to check if overflow happens more than once in 32k timer and as you said, theoretically it's possible that if timer overflows more than once, these calculation will wrong. Having said that, do you really see any usecase where system will idle for more than 37 hours in single cpuidle execution to cause timer overflow? Vishwa Regards, Silesh Regards Vishwa Kevin -- 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
RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Friday, August 27, 2010 3:17 PM
To: vishwanath.sripa...@linaro.org
Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org
Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Hi,
On Sat, Aug 28, 2010 at 12:08 AM, vishwanath.sripa...@linaro.org wrote:
From: Vishwanath BS vishwanath.sripa...@linaro.org
This patch has instrumentation code for measuring latencies for
various CPUIdle C states for OMAP. Idea here is to capture the
timestamp at various phases of CPU Idle and then compute the sw
latency for various c states. For OMAP, 32k clock is chosen as
reference clock this as is an always on clock. wkup domain memory
(scratchpad memory) is used for storing timestamps. One can see the
worstcase latencies in below sysfs entries (after enabling
CONFIG_CPU_IDLE_PROF
in .config). This information can be used to correctly configure cpu idle
latencies for various C states after adding HW latencies for each of
these sw latencies.
/sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency
THis patch is tested on OMAP ZOOM3 using kevin's pm branch.
Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org
Cc: linaro-...@lists.linaro.org
---
...
+#ifdef CONFIG_CPU_IDLE_PROF
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* take care of overflow */
+ if (postidle_time preidle_time)
+ postidle_time += (u32) 0x;
+ if (wkup_time sleep_time)
+ wkup_time += (u32) 0x;
+
+ idle_time = postidle_time - preidle_time;
+ total_sleep_time = wkup_time - sleep_time;
+ latency = idle_time - total_sleep_time;
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
Is it needed to re-read the sleep_time and wkup_time values from the
scratchpad?
Sleep and wake up time stamps were taken just before and after executing wfi
and stored in scratchpad wkup memory. These values are used while computing
actual latency.
What about the 32k timer overflow? Could that cause the sleep_latency
and/or wkup_latency to be 0?
Overflow issues are taken care while computing idle_time and total_sleep_time
in code below.
+ if (postidle_time preidle_time)
+ postidle_time += (u32) 0x;
+ if (wkup_time sleep_time)
+ wkup_time += (u32) 0x;
+
+ /* calculate average latency after ignoring sprious ones */
+ if ((total_sleep_time 0) (latency state-actual_latency)
+ (latency = 0)) {
+ state-actual_latency = CONVERT_32K_USEC(latency);
+ latency = (sleep_time - preidle_time);
Risk of overflow?
Yes I just realized that overflow can cause sleep_latency and wkup_latency to
turn negative. Thanks for pointing it. Will fix it in next version.
+ state-sleep_latency = CONVERT_32K_USEC(latency);
+ latency = postidle_time - wkup_time;
Risk of overflow?
Agreed. Will fix it.
Vishwa
+ state-wkup_latency = CONVERT_32K_USEC(latency);
+ }
+#endif
+
return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec *
USEC_PER_SEC;
}
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of C V, Silesh
Sent: Friday, August 27, 2010 3:28 PM
To: vishwanath.sripa...@linaro.org
Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org
Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
g 28, 2010 at 3:38 AM, vishwanath.sripa...@linaro.org wrote:
From: Vishwanath BS vishwanath.sripa...@linaro.org
This patch has instrumentation code for measuring latencies for
various CPUIdle C states for OMAP. Idea here is to capture the
timestamp at various phases of CPU Idle and then compute the sw
latency for various c states. For OMAP, 32k clock is chosen as
reference clock this as is an always on clock. wkup domain memory
(scratchpad memory) is used for storing timestamps. One can see the
worstcase latencies in below sysfs entries (after enabling
CONFIG_CPU_IDLE_PROF
in .config). This information can be used to correctly configure cpu idle
latencies for various C states after adding HW latencies for each of
these sw latencies.
/sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency
THis patch is tested on OMAP ZOOM3 using kevin's pm branch.
Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org
Cc: linaro-...@lists.linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 58 --
arch/arm/mach-omap2/pm.h |5 ++
arch/arm/mach-omap2/sleep34xx.S | 121
+
drivers/cpuidle/Kconfig |5 ++
drivers/cpuidle/sysfs.c | 16 +-
include/linux/cpuidle.h |3 +
6 files changed, 202 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
omap2/cpuidle34xx.c
index 3d3d035..398bef8
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -25,6 +25,7 @@
#include linux/sched.h
#include linux/cpuidle.h
+#include linux/clk.h
#include plat/prcm.h
#include plat/irqs.h
#include plat/powerdomain.h
@@ -86,6 +87,11 @@ static struct cpuidle_params cpuidle_params_table[] = {
{1, 1, 3, 30},
};
+#ifdef CONFIG_CPU_IDLE_PROF
+static struct clk *clk_32k;
+#define CONVERT_32K_USEC(lat) (lat * (USEC_PER_SEC/clk_get_rate(clk_32k)))
+#endif
+
static int omap3_idle_bm_check(void)
{
if (!omap3_can_sleep())
@@ -115,21 +121,28 @@ static int _cpuidle_deny_idle(struct powerdomain
*pwrdm,
* Called from the CPUidle framework to program the device to the
* specified target state selected by the governor.
*/
+
static int omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_state *state)
{
struct omap3_processor_cx *cx = cpuidle_get_statedata(state);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
+#ifdef CONFIG_CPU_IDLE_PROF
+ int idle_time, latency;
+ long sleep_time, wkup_time, total_sleep_time;
+ long preidle_time, postidle_time;
+#endif
current_cx_state = *cx;
- /* Used to keep track of the total time in idle */
- getnstimeofday(ts_preidle);
-
local_irq_disable();
local_fiq_disable();
-
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(ts_preidle);
+#ifdef CONFIG_CPU_IDLE_PROF
+ preidle_time = omap3_sram_get_32k_tick();
+#endif
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
@@ -153,9 +166,39 @@ return_sleep_time:
getnstimeofday(ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
+#ifdef CONFIG_CPU_IDLE_PROF
+ postidle_time = omap3_sram_get_32k_tick();
+#endif
local_irq_enable();
local_fiq_enable();
+#ifdef CONFIG_CPU_IDLE_PROF
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* take care of overflow */
+ if (postidle_time preidle_time)
+ postidle_time += (u32) 0x;
+ if (wkup_time sleep_time)
+ wkup_time += (u32) 0x;
+
+ idle_time = postidle_time - preidle_time;
+ total_sleep_time = wkup_time - sleep_time;
+ latency = idle_time - total_sleep_time;
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* calculate average latency after ignoring sprious ones */
+ if ((total_sleep_time 0) (latency state-actual_latency)
+(latency = 0)) {
+ state-actual_latency = CONVERT_32K_USEC(latency);
+ latency = (sleep_time -
RE: [PATCH] OMAP PM: MPU/DMA Latency constraints
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, August 09, 2010 11:59 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP PM: MPU/DMA Latency constraints
Vishwanath Sripathy vishwanath...@ti.com writes:
This patch has implementation for OMAP MPU/DMA Latency constraints using PM
QOS.
Changelog is missing description of the problem being solved and the
motivation for the solution.
In particular, a system-wide API is being changed here with no
description of the problem or the reason for this particular solution.
On first glance, the idea here seems wrong. In getting rid of the device
pointer, how do you plan to handle per-device constraints?
Sorry for not being a very descriptive.
The motivation here is to remove the dependency on SRF for implementing mpu/dma
latency constraints. Instead they have been implemented using pm_qos
infrastructure.
Latest pm_qos apis take pm_qos handle to distinguish different pm_qos requests
(or use counting mechanism). Hence drivers need to pass pm_qos handle instead
of device pointer. Drivers just to define a handle and this handle gets
initialized when they make the first request. So from driver's point of view,
it's an opaque handle. That's why you see the change in signature of the api.
Regards
Vishwa
Kevin
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
---
arch/arm/plat-omap/Kconfig|3 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h |9 +-
arch/arm/plat-omap/omap-pm-noop.c | 20 +--
arch/arm/plat-omap/omap-pm.c | 309
+
6 files changed, 328 insertions(+), 17 deletions(-)
create mode 100755 arch/arm/plat-omap/omap-pm.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 286b606..ce544b0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -194,6 +194,9 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool No-op/debug PM layer
+config OMAP_PM
+ depends on PM
+ bool OMAP PM layer implementation
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 2a15191..fad2475 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM) += omap-pm.o
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..29dc45a
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -145,7 +145,8 @@ static inline int omap1_i2c_add_bus(struct
platform_device
*pdev, int bus_id)
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long
t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ struct pm_qos_request_list *qos_handle = NULL;
+ omap_pm_set_max_mpu_wakeup_lat(qos_handle, t);
}
static inline int omap2_i2c_add_bus(struct platform_device *pdev, int
bus_id)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-
omap/include/plat/omap-pm.h
index 728fbb9..47ba9e6 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,6 +19,7 @@
#include linux/clk.h
#include powerdomain.h
+#include linux/pm_qos_params.h
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
@@ -86,7 +87,7 @@ void omap_pm_if_exit(void);
/**
* omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
- * @dev: struct device * requesting the constraint
+ * @qos_request: handle for the constraint. The pointer should be
initialized to
NULL
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
@@ -118,7 +119,7 @@ void omap_pm_if_exit(void);
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list
**qos_request, long t);
/**
@@ -185,7 +186,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev, struct device *dev,
/**
* omap_pm_set_max_sdma_lat - set the maximum system DMA transfer start
latency
- * @dev: struct device *
+ * @qos_request: handle for the constraint. The pointer should be
initialized to
NULL
* @t: maximum DMA transfer start latency in microseconds
*
* Request that the maximum system DMA transfer start latency for this
@@ -210,7 +211,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev, struct device *dev,
* Returns
RE: [PATCH] OMAP PM: MPU/DMA Latency constraints
Kevin,
Any comments on this patch?
Thanks
Vishwa
-Original Message-
From: Sripathy, Vishwanath
Sent: Friday, July 23, 2010 2:07 PM
To: linux-omap@vger.kernel.org
Cc: Sripathy, Vishwanath
Subject: [PATCH] OMAP PM: MPU/DMA Latency constraints
This patch has implementation for OMAP MPU/DMA Latency constraints using PM
QOS.
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
---
arch/arm/plat-omap/Kconfig|3 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h |9 +-
arch/arm/plat-omap/omap-pm-noop.c | 20 +--
arch/arm/plat-omap/omap-pm.c | 309
+
6 files changed, 328 insertions(+), 17 deletions(-)
create mode 100755 arch/arm/plat-omap/omap-pm.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 286b606..ce544b0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -194,6 +194,9 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool No-op/debug PM layer
+config OMAP_PM
+ depends on PM
+ bool OMAP PM layer implementation
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 2a15191..fad2475 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM) += omap-pm.o
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..29dc45a
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -145,7 +145,8 @@ static inline int omap1_i2c_add_bus(struct platform_device
*pdev, int bus_id)
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ struct pm_qos_request_list *qos_handle = NULL;
+ omap_pm_set_max_mpu_wakeup_lat(qos_handle, t);
}
static inline int omap2_i2c_add_bus(struct platform_device *pdev, int bus_id)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-
omap/include/plat/omap-pm.h
index 728fbb9..47ba9e6 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,6 +19,7 @@
#include linux/clk.h
#include powerdomain.h
+#include linux/pm_qos_params.h
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
@@ -86,7 +87,7 @@ void omap_pm_if_exit(void);
/**
* omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
- * @dev: struct device * requesting the constraint
+ * @qos_request: handle for the constraint. The pointer should be
initialized to NULL
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
@@ -118,7 +119,7 @@ void omap_pm_if_exit(void);
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list
**qos_request, long t);
/**
@@ -185,7 +186,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev, struct device *dev,
/**
* omap_pm_set_max_sdma_lat - set the maximum system DMA transfer start
latency
- * @dev: struct device *
+ * @qos_request: handle for the constraint. The pointer should be
initialized to NULL
* @t: maximum DMA transfer start latency in microseconds
*
* Request that the maximum system DMA transfer start latency for this
@@ -210,7 +211,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev, struct device *dev,
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_sdma_lat(struct device *dev, long t);
+int omap_pm_set_max_sdma_lat(struct pm_qos_request_list **qos_request, long
t);
/**
diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-pm-
noop.c
index e129ce8..af2fe43 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -34,19 +34,17 @@ struct omap_opp *l3_opps;
* Device-driver-originated constraints (via board-*.c files)
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list **pmqos_req,
long t)
{
- if (!dev || t -1) {
+ if (!pmqos_req || t -1) {
WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
return -EINVAL;
};
if (t == -1)
- pr_debug(OMAP PM: remove max MPU wakeup latency constraint:
- dev %s\n, dev_name(dev));
+ pr_debug(OMAP PM: remove max MPU wakeup latency constraint\n
RE: [PATCH] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
Sent: Wednesday, July 14, 2010 1:51 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Ghorai, Sukumar
Subject: [PATCH] mmc: csd version check updated to support MMC v4.41
CSD_STRUCTURE [127:126] describes the version of the CSD structure.
According to the MMC specificaiton (v4.4.1), 3 is also a valid number.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
Tested on omap4430 ES2.0
drivers/mmc/core/mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89f7a25..525af33 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
* v1.2 has extra information in bits 15, 11 and 10.
*/
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 1 csd_struct != 2) {
+ if (csd_struct 3) {
Can't csd_struct be 0? If so then your new check will break right?
printk(KERN_ERR %s: unrecognised CSD structure version %d\n,
mmc_hostname(card-host), csd_struct);
return -EINVAL;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] usb: musb: Offmode fix for idle path
Hema,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kalliguddi, Hema
Sent: Thursday, July 08, 2010 3:59 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Kalliguddi, Hema; Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Kevin
Hilman
Subject: [PATCH] usb: musb: Offmode fix for idle path
From: Hema HK hem...@ti.com
With OMAP coreoff support usb was not functional as context was getting
lost after wakeup from coreoff. And also usb was blocking the coreoff
after loading the gadget driver even with no cable connected sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not used, configure in force idle and force standby mode.
When it is being used, configure in smart standby and smart idle mode.
So while attempting to coreoff the usb is configured to force standby and
force idle mode, after wakeup configured in smart idle and smart standby.
Since clock used for musb is auto gated, there is no need to specifically
enable/disable the clock. Removed enable/disable clock in suspend resume api.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
Based off : Kevin pm branch.
arch/arm/mach-omap2/pm34xx.c |4
arch/arm/mach-omap2/usb-musb.c| 15 +++
arch/arm/plat-omap/include/plat/usb.h |2 ++
drivers/usb/musb/musb_core.c | 11 ---
drivers/usb/musb/omap2430.c | 32
5 files changed, 49 insertions(+), 15 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
=
==
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
@@ -431,6 +431,8 @@ void omap_sram_idle(void)
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+ /* Save MUSB context */
+ musb_context_save_restore(1);
Do you really need to save and restore USB context in every OS Idle? Can't it
be done on a need basis like when USB is connected?
}
}
@@ -479,6 +481,8 @@ void omap_sram_idle(void)
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+ /* Restore MUSB context */
+ musb_context_save_restore(0);
/*
* Errata 1.164 fix : OTG autoidle can prevent
* sleep
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
=
==
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
@@ -177,6 +177,21 @@ void __init usb_musb_init(struct omap_mu
usb_musb_pm_init();
}
+void musb_context_save_restore(int save)
+{
+ struct device *dev = musb_device.dev;
+ struct device_driver *drv = dev-driver;
+ if (dev-driver) {
+
+ const struct dev_pm_ops *pm = drv-pm;
+
+ if (save)
+ pm-suspend(dev);
+ else
+ pm-resume_noirq(dev);
+ }
+}
+
#else
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
Index: linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
=
==
--- linux-omap-pm.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
@@ -82,6 +82,8 @@ extern void usb_ohci_init(const struct o
/* This is needed for OMAP3 errata 1.164: enabled autoidle can prevent sleep
*/
extern void usb_musb_disable_autoidle(void);
+/* For saving and restoring the musb context during off/wakeup*/
+extern void musb_context_save_restore(int save);
#endif
void omap_usb_init(struct omap_usb_config *pdata);
Index: linux-omap-pm/drivers/usb/musb/musb_core.c
=
==
--- linux-omap-pm.orig/drivers/usb/musb/musb_core.c
+++ linux-omap-pm/drivers/usb/musb/musb_core.c
@@ -2430,11 +2430,6 @@ static int musb_suspend(struct device *d
}
musb_save_context(musb);
-
- if (musb-set_clock)
- musb-set_clock(musb-clock, 0);
- else
- clk_disable(musb-clock);
spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
@@ -2446,12 +2441,6 @@ static int musb_resume_noirq(struct
RE: [RFC 1/7] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Friday, July 02, 2010 3:48 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Basak, Partha; Gopinath, Thara
Subject: [RFC 1/7] OMAP: Introduce a user list for each voltage domain
instance in
the voltage driver.
This patch introduces a user list of devices associated with each
voltage domain instance. The user list is implemented using plist
structure with priority node populated with the voltage values.
This patch also adds an API which will take in a device and
requested voltage as parameters, adds the info to the user list
and returns back the maximum voltage requested by all the user
devices. This can be used anytime to get the voltage that the
voltage domain instance can be transitioned into.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 83
+
arch/arm/plat-omap/include/plat/voltage.h |2 +
2 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 30f1770..a2f30a4 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -24,6 +24,9 @@
#include linux/clk.h
#include linux/err.h
#include linux/debugfs.h
+#include linux/spinlock.h
+#include linux/plist.h
+#include linux/slab.h
#include plat/omap-pm.h
#include plat/omap34xx.h
@@ -93,6 +96,20 @@ struct vp_reg_val {
};
/**
+ * omap_vdd_user_list- The per vdd user list
+ *
+ * @dev : The device asking for the vdd to be set at a
particular
+ * voltage
+ * @node : The list head entry
+ * @volt : The voltage requested by the device dev
+ */
+struct omap_vdd_user_list {
+ struct device *dev;
+ struct plist_node node;
+ u32 volt;
+};
+
+/**
* omap_vdd_info - Per Voltage Domain info
*
* @volt_data: voltage table having the distinct voltages
supported
@@ -103,6 +120,9 @@ struct vp_reg_val {
* vp registers
* @volt_clk : the clock associated with the vdd.
* @opp_dev : the 'struct device' associated with this vdd.
+ * @user_lock: the lock to be used by the plist user_list
+ * @user_list: the list head maintaining the various users
+ * of this vdd with the voltage requested by each user.
* @volt_data_count : Number of distinct voltages supported by this vdd.
* @nominal_volt : Nominal voltaged for this vdd.
* cmdval_reg: Voltage controller cmdval register.
@@ -115,6 +135,8 @@ struct omap_vdd_info{
struct clk *volt_clk;
struct device *opp_dev;
struct omap_volt_domain volt_domain;
+ spinlock_t user_lock;
+ struct plist_head user_list;
int volt_data_count;
unsigned long nominal_volt;
u8 cmdval_reg;
@@ -361,6 +383,10 @@ static void __init omap3_vdd_data_configure(struct
omap_vdd_info *vdd)
struct clk *sys_ck;
u32 sys_clk_speed, timeout_val, waittime;
+ /* Init the plist */
+ spin_lock_init(vdd-user_lock);
+ plist_head_init(vdd-user_list, vdd-user_lock);
+
if (!strcmp(vdd-volt_domain.name, mpu)) {
if (cpu_is_omap3630()) {
vdd-vp_reg.vlimitto_vddmin =
@@ -881,6 +907,63 @@ unsigned long omap_voltageprocessor_get_curr_volt(
}
/**
+ * omap_voltage_get_final : API to keep track of various requests to
[minor] This name does not match the actual API
+ * scale the VDD and returns the best possible
+ * voltage the VDD can be put to.
+ * @volt_domain: pointer to the voltage domain.
+ * @dev : the device pointer.
+ * @volt : the voltage which is requested by the device.
+ *
+ * This API is to be called before the actual voltage scaling is
+ * done to determine what is the best possible voltage the VDD can
+ * be put to. This API adds the device dev in the user list of the
+ * vdd volt_domain with volt as the requested voltage. The user list
+ * is a plist with the priority element absolute voltage values.
+ * The API then finds the maximum of all the requested voltages for
+ * the VDD and returns it back through volt pointer itself.
+ * Returns error value in case of any errors.
+ */
+int omap_volt_get_final(struct omap_volt_domain *volt_domain,
+ struct device *dev, unsigned long *volt)
+{
+ struct omap_vdd_info *vdd;
+ struct omap_vdd_user_list *user;
+ struct plist_node *node;
+ int found = 0;
+
+ if (!volt_domain || IS_ERR(volt_domain)) {
+ pr_warning(%s: VDD specified does not exist!\n, __func__);
+ return -EINVAL;
+ }
+
+ vdd = container_of(volt_domain, struct omap_vdd_info, volt_domain
RE: [RFC 5/7] OMAP: Introduce set_rate and get_rate API in omap device layer
-Original Message-
From: Gopinath, Thara
Sent: Friday, July 02, 2010 3:48 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Basak, Partha; Gopinath, Thara
Subject: [RFC 5/7] OMAP: Introduce set_rate and get_rate API in omap device
layer
This patch adds omap_device_set_rate and omap_device_get_rate
API's which can be used to generic device rate scaling.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/omap_device.c | 87
+
2 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-
omap/include/plat/omap_device.h
index 3694b62..e0d06bb 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -114,6 +114,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_set_rate(struct device *dev, unsigned long rate);
+unsigned long omap_device_get_rate(struct device *dev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 6614cba..900bb5d 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,8 @@
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/opp.h
+#include plat/voltage.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -734,3 +736,88 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+/**
+ * omap_device_set_rate - Set a new rate at which the device is to operate
+ * @dev : the device pointer
+ * @rate : the rnew rate for the device.
+ *
+ * This API gets the device opp table associated with this device and
+ * tries putting the device to the requested rate and the voltage domain
+ * associated with the device to the voltage corresponding to the
+ * requested rate. Since multiple devices can be assocciated with a
+ * voltage domain this API finds out the possible voltage the
+ * voltage domain can enter and then decides on the final device
+ * rate. Return 0 on success else the error value
+ */
+int omap_device_set_rate(struct device *dev, unsigned long rate)
+{
+ struct device_opp *dev_opp;
+ struct omap_opp *opp;
+ unsigned long volt, freq;
+ int ret;
+
+ dev_opp = opp_find_dev_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ dev_warn(dev, %s: Unable to find device opp table\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ /* Get the possible rate from the opp layer */
+ freq = rate;
+ opp = opp_find_freq_ceil(dev, freq);
+ if (IS_ERR(opp)) {
+ dev_err(dev, %s: Unable to find OPP for freq%ld\n,
+ __func__, rate);
+ return -ENODEV;
+ }
+ if (unlikely(freq != rate))
+ dev_warn(dev, %s: Available freq %ld != dpll freq %ld.\n,
+ __func__, freq, rate);
+
+ /* Get the voltage corresponding to the requested frequency */
+ volt = opp_get_voltage(opp);
+
+ /*
+ * Call into the voltage layer to get the final voltage possible
+ * for the voltage domain associated with the device.
+ */
+
+ ret = omap_volt_get_final(dev_opp-volt_domain, dev, volt);
+ if (ret) {
+ dev_err(dev, %s: Unable to get the final volt for scaling\n,
+ __func__);
+ return ret;
+ }
+
+ /* Do the actual scaling */
+ return omap_voltage_scale(dev_opp-volt_domain, volt);
This function also needs to be lock protected to avoid race conditions involved
when multiple guys try to scale the voltage simultaneously.
+}
+
+/**
+ * omap_device_get_rate - Gets the current operating rate of the device
+ * @dev - the device pointer
+ *
+ * This API returns the current operating rate of the device on success.
+ * Else returns the error value.
+ */
+unsigned long omap_device_get_rate(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ dev_opp = opp_find_dev_opp(dev);
+
+ if (IS_ERR(dev_opp)) {
+ dev_warn(dev, %s: Unable to find device opp table\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ if (!dev_opp-get_rate) {
+ dev_warn(dev, %s: No get_rate API\n, __func__);
+ return -EINVAL;
+ }
+
+ return dev_opp-get_rate(dev);
+}
--
1.7.0.rc1.33.g07cf0f
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
Boot fail on OMAP3430SDP
Hi, I am observing that image built using omap3_pm_defconfig on Kevin's pm branch does not seem to boot on OMAP3430 SDP board. It just stops after printing Uncompressing Linux... done, booting the kernel. I am using console=ttyS0 as part of my bootargs. Any hints? Vishwa -- 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: Boot fail on OMAP3430SDP
Here is the log from Early printk. Bytes transferred = 2094808 (1ff6d8 hex) ## Booting image at 8030 ... Image Name: Linux-2.6.35-rc3-10791-g305f453 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2094744 Bytes = 2 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.35-rc3-10791-g305f453 (vis...@vishwa-desktop) (gcc version 4.3 .3 (Sourcery G++ Lite 2009q1-203) ) #38 PREEMPT Tue Jun 29 19:13:42 IST 2010 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3430 3430SDP board bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyS0,115200n8 noinitrd root=/dev/nfs rw nfsroot=17 2.24.136.185:/home/a0876481/testtarget,nolock,tcp, ip=dhcp earlyprintk PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 125508k/125508k available, 5564k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc880 - 0xf800 ( 760 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc0034000 ( 176 kB) .text : 0xc0034000 - 0xc03ee000 (3816 kB) .data : 0xc03ee000 - 0xc0432280 ( 273 kB) SLUB: Genslabs=9, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:402 Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz omap_hwmod: l3_hwmod: cannot be enabled (3) omap_hwmod: l4_core_hwmod: cannot be enabled (3) omap_hwmod: l4_per_hwmod: cannot be enabled (3) omap_hwmod: l4_wkup_hwmod: cannot be enabled (3) omap_hwmod: sr1_hwmod: cannot be enabled (3) omap_hwmod: sr2_hwmod: cannot be enabled (3) Reprogramming SDRC clock to 33200 Hz GPMC revision 5.0 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller Could not get gpios_ick Could not get gpios_fck OMAP GPIO hardware version 2.5 OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok regulator: core version 0.5 NET: Registered protocol family 16 SmartReflex CLASS3 initialized OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz Vishwa -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath Sent: Tuesday, June 29, 2010 7:06 PM To: linux-omap@vger.kernel.org Subject: Boot fail on OMAP3430SDP Hi, I am observing that image built using omap3_pm_defconfig on Kevin's pm branch does not seem to boot on OMAP3430 SDP board. It just stops after printing Uncompressing Linux... done, booting the kernel. I am using console=ttyS0 as part of my bootargs. Any hints? Vishwa -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
Kevin, -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, May 18, 2010 10:07 PM To: Sripathy, Vishwanath Cc: Gulati, Shweta; linux-omap@vger.kernel.org Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue Sripathy, Vishwanath vishwanath...@ti.com writes: All that being said, why is the voltage level being programmed here? It seems to me that all of this errata handling should be self-contained in the voltage layer. I am not sure if entire errata can be contained in voltage layer. This is because we are performing DVFS operation in CPU Idle path which involves both Frequency and Voltage scaling. So currently this has been done in resource34xx.c where DVFS is implemented. What I mean is that there seems to be no good reason to be calling these from pm34xx.c, they should be called where voltage scaling is done. Sorry I still do not understand how errata can be invoked from Voltage scaling. Pls note that errata has to be applied only when Core is entering retention or off which can be detected only in omap_sram_idle function. Errata is tightly coupled with CPU idle path. Vishwa Kevin -- 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] OMAP3: PM: Workaround for DPLL3 Lock issue
Hi Benoit, -Original Message- From: Cousson, Benoit Sent: Wednesday, May 19, 2010 5:28 PM To: Gulati, Shweta Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue Hi Vishwa, On 5/13/2010 12:12 PM, shweta gulati wrote: From: Vishwanath Sripathyvishwanath...@ti.com OMAP3430/3630 has a Silicon bug because of which SDRC is released from IDLE even before Core DPLL has locked. This leads to undefined behaviour of SDRC DLL. This patch has workaround for the same. Description of WA for 3430: Initialization: Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is always locked. Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode: 1. Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency (by changing M2 Divider value). This is increasing the period duration of one L3 clock cycle. o In case of CORE is at OPP3 (166...@1.15v): Lower the frequency to 83MHz. o In case of CORE is at OPP2 (83...@1.05v): Keep the frequency as it is (83MHz). 2. Increase CORE Voltage to 1.2V. This is reducing the timing duration of the critical path signal which will now fit to one L3 clock cycle. 3. Enable DPLL3 Automatic mode. This will ensure proper transition to RETENTION or OFF mode. After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode: 1. Disable DPLL3 Automatic mode. 2. Restore previous DPLL3 M2 Frequency and CORE Voltage values. Description of WA for 3630: Initialization: Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is always locked. Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode: 1. Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency (by changing M2 Divider value) and set VDD2 Voltage for OPP100. This is increasing the period duration of one L3 clock cycle and reducing the timing duration of the critical path signal which will now fit to one L3 clock cycle. o In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V): Lower the frequency to 100MHz. Keep the voltage as it is (1.1375V). o In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V): Keep the frequency as it is (100MHz). Increase the voltage to 1.1375V. 2. Enable DPLL3 Automatic mode. This will ensure proper transition to RETENTION or OFF mode. After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode: 1. Disable DPLL3 Automatic mode. 2. Restore previous DPLL3 M2 Frequency and CORE Voltage values. Also OSWR should not be attempted if DPLL3 has locked. This should be done as part of OSWR patch series. Patch tested on 3430SDP and 3630 ZOOM3. Do you have a more accurate description of the bug? What is the defect ID? Defect Id is i581. The subject is about DPLL3 lock issue, and the description is all about the transition to CORE RET or OFF and playing with voltage... and why OSWR is affected as well? I'm a little bit confused by that... Is this bug dependent of the target power state? What about INACTIVE? The root cause of the issue is that SDRC IDLEREQ is deasserted before DPLL3 has locked. Because of this DLL may/may not lock based on Process Voltage Temperature conditions. The bug can occur when DPLL3 automatic transition is enabled. So DPLL3 automatic transition is disabled by default and it is enabled only when system is entering ret/off state (to facilitate voltage scaling). So when system is entering ret/off state, WA is applied (since DPLL3 autoidle is enabled, we can possibly hit the issue; hence the WA) Regarding OSWR, as per errata i580, DPLL3 cannot be kept Locked when CORE is in OSWR state if DPLL3 is set in Manual Lock mode. So if DPLL3 autoidle is not enabled (manual lock mode), then we should not attempt to goto Core OSWR. Why setting the CORE at 1.2v when the description is only considering 1.1375v? For OMAP3430, as per errata VDD2 should be set to 1.2V before attempting off/retention. 1.1375V applies for OMAP3630. Regards Vishwa Thanks, Benoit -- 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] OMAP3: PM: Workaround for DPLL3 Lock issue
Hi Benoit, -Original Message- From: Cousson, Benoit Sent: Wednesday, May 19, 2010 8:00 PM To: Sripathy, Vishwanath Cc: Gulati, Shweta; linux-omap@vger.kernel.org Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue On 5/19/2010 3:50 PM, Sripathy, Vishwanath wrote: Hi Benoit, -Original Message- From: Cousson, Benoit Sent: Wednesday, May 19, 2010 5:28 PM To: Gulati, Shweta Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue Hi Vishwa, On 5/13/2010 12:12 PM, shweta gulati wrote: From: Vishwanath Sripathyvishwanath...@ti.com OMAP3430/3630 has a Silicon bug because of which SDRC is released from IDLE even before Core DPLL has locked. This leads to undefined behaviour of SDRC DLL. This patch has workaround for the same. Description of WA for 3430: Initialization: Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is always locked. Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode: 1.Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency (by changing M2 Divider value). This is increasing the period duration of one L3 clock cycle. o In case of CORE is at OPP3 (166...@1.15v): Lower the frequency to 83MHz. o In case of CORE is at OPP2 (83...@1.05v): Keep the frequency as it is (83MHz). 2.Increase CORE Voltage to 1.2V. This is reducing the timing duration of the critical path signal which will now fit to one L3 clock cycle. 3.Enable DPLL3 Automatic mode. This will ensure proper transition to RETENTION or OFF mode. After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode: 1.Disable DPLL3 Automatic mode. 2.Restore previous DPLL3 M2 Frequency and CORE Voltage values. Description of WA for 3630: Initialization: Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is always locked. Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode: 1.Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency (by changing M2 Divider value) and set VDD2 Voltage for OPP100. This is increasing the period duration of one L3 clock cycle and reducing the timing duration of the critical path signal which will now fit to one L3 clock cycle. o In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V): Lower the frequency to 100MHz. Keep the voltage as it is (1.1375V). o In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V): Keep the frequency as it is (100MHz). Increase the voltage to 1.1375V. 2.Enable DPLL3 Automatic mode. This will ensure proper transition to RETENTION or OFF mode. After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode: 1.Disable DPLL3 Automatic mode. 2.Restore previous DPLL3 M2 Frequency and CORE Voltage values. Also OSWR should not be attempted if DPLL3 has locked. This should be done as part of OSWR patch series. Patch tested on 3430SDP and 3630 ZOOM3. Do you have a more accurate description of the bug? What is the defect ID? Defect Id is i581. The subject is about DPLL3 lock issue, and the description is all about the transition to CORE RET or OFF and playing with voltage... and why OSWR is affected as well? I'm a little bit confused by that... Is this bug dependent of the target power state? What about INACTIVE? The root cause of the issue is that SDRC IDLEREQ is deasserted before DPLL3 has locked. Because of this DLL may/may not lock based on Process Voltage Temperature conditions. The bug can occur when DPLL3 automatic transition is enabled. So DPLL3 automatic transition is disabled by default and it is enabled only when system is entering ret/off state (to facilitate voltage scaling). So when system is entering ret/off state, WA is applied (since DPLL3 autoidle is enabled, we can possibly hit the issue; hence the WA) Thanks, but that still not explain why this WA is considered only for device transition to RET or OFF. The DPLL3 can got to idle as soon as the CORE is INACTIVE. How this case is handled? DPLL3 auto idle is disabled when Core is in ON or INACTIVE state. So DPLL3 cannot goto idle state. We enable DPPL3 auto idle only when Core is about to enter RET or OFF state (otherwise VDD2 will not be able to scale the voltage down). Why is it depend of the voltage? Am I missing something? After checking the errata, it looks like there is no further explanation than this one: These cases cannot be executed if only Power Domain transition is targeted which does not explain anything:-( I'll check that with Hayati. Apparently by increasing
RE: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, May 14, 2010 11:28 PM
To: Gulati, Shweta
Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
shweta gulati shweta.gul...@ti.com writes:
From: Vishwanath Sripathy vishwanath...@ti.com
OMAP3430/3630 has a Silicon bug because of which SDRC is
released from IDLE even before Core DPLL has locked. This leads
to undefined behaviour of SDRC DLL.
This patch has workaround for the same.
Description of WA for 3430:
Initialization:
Disable DPLL3 automatic mode by default. Issue will not be faced as
DPLL3
is always locked.
Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
1. Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
(by changing M2 Divider value). This is increasing the period duration
of
one L3 clock cycle.
o In case of CORE is at OPP3 (166...@1.15v):
Lower the frequency to 83MHz.
o In case of CORE is at OPP2 (83...@1.05v):
Keep the frequency as it is (83MHz).
2. Increase CORE Voltage to 1.2V. This is reducing the timing duration of
the
critical path signal which will now fit to one L3 clock cycle.
3. Enable DPLL3 Automatic mode. This will ensure proper transition to
RETENTION or OFF mode.
After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
1. Disable DPLL3 Automatic mode.
2. Restore previous DPLL3 M2 Frequency and CORE Voltage values.
Description of WA for 3630:
Initialization:
Disable DPLL3 automatic mode by default. Issue will not be faced as
DPLL3 is
always locked.
Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
1. Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
This is increasing the period duration of one L3 clock cycle and
reducing
the timing duration of the critical path signal which will now fit to
one
L3 clock cycle.
o In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
Lower the frequency to 100MHz.
Keep the voltage as it is (1.1375V).
o In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
Keep the frequency as it is (100MHz).
Increase the voltage to 1.1375V.
2. Enable DPLL3 Automatic mode. This will ensure proper transition to
RETENTION or OFF mode.
After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
1. Disable DPLL3 Automatic mode.
2. Restore previous DPLL3 M2 Frequency and CORE Voltage values.
Also OSWR should not be attempted if DPLL3 has locked. This should be done
as
part of OSWR patch series.
Patch tested on 3430SDP and 3630 ZOOM3.
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
This patch appears to depend on Thara's SR series. Please state
dependencies here.
OK
Index: linux-omap-pm/arch/arm/mach-omap2/pm.h
=
==
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm.h
+++ linux-omap-pm/arch/arm/mach-omap2/pm.h
@@ -60,6 +60,10 @@ struct prm_setup_vc {
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int
state);
+extern int program_vdd2_opp_3430(void);
+extern int reprogram_vdd2_opp_3430(int restore);
+extern int program_vdd2_opp_3630(void);
+extern int reprogram_vdd2_opp_3630(int restore);
extern u32 wakeup_timer_seconds;
extern struct omap_dm_timer *gptimer_wakeup;
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
=
==
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
#include sdrc.h
#include omap3-opp.h
+
stray whitespace change
#ifdef CONFIG_SUSPEND
static suspend_state_t suspend_state = PM_SUSPEND_ON;
static inline bool is_suspending(void)
@@ -363,6 +364,8 @@ void omap_sram_idle(void)
u32 sdrc_pwr = 0;
int per_state_modified = 0;
unsigned int start =0, end = 0;
+ u32 fclk_status = 0;
+ int restore = 1;
if (!_omap_sram_idle)
return;
@@ -415,15 +418,6 @@ void omap_sram_idle(void)
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.
-*/
- if (mpu_next_state = PWRDM_POWER_RET)
- omap_smartreflex_disable(VDD1, 1
RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
-Original Message-
From: Premi, Sanjeev
Sent: Monday, April 05, 2010 6:39 PM
To: Sripathy, Vishwanath; Paul Walmsley
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Sripathy, Vishwanath
Sent: Monday, April 05, 2010 5:23 PM
To: Paul Walmsley
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, April 05, 2010 4:44 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass
Clock Divider
On Mon, 5 Apr 2010, Sripathy, Vishwanath wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
On Thu, 1 Apr 2010, Vishwanath BS wrote:
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-
omap2/clock3xxx_data.c
index d5153b6..d8e57a6
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
sdrc_ick_p = clk_get(NULL, sdrc_ick);
arm_fck_p = clk_get(NULL, arm_fck);
+ /* Set the bypass clock dividers for DPLL1 and DPLL2 */
+ if (cpu_is_omap3630()) {
+ clk_set_rate(dpll1_fck, 4/2);
+ clk_set_rate(dpll2_fck, 4/2);
+ } else {
+ clk_set_rate(dpll1_fck, 33200/4);
+ clk_set_rate(dpll2_fck, 33200/4);
+ }
This code is highly OPP-specific. Why is this code needed here?
Shouldn't the code in resource34xx.c be sufficient?
Code in resource34xx.c will be executed only when DVFS is
executed.
However above code makes sure that initial values of Bypass clock
dividers are good. This will ensure that even if DVFS is disabled,
IVA/MPU are never overclocked when they enter bypass mode.
My point is that you don't know how the bootloader has
configured the
system at the point when this code executes. You don't
know what voltage
level VDD1 and VDD2 are at; you don't know what state the
clock tree is
in. You only know this when you change OPPs. And the
selection of the
OPP at startup is use-case dependent.
May be I can move this code to init_opp?
I have been trying to find a good place for the same myself. Though,
my reason is different. The default kernel boots with the OPP3 for
OMAP34xx; but when mpurate is used to set 720; I feel sometimes the
boot may fail if the voltage isn't right.
I thought uboot would have set the right voltage while setting the MPU rate.
Isn't that true?
The voltage does stabilize when smartrelex reflex is initialized.
Why do you have dependency on SR for voltage stabilization? You can set the
right voltage even w/o SR (via VP). SR is only for optimizing Voltage for a
given OPP.
Regards
Vishwa
I was trying to move smartreflex above in the init sequence; after
i2c has been initialized.
Comments/ thoughts?
Best regards,
Sanjeev
So as far as I can tell, this code shouldn't be there. If
you want to do
something like this, then you should add some generic way
(e.g., a kernel
command line parameter) to set the VDD1 and VDD2 OPPs at boot.
- Paul
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, April 01, 2010 2:57 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
On Thu, 1 Apr 2010, Vishwanath BS wrote:
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 solution is to make sure DPLL1/DPLL2 bypass clock is always less
than maximum supported frequency for the specific OPP.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-
omap2/clock3xxx_data.c
index d5153b6..d8e57a6
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
...
@@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
sdrc_ick_p = clk_get(NULL, sdrc_ick);
arm_fck_p = clk_get(NULL, arm_fck);
+ /* Set the bypass clock dividers for DPLL1 and DPLL2 */
+ if (cpu_is_omap3630()) {
+ clk_set_rate(dpll1_fck, 4/2);
+ clk_set_rate(dpll2_fck, 4/2);
+ } else {
+ clk_set_rate(dpll1_fck, 33200/4);
+ clk_set_rate(dpll2_fck, 33200/4);
+ }
This code is highly OPP-specific. Why is this code needed here?
Shouldn't the code in resource34xx.c be sufficient?
Code in resource34xx.c will be executed only when DVFS is executed. However
above code makes sure that initial values of Bypass clock dividers are good.
This will ensure that even if DVFS is disabled, IVA/MPU are never overclocked
when they enter bypass mode.
Regards
Vishwa
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Paul, Sorry for late response. Here is the answer for some of the queries that you had posted. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, January 26, 2010 11:13 AM To: Reddy, Teerth Cc: linux-omap@vger.kernel.org; t...@atomide.com; Kevin Hilman Subject: RE: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset Hello Teerth, On Mon, 25 Jan 2010, Reddy, Teerth wrote: From: Paul Walmsley [mailto:p...@pwsan.com] I wonder if this also needs to make sure that all the other system initiators are mute before continuing, for the same reason cited in commit 18862cbe47e37beba98f22c088fbe6fe029df889 ? I suppose that, for example, if an interrupt occurs on the IVA2.2 or the DMA controller tries to access the SDRC, it would hopefully only wedge those initiators and not the whole chip? Do you think we need to take care of the system initiators if we are disabling all the interrupts before going for a warm reset? Are you disabling _all_ the interrupts, or just the MPU's interrupts? Even if you did disable all of the system interrupts, couldn't DMA be ongoing from/to another system initiator, independently of interrupts? We should disable all MPU interrupts. Yes there can be another initiator active in the system parallelly. However all the system initiators will recover from reset once warm reset is triggered. I think this doesn't seem to hold good here. You may be right, but I'd like you to describe your reasoning on this point. Please let me know if you understanding is wrong. My concerns here are twofold: 1. If other system initiators are interacting with the SDRC during this process, is there a danger that the interconnect could enter a state that would prevent the warm reset from occurring, thus wedging the system? This should not happen since bottle neck would be L4, only initiators accessing L4 are expected to be MPU and DMA (and maybe DSP) and L4 has 4 threads. We cannot think of a blocking scenario. 2. When the warm-reset occurs, will it also completely reset other initiators that may be wedged waiting for some SDRC access to complete? Yes Vishwa - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, April 05, 2010 4:44 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
On Mon, 5 Apr 2010, Sripathy, Vishwanath wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
On Thu, 1 Apr 2010, Vishwanath BS wrote:
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-
omap2/clock3xxx_data.c
index d5153b6..d8e57a6
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
sdrc_ick_p = clk_get(NULL, sdrc_ick);
arm_fck_p = clk_get(NULL, arm_fck);
+ /* Set the bypass clock dividers for DPLL1 and DPLL2 */
+ if (cpu_is_omap3630()) {
+ clk_set_rate(dpll1_fck, 4/2);
+ clk_set_rate(dpll2_fck, 4/2);
+ } else {
+ clk_set_rate(dpll1_fck, 33200/4);
+ clk_set_rate(dpll2_fck, 33200/4);
+ }
This code is highly OPP-specific. Why is this code needed here?
Shouldn't the code in resource34xx.c be sufficient?
Code in resource34xx.c will be executed only when DVFS is executed.
However above code makes sure that initial values of Bypass clock
dividers are good. This will ensure that even if DVFS is disabled,
IVA/MPU are never overclocked when they enter bypass mode.
My point is that you don't know how the bootloader has configured the
system at the point when this code executes. You don't know what voltage
level VDD1 and VDD2 are at; you don't know what state the clock tree is
in. You only know this when you change OPPs. And the selection of the
OPP at startup is use-case dependent.
May be I can move this code to init_opp?
So as far as I can tell, this code shouldn't be there. If you want to do
something like this, then you should add some generic way (e.g., a kernel
command line parameter) to set the VDD1 and VDD2 OPPs at boot.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHV3 0/2] MPU/IVA bypass clock configuration
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, April 01, 2010 2:46 PM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHV3 0/2] MPU/IVA bypass clock configuration Hi Vishwanath, On Thu, 1 Apr 2010, Vishwanath BS wrote: 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 solution is to make sure DPLL1/DPLL2 bypass clock is always less than maximum supported frequency for the specific OPP. Typically these settings are to be done in bootloaders. All the patches have been tested on OMAP3630 ZOOM3 platform. Comments adressed in V3: 1. Used clk_set_rate API instead of directly writing to registers 2. Split the patch into 2 patches. Vishwanath BS (4): OMAP3: Set MPU and IVA bypass Clock Divider OMAP3 PM: Set MPU and IVA bypass clock dividers in DVFS On what tree do these patches apply? I have applied them on top of wip_opp branch in Kevin's PM branch. Regards Vishwa - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHV2] OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, March 30, 2010 3:01 PM To: Sripathy, Vishwanath Cc: Kevin Hilman; linux-omap@vger.kernel.org; Gulati, Shweta Subject: RE: [PATCHV2] OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation On Mon, 29 Mar 2010, Sripathy, Vishwanath wrote: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Please add this support by modifying/extending the existing clock/DPLL management code instead of manually writing registers. Min/max dividers in clock framework are for dpll lock frequency, where as in the patch, we configure dpll bypass frequency. Shall I add a new API in dpll.c to configure bypass clock dividers? That API is called clk_set_rate() and is already present as you can see by grep'ping clock3xxx_data.c for OMAP3430_MPU_CLK_SRC_MASK (as one example). Thanks, I will repost the patch. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHV2] OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation
Kevin, -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, March 17, 2010 11:32 PM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCHV2] OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation Vishwanath BS vishwanath...@ti.com writes: 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 solution is to make sure DPLL1/DPLL2 bypass clock is always less than maximum supported frequency for the specific OPP Tested on 3630 ZOOM3. changes in V2 : Rebased to new OPP implementation Signed-off-by: Shweta Gulati shweta.gul...@ti.com Signed-off-by: Vishwanath BS vishwanath...@ti.com --- This should be broken up into two parts. One that applies to mainline (or l-o master), and another that fixes SRF that can be applied to PM branch. The first will be targted for mainline, but the SRF change will be only in PM branch, as SRF is deprecated and will be replaced. ack That being said, the approach in this patch is not the right approach. It appears to completely ignore the min/max dividers that are already managed by the clock/DPLL code. Please add this support by modifying/extending the existing clock/DPLL management code instead of manually writing registers. Min/max dividers in clock framework are for dpll lock frequency, where as in the patch, we configure dpll bypass frequency. Shall I add a new API in dpll.c to configure bypass clock dividers? Vishwa Kevin -- 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 L23.I3 PM 2/2]: Setting Mpu registers properly when enable_off_mode is enabled
-Original Message-
From: Gulati, Shweta
Sent: Wednesday, March 24, 2010 7:16 PM
To: linux-omap@vger.kernel.org
Cc: Gulati, Shweta; Sripathy, Vishwanath
Subject: [PATCH L23.I3 PM 2/2]: Setting Mpu registers properly when
enable_off_mode is enabled
Subject should be [PATCH 2/2] OMAP3 PM: Setting Mpu registers properly when
enable_off_mode is enabled. Do not put TI Internal release names.
From: Shweta Gulati shweta.gul...@ti.com
When enable_off_mode is enabled and ROM code issues WFI, the
powerstate of all the powerdomains is set as OFF in PM_PWSTCTRL
register and when it restores back the system to previous state
it sets MPU as OFF and system hangs.
This Patch ensures that for MPU the state is ON after it comes out of
Idle/Suspend till it renters Idle.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
Index: kernel-omap3-dev/arch/arm/mach-omap2/pm34xx.c
=
==
--- kernel-omap3-dev.orig/arch/arm/mach-omap2/pm34xx.c
+++ kernel-omap3-dev/arch/arm/mach-omap2/pm34xx.c
@@ -573,8 +573,14 @@ void omap_sram_idle(void)
_omap_sram_idle(omap3_arm_context, save_state);
cpu_init();
+
if (is_suspending())
pm_dbg_regset_save(2);
+ /* Ensure that Mpu state is restored back as ON
+ * after coming out of suspend/Idle.
+ */
+ prm_rmw_mod_reg_bits(OMAP_POWERSTATEST_MASK, 0x3,
+ MPU_MOD, PM_PWSTCTRL);
/* Restore normal SDRC POWER settings */
if (omap_rev() = OMAP3430_REV_ES3_0
@@ -1209,10 +1215,16 @@ void omap3_pm_off_mode_enable(int enable
resource_unlock_opp(VDD1_OPP);
resource_unlock_opp(VDD2_OPP);
#endif
+ /* For Mpu only next state should be set as OFF, the
+ * powerstate bits of PM_PWSTCTRL_MPU should not be explicitily
+ * set as OFF
+ */
+
list_for_each_entry(pwrst, pwrst_list, node) {
if (strcmp(iva2_pwrdm, pwrst-pwrdm-name)) {
pwrst-next_state = state;
- set_pwrdm_state(pwrst-pwrdm, state);
+ if (strcmp(mpu_pwrdm, pwrst-pwrdm-name))
+ set_pwrdm_state(pwrst-pwrdm, state);
}
}
}
--
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 L23.I3 PM 1/2 ]: To put all the powerdomains in OFF mode instead of Ret
-Original Message-
From: Gulati, Shweta
Sent: Wednesday, March 24, 2010 7:17 PM
To: linux-omap@vger.kernel.org
Cc: Gulati, Shweta; Sripathy, Vishwanath
Subject: [PATCH L23.I3 PM 1/2 ]: To put all the powerdomains in OFF mode
instead
of Ret
Subject should not have TI internal release names.
Also Cover letter for the patch series is missing
From: Shweta Gulati shweta.gul...@ti.com
According to Defect OMAPS00210499 CAM, DSS and USBHOST should stay
in OFF state instead of Retention in OS Idle Path.
This Patch puts all the powerdomain in OFF state by default
in pm init code and ensures that Mpu next state is OFF only
before it goes to Suspend/Idle.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
Index: kernel-omap3-dev/arch/arm/mach-omap2/cpuidle34xx.c
=
==
--- kernel-omap3-dev.orig/arch/arm/mach-omap2/cpuidle34xx.c
+++ kernel-omap3-dev/arch/arm/mach-omap2/cpuidle34xx.c
@@ -144,11 +144,14 @@ static int omap3_enter_idle(struct cpuid
local_irq_disable();
local_fiq_disable();
- if (!enable_off_mode) {
+ if (disable_off_mode) {
if (mpu_state PWRDM_POWER_RET)
mpu_state = PWRDM_POWER_RET;
if (core_state PWRDM_POWER_RET)
core_state = PWRDM_POWER_RET;
+ } else {
+ mpu_state = PWRDM_POWER_OFF;
+ core_state = PWRDM_POWER_OFF;
}
/* For any state above inactive set the logic and memory retention
Index: kernel-omap3-dev/arch/arm/mach-omap2/pm-debug.c
=
==
--- kernel-omap3-dev.orig/arch/arm/mach-omap2/pm-debug.c
+++ kernel-omap3-dev/arch/arm/mach-omap2/pm-debug.c
@@ -548,7 +548,7 @@ static int option_set(void *data, u64 va
*option = val;
- if (option == enable_off_mode)
+ if (option == disable_off_mode)
omap3_pm_off_mode_enable(val);
return 0;
}
@@ -597,8 +597,8 @@ static int __init pm_dbg_init(void)
}
- (void) debugfs_create_file(enable_off_mode, S_IRUGO | S_IWUGO, d,
-enable_off_mode, pm_dbg_option_fops);
+ (void) debugfs_create_file(disable_off_mode, S_IRUGO | S_IWUGO, d,
+disable_off_mode, pm_dbg_option_fops);
(void) debugfs_create_file(sleep_while_idle, S_IRUGO | S_IWUGO, d,
sleep_while_idle, pm_dbg_option_fops);
(void) debugfs_create_file(enable_oswr, S_IRUGO | S_IWUGO, d,
Index: kernel-omap3-dev/arch/arm/mach-omap2/pm.h
=
==
--- kernel-omap3-dev.orig/arch/arm/mach-omap2/pm.h
+++ kernel-omap3-dev/arch/arm/mach-omap2/pm.h
@@ -13,7 +13,7 @@
#include plat/powerdomain.h
-extern u32 enable_off_mode;
+extern u32 disable_off_mode;
extern u32 sleep_while_idle;
extern u32 enable_oswr;
extern u32 voltage_off_while_idle;
Index: kernel-omap3-dev/arch/arm/mach-omap2/pm34xx.c
=
==
--- kernel-omap3-dev.orig/arch/arm/mach-omap2/pm34xx.c
+++ kernel-omap3-dev/arch/arm/mach-omap2/pm34xx.c
@@ -75,7 +75,7 @@ static inline bool is_suspending(void)
#define OMAP3630_EFUSE_CNTRL 0x48002A8C
#define ABO_LDO_TRANXDONE_TIMEOUT100
-u32 enable_off_mode;
+u32 disable_off_mode;
u32 sleep_while_idle;
u32 enable_oswr;
u32 wakeup_timer_seconds;
@@ -1197,15 +1197,15 @@ static void __init prcm_setup_regs(void)
omap3_d2d_idle();
}
-void omap3_pm_off_mode_enable(int enable)
+void omap3_pm_off_mode_enable(int disable)
{
struct power_state *pwrst;
u32 state;
- if (enable)
- state = PWRDM_POWER_OFF;
- else
+ if (disable)
state = PWRDM_POWER_RET;
+ else
+ state = PWRDM_POWER_OFF;
#ifdef CONFIG_OMAP_PM_SRF
resource_lock_opp(VDD1_OPP);
@@ -1303,7 +1303,8 @@ static int __init pwrdms_setup(struct po
if (!pwrst)
return -ENOMEM;
pwrst-pwrdm = pwrdm;
- if (strcmp(iva2_pwrdm, pwrdm-name))
+ if (!strcmp(mpu_pwrdm, pwrdm-name) ||
+ !strcmp(core_pwrdm, pwrdm-name))
pwrst-next_state = PWRDM_POWER_RET;
else
pwrst-next_state = PWRDM_POWER_OFF;
Index: kernel-omap3-dev/arch/arm/mach-omap2/resource34xx.c
=
==
--- kernel-omap3-dev.orig/arch/arm/mach-omap2/resource34xx.c
+++ kernel-omap3-dev/arch/arm/mach-omap2/resource34xx.c
@@ -106,7 +106,7 @@ void init_pd_latency(struct shared_resou
struct pd_latency_db *pd_lat_db;
resp-no_of_users = 0;
- if (enable_off_mode)
+ if (!disable_off_mode)
resp-curr_level = PD_LATENCY_OFF;
else
RE: [PATCH v4 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS
-Original Message- From: K, Ambresh Sent: Thursday, March 18, 2010 12:46 PM To: Gurav , Pramod Cc: linux-omap@vger.kernel.org; Reddy, Teerth; Sripathy, Vishwanath Subject: Re: [PATCH v4 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS Gurav , Pramod wrote: From: Teerth Reddy tee...@ti.com The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. The wait time for L3 clock stabilization is calculated using the formula = 4*REFCLK + 8*CLKOUTX2, which uses the M, N and M2 read from the registers. Since this gives slightly less value, 2us is added as buffer for safety. This works fine for omap3. Signed-off-by: Teerth Reddy tee...@ti.com Signed-off-by: Pramod Gurav pramod.gu...@ti.com Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com --- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 54 +++- arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx.c|2 +- arch/arm/mach-omap2/clock3xxx.h|1 + arch/arm/mach-omap2/clock3xxx_data.c | 13 arch/arm/mach-omap2/sram34xx.S |8 + arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 51 ++ 8 files changed, 126 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach- omap2/clkt34xx_dpll3m2.c index b2b1e37..29421b1 100644 --- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c +++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c @@ -24,13 +24,21 @@ #include plat/clock.h #include plat/sram.h #include plat/sdrc.h +#include plat/prcm.h #include clock.h #include clock3xxx.h #include clock34xx.h #include sdrc.h -#define CYCLES_PER_MHZ 100 +#defineCYCLES_PER_MHZ 100 + +#defineDPLL_M_MASK 0x7ff +#defineDPLL_N_MASK 0x7f +#defineDPLL_M2_MASK0x1f +#defineSHIFT_DPLL_M16 +#defineSHIFT_DPLL_N8 +#defineSHIFT_DPLL_M2 27 /* * CORE DPLL (DPLL3) M2 divider rate programming functions @@ -56,6 +64,11 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) struct omap_sdrc_params *sdrc_cs0; struct omap_sdrc_params *sdrc_cs1; int ret; + u32 clk_sel_regval; + u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2; + u32 sys_clk_rate, sdrc_clk_stab; + u32 refclk, clkoutx2, switch_latency; + unsigned int delay_sram; if (!clk || !rate) return -EINVAL; @@ -79,16 +92,41 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) unlock_dll = 1; } + clk_sel_regval = __raw_readl(clk-clksel_reg); + + /* Get the M, N and M2 values required for getting sdrc clk stab */ + core_dpll_mul_m = (clk_sel_regval SHIFT_DPLL_M) DPLL_M_MASK; + core_dpll_div_n = (clk_sel_regval SHIFT_DPLL_N) DPLL_N_MASK; + core_dpll_clkoutdiv_m2 = (clk_sel_regval SHIFT_DPLL_M2) + DPLL_M2_MASK; + sys_clk_rate = clk_get_rate(sys_ck_p); + + sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ; + + /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */ + refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate; + clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) / + (sys_clk_rate * core_dpll_mul_m * 2); + switch_latency = refclk + 8 * clkoutx2; + + /* Adding 2us to sdrc clk stab */ + sdrc_clk_stab = switch_latency + 2; + + delay_sram = delay_sram_val(); + /* -* XXX This only needs to be done when the CPU frequency changes +* Calculate the number of MPU cycles +* to wait for SDRC to stabilize */ + _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ; - c = (_mpurate SDRC_MPURATE_SCALE) SDRC_MPURATE_BASE_SHIFT; - c += 1; /* for safety */ - c *= SDRC_MPURATE_LOOPS; - c = SDRC_MPURATE_SCALE; - if (c == 0) - c = 1; + + c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2)); + + pr_debug(m = %d, n = %d, m2 =%d\n, core_dpll_mul_m, core_dpll_div_n, + core_dpll_clkoutdiv_m2); + pr_debug(switch_latency = %d, sys_clk_rate = %d, cycles = %d\n, + switch_latency, sys_clk_rate, c); pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n, clk-rate, validrate); diff --git a/arch/arm/mach-omap2
RE: [PATCH v2 2/2] OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630
-Original Message-
From: K, Ambresh
Sent: Thursday, March 18, 2010 12:48 PM
To: Gurav , Pramod
Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
Subject: Re: [PATCH v2 2/2] OMAP3630 SDRC: Change in DVFS Latency Formula for
OMAP3630
Gurav , Pramod wrote:
This patch uses new formula to derive the dpll3 clock Stabilization
delay during DVFS for OMAP3630. The formula used is :
Latency = 2 * SYS_CLK + 10 * CLKOUTX2
1usec buffer time is added for safety.
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Pramod Gurav pramod.gu...@ti.com
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 60
++--
1 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach-
omap2/clkt34xx_dpll3m2.c
index 29421b1..58979ec 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -40,6 +40,9 @@
#defineSHIFT_DPLL_N8
#defineSHIFT_DPLL_M2 27
+#defineAVOID_TRUNC_10001000
+#defineAVOID_TRUNC_100 100
+
/*
* CORE DPLL (DPLL3) M2 divider rate programming functions
*
@@ -67,7 +70,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
u32 clk_sel_regval;
u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2;
u32 sys_clk_rate, sdrc_clk_stab;
- u32 refclk, clkoutx2, switch_latency;
+ u32 refclk, clkoutx2, switch_latency, dpll_lock_freq;
unsigned int delay_sram;
if (!clk || !rate)
@@ -100,28 +103,47 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk,
unsigned long rate)
core_dpll_clkoutdiv_m2 = (clk_sel_regval SHIFT_DPLL_M2)
DPLL_M2_MASK;
sys_clk_rate = clk_get_rate(sys_ck_p);
-
sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ;
- /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
- refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
- clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
- (sys_clk_rate * core_dpll_mul_m * 2);
- switch_latency = refclk + 8 * clkoutx2;
-
- /* Adding 2us to sdrc clk stab */
- sdrc_clk_stab = switch_latency + 2;
-
- delay_sram = delay_sram_val();
-
- /*
-* Calculate the number of MPU cycles
-* to wait for SDRC to stabilize
-*/
-
_mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
+ delay_sram = delay_sram_val();
- c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+ if (cpu_is_omap3630()) {
+ /*
+* wait time for L3 clk stabilization =
+* 2*SYS_CLK + 10*CLKOUTX2
+*/
+ /*
+* To avoid truncation of floating values, AVOID_TRUNC_1000
+* AVOID_TRUNC_100 are multiplied and divided appropriately
+*/
+ refclk = 2 * (AVOID_TRUNC_1000 / sys_clk_rate);
+ dpll_lock_freq = (AVOID_TRUNC_1000 * AVOID_TRUNC_100 *
+ (core_dpll_div_n + 1))/
+ (2 * sys_clk_rate * core_dpll_mul_m);
+ clkoutx2 = 10 * (dpll_lock_freq * core_dpll_clkoutdiv_m2) /
+ AVOID_TRUNC_100;
+ switch_latency = refclk + clkoutx2;
+
+ /* Adding 1000 nano seconds to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 1000;
+ c = ((sdrc_clk_stab * _mpurate) /
+ (delay_sram * 2 * AVOID_TRUNC_1000));
+ } else {
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+ refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
+ clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
+ (sys_clk_rate * core_dpll_mul_m * 2);
+ switch_latency = refclk + 8 * clkoutx2;
+
+ /* Adding 2us to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2;
+ /*
+* Calculate the number of MPU cycles to wait for
+* SDRC to stabilize
+*/
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+ }
-PFA,
- Attached patch provides further optimized 3630 3430 path for
calculating M2 stablization delay.
- The formula used to compute clkoutx2, is actually calculating for
clkoutm2x2 according to trm clkoutx2 = (Fref * 2 * M)/ (N + 1).
(Thanks to Eduardo for pointing this).
No, CLKOUTX2 is dependent on M2. Pls refer to table 3-45 (DPLL Operating Mode
and Latency) in 3630 TRM Version D.
Regards
Vishwa
Thanks,
Ambresh
pr_debug(m = %d, n = %d, m2 =%d\n, core_dpll_mul_m, core_dpll_div_n
[PATCH] OMAP3 PM : Remove IVA state conflict between PM and DspBridge code
From: Shweta Gulati shweta.gul...@ti.com
When the Dsp Bridge module is loaded, the state Of Iva Power domain
configured in suspend path (provided enable_off_mode is disabled) by
DspBridge code and PM code are different so IVA does not
enter the target state .Per and Core domain have sleep dependency over IVA,
so they also don't enter.
This Patch puts IVA to Off and in suspend path the code
excludes IVA state transition through PM code ,thus only DspBridge
code handles IVA state.And all the powerdomains enter target state
(RETENTION or OFF)in suspend path.
Signed-off-by: Sripathy Vishwanath vishwanath...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
Index: kernel-omap3/arch/arm/mach-omap2/pm34xx.c
===
--- kernel-omap3.orig/arch/arm/mach-omap2/pm34xx.c
+++ kernel-omap3/arch/arm/mach-omap2/pm34xx.c
@@ -764,16 +764,20 @@ static int omap3_pm_suspend(void)
omap2_pm_wakeup_on_timer(wakeup_timer_seconds);
/* Read current next_pwrsts */
- list_for_each_entry(pwrst, pwrst_list, node)
- pwrst-saved_state = pwrdm_read_next_pwrst(pwrst-pwrdm);
- /* Set ones wanted by suspend */
list_for_each_entry(pwrst, pwrst_list, node) {
- if (set_pwrdm_state(pwrst-pwrdm, pwrst-next_state))
- goto restore;
- if (pwrdm_clear_all_prev_pwrst(pwrst-pwrdm))
- goto restore;
+ if (strcmp(iva2_pwrdm, pwrst-pwrdm-name))
+ pwrst-saved_state =
+ pwrdm_read_next_pwrst(pwrst-pwrdm);
+ }
+ /* Set ones wanted by suspend */
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ if (strcmp(iva2_pwrdm, pwrst-pwrdm-name)) {
+ if (set_pwrdm_state(pwrst-pwrdm, pwrst-next_state))
+ goto restore;
+ if (pwrdm_clear_all_prev_pwrst(pwrst-pwrdm))
+ goto restore;
+ }
}
-
omap_uart_prepare_suspend();
omap3_intc_suspend();
@@ -782,14 +786,16 @@ static int omap3_pm_suspend(void)
restore:
/* Restore next_pwrsts */
list_for_each_entry(pwrst, pwrst_list, node) {
- state = pwrdm_read_prev_pwrst(pwrst-pwrdm);
- if (state pwrst-next_state) {
- printk(KERN_INFO Powerdomain (%s) didn't enter
- target state %d\n,
- pwrst-pwrdm-name, pwrst-next_state);
- ret = -1;
+ if (strcmp(iva2_pwrdm, pwrst-pwrdm-name)) {
+ state = pwrdm_read_prev_pwrst(pwrst-pwrdm);
+ if (state pwrst-next_state) {
+ printk(KERN_INFO Powerdomain (%s) didn't enter
+ target state %d\n, pwrst-pwrdm-name,
+ pwrst-next_state);
+ ret = -1;
+ }
+ set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
}
- set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
}
if (ret)
printk(KERN_ERR Could not enter target state in pm_suspend\n);
@@ -1136,6 +1142,12 @@ static void __init prcm_setup_regs(void)
/* Clear any pending PRCM interrupts */
prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+/* Put the IVA2 In Idle */
+ prm_rmw_mod_reg_bits(OMAP3430_LASTPOWERSTATEENTERED_MASK, 0,
+ OMAP3430_IVA2_MOD, PM_PWSTCTRL);
+ /* Make Clock transition Automatic */
+ cm_rmw_mod_reg_bits(OMAP3430_CLKTRCTRL_IVA2_MASK, 0x3,
+ OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
omap3_iva_idle();
omap3_d2d_idle();
@@ -1160,8 +1172,10 @@ void omap3_pm_off_mode_enable(int disabl
resource_unlock_opp(VDD2_OPP);
#endif
list_for_each_entry(pwrst, pwrst_list, node) {
- pwrst-next_state = state;
- set_pwrdm_state(pwrst-pwrdm, state);
+ if (strcmp(iva2_pwrdm, pwrst-pwrdm-name)) {
+ pwrst-next_state = state;
+ set_pwrdm_state(pwrst-pwrdm, state);
+ }
}
}
@@ -1274,7 +1288,10 @@ static int __init pwrdms_setup(struct po
if (!pwrst)
return -ENOMEM;
pwrst-pwrdm = pwrdm;
- pwrst-next_state = PWRDM_POWER_RET;
+ if (strcmp(iva2_pwrdm, pwrdm-name))
+ pwrst-next_state = PWRDM_POWER_RET;
+ else
+pwrst-next_state = PWRDM_POWER_OFF;
list_add(pwrst-node, pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
--
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
RE: [PATCH] OMAP3 PM: Disable SR only during Device Retention/OFF
Kevin,
Can you pls take this patch if there are no comments?
Regards
Vishwa
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
Sent: Thursday, January 07, 2010 11:22 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP3 PM: Disable SR only during Device Retention/OFF
Currently in omap_sram_idle function, SR is disabled whenever next state
is retention/OFF w/o checking whether system can really enter retention/off.
This patch adds another condition to disable SR. Basically FCLK register for
Core and PER are checked before disabling SR. THis will give some more power
savings in MP3 usecase (where Core enters retention where as PER does not).
Tested OMAP3430 ZOOM2
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3868cdf..13c5dfb
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -479,6 +479,7 @@ void omap_sram_idle(void)
int mpu_logic_state, mpu_mem_state, core_logic_state, core_mem_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
+ u32 fclk_status;
if (!_omap_sram_idle)
return;
@@ -545,15 +546,6 @@ void omap_sram_idle(void)
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.
- */
- if (mpu_next_state = PWRDM_POWER_RET)
- disable_smartreflex(SR1);
- if (core_next_state = PWRDM_POWER_RET)
- disable_smartreflex(SR2);
-
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0, core_next_state core_logic_state);
@@ -600,6 +592,21 @@ void omap_sram_idle(void)
omap3_intc_prepare_idle();
/*
+ * Disable smartreflex before entering WFI.
+ * Only needed if we are going to enter retention or off.
+ */
+ fclk_status = cm_read_mod_reg(OMAP3430_PER_MOD, CM_FCLKEN) |
+ cm_read_mod_reg(CORE_MOD, CM_FCLKEN1) |
+ cm_read_mod_reg(CORE_MOD, OMAP3430ES2_CM_FCLKEN3);
+
+ if (!fclk_status) {
+ if (mpu_next_state = PWRDM_POWER_RET)
+ disable_smartreflex(SR1);
+ if (core_next_state = PWRDM_POWER_RET)
+ disable_smartreflex(SR2);
+ }
+
+ /*
* On EMU/HS devices ROM code restores a SRDC value
* from scratchpad which has automatic self refresh on timeout
* of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
@@ -685,11 +692,12 @@ void omap_sram_idle(void)
* Enable smartreflex after WFI. Only needed if we entered
* retention or off
*/
- if (mpu_next_state = PWRDM_POWER_RET)
- enable_smartreflex(SR1);
- if (core_next_state = PWRDM_POWER_RET)
- enable_smartreflex(SR2);
-
+ if (!fclk_status) {
+ if (mpu_next_state = PWRDM_POWER_RET)
+ enable_smartreflex(SR1);
+ if (core_next_state = PWRDM_POWER_RET)
+ enable_smartreflex(SR2);
+ }
/* PER */
if (per_next_state PWRDM_POWER_ON) {
if (per_next_state == PWRDM_POWER_OFF) {
--
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: [PATCHV4 3/4] OMAP3: Introduce 3630 DPLL4 HSDivider changes
Hi Paul,
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, January 08, 2010 3:14 AM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHV4 3/4] OMAP3: Introduce 3630 DPLL4 HSDivider changes
Hello Vishwanath,
some more comments.
On Thu, 7 Jan 2010, Vishwanath BS wrote:
DPLL4 HS Divider (M2, M3, M4, M5 and M6) field width has been increased by
1 bit
in 3630.
This patch has changes to accommodate this in CM dynamically based on chip
version.
Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and M6
and
value of these nodes are used if cpu type is 3630.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx_data.c| 125
++-
arch/arm/mach-omap2/cm-regbits-34xx.h |8 ++-
arch/arm/plat-omap/include/plat/clock.h |1 +
3 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c b/arch/arm/mach-
omap2/clock34xx_data.c
index 66a3a96..04c8e3c 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -236,6 +236,42 @@ static const struct clksel_rate div16_dpll_rates[] = {
{ .div = 0 }
};
+static const struct clksel_rate div32_dpll_rates[] = {
Please rename this to something like 'div32_dpll4_rates_3630' to indicate
that it is DPLL4-specific and 3630-specific.
OK
+ { .div = 1, .val = 1, .flags = RATE_IN_36XX | DEFAULT_RATE },
+ { .div = 2, .val = 2, .flags = RATE_IN_36XX },
+ { .div = 3, .val = 3, .flags = RATE_IN_36XX },
+ { .div = 4, .val = 4, .flags = RATE_IN_36XX },
+ { .div = 5, .val = 5, .flags = RATE_IN_36XX },
+ { .div = 6, .val = 6, .flags = RATE_IN_36XX },
+ { .div = 7, .val = 7, .flags = RATE_IN_36XX },
+ { .div = 8, .val = 8, .flags = RATE_IN_36XX },
+ { .div = 9, .val = 9, .flags = RATE_IN_36XX },
+ { .div = 10, .val = 10, .flags = RATE_IN_36XX },
+ { .div = 11, .val = 11, .flags = RATE_IN_36XX },
+ { .div = 12, .val = 12, .flags = RATE_IN_36XX },
+ { .div = 13, .val = 13, .flags = RATE_IN_36XX },
+ { .div = 14, .val = 14, .flags = RATE_IN_36XX },
+ { .div = 15, .val = 15, .flags = RATE_IN_36XX },
+ { .div = 16, .val = 16, .flags = RATE_IN_36XX },
+ { .div = 17, .val = 17, .flags = RATE_IN_36XX },
+ { .div = 18, .val = 18, .flags = RATE_IN_36XX },
+ { .div = 19, .val = 19, .flags = RATE_IN_36XX },
+ { .div = 20, .val = 20, .flags = RATE_IN_36XX },
+ { .div = 21, .val = 21, .flags = RATE_IN_36XX },
+ { .div = 22, .val = 22, .flags = RATE_IN_36XX },
+ { .div = 23, .val = 23, .flags = RATE_IN_36XX },
+ { .div = 24, .val = 24, .flags = RATE_IN_36XX },
+ { .div = 25, .val = 25, .flags = RATE_IN_36XX },
+ { .div = 26, .val = 26, .flags = RATE_IN_36XX },
+ { .div = 27, .val = 27, .flags = RATE_IN_36XX },
+ { .div = 28, .val = 28, .flags = RATE_IN_36XX },
+ { .div = 29, .val = 29, .flags = RATE_IN_36XX },
+ { .div = 30, .val = 30, .flags = RATE_IN_36XX },
+ { .div = 31, .val = 31, .flags = RATE_IN_36XX },
+ { .div = 32, .val = 32, .flags = RATE_IN_36XX },
+ { .div = 0 }
+};
+
/* DPLL1 */
/* MPU clock source */
/* Type: DPLL */
@@ -587,6 +623,17 @@ static struct clk dpll4_ck = {
.recalc = omap3_dpll_recalc,
};
+static struct clk dpll4_ck_3630 __initdata = {
Marking these as __initdata will crash the system for DVFS changes after
the kernel boots. Please fix.
Sorry I did not understand why it should crash the system for DVFS?
dpll4_ck_3630 is not used anywhere after it's values are copied into dpll4_ck
as part of clock_init. Same is the case with others.
+ .name = dpll4_ck,
+ .ops= clkops_noncore_dpll_ops,
+ .parent = sys_ck,
+ .dpll_data = dpll4_dd_3630,
+ .round_rate = omap2_dpll_round_rate,
+ .set_rate = omap3_dpll4_set_rate,
+ .clkdm_name = dpll4_clkdm,
+ .recalc = omap3_dpll_recalc,
+};
+
/*
* This virtual clock provides the CLKOUTX2 output from the DPLL if the
* DPLL isn't bypassed --
@@ -605,6 +652,11 @@ static const struct clksel div16_dpll4_clksel[] = {
{ .parent = NULL }
};
+static const struct clksel div32_dpll4_clksel[] = {
+ { .parent = dpll4_ck, .rates = div32_dpll_rates },
+ { .parent = NULL }
+};
+
/* This virtual clock is the source for dpll4_m2x2_ck */
static struct clk dpll4_m2_ck = {
.name = dpll4_m2_ck,
@@ -618,6 +670,18 @@ static struct clk dpll4_m2_ck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk dpll4_m2_ck_3630 __initdata = {
+ .name = dpll4_m2_ck,
+ .ops= clkops_null,
+ .parent = dpll4_ck,
+ .init = omap2_init_clksel_parent,
+ .clksel_reg = OMAP_CM_REGADDR(PLL_MOD
RE: [PATCH 8/10] OPP layer and additional cleanups
Romit,
With VDD1 OPP resource being removed, how are you maitaning link between MPU
and DSP frequencies? I could not find such a link in the below code. May be I
am missing something??
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit
Sent: Thursday, December 31, 2009 7:00 PM
To: p...@pwsan.com; Menon, Nishanth; khil...@deeprootsystems.com
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 8/10] OPP layer and additional cleanups
1. Removed the OPP resources and instead introduced voltage resources.
This leads to a leaner implementation of DVFS. It still has scope for
cleanup and this will be done soon.
2. Introduced a L3 frequency resource a.k.a. l3_freq.
3. L3 frequency changes are now handled through CPUFREQ notifiers.
4. The frequency resources use the new OPP layer APIs.
5. Removed hardcoded call to vcbypass function of the smartreflex driver.
Now we invoke the generic voltage scaling function.
diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-
omap2/resource34xx.c
index 157b38e..59b8faa 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -37,6 +37,8 @@
#warning MPU latency constraints require CONFIG_CPU_IDLE to function!
#endif
+static struct device vdd1_volt_dev, vdd2_volt_dev;
+
/**
* init_latency - Initializes the mpu/core latency resource.
* @resp: Latency resource to be initalized
@@ -146,115 +148,6 @@ int set_pd_latency(struct shared_resource *resp, u32
latency)
return 0;
}
-static struct shared_resource *vdd1_resp;
-static struct shared_resource *vdd2_resp;
-static struct device dummy_mpu_dev;
-static struct device dummy_dsp_dev;
-static struct device vdd2_dev;
-static int vdd1_lock;
-static int vdd2_lock;
-static struct clk *dpll1_clk, *dpll2_clk, *dpll3_clk;
-static int curr_vdd1_opp;
-static int curr_vdd2_opp;
-static DEFINE_MUTEX(dvfs_mutex);
-
-/**
- * opp_to_freq - convert OPPID to frequency (DEPRECATED)
- * @freq: return frequency back to caller
- * @opps: opp list
- * @opp_id: OPP ID we are searching for
- *
- * return 0 and freq is populated if we find the opp_id, else,
- * we return error
- *
- * NOTE: this function is a standin for the timebeing as opp_id is deprecated
- */
-static int __deprecated opp_to_freq(unsigned long *freq,
- const struct omap_opp *opps, u8 opp_id)
-{
- struct omap_opp *opp;
-
- BUG_ON(!freq || !opps);
-
- opp = opp_find_by_opp_id(opps, opp_id);
- if (!opp)
- return -EINVAL;
-
- *freq = opp_get_freq(opp);
-
- return 0;
-}
-
-/**
- * freq_to_opp - convert a frequency back to OPP ID (DEPRECATED)
- * @opp_id: opp ID returned back to caller
- * @opps: opp list
- * @freq: frequency we are searching for
- *
- * return 0 and opp_id is populated if we find the freq, else, we return
error
- *
- * NOTE: this function is a standin for the timebeing as opp_id is deprecated
- */
-static int __deprecated freq_to_opp(u8 *opp_id, struct omap_opp *opps,
- unsigned long freq)
-{
- struct omap_opp *opp;
-
- BUG_ON(!opp_id || !opps);
- opp = opp_find_freq_ceil(opps, freq);
- if (IS_ERR(opp))
- return -EINVAL;
- *opp_id = opp_get_opp_id(opp);
- return 0;
-}
-
-/**
- * init_opp - Initialize the OPP resource
- */
-void init_opp(struct shared_resource *resp)
-{
- struct clk *l3_clk;
- int ret;
- u8 opp_id;
- resp-no_of_users = 0;
-
- if (!mpu_opps || !dsp_opps || !l3_opps)
- return;
-
- /* Initialize the current level of the OPP resource
- * to the opp set by u-boot.
- */
- if (strcmp(resp-name, vdd1_opp) == 0) {
- vdd1_resp = resp;
- dpll1_clk = clk_get(NULL, dpll1_ck);
- dpll2_clk = clk_get(NULL, dpll2_ck);
- ret = freq_to_opp(opp_id, mpu_opps, dpll1_clk-rate);
- BUG_ON(ret); /* TBD Cleanup handling */
- curr_vdd1_opp = opp_id;
- } else if (strcmp(resp-name, vdd2_opp) == 0) {
- vdd2_resp = resp;
- dpll3_clk = clk_get(NULL, dpll3_m2_ck);
- l3_clk = clk_get(NULL, l3_ick);
- ret = freq_to_opp(opp_id, l3_opps, l3_clk-rate);
- BUG_ON(ret); /* TBD Cleanup handling */
- curr_vdd2_opp = opp_id;
- }
- resp-curr_level = opp_id;
- return;
-}
-
-int resource_access_opp_lock(int res, int delta)
-{
- if (res == VDD1_OPP) {
- vdd1_lock += delta;
- return vdd1_lock;
- } else if (res == VDD2_OPP) {
- vdd2_lock += delta;
- return vdd2_lock;
- }
- return -EINVAL;
-}
-
#ifndef CONFIG_CPU_FREQ
static unsigned long compute_lpj(unsigned long ref, u_int div, u_int mult)
{
@@ -277,235 +170,60 @@ static unsigned long
RE: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp
Nishant,
Have you tested your opp patches on 3630? Apparently opp changes in wip branch
does not even boot on ZOOM3 board.
Vishwa
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 07, 2010 5:16 AM
To: Kevin Hilman
Cc: linux-omap; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan; Paul
Walmsley; Dasgupta, Romit; Premi, Sanjeev; Shilimkar, Santosh; Aguirre,
Sergio;
Gopinath, Thara; Sripathy, Vishwanath; K, Ambresh
Subject: Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp
Kevin Hilman had written, on 12/22/2009 10:45 AM, the following:
Menon, Nishanth n...@ti.com writes:
Kevin Hilman said the following on 12/19/2009 04:42 AM:
Nishanth Menon n...@ti.com writes:
SmartReflex implements a get_opp to search through the opp table,
replace it with the accessor function as it is a duplicate of
freq_to_opp
SmartReflex is not quite working with this version which is in
pm-wip-opp. My (untested) theory below...
[...]
Ambresh and I just tested the very latest of the pm-wip-opp branch
and checked. Voltage transitions and SR adjustments are happily
happening on SDP3430 ES3.1 at the very least (verified with a scope on
vdd1).
and if you look closely in the code, sr2.vdd_opp_clk-rate and
sr1.vdd_opp_clk-rate are based on
sr1.vdd_opp_clk = clk_get(NULL, dpll1_ck)
sr2.vdd_opp_clk = clk_get(NULL, l3_ick);
now, if the dpll1_ck -rate and l3_ick-rate are not exact frequencies
as the opp tables, I think we have a clockframework bug and the code
here is correct. we should fix the clockframework/find the rootcause
elsewhere.
Now is the clockframework wrong? we added a patch to print the
frequencies and checked if IS_ERR(opp) is true - not a single call
while using cpu_freq transitions resulted in an error value and all
the frequencies we printed were from the OPP table
Might be good to hear your rationale for saying this result..
Part of my rationale was that the PM branch version get_vdd1_opp()
does an approximate match (actually the equivalent of
opp_find_freq_ceil() via get_opp.) So you replaced an approximate
match with an exact match. That may be the right solution and point
to a bug elsewhere, but it was not an equivalent replacement, and
probably should've been done in a separate patch with
justification/rationale. I didn't catch it during initial review.
But the primary reason I noticed it in the first place was that I was
seeing DVFS errors on n900, which is the only platform I have that
actually can do SmartReflex. Specifically, sr_reset_voltage() is
failing for VDD1. Dumping out the clock rates used in get_vdd1_opp()
show that the clocks rates are close, but not the exact value used in
the OPP table.
Here is the patch I used to add some debugging, and I see that for the
250MHz OPP, the clock framework rate is 24960 and for the 125MHz
OPP, the clock rate is 12480. As I said, close, but clearly an
find with exact match is going to fail.
Below the patch, is the console dump and backtrace of how get_vdd1_opp()
was called so you can see the call chain.
Kevin
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
omap2/smartreflex.c
index d341857..01a3dbd 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -155,6 +155,8 @@ static u8 get_vdd1_opp(void)
mpu_opps == NULL)
return 0;
+ printk(%s: sr1.vdd_opp_clk-rate = %d\n, __func__,
+ sr1.vdd_opp_clk-rate);
opp = opp_find_freq_exact(mpu_opps, sr1.vdd_opp_clk-rate, true);
if (IS_ERR(opp))
return 0;
@@ -451,6 +453,7 @@ static int sr_reset_voltage(int srid)
target_opp_no = get_vdd1_opp();
if (!target_opp_no) {
pr_info(Current OPP unknown: Cannot reset voltage\n);
+ __backtrace();
return 1;
}
/sys/devices/system/cpu/cpu0/cpufreq # echo 25 scaling_setspeed
get_vdd1_opp: sr1.vdd_opp_clk-rate = 24960
Current OPP unknown: Cannot reset voltage
[c0042c98] (sr_reset_voltage+0x0/0x190) from [c0043094]
(sr_stop_vddautocomap+0x12c/0x148)
r7:0001 r6:0001 r5:c03ac878 r4:
[c0042f68] (sr_stop_vddautocomap+0x0/0x148) from [c0043388]
(sr_voltagescale_vcbypass+0x2c/0x170)
[...]
Throws up my hands! 3430 on N900/SDP3430 should be essentially the same!
Configuration:
==
kernel:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
branch:
pm-wip-opp 6e1276f omap3:pm: remove map3_[mpu|dsp|l3]_rate_tables
Applied my bugfix: http://patchwork.kernel.org/patch/71457/
I have a 3430 ES3.1 SDP3430 where I did run the test:
Log Patch: http://pastebin.mozilla.org/695225
Test script: http://pastebin.mozilla.org/695226 (I call this test-me.sh)
Result log
RE: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp
Yes Vijay tried with your OPP patches on 3630 ZOOM3 and it seems to work. Vishwa -Original Message- From: Dasgupta, Romit Sent: Thursday, January 07, 2010 2:23 PM To: Sripathy, Vishwanath Cc: Menon, Nishanth; Kevin Hilman; linux-omap; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan; Paul Walmsley; Premi, Sanjeev; Shilimkar, Santosh; Aguirre, Sergio; Gopinath, Thara; K, Ambresh Subject: Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp Sripathy, Vishwanath wrote: Nishant, Have you tested your opp patches on 3630? Apparently opp changes in wip branch does not even boot on ZOOM3 board. Vishwa Vishwa, did you try on top of my OPP patches? Thanks, -Romit -- 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] Generic TRITON power scripts for OMAP3 based boards.
Shouldn't this be a patch series? I think this patch has dependency on previous
patch.
Vishwa
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Lesly A M
Sent: Thursday, January 07, 2010 4:03 PM
To: linux-omap@vger.kernel.org
Cc: Manuel, Lesly Arackal; Menon, Nishanth; Derrick, David;
sa...@linux.intel.com
Subject: [PATCH] Generic TRITON power scripts for OMAP3 based boards.
Changes to move the voltsetup_time sleep/wakeup/warm_rest sequence moved to
new file.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: n...@ti.com
Cc: dderr...@ti.com
Cc: sa...@linux.intel.com
---
arch/arm/mach-omap2/Makefile | 12 ++-
arch/arm/mach-omap2/board-3430sdp.c | 99 +---
arch/arm/mach-omap2/board-zoom-peripherals.c | 98 +---
arch/arm/mach-omap2/twl4030-script.c | 126
++
arch/arm/mach-omap2/twl4030-script.h | 12 +++
5 files changed, 194 insertions(+), 153 deletions(-)
create mode 100644 arch/arm/mach-omap2/twl4030-script.c
create mode 100644 arch/arm/mach-omap2/twl4030-script.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a08aa62..f681325 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -92,7 +92,8 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-
omap3evm.o \
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \
-mmc-twl4030.o
+mmc-twl4030.o \
+twl4030-script.o
obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51)+= board-rx51.o \
board-rx51-sdram.o \
@@ -101,14 +102,17 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-
rx51.o \
obj-$(CONFIG_MACH_OMAP_ZOOM2)+= board-zoom2.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
-board-zoom-debugboard.o
+board-zoom-debugboard.o \
+twl4030-script.o
obj-$(CONFIG_MACH_OMAP_ZOOM3)+= board-zoom3.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
-board-zoom-debugboard.o
+board-zoom-debugboard.o \
+twl4030-script.o
obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \
board-zoom-peripherals.o \
-mmc-twl4030.o
+mmc-twl4030.o \
+twl4030-script.o
obj-$(CONFIG_MACH_CM_T35)+= board-cm-t35.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-
3430sdp.c
index 7ded90f..c89073f 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -46,6 +46,7 @@
#include mux.h
#include sdram-qimonda-hyb18m512160af-6.h
#include mmc-twl4030.h
+#include twl4030-script.h
#include pm.h
#include omap3-opp.h
@@ -446,79 +447,6 @@ static struct twl4030_madc_platform_data
sdp3430_madc_data = {
.irq_line = 1,
};
-
-static struct twl4030_ins __initdata sleep_on_seq[] = {
- /* Broadcast message to put res to sleep */
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0,
RES_TYPE2_R1,
- RES_STATE_SLEEP), 2},
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0,
RES_TYPE2_R2,
- RES_STATE_SLEEP), 2},
-};
-
-static struct twl4030_script sleep_on_script __initdata = {
- .script = sleep_on_seq,
- .size = ARRAY_SIZE(sleep_on_seq),
- .flags = TWL4030_SLEEP_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p12_seq[] __initdata = {
- /* Broadcast message to put res to active */
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0,
RES_TYPE2_R1,
- RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p12_script __initdata = {
- .script = wakeup_p12_seq,
- .size = ARRAY_SIZE(wakeup_p12_seq),
- .flags = TWL4030_WAKEUP12_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p3_seq[] __initdata = {
- /* Broadcast
RE: [PATCHV4 1/3] OMAP3: introduce DPLL4 Jtype
-Original Message-
From: Eduardo Valentin [mailto:eduardo.valen...@nokia.com]
Sent: Tuesday, January 05, 2010 1:06 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org; Paul Walmsley; Woodruff, Richard; Menon,
Nishanth
Subject: Re: [PATCHV4 1/3] OMAP3: introduce DPLL4 Jtype
Hello,
Few little comments bellow.
On Tue, Jan 05, 2010 at 07:36:08AM +0100, ext Vishwanath BS wrote:
DPLL4 for 3630 introduces a changed block requiring special divisor
bits and additional reg fields. To allow for silicons to use this, this
is introduced as a omap3_has_jtype_dpll4() and is enabled for 3630
^
I don't see anywhere in this patch a reference to this function/macro
Yes, omap3_has_jtype_dpll4 is no longer used. This description is borrowed from
previous version of the patch. I will correct it.
silicon. Also FREQSEL field is no longer valid for OMAP3630. So reference
to this is removed for 3630.
Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock.h |3 ++
arch/arm/mach-omap2/clock34xx_data.c|2 +
arch/arm/mach-omap2/clock44xx_data.c|1 +
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/dpll.c | 53
--
arch/arm/plat-omap/include/plat/clock.h |1 +
6 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 93c48df..14f73e7 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -47,6 +47,9 @@
#define DPLL_LOW_POWER_BYPASS 0x5
#define DPLL_LOCKED0x7
+/*DPLL Type and DCO Selection Flags*/
+#define DPLL_J_TYPE0x1
+#define DPLL_NO_DCO_SEL0x2
Add blank line here, just to make it cleaner.
int omap2_clk_init(void);
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock34xx_data.c b/arch/arm/mach-
omap2/clock34xx_data.c
index 043caed..9aac354 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3241,6 +3241,8 @@ int __init omap2_clk_init(void)
cpu_clkflg |= CK_3430ES2;
}
}
+ if (cpu_is_omap3630())
+ dpll4_ck.dpll_data-flags |= DPLL_J_TYPE;
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-
omap2/clock44xx_data.c
index 2210e22..7347246 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2736,6 +2736,7 @@ int __init omap2_clk_init(void)
if (cpu_is_omap44xx()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
+ dpll_usb_ck.dpll_data-flags |= DPLL_NO_DCO_SEL | DPLL_J_TYPE;
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-
regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK (0x7f 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK (0x7 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT 24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff 24)
/* CM_CLKSEL3_PLL */
#define OMAP3430_DIV_96M_SHIFT 0
diff --git a/arch/arm/mach-omap2/dpll.c b/arch/arm/mach-omap2/dpll.c
index f6055b4..d52ab37 100644
--- a/arch/arm/mach-omap2/dpll.c
+++ b/arch/arm/mach-omap2/dpll.c
@@ -238,6 +238,42 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)
}
/**
+ * lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16
+ m, u8 n)
+ {
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ clkinp = clk-parent-rate;
+ fint = (clkinp / n) * m;
+
+ if (fint 10)
+ *dco = 2;
+ else
RE: [PATCH] OMAP3: PM: Dynamic calculation of SDRC clock stabilization delay
Kevin,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Tuesday, December 22, 2009 9:26 PM
To: Reddy, Teerth
Cc: Dasgupta, Romit; linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: PM: Dynamic calculation of SDRC clock
stabilization
delay
Reddy, Teerth tee...@ti.com writes:
Kevin,
Here's an uncompiled, untested version of 'measure_sram_delay' using
the DM Timer API:
unsigned int measure_sram_delay(unsigned int loop)
{
unsigned long start, end, flags;
void (*_omap3_sram_delay)(unsigned long);
_omap3_sram_delay = omap_sram_push(__sram_wait_delay,
__sram_wait_delay_sz);
gpt = omap_dm_timer_request();
if (!gpt)
pr_err(foo);
omap_dm_timer_set_source(gpt, OMAP_TIMER_SRC_SYS_CLK);
omap_dm_timer_set_load_start(gptimer, 0, 0);
local_irq_save(flags);
start = omap_dm_timer_read_counter(gpt);
_omap3_sram_delay(loop);
end = omap_dm_timer_read_counter(gpt);
local_irq_restore(flags);
omap_dm_timer_stop(gpt);
omap_dm_timer_free(gpt);
return end - start;
}
I see one shortcoming with this approach. The DVFS happens even
before the gp timers are initialized, while the kernel boots.
This is a bug. DVFS should be prevented until system is initialized.
I think DVFS is triggered when CPU Freq driver gets initialized. Depending on
the default governor cpufreq tries to scale the frequency which triggers DVFS.
So do you mean to say that cpufreq initialization should be prevented till
GPTimer is initialized?
Kevin
I am trying to use gp timers and I came across this problem. I
didn't see this issue with PMC. Please correct me if my
understanding is wrong.
--Snip---
Kernel command line: mem=128M, console=ttyS0,115200n8 noinitrd
root=/dev/nfs rw nfsroot=172.24.190.217:/data/nfs-
share/teerth/target11,nolock,rsize=1024,wsize=1024 ip=dhcp devfs=mount
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 125780KB available (3496K code, 358K data, 128K init, 0K highmem)
SLUB: Genslabs=9, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:402
Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
Reprogramming SDRC clock to 33200 Hz
--
GPMC revision 5.0
IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP GPIO hardware version 2.5
OMAP clockevent source: GPTIMER1 at 32768 Hz
--
Console: colour dummy device 80x30
Calibrating delay loop... 498.87 BogoMIPS (lpj=1945600)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
regulator: core version 0.5
Regards
Teerth
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] AM35xx: Clock table updates for AM3505/17
Ranjith, Paul,
I am trying do 3630 clock changes on top of this patch. However I am not able
to compile this patch since CK_3XXX etc are not defined. Is there any
dependency to use this patch? If so pls point me.
I am trying on .32.
Vishwa
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Tuesday, December 15, 2009 1:47 AM
To: linux-omap@vger.kernel.org
Cc: Lohithakshan, Ranjith
Subject: [PATCH 2/2] AM35xx: Clock table updates for AM3505/17
From: Ranjith Lohithakshan ranji...@ti.com
AM3505/17 though a OMAP3530 derivative have the following
main differences
- Removal of the following OMAP3 modules
- IVA
- ISP/CAM
- Modem and D2D components (MAD2D, SAD2D)
- USIM
- SSI
- Mailboxes
- USB OTG
- ICR
- MSPRO
- SmartReflex
- SDRC replaced with EMIF4 Controller in the SDRC subsystem
thus adding support for DDR2 memory devices
- Addition of the following new modules
- Ethernet MAC (CPGMAC)
- CAN Controller (HECC)
- New USB OTG Controller with integrated Phy
- Video Processing Front End (VPFE)
- Additional UART (UART4)
- All security accelerators disabled on GP devices and not to
be accessed or configured
This patch defines CPU flags for AM3505/17 and update the clock table.
Clock support for new modules will be added by subsequent patches.
Signed-off-by: Ranjith Lohithakshan ranji...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
[p...@pwsan.com: updated for 2.6.34 clock layout]
---
arch/arm/mach-omap2/clock34xx_data.c | 353 +--
---
1 files changed, 180 insertions(+), 173 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c b/arch/arm/mach-
omap2/clock34xx_data.c
index d714f84..043caed 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -2988,139 +2988,140 @@ static struct clk wdt1_fck = {
* clkdev
*/
-static struct omap_clk omap34xx_clks[] = {
- CLK(NULL, omap_32k_fck, omap_32k_fck, CK_343X),
- CLK(NULL, virt_12m_ck, virt_12m_ck, CK_343X),
- CLK(NULL, virt_13m_ck, virt_13m_ck, CK_343X),
- CLK(NULL, virt_16_8m_ck, virt_16_8m_ck, CK_3430ES2),
- CLK(NULL, virt_19_2m_ck, virt_19_2m_ck, CK_343X),
- CLK(NULL, virt_26m_ck, virt_26m_ck, CK_343X),
- CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_343X),
- CLK(NULL, osc_sys_ck, osc_sys_ck,CK_343X),
- CLK(NULL, sys_ck, sys_ck,CK_343X),
- CLK(NULL, sys_altclk, sys_altclk,CK_343X),
- CLK(NULL, mcbsp_clks, mcbsp_clks,CK_343X),
- CLK(NULL, sys_clkout1, sys_clkout1, CK_343X),
- CLK(NULL, dpll1_ck, dpll1_ck, CK_343X),
- CLK(NULL, dpll1_x2_ck, dpll1_x2_ck, CK_343X),
- CLK(NULL, dpll1_x2m2_ck, dpll1_x2m2_ck, CK_343X),
+/* XXX At some point we should rename this file to clock3xxx_data.c */
+static struct omap_clk omap3xxx_clks[] = {
+ CLK(NULL, omap_32k_fck, omap_32k_fck, CK_3XXX),
+ CLK(NULL, virt_12m_ck, virt_12m_ck, CK_3XXX),
+ CLK(NULL, virt_13m_ck, virt_13m_ck, CK_3XXX),
+ CLK(NULL, virt_16_8m_ck, virt_16_8m_ck, CK_3430ES2 |
CK_AM35XX),
+ CLK(NULL, virt_19_2m_ck, virt_19_2m_ck, CK_3XXX),
+ CLK(NULL, virt_26m_ck, virt_26m_ck, CK_3XXX),
+ CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_3XXX),
+ CLK(NULL, osc_sys_ck, osc_sys_ck,CK_3XXX),
+ CLK(NULL, sys_ck, sys_ck,CK_3XXX),
+ CLK(NULL, sys_altclk, sys_altclk,CK_3XXX),
+ CLK(NULL, mcbsp_clks, mcbsp_clks,CK_3XXX),
+ CLK(NULL, sys_clkout1, sys_clkout1, CK_3XXX),
+ CLK(NULL, dpll1_ck, dpll1_ck, CK_3XXX),
+ CLK(NULL, dpll1_x2_ck, dpll1_x2_ck, CK_3XXX),
+ CLK(NULL, dpll1_x2m2_ck, dpll1_x2m2_ck, CK_3XXX),
CLK(NULL, dpll2_ck, dpll2_ck, CK_343X),
CLK(NULL, dpll2_m2_ck, dpll2_m2_ck, CK_343X),
- CLK(NULL, dpll3_ck, dpll3_ck, CK_343X),
- CLK(NULL, core_ck, core_ck, CK_343X),
- CLK(NULL, dpll3_x2_ck, dpll3_x2_ck, CK_343X),
- CLK(NULL, dpll3_m2_ck, dpll3_m2_ck, CK_343X),
- CLK(NULL, dpll3_m2x2_ck, dpll3_m2x2_ck, CK_343X),
- CLK(NULL, dpll3_m3_ck, dpll3_m3_ck, CK_343X),
- CLK(NULL, dpll3_m3x2_ck, dpll3_m3x2_ck, CK_343X),
- CLK(etb, emu_core_alwon_ck, emu_core_alwon_ck, CK_343X),
- CLK(NULL, dpll4_ck, dpll4_ck, CK_343X),
- CLK(NULL, dpll4_x2_ck,
RE: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, December 15, 2009 12:38 PM To: Cousson, Benoit Cc: Sripathy, Vishwanath; Nayak, Rajendra; ext-ari.kau...@nokia.com; linux- o...@vger.kernel.org; Woodruff, Richard; Menon, Nishanth Subject: RE: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype Hi Benoît, Vishwanath, Thanks for the info, Benoît. On Fri, 11 Dec 2009, Cousson, Benoit wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Thursday, December 10, 2009 10:24 PM Hi Vishwanath, On Tue, 1 Dec 2009, Sripathy, Vishwanath wrote: 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: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, November 30, 2009 3:00 PM To: Sripathy, Vishwanath Cc: ext-ari.kau...@nokia.com; linux-omap@vger.kernel.org; Woodruff, Richard; Menon, Nishanth Subject: Re: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype Hello Vishwanath, a few comments: On Thu, 26 Nov 2009, Vishwanath BS wrote: From: Richard Woodruff r-woodru...@ti.com DPLL4 for 3630 introduces a changed block requiring special divisor bits and additional reg fields. To allow for silicons to use this, this is introduced as a omap3_has_jtype_dpll4() and is enabled for 3630 silicon Tested with 3630 ZOOM3 Could you please consider Ari Kauppi's suggestions that he posted on 30 and 31 October? They look good to me. Here is a link: Regarding comments from Ari Kauppi on addition of dco_sel_mask and sd_div_mask, yes I had a look at them. However I feel, it's better to have these masks in the structure variable. Reason being this approach will help us to support when dpll types for other dplls get changed in future. For example, if dpll3 block is changed, then having new mask will help us to support it. Is there a product coming out that will add more j-type DPLLs with different dco_sel_masks and sd_div_masks? If not, then let's go with Ari's suggested changes, since we don't really know if any more of these j-type DPLLs will be used. We can always add the fields back in when we need them. But if you know for sure that there is a chip variant coming out soon that will use more j-type DPLLs, let's talk about it. OMAP4 is using the same J-type for the DPLL_USB. The programming model is almost the same... sd_div is a the same location, but dco_sel is not there anymore because that DPLL will always be locked at 960MHz and thus will not require the mode for frequency 1GHz. At the DCO location, we have the bypass_clksel, so the code will have to take care of that. 31:24 DPLL_SD_DIV 23DPLL_BYP_CLKSEL 19:8 DPLL_MULT 7:0 DPLL_DIV Vishwanath, it sounds like it makes sense to hardcode the DPLL_SD_DIV and DCO_SEL shifts, since, so far, when present, they are always at the same offset. Instead of using a 'u8 jtype;' it seems to make sense to have a 'u8 flags' and have at least two flags there: DPLL_J_TYPE and DPLL_NO_DCO_SEL. (The latter flag would skip any DCO_SEL reads/writes for J-type DPLLs if it is set, so it will be usable for OMAP4. The code should also warn if DPLL_NO_DCO_SEL is set and DPLL_J_TYPE is not set.) Sound reasonable? Make sense. I will post new set of patches after incorporating all these. Thanks. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHV3 3/4] OMAP3: Correct width for CLKSEL Fields
Paul,
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, November 30, 2009 3:45 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHV3 3/4] OMAP3: Correct width for CLKSEL Fields
Hello Vishwanath,
On Thu, 26 Nov 2009, Vishwanath BS wrote:
DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in
3630.This patch has changes to accommodate this in CM dynamically based
on chip version. Primary changes are
1. Added clksel_mask_3630 to take care clksel width changes
2. CLock nodes which are newly added for 3630 are marked under CK_363X
3. Clock nodes which have changes for 3630 are marked as CK_3XXX | CK_363X
4. Clock nodes which are unchanged for 3630 are retained as CK_3XXX
5. 3630 specific Clock rates are marked as RATE_IN_363X
...
@@ -1232,6 +1238,12 @@ int __init omap2_clk_init(void)
for (c = omap34xx_clks; c omap34xx_clks + ARRAY_SIZE(omap34xx_clks);
c++)
if (c-cpu cpu_clkflg) {
+ /* for 3630, change the mask value for clocks which are
+ marked as CK_363X*/
Please follow the comment style in Documentation/CodingStyle.
+ if (cpu_is_omap3630() (c-cpu CK_363X)) {
+ c-lk.clk-clksel_mask =
+ c-lk.clk-clksel_mask_3630;
+ }
Again, let's avoid dynamic rewriting of the clock tree.
...
@@ -754,7 +796,8 @@ static struct clk dpll4_m4_ck = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_CLKSEL),
.clksel_mask= OMAP3430_CLKSEL_DSS1_MASK,
- .clksel = div16_dpll4_clksel,
+ .clksel_mask_3630 = OMAP3630_CLKSEL_DSS1_MASK,
+ .clksel = div32_dpll4_clksel,
.clkdm_name = dpll4_clkdm,
.recalc = omap2_clksel_recalc,
.set_rate = omap2_clksel_set_rate,
Okay, now I am convinced. We need to explore converting the struct clk
parent pointer into a const char * and a struct clk *, the latter resolved
at clock code init. That should let us split some of these struct clks
that vary between OMAP34xx and OMAP36xx without needing to split other
unrelated sections of the clock tree.
I am thinking of adding a new file called /mach-omap2/clock36xx.h and have
complete 36xx clock tree defined over there instead of tweaking 34xx clock
tree. Any comments?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH]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]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: [PATCHV3 2/4] OMAP3: Clock Type change for OMAP3 Clocks
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, November 30, 2009 1:57 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHV3 2/4] OMAP3: Clock Type change for OMAP3 Clocks
Hi Vishwanath,
On Thu, 26 Nov 2009, Vishwanath BS wrote:
In omap34xx_clks, CK_343X type is used by all OMAP3 family of
processors. It makes more sense to name clock type as CK_3XXX since it
is common to all OMAP3 processors.
Hmmm. Do all of the CK_3XXX clocks apply to AM3503/3517?
Currently all OMAP3 chip families are using CK_343X as the common clock and
this clock has been renamed to CK_3XXX. So CK_3XXX should be applicable for all.
- Paul
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock.h | 15 +-
arch/arm/mach-omap2/clock34xx.c | 370 +++---
arch/arm/mach-omap2/clock34xx.h | 158 +++---
arch/arm/plat-omap/include/plat/clock.h |2 +-
4 files changed, 274 insertions(+), 271 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 43b6bed..8ceefcc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -79,20 +79,23 @@ extern u8 cpu_mask;
/* clksel_rate data common to 24xx/343x */
static const struct clksel_rate gpt_32k_rates[] = {
-{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
+{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
{ .div = 0 }
};
static const struct clksel_rate gpt_sys_rates[] = {
-{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
+{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
{ .div = 0 }
};
static const struct clksel_rate gfx_l3_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X },
- { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE
},
- { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_343X },
- { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_343X },
+ { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX },
+ { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
+ { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_3XXX },
+ { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_3XXX },
{ .div = 0 }
};
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
omap2/clock34xx.c
index 832ed0b..167f075 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -94,69 +94,69 @@ struct omap_clk {
}, \
}
-#define CK_343X(1 0)
+#define CK_3XXX(1 0)
#define CK_3430ES1 (1 1)
#define CK_3430ES2 (1 2)
static struct omap_clk omap34xx_clks[] = {
- CLK(NULL, omap_32k_fck, omap_32k_fck, CK_343X),
- CLK(NULL, virt_12m_ck, virt_12m_ck, CK_343X),
- CLK(NULL, virt_13m_ck, virt_13m_ck, CK_343X),
+ CLK(NULL, omap_32k_fck, omap_32k_fck, CK_3XXX),
+ CLK(NULL, virt_12m_ck, virt_12m_ck, CK_3XXX),
+ CLK(NULL, virt_13m_ck, virt_13m_ck, CK_3XXX),
CLK(NULL, virt_16_8m_ck, virt_16_8m_ck, CK_3430ES2),
- CLK(NULL, virt_19_2m_ck, virt_19_2m_ck, CK_343X),
- CLK(NULL, virt_26m_ck, virt_26m_ck, CK_343X),
- CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_343X),
- CLK(NULL, osc_sys_ck, osc_sys_ck,CK_343X),
- CLK(NULL, sys_ck, sys_ck,CK_343X),
- CLK(NULL, sys_altclk, sys_altclk,CK_343X),
- CLK(NULL, mcbsp_clks, mcbsp_clks,CK_343X),
- CLK(NULL, sys_clkout1, sys_clkout1, CK_343X),
- CLK(NULL, dpll1_ck, dpll1_ck, CK_343X),
- CLK(NULL, dpll1_x2_ck, dpll1_x2_ck, CK_343X),
- CLK(NULL, dpll1_x2m2_ck, dpll1_x2m2_ck, CK_343X),
- CLK(NULL, dpll2_ck, dpll2_ck, CK_343X),
- CLK(NULL, dpll2_m2_ck, dpll2_m2_ck, CK_343X),
- CLK(NULL, dpll3_ck, dpll3_ck, CK_343X),
- CLK(NULL, core_ck, core_ck, CK_343X),
- CLK(NULL, dpll3_x2_ck, dpll3_x2_ck, CK_343X),
- CLK(NULL, dpll3_m2_ck, dpll3_m2_ck, CK_343X),
- CLK(NULL, dpll3_m2x2_ck, dpll3_m2x2_ck, CK_343X),
- CLK(NULL, dpll3_m3_ck, dpll3_m3_ck, CK_343X),
- CLK(NULL, dpll3_m3x2_ck, dpll3_m3x2_ck, CK_343X),
- CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_343X),
- CLK(NULL, dpll4_ck, dpll4_ck, CK_343X),
- CLK(NULL, dpll4_x2_ck
RE: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype
Paul
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, November 30, 2009 3:00 PM
To: Sripathy, Vishwanath
Cc: ext-ari.kau...@nokia.com; linux-omap@vger.kernel.org; Woodruff, Richard;
Menon, Nishanth
Subject: Re: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype
Hello Vishwanath,
a few comments:
On Thu, 26 Nov 2009, Vishwanath BS wrote:
From: Richard Woodruff r-woodru...@ti.com
DPLL4 for 3630 introduces a changed block requiring special divisor bits and
additional reg fields. To allow for silicons to use this, this is introduced
as a omap3_has_jtype_dpll4() and is enabled for 3630 silicon
Tested with 3630 ZOOM3
Could you please consider Ari Kauppi's suggestions that he posted on
30 and 31 October? They look good to me. Here is a link:
Regarding comments from Ari Kauppi on addition of dco_sel_mask and sd_div_mask,
yes I had a look at them. However I feel, it's better to have these masks in
the structure variable. Reason being this approach will help us to support when
dpll types for other dplls get changed in future. For example, if dpll3 block
is changed, then having new mask will help us to support it.
http://patchwork.kernel.org/patch/55009/
Also, finally got the 3630 documents, so some more detailed comments are
now possible:
- One thing that is confusing is that the 3630 Rev A TRM (SWPU176A)
conflicts with the 34xx-36xx Delta TRM (SWPU204). For example, the delta
TRM claims that the FREQSEL bits are all removed, but the 3630 TRM claims
that they are still present. Could you find out which one is correct? If
no FREQSEL bits are present, then the clock code shouldn't write to them.
3630 TRM (Rev A) shows that FREQSEL is no longer present for Per DPLL
(CM_CLKEN_PLL [23:20] is reserved). So we should not write freqsel for PER
dpll.
- Table 3-13 in the delta TRM claims that the DPLL4 multiplier bitfield
can now go to 4096. [This looks like an off-by-one error in the
documentation, since only 12 bits are available, so the max is (2^12 - 1)
= 4095.] But the important point for this patch is that the struct
dpll_data.max_multiplier field for DPLL4 needs to be increased.
I confirmed that DPLL4 Multiplier is 12 bits. So max value is 4095.
A few more questions below:
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 51
++-
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/id.c|4 ++-
arch/arm/plat-omap/include/plat/clock.h |3 ++
arch/arm/plat-omap/include/plat/cpu.h |3 +-
5 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
omap2/clock34xx.c
index da5bc1f..832ed0b 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -679,6 +679,41 @@ static void omap3_noncore_dpll_disable(struct clk *clk)
_omap3_noncore_dpll_stop(clk);
}
+/**
+ * lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16
+ m, u8 n)
+ {
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ clkinp = clk-parent-rate;
+ fint = (clkinp / n) * m;
+
+ if (fint 10)
+ *dco = 2;
+ else
+ *dco = 4;
+ /*
+* target sigma-delta to near 250MHz
+* sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)]
+*/
+ clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/
+ mod1 = (clkinp * m) % (250 * n);
+ sd = (clkinp * m) / (250 * n);
+ mod2 = sd % 10;
+ sd /= 10;
+
+ if (mod1 + mod2)
+ sd++;
+ *sd_div = sd;
+}
/* Non-CORE DPLL rate set code */
@@ -711,6 +746,13 @@ static int omap3_noncore_dpll_program(struct clk *clk,
u16 m, u8 n, u16 freqsel)
v = ~(dd-mult_mask | dd-div1_mask);
v |= m __ffs(dd-mult_mask);
v |= (n - 1) __ffs(dd-div1_mask);
+ if (dd-jtype) {
+ u8 dco, sd_div;
+ lookup_dco_sddiv(clk, dco, sd_div, m, n);
+ v = ~(dd-dco_sel_mask | dd-sd_div_mask);
+ v |= dco __ffs(dd-dco_sel_mask);
+ v |= sd_div __ffs(dd-sd_div_mask);
+ }
__raw_writel(v, dd-mult_div1_reg);
/* We let the clock framework set the other output dividers later */
@@ -1026,7 +1068,7 @@ static unsigned long omap3_clkoutx2_recalc(struct clk
*clk)
v = __raw_readl(dd-control_reg
RE: [PATCH 2/2] OMAP3: Implemented VFP restore/save context
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Tuesday, November 24, 2009 4:07 PM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 2/2] OMAP3: Implemented VFP restore/save context
From: Tero Kristo tero.kri...@nokia.com
VFP save context is called before MPU/NEON off. Restore is not needed as
the next VFP trap will restore context automatically. Uses the support
routine implemented in arch/arm/vfp/vfpmodule.c.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 21 -
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4f22107..dd5bbaf 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -18,6 +18,7 @@ extern u32 sleep_while_idle;
extern u32 voltage_off_while_idle;
extern void *omap3_secure_ram_storage;
+extern void vfp_pm_save_context(void);
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b26ae5b..4b01303 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -321,6 +321,18 @@ static void restore_control_register(u32 val)
__asm__ __volatile__ (mcr p15, 0, %0, c1, c0, 0 : : r (val));
}
+static inline void omap3_save_neon_context(void)
+{
+#ifdef CONFIG_VFP
+ vfp_pm_save_context();
+#endif
+}
+
+static inline void omap3_restore_neon_context(void)
+{
+ return;
+}
+
/* Function to restore the table entry that was modified for enabling MMU */
static void restore_table_entry(void)
{
@@ -365,6 +377,7 @@ void omap_sram_idle(void)
/* save_state = 3 = L1, L2 and logic lost */
int save_state = 0;
int mpu_next_state = PWRDM_POWER_ON;
+ int neon_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
@@ -398,8 +411,12 @@ void omap_sram_idle(void)
pwrdm_pre_transition();
/* NEON control */
- if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
+ if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON) {
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ neon_next_state = mpu_next_state;
+ if (neon_next_state == PWRDM_POWER_OFF)
+ omap3_save_neon_context();
+ }
/* PER */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
@@ -537,6 +554,8 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
+ if (neon_next_state == PWRDM_POWER_OFF)
+ omap3_restore_neon_context();
Why do call restore here when restore is done automatically upon context switch?
pwrdm_post_transition();
}
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields
Sergio,
-Original Message-
From: Aguirre, Sergio
Sent: Friday, November 20, 2009 9:28 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: RE: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields
Vishwa,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Sripathy, Vishwanath
Sent: Friday, November 20, 2009 9:29 AM
To: linux-omap@vger.kernel.org; Sripathy, Vishwanath
Subject: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields
DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in
3630.This patch has changes to accommodate this in CM
dynamically based on
chip version.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 18 --
arch/arm/mach-omap2/clock34xx.h | 53
--
arch/arm/mach-omap2/cm-regbits-34xx.h |7 +++-
arch/arm/plat-omap/include/plat/clock.h |4 +-
4 files changed, 71 insertions(+), 11 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/clock34xx.c
No file mode changes, please.
Ack
diff --git a/arch/arm/mach-omap2/clock34xx.c
b/arch/arm/mach-omap2/clock34xx.c
index 167f075..1e35f9a
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -43,6 +43,7 @@
#include prm-regbits-34xx.h
#include cm.h
#include cm-regbits-34xx.h
+#include plat/cpu.h
static const struct clkops clkops_noncore_dpll_ops;
@@ -97,6 +98,7 @@ struct omap_clk {
#define CK_3XXX(1 0)
#define CK_3430ES1 (1 1)
#define CK_3430ES2 (1 2)
+#define CK_363X(1 3)
static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_32k_fck, omap_32k_fck, CK_3XXX),
@@ -134,13 +136,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_12m_fck, omap_12m_fck, CK_3XXX),
CLK(NULL, dpll4_m2_ck, dpll4_m2_ck, CK_3XXX),
CLK(NULL, dpll4_m2x2_ck, dpll4_m2x2_ck, CK_3XXX),
- CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_3XXX),
+ CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_3XXX
| CK_363X),
Shouldn't CK_363X replace CK_3XXX?
CK_363X is always inside the CK_3XXX scope, but not the other way around.
Not really. If you see the intention of adding CK_363X, it is to indicate that
this particular clock node has some changes specific to 3630 and it needs
special handling. So we cannot replace CK_363X with CK_3XXX
CLK(NULL, dpll4_m3x2_ck, dpll4_m3x2_ck, CK_3XXX),
- CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_3XXX),
+ CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_3XXX
| CK_363X),
CLK(NULL, dpll4_m4x2_ck, dpll4_m4x2_ck, CK_3XXX),
- CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_3XXX),
+ CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_3XXX
| CK_363X),
CLK(NULL, dpll4_m5x2_ck, dpll4_m5x2_ck, CK_3XXX),
- CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_3XXX),
+ CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_3XXX
| CK_363X),
CLK(NULL, dpll4_m6x2_ck, dpll4_m6x2_ck, CK_3XXX),
CLK(NULL, emu_per_alwon_ck, emu_per_alwon_ck, CK_3XXX),
CLK(NULL, dpll5_ck, dpll5_ck, CK_3430ES2),
@@ -1222,6 +1224,8 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
dpll4_ck.dpll_data-sd_div_mask =
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
+ dpll4_dd.mult_mask =
OMAP3630_PERIPH_DPLL_MULT_MASK;
+ cpu_mask |= RATE_IN_363X;
}
}
@@ -1232,6 +1236,12 @@ int __init omap2_clk_init(void)
for (c = omap34xx_clks; c omap34xx_clks +
ARRAY_SIZE(omap34xx_clks); c++)
if (c-cpu cpu_clkflg) {
+ /* for 3630, change the mask value for
clocks which are
+ marked as CK_363X*/
+ if (cpu_is_omap3630() (c-cpu CK_363X)) {
+ c-lk.clk-clksel_mask =
+
c-lk.clk-clksel_mask_3630;
+ }
clkdev_add(c-lk);
clk_register(c-lk.clk);
omap2_init_clk_clkdm(c-lk.clk);
diff --git a/arch/arm/mach-omap2/clock34xx.h
b/arch/arm/mach-omap2/clock34xx.h
index 813a83e..93c92e5 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -243,6 +243,42 @@ static const struct clksel_rate
div16_dpll_rates[] = {
{ .div = 0 }
};
+static const struct clksel_rate div32_dpll_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_3XXX | DEFAULT_RATE },
+ { .div = 2, .val = 2, .flags = RATE_IN_3XXX },
+ { .div = 3, .val = 3, .flags = RATE_IN_3XXX },
+ { .div = 4, .val = 4, .flags = RATE_IN_3XXX },
+ { .div = 5, .val = 5, .flags = RATE_IN_3XXX
RE: [PATCHV2 4/4] OMAP3: add support for 192Mhz sgx clock
-Original Message-
From: Menon, Nishanth
Sent: Friday, November 20, 2009 9:49 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHV2 4/4] OMAP3: add support for 192Mhz sgx clock
unrelated to this patch comment: we might want to consider thinking in
terms of optimizing the memory as OMAP4 also kicks in.. some sort of
dynamic clock tree traversal and __initdata method perhaps??
Hi Vishwa,
Thanks for the patch, few minor comments follow:
Sripathy, Vishwanath had written, on 11/20/2009 09:28 AM, the following:
SGX can run at 192MHz on 3630 and this patch has changes to support this
feature. Basically DPLL4 M2 will be 192Mhz which will be used as SGX
Clock. 192Mhz clock is divided by 2 (using CM_CLKSEL_CORE) to generate
96Mh clock
- you probably intended 96Mhz
Yes, is should be 96Mhz.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 16 +++-
arch/arm/mach-omap2/clock34xx.h | 33
+
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
arch/arm/mach-omap2/id.c |7 +--
arch/arm/plat-omap/include/plat/cpu.h |3 +++
5 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
omap2/clock34xx.c
index 1e35f9a..bce7e46 100755
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_3XXX),
CLK(NULL, dpll4_ck, dpll4_ck, CK_3XXX),
CLK(NULL, dpll4_x2_ck, dpll4_x2_ck, CK_3XXX),
+ CLK(NULL, omap_192m_alwon_ck, omap_192m_alwon_ck,
CK_363X),
CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck, CK_3XXX),
CLK(NULL, omap_96m_fck, omap_96m_fck, CK_3XXX),
CLK(NULL, cm_96m_fck, cm_96m_fck,CK_3XXX),
@@ -1226,7 +1227,20 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
cpu_mask |= RATE_IN_363X;
- }
+ cpu_clkflg |= CK_363X;
I think introduce CK_36XX should be done seperately.
Ack. It should have been part of patch3.
+ }
+
+ if (omap3_has_192mhz_clk()) {
+ omap_96m_alwon_fck.parent = omap_192m_alwon_ck;
+ omap_96m_alwon_fck.init = omap2_init_clksel_parent;
+ omap_96m_alwon_fck.clksel_reg =
+ OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
+ omap_96m_alwon_fck.clksel_mask =
+ OMAP3630_CLKSEL_96M_MASK;
+ omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel;
+ omap_96m_alwon_fck.recalc = omap2_clksel_recalc;
+ }
+
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-
omap2/clock34xx.h
index 93c92e5..6fe89df 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = {
.recalc = omap3_clkoutx2_recalc,
};
+/* Adding 192MHz Clock node needed by SGX */
+static struct clk omap_192m_alwon_ck = {
+ .name = omap_192m_alwon_ck,
+ .ops= clkops_null,
+ .parent = dpll4_m2x2_ck,
+ .recalc = followparent_recalc,
+};
+
/*
* DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as
* PRM_96M_ALWON_(F)CLK. Two clocks then emerge from the PRM:
* 96M_ALWON_FCLK (called omap_96m_alwon_fck below) and
* CM_96K_(F)CLK.
*/
+static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_363X },
+ { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 0 }
+};
+
+static const struct clksel omap_96m_alwon_fck_clksel[] = {
+ { .parent = omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates },
+ { .parent = NULL }
+};
+
static struct clk omap_96m_alwon_fck = {
.name = omap_96m_alwon_fck,
.ops= clkops_null,
@@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = {
{ .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE },
{ .div = 4, .val = 1, .flags = RATE_IN_3XXX },
{ .div = 6, .val = 2, .flags = RATE_IN_3XXX },
+ { .div = 2, .val = 5, .flags = RATE_IN_363X },
dont we have more options here? thinking: does this mean that all 3XXX
and 36XX defines are valid ones for SGX?
From PRCM point of view all 3XXX configurations are valid for 3430. All 3XXX
and 363X are valid for 3630. May be SGX driver not use all
RE: [PATCH 4/4] OMAP3: add support for 192Mhz sgx clock
-Original Message-
From: Menon, Nishanth
Sent: Wednesday, November 18, 2009 10:20 PM
To: Sripathy, Vishwanath
Cc: linux-omap
Subject: Re: [PATCH 4/4] OMAP3: add support for 192Mhz sgx clock
Sripathy, Vishwanath had written, on 11/18/2009 08:16 AM, the following:
SGX can run at 192MHz on 3630 and this patch has changes to support this
feature.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 10 ++
arch/arm/mach-omap2/clock34xx.h | 33
+
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
omap2/clock34xx.c
index 77b88aa..885043e 100755
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_3XXX),
CLK(NULL, dpll4_ck, dpll4_ck, CK_3XXX),
CLK(NULL, dpll4_x2_ck, dpll4_x2_ck, CK_3XXX),
+ CLK(NULL, omap_192m_alwon_ck, omap_192m_alwon_ck,
CK_363X),
CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck, CK_3XXX),
CLK(NULL, omap_96m_fck, omap_96m_fck, CK_3XXX),
CLK(NULL, cm_96m_fck, cm_96m_fck,CK_3XXX),
@@ -1224,6 +1225,15 @@ int __init omap2_clk_init(void)
dpll4_ck.dpll_data-sd_div_mask =
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
cpu_mask |= RATE_IN_363X;
+ cpu_clkflg |= CK_363X;
+ omap_96m_alwon_fck.parent = omap_192m_alwon_ck;
+ omap_96m_alwon_fck.init = omap2_init_clksel_parent;
+ omap_96m_alwon_fck.clksel_reg =
+ OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
+ omap_96m_alwon_fck.clksel_mask =
+ OMAP3630_CLKSEL_96M_MASK;
+ omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel;
+ omap_96m_alwon_fck.recalc = omap2_clksel_recalc;
We should not ideally be linking this to j type DPLL perhaps? are'nt
these 36xx series specific? do we need FEATURE_HAS_192Mhz_CLK? that way
the future AM series/37xx series could also use this.
I will add FEATURE_HAS_192Mhz_CLK and put the code under this feature.
}
}
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-
omap2/clock34xx.h
index 93c92e5..6fe89df 100755
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = {
.recalc = omap3_clkoutx2_recalc,
};
+/* Adding 192MHz Clock node needed by SGX */
+static struct clk omap_192m_alwon_ck = {
+ .name = omap_192m_alwon_ck,
+ .ops= clkops_null,
+ .parent = dpll4_m2x2_ck,
+ .recalc = followparent_recalc,
+};
+
/*
* DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as
* PRM_96M_ALWON_(F)CLK. Two clocks then emerge from the PRM:
* 96M_ALWON_FCLK (called omap_96m_alwon_fck below) and
* CM_96K_(F)CLK.
*/
+static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_363X },
+ { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 0 }
+};
+
+static const struct clksel omap_96m_alwon_fck_clksel[] = {
+ { .parent = omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates },
+ { .parent = NULL }
+};
+
static struct clk omap_96m_alwon_fck = {
.name = omap_96m_alwon_fck,
.ops= clkops_null,
@@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = {
{ .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE },
{ .div = 4, .val = 1, .flags = RATE_IN_3XXX },
{ .div = 6, .val = 2, .flags = RATE_IN_3XXX },
+ { .div = 2, .val = 5, .flags = RATE_IN_363X },
+ { .div = 0 },
+};
+
+static const struct clksel_rate sgx_192m_rates[] = {
+ { .div = 1, .val = 4, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 0 },
+};
+
+static const struct clksel_rate sgx_corex2_rates[] = {
+ { .div = 3, .val = 6, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 5, .val = 7, .flags = RATE_IN_363X },
{ .div = 0 },
};
@@ -1234,6 +1265,8 @@ static const struct clksel_rate sgx_96m_rates[] = {
static const struct clksel sgx_clksel[] = {
{ .parent = core_ck,.rates = sgx_core_rates },
{ .parent = cm_96m_fck, .rates = sgx_96m_rates },
+ { .parent = omap_192m_alwon_ck, .rates = sgx_192m_rates },
+ { .parent = corex2_fck, .rates = sgx_corex2_rates },
{ .parent = NULL },
};
diff --git
RE: [PATCH 9/9 v2] omap3: pm: introduce 3630 opps
-Original Message-
From: Menon, Nishanth
Sent: Friday, November 13, 2009 11:35 AM
To: linux-omap
Cc: Menon, Nishanth; Cousson, Benoit; Hunter, Jon; Kevin Hilman; Chikkature
Rajashekar, Madhusudhan; Paul Walmsley; Dasgupta, Romit; Premi, Sanjeev;
Shilimkar, Santosh; Aguirre, Sergio; Lam, SuiLun; Gopinath, Thara; Sripathy,
Vishwanath
Subject: [PATCH 9/9 v2] omap3: pm: introduce 3630 opps
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123nav
igationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet
to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps.
Range of OPPs supported by Devices(tentative)-
|-3630-600-| (default)
|- 3630-800 -| (device: TBD)
|- 3630-1000 -| (device: TBD)
H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB
VDD1 OPP1 OPP2 OPP3OPP4
VDD2 OPP1 OPP2 OPP2OPP2
Note:
a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100,
Turbo and SB. This maps as shown above to the opp IDs (s/w term).
b) For boards which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Tested on: SDP3430, SDP3630
Cc: Benoit Cousson b-cous...@ti.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: SuiLun Lam s-...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap3-opp.h |9
arch/arm/mach-omap2/pm34xx.c| 87
+++---
2 files changed, 80 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-opp.h b/arch/arm/mach-omap2/omap3-
opp.h
index 7f27f44..a5880b8 100644
--- a/arch/arm/mach-omap2/omap3-opp.h
+++ b/arch/arm/mach-omap2/omap3-opp.h
@@ -4,22 +4,31 @@
#include plat/omap-pm.h
/* MPU speeds */
+#define S1000M 10
+#define S800M 8
#define S600M 6
#define S550M 55000
#define S500M 5
+#define S300M 3
#define S250M 25000
#define S125M 12500
/* DSP speeds */
+#define S875M 87500
+#define S660M 66000
+#define S520M 52000
#define S430M 43000
#define S400M 4
#define S360M 36000
+#define S260M 26000
#define S180M 18000
#define S90M9000
/* L3 speeds */
#define S83M8300
+#define S100M 1
#define S166M 16600
+#define S200M 2
extern struct omap_opp *omap3_mpu_rate_table;
extern struct omap_opp *omap3_dsp_rate_table;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 14131f8..86137bb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -141,6 +141,41 @@ static __initdata struct omap_opp
omap34xx_dsp_rate_table[] = {
{0, 0, 0, 0},
};
+static __initdata struct omap_opp omap36xx_mpu_rate_table[] = {
+ {0, 0, 0, 0},
+ /*OPP1 - 930mV - OPP50*/
+ {true, S300M, VDD1_OPP1, 0x1a},
+ /*OPP2 - 1.100V - OPP100*/
+ {true, S600M, VDD1_OPP2, 0x28},
+ /*OPP3 - 1.260V - OPP-Turbo*/
+ {false, S800M, VDD1_OPP3, 0x34},
+ /*OPP4 - 1.310V - OPP-SB*/
+ {false, S1000M, VDD1_OPP4, 0x38},
+ {0, 0, 0, 0},
+};
OPP Table vsel values seem to be wrong. Eg: for OPP1 to get 930mV, vsel should
be 0x1b. vsel=Ceiling((930-600)/12.5)
+
+static __initdata struct omap_opp omap36xx_l3_rate_table[] = {
+ {0, 0, 0, 0},
+ /*OPP1 - 930mV - OPP50 */
+ {true, S100M, VDD2_OPP1, 0x1a},
+ /*OPP2 - 1.375V - OPP100, OPP-Turbo, OPP-SB*/
+ {true, S200M, VDD2_OPP2, 0x2b},
+ {0, 0, 0, 0},
+};
+
Same case
+static __initdata struct omap_opp omap36xx_dsp_rate_table[] = {
+ {0, 0, 0, 0},
+ /*OPP1 - OPP50*/
+ {true, S260M, VDD1_OPP1, 0x1a},
+ /*OPP2 - OPP100*/
+ {true, S520M, VDD1_OPP2, 0x28},
+ /*OPP3 - OPP-Turbo*/
+ {false, S660M, VDD1_OPP3, 0x34},
+ /*OPP4 - OPP-SB*/
+ {false, S875M, VDD1_OPP4, 0x38},
+ {0, 0, 0, 0},
+};
+
Same case
struct omap_opp *omap3_mpu_rate_table;
struct omap_opp *omap3_dsp_rate_table;
struct omap_opp *omap3_l3_rate_table;
@@ -1287,22 +1322,42 @@ static void __init configure_vc(void)
void __init omap3_pm_init_opp_table(void
RE: Scalling_setspeed doesn't work
You need to use userspace governor before trying to set speed using scalling_setspeed. Can you pls confirm that? You can select userspace governor by using below command echo userspace /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Vishwa -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of tarek attia Sent: Tuesday, November 17, 2009 10:28 PM To: linux-omap Subject: Scalling_setspeed doesn't work When I try to change the value of (scalling_setspeed) file ,it doesn't change however it doesn't rise errors as well,,but after changing it and trying to rereading it ,I found that nothing is changed !!!? BTW:-I'm using Linux kernel(2.6.29) on the beagleboard with the power management branch Any help will be appreciated . Best Regards, tarek -- 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
[PATCH 0/4] OMAP3: Clock changes for OMAP3630
This patch set introduces clock changes for OMAP3630. Major changes in OMAP3630 w.r.t clock are 1. Introduction of j type dpll4 2. CLKSEL filed width is increased by 1 bit for DPLL4M3, M4, M5 and M6 3. SGX can be run at 192Mhz Patch set has been created for linux-omap-pm tree Richard Woodruff (1): OMAP3:clk - introduce DPLL4 jtype support Vishwanath BS (3): OMAP3:clk - Clock Type change for OMAP3 Clocks OMAP3:clk - correct width for CLKSEL Fields OMAP3:clk - add support for 192Mhz sgx clock arch/arm/mach-omap2/clock.h | 12 +- arch/arm/mach-omap2/clock34xx.c | 438 ++- arch/arm/mach-omap2/clock34xx.h | 244 +++-- arch/arm/mach-omap2/cm-regbits-34xx.h | 11 + arch/arm/mach-omap2/id.c|4 +- arch/arm/plat-omap/include/plat/clock.h |9 +- arch/arm/plat-omap/include/plat/cpu.h |3 +- 7 files changed, 441 insertions(+), 280 deletions(-) -- 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 1/4] OMAP3: introduce DPLL4 Jtype
From: Richard Woodruff r-woodru...@ti.com
DPLL4 for 3630 introduces a changed block requiring special divisor bits and
additional reg fields. To allow for silicons to use this, this is introduced as
a omap3_has_jtype_dpll4() and is enabled for 3630 silicon
Tested with 3630 ZOOM3
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 49 ++-
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/id.c|4 ++-
arch/arm/plat-omap/include/plat/clock.h |3 ++
arch/arm/plat-omap/include/plat/cpu.h |3 +-
5 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index da5bc1f..2c07b9e 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -679,6 +679,40 @@ static void omap3_noncore_dpll_disable(struct clk *clk)
_omap3_noncore_dpll_stop(clk);
}
+/**
+ * lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16
+m, u8 n) {
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ clkinp = clk-parent-rate;
+ fint = (clkinp / n) * m;
+
+ if (fint 10)
+ *dco = 2;
+ else
+ *dco = 4;
+ /*
+* target sigma-delta to near 250MHz
+* sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)]
+*/
+ clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/
+ mod1 = (clkinp * m) % (250 * n);
+ sd = (clkinp * m) / (250 * n);
+ mod2 = sd % 10;
+ sd /= 10;
+
+ if (mod1 + mod2)
+ sd++;
+ *sd_div = sd;
+}
/* Non-CORE DPLL rate set code */
@@ -711,6 +745,13 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16
m, u8 n, u16 freqsel)
v = ~(dd-mult_mask | dd-div1_mask);
v |= m __ffs(dd-mult_mask);
v |= (n - 1) __ffs(dd-div1_mask);
+ if (dd-jtype) {
+ u8 dco, sd_div;
+ lookup_dco_sddiv(clk, dco, sd_div, m, n);
+ v = ~(dd-dco_sel_mask | dd-sd_div_mask);
+ v |= dco __ffs(dd-dco_sel_mask);
+ v |= sd_div __ffs(dd-sd_div_mask);
+ }
__raw_writel(v, dd-mult_div1_reg);
/* We let the clock framework set the other output dividers later */
@@ -1026,7 +1067,7 @@ static unsigned long omap3_clkoutx2_recalc(struct clk
*clk)
v = __raw_readl(dd-control_reg) dd-enable_mask;
v = __ffs(dd-enable_mask);
- if (v != OMAP3XXX_EN_DPLL_LOCKED)
+ if (v != OMAP3XXX_EN_DPLL_LOCKED (!dd-jtype))
rate = clk-parent-rate;
else
rate = clk-parent-rate * 2;
@@ -1174,6 +1215,12 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+ if (omap3_has_jtype_dpll4())
+ {
+ dpll4_ck.dpll_data-jtype = 1;
+ dpll4_ck.dpll_data-dco_sel_mask =
OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
+ dpll4_ck.dpll_data-sd_div_mask =
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
+ }
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK (0x7f 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK (0x7 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT 24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff 24)
/* CM_CLKSEL3_PLL */
#define OMAP3430_DIV_96M_SHIFT 0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..3c1194c 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -176,6 +176,8 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
+ if (cpu_is_omap3630())
+ omap3_features |= OMAP3_HAS_JTYPE_DPLL4;
/*
[PATCH 2/4] OMAP3: Clock Type change for OMAP3 Clocks
In omap34xx_clks, CK_343X type is used by all OMAP3 family of processors. It
makes more sense to name clock type as CK_3XXX since it is common to all OMAP3
processors.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock.h | 12 +-
arch/arm/mach-omap2/clock34xx.c | 370 +++---
arch/arm/mach-omap2/clock34xx.h | 158 +++---
arch/arm/plat-omap/include/plat/clock.h |2 +-
4 files changed, 271 insertions(+), 271 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/clock.h
mode change 100644 = 100755 arch/arm/mach-omap2/clock34xx.c
mode change 100644 = 100755 arch/arm/mach-omap2/clock34xx.h
mode change 100644 = 100755 arch/arm/plat-omap/include/plat/clock.h
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 43b6bed..955bde5
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -79,20 +79,20 @@ extern u8 cpu_mask;
/* clksel_rate data common to 24xx/343x */
static const struct clksel_rate gpt_32k_rates[] = {
-{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
+{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_3XXX |
DEFAULT_RATE },
{ .div = 0 }
};
static const struct clksel_rate gpt_sys_rates[] = {
-{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
+{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX |
DEFAULT_RATE },
{ .div = 0 }
};
static const struct clksel_rate gfx_l3_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X },
- { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
- { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_343X },
- { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_343X },
+ { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX },
+ { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_3XXX |
DEFAULT_RATE },
+ { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_3XXX },
+ { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_3XXX },
{ .div = 0 }
};
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 2c07b9e..be630ce
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -94,69 +94,69 @@ struct omap_clk {
}, \
}
-#define CK_343X(1 0)
+#define CK_3XXX(1 0)
#define CK_3430ES1 (1 1)
#define CK_3430ES2 (1 2)
static struct omap_clk omap34xx_clks[] = {
- CLK(NULL, omap_32k_fck, omap_32k_fck, CK_343X),
- CLK(NULL, virt_12m_ck, virt_12m_ck, CK_343X),
- CLK(NULL, virt_13m_ck, virt_13m_ck, CK_343X),
+ CLK(NULL, omap_32k_fck, omap_32k_fck, CK_3XXX),
+ CLK(NULL, virt_12m_ck, virt_12m_ck, CK_3XXX),
+ CLK(NULL, virt_13m_ck, virt_13m_ck, CK_3XXX),
CLK(NULL, virt_16_8m_ck, virt_16_8m_ck, CK_3430ES2),
- CLK(NULL, virt_19_2m_ck, virt_19_2m_ck, CK_343X),
- CLK(NULL, virt_26m_ck, virt_26m_ck, CK_343X),
- CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_343X),
- CLK(NULL, osc_sys_ck, osc_sys_ck,CK_343X),
- CLK(NULL, sys_ck, sys_ck,CK_343X),
- CLK(NULL, sys_altclk, sys_altclk,CK_343X),
- CLK(NULL, mcbsp_clks, mcbsp_clks,CK_343X),
- CLK(NULL, sys_clkout1, sys_clkout1, CK_343X),
- CLK(NULL, dpll1_ck, dpll1_ck, CK_343X),
- CLK(NULL, dpll1_x2_ck, dpll1_x2_ck, CK_343X),
- CLK(NULL, dpll1_x2m2_ck, dpll1_x2m2_ck, CK_343X),
- CLK(NULL, dpll2_ck, dpll2_ck, CK_343X),
- CLK(NULL, dpll2_m2_ck, dpll2_m2_ck, CK_343X),
- CLK(NULL, dpll3_ck, dpll3_ck, CK_343X),
- CLK(NULL, core_ck, core_ck, CK_343X),
- CLK(NULL, dpll3_x2_ck, dpll3_x2_ck, CK_343X),
- CLK(NULL, dpll3_m2_ck, dpll3_m2_ck, CK_343X),
- CLK(NULL, dpll3_m2x2_ck, dpll3_m2x2_ck, CK_343X),
- CLK(NULL, dpll3_m3_ck, dpll3_m3_ck, CK_343X),
- CLK(NULL, dpll3_m3x2_ck, dpll3_m3x2_ck, CK_343X),
- CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_343X),
- CLK(NULL, dpll4_ck, dpll4_ck, CK_343X),
- CLK(NULL, dpll4_x2_ck, dpll4_x2_ck, CK_343X),
- CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck, CK_343X),
- CLK(NULL, omap_96m_fck, omap_96m_fck, CK_343X),
- CLK(NULL, cm_96m_fck, cm_96m_fck,CK_343X),
- CLK(NULL, omap_54m_fck, omap_54m_fck, CK_343X),
- CLK(NULL, omap_48m_fck, omap_48m_fck, CK_343X),
- CLK(NULL, omap_12m_fck, omap_12m_fck, CK_343X),
- CLK(NULL, dpll4_m2_ck, dpll4_m2_ck,
[PATCH 4/4] OMAP3: add support for 192Mhz sgx clock
SGX can run at 192MHz on 3630 and this patch has changes to support this
feature.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 10 ++
arch/arm/mach-omap2/clock34xx.h | 33 +
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 77b88aa..885043e 100755
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_3XXX),
CLK(NULL, dpll4_ck, dpll4_ck, CK_3XXX),
CLK(NULL, dpll4_x2_ck, dpll4_x2_ck, CK_3XXX),
+ CLK(NULL, omap_192m_alwon_ck, omap_192m_alwon_ck, CK_363X),
CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck, CK_3XXX),
CLK(NULL, omap_96m_fck, omap_96m_fck, CK_3XXX),
CLK(NULL, cm_96m_fck, cm_96m_fck,CK_3XXX),
@@ -1224,6 +1225,15 @@ int __init omap2_clk_init(void)
dpll4_ck.dpll_data-sd_div_mask =
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
cpu_mask |= RATE_IN_363X;
+ cpu_clkflg |= CK_363X;
+ omap_96m_alwon_fck.parent = omap_192m_alwon_ck;
+ omap_96m_alwon_fck.init = omap2_init_clksel_parent;
+ omap_96m_alwon_fck.clksel_reg =
+ OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
+ omap_96m_alwon_fck.clksel_mask =
+ OMAP3630_CLKSEL_96M_MASK;
+ omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel;
+ omap_96m_alwon_fck.recalc = omap2_clksel_recalc;
}
}
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 93c92e5..6fe89df 100755
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = {
.recalc = omap3_clkoutx2_recalc,
};
+/* Adding 192MHz Clock node needed by SGX */
+static struct clk omap_192m_alwon_ck = {
+ .name = omap_192m_alwon_ck,
+ .ops= clkops_null,
+ .parent = dpll4_m2x2_ck,
+ .recalc = followparent_recalc,
+};
+
/*
* DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as
* PRM_96M_ALWON_(F)CLK. Two clocks then emerge from the PRM:
* 96M_ALWON_FCLK (called omap_96m_alwon_fck below) and
* CM_96K_(F)CLK.
*/
+static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_363X },
+ { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 0 }
+};
+
+static const struct clksel omap_96m_alwon_fck_clksel[] = {
+ { .parent = omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates },
+ { .parent = NULL }
+};
+
static struct clk omap_96m_alwon_fck = {
.name = omap_96m_alwon_fck,
.ops= clkops_null,
@@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = {
{ .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE },
{ .div = 4, .val = 1, .flags = RATE_IN_3XXX },
{ .div = 6, .val = 2, .flags = RATE_IN_3XXX },
+ { .div = 2, .val = 5, .flags = RATE_IN_363X },
+ { .div = 0 },
+};
+
+static const struct clksel_rate sgx_192m_rates[] = {
+ { .div = 1, .val = 4, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 0 },
+};
+
+static const struct clksel_rate sgx_corex2_rates[] = {
+ { .div = 3, .val = 6, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 5, .val = 7, .flags = RATE_IN_363X },
{ .div = 0 },
};
@@ -1234,6 +1265,8 @@ static const struct clksel_rate sgx_96m_rates[] = {
static const struct clksel sgx_clksel[] = {
{ .parent = core_ck,.rates = sgx_core_rates },
{ .parent = cm_96m_fck, .rates = sgx_96m_rates },
+ { .parent = omap_192m_alwon_ck, .rates = sgx_192m_rates },
+ { .parent = corex2_fck, .rates = sgx_corex2_rates },
{ .parent = NULL },
};
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index a6383f9..39b3399 100755
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -336,6 +336,8 @@
#define OMAP3430_CLKSEL_L4_MASK(0x3 2)
#define OMAP3430_CLKSEL_L3_SHIFT 0
#define OMAP3430_CLKSEL_L3_MASK(0x3 0)
+#define OMAP3630_CLKSEL_96M_SHIFT 12
+#define OMAP3630_CLKSEL_96M_MASK (0x3 12)
/*
RE: [RFC] [PATCH] OMAP3630 PM: Correct width for CLKSEL Fields
Alex,
On Wed, Nov 04, 2009 at 04:58:40 +0530, Sripathy, Vishwanath wrote:
@@ -134,13 +135,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_12m_fck, omap_12m_fck, CK_343X),
CLK(NULL, dpll4_m2_ck, dpll4_m2_ck, CK_343X),
CLK(NULL, dpll4_m2x2_ck, dpll4_m2x2_ck, CK_343X),
- CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_343X),
+ CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m3x2_ck, dpll4_m3x2_ck, CK_343X),
- CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_343X),
+ CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m4x2_ck, dpll4_m4x2_ck, CK_343X),
- CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_343X),
+ CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m5x2_ck, dpll4_m5x2_ck, CK_343X),
- CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_343X),
+ CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m6x2_ck, dpll4_m6x2_ck, CK_343X),
CLK(NULL, emu_per_alwon_ck, emu_per_alwon_ck, CK_343X),
CLK(NULL, dpll5_ck, dpll5_ck, CK_3430ES2),
Doesn't it make more sense to have separate dpll4_*_ck's for 363X so as to
avoid the clksel_mask_3630?
Then you will have to duplicate all the nodes in dpll4 clock tree which is
redundant. There is no much difference in clock tree (between 3630 and 3430)
except that clksel width is changed for 3630 which I feel does not justify
adding a new clock tree. Updating the clksel mask is the simplest way to
achieve it.
@@ -1216,6 +1217,10 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+ if (cpu_is_omap36xx()) {
+ dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
+ cpu_mask |= RATE_IN_363X;
Extra space before '|'.
+ }
}
I think there's an indentation problem.
clk_init(omap2_clk_functions);
@@ -1225,6 +1230,11 @@ int __init omap2_clk_init(void)
for (c = omap34xx_clks; c omap34xx_clks + ARRAY_SIZE(omap34xx_clks);
c++)
if (c-cpu cpu_clkflg) {
+ /* for 3630, change the mask value for clocks which are
+ marked as CK_363X*/
+ if (cpu_is_omap36xx())
+ if (c-cpu CK_363X)
Extra space before ''.
+ c-lk.clk-clksel_mask =
c-lk.clk-clksel_mask_3630;
This looks longer than normally allowed.
What is longer? I did not get the comment.
Regards,
--
Alex
--
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
[RFC] [PATCH] OMAP3630 PM: Correct width for CLKSEL Fields
DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in 3630.
This patch has changes to accommodate this in CM dynamically based on chip
version.
These changes are dependent on previous changes sent by
Nishant/Richard under subject (OMAP3:clk - introduce DPLL4 jtype support)
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 7844c04..f47a91a
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -97,6 +97,7 @@ struct omap_clk {
#define CK_343X(1 0)
#define CK_3430ES1 (1 1)
#define CK_3430ES2 (1 2)
+#define CK_363X(1 3)
static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_32k_fck, omap_32k_fck, CK_343X),
@@ -134,13 +135,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_12m_fck, omap_12m_fck, CK_343X),
CLK(NULL, dpll4_m2_ck, dpll4_m2_ck, CK_343X),
CLK(NULL, dpll4_m2x2_ck, dpll4_m2x2_ck, CK_343X),
- CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_343X),
+ CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m3x2_ck, dpll4_m3x2_ck, CK_343X),
- CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_343X),
+ CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m4x2_ck, dpll4_m4x2_ck, CK_343X),
- CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_343X),
+ CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m5x2_ck, dpll4_m5x2_ck, CK_343X),
- CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_343X),
+ CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m6x2_ck, dpll4_m6x2_ck, CK_343X),
CLK(NULL, emu_per_alwon_ck, emu_per_alwon_ck, CK_343X),
CLK(NULL, dpll5_ck, dpll5_ck, CK_3430ES2),
@@ -1216,6 +1217,10 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+ if (cpu_is_omap36xx()) {
+ dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
+ cpu_mask |= RATE_IN_363X;
+ }
}
clk_init(omap2_clk_functions);
@@ -1225,6 +1230,11 @@ int __init omap2_clk_init(void)
for (c = omap34xx_clks; c omap34xx_clks + ARRAY_SIZE(omap34xx_clks);
c++)
if (c-cpu cpu_clkflg) {
+ /* for 3630, change the mask value for clocks which are
+ marked as CK_363X*/
+ if (cpu_is_omap36xx())
+ if (c-cpu CK_363X)
+ c-lk.clk-clksel_mask =
c-lk.clk-clksel_mask_3630;
clkdev_add(c-lk);
clk_register(c-lk.clk);
omap2_init_clk_clkdm(c-lk.clk);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index a1b3de7..3e9420f
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -243,6 +243,43 @@ static const struct clksel_rate div16_dpll_rates[] = {
{ .div = 0 }
};
+static const struct clksel_rate div32_dpll_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_343X | DEFAULT_RATE },
+ { .div = 2, .val = 2, .flags = RATE_IN_343X },
+ { .div = 3, .val = 3, .flags = RATE_IN_343X },
+ { .div = 4, .val = 4, .flags = RATE_IN_343X },
+ { .div = 5, .val = 5, .flags = RATE_IN_343X },
+ { .div = 6, .val = 6, .flags = RATE_IN_343X },
+ { .div = 7, .val = 7, .flags = RATE_IN_343X },
+ { .div = 8, .val = 8, .flags = RATE_IN_343X },
+ { .div = 9, .val = 9, .flags = RATE_IN_343X },
+ { .div = 10, .val = 10, .flags = RATE_IN_343X },
+ { .div = 11, .val = 11, .flags = RATE_IN_343X },
+ { .div = 12, .val = 12, .flags = RATE_IN_343X },
+ { .div = 13, .val = 13, .flags = RATE_IN_343X },
+ { .div = 14, .val = 14, .flags = RATE_IN_343X },
+ { .div = 15, .val = 15, .flags = RATE_IN_343X },
+ { .div = 16, .val = 16, .flags = RATE_IN_343X },
+ { .div = 17, .val = 17, .flags = RATE_IN_363X },
+ { .div = 18, .val = 18, .flags = RATE_IN_363X },
+ { .div = 19, .val = 19, .flags = RATE_IN_363X },
+ { .div = 20, .val = 20, .flags = RATE_IN_363X },
+ { .div = 21, .val = 21, .flags = RATE_IN_363X },
+ { .div = 22, .val = 22, .flags = RATE_IN_363X },
+ { .div = 23, .val = 23, .flags = RATE_IN_363X },
+ { .div = 24, .val = 24, .flags = RATE_IN_363X },
+ { .div = 25, .val = 25, .flags = RATE_IN_363X },
+ { .div = 26, .val = 26, .flags = RATE_IN_363X },
+ { .div = 27, .val = 27, .flags = RATE_IN_363X },
+ { .div = 28, .val = 28, .flags = RATE_IN_363X },
+ { .div = 29,
RE: [PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration
Yes it can be removed. I will repost the patch with them removed. Vishwa -Original Message- From: Gopinath, Thara Sent: Friday, October 16, 2009 6:16 AM To: Sripathy, Vishwanath; linux-omap@vger.kernel.org; Kevin Hilman Subject: RE: [PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath Sent: Friday, October 16, 2009 4:45 AM To: Sripathy, Vishwanath; linux-omap@vger.kernel.org; Kevin Hilman Subject: [PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration As part of Core domain context restoration while coming out of off mode there are some registers being restored which are not required to be restored. ROM code should have restored them already. Overwriting some of them can have potential side effect. Eg: CM_CLKEN_PLL register should not be written while dpll is locked. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index fb864cc..da16804 100644 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -279,7 +279,6 @@ void omap3_prcm_save_context(void) prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG); prcm_context.sgx_cm_clksel = cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL); - prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL); prcm_context.dss_cm_clksel = cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL); prcm_context.cam_cm_clksel = @@ -296,8 +295,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4); prcm_context.pll_cm_clksel5 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - prcm_context.pll_cm_clken = - cm_read_mod_reg(PLL_MOD, CM_CLKEN); prcm_context.pll_cm_clken2 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2); prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL); @@ -343,8 +340,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2); prcm_context.mpu_cm_autoidle2 = cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2); - prcm_context.pll_cm_autoidle = - cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE); prcm_context.iva2_cm_clkstctrl = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL); prcm_context.mpu_cm_clkstctrl = @@ -436,7 +431,6 @@ void omap3_prcm_restore_context(void) __raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG); cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD, CM_CLKSEL); - cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD, @@ -453,7 +447,6 @@ void omap3_prcm_restore_context(void) OMAP3430ES2_CM_CLKSEL4); cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN); cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD, OMAP3430ES2_CM_CLKEN2); __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL); @@ -492,7 +485,6 @@ void omap3_prcm_restore_context(void) cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD, CM_AUTOIDLE2); cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2); - cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE); cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD, CM_CLKSTCTRL); cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL); Why not remove these unwanted variables wkup_cm_clksel, pll_cm_clken, pll_cm_autoidle from the structure omap3_prcm_regs also? Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB and PER into idle loop
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Friday, October 16, 2009 5:49 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB and
PER into idle loop
From: Tero Kristo tero.kri...@nokia.com
This is needed to prevent core from entering off mode if one of the IVA2,
USB or PER powerdomains are going to stay at least in retention state.
If this is not done, a powerdomain waking from RET may access core
domain which has just been reset.
From PRCM HW point of view, if any of non core domains do not enter OFF mode,
then Core cannot enter off mode. So I do not understand why you want to do
this change.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 36 +++-
1 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 588ab79..3e5ae14 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -85,6 +85,13 @@ u32 voltage_off_while_idle;
OMAP3430_ST_DES1_MASK)
#define CORE_IDLEST3_ALL (\
OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
+#define PER_IDLEST_ALL (\
+ OMAP3430_ST_WDT3_MASK|OMAP3430_ST_MCBSP4_MASK|\
+ OMAP3430_ST_MCBSP3_MASK|OMAP3430_ST_MCBSP2_MASK|\
+ OMAP3430_ST_GPT9_MASK|OMAP3430_ST_GPT8_MASK|\
+ OMAP3430_ST_GPT7_MASK|OMAP3430_ST_GPT6_MASK|\
+ OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
+ OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
struct power_state {
struct powerdomain *pwrdm;
@@ -103,7 +110,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm, *usb_pwrdm;
static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -428,6 +435,8 @@ void omap_sram_idle(void)
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
int dss_state = PWRDM_POWER_ON;
+ int iva2_state = PWRDM_POWER_ON;
+ int usb_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
@@ -463,14 +472,28 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ /* Get powerdomain state data */
+ core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+ dss_state = pwrdm_read_pwrst(dss_pwrdm);
+ iva2_state = pwrdm_read_pwrst(iva2_pwrdm);
+ usb_state = pwrdm_read_pwrst(usb_pwrdm);
+ per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
+
+ /* Check if PER domain can enter OFF or not */
+ if (per_next_state == PWRDM_POWER_OFF) {
+ if ((cm_read_mod_reg(OMAP3430_PER_MOD, CM_IDLEST)
+ PER_IDLEST_ALL) != PER_IDLEST_ALL) {
+ per_next_state = PWRDM_POWER_RET;
+ pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
+ per_state_modified = 1;
+ }
+ }
/*
* Check whether core will enter idle or not. This is needed
* because I/O pad wakeup will fail if core stays on and PER
* enters off. This will also prevent unnecessary core context
* save / restore.
*/
- core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- dss_state = pwrdm_read_pwrst(dss_pwrdm);
if (core_next_state PWRDM_POWER_ON) {
core_saved_state = core_next_state;
if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1) CORE_IDLEST1_ALL)
@@ -482,14 +505,16 @@ void omap_sram_idle(void)
core_next_state = PWRDM_POWER_ON;
pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
} else if (core_next_state == PWRDM_POWER_OFF
- dss_state == PWRDM_POWER_ON) {
+ (dss_state == PWRDM_POWER_ON ||
+ iva2_state = PWRDM_POWER_RET ||
+ usb_state = PWRDM_POWER_RET ||
+ per_next_state = PWRDM_POWER_RET)) {
core_next_state = PWRDM_POWER_RET;
pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
}
}
/* PER */
- per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
if (per_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
@@ -1240,6 +1265,7 @@
[PATCHV2] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration
As part of Core domain context restoration while coming out of off mode
there are some registers being restored which are not required to be restored.
ROM code should have restored them already. Overwriting some of them can have
potential side effect. Eg: CM_CLKEN_PLL register should not be written while
dpll is locked.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index fb864cc..88182a8 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -43,7 +43,6 @@ struct omap3_prcm_regs {
u32 iva2_cm_clksel2;
u32 cm_sysconfig;
u32 sgx_cm_clksel;
- u32 wkup_cm_clksel;
u32 dss_cm_clksel;
u32 cam_cm_clksel;
u32 per_cm_clksel;
@@ -52,7 +51,6 @@ struct omap3_prcm_regs {
u32 pll_cm_autoidle2;
u32 pll_cm_clksel4;
u32 pll_cm_clksel5;
- u32 pll_cm_clken;
u32 pll_cm_clken2;
u32 cm_polctrl;
u32 iva2_cm_fclken;
@@ -76,7 +74,6 @@ struct omap3_prcm_regs {
u32 usbhost_cm_iclken;
u32 iva2_cm_autiidle2;
u32 mpu_cm_autoidle2;
- u32 pll_cm_autoidle;
u32 iva2_cm_clkstctrl;
u32 mpu_cm_clkstctrl;
u32 core_cm_clkstctrl;
@@ -279,7 +276,6 @@ void omap3_prcm_save_context(void)
prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG);
prcm_context.sgx_cm_clksel =
cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL);
- prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
prcm_context.dss_cm_clksel =
cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL);
prcm_context.cam_cm_clksel =
@@ -296,8 +292,6 @@ void omap3_prcm_save_context(void)
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4);
prcm_context.pll_cm_clksel5 =
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
- prcm_context.pll_cm_clken =
- cm_read_mod_reg(PLL_MOD, CM_CLKEN);
prcm_context.pll_cm_clken2 =
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
@@ -343,8 +337,6 @@ void omap3_prcm_save_context(void)
cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2);
prcm_context.mpu_cm_autoidle2 =
cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2);
- prcm_context.pll_cm_autoidle =
-cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
prcm_context.iva2_cm_clkstctrl =
cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
prcm_context.mpu_cm_clkstctrl =
@@ -436,7 +428,6 @@ void omap3_prcm_restore_context(void)
__raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG);
cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD,
CM_CLKSEL);
- cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL);
cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD,
CM_CLKSEL);
cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD,
@@ -453,7 +444,6 @@ void omap3_prcm_restore_context(void)
OMAP3430ES2_CM_CLKSEL4);
cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
OMAP3430ES2_CM_CLKSEL5);
- cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
OMAP3430ES2_CM_CLKEN2);
__raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
@@ -492,7 +482,6 @@ void omap3_prcm_restore_context(void)
cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD,
CM_AUTOIDLE2);
cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2);
- cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE);
cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD,
CM_CLKSTCTRL);
cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use Constraint Framework
Sysfs entry vdd_opp currently does not use constraint framework.
Because of this, even if you set the opp via this entry, it has no effect
since it can be overridden by on demand governor any time.
This patch has changes to make vdd_opp to use constraint framework.
vdd_lock variable has to be used when application wants to disable DVFS
altogether. This will override any other constraints and will lock the
OPP to given value.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 13783f3..bcdc00d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -47,6 +47,8 @@ static ssize_t idle_store(struct kobject *k, struct
kobj_attribute *,
static ssize_t vdd_opp_show(struct kobject *, struct kobj_attribute *, char *);
static ssize_t vdd_opp_store(struct kobject *k, struct kobj_attribute *,
const char *buf, size_t n);
+static ssize_t vdd_opp_lock_store(struct kobject *k, struct kobj_attribute *,
+ const char *buf, size_t n);
static struct kobj_attribute vdd1_opp_attr =
__ATTR(vdd1_opp, 0644, vdd_opp_show, vdd_opp_store);
@@ -103,6 +105,41 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
const char *buf, size_t n)
{
unsigned short value;
+ struct omap_opp *opp_table;
+
+ if (sscanf(buf, %hu, value) != 1)
+ return -EINVAL;
+
+ if (attr == vdd1_opp_attr) {
+ if (value MIN_VDD1_OPP || value MAX_VDD1_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid value\n);
+ return -EINVAL;
+ }
+ opp_table = omap_get_mpu_rate_table();
+ omap_pm_cpu_set_freq(sysfs_cpufreq_dev,
+ opp_table[value].rate);
+ } else if (attr == vdd2_opp_attr) {
+ if (value MIN_VDD2_OPP || (value MAX_VDD2_OPP)) {
+ printk(KERN_ERR vdd_opp_store: Invalid value\n);
+ return -EINVAL;
+ }
+ if (value == VDD2_OPP2)
+ omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+ OCP_INITIATOR_AGENT, 83*1000*4);
+ else if (value == VDD2_OPP3)
+ omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+ OCP_INITIATOR_AGENT, 166*1000*4);
+
+ } else {
+ return -EINVAL;
+ }
+ return n;
+}
+
+static ssize_t vdd_opp_lock_store(struct kobject *kobj,
+ struct kobj_attribute *attr, const char *buf, size_t n)
+{
+ unsigned short value;
int flags = 0;
if (sscanf(buf, %hu, value) != 1)
@@ -121,6 +158,11 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
if (vdd1_locked == 0 value != 0) {
resource_lock_opp(VDD1_OPP);
vdd1_locked = 1;
+ if (value MIN_VDD1_OPP || value MAX_VDD1_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid
value\n);
+ return -EINVAL;
+ }
+ resource_set_opp_level(VDD1_OPP, value, flags);
}
} else if (attr == vdd2_lock_attr) {
flags = OPP_IGNORE_LOCK;
@@ -134,21 +176,12 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
if (vdd2_locked == 0 value != 0) {
resource_lock_opp(VDD2_OPP);
vdd2_locked = 1;
+ if (value MIN_VDD2_OPP || value MAX_VDD2_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid
value\n);
+ return -EINVAL;
+ }
+ resource_set_opp_level(VDD2_OPP, value, flags);
}
- }
-
- if (attr == vdd1_opp_attr) {
- if (value 1 || value 5) {
- printk(KERN_ERR vdd_opp_store: Invalid value\n);
- return -EINVAL;
- }
- resource_set_opp_level(VDD1_OPP, value, flags);
- } else if (attr == vdd2_opp_attr) {
- if (value 2 || value 3) {
- printk(KERN_ERR vdd_opp_store: Invalid value\n);
- return -EINVAL;
- }
- resource_set_opp_level(VDD2_OPP, value, flags);
} else {
return -EINVAL;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use Constraint Framework
Note that this patch has dependency on Patch sent by Romit (in attached email).
Vishwanath
-Original Message-
From: Sripathy, Vishwanath
Sent: Friday, October 16, 2009 2:26 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org; Hilman, Kevin
Subject: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use Constraint Framework
Sysfs entry vdd_opp currently does not use constraint framework.
Because of this, even if you set the opp via this entry, it has no effect
since it can be overridden by on demand governor any time.
This patch has changes to make vdd_opp to use constraint framework.
vdd_lock variable has to be used when application wants to disable DVFS
altogether. This will override any other constraints and will lock the
OPP to given value.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 13783f3..bcdc00d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -47,6 +47,8 @@ static ssize_t idle_store(struct kobject *k, struct
kobj_attribute *,
static ssize_t vdd_opp_show(struct kobject *, struct kobj_attribute *, char *);
static ssize_t vdd_opp_store(struct kobject *k, struct kobj_attribute *,
const char *buf, size_t n);
+static ssize_t vdd_opp_lock_store(struct kobject *k, struct kobj_attribute *,
+ const char *buf, size_t n);
static struct kobj_attribute vdd1_opp_attr =
__ATTR(vdd1_opp, 0644, vdd_opp_show, vdd_opp_store);
@@ -103,6 +105,41 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
const char *buf, size_t n)
{
unsigned short value;
+ struct omap_opp *opp_table;
+
+ if (sscanf(buf, %hu, value) != 1)
+ return -EINVAL;
+
+ if (attr == vdd1_opp_attr) {
+ if (value MIN_VDD1_OPP || value MAX_VDD1_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid value\n);
+ return -EINVAL;
+ }
+ opp_table = omap_get_mpu_rate_table();
+ omap_pm_cpu_set_freq(sysfs_cpufreq_dev,
+ opp_table[value].rate);
+ } else if (attr == vdd2_opp_attr) {
+ if (value MIN_VDD2_OPP || (value MAX_VDD2_OPP)) {
+ printk(KERN_ERR vdd_opp_store: Invalid value\n);
+ return -EINVAL;
+ }
+ if (value == VDD2_OPP2)
+ omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+ OCP_INITIATOR_AGENT, 83*1000*4);
+ else if (value == VDD2_OPP3)
+ omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+ OCP_INITIATOR_AGENT, 166*1000*4);
+
+ } else {
+ return -EINVAL;
+ }
+ return n;
+}
+
+static ssize_t vdd_opp_lock_store(struct kobject *kobj,
+ struct kobj_attribute *attr, const char *buf, size_t n)
+{
+ unsigned short value;
int flags = 0;
if (sscanf(buf, %hu, value) != 1)
@@ -121,6 +158,11 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
if (vdd1_locked == 0 value != 0) {
resource_lock_opp(VDD1_OPP);
vdd1_locked = 1;
+ if (value MIN_VDD1_OPP || value MAX_VDD1_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid
value\n);
+ return -EINVAL;
+ }
+ resource_set_opp_level(VDD1_OPP, value, flags);
}
} else if (attr == vdd2_lock_attr) {
flags = OPP_IGNORE_LOCK;
@@ -134,21 +176,12 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
if (vdd2_locked == 0 value != 0) {
resource_lock_opp(VDD2_OPP);
vdd2_locked = 1;
+ if (value MIN_VDD2_OPP || value MAX_VDD2_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid
value\n);
+ return -EINVAL;
+ }
+ resource_set_opp_level(VDD2_OPP, value, flags);
}
- }
-
- if (attr == vdd1_opp_attr) {
- if (value 1 || value 5) {
- printk(KERN_ERR vdd_opp_store: Invalid value\n);
- return -EINVAL;
- }
- resource_set_opp_level(VDD1_OPP, value, flags);
- } else if (attr == vdd2_opp_attr) {
- if (value 2 || value 3) {
- printk(KERN_ERR vdd_opp_store: Invalid value\n);
- return -EINVAL;
- }
- resource_set_opp_level(VDD2_OPP, value, flags);
} else {
return -EINVAL
[PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration
As part of Core domain context restoration while coming out of off mode there are some registers being restored which are not required to be restored. ROM code should have restored them already. Overwriting some of them can have potential side effect. Eg: CM_CLKEN_PLL register should not be written while dpll is locked. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index fb864cc..da16804 100644 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -279,7 +279,6 @@ void omap3_prcm_save_context(void) prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG); prcm_context.sgx_cm_clksel = cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL); - prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL); prcm_context.dss_cm_clksel = cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL); prcm_context.cam_cm_clksel = @@ -296,8 +295,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4); prcm_context.pll_cm_clksel5 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - prcm_context.pll_cm_clken = - cm_read_mod_reg(PLL_MOD, CM_CLKEN); prcm_context.pll_cm_clken2 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2); prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL); @@ -343,8 +340,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2); prcm_context.mpu_cm_autoidle2 = cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2); - prcm_context.pll_cm_autoidle = -cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE); prcm_context.iva2_cm_clkstctrl = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL); prcm_context.mpu_cm_clkstctrl = @@ -436,7 +431,6 @@ void omap3_prcm_restore_context(void) __raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG); cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD, CM_CLKSEL); - cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD, @@ -453,7 +447,6 @@ void omap3_prcm_restore_context(void) OMAP3430ES2_CM_CLKSEL4); cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN); cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD, OMAP3430ES2_CM_CLKEN2); __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL); @@ -492,7 +485,6 @@ void omap3_prcm_restore_context(void) cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD, CM_AUTOIDLE2); cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2); - cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE); cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD, CM_CLKSTCTRL); cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration
As part of Core domain context restoration while coming out of off mode there are some registers being restored which are not required to be restored. ROM code should have restored them already. Overwriting some of them can have potential side effect. Eg: CM_CLKEN_PLL register should not be written while dpll is locked. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index fb864cc..da16804 100644 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -279,7 +279,6 @@ void omap3_prcm_save_context(void) prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG); prcm_context.sgx_cm_clksel = cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL); - prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL); prcm_context.dss_cm_clksel = cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL); prcm_context.cam_cm_clksel = @@ -296,8 +295,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4); prcm_context.pll_cm_clksel5 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - prcm_context.pll_cm_clken = - cm_read_mod_reg(PLL_MOD, CM_CLKEN); prcm_context.pll_cm_clken2 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2); prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL); @@ -343,8 +340,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2); prcm_context.mpu_cm_autoidle2 = cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2); - prcm_context.pll_cm_autoidle = -cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE); prcm_context.iva2_cm_clkstctrl = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL); prcm_context.mpu_cm_clkstctrl = @@ -436,7 +431,6 @@ void omap3_prcm_restore_context(void) __raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG); cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD, CM_CLKSEL); - cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD, @@ -453,7 +447,6 @@ void omap3_prcm_restore_context(void) OMAP3430ES2_CM_CLKSEL4); cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN); cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD, OMAP3430ES2_CM_CLKEN2); __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL); @@ -492,7 +485,6 @@ void omap3_prcm_restore_context(void) cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD, CM_AUTOIDLE2); cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2); - cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE); cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD, CM_CLKSTCTRL); cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL); -- 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][RFC] OMAP3: PM: Adding OSWR support
Girish -Original Message- From: Ghongdemath, Girish Sent: Wednesday, September 02, 2009 5:03 AM To: Sripathy, Vishwanath; 'Tony Lindgren'; Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH][RFC] OMAP3: PM: Adding OSWR support -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath Subject: RE: [PATCH][RFC] OMAP3: PM: Adding OSWR support OSWR stands for Open Switch With Retention. This is one of the target power states where logic is lost for all the modules in the power domain except for the ones with Built in retention Flip Flops. This is the main difference between OFF and So, this's supported for CORE, PER and MPU? -Girish OSWR is supported for only for Core and MPU domains (in SW). PER will be in OFF state when Core is in OSWR. -- 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][RFC] OMAP3: PM: Adding OSWR support
OSWR stands for Open Switch With Retention. This is one of the target power states where logic is lost for all the modules in the power domain except for the ones with Built in retention Flip Flops. This is the main difference between OFF and OSWR mode. Because of this feature, wake up latency for OSWR is lesser than OFF mode but more than CSWR (Closed Switch With Retention - where module logic retained). Vishwa -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, August 28, 2009 9:37 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH][RFC] OMAP3: PM: Adding OSWR support * Thara Gopinath th...@ti.com [090827 09:54]: This patch adds OSWR support for MPU/CORE domains in CPUidle. Two new C states are being added to the existing C states which makes the new states look like below. Please explain what OSWR means, the patch description should be clear to everybody. I guess you mean Open SWitch Retention? 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: Warnings: pm branch
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Wednesday, August 12, 2009 6:59 PM
To: V, Hemanth
Cc: Pandita, Vikram; linux-omap@vger.kernel.org
Subject: Re: Warnings: pm branch
Hemanth V heman...@ti.com writes:
- Original Message -
From: Kevin Hilman khil...@deeprootsystems.com
To: Pandita, Vikram vikram.pand...@ti.com
Cc: linux-omap@vger.kernel.org
Sent: Tuesday, August 11, 2009 8:57 PM
Subject: Re: Warnings: pm branch
Pandita, Vikram vikram.pand...@ti.com writes:
Has anyone send these warning logs on the pm branch on kevin's tree [1]
This seems to be some issue in CpuIdle path with interrupts?
4WARNING: at arch/arm/kernel/process.c:171 cpu_idle+0x60/0x88()
WARNING: at arch/arm/kernel/process.c:171 cpu_idle+0x60/0x88()
dModules linked in:Modules linked in:
[c0031344] [c0031344] (unwind_backtrace+0x0/0xdc)
(unwind_backtrace+0x0/0xdc
) from [c0057a08] from [c0057a08] (warn_slowpath_common+0x48/0x60)
(warn_slowpath_common+0x48/0x60)
[c0057a08] [c0057a08] (warn_slowpath_common+0x48/0x60)
(warn_slowpath_common
+0x48/0x60) from [c002d204] from [c002d204] (cpu_idle+0x60/0x88)
(cpu_idle+0x60/0x88)
[c002d204] [c002d204] (cpu_idle+0x60/0x88) (cpu_idle+0x60/0x88) from
[c0008
a70] from [c0008a70] (start_kernel+0x234/0x28c)
(start_kernel+0x234/0x28c)
[c0008a70] [c0008a70] (start_kernel+0x234/0x28c)
(start_kernel+0x234/0x28c)
from [80008034] from [80008034] (0x80008034)
(0x80008034)
Yes, I've seen it, but have yet to debug it.
This warning is from the generic ARM idle loop reporting that the OMAP
idle path is returning with IRQs disabled.
Kevin
I did some more debugging on this. I added the below instrumentation to
local_irq_disable to capture
the PC of the last call to local_irq_disable.
extern unsigned long hem_pc;
register unsigned long current_pc asm (pc);
#define local_irq_disable() \
do { hem_pc = current_pc;raw_local_irq_disable();
trace_hardirqs_off(); } while (0)
When I set a breakpoint at the instruction pointing to
WARN_ON(irqs_disabled()) using
lauterbach and dump hem_pc, I see that the last call to irq_disable is
actuall from cpu_idle itself.
Looks like some recursion is happening. Does anyone have any inputs on this.
void cpu_idle(void)
{
local_fiq_enable();
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick(1);
leds_event(led_idle_start);
while (!need_resched()) {
#ifdef CONFIG_HOTPLUG_CPU
if (cpu_is_offline(smp_processor_id()))
cpu_die();
#endif
local_irq_disable();
Thanks
Hemanth
Below patch seems to fix the issue.
The question remains, who is disabling interrupts?
If this patch works, someone is disabling interrupts between the
enable in this routine and the return of this function.
Kevin
It's disabled in cpu_idle function itself before calling pm_idle
Here is the snap of cpu_idle
void cpu_idle(void)
{
local_fiq_enable();
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick(1);
leds_event(led_idle_start);
while (!need_resched()) {
#ifdef CONFIG_HOTPLUG_CPU
if (cpu_is_offline(smp_processor_id()))
cpu_die();
#endif
local_irq_disable(); //it's disabled here
if (hlt_counter) {
local_irq_enable();
cpu_relax();
} else {
stop_critical_timings();
pm_idle();
start_critical_timings();
/*
* This will eventually be removed - pm_idle
* functions should always return with IRQs
* enabled.
*/
WARN_ON(irqs_disabled());
local_irq_enable();
}
}
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 8504a21..3014104 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -75,8 +75,10 @@ static void cpuidle_idle_call(void)
#endif
/* ask the governor for the next state */
next_state = cpuidle_curr_governor-select(dev);
+
if (need_resched())
- return;
+ goto out;
+
target_state = dev-states[next_state];
/* enter the state and update stats */
@@ -91,6 +93,12 @@ static void cpuidle_idle_call(void)
/* give the governor an opportunity to reflect on the outcome */
if
