> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
