> > 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:
uart_fast5.diff
Description: uart_fast5.diff
