From: "Grygorii.Strashko@linaro.org" <grygorii.strashko@linaro.org>
To: Tony Lindgren <tony@atomide.com>,
"Grygorii.Strashko@linaro.org" <grygorii.strashko@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
linux-gpio@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Felipe Balbi <balbi@ti.com>,
Javier Martinez Canillas <jmartinez@softcrates.net>,
Nishanth Menon <nm@ti.com>
Subject: Re: [PATCH 1/1] gpio: omap: Fix PM runtime issue and remove most BANK_USED macros
Date: Wed, 29 Apr 2015 00:57:23 +0300 [thread overview]
Message-ID: <55400243.4040504@linaro.org> (raw)
In-Reply-To: <20150423143952.GR18048@atomide.com>
Hi Tony,
Sorry for delayed reply.
On 04/23/2015 05:39 PM, Tony Lindgren wrote:
> * Grygorii.Strashko@linaro.org <grygorii.strashko@linaro.org> [150423 04:13]:
>> On 04/21/2015 07:08 PM, Tony Lindgren wrote:
>>> @@ -438,11 +447,30 @@ static void omap_enable_gpio_module(struct gpio_bank *bank, unsigned offset)
>>> writel_relaxed(ctrl, reg);
>>> bank->context.ctrl = ctrl;
>>> }
>>> +
>>> + if (is_irq) {
>>> + omap_set_gpio_direction(bank, offset, 1);
>>> + bank->irq_usage |= BIT(offset);
>>> + } else {
>>> + omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
>>> + bank->mod_usage |= BIT(offset);
>>> + }
>>
>> The OMAP GPIO driver implements two Core interfaces IRQ-chip and GPIO-chip which, in general,
>> more or less independent.
>>
>> So, I don't think, that it's good to mix GPIO-IRQ-chip specific code with GPIO-chip code.
>> And this even don't really correspond the purpose of omap_enable_gpio_module() :( and might
>> introduce misunderstanding of code. The worst thing is that future fixes in IRQ-chip may
>> affect on on GPIO-chip and vise versa :(
>
> Hmm I'm thinking omap_enable/disable_gpio_module() eventually becomes
> our runtime_resume/suspend(). Currently the enabling and disabling is
> buggy for GPIO for some corner cases.. AFAIK the only difference between
It might be very helpful if you'd able to share additional info about
any "corner cases" you know.
> enabling GPIO vs GPIO-IRQ is the calling of omap_set_gpio_direction
> vs omap_set_gpio_triggering. Or at least that's the way it should be
> unless I'm missing something?
I think yes. what i'd like to say, first of all, is that it might be not good idea to mix
too much functionality in omap_enable/disable_gpio_module() - especially GPIO-IRQ vs
GPIO-chip ( Very easy to get lost ;)
For example (1) - your change of omap_gpio_request() looks like invalid:
static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
- unsigned long flags;
- /*
- * If this is the first gpio_request for the bank,
- * enable the bank module.
- */
- if (!BANK_USED(bank))
- pm_runtime_get_sync(bank->dev);
-
- spin_lock_irqsave(&bank->lock, flags);
- /* Set trigger to none. You need to enable the desired trigger with
- * request_irq() or set_irq_type(). Only do this if the IRQ line has
- * not already been requested.
- */
- if (!LINE_USED(bank->irq_usage, offset)) {
- omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
- omap_enable_gpio_module(bank, offset);
^^ above two line should be executed only if GPIO line was not requested as IRQ before
- }
- bank->mod_usage |= BIT(offset);
- spin_unlock_irqrestore(&bank->lock, flags);
+ omap_enable_gpio_module(bank, offset, false);
^^ after your change, it looks like omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE)
will be called always and GPIO triggering configuration might be lost
return 0;
}
Example (2)
I've found commit 55b6019ae294 "OMAP: GPIO: clear/restore level/edge detect settings on mask/unmask"
which does the following
gpio_mask_irq()
|- _set_gpio_triggering(bank, get_gpio_index(gpio), IRQ_TYPE_NONE);
gpio_unmask_irq()
|- u32 trigger = irqd_get_trigger_type(d);
if (trigger)
omap_set_gpio_triggering(bank, offset, trigger);
As result, it seems unreasonable to physically configure IRQ triggering type in GPIO bank registers
inside omap_gpio_irq_type(). Of course, such assumption should be double checked taking into account that
__irq_set_trigger() can be called any time even before request_irq().
Also, seems the same could be applied to omap_enable_gpio_module and omap_set_gpio_direction and they
could be removed from omap_gpio_irq_type().
>
>> Could we keep omap_xxx_gpio_module() functions responsible only for GPIO bank PM and
>> enabling/disabling?
>
> If you're thinking about just thinking about having separate wrappers around
> it like this::
>
> static void omap_enable_gpio_module(struct gpio_bank *bank, unsigned offset,
> bool is_irq)
> {
> ...
> }
>
> static void omap_enable_gpio((struct gpio_bank *bank, unsigned offset)
> {
> omap_enable_gpio_module(bpio_bank, offset, 0);
> }
>
> static void omap_enable_gpio_irq((struct gpio_bank *bank, unsigned offset)
> {
> omap_enable_gpio_module(bpio_bank, offset, 1);
> }
>
> Then yes makes sense to me. Or do you have something else in mind?
Yep. Commented above.
Also, it probably could work if we will set GPIO_CTRL.DISABLEMODULE=1
in omap_gpio_runtime_resume and GPIO_CTRL.DISABLEMODULE=0 in _runtime_suspend,
but it may require from us to split CPUIdle and suspend code path (
--
regards,
-grygorii
next prev parent reply other threads:[~2015-04-28 21:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-21 16:08 [PATCH 1/1] gpio: omap: Fix PM runtime issue and remove most BANK_USED macros Tony Lindgren
2015-04-22 14:20 ` Felipe Balbi
2015-04-23 11:12 ` Grygorii.Strashko@linaro.org
2015-04-23 14:39 ` Tony Lindgren
2015-04-28 21:57 ` Grygorii.Strashko@linaro.org [this message]
2015-04-29 14:26 ` Tony Lindgren
2015-04-30 19:10 ` Grygorii.Strashko@linaro.org
2015-04-30 21:12 ` Tony Lindgren
2015-05-02 16:27 ` Grygorii.Strashko@linaro.org
2015-05-04 15:38 ` Tony Lindgren
2015-05-12 9:00 ` Linus Walleij
2015-05-12 14:13 ` Tony Lindgren
2015-05-12 15:31 ` Grygorii.Strashko@linaro.org
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=55400243.4040504@linaro.org \
--to=grygorii.strashko@linaro.org \
--cc=balbi@ti.com \
--cc=gnurou@gmail.com \
--cc=jmartinez@softcrates.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--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).