"ext Woodruff, Richard" <r-woodruff2@xxxxxx> writes: >> > The current check will: On activity raise a cpuidle bus master >> > activity failure for some number of seconds. This allows normal >> > typing for extended periods. It does this by marking UART function >> > IRQs with a time stamp and it checks internal state to make sure >> > RX/TX engine is not busy or has queued data waiting. >> >> Isn't this exactly what is done in "Added sleep support to UART" patch >> in workaround patch set? > > See last mail. It probably is. I assumed that was derived from our code which has been available for a long time before. I didn't actually look at it very closely with that assumption. > >> > This activity assertion will gate the usage of C states where its F- >> CLOCK is cut. At the same time its natural wake up events are enabled >> (along with the above hack as the tx events are not currenly hooked >> into the wakeup logic). >> > >> > When OFF/RET mode is selected IO pad is enabled for the port wakeup. >> >> I have seen this in CDP reference code. Is there some specific reason >> why this is enabled dynamically in code? > > Not that I am aware. > > Do you think there is a need to toggle it? Today only the global > IOPAD enable is toggled (which is necessary for pad state latching). No, I might have seen this global IOPAD enable. This is valuable information. Currently in linux-omap setting IOPAD enable bit is done on initialization. We haven't noticed any problems this far, but this feature haven't been used too much. So probably we have been just lucky? -- Jouni Högander -- 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
