RE: [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman Sent: 04 March, 2011 18:56 To: Kristo Tero (Nokia-MS/Tampere) Cc: p...@pwsan.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on Hi Tero, tero.kri...@nokia.com writes: [...] + /* If DSS is active, prevent CORE RET/OFF */ + dss_state = pwrdm_read_pwrst(dss_pd); + if (dss_state == PWRDM_POWER_ON + core_next_state != PWRDM_POWER_ON) + core_next_state = PWRDM_POWER_INACTIVE; + Due to sleepdeps/autodeps, when this code runs, DSS powerdomain is always on. The result is that CORE is always set to INACTIVE. Now I recall that someone was asking about a patch similar to this earlier, and had the same issue with DSS sleepdep collision. What is the reason for having the sleepdep for DSS powerdomain anyway? At least I can't see any reason why the sleepdep for DSS should be set. In my opinion it should be perfectly okay for DSS domain to idle independently of MPU/CORE, as this is going to be better for power consumption also. Agreed, but currently the sleepdeps with MPU are automatically managed (by clkdm autodeps and hwmod initiator deps.) Until we have merged a solution to more selectively enable sleepdeps (or remove them) $SUBJECT patch cannot be merged. Ok I thought this is the case... it would be possible to implement a temporary/permanent solution that uses idle status check instead of pwrdm state check, and prevent core idle if dss is not going to idle. What is the current status with those idlest patches anyway? -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on
Hi Kevin, -Original Message- From: ext Kevin Hilman [mailto:khil...@ti.com] Sent: 04 March, 2011 01:25 To: Paul Walmsley Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Kristo Tero (Nokia-MS/Tampere) Subject: Re: [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on Paul Walmsley p...@pwsan.com writes: From: Tero Kristo tero.kri...@nokia.com Prevent the CORE power domain from entering RETENTION or OFF when DSS is on. Otherwise, the display FIFO(s) may underflow due to the time needed for the CORE to wake back up, causing tearing and unnecessary interrupts. Signed-off-by: Tero Kristo tero.kri...@nokia.com [p...@pwsan.com: wrote commit message] Signed-off-by: Paul Walmsley p...@pwsan.com This isn't quite ready for merge, and needs a little more testing with current DSS driver and mainline. --- arch/arm/mach-omap2/cpuidle34xx.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach- omap2/cpuidle34xx.c index 0335cd8..d1b7789 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -9,8 +9,9 @@ * Copyright (C) 2007 Texas Instruments, Inc. * Karthik Dasu karthik...@ti.com * - * Copyright (C) 2006 Nokia Corporation + * Copyright (C) 2006, 2011 Nokia Corporation * Tony Lindgren t...@atomide.com + * Tero Kristo tero.kri...@nokia.com * * Copyright (C) 2005 Texas Instruments, Inc. * Richard Woodruff r-woodru...@ti.com @@ -268,6 +269,12 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev, goto select_state; } +/* If DSS is active, prevent CORE RET/OFF */ +dss_state = pwrdm_read_pwrst(dss_pd); +if (dss_state == PWRDM_POWER_ON +core_next_state != PWRDM_POWER_ON) +core_next_state = PWRDM_POWER_INACTIVE; + Due to sleepdeps/autodeps, when this code runs, DSS powerdomain is always on. The result is that CORE is always set to INACTIVE. Now I recall that someone was asking about a patch similar to this earlier, and had the same issue with DSS sleepdep collision. What is the reason for having the sleepdep for DSS powerdomain anyway? At least I can't see any reason why the sleepdep for DSS should be set. In my opinion it should be perfectly okay for DSS domain to idle independently of MPU/CORE, as this is going to be better for power consumption also. A side effect of this problem is exposing a known issue with PER wakeups (UART3, GPIO). Since CORE never goes to retention/off, IO-pad wakeups are never enabled, so PER wakeups do not work. I think we need a different way of checking for DSS activity. Sounds like another usecase for idle notifiers. 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 0/2] OMAP3: cpuidle: prevent CORE pwrdm from entering low-power state when DSS active
-Original Message-
From: ext Paul Walmsley [mailto:p...@pwsan.com]
Sent: 02 March, 2011 00:49
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Kristo Tero (Nokia-MS/Tampere)
Subject: [PATCH 0/2] OMAP3: cpuidle: prevent CORE pwrdm from entering
low-power state when DSS active
This series prevents the OMAP3 CPUIdle code from programming the CORE
powerdomain to enter any power state lower than ON when the DSS power
domain
is ON. (The assumption is that in this case, the DSS is active, DMA'ing
lines from RAM and displaying them somewhere.)
Tero, please don't hesitate to comment on the patch from you if I got
the
commit message wrong.
Hi Paul,
It looks good to me.
- Paul
---
Tero Kristo (1):
OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF
when DSS is on
Paul Walmsley (1):
OMAP3: cpuidle: add more details to the DSS-related CORE power
domain state restriction
arch/arm/mach-omap2/cpuidle34xx.c | 36
++--
1 files changed, 34 insertions(+), 2 deletions(-)
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH] omap: dmtimer: Enable autoidle
-Original Message- From: ext Kevin Hilman [mailto:khil...@ti.com] Sent: 15 February, 2011 01:29 To: Kristo Tero (Nokia-MS/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: dmtimer: Enable autoidle Tero Kristo tero.kri...@nokia.com writes: This will save some power. Signed-off-by: Tero Kristo tero.kri...@nokia.com Please report which platforms this was tested with. Tested only on OMAP3. Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ +l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- 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: dmtimer: Enable autoidle
-Original Message- From: ext DebBarma, Tarun Kanti [mailto:tarun.ka...@ti.com] Sent: 15 February, 2011 11:31 To: Kristo Tero (Nokia-MS/Tampere); Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti Sent: Tuesday, February 15, 2011 2:50 PM To: tero.kri...@nokia.com; Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of tero.kri...@nokia.com Sent: Tuesday, February 15, 2011 1:47 PM To: Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: ext Kevin Hilman [mailto:khil...@ti.com] Sent: 15 February, 2011 01:29 To: Kristo Tero (Nokia-MS/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: dmtimer: Enable autoidle Tero Kristo tero.kri...@nokia.com writes: This will save some power. Signed-off-by: Tero Kristo tero.kri...@nokia.com Please report which platforms this was tested with. Tested only on OMAP3. Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. It works on OMAP2 and OMAP4. Ok, on OMAP4 I should have clarified further. AUTOIDLE is present only for millisecond timers: 1,2,10. The reset of the timers do not have this bit. Does it matter if the bit is set on the timers that don't have it or does the HW just ignore it? Or should we enumerate the timers that support it on omap4? -- Tarun Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ + l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- 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 -- 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: dmtimer: Enable autoidle
-Original Message- From: ext DebBarma, Tarun Kanti [mailto:tarun.ka...@ti.com] Sent: 15 February, 2011 11:52 To: Kristo Tero (Nokia-MS/Tampere); Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle [...] Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. It works on OMAP2 and OMAP4. Ok, on OMAP4 I should have clarified further. AUTOIDLE is present only for millisecond timers: 1,2,10. The reset of the timers do not have this bit. Does it matter if the bit is set on the timers that don't have it or does the HW just ignore it? Or should we enumerate the timers that support it on omap4? For other timers it happens to be SOFTRESET bit. So HW would not ignore. Ok, so this one should only be implemented for omap2/3 or added logic is needed for omap4. -- Tarun Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ +l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- 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 -- 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 save secure RAM to restore MPU power state
-Original Message-
From: ext Kevin Hilman [mailto:khil...@ti.com]
Sent: 26 January, 2011 02:50
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; Kristo Tero (Nokia-MS/Tampere)
Subject: [PATCH] OMAP3: PM: fix save secure RAM to restore MPU power
state
Currently, on HS/EMU devices, MPU power state forced to on during PM
init by the save secure RAM code. Rather than forcing the state of
MPU powerdomain to on, simply read the current value and restore it
after the ROM code has run.
This only affects the !CPUidle case since when CPUidle is enabled, the
MPU power state is dynamically changed by CPUidle. In the !CPUidle
case, MPU power state is initialized once at init and never touched.
Cc: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
If no objectsions, will be queued in my pm-fixes branch for 2.6.38-rc.
Looks good to me. Ack, if you need one.
arch/arm/mach-omap2/pm34xx.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8cbbead..1916038 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -168,9 +168,10 @@ static void omap3_core_restore_context(void)
* once during boot sequence, but this works as we are not using secure
* services.
*/
-static void omap3_save_secure_ram_context(u32 target_mpu_state)
+static void omap3_save_secure_ram_context(void)
{
u32 ret;
+ int mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
/*
@@ -181,7 +182,7 @@ static void omap3_save_secure_ram_context(u32
target_mpu_state)
pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
ret = _omap_save_secure_sram((u32 *)
__pa(omap3_secure_ram_storage));
- pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
+ pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
/* Following is for error tracking, it should not happen */
if (ret) {
printk(KERN_ERR save_secure_sram() returns %08x\n,
@@ -1094,7 +1095,7 @@ static int __init omap3_pm_init(void)
local_fiq_disable();
omap_dma_global_context_save();
- omap3_save_secure_ram_context(PWRDM_POWER_ON);
+ omap3_save_secure_ram_context();
omap_dma_global_context_restore();
local_irq_enable();
--
1.7.3.5
--
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: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of ext Vishwanath Sripathy
Sent: 19 January, 2011 06:39
To: Kristo Tero (Nokia-MS/Tampere); linux-omap@vger.kernel.org
Cc: Paul Walmsley; Kevin Hilman
Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
doing so would reset an active clockdomain
Tero,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Tuesday, January 18, 2011 3:18 PM
To: linux-omap@vger.kernel.org
Cc: Paul Walmsley; Kevin Hilman
Subject: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if doing
so would reset an active clockdomain
On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
parts of the chip will be reset. If those parts of the chip are busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results.
If some parts of the chip are busy, then how can Core domain enter off
state? The necessary condition for Core to enter low power state is that
all the clock domains (including DSS, CAM, IVA, USB, PER etc) should
have
idled. Doesn't it mean that all the modules have idled and asserted
idleack when Core is entering off state?
This can happen e.g. when some powerdomain has entered RET state. We have faced
this issue at least with IVA2 because it has its own power management.
Vishwa
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 40
+++-
1 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
omap2/cpuidle34xx.c
index f3e043f..d31b858 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -61,7 +61,7 @@ struct omap3_processor_cx {
struct omap3_processor_cx
omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
struct powerdomain *mpu_pd, *core_pd, *per_pd;
-struct powerdomain *cam_pd;
+struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd, *usb_pd;
/*
* The latencies/thresholds for various C states have
@@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct
cpuidle_device *dev,
{
struct cpuidle_state *new_state = next_valid_state(dev, state);
u32 core_next_state, per_next_state = 0, per_saved_state = 0;
-u32 cam_state;
+u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
struct omap3_processor_cx *cx;
int ret;
@@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct
cpuidle_device *dev,
*its own code.
*/
+/* XXX Add CORE-active check here */
+
/*
* Prevent idle completely if CAM is active.
* CAM does not have wakeup capability in OMAP3.
@@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct
cpuidle_device *dev,
(core_next_state PWRDM_POWER_RET))
per_next_state = PWRDM_POWER_RET;
+/* XXX Add prevent-PER-off check here */
+
+/*
+ * If we are attempting CORE off, check if any other
powerdomains
+ * are at retention or higher. CORE off causes chipwide reset
which
+ * would reset these domains also.
+ */
+if (core_next_state == PWRDM_POWER_OFF) {
+iva2_state = pwrdm_read_pwrst(iva2_pd);
+sgx_state = pwrdm_read_pwrst(sgx_pd);
+usb_state = pwrdm_read_pwrst(usb_pd);
+dss_state = pwrdm_read_pwrst(dss_pd);
+
+if (cam_state PWRDM_POWER_OFF ||
+dss_state PWRDM_POWER_OFF ||
+iva2_state PWRDM_POWER_OFF ||
+per_next_state PWRDM_POWER_OFF ||
+sgx_state PWRDM_POWER_OFF ||
+usb_state PWRDM_POWER_OFF)
+core_next_state = PWRDM_POWER_RET;
+}
+
+/* Fallback to new target core/mpu state */
+while (cx-core_state core_next_state) {
+state--;
+cx = cpuidle_get_statedata(state);
+}
+
+new_state = state;
+
/* Are we changing PER target state? */
if (per_next_state != per_saved_state)
pwrdm_set_next_pwrst(per_pd, per_next_state);
@@ -489,6 +521,10 @@ int __init omap3_idle_init(void)
core_pd = pwrdm_lookup(core_pwrdm);
per_pd = pwrdm_lookup(per_pwrdm);
cam_pd = pwrdm_lookup(cam_pwrdm);
+dss_pd = pwrdm_lookup(dss_pwrdm);
+iva2_pd = pwrdm_lookup(iva2_pwrdm);
+sgx_pd = pwrdm_lookup(sgx_pwrdm);
+usb_pd = pwrdm_lookup(usbhost_pwrdm);
omap_init_power_states();
cpuidle_register_driver(omap3_idle_driver);
--
1.7.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
RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
-Original Message-
From: ext Vishwanath Sripathy [mailto:vishwanath...@ti.com]
Sent: 19 January, 2011 08:06
To: Kristo Tero (Nokia-MS/Tampere); linux-omap@vger.kernel.org
Cc: Paul Walmsley; Kevin Hilman
Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
doing so would reset an active clockdomain
Tero,
-Original Message-
From: Vishwanath Sripathy [mailto:vishwanath...@ti.com]
Sent: Wednesday, January 19, 2011 10:09 AM
To: Tero Kristo; linux-omap@vger.kernel.org
Cc: Paul Walmsley; Kevin Hilman
Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
doing so would reset an active clockdomain
Tero,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Tuesday, January 18, 2011 3:18 PM
To: linux-omap@vger.kernel.org
Cc: Paul Walmsley; Kevin Hilman
Subject: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
doing
so would reset an active clockdomain
On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many
other
parts of the chip will be reset. If those parts of the chip are
busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results.
If some parts of the chip are busy, then how can Core domain enter off
state? The necessary condition for Core to enter low power state is
that
all the clock domains (including DSS, CAM, IVA, USB, PER etc) should
have
idled. Doesn't it mean that all the modules have idled and asserted
idleack when Core is entering off state?
Besides these, Core off should reset the modules which are only in Core
domain. It should not impact other power domains. Also Core domain
modules
which are reset will restore their context when Core comes out of off
mode. So why are you saying that If those parts of the chip are busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results.?
Core off issues reset to peripheral domains when it wakes up, this is somehow
(badly) visible in TRM (look for COREDOMAINWKUP_RST.) When this reset happens,
the peripheral domain shows its reset status as being high, but the powerdomain
itself has not entered off (previous state can be e.g. RET), thus its context
will not be restored.
Also, another justification for this patch is to prevent unnecessary core-off
when the device can't really idle at all = prevents unnecessary overhead
inside omap_sram_idle path.
Vishwa
Vishwa
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 40
+++-
1 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
omap2/cpuidle34xx.c
index f3e043f..d31b858 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -61,7 +61,7 @@ struct omap3_processor_cx {
struct omap3_processor_cx
omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
struct powerdomain *mpu_pd, *core_pd, *per_pd;
-struct powerdomain *cam_pd;
+struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd,
*usb_pd;
/*
* The latencies/thresholds for various C states have
@@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct
cpuidle_device *dev,
{
struct cpuidle_state *new_state = next_valid_state(dev, state);
u32 core_next_state, per_next_state = 0, per_saved_state = 0;
- u32 cam_state;
+ u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
struct omap3_processor_cx *cx;
int ret;
@@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct
cpuidle_device *dev,
*its own code.
*/
+ /* XXX Add CORE-active check here */
+
/*
* Prevent idle completely if CAM is active.
* CAM does not have wakeup capability in OMAP3.
@@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct
cpuidle_device *dev,
(core_next_state PWRDM_POWER_RET))
per_next_state = PWRDM_POWER_RET;
+ /* XXX Add prevent-PER-off check here */
+
+ /*
+ * If we are attempting CORE off, check if any other
powerdomains
+ * are at retention or higher. CORE off causes chipwide reset
which
+ * would reset these domains also.
+ */
+ if (core_next_state == PWRDM_POWER_OFF) {
+ iva2_state = pwrdm_read_pwrst(iva2_pd);
+ sgx_state = pwrdm_read_pwrst(sgx_pd);
+ usb_state = pwrdm_read_pwrst(usb_pd);
+ dss_state = pwrdm_read_pwrst(dss_pd);
+
+ if (cam_state PWRDM_POWER_OFF ||
+ dss_state PWRDM_POWER_OFF ||
+ iva2_state PWRDM_POWER_OFF ||
+ per_next_state PWRDM_POWER_OFF ||
+ sgx_state PWRDM_POWER_OFF ||
+ usb_state PWRDM_POWER_OFF)
+
RE: [PATCHv6] OMAP3: Serial: Improved sleep logic
-Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 10 March, 2010 20:21 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic Kevin Hilman khil...@deeprootsystems.com writes: Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com This patch contains following improvements: - Only RX interrupt will now kick the sleep prevent timer - TX fifo status is checked before disabling clocks, this will prevent on-going transmission to be cut - Smartidle is now enabled/disabled only while switching clocks, as having smartidle enabled while RX/TX prevents any wakeups from being received from UART module - Added workqueue for wakeup checks, as jiffy timer access within the idle loop results into skewed timers as jiffy timers are stopped - Added garbage_timer for ignoring the first character received during the first tick after clock enable, this prevents garbage characters to be received in low sleep states - omap_uart_enable_irqs() changed to use enable_irq / disable_irq instead of request / free. Using request/free changes the behavior after first suspend due to reversed interrupt handler ordering Signed-off-by: Tero Kristo tero.kri...@nokia.com Thanks Tero. This version looks good. Adding to pm-fixes queue for 2.6.34-rcX after minor change below... There's still something slightly strange going on here... I noticed via powertop that the garbage timer is now one of the top reasons for wakeup in an idle system. Seems like the garbage timer is firing when it shouldn't be, and triggering unnecessary wakeups Based on powertop stats, the garbage timer is firing about 3x more often than the GPtimer that should be waking the system. You get one timer expire each wakeup cycle, but the system actually fires its own timer for each UART, thus you get 3x. It is possible to optimize the timer a bit by only firing it if we have a wakeup from UART, but this probably causes occasional garbage to the console, if a wakeup from some other source than UART and UART RX happen at the same time. Might be the lesser of two evils though. I can experiment with this change a bit and see how it behaves. I haven't dug any deeper, but this needs to be fixed before merging upstream. 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: [PATCHv6] OMAP3: Serial: Improved sleep logic
-Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 11 March, 2010 18:30 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic tero.kri...@nokia.com writes: -Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 10 March, 2010 20:21 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic Kevin Hilman khil...@deeprootsystems.com writes: Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com This patch contains following improvements: - Only RX interrupt will now kick the sleep prevent timer - TX fifo status is checked before disabling clocks, this will prevent on-going transmission to be cut - Smartidle is now enabled/disabled only while switching clocks, as having smartidle enabled while RX/TX prevents any wakeups from being received from UART module - Added workqueue for wakeup checks, as jiffy timer access within the idle loop results into skewed timers as jiffy timers are stopped - Added garbage_timer for ignoring the first character received during the first tick after clock enable, this prevents garbage characters to be received in low sleep states - omap_uart_enable_irqs() changed to use enable_irq / disable_irq instead of request / free. Using request/free changes the behavior after first suspend due to reversed interrupt handler ordering Signed-off-by: Tero Kristo tero.kri...@nokia.com Thanks Tero. This version looks good. Adding to pm-fixes queue for 2.6.34-rcX after minor change below... There's still something slightly strange going on here... I noticed via powertop that the garbage timer is now one of the top reasons for wakeup in an idle system. Seems like the garbage timer is firing when it shouldn't be, and triggering unnecessary wakeups Based on powertop stats, the garbage timer is firing about 3x more often than the GPtimer that should be waking the system. You get one timer expire each wakeup cycle, but the system actually fires its own timer for each UART, thus you get 3x. It is possible to optimize the timer a bit by only firing it if we have a wakeup from UART, but this probably causes occasional garbage to the console, if a wakeup from some other source than UART and UART RX happen at the same time. Might be the lesser of two evils though. I can experiment with this change a bit and see how it behaves. OK, the 3x makes sense, but the garbage timer should never be the cause of a wakeup. Maybe you also need to be sure that the garbage timer is disabled before clocks are disabled so it doesn't fire and cause a wakeup. Yeah, that's another addition that I can do, but I don't think the system is actually woken up even though powertop claims so. Powertop is not too reliable wakeup source indicator, it only shows the number of expired timers / interrupts in most cases, but it does not know whether the device was sleeping when the interrupt was raised or not. The number of wakeups can be reliably seen from the number of PRCM interrupts that have occurred, but powertop does not parse the results too well for OMAP3 currently. And, there is no wakeup source indicator anyway available that would be exported from the kernel currently. I have fiddled at some point with a patch that does this, but I never posted it anywhere. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv6 9/9] OMAP3: PM: Added support for suspending to INACTIVE state
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 08 March, 2010 19:16
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv6 9/9] OMAP3: PM: Added support for
suspending to INACTIVE state
tero.kri...@nokia.com writes:
[...]
True, ancient info there. OFF for example has been supported
for ages already.
+ if (state != PWRDM_POWER_INACTIVE)
+ while (!(pwrdm-pwrsts (1 state))) {
+ if (state == PWRDM_POWER_OFF)
+ return ret;
+ state--;
+ }
I think all powerdomains can be inactive right?
Yes.
I think it would be cleaner to just have all the pwrdm-pwrsts fields
include intactive as a valid option.
Something like the patch below. IIRC, you did something like this in
one of the earlier versions of the patch.
Yeah, something like this was done previously, however Paul did not
like the idea of changing the generic powerdomain code too much so I
dropped it completely. It is now done only via the support functions
in patch #1, and only done for the powerdomains that actually need
it for the cpuidle (mpu/core/neon.) It would be possible to add
support for the rest of the powerdomains also, but I decided to drop
this in favor of getting the patch set in.
I'm not proposing changing any of the other powerdomain code. Just
changing the PWRSTS_* defines, essentially so that INACTIVE is
a valid state.
That will eliminate the need for a special check for inactive in this
patch.
This is a chicken-egg problem. If you alter the PWRSTS_* defines, you need to
change implementation of pwrdm_set_next_pwrst() as it would accept INACTIVE
also, which is not supported by the code right now.
Kevin
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index a1ecd47..c692472 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -31,17 +31,17 @@
#define PWRDM_MAX_PWRSTS4
/* Powerdomain allowable state bitfields */
-#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF) | \
+#define PWRSTS_ON ((1 PWRDM_POWER_INACTIVE) | \
(1 PWRDM_POWER_ON))
+#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF)
| PWRSTS_ON)
+
#define PWRSTS_OFF_RET ((1 PWRDM_POWER_OFF) | \
(1 PWRDM_POWER_RET))
-#define PWRSTS_RET_ON ((1 PWRDM_POWER_RET) | \
- (1 PWRDM_POWER_ON))
-
-#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 PWRDM_POWER_ON))
+#define PWRSTS_RET_ON ((1 PWRDM_POWER_RET)
| PWRSTS_ON)
+#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | PWRSTS_ON)
/* Powerdomain flags */
#define PWRDM_HAS_HDWR_SAR (1 0) /* hardware
save-and-restore support */
--
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: GPIO: Added dynamic control logic for pad wakeups
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 08 March, 2010 19:06
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: GPIO: Added dynamic control logic
for pad wakeups
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Pad wakeups are now enabled if the corresponding GPIO
interrupt is enabled.
Applies on top of PM branch.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
I just discovered this one in patchwork... sorry for the delay.
Changes in wakeup state should not be directly correlated to interrupt
enabled GPIOs. Rather, this should only be done for GPIOs that are
explicitly wakeup enabled (via enable_irq_wake(), which in turn
calls gpio_wake_enable()).
This logic somehow escapes me... I would guess drivers should not care during
dynamic idle whether the device is in off/ret/ina and interrupts should just
work. This is done to make this happen. Also, I understood that gpio wakeup
logic is needed for the suspend wakeup, which is quite different from dynamic
idle wakeup.
However, if this is intended behavior for the kernel, then I will accept it.
You are saying the code below should be moved into the gpio_wake_enable() /
disable() calls?
A couple other minor comments below...
---
arch/arm/plat-omap/gpio.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index e242112..fa79db2 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -267,6 +267,7 @@ static struct gpio_bank gpio_bank_34xx[6] = {
#define OMAP34XX_PAD_SAFE_MODE 0x7
#define OMAP34XX_PAD_IN_PU_GPIO 0x11c
#define OMAP34XX_PAD_IN_PD_GPIO 0x10c
+#define OMAP34XX_PAD_WAKE_EN (1 14)
Can use BIT(14) here
struct omap3_gpio_regs {
u32 sysconfig;
@@ -713,6 +714,8 @@ static inline void
set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
{
void __iomem *base = bank-base;
u32 gpio_bit = 1 gpio;
+struct gpio_pad *pad;
+int gpio_num;
u32 val;
if (cpu_is_omap44xx()) {
@@ -750,6 +753,23 @@ static inline void
set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
* GPIO wakeup request can only be
generated on edge
* transitions
*/
The comment above needs to stay with the original code.
+pad = gpio_pads;
+
+gpio_num = bank-virtual_irq_start -
IH_GPIO_BASE +
+gpio;
+/* Find the pad corresponding the GPIO */
+while (pad-gpio = 0 pad-gpio != gpio_num)
+pad++;
+/* Enable / disable pad wakeup */
+if (pad-gpio == gpio_num) {
+val = omap_ctrl_readw(pad-offset);
+if (trigger IRQ_TYPE_EDGE_BOTH)
+val |= OMAP34XX_PAD_WAKE_EN;
+else
+val =
~(u16)OMAP34XX_PAD_WAKE_EN;
+omap_ctrl_writew(val, pad-offset);
+}
+
if (trigger IRQ_TYPE_EDGE_BOTH)
__raw_writel(1 gpio, bank-base
+ OMAP24XX_GPIO_SETWKUENA);
@@ -1654,7 +1674,7 @@ static int __init omap3_gpio_pads_init(void)
gpio_pads[gpio_amt].gpio = -1;
return 0;
}
-late_initcall(omap3_gpio_pads_init);
+early_initcall(omap3_gpio_pads_init);
This change isn't explained in the changelog and appears unrelated to
this patch.
The reason for this change is that we need the gpio-pad mapping early now to
enable wakeups properly. Otherwise some components can enable gpio interrupts
early in the boot cycle and they will miss their wakeup setting because the map
does not exist yet. I think another way to do this would be to enable wakeups
for all enabled interrupts during the omap3_gpio_pads_init().
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv6 9/9] OMAP3: PM: Added support for suspending to INACTIVE state
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 02 March, 2010 01:43
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv6 9/9] OMAP3: PM: Added support for
suspending to INACTIVE state
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
With the new support functions this is now possible.
Suspending to INACTIVE
is useful for testing purposes.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index cdbedcf..41d6cc3 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -633,11 +633,12 @@ int set_pwrdm_state(struct powerdomain
*pwrdm, u32 state)
if (pwrdm == NULL || IS_ERR(pwrdm))
return -EINVAL;
-while (!(pwrdm-pwrsts (1 state))) {
-if (state == PWRDM_POWER_OFF)
-return ret;
-state--;
-}
The comment above set_pwrdm_state() says only ON RET are supported.
Please update that comment as well.
True, ancient info there. OFF for example has been supported for ages already.
+if (state != PWRDM_POWER_INACTIVE)
+while (!(pwrdm-pwrsts (1 state))) {
+if (state == PWRDM_POWER_OFF)
+return ret;
+state--;
+}
I think all powerdomains can be inactive right?
Yes.
I think it would be cleaner to just have all the pwrdm-pwrsts fields
include intactive as a valid option.
Something like the patch below. IIRC, you did something like this in
one of the earlier versions of the patch.
Yeah, something like this was done previously, however Paul did not like the
idea of changing the generic powerdomain code too much so I dropped it
completely. It is now done only via the support functions in patch #1, and only
done for the powerdomains that actually need it for the cpuidle
(mpu/core/neon.) It would be possible to add support for the rest of the
powerdomains also, but I decided to drop this in favor of getting the patch set
in.
Kevin
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index a1ecd47..c692472 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -31,17 +31,17 @@
#define PWRDM_MAX_PWRSTS 4
/* Powerdomain allowable state bitfields */
-#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF) | \
+#define PWRSTS_ON ((1 PWRDM_POWER_INACTIVE) | \
(1 PWRDM_POWER_ON))
+#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF) | PWRSTS_ON)
+
#define PWRSTS_OFF_RET((1 PWRDM_POWER_OFF) | \
(1 PWRDM_POWER_RET))
-#define PWRSTS_RET_ON ((1 PWRDM_POWER_RET) | \
- (1 PWRDM_POWER_ON))
-
-#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 PWRDM_POWER_ON))
+#define PWRSTS_RET_ON ((1 PWRDM_POWER_RET) | PWRSTS_ON)
+#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | PWRSTS_ON)
/* Powerdomain flags */
#define PWRDM_HAS_HDWR_SAR(1 0) /* hardware
save-and-restore support */
--
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: [PATCHv6 4/9] OMAP3: PM: Removed pwrdm state hacking from omap_sram_idle
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 02 March, 2010 01:32
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv6 4/9] OMAP3: PM: Removed pwrdm state
hacking from omap_sram_idle
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Following hacks will be moved inside cpuidle in subsequent patch:
- CAM domain prevents idle completely
- PER should not go OFF if core remains active
This simplifies the design and allows cpuidle to keep better
track of which
power states system will actually enter.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
I think this should be combined with PATCH 7. IOW, the removal and
re-addition should be in the same patch.
Ok, will change this.
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 19 ++-
1 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index c2d80fc..cdbedcf 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,7 +93,6 @@ static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm;
static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -373,7 +372,6 @@ void omap_sram_idle(void)
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
-int per_state_modified = 0;
if (!_omap_sram_idle)
return;
@@ -411,20 +409,11 @@ void omap_sram_idle(void)
core_next_state = omap3_pwrdm_read_next_pwrst(core_pwrdm);
if (per_next_state PWRDM_POWER_ON) {
omap2_gpio_prepare_for_idle(per_next_state);
-if (per_next_state == PWRDM_POWER_OFF) {
-if (core_next_state == PWRDM_POWER_ON) {
-per_next_state = PWRDM_POWER_RET;
-pwrdm_set_next_pwrst(per_pwrdm,
per_next_state);
-per_state_modified = 1;
-} else
-omap3_per_save_context();
-}
+if (per_next_state == PWRDM_POWER_OFF)
+omap3_per_save_context();
omap_uart_prepare_idle(2);
}
-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.
@@ -554,8 +543,6 @@ void omap_sram_idle(void)
}
omap2_gpio_resume_after_idle();
omap_uart_resume_idle(2);
-if (per_state_modified)
-pwrdm_set_next_pwrst(per_pwrdm,
PWRDM_POWER_OFF);
}
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -564,7 +551,6 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
-
pwrdm_post_transition();
}
@@ -1239,7 +1225,6 @@ static int __init omap3_pm_init(void)
neon_pwrdm = pwrdm_lookup(neon_pwrdm);
per_pwrdm = pwrdm_lookup(per_pwrdm);
core_pwrdm = pwrdm_lookup(core_pwrdm);
-cam_pwrdm = pwrdm_lookup(cam_pwrdm);
neon_clkdm = clkdm_lookup(neon_clkdm);
mpu_clkdm = clkdm_lookup(mpu_clkdm);
--
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: [PATCHv6 1/9] OMAP3: PM: Added support functions for omap3 pwrdm handling
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 02 March, 2010 01:17
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv6 1/9] OMAP3: PM: Added support functions
for omap3 pwrdm handling
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Added omap3_pwrdm_set_next_pwrst and
omap3_pwrdm_read_next_pwrst. These
functions add support for INACTIVE and ON states to the standard OMAP
powerdomain functions, and add caching logic for the next
state. These
functions are used in subsequent patches to simplify the
logic of the idle
loop.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/pm34xx.c | 60
+-
2 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 75aa685..1d9a740 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -67,6 +67,8 @@ static inline void omap3_pm_init_vc(struct
prm_setup_vc *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 omap3_pwrdm_set_next_pwrst(struct powerdomain
*pwrdm, u8 pwrst);
+extern int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm);
extern u32 wakeup_timer_seconds;
extern struct omap_dm_timer *gptimer_wakeup;
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 1359ec9..f20d3d8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -576,6 +576,64 @@ int omap3_can_sleep(void)
return 1;
}
+struct powerdomain_data {
+u8 next_state;
+u8 init_done;
+};
+
+static struct powerdomain_data mpu_pwrdm_data;
+static struct powerdomain_data core_pwrdm_data;
+static struct powerdomain_data neon_pwrdm_data;
+
+static struct powerdomain_data *get_pwrdm_data(struct
powerdomain *pwrdm)
+{
+if (pwrdm == mpu_pwrdm)
+return mpu_pwrdm_data;
+else if (pwrdm == core_pwrdm)
+return core_pwrdm_data;
+else if (pwrdm == neon_pwrdm)
+return neon_pwrdm_data;
+return NULL;
+}
+
+int omap3_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
I think this func should be documented along the lines of the
changelog.
It should describe the caching and the fact that 'INACTIVE' is a state
that can be read, but not written.
Ok, will do the change.
+{
+struct powerdomain_data *data = get_pwrdm_data(pwrdm);
+u8 prg_pwrst;
+
+if (!data)
+return pwrdm_set_next_pwrst(pwrdm, pwrst);
+
+if (!data-init_done)
+data-init_done = 1;
Not sure I follow the purpose of the 'init_done' flag here,
but I'm having
an averse reaction to it.
init_done actually means if the cache is valid or not. If not, we ignore the
current cached state. Another way of doing this would be to initialize all
values at proper point during boot by reading from HW, or just put the HW reset
values to the cache during compile time. The cache validity bit is needed in
the read_next_pwrst code also below.
+else if (data-next_state == pwrst)
+return 0;
+
+if (pwrst == PWRDM_POWER_INACTIVE)
+prg_pwrst = PWRDM_POWER_ON;
+else
+prg_pwrst = pwrst;
+
+pwrdm_set_next_pwrst(pwrdm, prg_pwrst);
+
+if (pwrst == PWRDM_POWER_ON)
+omap2_clkdm_deny_idle(pwrdm-pwrdm_clkdms[0]);
+else
+omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+
+data-next_state = pwrst;
+return 0;
+}
+
+int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
+{
+struct powerdomain_data *data = get_pwrdm_data(pwrdm);
+
+if (!data || !data-init_done)
+return pwrdm_read_next_pwrst(pwrdm);
+return data-next_state;
+}
+
/* This sets pwrdm state (other than mpu core. Currently only ON
* RET are supported. Function is assuming that clkdm doesn't have
* hw_sup mode enabled. */
@@ -604,7 +662,7 @@ int set_pwrdm_state(struct powerdomain
*pwrdm, u32 state)
pwrdm_wait_transition(pwrdm);
}
-ret = pwrdm_set_next_pwrst(pwrdm, state);
+ret = omap3_pwrdm_set_next_pwrst(pwrdm, state);
if (ret) {
printk(KERN_ERR Unable to set state of
powerdomain: %s\n,
pwrdm-name);
--
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: [PATCHv5] OMAP3: Serial: Improved sleep logic
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 24 February, 2010 18:05
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv5] OMAP3: Serial: Improved sleep logic
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
This patch contains following improvements:
- Only RX interrupt will now kick the sleep prevent timer
- TX fifo status is checked before disabling clocks, this
will prevent
on-going transmission to be cut
- Smartidle is now enabled/disabled only while switching
clocks, as having
smartidle enabled while RX/TX prevents any interrupts from being
received from UART module
- Sleep prevent timer is changed to use timespec instead of
a jiffy timer
as jiffy timers are not valid within idle loop (tick
scheduler is stopped)
Could also probably use hrtimers for this.
Maybe, I didn't try this out though. It is possible that there are some issues
as hrtimers use ktime() as far as I understand and it is not accessible during
suspend. There is a separate issue with this patch and suspend though, I am
currently working on a fix for that. Suspend skewes the timebase even more, and
we get expire timers that point far into the future after suspend.
That being said, I'm not sure what is the problem you're trying to
solve with this change. I don't see any timings that are timing events
inside the idle loop.
Here is the call-chain that currently accesses jiffies count incorrectly:
cpu_idle:
tick_nohz_stop_sched_tick(1); /* jiffy timer stops here */
omap_sram_idle();
omap_uart_prepare_idle();
asm(wfi); /* sleep here for N seconds */
omap_uart_resume_idle(); /* This call uses incorrect jiffy timer now */
tick_nohz_restart_sched_tick(); /* jiffy timer restarted here, and jiffy
timer is refreshed also to correct value */
- Added RX ignore timer for ignoring the first character
received during
first millisecond of wakeup, this prevents garbage
character to be receive
in low sleep states
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Something is still not quite right here.
This doesn't work on my n900 here when testing this patch on top of
the PM branch. The default is now a default timeout of zero. When I
enable a 5 sec. timeout for UART2 on RX-51, when the timer expires, I
no longer have response on the console.
To test, I booted my n900 with init=/bin/sh to avoid all the setup
done by /sbin/preinit. Then I enabled a timeout for UART2 only, and
then the console hangs.
Here's my hunch as to what's happening:
I think the problem is a deadlock in getrawmonotonic(). Nested calls
here will deadlock due to the xtime_lock being held.
Looking at the seqlock code, I think a seqlock reader can hang only in a case
where someone is constantly writing the seqlock. And, as we are inside
interrupt, this should not be possible.
When updading the timeout, sleep_timeout_store() does a
getrawmonotonic() to update the expiry time. While this happening,
the UART interrupt could fire, causing an omap_uart_block_sleep()
which would also getrawmonotonic() and deadlock in interrupt mode.
It does not really explain why it hangs after the 5 second period though, as
the device has called getrawmonotonic several times by this already. I have not
seen this kind of behavior in my testing, even while fiddling with the
sleep_timeout_store().
Anyway, I'll attempt to re-run my test on the latest PM / master branches and
see what happens.
Kevin
---
arch/arm/mach-omap2/serial.c | 98
+
1 files changed, 69 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 5f3035e..f49c465 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -29,6 +29,8 @@
#include plat/clock.h
#include plat/control.h
+#include asm/div64.h
+
#include prm.h
#include pm.h
#include prm-regbits-34xx.h
@@ -42,13 +44,14 @@
* disabled via sysfs. This also causes that any deeper
omap sleep states are
* blocked.
*/
-#define DEFAULT_TIMEOUT 0
+#define DEFAULT_TIMEOUT (0LL * NSEC_PER_SEC)
struct omap_uart_state {
int num;
int can_sleep;
-struct timer_list timer;
-u32 timeout;
+struct timespec expire_time;
+struct timespec garbage_time;
+u64 timeout;
void __iomem *wk_st;
void __iomem *wk_en;
@@ -243,6 +246,9 @@ static inline void
omap_uart_save_context(struct omap_uart_state *uart) {}
static inline void omap_uart_restore_context(struct
omap_uart_state *uart) {}
#endif /* CONFIG_PM CONFIG_ARCH_OMAP3 */
+static void omap_uart_smart_idle_enable(struct
omap_uart_state *uart,
+int enable);
+
static inline void omap_uart_enable_clocks(struct
omap_uart_state *uart)
{
if (uart-clocked)
@@ -250,8 +256,13 @@ static inline void
RE: [PATCHv5] OMAP3: Serial: Improved sleep logic
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman Sent: 25 February, 2010 17:21 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv5] OMAP3: Serial: Improved sleep logic tero.kri...@nokia.com writes: [...] Here's my hunch as to what's happening: I think the problem is a deadlock in getrawmonotonic(). Nested calls here will deadlock due to the xtime_lock being held. Looking at the seqlock code, I think a seqlock reader can hang only in a case where someone is constantly writing the seqlock. And, as we are inside interrupt, this should not be possible. When updading the timeout, sleep_timeout_store() does a getrawmonotonic() to update the expiry time. While this happening, the UART interrupt could fire, causing an omap_uart_block_sleep() which would also getrawmonotonic() and deadlock in interrupt mode. It does not really explain why it hangs after the 5 second period though, as the device has called getrawmonotonic several times by this already. I have not seen this kind of behavior in my testing, even while fiddling with the sleep_timeout_store(). minor clarification... For me the hang is not after the 5 second timeout. For me it happens as soon as I write a non-zero value to /sys/devices/.../serial8250.2/sleep_timeout. It looks somewhat weird... I did some debugging on this today and I am seeing the same hang here, and it actually seems to be caused by the getrawmonotonic() somehow, as the system did not hang anymore after I removed the calls. Anyway, I figured another way to solve the issues I am seeing. I reverted back to using jiffy timers, but added a workqueue for wakeups; now wakeup timers are kicked into action after the timebase is restored. I'll post the new patch right away. There is still one issue with the UART though; some TX is still lost because PM code does not currently prevent CORE off while PER is active, basically resetting the PER domain when CORE goes off. This would be fixed by the cpuidle set I posted a bit back. Another note, I am seeing really strange behavior for my n900 with current linux-omap tree. PM branch boots up nicely, but it does not go into dynamic idle until I force it to suspend once Also, master branch crashes mid-boot to an ubifs caused DMA failure. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv4] OMAP3: Serial: Improved sleep logic
Grr, ktime_get() is not accessible during suspend, and thus this patch causes a
WARN during wakeup from suspend. I'll convert the patch to use
getrawmonotonic() instead, sending out a refreshed one soon.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo
Tero (Nokia-D/Tampere)
Sent: 12 February, 2010 20:23
To: linux-omap@vger.kernel.org
Subject: [PATCHv4] OMAP3: Serial: Improved sleep logic
From: Tero Kristo tero.kri...@nokia.com
This patch contains following improvements:
- Only RX interrupt will now kick the sleep prevent timer
- TX fifo status is checked before disabling clocks, this will prevent
on-going transmission to be cut
- Smartidle is now enabled/disabled only while switching
clocks, as having
smartidle enabled while RX/TX prevents any wakeups from being
received from UART module
- Sleep prevent timer is changed to use ktime_get() instead of
a jiffy timer
as jiffy timers are not valid within idle loop (tick
scheduler is stopped)
- Added RX ignore timer for ignoring the first character
received during
first millisecond of wakeup, this prevents garbage character
to be receive
in low sleep states
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/serial.c | 79
+++--
1 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 5f3035e..4be9ace 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -29,6 +29,8 @@
#include plat/clock.h
#include plat/control.h
+#include asm/div64.h
+
#include prm.h
#include pm.h
#include prm-regbits-34xx.h
@@ -42,13 +44,14 @@
* disabled via sysfs. This also causes that any deeper omap
sleep states are
* blocked.
*/
-#define DEFAULT_TIMEOUT 0
+#define DEFAULT_TIMEOUT (0LL * NSEC_PER_SEC)
struct omap_uart_state {
int num;
int can_sleep;
- struct timer_list timer;
- u32 timeout;
+ ktime_t expire_time;
+ ktime_t garbage_time;
+ u64 timeout;
void __iomem *wk_st;
void __iomem *wk_en;
@@ -243,6 +246,9 @@ static inline void
omap_uart_save_context(struct omap_uart_state *uart) {}
static inline void omap_uart_restore_context(struct
omap_uart_state *uart) {}
#endif /* CONFIG_PM CONFIG_ARCH_OMAP3 */
+static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
+ int enable);
+
static inline void omap_uart_enable_clocks(struct
omap_uart_state *uart)
{
if (uart-clocked)
@@ -250,8 +256,12 @@ static inline void
omap_uart_enable_clocks(struct omap_uart_state *uart)
clk_enable(uart-ick);
clk_enable(uart-fck);
+ omap_uart_smart_idle_enable(uart, 0);
uart-clocked = 1;
omap_uart_restore_context(uart);
+
+ /* Set up garbage timer to ignore RX during first 1ms */
+ uart-garbage_time = ktime_add_ns(ktime_get(), NSEC_PER_MSEC);
}
#ifdef CONFIG_PM
@@ -263,6 +273,7 @@ static inline void
omap_uart_disable_clocks(struct omap_uart_state *uart)
omap_uart_save_context(uart);
uart-clocked = 0;
+ omap_uart_smart_idle_enable(uart, 1);
clk_disable(uart-ick);
clk_disable(uart-fck);
}
@@ -320,12 +331,9 @@ static void omap_uart_block_sleep(struct
omap_uart_state *uart)
{
omap_uart_enable_clocks(uart);
- omap_uart_smart_idle_enable(uart, 0);
uart-can_sleep = 0;
if (uart-timeout)
- mod_timer(uart-timer, jiffies + uart-timeout);
- else
- del_timer(uart-timer);
+ uart-expire_time = ktime_add_ns(ktime_get(),
uart-timeout);
}
static void omap_uart_allow_sleep(struct omap_uart_state *uart)
@@ -338,16 +346,7 @@ static void omap_uart_allow_sleep(struct
omap_uart_state *uart)
if (!uart-clocked)
return;
- omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
- del_timer(uart-timer);
-}
-
-static void omap_uart_idle_timer(unsigned long data)
-{
- struct omap_uart_state *uart = (struct omap_uart_state *)data;
-
- omap_uart_allow_sleep(uart);
}
void omap_uart_prepare_idle(int num)
@@ -355,8 +354,14 @@ void omap_uart_prepare_idle(int num)
struct omap_uart_state *uart;
list_for_each_entry(uart, uart_list, node) {
+ if (num == uart-num !uart-can_sleep
uart-timeout)
+ if (ktime_get().tv64 uart-expire_time.tv64)
+ uart-can_sleep = 1;
+
if (num == uart-num uart-can_sleep) {
- omap_uart_disable_clocks(uart);
+ if (serial_read_reg(uart-p, UART_LSR)
+ UART_LSR_TEMT)
+ omap_uart_disable_clocks(uart);
return;
}
}
@@ -404,6 +409,10 @@ int omap_uart_can_sleep(void)
if
RE: [PATCH] OMAP3: Serial: Improved sleep logic
This patch can be ignored. The RX fifo clear logic did not really work for low
C states (C1 / C2) and you would still get garbage. I'll send an updated patch
where I have replaced the logic by an ignore timer for the first millisecond
after clocks are enabled. Also, I forgot v2 out from this.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo
Tero (Nokia-D/Tampere)
Sent: 10 February, 2010 18:29
To: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP3: Serial: Improved sleep logic
From: Tero Kristo tero.kri...@nokia.com
This patch contains following improvements:
- Only RX interrupt will now kick the sleep prevent timer
- TX fifo status is checked before disabling clocks, this will prevent
on-going transmission to be cut
- Smartidle is disabled while entering idle if we have data in
the transmit
buffer because having this enabled would prevent wakeups from the TX
interrupt and this would cause pauses while sending large
blocks of data
- Sleep prevent timer is changed to use ktime_get() instead of
a jiffy timer
as jiffy timers are not valid within idle loop (tick
scheduler is stopped)
- RX and TX fifos are cleared when clocks are enabled, this
will purge the
first character from RX fifo, which is most likely garbage
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/serial.c | 70
+++---
1 files changed, 45 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 837b347..d7d96ba 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,12 +23,15 @@
#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
+#include linux/delay.h
#include plat/common.h
#include plat/board.h
#include plat/clock.h
#include plat/control.h
+#include asm/div64.h
+
#include prm.h
#include pm.h
#include prm-regbits-34xx.h
@@ -36,13 +39,13 @@
#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV 0x52
#define UART_OMAP_WER 0x17/* Wake-up enable register */
-#define DEFAULT_TIMEOUT (5 * HZ)
+#define DEFAULT_TIMEOUT (5LL * NSEC_PER_SEC)
struct omap_uart_state {
int num;
int can_sleep;
- struct timer_list timer;
- u32 timeout;
+ ktime_t expire_time;
+ u64 timeout;
void __iomem *wk_st;
void __iomem *wk_en;
@@ -231,6 +234,9 @@ static inline void
omap_uart_enable_clocks(struct omap_uart_state *uart)
clk_enable(uart-fck);
uart-clocked = 1;
omap_uart_restore_context(uart);
+
+ /* Clear RX and TX fifos, as they contain garbage at
this point */
+ serial_write_reg(uart-p, UART_FCR, 0xa7);
}
#ifdef CONFIG_PM
@@ -302,9 +308,7 @@ static void omap_uart_block_sleep(struct
omap_uart_state *uart)
omap_uart_smart_idle_enable(uart, 0);
uart-can_sleep = 0;
if (uart-timeout)
- mod_timer(uart-timer, jiffies + uart-timeout);
- else
- del_timer(uart-timer);
+ uart-expire_time = ktime_add_ns(ktime_get(),
uart-timeout);
}
static void omap_uart_allow_sleep(struct omap_uart_state *uart)
@@ -317,25 +321,28 @@ static void omap_uart_allow_sleep(struct
omap_uart_state *uart)
if (!uart-clocked)
return;
- omap_uart_smart_idle_enable(uart, 1);
+ if (serial_read_reg(uart-p, UART_LSR) UART_LSR_TEMT)
+ omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
- del_timer(uart-timer);
-}
-
-static void omap_uart_idle_timer(unsigned long data)
-{
- struct omap_uart_state *uart = (struct omap_uart_state *)data;
-
- omap_uart_allow_sleep(uart);
}
void omap_uart_prepare_idle(int num)
{
struct omap_uart_state *uart;
+ ktime_t t;
list_for_each_entry(uart, uart_list, node) {
+ if (num == uart-num !uart-can_sleep) {
+ t = ktime_get();
+ if (t.tv64 uart-expire_time.tv64)
+ uart-can_sleep = 1;
+ }
if (num == uart-num uart-can_sleep) {
- omap_uart_disable_clocks(uart);
+ if (serial_read_reg(uart-p, UART_LSR)
+ UART_LSR_TEMT)
+ omap_uart_disable_clocks(uart);
+ else
+ omap_uart_smart_idle_enable(uart, 0);
return;
}
}
@@ -360,6 +367,7 @@ void omap_uart_resume_idle(int num)
/* Check for normal UART wakeup */
if (__raw_readl(uart-wk_st) uart-wk_mask)
omap_uart_block_sleep(uart);
+
return;
}
}
@@ -407,8 +415,14 @@ int omap_uart_can_sleep(void)
static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
{
struct
RE: [PATCH] OMAP3: Serial: Improved sleep logic
-Original Message-
From: ext Tony Lindgren [mailto:t...@atomide.com]
Sent: 04 February, 2010 18:11
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
* tero.kri...@nokia.com tero.kri...@nokia.com [100203 23:59]:
-Original Message-
From: ext Tony Lindgren [mailto:t...@atomide.com]
Sent: 03 February, 2010 19:50
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
* Tero Kristo tero.kri...@nokia.com [100202 01:38]:
From: Tero Kristo tero.kri...@nokia.com
Only RX interrupt will now kick the sleep prevent timer. In
addition, TX
fifo status is checked before disabling clocks, this will
prevent occasional
garbage being printed on serial line. Smartidle is also
disabled while
entering idle if we have data in the transmit buffer,
because having this
enabled will prevent wakeups from the TX interrupt, and
this causes
pauses while sending large blocks of data.
Sounds this is for 2.6.34 merge window and does not contain anything
that needs to be fixed for 2.6.33.
Yeah, this only fixes a couple of annoying issues, but
nothing fatal. Also improves power efficiency in some cases
which is a nice to have feature, and basically eases the
development of PM code as the UART does not block the system
from sleeping always.
Yeah cool. Separate issue, but I wonder if we should also clear
the the first rx character from the fifo to avoid corrupting
the console. Only when the uart clocks are off and and
we get a key press. Would be easy to do just do with one
serial_read_reg(uart-p, UART_RX)..
Yeah, I can try to add this change to the code and see what happens.
Tony
-Tero
Regards,
Tony
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/serial.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 777e802..e11dfe9 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -317,7 +317,8 @@ static void omap_uart_allow_sleep(struct
omap_uart_state *uart)
if (!uart-clocked)
return;
- omap_uart_smart_idle_enable(uart, 1);
+ if (serial_read_reg(uart-p, UART_LSR) UART_LSR_TEMT)
+ omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
del_timer(uart-timer);
}
@@ -335,7 +336,11 @@ void omap_uart_prepare_idle(int num)
list_for_each_entry(uart, uart_list, node) {
if (num == uart-num uart-can_sleep) {
- omap_uart_disable_clocks(uart);
+ if (serial_read_reg(uart-p, UART_LSR)
+ UART_LSR_TEMT)
+ omap_uart_disable_clocks(uart);
+ else
+ omap_uart_smart_idle_enable(uart, 0);
return;
}
}
@@ -407,8 +412,14 @@ int omap_uart_can_sleep(void)
static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
{
struct omap_uart_state *uart = dev_id;
+ u8 lsr;
- omap_uart_block_sleep(uart);
+ lsr = serial_read_reg(uart-p, UART_LSR);
+ /* Check for receive interrupt */
+ if (lsr UART_LSR_DR)
+ omap_uart_block_sleep(uart);
+ if (lsr UART_LSR_TEMT uart-can_sleep)
+ omap_uart_smart_idle_enable(uart, 1);
return IRQ_NONE;
}
--
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: [PATCH] OMAP3: Serial: Improved sleep logic
-Original Message-
From: ext Tony Lindgren [mailto:t...@atomide.com]
Sent: 03 February, 2010 19:50
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
* Tero Kristo tero.kri...@nokia.com [100202 01:38]:
From: Tero Kristo tero.kri...@nokia.com
Only RX interrupt will now kick the sleep prevent timer. In
addition, TX
fifo status is checked before disabling clocks, this will
prevent occasional
garbage being printed on serial line. Smartidle is also
disabled while
entering idle if we have data in the transmit buffer,
because having this
enabled will prevent wakeups from the TX interrupt, and this causes
pauses while sending large blocks of data.
Sounds this is for 2.6.34 merge window and does not contain anything
that needs to be fixed for 2.6.33.
Yeah, this only fixes a couple of annoying issues, but nothing fatal. Also
improves power efficiency in some cases which is a nice to have feature, and
basically eases the development of PM code as the UART does not block the
system from sleeping always.
-Tero
Regards,
Tony
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/serial.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 777e802..e11dfe9 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -317,7 +317,8 @@ static void omap_uart_allow_sleep(struct
omap_uart_state *uart)
if (!uart-clocked)
return;
-omap_uart_smart_idle_enable(uart, 1);
+if (serial_read_reg(uart-p, UART_LSR) UART_LSR_TEMT)
+omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
del_timer(uart-timer);
}
@@ -335,7 +336,11 @@ void omap_uart_prepare_idle(int num)
list_for_each_entry(uart, uart_list, node) {
if (num == uart-num uart-can_sleep) {
-omap_uart_disable_clocks(uart);
+if (serial_read_reg(uart-p, UART_LSR)
+UART_LSR_TEMT)
+omap_uart_disable_clocks(uart);
+else
+omap_uart_smart_idle_enable(uart, 0);
return;
}
}
@@ -407,8 +412,14 @@ int omap_uart_can_sleep(void)
static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
{
struct omap_uart_state *uart = dev_id;
+u8 lsr;
-omap_uart_block_sleep(uart);
+lsr = serial_read_reg(uart-p, UART_LSR);
+/* Check for receive interrupt */
+if (lsr UART_LSR_DR)
+omap_uart_block_sleep(uart);
+if (lsr UART_LSR_TEMT uart-can_sleep)
+omap_uart_smart_idle_enable(uart, 1);
return IRQ_NONE;
}
--
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: [PATCHv4 1/8] OMAP3: Clockdomain: Added API for checking if HWSUP is enabled
-Original Message-
From: ext Paul Walmsley [mailto:p...@pwsan.com]
Sent: 02 February, 2010 00:11
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 1/8] OMAP3: Clockdomain: Added API for
checking if HWSUP is enabled
Hi Tero,
On Fri, 22 Jan 2010, Tero Kristo wrote:
From: Tero Kristo tero.kri...@nokia.com
omap2_clkdm_get_hwsup(clkdm) can be used to check if automatic HW
transitions for the domain are enabled or not. This is needed for the
powerdomain code that adds support for INACTIVE state, as it needs to
disable HWSUP on the fly for ON state, and re-enable it
after returning
to some other state.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
An updated patch with some revisions is below. Please let me know if
there's something that still should be changed. The revisions are:
Your changes look okay to me.
1. Split the if-statement expressions up into separate lines per
CodingStyle
2. Rename omap2_clkdm_get_hwsup() to omap2_clkdm_read_hwsup()
to follow
the general practice in this file and powerdomain.c that
functions with
'_get_' in the name read configuration data, and functions
with '_read_'
read from the hardware (or a cache of the hardware register)
3. Add OMAP4 support
4. Added the extra asterisk in the comment body to indicate
kerneldoc-format comment
5. Updated patch to apply after the current round of 2.6.34 changes
regards,
- Paul
From fc2f8ad184e012a5574e1110c359354d247a1709 Mon Sep 17 00:00:00 2001
From: Tero Kristo tero.kri...@nokia.com
Date: Mon, 1 Feb 2010 13:41:26 -0700
Subject: [PATCH] OMAP3: Clockdomain: Added API for checking if
HWSUP is enabled
omap2_clkdm_read_hwsup(clkdm) can be used to check if automatic HW
transitions for the domain are enabled or not. This is needed for the
powerdomain code that adds support for INACTIVE state, as it needs to
disable HWSUP on the fly for ON state, and re-enable it after returning
to some other state.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
[p...@pwsan.com: added kerneldoc comment magic start; changed function
name to omap2_clkdm_read_hwsup(); broke up expressions in function
body; added OMAP4 support]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.c | 30
+
arch/arm/plat-omap/include/plat/clockdomain.h |1 +
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index a38a615..8dce3c9 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -868,6 +868,36 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
}
/**
+ * omap2_clkdm_read_hwsup - read the hwsup idle transition bit
+ * @clkdm: struct clockdomain *
+ *
+ * Checks whether hardware is allowed to switch the clockdomain @clkdm
+ * automatically into active or idle states. Returns -EINVAL if @clkdm
+ * is NULL; otherwise, 1 if hardware auto-idle is enabled, 0 if not.
+ */
+int omap2_clkdm_read_hwsup(struct clockdomain *clkdm)
+{
+ u32 u, v;
+
+ if (!clkdm)
+ return -EINVAL;
+
+ u = cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs, CM_CLKSTCTRL);
+ u = clkdm-clktrctrl_mask;
+
+ if (cpu_is_omap24xx())
+ v = OMAP24XX_CLKSTCTRL_ENABLE_AUTO;
+ else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+ v = OMAP34XX_CLKSTCTRL_ENABLE_AUTO;
+ else
+ BUG();
+
+ v = __ffs(clkdm-clktrctrl_mask);
+
+ return (u == v) ? 1 : 0;
+}
+
+/**
* omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
* @clkdm: struct clockdomain *
*
diff --git a/arch/arm/plat-omap/include/plat/clockdomain.h
b/arch/arm/plat-omap/include/plat/clockdomain.h
index ba0a6c0..9d25f4e 100644
--- a/arch/arm/plat-omap/include/plat/clockdomain.h
+++ b/arch/arm/plat-omap/include/plat/clockdomain.h
@@ -129,6 +129,7 @@ int clkdm_del_sleepdep(struct clockdomain
*clkdm1, struct clockdomain *clkdm2);
int clkdm_read_sleepdep(struct clockdomain *clkdm1, struct
clockdomain *clkdm2);
int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm);
+int omap2_clkdm_read_hwsup(struct clockdomain *clkdm);
void omap2_clkdm_allow_idle(struct clockdomain *clkdm);
void omap2_clkdm_deny_idle(struct clockdomain *clkdm);
--
1.6.6.rc2.5.g49666
--
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 2/8] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level
-Original Message- From: ext Paul Walmsley [mailto:p...@pwsan.com] Sent: 02 February, 2010 10:04 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv4 2/8] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level Hello Tero, On Fri, 22 Jan 2010, Tero Kristo wrote: Currently only ON, RET and OFF are supported, and ON is arguably broken as it allows the powerdomain to enter INACTIVE state unless idle is prevented. Now, pwrdm code prevents idle if ON is selected and hardware supervised mode for the underlying clockdomain is enabled, and also adds support for INACTIVE. This simplifies the control needed inside sleep code. This patch also requires caching of next power state inside powerdomain code, as INACTIVE is not directly supported by hardware. Next powerstate is thus now stored for each powerdomain in next_state. Still thinking about this patch. Am not sure it makes sense, or at least, it is incomplete. Consider: Reasoning for this patch at least for OMAP3 is as follows: - sleep code needs to know the states for mpu and core better than it does now, there is currently at least one bug in the sleep path which effectively prevents core INACTIVE completely (uart clocks are only turned off if core is going to RET or OFF) - support for ON/INACTIVE allows better testing facilities for different power states (e.g. suspend) - adding support for ON/INACTIVE to powerdomain code simplifies the interface between cpuidle34xx / pm34xx - adding support for other powerdomains than mpu/core is a nice to have feature and we can most likely live without it Alternative is to duplicate this code to several locations (pm34xx.c, cpuidle34xx.c.), or just put this code into separate file, and use it from the locations where it is needed. 1. In the current code, pwrdm-next_state can never be initialized to INACTIVE during pwrdm_register(), but this should be possible. To do this, the code needs to iterate through the powerdomain's clockdomains and determine whether they are in hardware-supervised idle or software-supervised idle. Well, there is a chicken-egg problem here. It is not possible to check the clockdomains at this state as clockdomains do not exist yet. It would be possible to split this out from powerdomain code, maybe into powerdomain34xx.c as you suggested and do the init later. 2. What should happen to pwrdm-next_state if someone calls omap2_clkdm_allow_idle(), omap2_clkdm_deny_idle(), omap2_clkdm_sleep(), or omap2_clkdm_wakeup()? Right now, nothing will happen, which is a problem since calling one of these functions could mean that the powerdomain's possible next state may change from ON to INACTIVE or vice-versa. A similar problem appears to exist with hwsup_changed: other code may have changed the clockdomain autoidle state, which may cause hwsup_changed to not reflect reality any longer. True... We should probably do something for these. However, at least currently this implementation does not cause any problems as clkdm_allow_idle, deny_idle, sleep and wakeup are not used anywhere. ... I am still not sure that the idea of setting the powerdomain's next power state to INACTIVE makes sense. The TRM claims that a powerdomain can be inactive, but this seems to be just poor documentation. To say that a powerdomain can be inactive is really just to say that the powerdomain is 'ON' -- powered -- but all of its subsidiary clockdomain activity states are INACTIVE. Between ON and INACTIVE, the power state of the powerdomain is the same from the hardware's point of view -- but the differences between the OFF, RET, and ON power states are distinct. And from the PRCM point of view, the only place that an INACTIVE power domain state shows up is in the powerdomain current power state register. This is also visible in the previous state register, and well, denying/allowing clockdomain to idle only makes sense for the ON state in general, as this is the only case where we actually care if we have allowed idle or not. It is also good to know if a clockdomain has actually entered idle or not, if we do not have INACTIVE state for powerdomain, we do not know this from anywhere. Perhaps a separate code layer that incorporates your ideas is worthwhile for use by pm*.c and cpuidle*.c, in order to simplify that code. But in the current powerdomain and clockdomain code, when we depart from what the hardware is capable of, the code needs to cover all of the software corner cases that can affect state transitions. Otherwise we probably should stick with the simplicity of following the hardware's registers and capabilities. Yeah, I think I try to put my powerdomain hacks into separate file. The patch might also break stuff for OMAP2 or OMAP4, which I think we want to avoid. Someone can then fix OMAP4 support if deemed necessary. Let's discuss further if you are interested.
RE: OMAP3: PM: Disable OTG autoidle when waking up from off-mode
-Original Message-
From: ext Gupta, Ajay Kumar [mailto:ajay.gu...@ti.com]
Sent: 21 January, 2010 12:31
To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
Cc: Kevin Hilman
Subject: RE: OMAP3: PM: Disable OTG autoidle when waking up
from off-mode
Hi Kristo,
There are some issues with this patch in PM branch.
Please find my comments inline.
Regards,
Ajay
OMAP3: PM: Disable OTG autoidle when waking up from off-mode
OMAP3 sleep can be prevented in some cases where OTG autoidle is
enabled.
This patch force disables autoidle during wakeup from
off-mode. See
omap
errata 1.164.
This fix can't be done in driver level, as off-mode
entry resets and
enables
the autoidle bit, and driver does not access the
register after each
off-mode
entry even if it is loaded.
Tero Kristo tero.kristo nokia.com
Kevin Hilman khilman deeprootsystems.com
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 81ed252..ddd19cd 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -37,6 +37,7 @@
#include plat/gpmc.h
#include plat/dma.h
#include plat/dmtimer.h
+#include plat/usb.h
#include asm/tlbflush.h
@@ -430,6 +431,11 @@ void omap_sram_idle(void)
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+/*
+ * Errata 1.164 fix : OTG autoidle can prevent
+ * sleep
+ */
+usb_musb_disable_autoidle();
Do we really need it? We are anyway disabling autoidle in
Drivers/usb/musb/omap2430.c file.
This is not enough, as off-mode entry will reset this register. And, we are not
calling MUSB resume functions after every wakeup from off.
clk_disable(otg_clk);
-clk_put(otg_clk);
-}
+}
snip..
-iounmap(otg_base);
+void usb_musb_disable_autoidle(void)
+{
+__raw_writel(0, otg_base + OTG_SYSCONFIG);
We should first read the register and the reset the first bit D0
for disabling autoidle.
We know that always when we are calling this function, we are waking up from
off-mode and MUSB module has been reset also. Thus, no need to read it, as we
know what the reset value is.
Also, musb clock needs to be enabled during this function call.
When I tool musb save/restore patch (accepted and in queue),
I found a system hand during resume.
It is possible that MUSB clock is disabled here if you are fiddling with the
clocks on the MUSB module side. In that case this patch should probably be
modified.
-Tero--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
-Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 20 January, 2010 02:48 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv3 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle tero.kri...@nokia.com writes: -Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 18 January, 2010 20:41 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHv3 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com pwrdm_can_idle(pwrdm) will check if the specified powerdomain can enter idle. This is done by checking all clockdomains under the powerdomain if they can idle also. omap2_clkdm_can_idle(clkdm) will check if the specified clockdomain can enter idle. This checks the functional clocks and idle status bits of the domain according to following rules: 1) get inverse of idlest and mask against idle_def.mask * this gives a bitmask with non-idle bits high 2) bitwise OR active functional clocks from the domain to the result * in some cases FCLK can be active but idlest still shows module in idle 3) disable bits defined in idle_def.mask disable? it looks like they're just being ignored. Oh yes, just a small typo here in patch description. This should indeed say that they are ignored, as the bit-field also is named as ignore. * some bits should be ignored, like UART clocks which are dynamically switched inside sleep loop These calls can be used e.g. inside cpuidle to decide which power states core and mpu should enter during idle, as there are certain dependencies between wakeup capabilities and reset logic. Signed-off-by: Tero Kristo tero.kri...@nokia.com Thanks for adding the IDLEST checks, I think that will help. Yes, and this is actually required for the secure side clock status handling, this information is not available anywhere else, thus it is impossible to get the idle status from the clock framework usecounts. In the .mask field, instead of using a hard-coded mask, probably using the existing bitfields headers would be a bit more readable, and help ensure correctness. Well, the bitfield definitions for those do not exist at the moment. We could use the EN bit definitions for the CM_FCLKEN* since they're the same for IDLEST. Some bits do not exist as EN bit definitions, but they do exist as ST. E.g secure clocks do not have EN bit, and some CORE domain EN bits are not definied either as they do not exist. I will update the masks in the code according to this, and just use ST bits. The idea of the mask is just to get all bits in that are needed, e.g. PER domain does not have GPIO bits in the mask, as these appear to always be in a state that they are accessible (i.e. IDLEST shows accessible for them.) And I think if we used the #defines here, it would be much clearer what bits are included and which are left out. Some comments as to which ones are needed or not would be helpful too. Ok, I'll inline the comments with the masks. I can write all IDLEST bits into the masks (as was done before) if you like this approach better. This will generate rather long definitions though, and the probability of errors in those is actually higher than in this version (I just write a number of low bits to one.) I guess you didn't see the rest of my comments further down in the original review. There was at least one error already in the SGX since it's bit is not bit 0 but but 1. Using the existing #defines would've solved that. True, I will update the masks according to this. On that note, please check out the other inline comments in the original review. I should've mentioned that there were further comments inline in the original review. Sorry for the confusion. Yeah, sorry missed those, will comment now. Kevin Hopefully there's a way to auto-generate these for OMAP4. --- arch/arm/mach-omap2/clockdomain.c | 27 arch/arm/mach-omap2/clockdomains.h| 54 + arch/arm/mach-omap2/powerdomain.c | 25 +++ arch/arm/plat-omap/include/plat/clockdomain.h | 17 arch/arm/plat-omap/include/plat/powerdomain.h |1 + 5 files changed, 124 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c index dd285f0..f42111a 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -472,6 +472,33 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm) return 0; } + +/** + * omap2_clkdm_can_idle - check if clockdomain has any active clocks or not + * @clkdm: struct clockdomain * + * + * Checks if the clockdomain has any active clock or not, i.e. whether it + * can enter idle. Returns -EINVAL if clkdm
RE: [PATCHv3 1/6] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level
Hi Paul,
Thanks for comments, my responses inline below.
-Original Message-
From: ext Paul Walmsley [mailto:p...@pwsan.com]
Sent: 21 January, 2010 06:35
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com
Subject: Re: [PATCHv3 1/6] OMAP: Powerdomains: Add support for
INACTIVE state on pwrdm level
Hi Tero,
I regret the delay in reviewing. I haven't kept up on the comments on
this thread, so if I've asked a question that you've already answered,
please feel free to point me to the response.
A few comments/questions:
On Fri, 15 Jan 2010, Tero Kristo wrote:
From: Tero Kristo tero.kri...@nokia.com
Currently only ON, RET and OFF are supported, and ON is
arguably broken as it
allows the powerdomain to enter INACTIVE state unless idle
is prevented.
Now, pwrdm code prevents idle if ON is selected, and also
adds support for
INACTIVE. This simplifies the control needed inside sleep code.
This patch also requires caching of next power state inside
powerdomain code,
as INACTIVE is not directly supported by hardware.
The idea seems like a good one, and a simplification for the
PM code. I'm
a little worried that this patch mixes hardware-programmable
powerdomain
states with logical powerdomain states. I wonder if we would
be better
off separating, for example, the logic of putting a powerdomain into
INACTIVE state and any other logical powerdomain management, from the
physical details of how the chip is programmed. Just looking for your
comments on this, not necessarily any changes in your patches in this
regard.
Next powerstate is thus now stored for each powerdomain in
next_state.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/powerdomain.c | 32
arch/arm/mach-omap2/powerdomains34xx.h| 26
++--
arch/arm/plat-omap/include/plat/powerdomain.h |4 +++
3 files changed, 43 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 26b3f3e..a08d596 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -110,8 +110,8 @@ static struct powerdomain
*_pwrdm_deps_lookup(struct powerdomain *pwrdm,
static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
{
-int prev;
-int state;
+u8 prev;
+u8 state;
if (pwrdm == NULL)
return -EINVAL;
@@ -218,7 +218,9 @@ int pwrdm_register(struct powerdomain *pwrdm)
pr_debug(powerdomain: registered %s\n, pwrdm-name);
ret = 0;
-
+pwrdm-next_state =
+prm_read_mod_bits_shift(pwrdm-prcm_offs, PM_PWSTCTRL,
+OMAP_POWERSTATE_MASK);
pr_unlock:
write_unlock_irqrestore(pwrdm_rwlock, flags);
@@ -699,19 +701,38 @@ int pwrdm_get_mem_bank_count(struct
powerdomain *pwrdm)
*/
int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
{
+u8 prg_pwrst;
+
if (!pwrdm)
return -EINVAL;
+if (pwrdm-next_state == pwrst)
+return 0;
+
if (!(pwrdm-pwrsts (1 pwrst)))
return -EINVAL;
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
pwrdm-name, pwrst);
+/* INACTIVE is reserved, so we program pwrdm as ON */
+if (pwrst == PWRDM_POWER_INACTIVE)
+prg_pwrst = PWRDM_POWER_ON;
+else
+prg_pwrst = pwrst;
+
prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
- (pwrst OMAP_POWERSTATE_SHIFT),
+ (prg_pwrst OMAP_POWERSTATE_SHIFT),
pwrdm-prcm_offs, PM_PWSTCTRL);
+/* If next state is ON, prevent idle */
+if (pwrst == PWRDM_POWER_ON)
+omap2_clkdm_deny_idle(pwrdm-pwrdm_clkdms[0]);
+else
+omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
Looks like this will force clockdomains into hardware-supervised mode,
even if they were originally programmed into software-supervised mode.
Please fix this so clockdomains that were originally programmed into
software-supervised mode aren't inadvertently switched.
I think the change here would be to only deny/allow idle if we are in hwsup
mode. Probably needs caching of the setup also. I'll do the change for this.
+
+pwrdm-next_state = pwrst;
+
return 0;
}
@@ -728,8 +749,7 @@ int pwrdm_read_next_pwrst(struct
powerdomain *pwrdm)
if (!pwrdm)
return -EINVAL;
-return prm_read_mod_bits_shift(pwrdm-prcm_offs, PM_PWSTCTRL,
-OMAP_POWERSTATE_MASK);
+return pwrdm-next_state;
}
/**
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index 588f7e0..f50a3f2 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -165,7 +165,7 @@
RE: [PATCHv3 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 18 January, 2010 20:41
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv3 5/6] OMAP: Powerdomains: Add support for
checking if pwrdm/clkdm can idle
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
pwrdm_can_idle(pwrdm) will check if the specified
powerdomain can enter
idle. This is done by checking all clockdomains under the powerdomain
if they can idle also.
omap2_clkdm_can_idle(clkdm) will check if the specified
clockdomain can
enter idle. This checks the functional clocks and idle
status bits of the
domain according to following rules:
1) get inverse of idlest and mask against idle_def.mask
* this gives a bitmask with non-idle bits high
2) bitwise OR active functional clocks from the domain to the result
* in some cases FCLK can be active but idlest still shows
module in idle
3) disable bits defined in idle_def.mask
disable? it looks like they're just being ignored.
Oh yes, just a small typo here in patch description. This should indeed say
that they are ignored, as the bit-field also is named as ignore.
* some bits should be ignored, like UART clocks which are
dynamically
switched inside sleep loop
These calls can be used e.g. inside cpuidle to decide which
power states
core and mpu should enter during idle, as there are certain
dependencies
between wakeup capabilities and reset logic.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Thanks for adding the IDLEST checks, I think that will help.
Yes, and this is actually required for the secure side clock status handling,
this information is not available anywhere else, thus it is impossible to get
the idle status from the clock framework usecounts.
In the .mask field, instead of using a hard-coded mask, probably using
the existing bitfields headers would be a bit more readable, and help
ensure correctness.
Well, the bitfield definitions for those do not exist at the moment. The idea
of the mask is just to get all bits in that are needed, e.g. PER domain does
not have GPIO bits in the mask, as these appear to always be in a state that
they are accessible (i.e. IDLEST shows accessible for them.)
I can write all IDLEST bits into the masks (as was done before) if you like
this approach better. This will generate rather long definitions though, and
the probability of errors in those is actually higher than in this version (I
just write a number of low bits to one.)
Hopefully there's a way to auto-generate these for OMAP4.
---
arch/arm/mach-omap2/clockdomain.c | 27
arch/arm/mach-omap2/clockdomains.h| 54
+
arch/arm/mach-omap2/powerdomain.c | 25 +++
arch/arm/plat-omap/include/plat/clockdomain.h | 17
arch/arm/plat-omap/include/plat/powerdomain.h |1 +
5 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index dd285f0..f42111a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -472,6 +472,33 @@ int omap2_clkdm_wakeup(struct
clockdomain *clkdm)
return 0;
}
+
+/**
+ * omap2_clkdm_can_idle - check if clockdomain has any
active clocks or not
+ * @clkdm: struct clockdomain *
+ *
+ * Checks if the clockdomain has any active clock or not,
i.e. whether it
+ * can enter idle. Returns -EINVAL if clkdm is NULL; 0 if
unable to idle;
+ * 1 if can idle.
+ */
+int omap2_clkdm_can_idle(struct clockdomain *clkdm)
+{
+int i;
+
+if (!clkdm)
+return -EINVAL;
+
+for (i = 0; i clkdm-clk_reg_amt; i++)
+if (((~cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
+CM_IDLEST + 4 * i)
+clkdm-idle_def[i].mask) |
+
cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
+CM_FCLKEN + 4 * i))
+~clkdm-idle_def[i].ignore)
This has some readability/indent issues.
Also, could check fclk first, if active fclks, no reason to check
idlest. How about something like this (untested, but I *think* I kept
the same logic):
for (i = 0; i clkdm-clk_reg_amt; i++) {
u32 idlest, fclk;
fclk = cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
CM_FCLKEN + 4 * i);
if (fclk ~clkdm-idle_def[i].ignore)
return 0;
idlest = cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
CM_IDLEST + 4 * i);
if (~idlest clkdm-idle_def[i].mask)
return 0;
}
+return 0;
+return 1;
+}
+
/**
* omap2_clkdm_allow_idle - enable hwsup idle transitions
RE: [PATCHv2 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
Sent: 12 January, 2010 20:57
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv2 5/6] OMAP: Powerdomains: Add support for
checking if pwrdm/clkdm can idle
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
pwrdm_can_idle(pwrdm) will check if the specified
powerdomain can enter
idle. This is done by checking all clockdomains under the powerdomain
if they can idle also.
omap2_clkdm_can_idle(clkdm) will check if the specified
clockdomain can
enter idle. This checks the functional clock status in the
clockdomain.
These calls can be used e.g. inside cpuidle to decide which
power states
core and mpu should enter during idle, as there are certain
dependencies
between wakeup capabilities and reset logic.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
This looks good by me, but needs a review from Paul to go upstream with
the rest of his clockdomain/powerdomain updates for 2.6.34.
One question... I'm wondering if it might be good to also check the
CM_IDLEST_pwrdm register in the can_idle function. Even if all
clocks are disabled, if the idle modes of the module are not
set correctly,
it may not enter the target state.
Hmm I guess you are right here. I think at least one case would be secure
devices which do not have FCLK control on the non-secure kernel, but their
IDLEST would indeed block state transition. I'll investigate this a bit and
update the patch.
Kevin
---
arch/arm/mach-omap2/clockdomain.c | 24
arch/arm/mach-omap2/clockdomains.h| 14 ++
arch/arm/mach-omap2/powerdomain.c | 25
+
arch/arm/plat-omap/include/plat/clockdomain.h | 12
arch/arm/plat-omap/include/plat/powerdomain.h |1 +
5 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index fcd8232..9ddeb96 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -474,6 +474,30 @@ int omap2_clkdm_wakeup(struct
clockdomain *clkdm)
return 0;
}
+
+/**
+ * omap2_clkdm_can_idle - check if clockdomain has any
active clocks or not
+ * @clkdm: struct clockdomain *
+ *
+ * Checks if the clockdomain has any active clock or not,
i.e. whether it
+ * can enter idle. Returns -EINVAL if clkdm is NULL; 0 if
unable to idle;
+ * 1 if can idle.
+ */
+int omap2_clkdm_can_idle(struct clockdomain *clkdm)
+{
+int i;
+const int fclk_regs[] = { CM_FCLKEN, OMAP3430ES2_CM_FCLKEN3 };
+
+if (!clkdm)
+return -EINVAL;
+
+for (i = 0; i clkdm-fclk_reg_amt; i++)
+if (cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
+fclk_regs[i])
~clkdm-fclk_masks[i])
+return 0;
+return 1;
+}
+
/**
* omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
* @clkdm: struct clockdomain *
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index c4ee076..2cde82a 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -167,6 +167,7 @@ static struct clockdomain iva2_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_IVA2_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+.fclk_reg_amt = 1,
};
static struct clockdomain gfx_3430es1_clkdm = {
@@ -183,6 +184,7 @@ static struct clockdomain sgx_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_SGX_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
+.fclk_reg_amt = 1,
};
/*
@@ -206,6 +208,11 @@ static struct clockdomain core_l3_34xx_clkdm = {
.flags = CLKDM_CAN_HWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_L3_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+.fclk_reg_amt = 2,
+.fclk_masks = {
+[0] = OMAP3430_EN_UART2 | OMAP3430_EN_UART1,
+[1] = 0,
+},
};
static struct clockdomain core_l4_34xx_clkdm = {
@@ -222,6 +229,7 @@ static struct clockdomain dss_34xx_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_DSS_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+.fclk_reg_amt = 1,
};
static struct clockdomain cam_clkdm = {
@@ -230,6 +238,7 @@ static struct clockdomain cam_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_CAM_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+.fclk_reg_amt = 1,
};
static struct clockdomain usbhost_clkdm = {
@@ -238,6 +247,7 @@
RE: [PATCHv2 1/6] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 12 January, 2010 20:25
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv2 1/6] OMAP: Powerdomains: Add support for
INACTIVE state on pwrdm level
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Currently only ON, RET and OFF are supported, and ON is
arguably broken as it
allows the powerdomain to enter INACTIVE state unless idle
is prevented.
Now, pwrdm code prevents idle if ON is selected, and also
adds support for
INACTIVE. This simplifies the control needed inside sleep code.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Hi Tero,
apologies for the long delay in reviewing this updated series.
No problem, I have actually been on a holiday myself so I did not really miss
review comments that much. Thanks for taking the time to look at this.
I really like this idea as it indeed simplifies the control code
inside the idle path. This also needs a review by Paul and should
merge via his powerdomain updates for 2.6.34.
The changelog should also describe that the powerdomain struct
now caches the next_state.
Yeah, I can add this comment.
One minor comment. I think the introduction of signed compares in
certain cases leads to possible confusion and readability problems.
I'm not sure I realy follow the need for the invalid state. Instead
of setting next_state to -1 in pwrdm_register, why not read the
current HW value and use that as the starting value?
I guess this invalid stuff comes from my old lazy initialization habits. :) But
yes, I can change this into a format where we just read the current value from
the register.
If the invalid state is really needed, instead of using -1 and having
to change to using signed comparisons in certain cases, it seems like
we could just define a new invalid state as zero, and move the others
up a notch.
This is probably not good, as it would break the direct SW to HW value mapping,
so I will go with the previous one.
Then, use something like this to check for a valid state:
static inline bool pwrdm_is_valid_state(struct powerdomain *pwrdm) {
return (pwrdm-state PWRDM_POWER_INVALID) ? true : false;
}
Kevin
---
arch/arm/mach-omap2/powerdomain.c | 32
+
arch/arm/mach-omap2/powerdomains34xx.h| 26
++--
arch/arm/plat-omap/include/plat/powerdomain.h |6 -
3 files changed, 45 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index b6990e3..1237717 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -112,8 +112,8 @@ static struct powerdomain
*_pwrdm_deps_lookup(struct powerdomain *pwrdm,
static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
{
-int prev;
-int state;
+u8 prev;
+u8 state;
if (pwrdm == NULL)
return -EINVAL;
@@ -220,7 +220,7 @@ int pwrdm_register(struct powerdomain *pwrdm)
pr_debug(powerdomain: registered %s\n, pwrdm-name);
ret = 0;
-
+pwrdm-next_state = -1;
pr_unlock:
write_unlock_irqrestore(pwrdm_rwlock, flags);
@@ -701,19 +701,38 @@ int pwrdm_get_mem_bank_count(struct
powerdomain *pwrdm)
*/
int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
{
+u8 prg_pwrst;
+
if (!pwrdm)
return -EINVAL;
+if (pwrdm-next_state == pwrst)
+return 0;
+
if (!(pwrdm-pwrsts (1 pwrst)))
return -EINVAL;
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
pwrdm-name, pwrst);
+/* INACTIVE is reserved, so we program pwrdm as ON */
+if (pwrst == PWRDM_POWER_INACTIVE)
+prg_pwrst = PWRDM_POWER_ON;
+else
+prg_pwrst = pwrst;
+
prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
- (pwrst OMAP_POWERSTATE_SHIFT),
+ (prg_pwrst OMAP_POWERSTATE_SHIFT),
pwrdm-prcm_offs, PM_PWSTCTRL);
+/* If next state is ON, prevent idle */
+if (pwrst == PWRDM_POWER_ON)
+omap2_clkdm_deny_idle(pwrdm-pwrdm_clkdms[0]);
+else
+omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+
+pwrdm-next_state = pwrst;
+
return 0;
}
@@ -730,8 +749,11 @@ int pwrdm_read_next_pwrst(struct
powerdomain *pwrdm)
if (!pwrdm)
return -EINVAL;
+if (pwrdm-next_state -1)
+return pwrdm-next_state;
+
return prm_read_mod_bits_shift(pwrdm-prcm_offs, PM_PWSTCTRL,
-OMAP_POWERSTATE_MASK);
+ OMAP_POWERSTATE_MASK);
}
/**
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index fd09b08..9eb2dc5 100644
---
RE: [PATCH 07/10 V3] omap3: clk: use pm accessor functions for cpufreq table
Hi,
One comment below.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
Nishanth Menon
Sent: 25 November, 2009 06:09
To: linux-omap
Cc: Nishanth Menon; Benoit Cousson; Kevin Hilman; Madhusudhan
Chikkature Rajashekar; Paul Walmsley; Romit Dasgupta; Sanjeev
Premi; Santosh Shilimkar; Sergio Alberto Aguirre Rodriguez;
Thara Gopinath; Vishwanath Sripathy
Subject: [PATCH 07/10 V3] omap3: clk: use pm accessor
functions for cpufreq table
omap2_clk_init_cpufreq_table currently directly accesses the opp
table, making it unscalable to various OMAPs. Instead use the
accessor functions to populate the cpufreq table
Cc: Benoit Cousson b-cous...@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: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 32
+++-
1 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c
b/arch/arm/mach-omap2/clock34xx.c
index 5150939..d07f1c1 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -1042,30 +1042,36 @@ static unsigned long
omap3_clkoutx2_recalc(struct clk *clk)
#if defined(CONFIG_ARCH_OMAP3)
#ifdef CONFIG_CPU_FREQ
-static struct cpufreq_frequency_table freq_table[MAX_VDD1_OPP+1];
+
+static struct cpufreq_frequency_table *freq_table;
void omap2_clk_init_cpufreq_table(struct
cpufreq_frequency_table **table)
{
- struct omap_opp *prcm;
int i = 0;
+ u8 opp_num;
+ struct omap_opp *opp = NULL;
+ unsigned long freq = ULONG_MAX;
- if (!mpu_opps)
+ if (!mpu_opps || opp_get_opp_count(opp_num, mpu_opps)) {
+ pr_warning(%s: failed to initialize frequency
+ table\n, __func__);
return;
-
- prcm = mpu_opps + MAX_VDD1_OPP;
- for (; prcm-rate; prcm--) {
- freq_table[i].index = i;
- freq_table[i].frequency = prcm-rate / 1000;
- i++;
}
- if (i == 0) {
- printk(KERN_WARNING %s: failed to initialize
frequency \
-
table\n,
-
__func__);
+ freq_table = kmalloc(sizeof(struct cpufreq_frequency_table) *
+ (opp_num + 1), GFP_KERNEL);
I guess this should be GFP_ATOMIC, we have clockfw spinlock reserved when this
is called (gave me a runtime warning.)
+ if (!freq_table) {
+ pr_warning(%s: failed to allocate frequency
+ table\n, __func__);
return;
}
+ while (!opp_get_lower_opp(opp, freq, mpu_opps)) {
+ freq_table[i].index = i;
+ freq_table[i].frequency = freq / 1000;
+ i++;
+ }
+
freq_table[i].index = i;
freq_table[i].frequency = CPUFREQ_TABLE_END;
--
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
--
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 04/10 V3] omap3: pm: srf: use opp accessor functions
Hi, Couple of comments below. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Nishanth Menon Sent: 25 November, 2009 06:09 To: linux-omap Cc: Nishanth Menon; Benoit Cousson; Kevin Hilman; Madhusudhan Chikkature Rajashekar; Paul Walmsley; Romit Dasgupta; Sanjeev Premi; Santosh Shilimkar; Sergio Alberto Aguirre Rodriguez; Thara Gopinath; Vishwanath Sripathy Subject: [PATCH 04/10 V3] omap3: pm: srf: use opp accessor functions With the accessor functions, many of the direct accesses are redundant. However we do not want to rewrite SRF at this point of time We do the following here: Remove get_opp and introduce three SRF specific accessor functions: opp_to_freq, freq_to_opp - need this coz of usage of opp IDs NOTE: These functions should be removed at a later point of time. get_opp is removed because, with the above functions, it is redundant. NOTE: this implementation is just a start and leaves scope for further cleanups which can be added on top. NOTE: this increases the number of warnings to: arch/arm/mach-omap2/resource34xx.c: In function 'opp_to_freq': arch/arm/mach-omap2/resource34xx.c:182: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'freq_to_opp': arch/arm/mach-omap2/resource34xx.c:213: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'init_opp': arch/arm/mach-omap2/resource34xx.c:242: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:249: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp_freq': arch/arm/mach-omap2/resource34xx.c:302: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:303: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:308: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp': arch/arm/mach-omap2/resource34xx.c:351: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:352: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:356: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:380: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'resource_set_opp_level': arch/arm/mach-omap2/resource34xx.c:417: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:418: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:420: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'set_opp': arch/arm/mach-omap2/resource34xx.c:497: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'validate_opp': arch/arm/mach-omap2/resource34xx.c:516: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:518: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'init_freq': arch/arm/mach-omap2/resource34xx.c:541: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:544: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'set_freq': arch/arm/mach-omap2/resource34xx.c:560: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:565: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'validate_freq': arch/arm/mach-omap2/resource34xx.c:579: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:581: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) Cc: Benoit Cousson b-cous...@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:
RE: [PATCH 03/10 V3] omap3: pm: use opp accessor functions for omap34xx
One additional comment to this patch, compilation of board-rx51.c fails unless
#include pm.h is added to it. This might be true for other boards also seeing
it has been added to zoom2 at least.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
Sent: 25 November, 2009 19:22
To: Nishanth Menon
Cc: linux-omap
Subject: Re: [PATCH 03/10 V3] omap3: pm: use opp accessor
functions for omap34xx
Nishanth Menon n...@ti.com writes:
Move the definitions from omap3-opp.h to pm34xx.c. The definitions
are now based on omap_opp_def instead of omap_opp itself.
Since the opp.h has the omap_opp definition, omap-pm.h conflicts and
has been removed in favor of opp.h.
ok
omap3_pm_init_opp_table is used to initialize the OPP table and
relevant board files which have omap2_init_common_hw called with opp
arrays have been updated with omap3_pm_init_opp_table.
This change now allows us to dynamically register OPPs to the system
based on silicon type we detect.
Nice.
With this patch, I would suggest a couple more cleanups in how
we are handling
the master OPP lists for MPU, DSP and L3.
Namely, It's time we could remove the rate_table passing from the OMAP
PM layer all together and just keep them as pointers in opp.h.
The longer term goal is to remove OPP handling from OMAP PM
all together,
so this will be a step in that direction.
I've attached a patch that applies on top of your series that drops
the OPPs from OMAP PM layer. After doing this, we now have some
duplicate global pointers to the various rate tables that could be
cleaned up. In addition, all the rate tables could be dropped from
init_common_hw.
If you follow my proposal for using opp_add() instead of opp_init()
the board files that want to just use default OPPs do not have to do
anyting with the rate tables. Only board files wanting to add OPPs
would have to include opp.h and use opp_add().
Also, dropping the rate tables from init_common_hw would mean you
shouldn't have init sequence issues anymore and you can do the OPP
init inside existing PM init.
Kevin
NOTE: This introduces the following warnings highlighting areas we
need to cleanup:
arch/arm/mach-omap2/smartreflex.c: In function 'get_opp':
arch/arm/mach-omap2/smartreflex.c:161: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:164: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:166: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:168: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c: In function 'get_opp':
arch/arm/mach-omap2/resource34xx.c:165: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:168: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:170: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:172: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c: In function 'program_opp':
arch/arm/mach-omap2/resource34xx.c:284: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:285: warning: 'opp_id' is
deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-omap3beagle.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-rx51.c |1 +
arch/arm/mach-omap2/board-zoom2.c |2 +
arch/arm/mach-omap2/omap3-opp.h | 58
+---
arch/arm/mach-omap2/pm.h |6 +++
arch/arm/mach-omap2/pm34xx.c | 68
+
arch/arm/plat-omap/include/plat/omap-pm.h | 17 +---
9 files changed, 84 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index eac529f..0ec8327 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -220,6 +220,7 @@ static void __init omap_3430sdp_init_irq(void)
{
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+omap3_pm_init_opp_table();
omap3_pm_init_vc(omap3_setuptime_table);
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
omap3_mpu_rate_table,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
RE: [PATCH 1/2] ARM: Implemented support for VFP PM context saving
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: 24 November, 2009 17:19 To: Catalin Marinas Cc: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Dave Estes Subject: Re: [PATCH 1/2] ARM: Implemented support for VFP PM context saving On Tue, Nov 24, 2009 at 01:20:26PM +, Catalin Marinas wrote: BTW, the two patches below were mentioned to me some time ago but I haven't got the time to look at them: [ARM] vfp: Fix bug in vfp_pm_suspend https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c ommit;h=88984c9b2d69c222ee1e2afc948ca73f597d40ff This one is bad - it gets the current CPU by directly referencing ti-cpu. Too bad if you have kernel preemption enabled; the value obtained that way is effectively meaningless. The only way to get a meaningful value is via 'get_cpu()' and after you've done with using it, 'put_cpu()'. That ensures you can't be preempted onto a different CPU mid-operation. It's safe in vfp_notifier because we're called in an already atomic context. I investigated this issue a bit more, and indeed there is a potential bug in the vfp_pm_suspend(). Most of the time it works fine as apparently shell process has VFP enabled at least on my system, and it saves the state. The issue is different with dynamic idle, we are calling the code from init thread which does not need VFP for anything, and thus VFP is always disabled if we try to call vfp_pm_suspend(). For OMAP3, I found a way to fix the dynamic idle part to work properly by just simply calling vfp_sync_state() from idle. This functionality is supposed to be used by ptrace, but I guess it could be used for this also? A proper fix for suspend is bit more difficult, as I don't know too well how SMP is supposed to work in this case. I guess there is a separate VFP co-processor available for each ARM core, but vfp_pm_suspend() is only called once for the whole system? [ARM] vfp: Add additional vfp interfaces https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c ommit;h=393e4bfaaf79377d29cd6bb2228f87601aeca668 I don't like what's in this one. Lack of explaination in the commit log doesn't help. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: Implemented support for VFP PM context saving
-Original Message- From: ext Catalin Marinas [mailto:catalin.mari...@arm.com] Sent: 24 November, 2009 15:20 To: Russell King - ARM Linux Cc: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Dave Estes Subject: Re: [PATCH 1/2] ARM: Implemented support for VFP PM context saving On Tue, 2009-11-24 at 11:48 +, Russell King - ARM Linux wrote: On Tue, Nov 24, 2009 at 12:37:03PM +0200, Tero Kristo wrote: In some ARM architectures, like OMAP3, the VFP context can be lost during dynamic sleep cycle. For this purpose, there is now a function vfp_pm_save_context() that should be called before the VFP is assumed to lose context. Next VFP trap will then restore context automatically. We need to have the last_VFP_context[cpu] cleared after the save in idle, else the restore would fail to restore when it sees that the last_VFP_context is same as the current threads vfp_state. This happens when the same process/thread traps an exception post idle. Main work for this patch was done by Peter and Rajendra. Some cleanup and optimization by Tero. Why not re-use vfp_pm_suspend() ? Haven't you shown that vfp_pm_suspend may be buggy since it doesn't save in the VFP-disabled case? BTW, the two patches below were mentioned to me some time ago but I haven't got the time to look at them: [ARM] vfp: Fix bug in vfp_pm_suspend https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c ommit;h=88984c9b2d69c222ee1e2afc948ca73f597d40ff [ARM] vfp: Add additional vfp interfaces https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c ommit;h=393e4bfaaf79377d29cd6bb2228f87601aeca668 These look pretty much like the same thing we have attempted on the omap3 patches, I could try these out and check if they work for omap3 also. They fix the potentially broken suspend also. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: DVFS: No sdrc AC timing changes during core dvfs
Hi, Is there any update on this chain seeing this has been pending for a month now? -Tero -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Woodruff, Richard Sent: 22 October, 2009 15:20 To: Cousson, Benoit; Paul Walmsley; Nayak, Rajendra Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] OMAP3: DVFS: No sdrc AC timing changes during core dvfs Hi Beonit, From: Cousson, Benoit Sent: Thursday, October 22, 2009 3:59 AM To: Woodruff, Richard; Paul Walmsley; Nayak, Rajendra It is not guaranteed safe to write actim registers on the fly to an active part. It is safe to do RFR as it is buffered and sent out at a safe time. I think that what Paul is suggesting is to change the ACTIM after ensuring that the DDR is in self-refresh. In that case it is perfectly valid; it is just tricky to ensure that all initiators are in mute before doing that. Yes that is true, however, ... That is not the way the code is setup and it's a long way from that. Run time pause of drivers is a minefield. With out a broad notifier they best you would hope for is some opportunistic change time (against full system). You wouldn't have a guaranteed way to speed them up again where you need them most at high opp. Some minimal kernel not using dma and the like could do it but that is probably more misleading to put in the tree than something useful for most. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Force write last pad config register into save area
-Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 17 November, 2009 20:34 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP3: PM: Force write last pad config register into save area Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com Due to OMAP3 errata XYZ, the save of the last pad register (ETK_D14 and ETK_D15) can fail sometimes when there is simultaneous OCP access to the SCM register area. Fixed by writing the last register to the save area. Also, optimized the delay loop for the HW save to include an udelay(1), which limits the number of unnecessary HW accesses to SCM register area during the save. Signed-off-by: Tero Kristo tero.kri...@nokia.com I certainly like this fix much better than the original proposal: http://marc.info/?l=linux-omapm=125474186609661w=2 Pulling into PM branch after s/XYZ/1.157/ I will resend the patch when TI has confirmed the errata number. This version of the patch was also missing an #include linux/delay.h for the udelay, I missed this in the hurry, so I will add this one also. -Tero --- arch/arm/mach-omap2/pm34xx.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 4b01303..4ead40e 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -155,7 +155,15 @@ static void omap3_core_save_context(void) /* wait for the save to complete */ while (!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS) PADCONF_SAVE_DONE)) -; +udelay(1); + +/* + * Force write last pad into memory, as this can fail in some + * cases according to errata XYZ + */ +omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14), +OMAP343X_CONTROL_MEM_WKUP + 0x2a0); + /* Save the Interrupt controller context */ omap_intc_save_context(); /* Save the GPMC context */ -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/6] OMAP3: PM: Added support for INACTIVE and ON states for powerdomains
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 16 November, 2009 21:42
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/6] OMAP3: PM: Added support for INACTIVE
and ON states for powerdomains
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Previously omap_sram_idle() did not know about the
difference between ON and
INACTIVE states, which complicated the state handling in these cases.
This changelog needs an update.
This patch changes makes the IO-chain arming conditional and removes
the clockdomain idle calls.
IO-chain arming is already conditional, the condition needs to be changed a bit
due to changed powerdomain states.
- previously: less than PWRDM_POWER_ON = RET and OFF
- now: less than or equal to PWRDM_POWER_RET = RET and OFF
What is changed actually is that if CORE or PER is going INACTIVE, we will
disable UART clocks which will allow CORE and UART to go inactive. Previously
this did not happen.
While I understand the clkdm idle call removal, It's not clear from
the changelog how these are related to the new handling of INACTIVE
states.
Yes, I can try to fix the changelog a bit regarding this.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 9d0a9b4..7b52f30 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -383,6 +383,7 @@ void omap_sram_idle(void)
mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
switch (mpu_next_state) {
case PWRDM_POWER_ON:
+case PWRDM_POWER_INACTIVE:
case PWRDM_POWER_RET:
/* No need to save context */
save_state = 0;
@@ -448,9 +449,11 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
-/* Enable IO-PAD and IO-CHAIN wakeups */
-prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
-omap3_enable_io_chain();
+if (core_next_state = PWRDM_POWER_RET) {
+/* Enable IO-PAD and IO-CHAIN wakeups */
+prm_set_mod_reg_bits(OMAP3430_EN_IO,
WKUP_MOD, PM_WKEN);
+omap3_enable_io_chain();
+}
}
omap3_intc_prepare_idle();
@@ -542,15 +545,13 @@ void omap_sram_idle(void)
}
/* Disable IO-PAD and IO-CHAIN wakeup */
-if (core_next_state PWRDM_POWER_ON) {
+if (core_next_state = PWRDM_POWER_ON) {
Hmm, did you mean = RET here?
True, this is a bug. Should be RET.
Otherwise, you can just remove the conditional.
prm_clear_mod_reg_bits(OMAP3430_EN_IO,
WKUP_MOD, PM_WKEN);
omap3_disable_io_chain();
}
pwrdm_post_transition();
-
-omap2_clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
int omap3_can_sleep(void)
@@ -598,7 +599,6 @@ int set_pwrdm_state(struct powerdomain
*pwrdm, u32 state)
}
if (sleep_switch) {
-omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
pwrdm_wait_transition(pwrdm);
pwrdm_state_switch(pwrdm);
}
--
1.5.4.3
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 4/6] OMAP3: PM: Removed PER + CORE state hacking from omap_sram_idle
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 16 November, 2009 21:45
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 4/6] OMAP3: PM: Removed PER + CORE state
hacking from omap_sram_idle
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
A more descriptive changelog would be nice here.
This should be moved inside cpuidle to simplify design.
And this should probably say ... and will be moved into CPUidle in
subsequent patch.
I'll update this.
Kevin
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 18 ++
1 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 7b52f30..c704756 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -81,7 +81,6 @@ static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm;
static struct prm_setup_times_vc prm_setup_times_default = {
.clksetup = 0xff,
@@ -370,7 +369,6 @@ void omap_sram_idle(void)
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
-int per_state_modified = 0;
if (!_omap_sram_idle)
return;
@@ -409,19 +407,10 @@ void omap_sram_idle(void)
if (per_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
-if (per_next_state == PWRDM_POWER_OFF) {
-if (core_next_state == PWRDM_POWER_ON) {
-per_next_state = PWRDM_POWER_RET;
-pwrdm_set_next_pwrst(per_pwrdm,
per_next_state);
-per_state_modified = 1;
-} else
-omap3_per_save_context();
-}
+if (per_next_state == PWRDM_POWER_OFF)
+omap3_per_save_context();
}
-if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
-omap2_clkdm_deny_idle(mpu_pwrdm-pwrdm_clkdms[0]);
-
/*
* Disable smartreflex before entering WFI.
* Only needed if we are going to enter retention or off.
@@ -540,8 +529,6 @@ void omap_sram_idle(void)
omap3_gpio_restore_pad_context(1);
omap2_gpio_resume_after_idle();
omap_uart_resume_idle(2);
-if (per_state_modified)
-pwrdm_set_next_pwrst(per_pwrdm,
PWRDM_POWER_OFF);
}
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -1170,7 +1157,6 @@ static int __init omap3_pm_init(void)
neon_pwrdm = pwrdm_lookup(neon_pwrdm);
per_pwrdm = pwrdm_lookup(per_pwrdm);
core_pwrdm = pwrdm_lookup(core_pwrdm);
-cam_pwrdm = pwrdm_lookup(cam_pwrdm);
omap_push_sram_idle();
#ifdef CONFIG_SUSPEND
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] OMAP3: CPUidle: Added peripheral pwrdm checks into bm check
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 16 November, 2009 21:59
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 6/6] OMAP3: CPUidle: Added peripheral
pwrdm checks into bm check
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Following checks are made (and their reasoning):
- If CAM domain is active, prevent idle completely
* CAM pwrdm does not have HW wakeup capability
- If PER is likely to remain on, prevent PER off
* Saves on unnecessary context save/restore
- If CORE domain is active, prevent PER off-mode
* PER off in this case would prevent wakeups from PER completely
- Only allow CORE off, if all peripheral domains are off
* CORE off will cause a chipwide reset
Also, enabled CHECK_BM flag for C2, as this is needed for
the camera case.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Some questions and a couple minor style comments below...
Will do the style changes, answers below.
---
arch/arm/mach-omap2/cpuidle34xx.c | 105
++---
1 files changed, 98 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index e46345f..4654e87 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -58,7 +58,8 @@ struct omap3_processor_cx {
struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
-struct powerdomain *mpu_pd, *core_pd;
+struct powerdomain *mpu_pd, *core_pd, *per_pd, *iva2_pd;
+struct powerdomain *sgx_pd, *usb_pd, *cam_pd, *dss_pd;
/*
* The latencies/thresholds for various C states have
@@ -91,6 +92,13 @@ static int omap3_idle_bm_check(void)
return 0;
}
+static int pwrdm_get_idle_state(struct powerdomain *pwrdm)
could use a function comment
Ok.
+{
+if (pwrdm_can_idle(pwrdm))
+return pwrdm_read_next_pwrst(pwrdm);
+return PWRDM_POWER_ON;
+}
+
Possible candidate for powerdomain API?
Candidate yes, if we would need this somewhere else. I did not want to make an
API change that is not needed anywhere else at the moment. Maybe Paul has some
comments on this?
/**
* omap3_enter_idle - Programs OMAP3 to enter the specified state
* @dev: cpuidle device
@@ -153,14 +161,90 @@ static int omap3_enter_idle_bm(struct
cpuidle_device *dev,
struct cpuidle_state *state)
{
struct cpuidle_state *new_state = state;
-
-if ((state-flags CPUIDLE_FLAG_CHECK_BM)
omap3_idle_bm_check()) {
-BUG_ON(!dev-safe_state);
-new_state = dev-safe_state;
+u32 per_state = 0, saved_per_state = 0, cam_state, usb_state;
+u32 iva2_state, sgx_state, dss_state, new_core_state;
+struct omap3_processor_cx *cx;
+int ret;
+
+if (state-flags CPUIDLE_FLAG_CHECK_BM) {
+if (omap3_idle_bm_check()) {
+BUG_ON(!dev-safe_state);
+new_state = dev-safe_state;
+goto select_state;
+}
+cx = cpuidle_get_statedata(state);
+new_core_state = cx-core_state;
+
+/* Check if CORE is active, if yes, fallback to
inactive */
+if (!pwrdm_can_idle(core_pd))
+new_core_state = PWRDM_POWER_INACTIVE;
+
+/*
+ * Prevent idle completely if CAM is active.
+ * CAM does not have wakeup capability in OMAP3.
+ */
+cam_state = pwrdm_get_idle_state(cam_pd);
+if (cam_state == PWRDM_POWER_ON) {
+new_state = dev-safe_state;
+goto select_state;
+}
+
+/*
+ * Check if PER can idle or not. If we are not likely
+ * to idle, deny PER off. This prevents unnecessary
+ * context save/restore.
+ */
+saved_per_state = pwrdm_read_next_pwrst(per_pd);
+if (pwrdm_can_idle(per_pd)) {
+per_state = saved_per_state;
+/*
+ * Prevent PER off if CORE is active as this
+ * would disable PER wakeups completely
+ */
+if (per_state == PWRDM_POWER_OFF
+new_core_state PWRDM_POWER_RET)
+per_state = PWRDM_POWER_RET;
+
+} else if (saved_per_state == PWRDM_POWER_OFF)
+per_state = PWRDM_POWER_RET;
+
+/*
+ * If we are attempting CORE off, check if any other
+ * powerdomains are at retention or higher.
CORE off causes
+ * chipwide reset which would reset these domains also.
+ */
+if (new_core_state == PWRDM_POWER_OFF) {
+
RE: [PATCH 5/6] OMAP: Powerdomains: Add support for checking if pwrdm can idle
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 16 November, 2009 22:13
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 5/6] OMAP: Powerdomains: Add support for
checking if pwrdm can idle
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
pwrdm_can_idle(pwrdm) will check if the specified
powerdomain can enter
idle. This is done by checking the current fclk enable bits.
This call can be used e.g. inside cpuidle to decide which
power states
core and mpu should enter during idle, as there are certain
dependencies
between wakeup capabilities and reset logic.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
In your initial implementatio, you were checking all (most) of the
fclks in a given powerdomain. In this version, you're currently only
checking masks in CORE (UART1 and 2) and PER (UART3.)
The masks are negative masks, we are checking whether all the rest of the
clocks are inactive or not. UART clocks are currently masked away because we
are controlling those inside omap_sram_idle, thus they are always on when we do
the check, and the system assumes we can enter idle after they are disabled.
I'll assume it's just to propose the idea and we can add more fclks
later.
There might be some sort of need to add or change the masks on some boards.
Some of the UARTs might be controlled by some other drivers, in which case
their FCLK should actually be checked against, and not masked, because they
would no longer be controlled inside omap_sram_idle().
That being said, I'm a little reluctant to add another list of FCLK
masks. This seems like something that clock/clockdomain code should be
handling.
In terms of cleanness, it seems that pwrdm_can_idle() should call some
sort of clkdm_can_idle() call for all the clockdomains associated with
it (pwrdm-pwrdm_clkdms[].)
The clockdomain code already tracks its usecount, so clkdm_can_idle()
might be as simple as checking clkdm-usecount. Just a thought
without digging into the clkdm code.
I did think and experiment with this usecount option a bit. The problem with
usecounts is that you will have some interesting usecount numbers due to
always_on clocks, uart clocks, and interface clocks. For example per_clkdm
usecount is currently 9 on my rx51 board when we are entering omap_sram_idle
and there is nothing but UART3 active. This number is most likely something
else if we have a different board which has e.g. different number of interface
clocks active. Interface clocks do not matter in the idle equation because we
have autoidle enabled for all of those when we are entering idle and they will
be turned off by hw. It might be possible to somehow keep a separate usecount
for FCLKs and all clocks inside clock framework, but this sounds awfully
complex, as you can simply read this from HW.
However, the part where this idle check would be moved inside clockdomain code
is simple, I could just move the FCLK check bit there, and move the fclk_reg
and mask definitions from pwrdm to clkdm.
How does the option of moving the FCLK checks inside clkdm code sound like, but
keeping the implementation similar otherwise?
Kevin
---
arch/arm/mach-omap2/powerdomain.c | 22
++
arch/arm/mach-omap2/powerdomains34xx.h| 14 ++
arch/arm/plat-omap/include/plat/powerdomain.h |9 +
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 1237717..bf2b97a 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1217,6 +1217,28 @@ int pwrdm_wait_transition(struct
powerdomain *pwrdm)
return 0;
}
+/**
+ * pwrdm_can_idle - check if the powerdomain can enter idle
+ * @pwrdm: struct powerdomain * the powerdomain to check status of
+ *
+ * Does a functional clock check for the powerdomain and
returns 1 if the
+ * powerdomain can enter idle, 0 if not.
+ */
+int pwrdm_can_idle(struct powerdomain *pwrdm)
+{
+int i;
+const int fclk_regs[] = { CM_FCLKEN, OMAP3430ES2_CM_FCLKEN3 };
+
+if (!pwrdm)
+return -EINVAL;
+
+for (i = 0; i pwrdm-fclk_reg_amt; i++)
+if (cm_read_mod_reg(pwrdm-prcm_offs, fclk_regs[i])
+(0x ^ pwrdm-fclk_masks[i]))
+return 0;
+return 1;
+}
+
int pwrdm_state_switch(struct powerdomain *pwrdm)
{
return _pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index 9eb2dc5..c8cd297 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -180,6 +180,7 @@ static struct powerdomain iva2_pwrdm = {
[2] = PWRSTS_OFF_ON,
[3] = PWRDM_POWER_ON,
},
RE: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register save/restore
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
Sent: 12 November, 2009 01:27
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register
save/restore
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Current value is stored on SDRAM and it is written back
during wakeup.
Previously a static value of 0x72 was written there.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Thanks, applying to PM branch, queuing for pm-fixes.
I have a slightly modified version available of this now, which stores the data
inside arm_context. It is probably a bit nicer than this one. I'll send out the
refreshed version of this patch and you can see which one you want to use.
Kevin
---
arch/arm/mach-omap2/control.c |1 +
arch/arm/mach-omap2/sleep34xx.S | 23 ---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c
b/arch/arm/mach-omap2/control.c
index 296f2c2..730fc53 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -94,6 +94,7 @@ void *omap3_secure_ram_storage;
* during the restore path.
*/
u32 omap3_arm_context[128];
+u32 omap3_aux_ctrl[2] = { 0x1, 0x0 };
struct omap3_control_regs {
u32 sysconfig;
diff --git a/arch/arm/mach-omap2/sleep34xx.S
b/arch/arm/mach-omap2/sleep34xx.S
index f4f5ebe..0b03bf9 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -26,6 +26,7 @@
*/
#include linux/linkage.h
#include asm/assembler.h
+#include asm/memory.h
#include mach/io.h
#include mach/control.h
@@ -278,7 +279,11 @@ restore:
mov r1, #0 @ set task id for ROM code in r1
mov r2, #4 @ set some flags in r2, r6
mov r6, #0xff
-adr r3, write_aux_control_params@ r3 points to
parameters
+ldr r3, write_aux_control_params@ r3 points to
parameters
+ldr r4, phys_offset
+addsr3, r3, r4
+ldr r4, page_offset
+subsr3, r3, r4
mcr p15, 0, r0, c7, c10, 4 @ data write barrier
mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
.word 0xE1600071 @ call SMI monitor (smi #1)
@@ -287,13 +292,18 @@ restore:
l2_inv_api_params:
.word 0x1, 0x00
write_aux_control_params:
-.word 0x1, 0x72
+.word omap3_aux_ctrl
l2_inv_gp:
/* Execute smi to invalidate L2 cache */
mov r12, #0x1 @ set up to invalide L2
smi:.word 0xE1600070@ Call SMI monitor (smieq)
/* Write to Aux control register to set some bits */
-mov r0, #0x72
+ldr r1, write_aux_control_params
+ldr r0, phys_offset
+addsr1, r1, r0
+ldr r0, page_offset
+subsr1, r1, r0
+ldr r0, [r1, #4]
mov r12, #0x3
.word 0xE1600070@ Call SMI monitor (smieq)
logic_l1_restore:
@@ -420,6 +430,9 @@ usettbr0:
save_context_wfi:
/*b save_context_wfi*/ @ enable to debug save code
mov r8, r0 /* Store SDRAM address in r8 */
+mrc p15, 0, r4, c1, c0, 1 @ Read Auxiliary
Control Register
+ldr r5, write_aux_control_params
+str r4, [r5, #4]
/* Check what that target sleep state is:stored in r1*/
/* 1 - Only L1 and logic lost */
/* 2 - Only L2 lost */
@@ -605,6 +618,10 @@ wait_dll_lock:
bne wait_dll_lock
bx lr
+phys_offset:
+.word PHYS_OFFSET
+page_offset:
+.word PAGE_OFFSET
cm_idlest1_core:
.word CM_IDLEST1_CORE_V
sdrc_dlla_status:
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 09/11] OMAP3: PM: Added support for L2 aux ctrl register save and restore
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 12 November, 2009 01:45
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 09/11] OMAP3: PM: Added support for L2 aux
ctrl register save and restore
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
This patch adds a save and restore mechanism for ARM L2
auxiliary control
register. This feature is enabled via Kconfig option
OMAP3_L2_AUX_SECURE_SAVE_RESTORE and the service ID for PPA
can be provided
via option OMAP3_L2_AUX_SECURE_SERVICE_SET_ID. If bootloader
does not modify
L2 aux register, using this save and restore logic for it is
not needed.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Thanks, pulling into PM branch.
Same thing for this one, I have a version that uses arm_context as storage
area. I'll send it out also in a bit.
Kevin
---
arch/arm/mach-omap2/control.c |1 +
arch/arm/mach-omap2/sleep34xx.S | 31
+++
arch/arm/plat-omap/Kconfig | 17 +
3 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c
b/arch/arm/mach-omap2/control.c
index 730fc53..82d8f1a 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -95,6 +95,7 @@ void *omap3_secure_ram_storage;
*/
u32 omap3_arm_context[128];
u32 omap3_aux_ctrl[2] = { 0x1, 0x0 };
+u32 omap3_l2_aux_ctrl[2] = { 0x1, 0x0 };
struct omap3_control_regs {
u32 sysconfig;
diff --git a/arch/arm/mach-omap2/sleep34xx.S
b/arch/arm/mach-omap2/sleep34xx.S
index 0b03bf9..e291d6d 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -288,11 +288,30 @@ restore:
mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
.word 0xE1600071 @ call SMI monitor (smi #1)
+#ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+/* Restore L2 aux control register */
+@ set service ID for PPA
+mov r0, #CONFIG_OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
+mov r12, r0 @ copy service ID in r12
+mov r1, #0 @ set task ID for ROM code in r1
+mov r2, #4 @ set some flags in r2, r6
+mov r6, #0xff
+ldr r3, write_l2_aux_control_params @ r3 points to
parameters
+ldr r4, phys_offset
+addsr3, r3, r4
+ldr r4, page_offset
+subsr3, r3, r4
+mcr p15, 0, r0, c7, c10, 4 @ data write barrier
+mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
+.word 0xE1600071 @ call SMI monitor (smi #1)
+#endif
b logic_l1_restore
l2_inv_api_params:
.word 0x1, 0x00
write_aux_control_params:
.word omap3_aux_ctrl
+write_l2_aux_control_params:
+.word omap3_l2_aux_ctrl
l2_inv_gp:
/* Execute smi to invalidate L2 cache */
mov r12, #0x1 @ set up to invalide L2
@@ -306,6 +325,15 @@ smi:.word 0xE1600070
@ Call SMI monitor (smieq)
ldr r0, [r1, #4]
mov r12, #0x3
.word 0xE1600070@ Call SMI monitor (smieq)
+/* Restore L2 AUX control register */
+ldr r1, write_l2_aux_control_params
+ldr r0, phys_offset
+addsr1, r1, r0
+ldr r0, page_offset
+subsr1, r1, r0
+ldr r0, [r1, #4]
+mov r12, #0x2
+.word 0xE1600070@ Call SMI monitor (smieq)
logic_l1_restore:
mov r1, #0
/* Invalidate all instruction caches to PoU
@@ -433,6 +461,9 @@ save_context_wfi:
mrc p15, 0, r4, c1, c0, 1 @ Read Auxiliary
Control Register
ldr r5, write_aux_control_params
str r4, [r5, #4]
+mrc p15, 1, r4, c9, c0, 2 @ Read L2 AUX ctrl register
+ldr r5, write_l2_aux_control_params
+str r4, [r5, #4]
/* Check what that target sleep state is:stored in r1*/
/* 1 - Only L1 and logic lost */
/* 2 - Only L2 lost */
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 2143db5..3ff1a5f 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -185,6 +185,23 @@ config OMAP3_DEBOBS
help
Use ETK pads for debug observability
+config OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+bool OMAP3 HS/EMU save and restore for L2 AUX control register
+depends on ARCH_OMAP3 PM
+default n
+help
+ Without this option, L2 Auxiliary control register
contents are
+ lost during off-mode entry on HS/EMU devices. This feature
+ requires support from PPA / boot-loader in HS/EMU
devices, which
+ currently does not exist by default.
+
+config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
+int Service ID for the support routine to set L2 AUX control
+depends on OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+default 43
+help
+ PPA routine service ID for
RE: [PATCH 08/11] OMAP3: PM: Disabled I2C4 repeated start operation mode
-Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 12 November, 2009 01:30 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 08/11] OMAP3: PM: Disabled I2C4 repeated start operation mode Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com Repeated start forces I2C4 pads low during idle, which increases power consumption through external pull-ups. On the other hand, this change increases I2C4 command latencies a bit. Could you give an idea about how much the latencies increased? There is an additional master code (= 10 bits with start + ack) transmitted in the beginning of each I2C4 transmission. It is transmitted in fast/standard mode instead of high-speed, thus the duration of each I2C command is approximately doubled, from 25us to 50us. I'll update the patch description a bit and re-send. I'll apply this one but would like to update the changelog with some more details if available. Kevin Signed-off-by: Tero Kristo tero.kri...@nokia.com --- arch/arm/mach-omap2/pm34xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index fec9c38..154cd31 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -1219,7 +1219,7 @@ static void __init configure_vc(void) prm_write_mod_reg(OMAP3430_CMD1 | OMAP3430_RAV1, OMAP3430_GR_MOD, OMAP3_PRM_VC_CH_CONF_OFFSET); -prm_write_mod_reg(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN | OMAP3430_SREN, +prm_write_mod_reg(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN, OMAP3430_GR_MOD, OMAP3_PRM_VC_I2C_CFG_OFFSET); -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 11/11] OMAP3: PM: Disable OTG autoidle when waking up from off-mode
-Original Message-
From: ext Gadiyar, Anand [mailto:gadi...@ti.com]
Sent: 12 November, 2009 08:25
To: Kevin Hilman; Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH 11/11] OMAP3: PM: Disable OTG autoidle
when waking up from off-mode
Kevin Hilman wrote:
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
OMAP3 sleep can be prevented in some cases where OTG
autoidle is enabled.
This patch force disables autoidle during wakeup from
off-mode. See omap
errata 1.164.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
This one needs a refresh against current PM branch.
---
arch/arm/mach-omap2/pm34xx.c |6 ++
arch/arm/mach-omap2/usb-musb.c| 14 --
arch/arm/plat-omap/include/mach/usb.h |3 +++
mach/usb.h moved to plat/usb.h
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 5eb7321..070a0a2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -39,6 +39,7 @@
#include mach/gpmc.h
#include mach/dma.h
#include mach/dmtimer.h
+#include mach/usb.h
#include asm/tlbflush.h
@@ -496,6 +497,11 @@ void omap_sram_idle(void)
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+ /*
+ * Errata 1.164 fix : OTG autoidle can prevent
+ * sleep
+ */
+ usb_musb_disable_autoidle();
NAK. This belongs in the MUSB driver, not in the idle path.
Kevin,
When we exit off-mode, the autoidle will get enabled, and needs
an explicit disable. If the MUSB driver is not loaded, there will
be no one to do this.
Also, even if the driver is loaded, it doesn't disable this bit each sleep
cycle.
- Anand
Kevin
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
diff --git a/arch/arm/mach-omap2/usb-musb.c
b/arch/arm/mach-omap2/usb-musb.c
index 8dde0b7..f4b86c0 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -44,10 +44,11 @@ static struct platform_device dummy_pdev = {
},
};
+static void __iomem *otg_base;
+static struct clk *otg_clk;
+
static void __init usb_musb_pm_init(void)
{
- void __iomem *otg_base;
- struct clk *otg_clk;
struct device *dev = dummy_pdev.dev;
if (!cpu_is_omap34xx())
@@ -74,12 +75,13 @@ static void __init usb_musb_pm_init(void)
cpu_relax();
}
- if (otg_clk) {
+ if (otg_clk)
clk_disable(otg_clk);
- clk_put(otg_clk);
- }
+}
- iounmap(otg_base);
+void usb_musb_disable_autoidle(void)
+{
+ __raw_writel(0, otg_base + OTG_SYSCONFIG);
}
#ifdef CONFIG_USB_MUSB_SOC
diff --git a/arch/arm/plat-omap/include/mach/usb.h
b/arch/arm/plat-omap/include/mach/usb.h
index a4068a4..310ee17 100644
--- a/arch/arm/plat-omap/include/mach/usb.h
+++ b/arch/arm/plat-omap/include/mach/usb.h
@@ -46,6 +46,9 @@ extern void usb_musb_init(void);
extern void usb_ehci_init(struct
ehci_hcd_omap_platform_data *pdata);
+/* This is needed for OMAP3 errata 1.164: enabled
autoidle can prevent sleep */
+extern void usb_musb_disable_autoidle(void);
+
#endif
void omap_usb_init(struct omap_usb_config *pdata);
--
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 07/11] OMAP3: Fixed ARM aux ctrl register save/restore
-Original Message-
From: ext Gopinath, Thara [mailto:th...@ti.com]
Sent: 28 October, 2009 11:32
To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
Subject: RE: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register
save/restore
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero
Kristo
Sent: Friday, October 23, 2009 9:34 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register
save/restore
From: Tero Kristo tero.kri...@nokia.com
Current value is stored on SDRAM and it is written back
during wakeup.
Previously a static value of 0x72 was written there.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/control.c |1 +
arch/arm/mach-omap2/sleep34xx.S | 23 ---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c
b/arch/arm/mach-omap2/control.c
index 296f2c2..730fc53 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -94,6 +94,7 @@ void *omap3_secure_ram_storage;
* during the restore path.
*/
u32 omap3_arm_context[128];
+u32 omap3_aux_ctrl[2] = { 0x1, 0x0 };
struct omap3_control_regs {
u32 sysconfig;
diff --git a/arch/arm/mach-omap2/sleep34xx.S
b/arch/arm/mach-omap2/sleep34xx.S
index f4f5ebe..0b03bf9 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -26,6 +26,7 @@
*/
#include linux/linkage.h
#include asm/assembler.h
+#include asm/memory.h
#include mach/io.h
#include mach/control.h
@@ -278,7 +279,11 @@ restore:
mov r1, #0 @ set task id for ROM code in r1
mov r2, #4 @ set some flags in r2, r6
mov r6, #0xff
-adr r3, write_aux_control_params@ r3 points to
parameters
+ldr r3, write_aux_control_params@ r3 points to
parameters
+ldr r4, phys_offset
+addsr3, r3, r4
+ldr r4, page_offset
+subsr3, r3, r4
mcr p15, 0, r0, c7, c10, 4 @ data write barrier
mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
.word 0xE1600071 @ call SMI monitor (smi #1)
@@ -287,13 +292,18 @@ restore:
l2_inv_api_params:
.word 0x1, 0x00
write_aux_control_params:
-.word 0x1, 0x72
+.word omap3_aux_ctrl
l2_inv_gp:
/* Execute smi to invalidate L2 cache */
mov r12, #0x1 @ set up to invalide L2
smi:.word 0xE1600070@ Call SMI monitor (smieq)
/* Write to Aux control register to set some bits */
-mov r0, #0x72
+ldr r1, write_aux_control_params
+ldr r0, phys_offset
+addsr1, r1, r0
+ldr r0, page_offset
+subsr1, r1, r0
+ldr r0, [r1, #4]
mov r12, #0x3
.word 0xE1600070@ Call SMI monitor (smieq)
logic_l1_restore:
@@ -420,6 +430,9 @@ usettbr0:
save_context_wfi:
/*b save_context_wfi*/ @ enable to debug save code
mov r8, r0 /* Store SDRAM address in r8 */
+mrc p15, 0, r4, c1, c0, 1 @ Read Auxiliary
Control Register
+ldr r5, write_aux_control_params
+str r4, [r5, #4]
There is a simpler way of doing this. Store the aux control
value at the top of the sdram array where other parameters are
stored. It would be something like following
mrc p15, 0, r4, c1, c0, 1
str r4, [r8]
add r8, r8, #4
In the restore, you can read it from this location and pass it
as parameter for smi for gp device or pass this location as a
parameter for emu device. In this way no need to define
page_offset and phys_offset. I have a patch done for this for
an internal code base. I can share it with you if interested.
Else I can post it after rebasing. Do let me know.
I can modify my patch according to this. However, do you know how much of the
sdram array is currently used? The size is 128 32bit words but I would not like
to calculate manually how much of that is used and whether I need to increase
its size or not.
/* Check what that target sleep state is:stored in r1*/
/* 1 - Only L1 and logic lost */
/* 2 - Only L2 lost */
@@ -605,6 +618,10 @@ wait_dll_lock:
bne wait_dll_lock
bx lr
+phys_offset:
+.word PHYS_OFFSET
+page_offset:
+.word PAGE_OFFSET
cm_idlest1_core:
.word CM_IDLEST1_CORE_V
sdrc_dlla_status:
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] RX51: SDRAM settings changes
-Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 26 October, 2009 20:50 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 0/4] RX51: SDRAM settings changes Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com Following patch set fixes a few issues with current RX51 board SDRAM settings. Applies on top of PM branch. Tero, Can you resend this series against the master branch? There is no reason this should be carried in the PM branch anymore. You'll have to add to your series the patch to add the board-rx51-sdram.c file, which I currently carry in the PM branch. Then, for the PM branch, we just need a small patch to add the various rate tables in the call to init_common_hw until DVFS stuff is upstream. Ok, I have now done this. I also combined the series into one patch as it will generate a new file and I don't see any need to clutter git-log with several patches to currently non-existent file. Sending out now. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 20 October, 2009 20:48
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
setup times dynamically in idle loop
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
It is suggested by TI (SWPA152 February 2009) to write clksetup,
voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in
idle loop.
Can you summarize the reasons why?
Basically this optimizes the clksetup / voltsetup times according to the sleep
mode. Currently the settings are too high in both retention and off-mode,
because the hardware appears to use for example VOLTSETUP2 even if we are not
in off-mode, adding extra delay to wakeup. Also, CLKSETUP is too high for
retention mode because oscillator is not actually shut-off here.
However, now that I think about it, it might be better to change this in a way
that it is user configurable whether we want to change the settings or not,
maybe add new items in to the prm_setup struct for alternate settings for ret /
off and only use these if available. Some boards might actually switch
oscillator off in retention mode which would require higher setup time.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 36
+---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index f492142..ae83121 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -575,6 +575,30 @@ void omap_sram_idle(void)
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
+/* Write voltage setup times which are changed dynamically */
AFAICT, we only set these values at init time and they are never
changed. Are there some forthcoming patches that change these
dynamically?
Following bit of the code actually changes them dynamically, you can see that
e.g. CLKSETUP time is either prm_setup.clksetup or 0x1 depending on the sleep
mode. But as previously said, I think these should probably be added as new
items to the prm_setup struct.
Kevin
+if (core_next_state == PWRDM_POWER_OFF) {
+prm_write_mod_reg(0, OMAP3430_GR_MOD,
+OMAP3_PRM_VOLTSETUP1_OFFSET);
+prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
+OMAP3_PRM_VOLTSETUP2_OFFSET);
+prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
+OMAP3_PRM_CLKSETUP_OFFSET);
+} else {
+prm_write_mod_reg((prm_setup.voltsetup_time2
+OMAP3430_SETUP_TIME2_SHIFT) |
+(prm_setup.voltsetup_time1
+OMAP3430_SETUP_TIME1_SHIFT),
+OMAP3430_GR_MOD,
OMAP3_PRM_VOLTSETUP1_OFFSET);
+prm_write_mod_reg(0, OMAP3430_GR_MOD,
+OMAP3_PRM_VOLTSETUP2_OFFSET);
+/*
+ * Use static 1 as only HF_CLKOUT is turned off.
+ * Value taken from application note SWPA152
+ */
+prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
+OMAP3_PRM_CLKSETUP_OFFSET);
+}
+
/*
* omap3_arm_context is the location where ARM registers
* get saved. The restore path then reads from this
@@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VC_I2C_CFG_OFFSET);
-/* Write setup times */
-prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
-OMAP3_PRM_CLKSETUP_OFFSET);
-prm_write_mod_reg((prm_setup.voltsetup_time2
-OMAP3430_SETUP_TIME2_SHIFT) |
-(prm_setup.voltsetup_time1
-OMAP3430_SETUP_TIME1_SHIFT),
-OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
-
+/* Write static setup times */
prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTOFFSET_OFFSET);
-prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
-OMAP3_PRM_VOLTSETUP2_OFFSET);
pm_dbg_regset_init(1);
pm_dbg_regset_init(2);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 09/17] OMAP3: PM: Ack pending interrupts before entering suspend
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
Sent: 20 October, 2009 20:31
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
before entering suspend
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Suspending drivers may still generate interrupts just before
their suspend is
completed. Any pending interrupts here will prevent sleep.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
This could also be done in omap3_intc_prepare_idle() hook.
I thought it is better to do this in suspend path only, because in normal sleep
case we most likely don't want to miss any interrupts. In suspend case, we
usually want to enter the suspend no matter what, and this is used here only to
clean up the mess left by some of the drivers. The GPT case is one of the main
things we try to fix here.
-Tero
---
arch/arm/mach-omap2/irq.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/plat-omap/include/mach/irqs.h |1 +
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index aceedd8..4ed05e9 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -101,7 +101,7 @@ static int omap_check_spurious(unsigned int irq)
}
/* XXX: FIQ and additional INTC support (only MPU at the moment) */
-static void omap_ack_irq(unsigned int irq)
+void omap_ack_irq(unsigned int irq)
{
intc_bank_write_reg(0x1, irq_banks[0], INTC_CONTROL);
}
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 5854fa7..6a41811 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -778,6 +778,8 @@ static int omap3_pm_suspend(void)
omap_uart_prepare_suspend();
+/* Ack pending IRQs, as a pending IRQ will cause the
suspend to fail */
+omap_ack_irq(0);
regset_save_on_suspend = 1;
omap_sram_idle();
regset_save_on_suspend = 0;
diff --git a/arch/arm/plat-omap/include/mach/irqs.h
b/arch/arm/plat-omap/include/mach/irqs.h
index 2473910..d56be1c 100644
--- a/arch/arm/plat-omap/include/mach/irqs.h
+++ b/arch/arm/plat-omap/include/mach/irqs.h
@@ -483,6 +483,7 @@
#ifndef __ASSEMBLY__
extern void omap_init_irq(void);
extern int omap_irq_pending(void);
+extern void omap_ack_irq(unsigned int irq);
void omap3_intc_save_context(void);
void omap3_intc_restore_context(void);
#endif
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 21 October, 2009 17:15
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
setup times dynamically in idle loop
tero.kri...@nokia.com writes:
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 20 October, 2009 20:48
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
setup times dynamically in idle loop
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
It is suggested by TI (SWPA152 February 2009) to write clksetup,
voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in
idle loop.
Can you summarize the reasons why?
Basically this optimizes the clksetup / voltsetup times
according to the sleep mode. Currently the settings are too
high in both retention and off-mode, because the hardware
appears to use for example VOLTSETUP2 even if we are not in
off-mode, adding extra delay to wakeup. Also, CLKSETUP is too
high for retention mode because oscillator is not actually
shut-off here.
However, now that I think about it, it might be better to
change this in a way that it is user configurable whether we
want to change the settings or not, maybe add new items in to
the prm_setup struct for alternate settings for ret / off and
only use these if available. Some boards might actually switch
oscillator off in retention mode which would require higher setup time.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 36
+---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index f492142..ae83121 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -575,6 +575,30 @@ void omap_sram_idle(void)
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
+ /* Write voltage setup times which are changed dynamically */
AFAICT, we only set these values at init time and they are never
changed. Are there some forthcoming patches that change these
dynamically?
Following bit of the code actually changes them dynamically, you can
see that e.g. CLKSETUP time is either prm_setup.clksetup or 0x1
depending on the sleep mode.
Doh, I see now.
But as previously said, I think these should probably be added as
new items to the prm_setup struct.
Yes, I would rather see the prm_setup struct extended so these can be
passed in by board code.
I'll change the patch accordingly.
Kevin
+ if (core_next_state == PWRDM_POWER_OFF) {
+ prm_write_mod_reg(0, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP1_OFFSET);
+ prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ } else {
+ prm_write_mod_reg((prm_setup.voltsetup_time2
+ OMAP3430_SETUP_TIME2_SHIFT) |
+ (prm_setup.voltsetup_time1
+ OMAP3430_SETUP_TIME1_SHIFT),
+ OMAP3430_GR_MOD,
OMAP3_PRM_VOLTSETUP1_OFFSET);
+ prm_write_mod_reg(0, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ /*
+ * Use static 1 as only HF_CLKOUT is turned off.
+ * Value taken from application note SWPA152
+ */
+ prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ }
+
/*
* omap3_arm_context is the location where ARM registers
* get saved. The restore path then reads from this
@@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VC_I2C_CFG_OFFSET);
- /* Write setup times */
- prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
- OMAP3_PRM_CLKSETUP_OFFSET);
- prm_write_mod_reg((prm_setup.voltsetup_time2
- OMAP3430_SETUP_TIME2_SHIFT) |
- (prm_setup.voltsetup_time1
- OMAP3430_SETUP_TIME1_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
-
+ /* Write static setup times */
prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTOFFSET_OFFSET);
- prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTSETUP2_OFFSET);
pm_dbg_regset_init(1);
pm_dbg_regset_init(2);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More
RE: [PATCH 09/17] OMAP3: PM: Ack pending interrupts before entering suspend
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 21 October, 2009 17:20
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
before entering suspend
tero.kri...@nokia.com writes:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
Kevin Hilman
Sent: 20 October, 2009 20:31
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
before entering suspend
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Suspending drivers may still generate interrupts just before
their suspend is
completed. Any pending interrupts here will prevent sleep.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
This could also be done in omap3_intc_prepare_idle() hook.
I thought it is better to do this in suspend path only, because in
normal sleep case we most likely don't want to miss any
interrupts.
Agreed, then I'd suggest doing this in omap3_intc_[suspend|resume]()
hooks.
In suspend case, we usually want to enter the suspend no
matter what, and this is used here only to clean up the mess left by
some of the drivers. The GPT case is one of the main things we try
to fix here.
So is this still needed with the GPTIMER fix in PATCH 8/17?
Yeah, it is not enough to ack the interrupt at module level, we still have the
pending IRQ in the interrupt controller itself.
If there are other drivers having delayed interrupt triggering, it
sounds like the drivers need to be fixed instead of this brute force
approach.
I think any system device can have similar issue if they receive an interrupt
while we are entering suspend. The main problem is the sequence executed during
suspend: interrupts are disabled before we suspend the system devices (e.g.
clock source) and it is very possible for the devices to receive interrupts
during this window. GPT is a special case because it also has internal
buffering for the register writes, so it continues to tick a while after it is
stopped. GPT is also special in a sense that it can trigger an interrupt at
arbitrary points of time.
I don't know if similar issue exists on other platforms so changing the suspend
sequence itself is probably not an option. And.. acking all interrupts at every
suspending device is probably neither.
-Tero
---
arch/arm/mach-omap2/irq.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/plat-omap/include/mach/irqs.h |1 +
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index aceedd8..4ed05e9 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -101,7 +101,7 @@ static int
omap_check_spurious(unsigned int irq)
}
/* XXX: FIQ and additional INTC support (only MPU at the
moment) */
-static void omap_ack_irq(unsigned int irq)
+void omap_ack_irq(unsigned int irq)
{
intc_bank_write_reg(0x1, irq_banks[0], INTC_CONTROL);
}
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 5854fa7..6a41811 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -778,6 +778,8 @@ static int omap3_pm_suspend(void)
omap_uart_prepare_suspend();
+ /* Ack pending IRQs, as a pending IRQ will cause the
suspend to fail */
+ omap_ack_irq(0);
regset_save_on_suspend = 1;
omap_sram_idle();
regset_save_on_suspend = 0;
diff --git a/arch/arm/plat-omap/include/mach/irqs.h
b/arch/arm/plat-omap/include/mach/irqs.h
index 2473910..d56be1c 100644
--- a/arch/arm/plat-omap/include/mach/irqs.h
+++ b/arch/arm/plat-omap/include/mach/irqs.h
@@ -483,6 +483,7 @@
#ifndef __ASSEMBLY__
extern void omap_init_irq(void);
extern int omap_irq_pending(void);
+extern void omap_ack_irq(unsigned int irq);
void omap3_intc_save_context(void);
void omap3_intc_restore_context(void);
#endif
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 20 October, 2009 19:02
To: Kristo Tero (Nokia-D/Tampere)
Cc: giris...@ti.com; r-woodru...@ti.com;
linux-omap@vger.kernel.org; Hogander Jouni (Nokia-D/Tampere)
Subject: Re: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in
interrupt controller
tero.kri...@nokia.com writes:
There was one report from a custom board when it made a
difference. I've not tried to double check
this data. I don't have the reporters setup so there is no
guarantee I could reproduce anyway. In
general optimization seemed to make sense.
I second it.
Regards,
Girish
Is there errata number available for this issue by the way?
I could attach this to the patch.
Anyway, I guess the optimization would look something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO,
WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of
sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
Except omap_write* functions are deprecated.
I see, will use __raw_writel here then.
I'd rather see a call into the interrupt code. Something like
omap_intc_prepare_idle()
Can do these changes to add the interface yes. Though name would be
omap3_intc_prepare_idle() / ...resume_idle() as this is only needed for OMAP3.
Also, isn't this only needed if CORE != ON?
I understood from the problem description that this is needed always when we
are entering WFI, because we might have L3/L4 sleep/run transitions there even
if CORE is on.
/*
* On EMU/HS devices ROM code restores a SRDC value
@@ -561,6 +569,8 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
+ /* Re-enable interrupt controller autoidle */
+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE +
INTC_SYSCONFIG);
and omap_intc_resume_idle()
-Tero--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/17] PM: fix suspend control for IVA2
-Original Message-
From: ext Girish S G [mailto:giris...@ti.com]
Sent: 16 October, 2009 20:16
To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
Subject: RE: [PATCH 01/17] PM: fix suspend control for IVA2
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero
Kristo
From: Tero Kristo tero.kri...@nokia.com
IVA2 controls its target power state individually, thus
suspend should not
touch IVA2. Without this patch DSP suspend always fails.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Acked-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -676,6 +676,12 @@ static int omap3_pm_suspend(void)
pwrst-saved_state =
pwrdm_read_next_pwrst(pwrst-pwrdm);
/* Set ones wanted by suspend */
list_for_each_entry(pwrst, pwrst_list, node) {
+/* Special handling for IVA2, just use current
sleep state */
+if (pwrst-pwrdm == iva2_pwrdm) {
+state = pwrdm_read_pwrst(pwrst-pwrdm);
+if (state PWRDM_POWER_ON)
+pwrst-next_state = state;
+}
Agree, IVA2 pwrdm is handled autonomously by bridge. I think
this needs some additional change to remove all the redundant
configuration of iva pwdm. There are some inconsistencies like,
- Say enable_off_mode is disabled. Before doing system
wide suspend if DSP hibernates then IVA2 will be put to OFF. In that
case we have IVA2 going to OFF and other domains in RET. This
might not be an issue, but it's bad from sytem PM framework integrity
perspective.
This is an issue with bridge driver, and I am not sure how this should be
fixed. Currently bridge driver does not care whether off mode is enabled or not.
- enable_off_mode-omap3_pm_off_mode_enable will also
touch IVA2 power domain next state. This we don't want to do if dsp
bridge is already taking care of IVA2.
IMO, we need to have some mechanism wherein if bridge PM takes
care of IVA then PM framework should not configure the IVA
powerstate. It should only do if bridge PM is disabled.
Should we have a Kconfig option for this? Like CONFIG_OMAP3_BRIDGE_PM, and
disable all iva2 controls from pm34xx.c if it is enabled? Otherwise control
IVA2 as currently done.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 03/17] PM: Block CORE off when DSS is active
-Original Message-
From: ext Cousson, Benoit [mailto:b-cous...@ti.com]
Sent: 16 October, 2009 18:27
To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
Cc: Kalle Jokiniemi
Subject: RE: [PATCH 03/17] PM: Block CORE off when DSS is active
Hi Tero,
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270
Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Friday, October 16, 2009 12:49 PM
To: linux-omap@vger.kernel.org
Cc: Kalle Jokiniemi
Subject: [PATCH 03/17] PM: Block CORE off when DSS is active
From: Kalle Jokiniemi kalle.jokini...@digia.com
If CORE power domain is allowed to reach off state
while display is active, the display will go blank.
Fixed by adding a check in idle loop.
What is root cause? I guess it is due to extra latency
required to wakeup from OFF?
In that case, it should be better to use the
omap_pm_set_max_dev_wakeup_lat() function and set a latency
constraint to the CORE.
I believe the root cause is that if core enters off while display is doing
something (between DSS data bursts for example), then when the display next
wakes up and tries to access memories, core has lost its context which is
rather bad. It is not really a wakeup latency issue as such.
On the other hand, I remember a discussion between Kevin and
Tomi saying that this API might not be fully functional yet.
Regards,
Benoit
Signed-off-by: Kalle Jokiniemi ext-kalle.jokini...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index e8704a6..52a3f2b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -103,7 +103,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm, *iva2_pwrdm;
+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -427,6 +427,7 @@ void omap_sram_idle(void)
int mpu_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
+ int dss_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
@@ -469,6 +470,7 @@ void omap_sram_idle(void)
* save / restore.
*/
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+ dss_state = pwrdm_read_pwrst(dss_pwrdm);
if (core_next_state PWRDM_POWER_ON) {
core_saved_state = core_next_state;
if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1)
CORE_IDLEST1_ALL)
@@ -479,6 +481,10 @@ void omap_sram_idle(void)
CORE_IDLEST3_ALL) !=
CORE_IDLEST3_ALL) {
core_next_state = PWRDM_POWER_ON;
pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_ON);
+ } else if (core_next_state == PWRDM_POWER_OFF
+ dss_state == PWRDM_POWER_ON) {
+ core_next_state = PWRDM_POWER_RET;
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
}
}
@@ -1234,6 +1240,7 @@ static int __init omap3_pm_init(void)
core_pwrdm = pwrdm_lookup(core_pwrdm);
cam_pwrdm = pwrdm_lookup(cam_pwrdm);
iva2_pwrdm = pwrdm_lookup(iva2_pwrdm);
+ dss_pwrdm = pwrdm_lookup(dss_pwrdm);
omap_push_sram_idle();
#ifdef CONFIG_SUSPEND
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
-Original Message-
From: ext Girish S G [mailto:giris...@ti.com]
Sent: 16 October, 2009 21:10
To: 'Woodruff, Richard'; Kristo Tero (Nokia-D/Tampere);
linux-omap@vger.kernel.org
Cc: Hogander Jouni (Nokia-D/Tampere)
Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in
interrupt controller
-Original Message-
From: Woodruff, Richard [mailto:r-woodru...@ti.com]
Sent: Friday, October 16, 2009 1:04 PM
To: Ghongdemath, Girish; 'Tero Kristo'; linux-omap@vger.kernel.org
Cc: 'Jouni Hogander'
Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE
in interrupt controller
There was one report from a custom board when it made a
difference. I've not tried to double check
this data. I don't have the reporters setup so there is no
guarantee I could reproduce anyway. In
general optimization seemed to make sense.
I second it.
Regards,
Girish
Is there errata number available for this issue by the way? I could attach this
to the patch.
Anyway, I guess the optimization would look something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
/*
* On EMU/HS devices ROM code restores a SRDC value
@@ -561,6 +569,8 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
+ /* Re-enable interrupt controller autoidle */
+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
/*
* Enable smartreflex after WFI. Only needed if we
--
1.5.4.3--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM OMAP3: Change omap3_save_secure_ram to be called only during init
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 13 August, 2009 17:17
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] PM OMAP3: Change omap3_save_secure_ram to
be called only during init
Tero Kristo tero.kri...@nokia.com writes:
This function is now called only once during the
initialization of the device
and consequent sleep cycles will re-use the same saved
contents for secure
RAM. Users who need secure services should do secure RAM
saving before
entering off-mode, if a secure service has been accessed
after last save.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
You explain what you're doing, but you don't explain why.
Is there a large latency involved in this save/restore that you're
trying to eliminate for the no-secure-services case?
There are both latency and reliability issues. The context save uses a hardware
resource which takes an order of hundreds of milliseconds to initialize after a
wake up from off-mode, and also there is no way of checking whether it is ready
from kernel side or not. It just crashes if you use it too quickly.
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 4223622..b8cf5f2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -127,6 +127,12 @@ static void omap3_core_restore_context(void)
omap_dma_global_context_restore();
}
+/*
+ * FIXME: This function should be called before entering
off-mode after
+ * OMAP3 secure services have been accessed. Currently it
is only called
+ * once during boot sequence, but this works as we are not
using secure
+ * services.
+ */
static void omap3_save_secure_ram_context(u32 target_mpu_state)
{
u32 ret;
@@ -349,7 +355,6 @@ void omap_sram_idle(void)
OMAP3_PRM_VOLTCTRL_OFFSET);
omap3_core_save_context();
omap3_prcm_save_context();
-omap3_save_secure_ram_context(mpu_next_state);
}
/* Enable IO-PAD wakeup */
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
@@ -923,6 +928,18 @@ int __init omap3_pm_init(void)
}
omap3_save_scratchpad_contents();
+if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+local_irq_disable();
+local_fiq_disable();
+
+omap_dma_global_context_save();
+omap3_save_secure_ram_context(PWRDM_POWER_ON);
+omap_dma_global_context_restore();
+
+local_irq_enable();
+local_fiq_enable();
+}
+
err1:
return ret;
err2:
--
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: [PATCH 0/2] adding back some features
-Original Message-
From: ext Tony Lindgren [mailto:t...@atomide.com]
Sent: 17 June, 2009 12:58
To: Paul Walmsley
Cc: Kristo Tero (Nokia-D/Tampere); Kevin Hilman;
linux-omap@vger.kernel.org
Subject: Re: [PATCH 0/2] adding back some features
* Paul Walmsley p...@pwsan.com [090617 01:35]:
code comment below:
On Wed, 17 Jun 2009, Tony Lindgren wrote:
* Kevin Hilman khil...@deeprootsystems.com [090615 09:05]:
Kevin Hilman khil...@deeprootsystems.com writes:
Tony Lindgren t...@atomide.com writes:
Hi,
* Kevin Hilman khil...@deeprootsystems.com [090612 15:13]:
Here's a couple patches to add-back some feature dropped in
the mainline sync. These are needed for the PM
branch among other things.
Applies to linux-omap master.
Kevin Hilman (1):
OMAP2/3: SoC IDs: add omap_type() for determining GP/EMU/HS
Is there any reason to get this one into mainline early?
Well, the PM branch has a dependency, but also the recenetly
submitted qwatchdog driver has a dependency.
If not, I suggest you keep this in your pm branch for next
merge window that I can keep merging to l-o master as needed.
However, if omap_type() is by other queues earlier,
then I can
add it into my upstream queue. If this blocks several queues
from being rebased against mainline kernel, that alone might
already be a good enough reason to get it in early.
I think it should go via your upstream queue. I
imagine some of
the other upcoming driver submissions from TI will have a
dependency as well since there is still some missing
EMU/HS support ind drivers.
Also, I'm carrying this SRAM patch below for HS/EMU that
could go
into Paul's SRAM/SDRC queue if this omap_type() gets
merged sooner
rather than later.
Hmm, the HS omap sram.c patch below for sure justifies
fixing it as
incorrect SRAM size can cause nasty bugs.
Will add both omap_type and the sram.c patch below to omap-fixes.
Regards,
Tony
Kevin
commit 106588e30f070d9a8d5906d409e0b9aad89edc9e
Author: Tero Kristo tero.kri...@nokia.com
Date: Thu Oct 9 17:47:02 2008 +0300
OMAP3: SRAM size fix for HS/EMU devices
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@ti.deeprootsystems.com
diff --git a/arch/arm/plat-omap/sram.c
b/arch/arm/plat-omap/sram.c
old mode 100644 new mode 100755 index 65006df..f40bd2d
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -131,9 +131,15 @@ void __init omap_detect_sram(void)
if (cpu_class_is_omap2()) {
if (is_sram_locked()) {
if (cpu_is_omap34xx()) {
-omap_sram_base =
OMAP3_SRAM_PUB_VA;
-omap_sram_start =
OMAP3_SRAM_PUB_PA;
-omap_sram_size =
0x8000; /* 32K */
+if (omap_type() ==
OMAP2_DEVICE_TYPE_GP) {
+omap_sram_base
= OMAP3_SRAM_PUB_VA;
+omap_sram_start
= OMAP3_SRAM_PUB_PA;
+omap_sram_size
= 0x8000; /* 32K */
+} else {
This would be better if it specifically tested for HS and
EMU devices.
There are at least two other omap_type() possibilities here, TEST
and BAD
Tero, can you please repost? I will hold on sending out the
omap-fixes for that, and refresh omap-fixes with the updated patch.
I'll try to look at this tomorrow if I happen to have time, I am currently
quite busy fixing some bugs in our code base. However, if you need it right now
and if someone wants to re-write this to check against TEST and BAD, I am of
course okay with that (rather simple fix actually.) :)
-Tero
Tony
+omap_sram_base
= OMAP3_SRAM_PUB_VA;
+omap_sram_start
= OMAP3_SRAM_PUB_PA;
+omap_sram_size
= 0x7000; /* 28K */
+}
} else {
omap_sram_base =
OMAP2_SRAM_PUB_VA;
omap_sram_start =
OMAP2_SRAM_PUB_PA;
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 08 June, 2009 20:24
To: Jean Pihet
Cc: Paul Walmsley; Kristo Tero (Nokia-D/Tampere); linux-omap
Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
Jean Pihet jpi...@mvista.com writes:
On Monday 08 June 2009 16:59:36 Kevin Hilman wrote:
Jean Pihet jpi...@mvista.com writes:
Paul,
Here is the updated patch that fixes the Overo build as well.
Can you check it?
Kevin, can you push it if it is correct?
Can you run it through checkpatch, fix the errors and also merge
Tero's
RX51 patch if it looks good to you.
Ok. I will check. The cause might be the mailer.
I think we need the omap_cfg_reg calls in the RX51 board
file as well,
even if the bootloader has the mux setting already right. That way a
warning will be issued in case of a faulty bootloader. Do you agree?
I agree.
Well, this is ok for me too as it does not really change anything. I will voice
my opinion here though. :)
I find it somewhat weird that we take care of two pads in this fashion out of
~350 or so, where in most cases we just assume that the pads are configured
properly by the boot loader. Should we do the same for every pad? Does the
kernel even boot if the CKE signals are configured incorrectly? I would guess
the boot loader will fail to load the kernel image into SDRAM in that case.
-Tero
Kevin
Below are the checkpatch errors I get: looks lik your mailer is
probably wrapping the patch and there is also one error to fix.
Kevin
Regards,
Jean
ERROR: patch seems to be corrupt (line wrapped?)
#306: FILE: arch/arm/mach-omap2/clock34xx.c:477:
unsigned long rate)
ERROR: trailing whitespace
#494: FILE: arch/arm/mach-omap2/sdrc.c:128:
+ * @sdrc_cs[01]: pointers to a null-terminated list of struct $
total: 2 errors, 0 warnings, 648 lines checked
Your patch has style problems, please review. If any of
these errors
are false positives report them to the maintainer, see
CHECKPATCH in
MAINTAINERS.
Regards,
Jean
From ebe57354b0de059e1f042e0c488f761853f0 Mon Sep 17 00:00:00
2001
From: Jean Pihet jpi...@mvista.com
Date: Fri, 5 Jun 2009 17:19:00 +0200
Subject: OMAP3: add support for 2 SDRAM chip selects
Some boards (Beagle Cx, Overo) have 2 SDRAM parts
connected to the
SDRC.
This patch adds the following:
- ensure that the CKE signals mux settings are correct
- add a new argument of type omap_sdrc_params struct* to
omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
- adapted the OMAP boards files to the new prototype of
omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
- adapt the sram sleep code to configure the SDRC for the 2nd CS
Note: If the 2nd param to omap2_init_common_hw is NULL, then the
parameters are not programmed into the SDRC CS1 registers
Tested on 3430 SDP and Beagleboard rev C2 and B5, with
suspend/resume and frequency changes (cpufreq).
Thanks to Paul Walmsley and Kevin Hilman for the suggestions and
code reviews.
Signed-off-by: Jean Pihet jpi...@mvista.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |6 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-n800.c |2 +-
arch/arm/mach-omap2/board-omap2evm.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
arch/arm/mach-omap2/board-omap3evm.c |6 +-
arch/arm/mach-omap2/board-omap3pandora.c |3 +-
arch/arm/mach-omap2/board-overo.c|9 ++-
arch/arm/mach-omap2/board-rx51.c |6 +-
arch/arm/mach-omap2/clock34xx.c | 37 ++--
arch/arm/mach-omap2/io.c |5 +-
arch/arm/mach-omap2/mux.c|6 ++
arch/arm/mach-omap2/sdrc.c | 63 +-
arch/arm/mach-omap2/sram34xx.S | 137
+++---
arch/arm/plat-omap/include/mach/io.h |3 +-
arch/arm/plat-omap/include/mach/mux.h|4 +
arch/arm/plat-omap/include/mach/sdrc.h |8 +-
arch/arm/plat-omap/include/mach/sram.h | 23 +++--
arch/arm/plat-omap/sram.c| 34 +---
23 files changed, 267 insertions(+), 108 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index aa5df72..4cb7bc5 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -322,7 +322,7 @@ out:
static void __init omap_2430sdp_init_irq(void) {
- omap2_init_common_hw(NULL);
+ omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
sdp2430_init_smc91x();
diff --git
RE: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
-Original Message- From: ext Jean Pihet [mailto:jpi...@mvista.com] Sent: 09 June, 2009 11:24 To: Kristo Tero (Nokia-D/Tampere) Cc: khil...@deeprootsystems.com; p...@pwsan.com; linux-omap@vger.kernel.org Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects On Tuesday 09 June 2009 10:14:58 tero.kri...@nokia.com wrote: -Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 08 June, 2009 20:24 To: Jean Pihet Cc: Paul Walmsley; Kristo Tero (Nokia-D/Tampere); linux-omap Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects Jean Pihet jpi...@mvista.com writes: On Monday 08 June 2009 16:59:36 Kevin Hilman wrote: Jean Pihet jpi...@mvista.com writes: Paul, Here is the updated patch that fixes the Overo build as well. Can you check it? Kevin, can you push it if it is correct? Can you run it through checkpatch, fix the errors and also merge Tero's RX51 patch if it looks good to you. Ok. I will check. The cause might be the mailer. I think we need the omap_cfg_reg calls in the RX51 board file as well, even if the bootloader has the mux setting already right. That way a warning will be issued in case of a faulty bootloader. Do you agree? I agree. Well, this is ok for me too as it does not really change anything. I will voice my opinion here though. :) I find it somewhat weird that we take care of two pads in this fashion out of ~350 or so, where in most cases we just assume that the pads are configured properly by the boot loader. Should we do the same for every pad? Got your point. This omap_cfg_reg throws a warning if the pad is incorrectly configured. The goal is to better track the problem in case of a wrong/older bootloader. In the ideal world the bootloader and kernel should match and do it all right! Does the kernel even boot if the CKE signals are configured incorrectly? I would guess the boot loader will fail to load the kernel image into SDRAM in that case. The kernel boots fine in that case, only the SDRAM contents are not preserved when going to low power mode. Ok, in this case it sounds ok to me also as it might generate hard to track bugs. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings suspend/resume)
-Original Message-
From: ext Paul Walmsley [mailto:p...@pwsan.com]
Sent: 05 June, 2009 21:11
To: Jean Pihet; Kristo Tero (Nokia-D/Tampere)
Cc: Kevin Hilman; linux-omap
Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip
selects (was: Re: Beagleboard rev C memory timings suspend/resume)
Hi Jean,
On Fri, 5 Jun 2009, Jean Pihet wrote:
Here is the new patch that includes all the remarks and suggestion.
The description is here below.
Some notes:
- all calls to omap2_init_common_hw have been adapted in the board
files. it looks like 2430SDP and Pandora board files are
broken since
they use only one param. Can that be checked on those boards?
- it is assumed that RX51 only uses 1 CS. Is that correct?
Can you review it and possibly merge?
Looks great.
Tero, does RX51 use two SDRC chipselects!
Yes, I'll take a look at this and post a patch on top of this. I did this for
the earlier version already, but need to re-check this one.
-Tero
Acked-by: Paul Walmsley p...@pwsan.com
Thanks regards,
Jean
--
From 097a640997b74638e0e7200ecd5834205204c956 Mon Sep 17
00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Fri, 5 Jun 2009 17:19:00 +0200
Subject: [PATCH] [PATCH] OMAP3: add support for 2 SDRAM chip selects
Some boards (Beagle Cx, Overo) have 2 SDRAM parts connected to the
SDRC.
This patch adds the following:
- ensure that the CKE signals mux settings are correct
- add a new argument of type omap_sdrc_params struct* to
omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
- adapted the OMAP boards files to the new prototype of
omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
- adapt the sram sleep code to configure the SDRC for the 2nd CS
Note: If the 2nd param to omap2_init_common_hw is NULL, then the
parameters are not programmed into the SDRC CS1 registers
Tested on 3430 SDP and Beagleboard rev C2 and B5, with
suspend/resume
and frequency changes (cpufreq).
Thanks to Paul Walmsley and Kevin Hilman for the suggestions
and code
reviews.
Signed-off-by: Jean Pihet jpi...@mvista.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |6 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-n800.c |2 +-
arch/arm/mach-omap2/board-omap2evm.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
arch/arm/mach-omap2/board-omap3evm.c |6 +-
arch/arm/mach-omap2/board-omap3pandora.c |3 +-
arch/arm/mach-omap2/board-overo.c|8 ++-
arch/arm/mach-omap2/board-rx51.c |6 +-
arch/arm/mach-omap2/clock34xx.c | 37 ++--
arch/arm/mach-omap2/io.c |5 +-
arch/arm/mach-omap2/mux.c|6 ++
arch/arm/mach-omap2/sdrc.c | 63 +-
arch/arm/mach-omap2/sram34xx.S | 137
+++---
arch/arm/plat-omap/include/mach/io.h |3 +-
arch/arm/plat-omap/include/mach/mux.h|4 +
arch/arm/plat-omap/include/mach/sdrc.h |8 +-
arch/arm/plat-omap/include/mach/sram.h | 23 +++--
arch/arm/plat-omap/sram.c| 34 +---
23 files changed, 266 insertions(+), 108 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index aa5df72..4cb7bc5 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -322,7 +322,7 @@ out:
static void __init omap_2430sdp_init_irq(void) {
-omap2_init_common_hw(NULL);
+omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
sdp2430_init_smc91x();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 195b749..24e2728 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -302,8 +302,10 @@ static inline void __init
sdp3430_init_smc91x(void)
static void __init omap_3430sdp_init_irq(void) {
-omap2_init_common_hw(hyb18m512160af6_sdrc_params,
omap3_mpu_rate_table,
- omap3_dsp_rate_table, omap3_l3_rate_table);
+omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
+ omap3_mpu_rate_table,
+ omap3_dsp_rate_table,
+ omap3_l3_rate_table);
omap_init_irq();
omap_gpio_init();
sdp3430_init_smc91x();
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 2e24812..2dd1350 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -323,7 +323,7 @@ out:
static void __init omap_apollon_init_irq(void) {
-omap2_init_common_hw(NULL, NULL, NULL,
RE: [PATCH] RX51: Add support for SDRAM chip select 1
-Original Message-
From: ext Jean Pihet [mailto:jpi...@mvista.com]
Sent: 08 June, 2009 16:06
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] RX51: Add support for SDRAM chip select 1
Hi Tero,
You should also ensure that the CKE signals mux settings are
correct cf. an example for Overo at
http://patchwork.kernel.org/patch/28598/.
Our bootloader configures the pads, I just double checked that it also changes
CKE pads to proper config.
The patch looks good otherwise? I tested this on RX51 HW and it works ok.
-Tero
Note: the config option CONFIG_OMAP_MUX must be set for the
omap_cfg* functions to have any effect.
Regards,
Jean
On Monday 08 June 2009 14:03:23 Tero Kristo wrote:
From: Tero Kristo tero.kri...@nokia.com
Applies on top of PM branch.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/board-rx51.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51.c
b/arch/arm/mach-omap2/board-rx51.c index 3e4b7f8..7ab8a74 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -61,7 +61,11 @@ static struct omap_bluetooth_config
rx51_bt_config
= {
static void __init rx51_init_irq(void) {
-omap2_init_common_hw(rx51_get_sdram_timings(), NULL,
+struct omap_sdrc_params *sdrc_params;
+
+sdrc_params = rx51_get_sdram_timings();
+
+omap2_init_common_hw(sdrc_params, sdrc_params,
omap3_mpu_rate_table,
omap3_dsp_rate_table,
omap3_l3_rate_table);
--
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: Smart Reflex pm patches causes a kernel panic
Hi Elvis, I think I saw something similar last week, and it was caused by not having CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked line in sr_configure_vp(): vpconfig = PRM_VP1_CONFIG_ERROROFFSET | PRM_VP1_CONFIG_ERRORGAIN | PRM_VP1_CONFIG_TIMEOUTEN | mpu_opps[resource_get_level(vdd1_opp)].vsel OMAP3430_INITVOLTAGE_SHIFT; SR2 has similar code a bit later. You will also get a failure if mpu_opps[] and/or l3_opps[] is not defined at all in your board files, this null pointer exception would actually indicate a problem like that more likely. -Tero -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Elvis Dowson Sent: 19 May, 2009 14:21 To: Kevin Hilman Cc: Linux OMAP Users Subject: Smart Reflex pm patches causes a kernel panic Hi Kevin, I get a kernel panic on my TI OMAP 3503 when I incorporate the SR patches. How can I trace and debug this to find the cause of this null pointer error ? Power Management for TI OMAP3. mmc0: mmc_rescan - card ocr from io_op=0x, err = -110 pm_dbg_init() Unable to handle kernel NULL pointer dereference at virtual address 001e pgd = c0004000 [001e] *pgd= Internal error: Oops: 5 [#1] PREEMPT Modules linked in: CPU: 0Not tainted (2.6.29-omap1 #1) PC is at sr_configure_vp+0x28/0x1bc LR is at sr_configure_vp+0x1c/0x1bc pc : [c01055f4]lr : [c01055e8]psr: 6113 sp : cf81ff28 ip : cf81ff28 fp : cf81ff3c r10: r9 : r8 : 0001 r7 : c0012b44 r6 : r5 : c05c8660 r4 : c05c8624 r3 : r2 : 0001 r1 : 8113 r0 : Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 0017 Process swapper (pid: 1, stack limit = 0xcf81e2e8) Stack: (0xcf81ff28 to 0xcf82) ff20: c05c8660 c05c8624 cf81ff5c cf81ff40 c0012bc8 c01055d8 ff40: 08012954 c002d9d0 c002da20 cf81ffd4 cf81ff60 c00f52f8 c0012b50 ff60: cf81ff8c cf81ff70 c01cb9e4 c01cb6a8 cf81ff00 cf9a26e0 c01cbae4 cf81ff96 ff80: cf81ffbc cf81ff90 c014d408 c01cb970 c02fb2b4 35339600 0031 ffa0: 0192 c05d2034 cf81ffd4 c002d9d0 c002da20 ffc0: cf81fff4 cf81ffd8 c00083fc c00f52ac 0001 ffe0: cf81fff8 c011e2b8 c0008384 0836d404 5777f140 Backtrace: [c01055cc] (sr_configure_vp+0x0/0x1bc) from [c0012bc8] (omap3_sr_init+0x84/0x114) r4:c05c8624 [c0012b44] (omap3_sr_init+0x0/0x114) from [c00f52f8] (do_one_initcall+0x58/0x198) r5:c002da20 r4:c002d9d0 [c00f52a0] (do_one_initcall+0x0/0x198) from [c00083fc] (kernel_init +0x84/0xf4) r8: r7: r6: r5:c002da20 r4:c002d9d0 [c0008378] (kernel_init+0x0/0xf4) from [c011e2b8] (do_exit +0x0/0x7d0) r5: r4: Code: eb0024a7 e59f3180 e350 05933000 (01d301be) ---[ end trace eadc9c7cb4a7e9eb ]--- Kernel panic - not syncing: Attempted to kill init! I have extracted the pm patches by doing a git format-patch master on the pm branch. This generates 186 patch files, as of today. Since I don't know which particular patch is causing the problem, I need to fully exclude the following patch numbers to prevent the kernel panic. # file://omap-pm/0149-OMAP3-SR-Fix-init-voltage-on-OPP-change.patch ;patch=1 \ # file://omap-pm/0151-OMAP3-SR-Update-VDD1-2-voltages-at-boot.patch ;patch=1 \ # file://omap-pm/0152-OMAP3-SR-Use-sysclk-for-SR-CLKLENGTH-calc.patch ;patch=1 \ # file://omap-pm/0153-OMAP3-SR-Disable-SR-autocomp-only-for-CORE- trans.patch ;patch=1 \ # file://omap-pm/0154-OMAP3-SR-Reset-voltage-level-on-SR-disable.patch ;patch=1 \ # file://omap-pm/0155-OMAP3-SR-Replace-printk-s-with-pr_-calls.patch ;patch=1 \ # file://omap-pm/0156-OMAP3-SR-Remove-redundant- defines.patch;patch=1 \ # file://omap-pm/0157-OMAP3-SR-Replace-SR_PASS-FAIL-SR_TRUE-FALSE.patch ;patch=1 \ # file://omap-pm/0158-OMAP3-SR-Replace-0x1-n-with-BIT- n.patch;patch=1 \ # file://omap-pm/0159-OMAP3-clock-Remove-virt_vdd1-2_prcm_set.patch ;patch=1 \ The following patches (from 167 to 186) are more recent, and no necessary to reproduce the crash above: # file://omap-pm/0168-OMAP3-SR-Fix-SR-driver-to-check-for-omap-pm -return.patch ;patch=1 \ # file://omap-pm/0169-OMAP3-PM-Don-t-do-unnecessary-searches-in-o map_sr_.patch ;patch=1 \ # file://omap-pm/0181-OMAP-PM-SmartReflex-has-build-dependency-on -OMAP-P.patch ;patch=1 \ # file://omap-pm/0186-OMAP3-PM-Fix-Smartreflex-when-used-with-PM_ NOOP-la.patch ;patch=1 \ Excluding the SR patches gives me a workable kernel that doesn't crash on startup. Best regards, Elvis -- To unsubscribe from this
RE: Smart Reflex pm patches causes a kernel panic
-Original Message- From: ext Elvis Dowson [mailto:elvis.dow...@mac.com] Sent: 19 May, 2009 14:49 To: Kristo Tero (Nokia-D/Tampere) Cc: Linux OMAP Users Subject: Re: Smart Reflex pm patches causes a kernel panic Hi Tero, Thanks for the reply. I'll try this out. I don't think mpu_opps is defined for my board_overo.c file. I guess I should look at the board_sdp3430.c as an example for this? Yes, take a look at it. You are basically missing some parameters in a call to omap2_init_common_hw(), at least the version I am looking at here has a few NULL pointers passed. The rate tables (mpu + l3) should be posted as parameters in that. -Tero Thanks and do let me know! Best regards, Elvis On May 19, 2009, at 3:41 PM, tero.kri...@nokia.com wrote: Hi Elvis, I think I saw something similar last week, and it was caused by not having CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked line in sr_configure_vp(): vpconfig = PRM_VP1_CONFIG_ERROROFFSET | PRM_VP1_CONFIG_ERRORGAIN | PRM_VP1_CONFIG_TIMEOUTEN | mpu_opps[resource_get_level(vdd1_opp)].vsel OMAP3430_INITVOLTAGE_SHIFT; SR2 has similar code a bit later. You will also get a failure if mpu_opps[] and/or l3_opps[] is not defined at all in your board files, this null pointer exception would actually indicate a problem like that more likely. -- 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: Force USB to standby if not used
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 14 May, 2009 18:56
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: PM: Force USB to standby if not used
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
This patch will allow device to enter sleep mode while a USB
cable is
connected and USB is either disabled or built as a module
from kernel
config.
Applies on top of PM branch.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/usb-musb.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c
b/arch/arm/mach-omap2/usb-musb.c index 12a9b0a..dd51d2f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -32,7 +32,9 @@
#include mach/usb.h
#define AUTOIDLE(1 0)
+#define FORCESTDBY (1 0)
#define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
+#define OTG_FORCESTDBY (OMAP34XX_HSUSB_OTG_BASE + 0x414)
static struct resource musb_resources[] = {
[0] = { /* start and end set dynamically */ @@ -185,7
+187,11 @@
void __init usb_musb_init(void)
return;
}
-/* Enable smartidle on MUSB to improve C1 wakeup latency */
-if (cpu_is_omap34xx())
+#if !defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
+/* Force MUSB to standby if not used */
+if (cpu_is_omap34xx()) {
omap_writel(AUTOIDLE, OTG_SYSCONFIG);
+omap_writel(FORCESTDBY, OTG_FORCESTDBY);
+}
+#endif
Tero,
Is this needed if OTG_SYSCONFIG is set to force-idle?
Yesterday, I pushed a patch changing OTG_SYSCONFIG to
force-idle instead of auto-idle since on ES3.0 3430SDP, having
it in auto-idle was keeping CORE from hitting retention.
IIUC, there's an errata where force-idle doesn't work properly.
Also, why the #ifdefs?
This code is already conditionally compiled based on
CONFIG_USB_MUSB_SOC (see mach-omap2/Makefile) which is set
whether MUSB is built-in or a module.
#if !defined(CONFIG_USB) then CONFIG_USB_MUSB_SOC will not be
defined either.
You are actually right, I missed that change to Makefile. The reason for this
patch was to be able to hit retention / off when USB is not enabled, and this
was possible with the #ifdef:s earlier. I think you can just ignore this patch.
-Tero--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] OMAP3: GPIO off-mode fixes
The first patch in this set contains a small bug, missing kfree() for one of the dynamically reserved arrays during init in error path. Sending a fixed patch now. -Tero -Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 09 March, 2009 20:48 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2] OMAP3: GPIO off-mode fixes Tero Kristo tero.kri...@nokia.com writes: These two patches add fixes to GPIO off-mode handling. First patch is more important as it fixes a HW bug, second one just optimizes off-mode code a bit by removing a couple of unnecessary registers from the context save. Thanks, pushing both patches to PM branch. 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] OMAP3: Fixed crash bug with serial + suspend
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 03 March, 2009 18:58
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: Fixed crash bug with serial + suspend
Tero Kristo tero.kri...@nokia.com writes:
It was possible for an unhandled interrupt to occur if there was
incoming serial traffic during wakeup from suspend. This was
caused by
the code in arch-arm/mach-omap2/serial.c keeping interrupt
enabled all
the time, but not acking its interrupts. Applies on top of PM branch.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 15 +++
arch/arm/mach-omap2/serial.c | 18 ++
arch/arm/plat-omap/include/mach/serial.h |1 +
3 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index 9102cee..5a627db 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -629,7 +629,22 @@ static void omap3_pm_finish(void)
pm_idle = saved_idle;
}
+/* Hooks to enable / disable UART interrupts during suspend
*/ static
+int omap3_pm_begin(suspend_state_t state) {
+omap_uart_enable_irqs(0);
+return 0;
+}
+
+static void omap3_pm_end(void)
+{
+omap_uart_enable_irqs(1);
+return;
+}
+
static struct platform_suspend_ops omap_pm_ops = {
+.begin = omap3_pm_begin,
+.end= omap3_pm_end,
.prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
.finish = omap3_pm_finish,
I think this functionality is more appropriate for the
prepare/finish hooks than the begin/end hooks. serial.c already has
omap_uart_prepare_suspend() hook where the interrupt disable
could be added., and a omap_uart_prepare_resume() call could
be added to the omap3_pm_finish.
This would cause sequencing issues and it would still be possible to get
unhandled interrupts if I understand the behavior of suspend correctly. I think
it works (simplified) like this:
call begin hook
suspend devices [ this is where the driver interrupt gets disabled ]
call prepare hook
enter state [ Zzzz ]
call finish hook
resume devices [ this is where the driver interrupt gets enabled ]
call end hook
So, if you use prepare / finish hooks to enable the interrupt in serial.c, you
will get a short time period where you have the interrupt enabled but you do
not have real handler for the interrupt. This time is longer if you have some
drivers in the system that take a long time to resume/suspend and you are
unlucky with the ordering of drivers.
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c index 90f1c67..952da79 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -432,6 +432,24 @@ static void omap_uart_idle_init(struct
omap_uart_state *uart)
WARN_ON(ret);
}
+void omap_uart_enable_irqs(int enable) {
+int i, ret;
+
+for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+struct plat_serial8250_port *p =
serial_platform_data + i;
+struct omap_uart_state *uart = omap_uart[i];
+
Can you use the list_for_each_entry(uart, uart_list, node)
construct instead of a for loop? Or was there a reason to
enable/ack all serial interrupts, even those that have not
been enabled.
Hmm, yea that's true. I'll fix this one.
+if (!p-membase)
+continue;
+if (enable)
+ret = request_irq(p-irq, omap_uart_interrupt,
+IRQF_SHARED, serial idle,
(void *)uart);
+else
+free_irq(p-irq, (void *)uart);
+}
+}
+
static ssize_t sleep_timeout_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
diff --git a/arch/arm/plat-omap/include/mach/serial.h
b/arch/arm/plat-omap/include/mach/serial.h
index 8e89585..7ca1f27 100644
--- a/arch/arm/plat-omap/include/mach/serial.h
+++ b/arch/arm/plat-omap/include/mach/serial.h
@@ -47,6 +47,7 @@ extern void omap_uart_check_wakeup(void); extern
void omap_uart_prepare_suspend(void); extern void
omap_uart_prepare_idle(int num); extern void
omap_uart_resume_idle(int num);
+extern void omap_uart_enable_irqs(int enable);
#endif
#endif
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap
in the body of a message to majord...@vger.kernel.org More majordomo
info at http://vger.kernel.org/majordomo-info.html
--
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: Add support for DPLL3 divisor values higher than 2
Hi Kevin, Sorry I was on a sick leave so could not reply to this. Tero Kristo tero.kri...@nokia.com writes: Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control. Tero, What is this patch against? It doesn't apply to current PM branch, current l-o HEAD or on top of you DVFS patchset. This patch was intended to replace: [PATCH 20/23] OMAP3: Add support for DPLL3 divisor values higher than 2 ...from the core dvfs patch set. -Tero Kevin Signed-off-by: Tero Kristo tero.kri...@nokia.com --- arch/arm/mach-omap2/clock34xx.c|9 +++-- arch/arm/mach-omap2/sram34xx.S |8 +--- arch/arm/plat-omap/include/mach/sram.h |7 +-- arch/arm/plat-omap/sram.c |6 +++--- 4 files changed, 16 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index d6d4b46..b38cb30 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -516,9 +516,9 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) sdrcrate = sdrc_ick.rate; if (rate clk-rate) -sdrcrate = ((rate / clk-rate) - 1); +sdrcrate = ((rate / clk-rate) 1); else -sdrcrate = ((clk-rate / rate) - 1); +sdrcrate = ((clk-rate / rate) 1); sp = omap2_sdrc_get_params(sdrcrate); if (!sp) @@ -545,13 +545,10 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) pr_debug(clock: SDRC timing params used: %08x %08x %08x\n, sp-rfr_ctrl, sp-actim_ctrla, sp-actim_ctrlb); -/* REVISIT: SRAM code doesn't support other M2 divisors yet */ -WARN_ON(new_div != 1 new_div != 2); - local_irq_disable(); omap3_configure_core_dpll(sp-rfr_ctrl, sp-actim_ctrla, sp-actim_ctrlb, new_div, unlock_dll, c, - sp-mr); + sp-mr, rate clk-rate); local_irq_enable(); omap2_clksel_recalc(clk); diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 16eb4ef..487fa86 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -70,6 +70,7 @@ * r5 = number of MPU cycles to wait for SDRC to stabilize after * reprogramming the SDRC when switching to a slower MPU speed * r6 = new SDRC_MR_0 register value + * r7 = increasing SDRC rate? (1 = yes, 0 = no) * */ ENTRY(omap3_sram_configure_core_dpll) @@ -77,9 +78,10 @@ ENTRY(omap3_sram_configure_core_dpll) ldr r4, [sp, #52] @ pull extra args off the stack ldr r5, [sp, #56] @ load extra args from the stack ldr r6, [sp, #60] @ load extra args from the stack +ldr r7, [sp, #64] @ load extra args from the stack dsb @ flush buffered writes to interconnect -cmp r3, #0x2@ if increasing SDRC clk rate, -blneconfigure_sdrc @ program the SDRC regs early (for RFR) +cmp r7, #1 @ if increasing SDRC clk rate, +bleqconfigure_sdrc @ program the SDRC regs early (for RFR) cmp r4, #SDRC_UNLOCK_DLL@ set the intended DLL state blequnlock_dll blnelock_dll @@ -89,7 +91,7 @@ ENTRY(omap3_sram_configure_core_dpll) cmp r4, #SDRC_UNLOCK_DLL@ wait for DLL status to change bleqwait_dll_unlock blnewait_dll_lock -cmp r3, #0x1@ if increasing SDRC clk rate, +cmp r7, #1 @ if increasing SDRC clk rate, beq return_to_sdram @ return to SDRAM code, otherwise, bl configure_sdrc @ reprogram SDRC regs now mov r12, r5 diff --git a/arch/arm/plat-omap/include/mach/sram.h b/arch/arm/plat-omap/include/mach/sram.h index d07da3b..ad0a600 100644 --- a/arch/arm/plat-omap/include/mach/sram.h +++ b/arch/arm/plat-omap/include/mach/sram.h @@ -24,7 +24,8 @@ extern u32 omap2_set_prcm(u32 dpll_ctrl_val, u32 sdrc_rfr_val, int bypass); extern u32 omap3_configure_core_dpll(u32 sdrc_rfr_ctrl, u32 sdrc_actim_ctrla, u32 sdrc_actim_ctrlb, u32 m2, - u32 unlock_dll, u32 f, u32 sdrc_mr); + u32 unlock_dll, u32 f, u32 sdrc_mr, + u32 inc); extern void omap3_sram_restore_context(void); /* Do not use these */ @@ -62,7 +63,9 @@ extern unsigned long omap243x_sram_reprogram_sdrc_sz; extern u32 omap3_sram_configure_core_dpll(u32 sdrc_rfr_ctrl, u32 sdrc_actim_ctrla, - u32 sdrc_actim_ctrlb, u32 m2); + u32 sdrc_actim_ctrlb, u32 m2,
RE: [PATCH 20/23] OMAP3: Add support for DPLL3 divisor values higher than 2
Hi,
Hi Tero
one comment on this patch ...
On Thu, 11 Dec 2008, Tero Kristo wrote:
Previously only 1 and 2 was supported. This is needed for
DVFS VDD2 control.
diff --git a/arch/arm/mach-omap2/sram34xx.S
b/arch/arm/mach-omap2/sram34xx.S index 16eb4ef..832cd76 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -70,6 +70,7 @@
* r5 = number of MPU cycles to wait for SDRC to stabilize after
* reprogramming the SDRC when switching to a slower MPU speed
* r6 = new SDRC_MR_0 register value
+ * r7 = increasing SDRC rate? (1 = yes, 0 = no)
*
*/
ENTRY(omap3_sram_configure_core_dpll)
@@ -78,8 +79,8 @@ ENTRY(omap3_sram_configure_core_dpll)
ldr r5, [sp, #56] @ load extra args from the stack
ldr r6, [sp, #60] @ load extra args from the stack
you will also need a
ldr r7, [sp, #64] @ load extra args from the stack
here
Woops. Resending in a bit.
Funny though that this patch does not seem to affect system stability
too
much at initial testing, it did not cause any crash when I tried this
out.
Might cause problems in longer run / stress testing.
dsb @ flush buffered writes
to interconnect
-cmp r3, #0x2@ if increasing SDRC clk rate,
-blneconfigure_sdrc @ program the SDRC regs
early (for RFR)
+cmp r7, #1 @ if increasing SDRC clk rate,
+bleqconfigure_sdrc @ program the SDRC regs
early (for RFR)
cmp r4, #SDRC_UNLOCK_DLL@ set the intended DLL state
blequnlock_dll
blnelock_dll
@@ -89,7 +90,7 @@ ENTRY(omap3_sram_configure_core_dpll)
cmp r4, #SDRC_UNLOCK_DLL@ wait for DLL status to change
bleqwait_dll_unlock
blnewait_dll_lock
-cmp r3, #0x1@ if increasing SDRC clk rate,
+cmp r7, #1 @ if increasing SDRC clk rate,
beq return_to_sdram @ return to SDRAM code,
otherwise,
bl configure_sdrc @ reprogram SDRC regs now
mov r12, r5
diff --git a/arch/arm/plat-omap/include/mach/sram.h
b/arch/arm/plat-omap/include/mach/sram.h
index d07da3b..ad0a600 100644
--- a/arch/arm/plat-omap/include/mach/sram.h
+++ b/arch/arm/plat-omap/include/mach/sram.h
@@ -24,7 +24,8 @@ extern u32 omap2_set_prcm(u32 dpll_ctrl_val, u32
sdrc_rfr_val, int bypass); extern u32
omap3_configure_core_dpll(u32 sdrc_rfr_ctrl,
u32 sdrc_actim_ctrla,
u32 sdrc_actim_ctrlb, u32 m2,
- u32 unlock_dll, u32 f, u32
sdrc_mr);
+ u32 unlock_dll, u32 f, u32 sdrc_mr,
+ u32 inc);
extern void omap3_sram_restore_context(void);
/* Do not use these */
@@ -62,7 +63,9 @@ extern unsigned long
omap243x_sram_reprogram_sdrc_sz;
extern u32 omap3_sram_configure_core_dpll(u32 sdrc_rfr_ctrl,
u32 sdrc_actim_ctrla,
- u32 sdrc_actim_ctrlb, u32 m2);
+ u32 sdrc_actim_ctrlb, u32 m2,
+ u32 unlock_dll, u32
f, u32 sdrc_mr,
+ u32 inc);
extern unsigned long omap3_sram_configure_core_dpll_sz;
#ifdef CONFIG_PM
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 68a1f69..9f6232f 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -372,10 +372,10 @@ static u32
(*_omap3_sram_configure_core_dpll)(u32 sdrc_rfr_ctrl,
u32 sdrc_actim_ctrla,
u32 sdrc_actim_ctrlb,
u32 m2, u32 unlock_dll,
- u32 f, u32 sdrc_mr);
+ u32 f, u32
sdrc_mr, u32 inc);
u32 omap3_configure_core_dpll(u32 sdrc_rfr_ctrl, u32
sdrc_actim_ctrla,
u32 sdrc_actim_ctrlb, u32 m2, u32
unlock_dll,
- u32 f, u32 sdrc_mr)
+ u32 f, u32 sdrc_mr, u32 inc)
{
if (!_omap3_sram_configure_core_dpll)
omap_sram_error();
@@ -383,7 +383,7 @@ u32 omap3_configure_core_dpll(u32
sdrc_rfr_ctrl, u32 sdrc_actim_ctrla,
return _omap3_sram_configure_core_dpll(sdrc_rfr_ctrl,
sdrc_actim_ctrla,
sdrc_actim_ctrlb, m2,
- unlock_dll, f, sdrc_mr);
+ unlock_dll, f,
sdrc_mr, inc);
}
#ifdef CONFIG_PM
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap
in the body of a message to [EMAIL PROTECTED] More
RE: [PATCH 1/1] Save sram context after changing MPU, DSP or core clocks
Hi Peter, This patch causes linker error without CONFIG_PM option, should add #ifdef:s around the call to omap3_save_scratchpad_contents(); -Tero -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Peter 'p2' De Schrijver Sent: 19 November, 2008 13:45 To: linux-omap@vger.kernel.org Cc: De-Schrijver Peter (Nokia-D/Helsinki) Subject: [PATCH 1/1] Save sram context after changing MPU, DSP or core clocks Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock34xx.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index d97d5a9..962ce56 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -911,6 +911,9 @@ printk(%s set to %luHz intended rate %luHz\n,dpll2_clk-name,clk_get_rate(dpll clk_set_rate(dpll3_clk, prcm_vdd-rate); curr_vdd2_prcm_set = prcm_vdd; } + + omap3_save_scratchpad_contents(); + return 0; } -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: GPIO fixes for off-mode
Hi, On Monday 01 December 2008, Tero Kristo wrote: Off mode is now using the omap2 retention fix code for scanning GPIOs only during off-mode transitions. All the *non_wakeup_gpios variables are now used for off-mode transition tracking on OMAP3. This patch fixes cases where GPIO state changes are missed during off-mode. I second the no #ifdefs comment ... I agree the code looks horrible at the moment with the multitude of #ifdef:s, I just did not feel comfortable fixing all of those, so I continued the way it has been written so far... Could you uplevel your description here a bit? I'm trying to understand if what this does is complete and correct. My understanding is that we currently have several mechanisms interacting to affect things that relate to the OMAP3-only off modes for pins used as GPIOs: - irq_chip.set_wake() calls, for GPIOs used as IRQs. We should assume that if the IRQ is wake-enabled, that applies to OFF mode too. (AFAICT, this mechanism is not handled by this patch.) Off mode wakeup requires setting up IO pads according to the wakeup scheme you want to have. This is rather nasty limitation of the HW and you need to be careful how you configure these things. This patch assumes you have configured your IO pads in a way that you get wakeups for your GPIOs during off, and when you eventually wakeup, it will scan all GPIOs to see if any GPIO interrupt has happened. You will not get edge sensitive interrupts from GPIOs during off-mode, because the hardware block handling the edge sensing has no power at all. - Hmm, and because a goal is to transparently enter OFF modes to save power, rather than only after drivers get suspend() calls that tend to trigger set_wake(), an un-commented conclusion seems to be that all GPIOs used as IRQs implicitly act like set_wake() was called. (Something which *is* partially addressed here.) Yes, this is correct. I think this is somewhat against the design of the omap2 code, as the GPIOs can wakeup the device from both suspend and dynamic idle. However, this is mainly caused by the IO pad wakeup mechanism of omap3, which does not care whether you are in dynamic idle or in suspend. Handling this correctly would require creating IO pad control mechanism to the kernel, something that I am not sure if we want to do (we would need to have separate IO pad config for suspend and dynamic idle.) - omap_cfg_reg() configuration for any pin can include its OFF-mode parameters. Virtually unused ... and not addressed by this patch, so I'm puzzled how pins are expected to be kept active with just this patch. Mux configuration for OMAP3 is handled mostly by boot loader at the moment, this is the behavior at least on TI SDP implementation. - OMAP2-specific bug workarounds, some GPIOs can't be used for wakeup, ergo bank-non_wakeup_gpios. This is resolved for OMAP3, yes? Well, basically only bank 0 can be used for wakeup in omap3, wakeups for all the rest are handled via IO pad. When I looked at this issue a while back, I came to believe that we'd need to map GPIOs to their config registers so we could diddle the OFF-mode bits. And I don't see such a mapping (table) here... Yep, if we want to have different configs for suspend and dynamic idle, this is something we should do. However, having around 190 pins in OMAP3 you can potentially configure as GPIOs, I am really hesitant writing such piece of code. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM: Added three PLL registers to the PRCM context save
Hi,
Just an initial comment to this patch, this is somewhat experimental and
I think we should agree what registers will actually be saved here and
what should be left for drivers. CM_CLKSEL4 is for DPLL5 which is used
by USB. Two of the CLKEN registers are more interesting.
-Tero
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext Tero Kristo
Sent: 19 November, 2008 11:32
To: linux-omap@vger.kernel.org
Subject: [PATCH] PM: Added three PLL registers to the PRCM context save
These registers are now also saved:
CM_CLKSEL4
CM_CLKEN
CM_CLKEN2
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/prcm.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c
b/arch/arm/mach-omap2/prcm.c index d5a1e4b..c64b668 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -46,7 +46,10 @@ struct omap3_prcm_regs {
u32 emu_cm_clksel;
u32 emu_cm_clkstctrl;
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;
u32 core_cm_fclken1;
@@ -233,8 +236,14 @@ void omap3_prcm_save_context(void)
cm_read_mod_reg(OMAP3430_EMU_MOD,
CM_CLKSTCTRL);
prcm_context.pll_cm_autoidle2 =
cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
+ prcm_context.pll_cm_clksel4 =
+ 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);
prcm_context.iva2_cm_fclken =
cm_read_mod_reg(OMAP3430_IVA2_MOD,
CM_FCLKEN); @@ -380,8 +389,13 @@ void omap3_prcm_restore_context(void)
CM_CLKSTCTRL);
cm_write_mod_reg(prcm_context.pll_cm_autoidle2, PLL_MOD,
CM_AUTOIDLE2);
+ cm_write_mod_reg(prcm_context.pll_cm_clksel4, PLL_MOD,
+ 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);
cm_write_mod_reg(prcm_context.iva2_cm_fclken, OMAP3430_IVA2_MOD,
CM_FCLKEN);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in the body of a message to
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/05] OMAP3: Basic Cpuidle with support for C0-C2
Hi Rajendra,
Currently cpuidle is not taking enable_off_mode variable (from pm.c)
into account, it only controls suspend / dynamic idle behavior.
-Tero
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext
Rajendra Nayak
Sent: 08 October, 2008 15:01
To: linux-omap@vger.kernel.org
Cc: 'Kevin Hilman'
Subject: [PATCH 01/05] OMAP3: Basic Cpuidle with support for C0-C2
Basic cpuidle driver for OMAP3 with deepest sleep state
supported being MPU CSWR.
Signed-off-by: Rajendra Nayak [EMAIL PROTECTED]
---
arch/arm/mach-omap2/Makefile |2
arch/arm/mach-omap2/cpuidle34xx.c| 274
+++
arch/arm/mach-omap2/pm34xx.c |4
arch/arm/plat-omap/include/mach/pm.h |1
4 files changed, 279 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile
2008-10-08 16:49:07.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/Makefile
2008-10-08 16:49:10.0 +0530
@@ -23,7 +23,7 @@ ifeq ($(CONFIG_PM),y)
obj-y += pm.o
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG)+= pm-debug.o
endif
Index: linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
2008-10-08 16:50:02.0 +0530
@@ -0,0 +1,274 @@
+/*
+ * linux/arch/arm/mach-omap2/cpuidle34xx.c
+ *
+ * OMAP3 CPU IDLE Routines
+ *
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ * Rajendra Nayak [EMAIL PROTECTED]
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Karthik Dasu [EMAIL PROTECTED]
+ *
+ * Copyright (C) 2006 Nokia Corporation
+ * Tony Lindgren [EMAIL PROTECTED]
+ *
+ * Copyright (C) 2005 Texas Instruments, Inc.
+ * Richard Woodruff [EMAIL PROTECTED]
+ *
+ * Based on pm.c for omap2
+ *
+ * This program is free software; you can redistribute it
and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/cpuidle.h
+#include mach/pm.h
+#include mach/prcm.h
+#include mach/powerdomain.h
+
+#ifdef CONFIG_CPU_IDLE
+
+#define OMAP3_MAX_STATES 7
+#define OMAP3_STATE_C0 0 /* C0 - System executing code */ #define
+OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */ #define
+OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */ #define
+OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */ #define
+OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */ #define
OMAP3_STATE_C5 5
+/* C5 - MPU OFF + Core RET */ #define OMAP3_STATE_C6 6 /* C6
- MPU OFF
++ Core OFF */
+
+struct omap3_processor_cx {
+ u8 valid;
+ u8 type;
+ u32 sleep_latency;
+ u32 wakeup_latency;
+ u32 mpu_state;
+ u32 core_state;
+ u32 threshold;
+ u32 flags;
+};
+
+struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
+struct omap3_processor_cx current_cx_state; struct
powerdomain *mpu_pd;
+
+static int omap3_idle_bm_check(void)
+{
+ return 0;
+}
+
+/**
+ * omap3_enter_idle - Programs OMAP3 to enter the specified state
+ * @dev: cpuidle device
+ * @state: The target state to be programmed
+ *
+ * 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;
+
+ current_cx_state = *cx;
+
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(ts_preidle);
+
+ local_irq_disable();
+ local_fiq_disable();
+
+ /* Program MPU to target state */
+ if (cx-mpu_state PWRDM_POWER_ON)
+ pwrdm_set_next_pwrst(mpu_pd, cx-mpu_state);
+
+ /* Execute ARM wfi */
+ omap_sram_idle();
+
+ /* Program MPU to ON */
+ if (cx-mpu_state PWRDM_POWER_ON)
+ pwrdm_set_next_pwrst(mpu_pd, PWRDM_POWER_ON);
+
+ getnstimeofday(ts_postidle);
+ ts_idle = timespec_sub(ts_postidle, ts_preidle);
+
+ local_irq_enable();
+ local_fiq_enable();
+
+ return timespec_to_ns(ts_idle);
+}
+
+/**
+ * omap3_enter_idle_bm - Checks for any bus activity
+ * @dev: cpuidle device
+ * @state: The target state to be programmed
+ *
+ * Called from the CPUidle framework for C states with
+CPUIDLE_FLAG_CHECK_BM
+ * flag set. This function checks for any pending bus
activity and then
+ * programs the device to the
RE: [PATCH] OMAP3 clock: put DPLL into bypass if bypass rate = clk-rate, not hardware rate
Hi, The three patches you sent (fix CONFIG_OMAP_RESET_CLOCKS, fix dss1_alwon_clk and this one) seem to fix problems I was seeing with retention. -Tero -Original Message- From: ext Paul Walmsley [mailto:[EMAIL PROTECTED] Sent: 25 September, 2008 17:39 To: linux-omap@vger.kernel.org Cc: Kristo Tero (Nokia-D/Tampere); [EMAIL PROTECTED] Subject: [PATCH] OMAP3 clock: put DPLL into bypass if bypass rate = clk-rate, not hardware rate When a non-CORE DPLL is enabled via omap3_noncore_dpll_enable(), use the user's desired rate in clk-rate to determine whether to put the DPLL into bypass or lock mode, rather than reading the DPLL's current idle state from its hardware registers. This fixes a bug observed when leaving retention. Non-CORE DPLLs were not being relocked when downstream clocks re-enabled; rather, the DPLL entered bypass mode. Problem reported by Tero Kristo [EMAIL PROTECTED]. Signed-off-by: Paul Walmsley [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock34xx.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index c89d6bc..df258f7 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -281,9 +281,7 @@ static int omap3_noncore_dpll_enable(struct clk *clk) if (!dd) return -EINVAL; - rate = omap2_get_dpll_rate(clk); - - if (dd-bypass_clk-rate == rate) + if (clk-rate == dd-bypass_clk-rate) r = _omap3_noncore_dpll_bypass(clk); else r = _omap3_noncore_dpll_lock(clk); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
-Original Message-
From: Balbi Felipe (Nokia-D/Helsinki)
Sent: 25 September, 2008 14:41
To: ext Tony Lindgren
Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero
(Nokia-D/Tampere); linux-omap@vger.kernel.org
Subject: Re: [PATCH] Fixed OMAP3 version check
On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
* Felipe Balbi [EMAIL PROTECTED] [080925 13:24]:
On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
Hi,
* Tero Kristo [EMAIL PROTECTED] [080916 14:59]:
CPU version was reported incorrectly (e.g. ES3.0 instead of
ES2.1.) Also added a piece of optimization for CPU
type check (omap_type()).
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/id.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c
b/arch/arm/mach-omap2/id.c
index ab7a6e9..4e2b449 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
int omap_type(void)
{
- u32 val = 0;
+ static u32 val;
+
+ if (val != 0)
+ return val;
Hmm I guess this would return a random val? :)
it would return 0, look that val is static.
Ah, sorry I did not see the static. So this is to cache the
result to
optimize it? I'd assume this function is only needed during
some init
code hopefully where performance does not matter..
Yeah, it's not like we're gonna check the revision after the
board is botted all up I guess.
PM code will need to either cache the type information or call this
check every time when entering off-mode. Some things work differently in
secure chips. Could probably just cache this inside PM code.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
-Original Message-
From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: 25 September, 2008 14:50
To: Kristo Tero (Nokia-D/Tampere)
Cc: Balbi Felipe (Nokia-D/Helsinki); linux-omap@vger.kernel.org
Subject: Re: [PATCH] Fixed OMAP3 version check
* Tony Lindgren [EMAIL PROTECTED] [080925 14:47]:
* [EMAIL PROTECTED] [EMAIL PROTECTED] [080925 14:45]:
-Original Message-
From: Balbi Felipe (Nokia-D/Helsinki)
Sent: 25 September, 2008 14:41
To: ext Tony Lindgren
Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero
(Nokia-D/Tampere);
linux-omap@vger.kernel.org
Subject: Re: [PATCH] Fixed OMAP3 version check
On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
* Felipe Balbi [EMAIL PROTECTED] [080925 13:24]:
On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
Hi,
* Tero Kristo [EMAIL PROTECTED] [080916 14:59]:
CPU version was reported incorrectly (e.g. ES3.0
instead of
ES2.1.) Also added a piece of optimization for CPU
type check (omap_type()).
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/id.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c
b/arch/arm/mach-omap2/id.c
index ab7a6e9..4e2b449 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
int omap_type(void)
{
- u32 val = 0;
+ static u32 val;
+
+ if (val != 0)
+ return val;
Hmm I guess this would return a random val? :)
it would return 0, look that val is static.
Ah, sorry I did not see the static. So this is to cache the
result to
optimize it? I'd assume this function is only needed during
some init
code hopefully where performance does not matter..
Yeah, it's not like we're gonna check the revision after
the board
is botted all up I guess.
PM code will need to either cache the type information or
call this
check every time when entering off-mode. Some things work
differently in secure chips. Could probably just cache
this inside PM code.
How about setting up the save and restore registers properly for GP
and HS omap once during PM init?
To clarify: Set the save and restore registers and needed
functions only once during PM init depending on the omap type.
That would be possible also. We only have two additional things to do in
secure OMAP chips anyway, so it is not a big deal. Need to get the damn
thing working first though, can think about optimizations later. .
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
Hi,
Here is a fix that works on top of your patch. Tested with ES2.1 and
ES3.0 chips. I left out the caching for CPU type.
-Tero
-Original Message-
From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: 25 September, 2008 13:18
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] Fixed OMAP3 version check
Hi,
* Tero Kristo [EMAIL PROTECTED] [080916 14:59]:
CPU version was reported incorrectly (e.g. ES3.0 instead of ES2.1.)
Also added a piece of optimization for CPU type check (omap_type()).
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/id.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c
b/arch/arm/mach-omap2/id.c index
ab7a6e9..4e2b449 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
int omap_type(void)
{
-u32 val = 0;
+static u32 val;
+
+if (val != 0)
+return val;
Hmm I guess this would return a random val? :)
if (cpu_is_omap24xx()) {
val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
@@ -169,7 +172,7 @@ void __init omap34xx_check_revision(void)
rev = (idcode 28) 0xff;
if (hawkeye == 0xb7ae)
-system_rev = 0x34300034 | ((1 + rev) 12);
+system_rev = 0x34300034 | (rev 12);
out:
switch (system_rev) {
Well AFAIK here are the numbers for rev:
ES1.0 0/* Cannot read idcode register */
ES2.0 0
ES2.1 1
ES3.0 2
While ES3.0 TRM claims:
ES1.0 0
ES2.0 1
ES2.1 2
ES3.0 3
Which I think is incorrect at least for ES2.0 and ES2.1.
Can you please try the attached patch and see if it detects
your ES3.0 correctly?
Tony
0001-OMAP3-Fixed-version-check.patch
Description: 0001-OMAP3-Fixed-version-check.patch
clk_disable_unused() is bugged
Hi, clk_disable_unused (in plat-omap/clock.c) is bugged in latest kernel. It checks whether ck-enable_reg is zero, and in most cases this happens to be so (CM_FCLKEN = 0.) Seems to be caused by some late change to clocktree where enable_reg fields are defined as module offsets, not register addresses. This bug causes several clocks to remain enabled after boot, and at least on OMAP3 it prevents retention. Paul, you got a fix coming for this? -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM: Added sleep support to UART
Just a quick comment to this patch, there might be issues (again) with OMAP2 as the patch has lived again a bit. So, someone should preferably test this on OMAP2 before integrating. This is now a standalone version of the patch and does not require GPIO patch below to work. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM debug support for 34xx
Any comments to this? I have already a new version available of this
stuff where I have integrated the suspend / next state control to this
also, and the file structure modified a bit.
Should this be split into several patches for easier handling or
something? It is getting rather big already (as a patch.)
-Tero
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext Tero Kristo
Sent: 12 September, 2008 14:49
To: linux-omap@vger.kernel.org
Subject: [PATCH] PM debug support for 34xx
This patch adds a few files to the debug file system for PM
debugging purposes. Enabled with kernel config options
CONFIG_PM_DEBUG and CONFIG_DEBUG_FS. Data available in debug
filesystem after this patch:
- State enter counters for power domains (OFF, RET, ON)
- State timers for the above (in ns)
- PM register dumps with programmable save points
- Current power domain states
- Interface to set_pwrdm_state()
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock.c |2 +
arch/arm/mach-omap2/clockdomain.c | 27 ++
arch/arm/mach-omap2/pm-debug.c| 406
+
arch/arm/mach-omap2/pm.c |2 +
arch/arm/mach-omap2/pm.h | 33 ++-
arch/arm/mach-omap2/pm34xx.c |6 +-
arch/arm/mach-omap2/powerdomain.c | 69 +
arch/arm/plat-omap/include/mach/powerdomain.h |7 +-
8 files changed, 548 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c
b/arch/arm/mach-omap2/clock.c index 88c8ef4..a5fc5b0 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -39,6 +39,7 @@
#include cm.h
#include cm-regbits-24xx.h
#include cm-regbits-34xx.h
+#include pm.h
#define MAX_CLOCK_ENABLE_WAIT 10
@@ -1025,5 +1026,6 @@ void omap2_clk_disable_unused(struct clk *clk)
printk(KERN_INFO Disabling unused clock \%s\\n, clk-name);
_omap2_clk_disable(clk);
+ pm_dbg_clk_state_switch(clk);
}
#endif
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index fa62f14..9670ed1 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -36,6 +36,8 @@
#include mach/powerdomain.h
#include mach/clockdomain.h
+#include pm.h
+
/* clkdm_list contains all registered struct clockdomains */
static LIST_HEAD(clkdm_list);
@@ -567,6 +569,8 @@ int omap2_clkdm_clk_enable(struct
clockdomain *clkdm, struct clk *clk)
else
omap2_clkdm_wakeup(clkdm);
+ pm_dbg_clkdm_state_switch(clkdm);
+
return 0;
}
@@ -618,6 +622,29 @@ int omap2_clkdm_clk_disable(struct
clockdomain *clkdm, struct clk *clk)
else
omap2_clkdm_sleep(clkdm);
+ pm_dbg_clkdm_state_switch(clkdm);
+
+ return 0;
+}
+
+#if defined(CONFIG_PM_DEBUG) defined(CONFIG_DEBUG_FS) #include
+linux/debugfs.h #include linux/seq_file.h int
+clkdm_dbg_show_counters(struct seq_file *s, void *unused) {
+ struct clockdomain *clkdm;
+
+ list_for_each_entry(clkdm, clkdm_list, node) {
+ if (strcmp(clkdm-name, emu_clkdm) == 0 ||
+ strcmp(clkdm-name, wkup_clkdm) == 0)
+ continue;
+ seq_printf(s, %s-%s (%d), clkdm-name,
+ clkdm-pwrdm.ptr-name,
+ atomic_read(clkdm-usecount));
+ seq_printf(s, \n);
+ }
+
return 0;
}
+#endif
diff --git a/arch/arm/mach-omap2/pm-debug.c
b/arch/arm/mach-omap2/pm-debug.c index b00f5f4..380a2a0 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -30,6 +30,9 @@
#include mach/clock.h
#include mach/board.h
+#include mach/powerdomain.h
+#include mach/clockdomain.h
+#include mach/common.h
#include prm.h
#include cm.h
#include pm.h
@@ -153,4 +156,407 @@ void omap2_pm_dump(int mode, int resume,
unsigned int us)
printk(%-20s: 0x%08x\n, regs[i].name, regs[i].val); }
+#ifdef CONFIG_DEBUG_FS
+#include linux/debugfs.h
+#include linux/seq_file.h
+
+static void pm_dbg_regset_store(u32 *ptr);
+
+struct dentry *pm_dbg_dir;
+
+static int pm_dbg_init_done;
+
+enum {
+ PM_DBG_STATE_NOW = 0,
+ PM_DBG_STATE_PREV,
+};
+
+struct pm_module_def {
+ char name[8]; /* Name of the module */
+ short type; /* CM or PRM */
+ unsigned short offset;
+ int low; /* First register address on this module */
+ int high; /* Last register address on this module */ };
+
+#define MOD_CM 0
+#define MOD_PRM 1
+
+static const struct pm_module_def pm_dbg_reg_modules[] = {
+ { IVA2, MOD_CM, OMAP3430_IVA2_MOD, 0, 0x4c },
+ { OCP, MOD_CM, OCP_MOD, 0, 0x10 },
+ { MPU, MOD_CM, MPU_MOD, 4, 0x4c },
+ { CORE, MOD_CM, CORE_MOD, 0, 0x4c },
+ { SGX, MOD_CM, OMAP3430ES2_SGX_MOD, 0, 0x4c },
+ { WKUP, MOD_CM, WKUP_MOD, 0, 0x40 },
+ { CCR, MOD_CM, PLL_MOD, 0, 0x70 },
+
RE: [PATCH 1/4] PM: Dynamic GPIO clock handling
These comments should now be fixed in the new version I just sent out.
-Tero
-Original Message-
From: Högander Jouni [mailto:[EMAIL PROTECTED]
Sent: 05 September, 2008 16:47
To: ext Paul Walmsley
Cc: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/4] PM: Dynamic GPIO clock handling
ext Paul Walmsley [EMAIL PROTECTED] writes:
Hello Tero, Jouni,
so is this basically a workaround patch?
Yes in new format. Please do not use word workaround;)
a few comments:
On Wed, 27 Aug 2008, Tero Kristo wrote:
From: ext Jouni Hogander [EMAIL PROTECTED]
In omap3 gpios 2-6 are in per domain. Functional clocks for these
should be disabled.
GPIO modules in PER domain are not able to act as a wake up
source if
PER domain is in retention. PER domain sleep transition
before MPU is
prevented by leaving icks active. PER domain still enters retention
together with MPU. When this happens IOPAD wake up
mechanism is used
for gpios.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm.c | 20 --
arch/arm/mach-omap2/pm.h |2 +-
arch/arm/mach-omap2/pm34xx.c | 56
+-
3 files changed, 67 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 4652136..1de5f14 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -32,7 +32,7 @@
#include pm.h
unsigned short enable_dyn_sleep;
-unsigned short clocks_off_while_idle;
+unsigned short gpio_clocks_off_while_idle;
atomic_t sleep_block = ATOMIC_INIT(0);
static ssize_t idle_show(struct kobject *, struct
kobj_attribute *,
char *); @@ -42,16 +42,16 @@ static ssize_t
idle_store(struct kobject
*k, struct kobj_attribute *, static struct kobj_attribute
sleep_while_idle_attr =
__ATTR(sleep_while_idle, 0644, idle_show, idle_store);
-static struct kobj_attribute clocks_off_while_idle_attr =
- __ATTR(clocks_off_while_idle, 0644, idle_show, idle_store);
+static struct kobj_attribute gpio_clocks_off_while_idle_attr =
+ __ATTR(gpio_clocks_off_while_idle, 0644, idle_show, idle_store);
static ssize_t idle_show(struct kobject *kobj, struct
kobj_attribute *attr,
char *buf)
{
if (attr == sleep_while_idle_attr)
return sprintf(buf, %hu\n, enable_dyn_sleep);
- else if (attr == clocks_off_while_idle_attr)
- return sprintf(buf, %hu\n, clocks_off_while_idle);
+ else if (attr == gpio_clocks_off_while_idle_attr)
+ return sprintf(buf, %hu\n,
gpio_clocks_off_while_idle);
else
return -EINVAL;
}
@@ -69,8 +69,8 @@ static ssize_t idle_store(struct kobject *kobj,
struct kobj_attribute *attr,
if (attr == sleep_while_idle_attr)
enable_dyn_sleep = value;
- else if (attr == clocks_off_while_idle_attr)
- clocks_off_while_idle = value;
+ else if (attr == gpio_clocks_off_while_idle_attr)
+ gpio_clocks_off_while_idle = value;
else
return -EINVAL;
@@ -106,10 +106,12 @@ static int __init omap_pm_init(void)
/* disabled till drivers are fixed */
enable_dyn_sleep = 0;
error = sysfs_create_file(power_kobj,
sleep_while_idle_attr.attr);
- if (error)
+ if (error) {
printk(KERN_ERR sysfs_create_file failed:
%d\n, error);
+ return error;
+ }
error = sysfs_create_file(power_kobj,
- clocks_off_while_idle_attr.attr);
+
gpio_clocks_off_while_idle_attr.attr);
if (error)
printk(KERN_ERR sysfs_create_file failed:
%d\n, error);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 68c9278..d446ea4 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -17,7 +17,7 @@ extern int omap2_pm_init(void); extern int
omap3_pm_init(void);
extern unsigned short enable_dyn_sleep; -extern unsigned short
clocks_off_while_idle;
+extern unsigned short gpio_clocks_off_while_idle;
extern atomic_t sleep_block;
extern void omap2_block_sleep(void); diff --git
a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index
a16eb33..0baf359 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -53,6 +53,43 @@ static void (*saved_idle)(void);
static struct powerdomain *mpu_pwrdm;
+/* Dynamic GPIO clock handling for sleep routines.
+ * omap_sram_idle() will call these functions and they will
+dynamically
+ * enable / disable GPIO clocks to allow sleep transitions. */
Please use CodingStyle format for multiple-line comments, e.g.,
Yes, needs to be fixed...
/*
* Dynamic GPIO clock handling ...
* etc. etc. etc.
*/
This also applies to several other comments later in the file.
ok
+#define NUM_OF_PERGPIOS 5
+static struct clk *gpio_fcks[NUM_OF_PERGPIOS];
+
+/* Enable GPIO clocks
RE: [PATCH 2/4] PM: Workaround for taking care of gpio clocks
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Tony Lindgren Sent: 20 August, 2008 14:37 To: Hogander Jouni (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks * Jouni Hogander [EMAIL PROTECTED] [080815 10:47]: In omap3 gpios 2-6 are in per domain. Functional clocks for these should be disabled. This patch is needed until gpio driver disables gpio clocks. GPIO modules in PER domain are not able to act as a wake up source if PER domain is in retention. PER domain sleep transition before MPU is prevented by leaving icks active. PER domain still enters retention together with MPU. When this happens IOPAD wake up mechanism is used for gpios. As we talked offline.. Should we pass the GPIO wake-up configuration from board-*.c files? Or can we always automatically do this safely on 34xx? After some investigation it seems that we can configure wake-up events for almost every GPIO from the padconfigs. There are only 2 pins that do not seem to have this functionality, however I am not sure if this is a documentation bug or what because it is strange that only 2 pins lack this capability. GPIOs 32 and 187 are missing wake-up capability from padconfig. Because of this, our proposal would be to make GPIO clock switching global, but this would be enabled from a sysfs entry pretty much like how it is in the patches now. However, this would be separated from UART clock switching. So, we would introduce two new sysfs files: uart_clocks_off_while_idle and gpio_clocks_off_while_idle. This would avoid introducing new complexity in to the idle loop. How does this sound like? -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: getnstimeofday() and suspend
Hmm, well it should get the value straight from the 32KiHZ sync timer. Does that get stopped somehow during suspend? Tony Timer is not stopped, because immediately after suspend I get correct value from it (called from wakeup interrupt), but after this it is reprogrammed by something, or either time management code gets confused somehow. Hi Tony, This behavior of the getnstimeofday() is breaking pm-debug and the serial console wakeup hack if we use suspend. Enabling RTC module seems to fix some of the issues in some cases, but we are going to lose timer accuracy (RTC accuracy is only 1 second.) Also, these functionalities should not be dependant on RTC imo. Should I revert these patches to use directly HW timer and ignore getnstimeofday() or what do you think? -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: getnstimeofday() and suspend
-Original Message- From: Stoppa Igor (Nokia-D/Helsinki) Sent: 15 August, 2008 13:11 To: Hogander Jouni (Nokia-D/Tampere) Cc: Kristo Tero (Nokia-D/Tampere); [EMAIL PROTECTED]; linux-omap@vger.kernel.org Subject: Re: getnstimeofday() and suspend On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote: Using them both would also generate more complexity. What would be the benefit in using them both? The RTC should be used during suspend since it's supposed to keep track of time regardless of how long the duration of the suspension is. The 32kHz alone is not a good generic solution since it overflows after a couple of days. General problem seems to be that arch/arm has not defined read_persistent_clock() function. Attached patch tries to fix this problem by using a 32k counter hack. Probably something similar should be done which checks for overflows and uses RTC if available. -Tero 0001-Fixed-timekeeping-bug-during-suspend.patch Description: 0001-Fixed-timekeeping-bug-during-suspend.patch
getnstimeofday() and suspend
Hi, I noticed an interesting feature in the getnstimeofday() function when used with suspend. System clock is effectively reset to the value it was just before suspend. You can see this behavior e.g. with this command line: date echo mem /sys/power/state date With approx. 2 minutes in suspend state the output for me was this: / # date echo mem sys/power/state date Thu Jan 1 00:13:40 UTC 1970PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) Successfully put all powerdomains to target state Restarting tasks ... done. Thu Jan 1 00:13:42 UTC 1970 I.e., the calendar clock was only advanced 2 seconds. The time you spend in suspend does not matter, the end result is the same, it will reset the time to the value it was before suspend. Is this behavior intended? -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: getnstimeofday() and suspend
-Original Message- From: ext Tony Lindgren [mailto:[EMAIL PROTECTED] Sent: 13 August, 2008 17:00 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: getnstimeofday() and suspend * [EMAIL PROTECTED] [EMAIL PROTECTED] [080813 15:59]: Hi, I noticed an interesting feature in the getnstimeofday() function when used with suspend. System clock is effectively reset to the value it was just before suspend. You can see this behavior e.g. with this command line: date echo mem /sys/power/state date With approx. 2 minutes in suspend state the output for me was this: / # date echo mem sys/power/state date Thu Jan 1 00:13:40 UTC 1970PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) Successfully put all powerdomains to target state Restarting tasks ... done. Thu Jan 1 00:13:42 UTC 1970 I.e., the calendar clock was only advanced 2 seconds. The time you spend in suspend does not matter, the end result is the same, it will reset the time to the value it was before suspend. Is this behavior intended? Hmm, well it should get the value straight from the 32KiHZ sync timer. Does that get stopped somehow during suspend? Tony Timer is not stopped, because immediately after suspend I get correct value from it (called from wakeup interrupt), but after this it is reprogrammed by something, or either time management code gets confused somehow. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] CPU-idle trial fix + PM debug expansion
Hi,
Quick counter comments here. :P
This will leave cx-core_state to its previous value in case
of ON state. So just pwrdm_set_next_pwrst(core_pd,
cx-core_state) without if is better.
I did not really consider the logic of cpu-idle code too much, just moved
context / save functionality to omap_sram_idle. I just made suspend + dynamic
idle work.
+save_core = (pwrdm_read_next_pwrst(core_pwrdm) ==
PWRDM_POWER_OFF);
+save_per = (pwrdm_read_next_pwrst(per_pwrdm) ==
PWRDM_POWER_OFF);
Just read next states here.
I am comparing the values to PWRDM_POWER_OFF, because you will only need to
save context if you enter OFF state.
+
+if (save_core) {
+omap3_save_core_ctx();
+omap3_save_prcm_ctx();
+}
And do this if core next_st PWRDM_POWER_ON
Save is not needed if you enter PWRDM_POWER_RET.
+
+if (save_per)
+omap3_save_per_ctx();
And same here. Additionally, do this only if core next_st
PWRDM_POWER_ON.
Per domain can in theory go to OFF even if core stays on (yes, there is some
discussion about tying Core + Per because of the gpio dependencies, but we
might find something else for this.)
-omap3_save_per_ctx();
omap2_gpio_prepare_for_retention();
/* XXX This is for gpio fclk hack. Will be removed as
gpio driver
* handqles fcks correctly */
per_gpio_clk_disable();
-omap_save_uart_ctx();
+if (save_per)
+omap_save_uart_ctx();
Again, do this only if core next_st PWRDM_POWER_ON and per
next_st == PWRDM_POWER_OFF.
Same here.
+
omap_serial_enable_clocks(0);
Consider Rajendras idea to do this only if needed.
I think the idea was to access uart clocks only if we can assume that per_pwrdm
will enter ret / off? Yes good idea.
/* XXX This is for gpio fclk hack. Will be removed as
gpio driver
* handles fcks correctly */
per_gpio_clk_enable();
-omap3_restore_per_ctx();
+
+if (save_per)
+omap3_restore_per_ctx();
omap2_gpio_resume_after_retention();
Same comments to restore part as before wfi. I think you
should look at what Rajendra has done (logic in
omap3_enter_idle). You might also want to look at previous
discussion related to this. Something like this:
I have looked at this code, and I somehow consider it a bit too complicated for
the purpose. The simpler setup I have implemented in omap_sram_idle is working,
also all powerdomains have their next states set-up correctly when you reach
omap_sram_idle. Anyway, it is easy to expand the code now that it actually
works.
neon_pwrdm\n);
+if (mpu_pwrdm == NULL || neon_pwrdm == NULL ||
per_pwrdm == NULL ||
+core_pwrdm == NULL) {
+printk(KERN_ERR Failed to get pwrdm pointers\n);
Neon handling is missing.
Neon pwrdm is accessed only in the init code to make wakeup dependency from mpu
- neon. I have not tried out neon save / restore so far (just some vfp hack is
needed.)
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Added sleep support to UART
Hi,
A few minor comments based on a quick look.
In terms of the OMAP3 code, is that for retention-idle only,
or does it work with off-idle also?
That patch should basically work in off-mode also, however it requires
correct settings in the padconfig registers which are currently done in
the boot code. Also, currently I have not had any chance to actually
test this in off-mode, I am still trying to get the off-mode work on my
HW.
On Tue, 10 Jun 2008, Tero Kristo wrote:
+const u32 omap2_uart_wk_bit[OMAP_MAX_NR_PORTS] = {
+ OMAP24XX_ST_UART1, OMAP24XX_ST_UART2, OMAP24XX_ST_UART3 };
Looks like that can be static.
True.
+/* UART padconfig registers, these may differ if
non-default padconfig
+ is used */
+#define CONTROL_PADCONF_UART1_RX 0x48002182 #define
+CONTROL_PADCONF_UART2_RX 0x4800217A #define
CONTROL_PADCONF_UART3_RX
+0x4800219E #define PADCONF_WAKEUP_ST 0x8000
Please use omap_ctrl_read{b,w,l}() rather than
omap_read{b,w,l}() for SCM addresses.
Hmm yea, could do.
Also, the above are register addresses + 2. Is it possible to
use the actual register addresses (ideally they should be
defined in include/asm-arm/arch-omap/control.h), do long
reads, and simply shift the register contents for the serial
ports that need it?
These registers are currently not defined anywhere and I did not feel
like wanting to put all the padconfig register definitions somewhere
(all 200+ of them) I don't think it is currently very clear how we
want to handle these registers in general. Also, this fix is more or
less temporary anyway while we are waiting for a real driver that
handles UART clocks properly (the final solution will most likely use
some of the elements of this though.)
Also, the spec says that these registers can be accessed in either 8, 16
or 32 bit modes so why make it unnecessarily complicated and potentially
buggy with shifts (race conditions)?
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Added sleep support to UART
Hi,
I'll resend the patch in the following email. Comments below what has
been changed.
-Original Message-
From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: 10 June, 2008 09:06
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/1] Added sleep support to UART
* Tony Lindgren [EMAIL PROTECTED] [080609 22:11]:
Hi,
Sorry for the delay on looking at this, it's looking pretty good in
general. Few more mostly cosmetic comments below.
Here's one more comment:
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
if (omap2_pm_debug) {
unsigned long long tmp;
- u32 resume_time;
+ s64 resume_time;
+ struct timespec t;
- resume_time = omap2_read_32k_sync_counter();
+ getnstimeofday(t);
+ resume_time = timespec_to_ns(t);
tmp = resume_time - sleep_time;
- tmp *= 100;
- omap2_pm_dump(0, 1, tmp / 32768);
+ omap2_pm_dump(0, 1, tmp / 1000);
}
You should make all these calculations using timespec_sub():
struct timespec ts1, ts2, ts_delta;
getnstimeofday(ts1);
getnstimeofday(ts2);
ts_delta = timespec_sub(ts2, ts1);
Fixed this in several places now to use timespec_sub, timespec_add and
timespec_compare.
copy-paste from another email
+#if defined(CONFIG_ARCH_OMAP2)
+static const u32 omap_uart_fclk_mask[OMAP_MAX_NR_PORTS] = {
+OMAP24XX_EN_UART1, OMAP24XX_EN_UART2, OMAP24XX_EN_UART3 };
#endif
+
+#if defined(CONFIG_ARCH_OMAP3)
+static const u32 omap_uart_fclk_mask[OMAP_MAX_NR_PORTS] = {
+OMAP3430_EN_UART1, OMAP3430_EN_UART2, OMAP3430_EN_UART3 };
The above should be omap24xx_uart_fclk_mask and
omap34xx_uart_fclk_mask.
Otherwise we cannot compile in both 24xx and 34xx into the same kernel.
Changed. Added omap_uart_fclk_mask to point to these structures though,
initialized at boot time. Also removed those #ifdef:s from the code.
+/* UART padconfig registers, these may differ if non-default
padconfig
+ is used */
+#define CONTROL_PADCONF_UART1_RX 0x48002182 #define
+CONTROL_PADCONF_UART2_RX 0x4800217A #define CONTROL_PADCONF_UART3_RX
+0x4800219E #define PADCONF_WAKEUP_ST 0x8000
+
+static const u32 omap_uart_padconf[OMAP_MAX_NR_PORTS] = {
+CONTROL_PADCONF_UART1_RX, CONTROL_PADCONF_UART2_RX,
+CONTROL_PADCONF_UART3_RX }; #endif
This should be omap34xx_uart_padconf is only used for 34xx. Also, it's
currently not defined for 24xx and breaks build.
Changed.
+void omap_serial_check_wakeup(void)
+{
+int i;
+
+if (cpu_is_omap34xx())
+for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+if (!uart_ick[i])
+continue;
+if (omap_readw(omap_uart_padconf[i])
PADCONF_WAKEUP_ST)
+omap_serial_kick();
+return;
+}
The formatting for return above looks one tab too much to the right?
This is actually a hidden bug, that return should be part of that if
statement. Luckily enough the code worked if you had only one UART
enabled in configs. Added braces around that stuff now.
+if (cpu_is_omap24xx()) {
+u32 l;
+
+for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+if (!uart_ick[i])
+continue;
+l = prm_read_mod_reg(CORE_MOD,
omap2_uart_wk_st[i]);
+if (l omap2_uart_wk_bit[i])
+omap_serial_kick();
+return;
+}
+}
+}
Here too.
Similar bug.
+
+if (cpu_is_omap24xx())
+prm_set_mod_reg_bits(omap2_uart_wk_bit[i],
CORE_MOD,
+omap2_uart_wk_en[i]);
}
How about run the patch through checkpatch.pl, this line looks too
long?
Ok, split the code lines that caused warnings now to be multiline
statements.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Added sleep support to UART
Hi,
This patch currently depends on at least one of the PM workaround
patches from Jouni Hogander. Namely this one:
[PATCH 07/10] 34XX: PM: Workaround to check whether any fck is active
before entering sleep
Sorry I think I forgot to mention this in the patch note. Should we
change the patch in order to make this one apply cleanly (I could make a
separate patch for the UART fclk hack which depends on the above?)
-Tero
-Original Message-
From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: 31 May, 2008 02:02
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/1] Added sleep support to UART
Hi,
* Tero Kristo [EMAIL PROTECTED] [080529 06:07]:
UART usage (e.g. serial console) now denies sleep for 5
seconds. This
makes it possible to use serial console when dynamic idle is enabled.
Also moved code from pm-debug.c to serial.c, and made pm24xx.c use
this new implementation.
The changes for pm34xx.c don't currently apply, can you please
refresh this patch?
Thanks,
Tony
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm-debug.c | 132
arch/arm/mach-omap2/pm.h |8 --
arch/arm/mach-omap2/pm24xx.c | 53 ++-
arch/arm/mach-omap2/pm34xx.c |8 ++-
arch/arm/mach-omap2/serial.c | 118
include/asm-arm/arch-omap/common.h |3 +
6 files changed, 163 insertions(+), 159 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c
b/arch/arm/mach-omap2/pm-debug.c index 8a9f3c4..c20fa3b 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -34,138 +34,6 @@
#ifdef CONFIG_PM_DEBUG
int omap2_pm_debug = 0;
-static int serial_console_clock_disabled; -static int
serial_console_uart; -static unsigned int
serial_console_next_disable;
-
-static struct clk *console_iclk, *console_fclk;
-
-static void serial_console_kick(void) -{
-serial_console_next_disable = omap2_read_32k_sync_counter();
-/* Keep the clocks on for 4 secs */
-serial_console_next_disable += 4 * 32768;
-}
-
-static void serial_wait_tx(void)
-{
-static const unsigned long uart_bases[3] = {
-0x4806a000, 0x4806c000, 0x4806e000
-};
-unsigned long lsr_reg;
-int looped = 0;
-
-/* Wait for TX FIFO and THR to get empty */
-lsr_reg = IO_ADDRESS(uart_bases[serial_console_uart -
1] + (5 2));
-while ((__raw_readb(lsr_reg) 0x60) != 0x60)
-looped = 1;
-if (looped)
-serial_console_kick();
-}
-
-u32 omap2_read_32k_sync_counter(void) -{
-return omap_readl(OMAP2_32KSYNCT_BASE + 0x0010);
-}
-
-void serial_console_fclk_mask(u32 *f1, u32 *f2) -{
-switch (serial_console_uart) {
-case 1:
-*f1 = ~(1 21);
-break;
-case 2:
-*f1 = ~(1 22);
-break;
-case 3:
-*f2 = ~(1 2);
-break;
-}
-}
-
-void serial_console_sleep(int enable) -{
-if (console_iclk == NULL || console_fclk == NULL)
-return;
-
-if (enable) {
-BUG_ON(serial_console_clock_disabled);
-if (clk_get_usecount(console_fclk) == 0)
-return;
-if ((int) serial_console_next_disable - (int)
omap2_read_32k_sync_counter() = 0)
-return;
-serial_wait_tx();
-clk_disable(console_iclk);
-clk_disable(console_fclk);
-serial_console_clock_disabled = 1;
-} else {
-int serial_wakeup = 0;
-u32 l;
-
-switch (serial_console_uart) {
-case 1:
-l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
-if (l OMAP24XX_ST_UART1)
-serial_wakeup = 1;
-break;
-case 2:
-l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
-if (l OMAP24XX_ST_UART2)
-serial_wakeup = 1;
-break;
-case 3:
-l = prm_read_mod_reg(CORE_MOD,
OMAP24XX_PM_WKST2);
-if (l OMAP24XX_ST_UART3)
-serial_wakeup = 1;
-break;
-}
-if (serial_wakeup)
-serial_console_kick();
-if (!serial_console_clock_disabled)
-return;
-clk_enable(console_iclk);
-clk_enable(console_fclk);
-serial_console_clock_disabled = 0;
-}
-}
-
-void pm_init_serial_console(void)
-{
-const struct omap_serial_console_config *conf;
-char name[16];
-
-conf = omap_get_config(OMAP_TAG_SERIAL_CONSOLE,
- struct omap_serial_console_config);
-if (conf == NULL)
-return;
-if
