Re: Broken cpuidle on PM branch?
On Tue, Oct 13, 2009 at 06:25:17PM +0200, ext Kevin Hilman wrote: Eduardo Valentin eduardo.valen...@nokia.com writes: Hello Amit, On Mon, Oct 12, 2009 at 09:23:47PM +0200, ext Amit Kucheria wrote: Hi, I am testing twl4030 script optimisations on the current PM branch. But I am seeing the board (RX51) freeze when CPU_IDLE is enabled in the config. Is it known to work on other boards? I'm actually seeing this same behavior. But the board actually does not freeze. If you keep a key pressed of send a sysrq through serial line then you eventually get it back. It seams to be something related to serial driver and wakeup ? Do you see this problem after doing # echo 1 /debug/pm_debug/sleep_while_idle No I don't. The problem is gone it seams. similar effect happens if we # echo 0 /sys/devices/platform/serial8250.2/sleep_timeout Of course, this would prevent device go to sleep I guess. ? There is a known problem with the UART inactivity timer that I'm debugging currently. Ok. Kevin Regards, Amit -- - Amit Kucheria, Kernel Developer, Verdurent - -- 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 -- Eduardo Valentin -- 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 -- Eduardo Valentin -- 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: Broken cpuidle on PM branch?
Eduardo Valentin eduardo.valen...@nokia.com writes: On Tue, Oct 13, 2009 at 06:25:17PM +0200, ext Kevin Hilman wrote: Eduardo Valentin eduardo.valen...@nokia.com writes: Hello Amit, On Mon, Oct 12, 2009 at 09:23:47PM +0200, ext Amit Kucheria wrote: Hi, I am testing twl4030 script optimisations on the current PM branch. But I am seeing the board (RX51) freeze when CPU_IDLE is enabled in the config. Is it known to work on other boards? I'm actually seeing this same behavior. But the board actually does not freeze. If you keep a key pressed of send a sysrq through serial line then you eventually get it back. It seams to be something related to serial driver and wakeup ? Do you see this problem after doing # echo 1 /debug/pm_debug/sleep_while_idle No I don't. The problem is gone it seams. similar effect happens if we # echo 0 /sys/devices/platform/serial8250.2/sleep_timeout Of course, this would prevent device go to sleep I guess. Yes, there is a problem with UART3 (in PER) going idle independently of CORE/MPU that I have not yet found. 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: Broken cpuidle on PM branch?
On Wed, Oct 14, 2009 at 03:06:41PM +0200, ext Kevin Hilman wrote:
Eduardo Valentin eduardo.valen...@nokia.com writes:
On Tue, Oct 13, 2009 at 06:25:17PM +0200, ext Kevin Hilman wrote:
Eduardo Valentin eduardo.valen...@nokia.com writes:
Hello Amit,
On Mon, Oct 12, 2009 at 09:23:47PM +0200, ext Amit Kucheria wrote:
Hi,
I am testing twl4030 script optimisations on the current PM branch. But
I am
seeing the board (RX51) freeze when CPU_IDLE is enabled in the config.
Is it known to work on other boards?
I'm actually seeing this same behavior. But the board actually does not
freeze. If you keep a key pressed of send a sysrq through serial line
then you eventually get it back.
It seams to be something related to serial driver and wakeup ?
Do you see this problem after doing
# echo 1 /debug/pm_debug/sleep_while_idle
No I don't. The problem is gone it seams.
similar effect happens if we
# echo 0 /sys/devices/platform/serial8250.2/sleep_timeout
Of course, this would prevent device go to sleep I guess.
Yes, there is a problem with UART3 (in PER) going idle independently
of CORE/MPU that I have not yet found.
yeah, one possible fix would be preventing it if core is going to on
@@ -514,7 +514,9 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(2);
+ if (core_next_state != PWRDM_POWER_ON)
+ omap_uart_prepare_idle(2);
+
Needs to see what is the impact of this approach though
Kevin
--
Eduardo Valentin
--
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: Broken cpuidle on PM branch?
Hello Amit, On Mon, Oct 12, 2009 at 09:23:47PM +0200, ext Amit Kucheria wrote: Hi, I am testing twl4030 script optimisations on the current PM branch. But I am seeing the board (RX51) freeze when CPU_IDLE is enabled in the config. Is it known to work on other boards? I'm actually seeing this same behavior. But the board actually does not freeze. If you keep a key pressed of send a sysrq through serial line then you eventually get it back. It seams to be something related to serial driver and wakeup ? Regards, Amit -- - Amit Kucheria, Kernel Developer, Verdurent - -- 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 -- Eduardo Valentin -- 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: Broken cpuidle on PM branch?
Amit Kucheria amit.kuche...@verdurent.com writes: Hi, I am testing twl4030 script optimisations on the current PM branch. But I am seeing the board (RX51) freeze when CPU_IDLE is enabled in the config. Is it known to work on other boards? Yes, and it works for me on RX51 as well, output of the maemo powertop below. For a known working defconfig, start from omap3_pm_defconfig and change the low-level debug UART from UART1 to UART3. There is a known UART bug in the current PM branch where if you don't 'echo 1 /debug/pm_debug/sleep_while_idle', the UART eventually locks up when the inactivity timer expires. I'm still looking into this one. Kevin / # powertop Powertop 1.13.1 status: Unable to send message: Connection refused Mounting debugfs...Success Sleeping for 11 seconds before sampling Collecting data for 30 seconds Sample interval was 00m 30s 20569us C# | Ratio | Avg/dura | Frequency | Ratio ++--+---+-- C0 | 83.4% | | 600 MHz | 0.0% C1 | 16.6% | 832.4ms | 550 MHz | 0.0% C2 | 0.0% | | 500 MHz | 100.0% C3 | 0.0% | | 250 MHz | 0.0% C4 | 0.0% | | 125 MHz | 0.0% IRQ#| Activity | Type | Name +++--- 37 | 27 | INTC | gp 11 | 23 | INTC | prcm 12 | 4 | INTC | DMA 225 | 2 | GPIO | omap2-onenand PID#| Activity | Name | Function Entry (Expire) +++--- 0 | 16 | kernel core | hrtimer_start (tick_sched_timer) 93 | 5 |bdi-default | bdi_forker_task (process_timeout) 483 | 5 |flush-ubifs_0_0 | schedule_timeout_interruptible (process) 0 | 4 | kernel core | arm_supers_timer (sync_supers_timer_fn) 5 | 3 | events/0 | queue_delayed_work (delayed_work_timer_) 483 | 1 |flush-ubifs_0_0 | hrtimer_start_range_ns (wbuf_timer_call) 483 | 1 |flush-ubifs_0_0 | hrtimer_start_range_ns (wbuf_timer_call) 484 | 1 | powertop | hrtimer_start_range_ns (hrtimer_wakeup) Power domain activity breakdown Domain | % of time spent in states +-+-+-+-+-- usbhost |OFF: 0%|RET: 100%|INA: 0%| ON: 0%| now:(RET) sgx |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF) per |OFF: 0%|RET: 83%|INA: 0%| ON: 16%| now:(ON) dss |OFF: 0%|RET: 100%|INA: 0%| ON: 0%| now:(RET) cam |OFF: 0%|RET: 100%|INA: 0%| ON: 0%| now:(RET) core |OFF: 0%|RET: 83%|INA: 0%| ON: 16%| now:(ON) neon |OFF: 0%|RET: 83%|INA: 0%| ON: 16%| now:(ON) mpu |OFF: 0%|RET: 83%|INA: 0%| ON: 16%| now:(ON) iva2 |OFF: 0%|RET: 100%|INA: 0%| ON: 0%| now:(RET) Clock activity breakdown at end of period Domain | Active clocks +---+---+-- core | SDRC | OMAPCTRL | UART1 | UART2 | core3 | USBTLL wkup | GPT1 | 32KSYNC |
