Re: FW: [PATCH 00/05] 34XX cpu idle patches - core off

Re: FW: [PATCH 00/05] 34XX cpu idle patches - core off

[Peter 'p2' De Schrijver]

On Fri, Jun 27, 2008 at 05:27:48PM +0530, ext Rajendra Nayak wrote:
> Hi Peter,
> 
> I have the CORE off working on top of Jouni's latest patch set posted on l-o.
> 
> 2 issues which I saw due to which CORE OFF was broken
> 1) Control module registers were redefined with the same name in control.h while my patches 
> defined them in cpuidle34xx.h. In control.h they were just offsets and in cpuidle34xx.h they were defined as physical address.
> While saving the control module context, the offset was getting passed to omap_readl resulting in a crash.
> 2) GPIO clocks disable was moved into SRAM code in Jouni's patch, which would not get executed in OFF path.
> 

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

Re: FW: [PATCH 00/05] 34XX cpu idle patches - core off

[Peter 'p2' De Schrijver]

Hi Rajendra,

> 
> The patches still require some amount of cleaning, once Jouni posts his next set of workaround patches 
> taking care of the sleep dependecy for PER, I will rework/clean these patches and then send it to the 
> linux-omap list.
> 
> I am still seeing some issues with debug uart responsiveness which I am looking into. Need to see if the wakeup
> is configured properly.
> 

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

Thanks,

Peter.

RE: FW: [PATCH 00/05] 34XX cpu idle patches - core off

[Igor Stoppa]

Hi,
On Mon, 2008-06-30 at 07:45 -0500, ext Woodruff, Richard wrote:

> For things like bluetooth or other the protocol should re-transmit.


That's avoided with an out of band irq.

-- 

Cheers, Igor

---

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

RE: FW: [PATCH 00/05] 34XX cpu idle patches - core off

[Woodruff, Richard]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

> > I am still seeing some issues with debug uart responsiveness which I
> am looking into. Need to see if the wakeup

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.


[-- Attachment #2: uart_fast5.diff --]
[-- Type: application/octet-stream, Size: 1126 bytes --]

diff -purN img/2.6_kernel/drivers/serial/8250.c 2.6_kernel/drivers/serial/8250.c
--- img/2.6_kernel/drivers/serial/8250.c	2008-05-09 18:50:53.000000000 -0500
+++ 2.6_kernel/drivers/serial/8250.c	2008-06-03 19:44:24.000000000 -0500
@@ -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
 }
 

RE: FW: [PATCH 00/05] 34XX cpu idle patches - core off

[Woodruff, Richard]

Hi,

> On Mon, 2008-06-30 at 07:45 -0500, ext Woodruff, Richard wrote:
>
> > For things like bluetooth or other the protocol should re-transmit.
>
> That's avoided with an out of band irq.

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.

Re: FW: [PATCH 00/05] 34XX cpu idle patches - core off

[Peter 'p2' De Schrijver]

> 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.
> 

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