Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
Hello Rajendra,
here are a few more comments on the CPUIdle patch set. Many of these, we
discussed today. A closer look at patch 11/11 reveals that it will need
some additional attention.
- Paul
General
---
1. Please separate the context save/restore patches from the CPUIdle
patches, and submit the context save/restore patches as an initial
patchset, then the CPUIdle patches as a second set.
2. Also, split the cache associativity changes to
arch/arm/mach-omap2/sleep34xx.S into a separate patch, and give it a
descriptive commit message to help readers understand what is changing
here.
Comments on the context save/restore patches
3. On the patch 5/11 scratchpad contents, please save/restore the
scratchpad registers into a structure with descriptively-named fields
rather than simply incrementing a pointer across a buffer. This will
document the layout of the scratchpad area and make this code easier to
verify.
4. Also on the same patch, move the clear_scratchpad_contents() and
save_scratchpad_contents() to mach-omap2/control.c. Please rename these
functions to omap3_clear_scratchpad_contents() and
omap3_save_scratchpad_contents().
5. On patch 11/11 CORE context save/restore, please use a structure with
descriptively-named fields in place of prcm_sleep_save, as was done for
the intc_context and control_ctx structures in the same patch, and
similar to comment #3 above.
6. Also on the same patch, this patch should be split into several smaller
patches. The PRCM, INTC, SRAM, and SCM save/restore functions should all
be split into separate patches. Please cc Paul Mundt
[EMAIL PROTECTED] on the INTC patch. Also please split the serial
driver clock control patch into a separate patch.
7. In the new PRCM save/restore patch, please move omap3_save_prcm_ctx()
and omap3_restore_prcm_ctx() to mach-omap2/prcm.c.
8. In the new IRQ save/restore patch, please move omap_save_intc_ctx() and
omap_restore_intc_ctx() to mach-omap2/irq.c.
9. In the new SCM save/restore patch, please move omap_save_control_ctx()
and omap_restore_control_ctx() to mach-omap2/control.c.
10. In the following changes to omap3_pm_init() in pm34xx.c hunk:
+ pwrdm_add_wkdep(neon_pwrdm, mpu_pwrdm);
+ pwrdm_add_wkdep(per_pwrdm, core_pwrdm);
+
please add a comment between the two pwrdm_add_wkdep() functions, reading
something similar to:
/*
* REVISIT: This wkdep is only necessary when GPIO2-6 are enabled for
* IO-pad wakeup. Otherwise it will unnecessarily waste power
* waking up PER with every CORE wakeup - see
* http://marc.info/?l=linux-omapm=121852150710062w=2
*/
11. In omap_(save|restore)_intc_ctx(), please use
intc_bank_(read|write)_reg() instead of __omap_readl/writel().
12. In omap_save_core_context(), please use descriptive preprocessor
macros for the constants in these two lines, so someone reading the code
can clearly see what bits are being used without having to consult the
TRM:
+ control_padconf_off |= 2;
...
+ while (!omap_readl(CONTROL_GENERAL_PURPOSE_STATUS) 0x1);
13. Similarly, in the new serial driver patch, please use descriptive
preprocessor macros for the constants in lines like these:
+ tmp = (serial_in(up, UART_OMAP_SYSC) 0x7) | (1 3);
14. In omap3_enter_idle_bm(), the first branch of this conditional needs
to have braces around it per CodingStyle chapter 2.
+ if (dev-safe_state)
+ return dev-safe_state-enter(dev, dev-safe_state);
+ else {
15. All of these constants from cpuidle34xx.h should be moved into
driver-specific files as implied by comments #7-9 above. You should be
able to delete many of them, since they already exist. But whichever
constants remain (if any) should be expressed as register offsets from the
OMAP device base address, not absolute addresses:
+/* Interrupt Controller registers */
+#define INTC_BASE 0x4820
+#define INTC_MIR_0 0x48200084
+#define INTC_MIR_1 0x482000A4
+#define INTC_MIR_2 0x482000C4
+#define INTCPS_SYSCONFIG 0x48200010
+#define INTCPS_PROTECTION 0x4820004C
+#define INTCPS_IDLE0x48200050
+#define INTCPS_THRESHOLD 0x48200068
+
+#define CONTROL_PADCONF_SYS_NIRQ 0x480021E0
+#define CONTROL_PADCONF_OFF0x48002270
+#define CONTROL_GENERAL_PURPOSE_STATUS 0x480022F4
+
+#define OMAP34XX_GPIO1_IRQENABLE1 0x4831001c
+#define OMAP34XX_GPIO1_WAKEUPEN0x48310020
+#define OMAP34XX_GPIO1_FALLINGDETECT 0x4831004c
Comments on the CPUIdle patches
---
16. Please drop the generic drivers/cpuidle/Kconfig patch from this set,
since it will affect other trees, and send it upstream separately to
linux-pm, lkml, and cc Venkatesh Pallipadi [EMAIL PROTECTED]
and Len Brown [EMAIL PROTECTED] for them to merge.
17. As we discussed, there are some drivers which don't work yet with OFF
mode unless unmergeable
RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
Serial and gpio clock disabling and gpio_prepare/resume can
be removed
from omap3_pm_idle because they are already done in omap_sram_idle.
And if omap_serial_can_sleep is removed from
omap3_can_sleep it should
be added to omap3_pm_idle.
Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE:
+#ifndef CONFIG_CPU_IDLE
static void omap3_pm_idle(void)
{
local_irq_disable();
@@ -454,33 +455,16 @@ static void omap3_pm_idle(void)
if (omap_irq_pending())
goto out;
- omap2_gpio_prepare_for_retention();
-
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(0, 0);
- omap_serial_enable_clocks(0, 1);
- omap_serial_enable_clocks(0, 2);
- /* XXX This is for gpio fclk hack. Will be
removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_disable();
- }
+ if (!omap_serial_can_sleep())
+ goto out;
omap_sram_idle();
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(1, 0);
- omap_serial_enable_clocks(1, 1);
- omap_serial_enable_clocks(1, 2);
- /* XXX This is for gpio fclk hack. Will be
removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_enable();
- }
-
- omap2_gpio_resume_after_retention();
out:
local_fiq_enable();
local_irq_enable();
}
+#endif /* CONFIG_CPU_IDLE */
These are also done as part of the last patch in the series.
Ok.. so I misunderstood your comment initially, I confused omap3_pm_idle with
the
omap3_enter_idle and thought this was already done.
Yes, these can be now removed.
--
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 00/11] OMAP3 CPUidle patches - ver 2
ext Rajendra Nayak [EMAIL PROTECTED] writes:
Check wether serial can sleep is missing from
omap3_enter_idle and it should be removed from omap3_can_sleep:
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index a02da6d..16ff30b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -431,7 +431,7 @@ static int omap3_enter_idle(struct
cpuidle_device *dev,
current_cx_state = *cx;
- if (cx-type == OMAP3_STATE_C0) {
+ if (cx-type == OMAP3_STATE_C0 || !omap_serial_can_sleep()) {
/* Do nothing for C0, not even a wfi */
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..f9b3676 100644
@@ -391,8 +391,6 @@ int omap3_can_sleep(void)
return 0;
if (atomic_read(sleep_block) 0)
return 0;
- if (!omap_serial_can_sleep())
- return 0;
return 1;
}
Doing this would make serial console to work faster.
Yes, I removed these in my patches and put in the changes suggested by Richard
in 8250.c
I doubt that your changes to 8250.c will be applied. I have understood
that omap specific changes are not accepted to generic 8250
driver. Anyway these changes doesn't help too much. Serial console is
annoyingly slow if sleep while idle is enabled.
I thought the final conclusion of the discussion was that it was too
expensive to the keep the
system in C0 all the time while UART inactivity runs, or did I miss
something?
This was misunderstanding. C0 is selected only for 5 seconds after
last activity on serial console rx line. After this 5 second sleep
prevention, cpuidle continues state selection normally. I don't see
this too expensive, what do you think?
_omap_sram_idle should be non-static:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..133a666 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -60,7 +60,7 @@ u32 restore_pointer_address;
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
+void (*_omap_sram_idle)(u32 *addr, int save_state);
static void (*saved_idle)(void);
I thought this is already part of the patches. It is now non-static.
Ok, I might have done something wrong with your patches.
Serial and gpio clock disabling and gpio_prepare/resume can
be removed from omap3_pm_idle because they are already done
in omap_sram_idle. And if omap_serial_can_sleep is removed
from omap3_can_sleep it should be added to omap3_pm_idle.
Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE:
+#ifndef CONFIG_CPU_IDLE
static void omap3_pm_idle(void)
{
local_irq_disable();
@@ -454,33 +455,16 @@ static void omap3_pm_idle(void)
if (omap_irq_pending())
goto out;
- omap2_gpio_prepare_for_retention();
-
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(0, 0);
- omap_serial_enable_clocks(0, 1);
- omap_serial_enable_clocks(0, 2);
- /* XXX This is for gpio fclk hack. Will be removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_disable();
- }
+ if (!omap_serial_can_sleep())
+ goto out;
omap_sram_idle();
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(1, 0);
- omap_serial_enable_clocks(1, 1);
- omap_serial_enable_clocks(1, 2);
- /* XXX This is for gpio fclk hack. Will be removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_enable();
- }
-
- omap2_gpio_resume_after_retention();
out:
local_fiq_enable();
local_irq_enable();
}
+#endif /* CONFIG_CPU_IDLE */
These are also done as part of the last patch in the series.
I already noticed your second reply.
I would like to see also some reformatting. E.g. patch 11
contains lots of code which is not related to CORE context
save/restore. It might be also good idea to enable only
non-off mode C states and have a pwrdms_setup function which
is something like this:
static int __init pwrdms_setup(struct powerdomain *pwrdm) {
struct power_state *pwrst;
if (!pwrdm-pwrsts)
return 0;
pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL);
if (!pwrst)
return -ENOMEM;
pwrst-pwrdm = pwrdm;
pwrst-next_state = PWRDM_POWER_RET;
list_add(pwrst-node, pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
pwrdm_enable_hdwr_sar(pwrdm);
#ifdef CONFIG_CPU_IDLE
/* Let cpuidle do selection here */
if (!strcmp(pwrst-pwrdm-name, core_pwrdm) ||
!strcmp(pwrst-pwrdm-name, mpu_pwrdm) ||
RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
Doing this would make serial console to work faster.
Yes, I removed these in my patches and put in the changes suggested by
Richard
in 8250.c
I doubt that your changes to 8250.c will be applied. I have understood
that omap specific changes are not accepted to generic 8250
driver. Anyway these changes doesn't help too much. Serial console is
annoyingly slow if sleep while idle is enabled.
Rajendra is it slow in your current builds on this tree with fixes in place?
Sluggish serial has NOT been an issue for us in other trees for a long time.
Perhaps something is missing.
In general keeping code out of the C0 path is good. What ever method makes
console serial usable and gets out of the way fastest to get better power
measurements in typical test environment is good.
Is the comment on the smart idle / no idle aspect or the whole path?
It probably is easier to put changes in our local cpu_idle-C0 function as
compared to a shared 8250 driver. But if it means adding extra code on a hot
system path it is less appealing.
If it's working here, we can ask what opinions are on ARM-Linux list. Today
there are other UART instance specific work arounds in that code.
Regards,
Richard W.
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
Hi Richard, ext Woodruff, Richard [EMAIL PROTECTED] writes: Doing this would make serial console to work faster. Yes, I removed these in my patches and put in the changes suggested by Richard in 8250.c I doubt that your changes to 8250.c will be applied. I have understood that omap specific changes are not accepted to generic 8250 driver. Anyway these changes doesn't help too much. Serial console is annoyingly slow if sleep while idle is enabled. Rajendra is it slow in your current builds on this tree with fixes in place? Sluggish serial has NOT been an issue for us in other trees for a long time. Perhaps something is missing. Why this is not problem in your trees is probably because you have similiar hack in place. At least in your CDP tree you have 6 second timeout after activity in serial console. While this timeout is on only mpu is allowed to enter sleep state. After this timeout C state selection continues normally. I agree that this is slightly better, but still not providing realistic PM for testing. PER and CORE sleep transitions are still prevented. I think we must remember that serial console is a debug interface. If doing some PM testing, it is not too big task to wait for 5 seconds before starting the test/measurement. In general keeping code out of the C0 path is good. What ever method makes console serial usable and gets out of the way fastest to get better power measurements in typical test environment is good. Is the comment on the smart idle / no idle aspect or the whole path? My comment was on the changes made to 8250 driver (smart idle / no idle). It probably is easier to put changes in our local cpu_idle-C0 function as compared to a shared 8250 driver. But if it means adding extra code on a hot system path it is less appealing. If it's working here, we can ask what opinions are on ARM-Linux list. Today there are other UART instance specific work arounds in that code. Ok, it would be great to get such code to 8250 driver. Regards, Richard W. -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches - ver 2
-Original Message- From: Woodruff, Richard [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2008 6:06 PM To: Högander Jouni; Nayak, Rajendra Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 Doing this would make serial console to work faster. Yes, I removed these in my patches and put in the changes suggested by Richard in 8250.c I doubt that your changes to 8250.c will be applied. I have understood that omap specific changes are not accepted to generic 8250 driver. Anyway these changes doesn't help too much. Serial console is annoyingly slow if sleep while idle is enabled. Rajendra is it slow in your current builds on this tree with fixes in place? Sluggish serial has NOT been an issue for us in other trees for a long time. Perhaps something is missing. Yes, its indeed a bit sluggish in my builds as well. Not as good as what we have in our internal tree. In general keeping code out of the C0 path is good. What ever method makes console serial usable and gets out of the way fastest to get better power measurements in typical test environment is good. Is the comment on the smart idle / no idle aspect or the whole path? It probably is easier to put changes in our local cpu_idle-C0 function as compared to a shared 8250 driver. But if it means adding extra code on a hot system path it is less appealing. If it's working here, we can ask what opinions are on ARM-Linux list. Today there are other UART instance specific work arounds in that code. Regards, Richard W. -- 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 00/11] OMAP3 CPUidle patches - ver 2
Check wether serial can sleep is missing from
omap3_enter_idle and it should be removed from omap3_can_sleep:
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index a02da6d..16ff30b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -431,7 +431,7 @@ static int omap3_enter_idle(struct
cpuidle_device *dev,
current_cx_state = *cx;
- if (cx-type == OMAP3_STATE_C0) {
+ if (cx-type == OMAP3_STATE_C0 || !omap_serial_can_sleep()) {
/* Do nothing for C0, not even a wfi */
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..f9b3676 100644
@@ -391,8 +391,6 @@ int omap3_can_sleep(void)
return 0;
if (atomic_read(sleep_block) 0)
return 0;
- if (!omap_serial_can_sleep())
- return 0;
return 1;
}
Doing this would make serial console to work faster.
Yes, I removed these in my patches and put in the changes suggested by Richard
in 8250.c
I thought the final conclusion of the discussion was that it was too expensive
to the keep the
system in C0 all the time while UART inactivity runs, or did I miss something?
_omap_sram_idle should be non-static:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..133a666 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -60,7 +60,7 @@ u32 restore_pointer_address;
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
+void (*_omap_sram_idle)(u32 *addr, int save_state);
static void (*saved_idle)(void);
I thought this is already part of the patches. It is now non-static.
Serial and gpio clock disabling and gpio_prepare/resume can
be removed from omap3_pm_idle because they are already done
in omap_sram_idle. And if omap_serial_can_sleep is removed
from omap3_can_sleep it should be added to omap3_pm_idle.
Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE:
+#ifndef CONFIG_CPU_IDLE
static void omap3_pm_idle(void)
{
local_irq_disable();
@@ -454,33 +455,16 @@ static void omap3_pm_idle(void)
if (omap_irq_pending())
goto out;
- omap2_gpio_prepare_for_retention();
-
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(0, 0);
- omap_serial_enable_clocks(0, 1);
- omap_serial_enable_clocks(0, 2);
- /* XXX This is for gpio fclk hack. Will be removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_disable();
- }
+ if (!omap_serial_can_sleep())
+ goto out;
omap_sram_idle();
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(1, 0);
- omap_serial_enable_clocks(1, 1);
- omap_serial_enable_clocks(1, 2);
- /* XXX This is for gpio fclk hack. Will be removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_enable();
- }
-
- omap2_gpio_resume_after_retention();
out:
local_fiq_enable();
local_irq_enable();
}
+#endif /* CONFIG_CPU_IDLE */
These are also done as part of the last patch in the series.
I would like to see also some reformatting. E.g. patch 11
contains lots of code which is not related to CORE context
save/restore. It might be also good idea to enable only
non-off mode C states and have a pwrdms_setup function which
is something like this:
static int __init pwrdms_setup(struct powerdomain *pwrdm) {
struct power_state *pwrst;
if (!pwrdm-pwrsts)
return 0;
pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL);
if (!pwrst)
return -ENOMEM;
pwrst-pwrdm = pwrdm;
pwrst-next_state = PWRDM_POWER_RET;
list_add(pwrst-node, pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
pwrdm_enable_hdwr_sar(pwrdm);
#ifdef CONFIG_CPU_IDLE
/* Let cpuidle do selection here */
if (!strcmp(pwrst-pwrdm-name, core_pwrdm) ||
!strcmp(pwrst-pwrdm-name, mpu_pwrdm) ||
!strcmp(pwrst-pwrdm-name, neon_pwrdm))
return set_pwrdm_state(pwrst-pwrdm, PWRDM_POWER_ON);
else
#endif
return set_pwrdm_state(pwrst-pwrdm,
pwrst-next_state); }
This way cpuidle code would be in a state that it could be
applied on linux-omap tree and it wouldn't break anything.
Then have e.g. separate patch for testing off state. This
patch could modify code to set next states to off and mark
off mode C states as a valid.
Yes, will do that. Maybe the couple of comments above are also due to
the last patch doing a lot more than it actually should.
Hi,
I am
Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
On ke, 2008-08-06 at 18:42 +0530, ext Rajendra Nayak wrote: Hi, Re-posting a refreshed version of these patches. I'm getting this error when trying to apply these patches with 'git-am' command: $ git-am ~/.evolution/mail/local/stage Applying Basic cpuidle driver fatal: patch fragment without header at line 13: @@ -0,0 +1,245 @@ Patch failed at 0001. with manual patch -p 1 .dotest/0001 they apply nicely, but it is very time-consuming to do it manually for each patch. Do you use normal git-format-patch and git-send-email to format and post the patches? Br, Kalle regards Rajendra Hi, I am sending an updated patch set for CPUidle which includes all fixes/comments posted on the previous set by Jouni/Richard W/Peter and others. The Following are the fixes 1) Uart clock enable/disable moved out of the context save/restore patch 2) GPIO IRQENABLE save/restore fix from Richard 3) Fixes from Jouni which do the following 1. Add wkdep between neon and mpu 2. Add wkdep between per and core 3. Deny hwsup mode before writing next pwrst state 4. Make sure that order in idle loop is such that clocks are _really_ enabled before accessing registers (serial gpio). 4) Safe state idle fix from Richard 5) Uart smart-force fix from Richard 6) Toggle IO-PAD enable/disable in idle As earlier these patches apply on top of Jouni's workaround patch set ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) The following is neccessay even with a minimal config to achieve OFF. $ echo 1 /sys/power/sleep_while_idle $ echo 1 /sys/power/clocks_off_while_idle regards, Rajendra -- 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 00/11] OMAP3 CPUidle patches
Did some idle measurements with these.. VDD1 : 2.0 mA VDD2 : 2.3 mA The numbers are on the higher side as the thresholds are still not optimal. Currently C6 has a threshold set to 300 ms which seems to be very low. We are working on deriving the optimal thresholds for each C state. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajendra Nayak Sent: Tuesday, July 01, 2008 7:46 PM To: linux-omap@vger.kernel.org Subject: [PATCH 00/11] OMAP3 CPUidle patches Hi, The following patches define and enable all of the below mentioned C states for OMAP3. These are tested with a minimal kernel config on OMAP3430sdp as most drivers today don't have context save/restore in place and some even lack aggresive clock handling. These apply on top of the workaround patch set submitted by Jouni. ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) The following is neccessay even with a minimal config to achieve OFF. $ echo 1 /sys/power/sleep_while_idle $ echo 1 /sys/power/clocks_off_while_idle The following C states are defined C0 - System executing code C1 - MPU WFI + Core active C2 - MPU CSWR + Core active C3 - MPU OFF + Core active C4 - MPU CSWR + Core CSWR C5 - MPU OFF + Core CSWR C6 - MPU OFF + Core OFF regards, Rajendra -- 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 00/11] OMAP3 CPUidle patches
ext Woodruff, Richard [EMAIL PROTECTED] writes: [x] Has anyone fixed the broken gpio wakeup enable code? Right now this might even kill you as it will clear you wakeup enable register. This could stop you from waking from a partially idle/clock stop condition on the L3? The problem was actually related to this. There is those gpio_prepare_* and gpio_resume_* functions which were not run. For some reason next_state for powerdomains doesn't update correctly before hw_sup mode is disabled. This caused problem that cpuidle thinks that core is entering ON state, while it was actually entering state written in omap3_pm_init. Now as cpuidle was thinking that core is not entering any sleep state it didn't run gpio_prepare_* and gpio_resume_* functions. This caused that interrupt was not generated for that gpio used by eth chip. This was fixed in my patches by disabling hw_sup mode before writing next_state and then re-enable it. Those patches are also writing next state if CORE next state is ON. Ok. As I sent in my mail a couple weeks back. The clearing of wakeup events at GPIOs when the CORE hits INACTIVE might result in windows of you not waking up, especially with dynamic tick in the system. I would guess the windows would be around boot suspend resume. It is not so clear if gpio that hack is even needed on OMAP3. There is some warning about spurious interrupts when going to RET/OFF for OMAP2. I don't recall for OMAP3. didn't those prepare functions dink with wake up masks in fear of spurious interrupts. So, wasn't the result for you the opposite, it kept you from waking, instead of suppressing extra wakes? Did you fix the OMAP2 GPIO wakeup mask in use at least? The code had a hardcoded mask based on OMAP2 wakeup capable gpios which don't apply to omap3. No I haven't modified that code. I have begun to use it before retention because it is under #if defined(CONFIG_ARCH_OMAP34XX) statement and used in case of omap2. Maybe we could stop using it in case of omap3 at least this comment in gpio.c supports this: See OMAP2420 Errata item 1.101? Seems to be just legacy code from omap2. -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches
It is not so clear if gpio that hack is even needed on OMAP3. There is some warning about spurious interrupts when going to RET/OFF for OMAP2. I don't recall for OMAP3. didn't those prepare functions dink with wake up masks in fear of spurious interrupts. So, wasn't the result for you the opposite, it kept you from waking, instead of suppressing extra wakes? Did you fix the OMAP2 GPIO wakeup mask in use at least? The code had a hardcoded mask based on OMAP2 wakeup capable gpios which don't apply to omap3. No I haven't modified that code. I have begun to use it before retention because it is under #if defined(CONFIG_ARCH_OMAP34XX) statement and used in case of omap2. Maybe we could stop using it in case of omap3 at least this comment in gpio.c supports this: See OMAP2420 Errata item 1.101? Seems to be just legacy code from omap2. Yes, that section needs to be reworked. It was probably the root cause of your failure. Regards, Richard W.
Re: [PATCH 00/11] OMAP3 CPUidle patches
ext Woodruff, Richard [EMAIL PROTECTED] writes: I am still trying to find my way thru the codebase in GIT; but here is what I can suggest based on similar problem diagnosed (still under test) on the OMAP3EVM: 1) Save/restore the GPIO_IRQENABLE1, GPIO_IRQENABLE2 2) Save/restore the GPIO_IRQSTATUS1, GPIO_IRQSTATUS2 For sure save/restore of IRQENABLE is needed. Our Labrador board which has Ethernet on per-gpio would stop to function after an OFF mode transition with out this save and restore (using CDP reference code). I think this is not related to OFF mode, because OFF state is not used on the boot. This problem seems to disappear when boot is done and C6 state is started to be used. Currently it seems to me that this problem exists if using states where mpu is in sleep state and core is active (C2, C3). This is under investigation. Is there any known restrictions in GPIO1 module wake-up capability when mpu is in sleep and core active? Any other known restrictions? I don't think STATUS is necessary. It’s a write 1 to clear register and should re-latch once there is data. As a side note I was noting that the SMC9211 etherchip actually may need a dvfs pre-post notifier. During DVFS spurious interrupt events cause the interface to disable interrupts on its own on some tests. Regards, Richard W. -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches
ext Woodruff, Richard [EMAIL PROTECTED] writes: For sure save/restore of IRQENABLE is needed. Our Labrador board which has Ethernet on per-gpio would stop to function after an OFF mode transition with out this save and restore (using CDP reference code). I think this is not related to OFF mode, because OFF state is not used on the boot. This problem seems to disappear when boot is done and C6 state is started to be used. Currently it seems to me that this problem exists if using states where mpu is in sleep state and core is active (C2, C3). This is under investigation. Is there any known restrictions in GPIO1 module wake-up capability when mpu is in sleep and core active? Any other known restrictions? If core is ACTIVE and irq is enabled at MPU then everything should work on any gpio block. If the core is INACTIVE (which is possible with hardware auto's on) then the same holds from above IF you have also enabled all wakeup mechanisms. If the core is in RET/OFF only selected gpio's will wake the system up. IIRC not all GPIO1 even are capable to wake you from this level of sleep. I don't recall the list. You do have the ability to use an IO PAD wake up to wake from those while in RET/OFF. However, I don't believe you will get an IO pad when you in INACTIVE/ACTIVE. You do have to program for this event to be generated at the pad and in the wakeup domain control registers. Questions might be: - Has the prcm init happened and is the entire wake up path been setup? [x] Has anyone fixed the broken gpio wakeup enable code? Right now this might even kill you as it will clear you wakeup enable register. This could stop you from waking from a partially idle/clock stop condition on the L3? The problem was actually related to this. There is those gpio_prepare_* and gpio_resume_* functions which were not run. For some reason next_state for powerdomains doesn't update correctly before hw_sup mode is disabled. This caused problem that cpuidle thinks that core is entering ON state, while it was actually entering state written in omap3_pm_init. Now as cpuidle was thinking that core is not entering any sleep state it didn't run gpio_prepare_* and gpio_resume_* functions. This caused that interrupt was not generated for that gpio used by eth chip. This was fixed in my patches by disabling hw_sup mode before writing next_state and then re-enable it. Those patches are also writing next state if CORE next state is ON. Regards, Richard W. -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches
[x] Has anyone fixed the broken gpio wakeup enable code? Right now this might even kill you as it will clear you wakeup enable register. This could stop you from waking from a partially idle/clock stop condition on the L3? The problem was actually related to this. There is those gpio_prepare_* and gpio_resume_* functions which were not run. For some reason next_state for powerdomains doesn't update correctly before hw_sup mode is disabled. This caused problem that cpuidle thinks that core is entering ON state, while it was actually entering state written in omap3_pm_init. Now as cpuidle was thinking that core is not entering any sleep state it didn't run gpio_prepare_* and gpio_resume_* functions. This caused that interrupt was not generated for that gpio used by eth chip. This was fixed in my patches by disabling hw_sup mode before writing next_state and then re-enable it. Those patches are also writing next state if CORE next state is ON. Ok. As I sent in my mail a couple weeks back. The clearing of wakeup events at GPIOs when the CORE hits INACTIVE might result in windows of you not waking up, especially with dynamic tick in the system. I would guess the windows would be around boot suspend resume. It is not so clear if gpio that hack is even needed on OMAP3. There is some warning about spurious interrupts when going to RET/OFF for OMAP2. I don't recall for OMAP3. didn't those prepare functions dink with wake up masks in fear of spurious interrupts. So, wasn't the result for you the opposite, it kept you from waking, instead of suppressing extra wakes? Did you fix the OMAP2 GPIO wakeup mask in use at least? The code had a hardcoded mask based on OMAP2 wakeup capable gpios which don't apply to omap3. Regards, Richard W.
RE: [PATCH 00/11] OMAP3 CPUidle patches
On pe, 2008-07-04 at 15:15 +0530, ext Rajendra Nayak wrote: ... ext Högander Jouni [EMAIL PROTECTED] writes: ... So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. Jouni had a theory that the ethernet device could cause this slowness trouble in the startup, so I investigated the matter a little further. By enabling the debug prints in the ethernet chip driver, diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c index 776c81d..7d1eead 100644 --- a/drivers/net/smc91x.c +++ b/drivers/net/smc91x.c @@ -62,7 +62,7 @@ static const char version[] = /* Debugging level */ #ifndef SMC_DEBUG -#define SMC_DEBUG 0 +#define SMC_DEBUG 1 #endif I was able to see, that we get lots of RX overrun interrupts with cpu_idle, meaning that incoming stuff is not getting processed. By generating UART interrupts, I we probably can also catch more network RX interrupts and this helps the bootup go faster. With cpu_idle disabled, there were no RX overruns. I'll try to see if this can be fixed somehow. eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. My setup does not seem to go beyond C2 state, btw. So I'll need to debug that also a bit. The above-mentioned patches are applied. Br, Kalle ... -- 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 00/11] OMAP3 CPUidle patches
Kalle Jokiniemi [EMAIL PROTECTED] writes: On pe, 2008-07-04 at 15:15 +0530, ext Rajendra Nayak wrote: ... ext Högander Jouni [EMAIL PROTECTED] writes: ... So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. Jouni had a theory that the ethernet device could cause this slowness trouble in the startup, so I investigated the matter a little further. By enabling the debug prints in the ethernet chip driver, diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c index 776c81d..7d1eead 100644 --- a/drivers/net/smc91x.c +++ b/drivers/net/smc91x.c @@ -62,7 +62,7 @@ static const char version[] = /* Debugging level */ #ifndef SMC_DEBUG -#define SMC_DEBUG 0 +#define SMC_DEBUG 1 #endif I was able to see, that we get lots of RX overrun interrupts with cpu_idle, meaning that incoming stuff is not getting processed. By generating UART interrupts, I we probably can also catch more network RX interrupts and this helps the bootup go faster. With cpu_idle disabled, there were no RX overruns. Your investigation supports this theory. Interrupt line from eth chip doesn't wake up mpu. I assume it is gpio line. Those are added to mpu wake-up events group, gpio wake-ups are enabled and mpu peripherals group wake-up event interrupt is enabled. I'm suspecting that this problem happens if state where mpu is in sleep state and core+per are awake is used. Any comments from TI people what might be wrong? I'll try to see if this can be fixed somehow. eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. My setup does not seem to go beyond C2 state, btw. So I'll need to debug that also a bit. The above-mentioned patches are applied. Br, Kalle ... -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches
I am still trying to find my way thru the codebase in GIT; but here is what I
can suggest based on similar problem diagnosed (still under test) on the
OMAP3EVM:
1) Save/restore the GPIO_IRQENABLE1, GPIO_IRQENABLE2
2) Save/restore the GPIO_IRQSTATUS1, GPIO_IRQSTATUS2
This needs to be done before entering (or leaving) deeper C-states.
Hope this helps.
Best regards,
Sanjeev
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Högander Jouni
Sent: Monday, July 07, 2008 3:27 PM
To: Kalle Jokiniemi
Cc: Nayak, Rajendra; 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org
Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches
Kalle Jokiniemi [EMAIL PROTECTED] writes:
On pe, 2008-07-04 at 15:15 +0530, ext Rajendra Nayak wrote:
...
ext Högander Jouni [EMAIL PROTECTED] writes:
...
So Rajendra sent his uImage and it works quite ok what comes to off
mode on my sdp board. I still see problems with serial console
(slow) and on boot I need to generate manually interrupts to get it
to boot. Otherwise board hangs at this point:
Yes, I noticed this as well. It takes quite long to bootup if you
don't generate UART interrupts.
After bootup once RET/OFF is hit, it takes a few hits to come out of
it as IO wakeup is missing.
Jouni had a theory that the ethernet device could cause this slowness
trouble in the startup, so I investigated the matter a little further.
By enabling the debug prints in the ethernet chip driver,
diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c index
776c81d..7d1eead 100644
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -62,7 +62,7 @@ static const char version[] =
/* Debugging level */
#ifndef SMC_DEBUG
-#define SMC_DEBUG 0
+#define SMC_DEBUG 1
#endif
I was able to see, that we get lots of RX overrun interrupts with
cpu_idle, meaning that incoming stuff is not getting processed. By
generating UART interrupts, I we probably can also catch more network
RX interrupts and this helps the bootup go faster. With cpu_idle
disabled, there were no RX overruns.
Your investigation supports this theory. Interrupt line from eth chip doesn't
wake up mpu. I assume it is gpio line. Those are added to mpu wake-up events
group, gpio wake-ups are enabled and mpu peripherals group wake-up event
interrupt is enabled.
I'm suspecting that this problem happens if state where mpu is in sleep state
and core+per are awake is used.
Any comments from TI people what might be wrong?
I'll try to see if this can be fixed somehow.
eth0: link up
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is
192.168.2.101
IP-Config: Complete:
device=eth0, addr=192.168.2.101, mask=255.255.255.0,
gw=192.168.2.1,
host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none),
bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath=
Looking up port of RPC 13/2 on 172.22.146.197 Looking up port
of RPC 15/1 on 172.22.146.197
VFS: Mounted root (nfs filesystem).
Freeing init memory: 108K
Rajendra, are you still using .config file you sent to me? Are all
the changes in your tree available in l-o list.
Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I
sent.
To debug further, can you put a few prints in omap3_enter_idle and
omap3_enter_idle_bm to see what states are selected by the menu gov.
We will then know if CORE RET/OFF is attempted but not achieved due
to some reason, or never attempted altogether.
My setup does not seem to go beyond C2 state, btw. So I'll need to
debug that also a bit. The above-mentioned patches are applied.
Br, Kalle
...
--
Jouni Högander
--
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
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 00/11] OMAP3 CPUidle patches
I am still trying to find my way thru the codebase in GIT; but here is what I can suggest based on similar problem diagnosed (still under test) on the OMAP3EVM: 1) Save/restore the GPIO_IRQENABLE1, GPIO_IRQENABLE2 2) Save/restore the GPIO_IRQSTATUS1, GPIO_IRQSTATUS2 For sure save/restore of IRQENABLE is needed. Our Labrador board which has Ethernet on per-gpio would stop to function after an OFF mode transition with out this save and restore (using CDP reference code). I don't think STATUS is necessary. It’s a write 1 to clear register and should re-latch once there is data. As a side note I was noting that the SMC9211 etherchip actually may need a dvfs pre-post notifier. During DVFS spurious interrupt events cause the interface to disable interrupts on its own on some tests. Regards, Richard W.
Re: [PATCH 00/11] OMAP3 CPUidle patches
Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? Cheers, Peter. -- 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 -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches
Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni [EMAIL PROTECTED] writes: Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Cheers, Peter. -- 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 -- Jouni Högander -- 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 -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches
-Original Message- From: Högander Jouni [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2008 3:02 PM To: ext Rajendra Nayak Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni [EMAIL PROTECTED] writes: Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. Cheers, Peter. -- 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 -- Jouni Högander -- 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 -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches
ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Högander Jouni [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2008 3:02 PM To: ext Rajendra Nayak Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni [EMAIL PROTECTED] writes: Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. Can you try to disable C2 state. I noticed that this state is used all the time at the point on boot where board hangs. I tried to disable and after this boot worked ok. With my image I couldn't achieve off state. eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. Ok, will send my results soon. -- Jouni Högander -- 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 00/11] OMAP3 CPUidle patches
So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. I tried the same uImage here on my SDP. It goes to off nicely after bootup, but after using the console, VDD2 does not to off anymore. VDD1 does go to off. Cheers, Peter. -- 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 00/11] OMAP3 CPUidle patches
ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Högander Jouni [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2008 3:02 PM To: ext Rajendra Nayak Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni [EMAIL PROTECTED] writes: Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. It seems that I get off state also with my own binary: diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 6440515..545ce99 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -447,7 +447,9 @@ static int omap3_enter_idle(struct cpuidle_device *dev, if (cx-type OMAP3_STATE_C1) sched_clock_idle_sleep_event(); /* about to enter deep idle */ - + if (cx-type == OMAP3_STATE_C6) + printk(KERN_ERRTrying OMAP3_STATE_C6\n); + mpu_pd = pwrdm_lookup(mpu_pwrdm); core_pd = pwrdm_lookup(core_pwrdm); per_pd = pwrdm_lookup(per_pwrdm); @@ -521,6 +523,15 @@ static int omap3_enter_idle(struct cpuidle_device *dev, omap2_gpio_resume_after_retention(); } + if (!pwrdm_read_prev_pwrst(mpu_pd)) + printk(mpu off achieved\n); + if (!pwrdm_read_prev_pwrst(core_pd)) + printk(core off achieved\n); + if (!pwrdm_read_prev_pwrst(per_pd)) + printk(per off achieved\n); + if (!pwrdm_read_prev_pwrst(neon_pd)) + printk(neon off achieved\n); + And the output is this: Trying OMAP3_STATE_C6 mpu off achieved core off achieved per off achieved Neon is not printed as it is in off or ret all the time. Basically off state is achieved using Rajendras patches + config. I still see that hang on boot. I have feeling that it is related to other states than C6. I tried to disable all other states than C0 and C6 by setting valid bit to 0. After this boot works ok, but C6 state is never tried. Any idea why? There is still some occasional hangs. Seems to be related to wakeup. Cheers, Peter. -- 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
Re: [PATCH 00/11] OMAP3 CPUidle patches
ext Rajendra Nayak [EMAIL PROTECTED] writes:
Hi,
The following patches define and enable all of the below mentioned C states
for OMAP3.
These are tested with a minimal kernel config on OMAP3430sdp as most drivers
today don't have context save/restore in place and
some even lack aggresive clock handling.
These apply on top of the workaround patch set submitted by Jouni.
([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.)
The following is neccessay even with a minimal config to achieve OFF.
$ echo 1 /sys/power/sleep_while_idle
$ echo 1 /sys/power/clocks_off_while_idle
The following C states are defined
C0 - System executing code
C1 - MPU WFI + Core active
C2 - MPU CSWR + Core active
C3 - MPU OFF + Core active
C4 - MPU CSWR + Core CSWR
C5 - MPU OFF + Core CSWR
C6 - MPU OFF + Core OFF
regards,
Rajendra
One more general comment on these patches as I looked at the code
after applying them.
Most of the code in omap3_enter_idle in cpuidle34xx.c could be shared
between suspend/pm_idle/cpuidle. I would do these changes to share
this code between these three things:
1. read mpu_pd pwrst, neon_pd pwrst, core_pd pwrst values in
omap_sram_idle in pm34xx.c
2. Move all the logic from omap3_enter_idle to omap_sram_idle. Use
values read in previous step to decide wether ctx savings/restores
are needed, what should be written to neon_pd next_pwrst, wether
omap2_gpio_prepare_for/resume_after_retention is needed, wether to
disable/enable serial and gpio clocks.
Basically what is left into omap3_enter_idle is writing next pwrsts
and cpuidle related stuff, something like this:
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;
struct powerdomain *mpu_pd, *core_pd;
current_cx_state = *cx;
if (cx-type == OMAP3_STATE_C0) {
/* Do nothing for C0, not even a wfi */
return 0;
}
local_irq_disable();
local_fiq_disable();
/* Used to keep track of the total time in idle */
getnstimeofday(ts_preidle);
if (cx-type OMAP3_STATE_C1)
sched_clock_idle_sleep_event(); /* about to enter deep idle */
mpu_pd = pwrdm_lookup(mpu_pwrdm);
core_pd = pwrdm_lookup(core_pwrdm);
pwrdm_set_next_pwrst(mpu_pd, cx-mpu_state);
pwrdm_set_next_pwrst(core_pd, cx-core_state);
if (omap_irq_pending())
goto return_sleep_time;
/* Execute ARM wfi */
omap_sram_idle();
return_sleep_time:
getnstimeofday(ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
if (cx-type OMAP3_STATE_C1)
sched_clock_idle_wakeup_event(timespec_to_ns(ts_idle));
local_irq_enable();
local_fiq_disable();
return (u32)timespec_to_ns(ts_idle)/1000;
}
If this is not done, we need to copy paste code from omap3_enter_idle
into suspend code anyway if we want to use offmode in it. It would be
more nice to have one funcion with this logic shared between
suspend/pm_idle/cpuidle rather than two or even three copies of it.
--
Jouni Högander
--
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 00/11] OMAP3 CPUidle patches
-Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. Cheers, Peter. -- 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 00/11] OMAP3 CPUidle patches
-Original Message-
From: Högander Jouni [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 03, 2008 11:28 AM
To: ext Rajendra Nayak
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches
ext Rajendra Nayak [EMAIL PROTECTED] writes:
Hi,
The following patches define and enable all of the below
mentioned C states for OMAP3.
These are tested with a minimal kernel config on
OMAP3430sdp as most drivers today don't have context
save/restore in place and
some even lack aggresive clock handling.
These apply on top of the workaround patch set submitted by Jouni.
([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.)
The following is neccessay even with a minimal config to
achieve OFF.
$ echo 1 /sys/power/sleep_while_idle
$ echo 1 /sys/power/clocks_off_while_idle
The following C states are defined
C0 - System executing code
C1 - MPU WFI + Core active
C2 - MPU CSWR + Core active
C3 - MPU OFF + Core active
C4 - MPU CSWR + Core CSWR
C5 - MPU OFF + Core CSWR
C6 - MPU OFF + Core OFF
regards,
Rajendra
One more general comment on these patches as I looked at the code
after applying them.
Most of the code in omap3_enter_idle in cpuidle34xx.c could be shared
between suspend/pm_idle/cpuidle. I would do these changes to share
this code between these three things:
1. read mpu_pd pwrst, neon_pd pwrst, core_pd pwrst values in
omap_sram_idle in pm34xx.c
2. Move all the logic from omap3_enter_idle to omap_sram_idle. Use
values read in previous step to decide wether ctx savings/restores
are needed, what should be written to neon_pd next_pwrst, wether
omap2_gpio_prepare_for/resume_after_retention is needed, wether to
disable/enable serial and gpio clocks.
Basically what is left into omap3_enter_idle is writing next pwrsts
and cpuidle related stuff, something like this:
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;
struct powerdomain *mpu_pd, *core_pd;
current_cx_state = *cx;
if (cx-type == OMAP3_STATE_C0) {
/* Do nothing for C0, not even a wfi */
return 0;
}
local_irq_disable();
local_fiq_disable();
/* Used to keep track of the total time in idle */
getnstimeofday(ts_preidle);
if (cx-type OMAP3_STATE_C1)
sched_clock_idle_sleep_event(); /* about to
enter deep idle */
mpu_pd = pwrdm_lookup(mpu_pwrdm);
core_pd = pwrdm_lookup(core_pwrdm);
pwrdm_set_next_pwrst(mpu_pd, cx-mpu_state);
pwrdm_set_next_pwrst(core_pd, cx-core_state);
if (omap_irq_pending())
goto return_sleep_time;
/* Execute ARM wfi */
omap_sram_idle();
return_sleep_time:
getnstimeofday(ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
if (cx-type OMAP3_STATE_C1)
sched_clock_idle_wakeup_event(timespec_to_ns(ts_idle));
local_irq_enable();
local_fiq_disable();
return (u32)timespec_to_ns(ts_idle)/1000;
}
If this is not done, we need to copy paste code from omap3_enter_idle
into suspend code anyway if we want to use offmode in it. It would be
more nice to have one funcion with this logic shared between
suspend/pm_idle/cpuidle rather than two or even three copies of it.
Yes, all this looks good to me.
--
Jouni Högander
--
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 00/11] OMAP3 CPUidle patches
-Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 6:41 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, On Tue, Jul 01, 2008 at 07:46:01PM +0530, ext Rajendra Nayak wrote: Hi, The following patches define and enable all of the below mentioned C states for OMAP3. These are tested with a minimal kernel config on OMAP3430sdp as most drivers today don't have context save/restore in place and some even lack aggresive clock handling. These apply on top of the workaround patch set submitted by Jouni. ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) The following is neccessay even with a minimal config to achieve OFF. $ echo 1 /sys/power/sleep_while_idle $ echo 1 /sys/power/clocks_off_while_idle The following C states are defined C0 - System executing code C1 - MPU WFI + Core active C2 - MPU CSWR + Core active C3 - MPU OFF + Core active C4 - MPU CSWR + Core CSWR C5 - MPU OFF + Core CSWR C6 - MPU OFF + Core OFF I don't see the core domain going to off state. On VDD1 I measured 52uA as the lowest consumption, VDD2 stays at 400uA. Maybe there is still a problem in my config file ? I disabled ethernet but I do use NOR flash to store the rootfs, so MTD needs to be enabled. Is that a problem ? Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. here is the .config I use # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc8-omap1 # Tue Jul 1 16:50:36 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_ZONE_DMA=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory CONFIG_CLASSIC_RCU=y # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set
Re: [PATCH 00/11] OMAP3 CPUidle patches
Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Cheers, Peter. -- 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
