On Tue, 2012-03-06 at 10:26 +0530, Rajendra Nayak wrote: > On Tuesday 06 March 2012 10:20 AM, Rajendra Nayak wrote: > > On Tuesday 06 March 2012 09:51 AM, Paul Walmsley wrote: > >> 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? > > > > Hi Paul, > > > > I completely agree with your observations and we knew we would have > > additional wakeups with this design. Like I mentioned in the other > > thread, we went ahead with this approach knowing we need to optimize > > with some kind of powerdomain level usecounting in the future, because > > it didn't exist back then when we did it this way. > > But now that we already have it, maybe we can fix this and do > > it such that we completely avoid an additional wakeup interrupt. > > > >> > >> 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. > > > > I haven't profiled it myself but I am guessing the delay isn't much. > > Having said that, I do agree with you that, however small the delay, > we end up doing needless IO trigger when the powerdomain isn't > really entering a low power state. I did some measurements on this a while back and the delay was around a few microseconds. I can redo this while doing version 5. -Tero > > > The 100us comes from the fact that there is no documentation on the > > exact delay, so went around asking whats the *real worst case* delay, > > and we got an answer, 100us should be really big enough :) > > > > regards, > > Rajendra > > > >> > >> > >> - Paul > > > -- 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
