added Rajendra, Nilesh, Vishwa, Mohan Hi On Fri, 2 Mar 2012, Tero Kristo wrote: > Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been > managed in cpuidle path which is not the right place. Subsequent patch > will remove IO Daisy chain handling in cpuidle path once daisy chain is > handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup > enable code from the trigger function to init time setup. > > Signed-off-by: Tero Kristo <t-kristo@xxxxxx> Should we keep the I/O wakeups enabled all the time? Seems like that could result in at least one spurious wake-up event -- and thus a PRCM interrupt -- for each I/O pad that has WAKEUPENABLE set. Seems like these interrupts could recur every time the I/O chain is reset. And that the I/O chain is now reset in every hwmod idle and enable operation for an IP block that contains dynamic mux data? Thinking about the problem naïvely... maybe you all can think through this with me: Consider an IP block 'A' that has a signal (like the UART rx_irrx signal) that's mux'ed to a pad with WAKEUPENABLE set. (Some examples of 'A' might include a UART, a GPIO, or a McBSP.) Shouldn't we enable I/O wakeups (by setting EN_IO/GLOBAL_WUEN) only immediately before the powerdomain containing IP block 'A' is going to transition into RETENTION or OFF? If we do that, then we can avoid needlessly resetting the I/O chain when a powerdomain is not going to go into a low-power state. I haven't measured the time it takes for the I/O chain to be reset. Maybe one of you have. But that 100 microsecond timeout that was specified in two of the other patches in this series has me a little worried. - Paul
