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: Fri, 05 Jun 2009 14:34:48 -0700 [thread overview]
Message-ID: <87ljo68ivb.fsf@deeprootsystems.com> (raw)
In-Reply-To: <B00E06E2766C2744B022DE9BAF3C59D5372EFA@zmy16exm69.ds.mot.com> (Wang Sawsd-A's message of "Sat\, 6 Jun 2009 03\:06\:40 +0800")
"Wang Sawsd-A24013" <cqwang@motorola.com> writes:
>> Could you try this patch with your TS GPIO configured as
>> level-triggered?
>>
>
> I tried the below patch, it can solve the issue also.
>
Thanks for testing.
This whole time, you're probably wondering... "why doesn't Kevin just
add the disable and enable hooks and be done with it." I don't think
I've explained myself there yet so let me try to explain so I don't
come across as refusing your original idea for no good reason other
than being stubborn.
We basically have the option of doing it in my proposed patch, which
adds additional overhead to the mask/unmask hooks or we can just add
disable/enable hooks as you did in your original patch.
The reason I prefer not to add disable/enable hooks is to take
advantage of the lazy disable feature. With lazy disable, by waiting
to actually disable, it allows us to handle potentially lost
interrupts and this is especially important for wakeup interrupts. An
interesting example this is interrupts that are lazy disabled during
suspend/resume.
For example, if a wakeup interrupt happens between the drivers
disable_irq(), what you want is for this interrupt to cancel suspend.
If you you implement a ->disable hook, and thus mask interrupts in HW
immediately, you will loose this interrupt. With lazy disable, the
drivers ISR will not be called, but genirq will see this interrupt and
set IRQ_PENDING. Late in the suspend path, IRQs that are IRQ_WAKEUP
and IRQ_PENDING will cancel suspend (see
kernel/irq/pm.c:check_wakeup_irqs())
Another possible scenario is an interrupt that happens between HW
resume and the drivers enable_irq() hook. With lazy disable, this
interrupt will be IRQ_PENDING when enable_irq() gets called and be
triggered/handled immedately.
Hope that helps explain my stubborness, ;)
Of course this doesn't mean it's an absolute decision. As always, I'm
certainly open to being pursuaded that there are other better reasons
for doing it differently.
Kevin
next prev parent reply other threads:[~2009-06-05 21:34 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
2009-06-05 19:06 ` Wang Sawsd-A24013
2009-06-05 21:34 ` Kevin Hilman [this message]
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=87ljo68ivb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox