From: Jon Hunter <jon-hunter@ti.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Kevin Hilman <khilman@linaro.org>,
device-tree <devicetree-discuss@lists.ozlabs.org>,
linux-omap <linux-omap@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/5] gpio/omap: force restore if context loss is not detectable
Date: Wed, 10 Apr 2013 14:50:22 -0500 [thread overview]
Message-ID: <5165C27E.1060704@ti.com> (raw)
In-Reply-To: <CACRpkdZciGZkWR-qxT96c9pO9UM4fPh_1BUJP9-b1fhjL6-uDg@mail.gmail.com>
On 04/10/2013 02:44 PM, Linus Walleij wrote:
> On Wed, Apr 10, 2013 at 9:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>> On 04/10/2013 02:39 PM, Linus Walleij wrote:
>>> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>>
>>>> When booting with device-tree the function pointer for detecting context
>>>> loss is not populated. Ideally, the pm_runtime framework should be
>>>> enhanced to allow a means for reporting context/state loss and we could
>>>> avoid populating such function pointers altogether. In the interim until
>>>> a generic non-device specific solution is in place, force a restore of
>>>> the gpio bank when enabling the gpio controller.
>>>>
>>>> Adds a new device-tree property for the OMAP GPIO controller to indicate
>>>> if the GPIO controller is located in a power-domain that never loses
>>>> power and hence will always maintain its logic state.
>>>>
>>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>>
>>> In this case it'd be really helpful to get an ACK from somebody else.
>>> I have no clue whether this thing is doing what it should, and if
>>> you were the maintainer I'd apply it but now I'd like to hear from
>>> Kevin or Santosh first...
>>
>> Santosh gave the his ACK for 1-4 (see 0/5) and Kevin added his
>> reviewed-by for 1-4 (again see 0/5).
>
> OK all in patch 0 how confusing #-)
>
> All patches applied with Kevin's and Santosh's tags!
Thanks. Sorry for the confusion!
By the way, I am hoping you only took 1-4, per the cover-letter I was
planning to have Benoit take 5 through his DT branch as there could be
conflicts if you merge this with Benoit's branch. Again sorry if this is
even more confusing ;-)
Cheers
Jon
next prev parent reply other threads:[~2013-04-10 19:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-04 20:16 [PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10 Jon Hunter
2013-04-04 20:16 ` [PATCH 1/5] gpio/omap: free irq domain in probe() failure paths Jon Hunter
2013-04-10 19:33 ` Linus Walleij
2013-04-10 19:48 ` Jon Hunter
2013-04-15 22:06 ` Kevin Hilman
2013-04-04 20:16 ` [PATCH 2/5] gpio/omap: remove extra context restores in *_runtime_resume() Jon Hunter
2013-04-10 19:34 ` Linus Walleij
2013-04-04 20:16 ` [PATCH 3/5] gpio/omap: optimise interrupt service routine Jon Hunter
2013-04-05 9:19 ` Felipe Balbi
2013-04-10 19:37 ` Linus Walleij
2013-04-04 20:16 ` [PATCH 4/5] gpio/omap: force restore if context loss is not detectable Jon Hunter
2013-04-10 19:39 ` Linus Walleij
[not found] ` <CACRpkdbeABuFXr0Gt6gRto3Pmo0m88AFn_xKJq14VonGg7Doww-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-10 19:41 ` Jon Hunter
2013-04-10 19:44 ` Linus Walleij
2013-04-10 19:50 ` Jon Hunter [this message]
2013-04-10 20:47 ` Linus Walleij
2013-04-04 20:16 ` [PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are always powered Jon Hunter
2013-04-04 20:35 ` Tony Lindgren
2013-04-04 21:01 ` Jon Hunter
2013-04-04 21:08 ` Tony Lindgren
2013-04-05 6:35 ` [PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10 Santosh Shilimkar
2013-04-05 12:18 ` Jon Hunter
2013-04-05 17:56 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5165C27E.1060704@ti.com \
--to=jon-hunter@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=khilman@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=santosh.shilimkar@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).