linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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