34XX cpu idle patches - core off

Thanks. I'm testing them now. 013-TIPATCH-fix-core-off.patch patches include/asm/arch/control.h which doesn't exist on a non-configured kernel. It's better to have the patch modify include/asm-arm/arch-omap/control.h.

Cheers,

Peter.

goa is a state of mind

Hi Rajendra,

That's what I'm seeing here as well. OMAP goes to off mode but UART wakeup seems to be broken.

Thanks,

Peter.

If by responsiveness it is meant slowness of output (tx path) that' likely good news. It means your hitting interconnect clock stop often and thus getting into first large active mode savings state. This is the biggest step power drop for active states. If your UART looks good you probably are not hitting target states enough from idle.

The UART's TX logic is not currently hooked into the wake up mechanism from clockstop (domain INACTIVE but ON, only RX an external IO events). As such to get good speed you need go to no-idle if there is TX work queued else you won't see TX interrupt events until the next wake up period, likely from GPTIMER0 at dynamic tick rate.

* Expect to loose the 1st character on debug console as a wake up event. Unless you use RTS/CTS (configured as wakeups) as an early wake up path, you will lose the start bit when the system restarts. For things like bluetooth or other the protocol should re-transmit.

If you mean your not waking that's something else.

I've attached a simple path which make UART responsive during high idle periods. It makes the PRCM handshake follow the UART transmitter state. You miss out on clock stop during FIFO drain time but that's not so much % wise in debug usage. An optimal alternative is to set a kernel TIMER to fire at about the expected TX empty time. This will make sure GPT0 wake up will fire. This will allow FIFO drain while in interconnect clock stop.

Regards,
Richard W.

diff -purN img/2.6_kernel/drivers/serial/8250.c 2.6_kernel/drivers/serial/8250.c
@@ -1221,6 +1221,14 @@ static inline void __stop_tx(struct uart
 		p->ier &= ~UART_IER_THRI;
 		serial_out(p, UART_IER, p->ier);
 	}
+#ifdef CONFIG_OMAP3_PM
+	{
+		/* Advertise partial idle to save power. RX side can do async wake */
+		unsigned int tmp;
+		tmp = (serial_in(p, UART_OMAP_SYSC) & 0x7) | (2 << 3);
+		serial_out(p, UART_OMAP_SYSC, tmp); /* smart-idle */
+	}
+#endif
 }
 
 static void serial8250_stop_tx(struct uart_port *port)

@@ -1268,6 +1276,15 @@ static void serial8250_start_tx(struct u
 		up->acr &= ~UART_ACR_TXDIS;
 		serial_icr_write(up, UART_ACR, up->acr);
 	}
+#ifdef CONFIG_OMAP3_PM
+	{
+		/* Don't advertise partial idle else TX irqs will not be seen */
+		/* Alternative is to set kernel timer at fifo drain rate */
+		unsigned int tmp;
+		tmp = (serial_in(up, UART_OMAP_SYSC) & 0x7) | (1 << 3);
+		serial_out(up, UART_OMAP_SYSC, tmp); /* no-idle */
+	}
+#endif
 }
 

Hi,

That's avoided with an out of band irq.

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

Hi,

That can work assuming that external device gives you a 'pre' interrupt before it generates the real timing dependent one. Some external device knowledgeable timer or buffering of the real event needs to happen.

Do some of your peripherals or some fpga glue do this?

In the past I've seen some OR'ing (with possibly conditioning) of interrupts back to a wake up capable gpio. But even in these cases depending on the peripheral you need a little per-time for low idles. Utilizing low control where it exists seems like a natural pre-event.

Regards,
Richard W.

AFAIC it's not waking. Even when using keyboard autorepeat to send spaces or enter, nothing happens.

Cheers,

Peter.

goa is a state of mind