On Tue, Feb 07, 2012 at 02:36:06PM -0800, Kevin Hilman wrote:

Tony Lindgren [off-list ref] writes:

[...]

quoted

quoted

quoted

quoted

--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c

@@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
 {
 	local_fiq_disable();
 
-	if (omap_irq_pending())
+	if (omap_irq_pending() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

This does not look right to me. I thought reverting of the serial
patches should have already solved the issue you're seeing with
slow serial port?

Those are the reverting commits drivers/tty/serial/serial-omap.c:

8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure
FIFO levels are set correctly in non-DMA mode")

af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit
FIFO threshold interrupts don't wake the chip")

These commits have absolutely nothing to do with it.  I pointed out the
bad commit in one of my emails:

commit 2fd149645eb46d26130d7070c6de037dddf34880
Author: Govindraj.R [off-list ref]
Date:   Wed Nov 9 17:41:21 2011 +0530

    ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
    

[...]

quoted

quoted

Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs
while in some of the deeper low power modes.

I tried reverting the rest of the patches between this one and HEAD for
omap-serial.c, but they have no effect what so ever on this bug.  As I
said in one of my emails in this thread, the above commit can't be
trivially reverted because some other stuff that the code relied upon
has vanished.

So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c
is the smallest 'fix' I could find if resolving the regression.

OK, thanks, that should be enough info for let Kevin take a look at this.

This one is indeed strange.  I have not seen this on the 34xx devices
I'm using (3430/n900, 3530/Overo, 3630/Zoom3).  

Just to confirm.  I assume you are using v3.3-rc2 (or later Linus
master) which has a few fixes for this driver already.

If it helps, I observed the same issue in a beagleboard rev B6, with v3.3-rc2

Russell's patch fixed it.

vmjl

Also, is this happening on your LDP.  Which ES revision does your 3430
have?
 
Kevin