Tony Lindgren [off-list ref] writes:

[...]

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
    
    Omap_uart_can_sleep function blocks system wide low power state until
    uart is active remove this func and add qos requests to prevent
    MPU from transitioning.
    
    Keep qos request to default value which will allow MPU to transition
    and while uart baud rate is available calculate the latency value
    from the baudrate and use the same to hold constraint while uart clocks
    are enabled, and if uart is auto-idled the constraint is updated with
    default constraint value allowing MPU to transition.
    
    Qos requests are blocking notifier calls so put these requests to
    work queue, also the driver uses irq_safe version of runtime API's
    and callbacks can be called in interrupt disabled context.
    So to avoid warn on slow path warning while using qos update
    API's from runtime callbacks use the qos_work_queue.
    
    During bootup the runtime_resume call backs might not be called and runtime
    callback gets called only after uart is idled by setting the autosuspend
    timeout. So qos_request from runtime resume callback might not activated during
    boot if uart baudrate is calculated during bootup for console uart, so schedule
    the qos_work queue once we calc_latency while configuring the uart port.
    
    Flush and complete any pending qos jobs in work queue while suspending.
    
    Signed-off-by: Govindraj.R [off-list ref]
    Acked-by: Greg Kroah-Hartman [off-list ref] (for drivers/tty changes)
    Signed-off-by: Kevin Hilman [off-list ref]

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.

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