[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <13B9B4C6EF24D648824FF11BE896716203BABB8733@dlee02.ent.ti.com>
Date: Thu, 22 Apr 2010 12:57:51 -0500
From: "Woodruff, Richard" <r-woodruff2@...com>
To: Kevin Hilman <khilman@...prootsystems.com>,
Mike Chan <mike@...roid.com>
CC: "tony@...mide.com" <tony@...mide.com>,
"paul@...an.com" <paul@...an.com>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 1/2] omap: pm34xx: Enable IO / IO-CHAIN wakeups for PER
> From: linux-omap-owner@...r.kernel.org [mailto:linux-omap-
> owner@...r.kernel.org] On Behalf Of Kevin Hilman
> 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.
For ES3 and before the io ring wake was 'armed' when ever core went to idle. When core power state changed accounting was done for state.
This scheme created a small time window where per wake events could be lost in handoff from gpio to io daisy chain when targeting chip off.
In ES3.1 the EN_IO_CHAIN bit was added as a way to cover this hole. It allows enabling the wake up daisy chain in software prior to idling core. The trm does detail the exact steps.
The 3.1 bug fix covered the transition window observed going to chip states but probably can cover here. I'm not sure about the patch as applied with studying.
Regards,
Richard W.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists