[PATCH 1/2] omap: pm34xx: Enable IO / IO-CHAIN wakeups for PER

Kevin Hilman khilman at deeprootsystems.com
Thu Apr 22 18:31:39 EDT 2010


Mike Chan <mike at android.com> writes:

> On Wed, Apr 21, 2010 at 5:07 PM, Kevin Hilman
> <khilman at deeprootsystems.com> wrote:
>> Mike Chan <mike at android.com> writes:
>>
>>> IO events can also come from GPIO modules, which reside in the PER domain.
>>> It is possible for the PER to enter RET while CORE is still in ON.
>>> If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not
>>> wakeup in this case, unless we enable it.
>>>
>>> Signed-off-by: Mike Chan <mike at android.com>
>>
>> Hi Mike,
>>
>> I'm a little puzzled on this one.  My understanding is that the IO pad
>> is only armed when CORE is in RET or OFF.
>>
>
> The issue we are seeing is when the device is active but idle, if CORE
> is ON and PER is in RET and the omap is sitting in swfi. If the user
> presses a keypad button, IO pad doesn't wake us out of idle. Setting a
> wakeup if PER or CORE goes into RET solve this.
>
>> I need to dig a little more in the TRM on this one to clarify.
>>
>
> I was looking at 4.11.2.2 I/O Wake-Up Mechanism (pg 421)
>

Yeah, that's the right place.

After a little more digging and asking around, this looks like a good
fix, but there's a minor problem with the implementation:

In the section of the TRM you referenced the following sentence is
hiding:

  "Software must wait for the I/O daisy chain to complete before it
   transitions the PER domain to a nonfunctional state."

In the proposed patch, it's likely that PER could transition to
INACTIVE/RET/OFF before the IO wakeups are enabled.  For example, if
nothing in PER is active except UART3, then PER will transition to an
idle state right after omap_uart_prepare_idle(2), which is before
the IO wakeups are currently enabled.

To be perfectly safe, the IO wakeups should be enabled before PER is
allowed to transition.

Kevin








More information about the linux-arm-kernel mailing list