[PATCHv4 4/6] ARM: OMAP3+: PRM: Enable IO wake up

[rnayak@ti.com (Rajendra Nayak)]

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@ti.com>
>
> 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.
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