Re: FW: [PATCH 00/05] 34XX cpu idle patches - core off
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: FW: [PATCH 00/05] 34XX cpu idle patches - core off
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: [PATCH 00/05] 34XX cpu idle patches - core off
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: [PATCH 00/05] 34XX cpu idle patches - core off
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
