From: Kevin Hilman <khilman@deeprootsystems.com>
To: Wang Sawsd-A24013 <cqwang@motorola.com>
Cc: linux-omap@vger.kernel.org, nm@ti.com, Mike Chan <mikechan@google.com>
Subject: Re: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
Date: Thu, 04 Jun 2009 16:01:46 -0700 [thread overview]
Message-ID: <87d49jeh7p.fsf@deeprootsystems.com> (raw)
In-Reply-To: <B00E06E2766C2744B022DE9BAF3C59D5372B9F@zmy16exm69.ds.mot.com> (Wang Sawsd-A's message of "Fri\, 5 Jun 2009 05\:58\:18 +0800")
"Wang Sawsd-A24013" <cqwang@motorola.com> writes:
>
>> What do you think about disabling the level/edge detection when
>> disable_irq_wake() is called instead? This seems more logical
>> and expected.
>
> Kevin, if we look at the current code, enable_irq_wake and
> disable_irq_wake Does not even touch any GPIO WAKEEN register, it
> seems it is intended To just log the gpio bit and enable its WAKEUP
> and IOPAD wakeup when suspend happens.
Correct.
> And also, enable_irq_wake/disable_irq_wake
> Are designed to be able used when both IRQ is enabled AND disabled,
> In another words, enable_irq_wake may be called after irq_disable,
> Disable_irq_wake may be called after irq_enable, if we change
> Level/edge detect then it may cause either IRQ never happen
Good point.
> After irq_enable, or IRQ staus bit also set after irq_disable. Since
> The root reason is the level/edge detect can cause IRQ status, it
> Is related with IRQ, not wakeup.
Correct again.
> What do you think?
I'm thinking I'm not thinking very clearly on the subject today. It's
too hot in Seattle today. ;)
I'm also thinking that this isn't just going to be a problem with
suspend/resume but also for hitting retention in idle. Any
level-triggered GPIO IRQ that is masked, yet still has level/edge
detect configured can prevent retention during idle since it will
cause IRQ status as you've pointed out.
Can you think of any reason not to disable the level/edge detect in
the ->mask() hook and to re-enable it in the ->unmask hook? Something
like the patch below?
Could you try this patch with your TS GPIO configured as level-triggered?
Kevin
commit f8eb69a2edd684c9e0b72bc3c84c6af9718bd4a4
Author: Kevin Hilman <khilman@deeprootsystems.com>
Date: Thu Jun 4 15:57:10 2009 -0700
OMAP: GPIO: clear/restore level/edge detect settings on mask/unmask
<needs detailed description>
Signed-off-by: Kevin Hilman <khilman@ti.deeprootsystems.com>
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 3b2054b..83ac494 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1135,6 +1135,7 @@ static void gpio_mask_irq(unsigned int irq)
struct gpio_bank *bank = get_irq_chip_data(irq);
_set_gpio_irqenable(bank, gpio, 0);
+ _set_gpio_triggering(bank, get_gpio_index(gpio), IRQ_TYPE_NONE);
}
static void gpio_unmask_irq(unsigned int irq)
@@ -1142,6 +1143,11 @@ static void gpio_unmask_irq(unsigned int irq)
unsigned int gpio = irq - IH_GPIO_BASE;
struct gpio_bank *bank = get_irq_chip_data(irq);
unsigned int irq_mask = 1 << get_gpio_index(gpio);
+ struct irq_desc *desc = irq_to_desc(irq);
+ u32 trigger = desc->status & IRQ_TYPE_SENSE_MASK;
+
+ if (trigger)
+ _set_gpio_triggering(bank, get_gpio_index(gpio), trigger);
/* For level-triggered GPIOs, the clearing must be done after
* the HW source is cleared, thus after the handler has run */
next prev parent reply other threads:[~2009-06-04 23:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <B00E06E2766C2744B022DE9BAF3C59D5372B95@zmy16exm69.ds.mot.com>
2009-06-04 21:38 ` [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable Kevin Hilman
2009-06-04 21:58 ` Wang Sawsd-A24013
2009-06-04 23:01 ` Kevin Hilman [this message]
2009-06-05 19:06 ` Wang Sawsd-A24013
2009-06-05 21:34 ` Kevin Hilman
2009-06-05 23:57 ` Wang Sawsd-A24013
2009-06-01 23:49 Wang Sawsd-A24013
2009-06-02 15:11 ` Kevin Hilman
2009-06-02 17:18 ` Wang Sawsd-A24013
2009-06-03 1:43 ` Kevin Hilman
2009-06-03 22:02 ` Wang Sawsd-A24013
2009-06-04 17:04 ` Kevin Hilman
2009-06-04 17:43 ` Wang Sawsd-A24013
-- strict thread matches above, loose matches on Subject: below --
2009-06-01 23:24 Wang Sawsd-A24013
2009-08-05 12:33 ` Tony Lindgren
2009-08-05 14:36 ` Kevin Hilman
2009-08-05 15:11 ` Tony Lindgren
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=87d49jeh7p.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=cqwang@motorola.com \
--cc=linux-omap@vger.kernel.org \
--cc=mikechan@google.com \
--cc=nm@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.