From: "Grygorii.Strashko@linaro.org" <grygorii.strashko@linaro.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
Javier Martinez Canillas <javier@dowhile0.org>,
ssantosh@kernel.org, Kevin Hilman <khilman@deeprootsystems.com>,
linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [RFC/RFT PATCH v2 7/7] gpio: omap: ensure that runtime pm will disable unused gpio banks
Date: Mon, 25 May 2015 18:08:07 +0300 [thread overview]
Message-ID: <55633AD7.8060806@linaro.org> (raw)
In-Reply-To: <556335AA.5090701@linaro.org>
On 05/25/2015 05:46 PM, Grygorii.Strashko@linaro.org wrote:
> Hi Tony,
>
> On 05/22/2015 09:10 PM, Tony Lindgren wrote:
>> * Grygorii Strashko <grygorii.strashko@linaro.org> [150522 07:37]:
>>> Now there are some points related to Runtime PM usage:
>>> 1) bank state doesn't need to be checked in places where
>>> Rintime PM is used, bacause Runtime PM maintains its
>>> own usage counter:
>>> if (!BANK_USED(bank))
>>> pm_runtime_get_sync(bank->dev);
>>> so, it's safe to drop such checks.
>>>
>>> 2) Such implementation is racy, because check !BANK_USED(bank)
>>> is not protected, like:
>>> CPU0 CPU1
>>> gpio_request(bankX.A)
>>> ...
>>> gpio_free(bankX.A) gpio_request(bankX.Y)
>>>
>>> and bankX can be unpowered in the middle of processing
>>> gpio_request(bankX.Y)
>>>
>>> 3) There is a call of pm_runtime_get_sync() in omap_gpio_irq_type(),
>>> but no corresponding put. As result, GPIO devices could be
>>> powered on forever if at least one GPIO was used as IRQ.
>>> Hence, allow powering off GPIO banks by adding missed
>>> pm_runtime_put(bank->dev) at the end of omap_gpio_irq_type().
>>>
>>> As, part of this change update omap2_gpio_xxxx_idle() functions
>>> to use pm_runtime_force_suspend()/pm_runtime_force_resume().
>>>
>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org>
>>> ---
>>> Changes in v2:
>>> - omap2_gpio_xxxx_idle() functions switched to use
>>> pm_runtime_force_suspend()/pm_runtime_force_resume() API.
>>>
>>> v1:
>>> http://marc.info/?l=linux-gpio&m=142567003515626&w=2
>>
>> This one causes an abort during boot on at least omap3.
>>
>> Maybe try to get a beagleboard xm to test with? It has Ethernet
>> over USB though, so that does not work with PM over NFSroot.
>>
>> If you want something to test with PM with mainline over
>> NFSroot, maybe you can get hold of some of the better supported
>> ones out of these boards:
>>
>> $ git grep "ethernet@gpmc" arch/arm/boot/dts/*.dts*
>>
>> For those Ethernet has a GPIO interrupt ;)
>
> Sure, I'll try get beagleboard.
>
> But, this log is very interesting :( What I can see
> from it is that GPIO IRQ is triggered in the middle of
> omap_sram_idle() - which shouldn't happen, because this is
> cpuidle path and local IRQs should be disabled.
>
> Am I missing smth?
>
Yep. I've missed this :(
pm_runtime_force_suspend
|- pm_runtime_disable
|-__pm_runtime_disable
|- spin_unlock_irq(&dev->power.lock);
So, Runtime PM forced API can't be used in cpuidle path :(
Sorry.
--
regards,
-grygorii
next prev parent reply other threads:[~2015-05-25 15:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 14:35 [RFC/RFT PATCH 0/7] gpio: omap: rework and fixes Grygorii Strashko
2015-05-22 14:35 ` [PATCH 1/7] gpio: omap: fix omap_gpio_free to not clean up irq configuration Grygorii Strashko
2015-06-01 13:11 ` Linus Walleij
2015-06-02 9:31 ` Javier Martinez Canillas
2015-05-22 14:35 ` [PATCH 2/7] gpio: omap: fix error handling in omap_gpio_irq_type Grygorii Strashko
2015-06-02 9:40 ` Javier Martinez Canillas
2015-06-02 14:27 ` Grygorii.Strashko@linaro.org
2015-06-03 19:34 ` Grygorii.Strashko@linaro.org
2015-05-22 14:35 ` [RFC/RFT PATCH 3/7] gpio: omap: rework omap_x_irq_shutdown to touch only irqs specific registers Grygorii Strashko
2015-05-22 14:35 ` [RFC/RFT PATCH 4/7] gpio: omap: rework omap_gpio_request to touch only gpio " Grygorii Strashko
2015-05-22 14:35 ` [RFC/RFT PATCH 5/7] gpio: omap: rework omap_gpio_irq_startup to handle current pin state properly Grygorii Strashko
2015-05-22 14:35 ` [RFC/RFT PATCH 6/7] gpio: omap: clean up omap_gpio_irq_type Grygorii Strashko
2015-05-22 17:53 ` Tony Lindgren
2015-05-22 14:35 ` [RFC/RFT PATCH v2 7/7] gpio: omap: ensure that runtime pm will disable unused gpio banks Grygorii Strashko
2015-05-22 18:10 ` Tony Lindgren
2015-05-25 14:46 ` Grygorii.Strashko@linaro.org
2015-05-25 15:08 ` Grygorii.Strashko@linaro.org [this message]
2015-05-22 19:03 ` [RFC/RFT PATCH 0/7] gpio: omap: rework and fixes Tony Lindgren
2015-06-01 13:15 ` Linus Walleij
2015-06-01 17:14 ` santosh shilimkar
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=55633AD7.8060806@linaro.org \
--to=grygorii.strashko@linaro.org \
--cc=gnurou@gmail.com \
--cc=javier@dowhile0.org \
--cc=khilman@deeprootsystems.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=ssantosh@kernel.org \
--cc=tony@atomide.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).