Re: [PATCH 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Fri, Apr 27, 2012 at 02:12:12PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@animalcreek.com writes: On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: Just thinking out loud... We could chose whether pm_idle cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). The presence of the davinci_emac is probably overkill, avoiding WFI should really only be done when the davinci_emac is *active*. e.g. using an am35x with an EMAC *present*, but not in use because there's an MMC rootfs for example. If there's a good way to detect an in-use davinci_emac, then disable_hlt() can be used to avoid WFI. When the davinci_emac is not in use (e.g. module unloaded etc.) then enable_hlt() can be used to (re)allow WFI. This can work for pm_idle but what should be done for cpu_idle (as in, omap3_enter_idle[_bm])? We should have some sort of solution for that so users can safely enable CONFIG_CPU_IDLE and not have the am3517 fall apart. Mark -- 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/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
Mark A. Greer mgr...@animalcreek.com writes: On Fri, Apr 27, 2012 at 02:12:12PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@animalcreek.com writes: On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: Just thinking out loud... We could chose whether pm_idle cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). The presence of the davinci_emac is probably overkill, avoiding WFI should really only be done when the davinci_emac is *active*. e.g. using an am35x with an EMAC *present*, but not in use because there's an MMC rootfs for example. If there's a good way to detect an in-use davinci_emac, then disable_hlt() can be used to avoid WFI. When the davinci_emac is not in use (e.g. module unloaded etc.) then enable_hlt() can be used to (re)allow WFI. This can work for pm_idle but what should be done for cpu_idle (as in, omap3_enter_idle[_bm])? We should have some sort of solution for that so users can safely enable CONFIG_CPU_IDLE and not have the am3517 fall apart. disable_hlt() will prevent either the default idle *or* CPUidle from being called. It will simply call cpu_relax() instead of calling any idle function. (c.f. cpu_idle() in arch/arm/kernel/process.c) 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 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Mon, Apr 30, 2012 at 03:00:56PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@animalcreek.com writes: On Fri, Apr 27, 2012 at 02:12:12PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@animalcreek.com writes: On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: Just thinking out loud... We could chose whether pm_idle cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). The presence of the davinci_emac is probably overkill, avoiding WFI should really only be done when the davinci_emac is *active*. e.g. using an am35x with an EMAC *present*, but not in use because there's an MMC rootfs for example. If there's a good way to detect an in-use davinci_emac, then disable_hlt() can be used to avoid WFI. When the davinci_emac is not in use (e.g. module unloaded etc.) then enable_hlt() can be used to (re)allow WFI. This can work for pm_idle but what should be done for cpu_idle (as in, omap3_enter_idle[_bm])? We should have some sort of solution for that so users can safely enable CONFIG_CPU_IDLE and not have the am3517 fall apart. disable_hlt() will prevent either the default idle *or* CPUidle from being called. It will simply call cpu_relax() instead of calling any idle function. (c.f. cpu_idle() in arch/arm/kernel/process.c) Yep, you're right. Sorry. Mark -- 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/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
Mark A. Greer mgr...@animalcreek.com writes: On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: Hi Hi Paul, Kevin. On Wed, 11 Apr 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() which calls omap_sram_idle(). omap_sram_idle() eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). To handle this, follow the same path in omap3_enter_idle() that would be followed if an interrupt were pending. I don't quite understand this patch. Are you saying that AM3517/3505 can't wake from WFI? That would seem odd. There are other sources of wakeup on the system other than I/O wakeup. I/O wakeup only applies to wakeups from the I/O pads when the chip is in RETENTION or OFF. And as I understand it, neither of those apply to AM3517/3505? Even if I/O wakeups aren't supported, many of the IP blocks on the system should be able to cause the ARM to exit WFI by asserting their SWAKEUP lines and raising their interrupt lines. I have changed the code to keep everything in the ON state and use cpu_do_idle()--basically a wfi, cpu_v7_do_idle() in this case--and everything works well (except networking, see below) when using an mmc-based rootfs. The issue is with the emac--it can't wake the system up unless there is an irq from the PHY to a wakeup-enabled GPIO (confirmed by h/w engr). So, when using networking or using an nfs-based rootfs, there are all kinds of timeouts, etc. Basically, doing a wfi (i.e., pm_idle or cpuidle) and expecting the emac to wake the system back up won't work. How would you like me to proceed (to avoid the wfi in pm_idle cpuidle)? Just thinking out loud... We could chose whether pm_idle cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). The presence of the davinci_emac is probably overkill, avoiding WFI should really only be done when the davinci_emac is *active*. e.g. using an am35x with an EMAC *present*, but not in use because there's an MMC rootfs for example. If there's a good way to detect an in-use davinci_emac, then disable_hlt() can be used to avoid WFI. When the davinci_emac is not in use (e.g. module unloaded etc.) then enable_hlt() can be used to (re)allow WFI. 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 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Fri, Apr 27, 2012 at 02:12:12PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@animalcreek.com writes: On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: We could chose whether pm_idle cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). The presence of the davinci_emac is probably overkill, avoiding WFI should really only be done when the davinci_emac is *active*. e.g. using an am35x with an EMAC *present*, but not in use because there's an MMC rootfs for example. If there's a good way to detect an in-use davinci_emac, then disable_hlt() can be used to avoid WFI. When the davinci_emac is not in use (e.g. module unloaded etc.) then enable_hlt() can be used to (re)allow WFI. Good idea. I'll see what I can do. Mark -- 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/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: Hi Hi Paul, Kevin. On Wed, 11 Apr 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() which calls omap_sram_idle(). omap_sram_idle() eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). To handle this, follow the same path in omap3_enter_idle() that would be followed if an interrupt were pending. I don't quite understand this patch. Are you saying that AM3517/3505 can't wake from WFI? That would seem odd. There are other sources of wakeup on the system other than I/O wakeup. I/O wakeup only applies to wakeups from the I/O pads when the chip is in RETENTION or OFF. And as I understand it, neither of those apply to AM3517/3505? Even if I/O wakeups aren't supported, many of the IP blocks on the system should be able to cause the ARM to exit WFI by asserting their SWAKEUP lines and raising their interrupt lines. I have changed the code to keep everything in the ON state and use cpu_do_idle()--basically a wfi, cpu_v7_do_idle() in this case--and everything works well (except networking, see below) when using an mmc-based rootfs. The issue is with the emac--it can't wake the system up unless there is an irq from the PHY to a wakeup-enabled GPIO (confirmed by h/w engr). So, when using networking or using an nfs-based rootfs, there are all kinds of timeouts, etc. Basically, doing a wfi (i.e., pm_idle or cpuidle) and expecting the emac to wake the system back up won't work. How would you like me to proceed (to avoid the wfi in pm_idle cpuidle)? Thanks, Mark -- 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/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: Hi Hi Paul, Kevin. On Wed, 11 Apr 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() which calls omap_sram_idle(). omap_sram_idle() eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). To handle this, follow the same path in omap3_enter_idle() that would be followed if an interrupt were pending. I don't quite understand this patch. Are you saying that AM3517/3505 can't wake from WFI? That would seem odd. There are other sources of wakeup on the system other than I/O wakeup. I/O wakeup only applies to wakeups from the I/O pads when the chip is in RETENTION or OFF. And as I understand it, neither of those apply to AM3517/3505? Even if I/O wakeups aren't supported, many of the IP blocks on the system should be able to cause the ARM to exit WFI by asserting their SWAKEUP lines and raising their interrupt lines. I have changed the code to keep everything in the ON state and use cpu_do_idle()--basically a wfi, cpu_v7_do_idle() in this case--and everything works well (except networking, see below) when using an mmc-based rootfs. The issue is with the emac--it can't wake the system up unless there is an irq from the PHY to a wakeup-enabled GPIO (confirmed by h/w engr). So, when using networking or using an nfs-based rootfs, there are all kinds of timeouts, etc. Basically, doing a wfi (i.e., pm_idle or cpuidle) and expecting the emac to wake the system back up won't work. How would you like me to proceed (to avoid the wfi in pm_idle cpuidle)? Just thinking out loud... We could chose whether pm_idle cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
From: Mark A. Greer mgr...@animalcreek.com Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() which calls omap_sram_idle(). omap_sram_idle() eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). To handle this, follow the same path in omap3_enter_idle() that would be followed if an interrupt were pending. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- arch/arm/mach-omap2/cpuidle34xx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 5358664..12cf81d 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -100,7 +100,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev, pwrdm_set_next_pwrst(mpu_pd, mpu_state); pwrdm_set_next_pwrst(core_pd, core_state); - if (omap_irq_pending() || need_resched()) + if (omap_irq_pending() || need_resched() || !omap3_has_io_wakeup()) goto return_sleep_time; /* Deny idle for C1 */ -- 1.7.9.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
Hi On Wed, 11 Apr 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() which calls omap_sram_idle(). omap_sram_idle() eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). To handle this, follow the same path in omap3_enter_idle() that would be followed if an interrupt were pending. I don't quite understand this patch. Are you saying that AM3517/3505 can't wake from WFI? That would seem odd. There are other sources of wakeup on the system other than I/O wakeup. I/O wakeup only applies to wakeups from the I/O pads when the chip is in RETENTION or OFF. And as I understand it, neither of those apply to AM3517/3505? Even if I/O wakeups aren't supported, many of the IP blocks on the system should be able to cause the ARM to exit WFI by asserting their SWAKEUP lines and raising their interrupt lines. So this change doesn't seem quite right to me... More broadly, if AM3517/3505 only supports powerdomains ON, then you should probably use your own CPUIdle driver that doesn't touch the powerdomain states at all. - Paul Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- arch/arm/mach-omap2/cpuidle34xx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 5358664..12cf81d 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -100,7 +100,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev, pwrdm_set_next_pwrst(mpu_pd, mpu_state); pwrdm_set_next_pwrst(core_pd, core_state); - if (omap_irq_pending() || need_resched()) + if (omap_irq_pending() || need_resched() || !omap3_has_io_wakeup()) goto return_sleep_time; /* Deny idle for C1 */ -- 1.7.9.4 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: On Wed, 11 Apr 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() which calls omap_sram_idle(). omap_sram_idle() eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). To handle this, follow the same path in omap3_enter_idle() that would be followed if an interrupt were pending. I don't quite understand this patch. Are you saying that AM3517/3505 can't wake from WFI? That would seem odd. No, I'm saying that I/O doesn't seem to wake it up from the WFI. I've learned to not trust the am35x TRM much so I'm pretty much feeling my way along in the dark. I do know that without this patch, the system is extremely slow which I believe is from it only returning from the WFI because of a timer expiration or something like that. There are other sources of wakeup on the system other than I/O wakeup. I/O wakeup only applies to wakeups from the I/O pads when the chip is in RETENTION or OFF. And as I understand it, neither of those apply to AM3517/3505? Hmm, its true that RETENTION and OFF aren't supported. It does wake up occasionally (as mentioned above) it just seems that I/O doesn't wake it up. I may be mistaken. I'm only going from what I've seen since and the TRM seems to have lots of errors so I'm not sure what to trust in it. Even if I/O wakeups aren't supported, many of the IP blocks on the system should be able to cause the ARM to exit WFI by asserting their SWAKEUP lines and raising their interrupt lines. Okay, but that doesn't seem to be working. I'll look some more to see why they aren't working. So this change doesn't seem quite right to me... More broadly, if AM3517/3505 only supports powerdomains ON, then you should probably use your own CPUIdle driver that doesn't touch the powerdomain states at all. Okay, I can do that. Mark -- -- 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/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
cc Govindraj On Wed, 11 Apr 2012, Mark A. Greer wrote: On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: I don't quite understand this patch. Are you saying that AM3517/3505 can't wake from WFI? That would seem odd. No, I'm saying that I/O doesn't seem to wake it up from the WFI. I've learned to not trust the am35x TRM much so I'm pretty much feeling my way along in the dark. Hehe, no worries, just curious. I do know that without this patch, the system is extremely slow which I believe is from it only returning from the WFI because of a timer expiration or something like that. How are you trying to wake it up -- from an incoming character via the UART? Does the system pause in the middle of UART transmits, or does it get the transmit buffers out cleanly and just not respond promptly to incoming characters? There are other sources of wakeup on the system other than I/O wakeup. I/O wakeup only applies to wakeups from the I/O pads when the chip is in RETENTION or OFF. And as I understand it, neither of those apply to AM3517/3505? Hmm, its true that RETENTION and OFF aren't supported. It does wake up occasionally (as mentioned above) it just seems that I/O doesn't wake it up. I may be mistaken. I'm only going from what I've seen since and the TRM seems to have lots of errors so I'm not sure what to trust in it. OK no problem, just trying to understand what's going on. Sounds like you've gotten tossed into the deep end :-) Even if I/O wakeups aren't supported, many of the IP blocks on the system should be able to cause the ARM to exit WFI by asserting their SWAKEUP lines and raising their interrupt lines. Okay, but that doesn't seem to be working. I'll look some more to see why they aren't working. There could be a hidden dependency on I/O wakeup being present in the UART driver. We've been going through some UART driver angst recently... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Wed, Apr 11, 2012 at 04:47:31PM -0600, Paul Walmsley wrote: cc Govindraj On Wed, 11 Apr 2012, Mark A. Greer wrote: On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: I don't quite understand this patch. Are you saying that AM3517/3505 can't wake from WFI? That would seem odd. No, I'm saying that I/O doesn't seem to wake it up from the WFI. I've learned to not trust the am35x TRM much so I'm pretty much feeling my way along in the dark. Hehe, no worries, just curious. I do know that without this patch, the system is extremely slow which I believe is from it only returning from the WFI because of a timer expiration or something like that. How are you trying to wake it up -- from an incoming character via the UART? Does the system pause in the middle of UART transmits, or does it get the transmit buffers out cleanly and just not respond promptly to incoming characters? Both cpu_idle/pm_idle thread (arch/arm/kernel/process.c:cpu_idle()) and the cpu idle driver (arch/arm/mach-omap2/cpuidle34xx.c:omap3_enter_idle()) behave the same without the 2 patches I posted. During boot, things become extremely sluggish. I took that to mean that the WFI wasn't being woken up unless a timer expired. I also believed that not having I/O wake-ups would cause that so I made those patches. There don't appear to be any missing or additional characters from the UART. This is all during the boot-up so I'm not even trying to enter characters via the UART. That's all I did for testing, if you can call it that. For the emif4, etc. patches, I would do a suspend-to-RAM and hit a key on the keyboard to wake it up again. There are no dropped or added characters in the [serial] console output. It does complain that the expected state wasn't entered (INACTIVE) and by looking at /sys/kernel/debug/pm_debug/count, the CORE domain is the only one that didn't increment its INA count. There are other sources of wakeup on the system other than I/O wakeup. I/O wakeup only applies to wakeups from the I/O pads when the chip is in RETENTION or OFF. And as I understand it, neither of those apply to AM3517/3505? Hmm, its true that RETENTION and OFF aren't supported. It does wake up occasionally (as mentioned above) it just seems that I/O doesn't wake it up. I may be mistaken. I'm only going from what I've seen since and the TRM seems to have lots of errors so I'm not sure what to trust in it. OK no problem, just trying to understand what's going on. Sounds like you've gotten tossed into the deep end :-) :) Even if I/O wakeups aren't supported, many of the IP blocks on the system should be able to cause the ARM to exit WFI by asserting their SWAKEUP lines and raising their interrupt lines. Okay, but that doesn't seem to be working. I'll look some more to see why they aren't working. There could be a hidden dependency on I/O wakeup being present in the UART driver. We've been going through some UART driver angst recently... OK. Mark -- -- 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
