> 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
