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

[Rajendra Nayak]

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 at 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.

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.

> 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
>