From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Dmitry Artamonow <mad_soft@inbox.ru>
Subject: Re: [PATCH 7/9] ARM: sa1100: move gpio irq handling to GPIO driver
Date: Fri, 22 Nov 2013 20:02:42 +0000 [thread overview]
Message-ID: <20131122200242.GE16735@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CALT56yM1rf7onJNu6L9tG52RrmDXcuWSoa=JfpakZRO+e7vnEQ@mail.gmail.com>
On Fri, Nov 22, 2013 at 11:46:10PM +0400, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> On Fri, Nov 22, 2013 at 9:45 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Therefore, if we want to have certain GPIOs triggering wakeups (iow,
> > those GPIOs which have had enable_irq_wake() called on them) but not
> > those which haven't, we need to reprogram GRER and GFER with the
> > GPIOs which can wake the system up.
>
> I thought so. I was puzzled, because that would mean, that we want to wake
> up from a GPIO, which is masked in GPIO_IRQ_mask, but enabled in PWER.
> Is that the real scenario/usecase? If we/kernel has disabled IRQ
> through _mask_irq,
> I thought, we didn't expect events from that pin (including wakeup), did we?
So, if a device driver decides that it wants to be woken up by a GPIO
and therefore calls enable_irq_wake() on it, but also calls disable_irq()
on that same interrupt to avoid _receiving_ the interrupt until it's
ready, does that mean that the system should _not_ be woken up?
I doubt many systems work this way - later PXA devices certainly don't,
where the wakeup is triggered from the silicon on the pad interface
rather than the interrupt controller - where the state of the IRQ masks
have no bearing what so ever on it.
Please, stop thinking about changing the behaviour of any of the SA11x0
stuff. Treat the code as-is as authoritive on the way things should be
done, and _carefully_ "adjust it" to how you'd like to see it - so we
can have a higher confidence that stuff isn't being broken or behaviour
isn't changed.
Such behaviour changes would include looping differently while handling
interrupts.
And more importantly, treat SA11x0 as a reference implementation for
IRQ stuff; that's the platform I developed the IRQ handling stuff on
which became the basis for tglx's IRQ layer in the kernel.
next prev parent reply other threads:[~2013-11-22 20:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-15 8:47 [PATCH 0/9] ARM: sa1100: Rework IRQ handling Dmitry Eremin-Solenikov
2013-11-15 8:47 ` [PATCH 1/9] ARM: sa1100 collie: use gpio-charger instead of pda-power Dmitry Eremin-Solenikov
2013-11-15 8:47 ` [PATCH 2/9] ARM: locomo: don't clobber chip data for chained irq Dmitry Eremin-Solenikov
2013-11-15 8:47 ` [PATCH 3/9] ARM: sa1100: switch to MULTI_IRQ_HANDLER Dmitry Eremin-Solenikov
2013-11-15 8:47 ` [PATCH 4/9] ARM: sa1100: convert gpio driver to be a proper platform driver Dmitry Eremin-Solenikov
2013-11-19 10:08 ` Linus Walleij
2013-11-15 8:47 ` [PATCH 5/9] ARM: sa1100: add platform functions to handle PWER settings Dmitry Eremin-Solenikov
2013-11-15 8:47 ` [PATCH 6/9] ARM: sa1100: enable IRQ domains Dmitry Eremin-Solenikov
2013-11-15 8:47 ` [PATCH 7/9] ARM: sa1100: move gpio irq handling to GPIO driver Dmitry Eremin-Solenikov
2013-11-22 17:45 ` Russell King - ARM Linux
2013-11-22 19:46 ` Dmitry Eremin-Solenikov
2013-11-22 20:02 ` Russell King - ARM Linux [this message]
2013-11-22 21:20 ` Dmitry Eremin-Solenikov
2013-11-15 8:47 ` [PATCH 8/9] ARM: sa1100: move per-IRQ PWER settings to core code Dmitry Eremin-Solenikov
2013-11-15 8:48 ` [PATCH 9/9] ARM: sa1100: refactor irq driver Dmitry Eremin-Solenikov
2013-11-19 13:00 ` [PATCH 0/9] ARM: sa1100: Rework IRQ handling Linus Walleij
2013-11-19 15:17 ` Dmitry Eremin-Solenikov
2013-11-19 20:24 ` Linus Walleij
2013-11-20 0:20 ` Russell King - ARM Linux
2013-11-20 0:45 ` Dmitry Eremin-Solenikov
2013-11-20 7:43 ` Dmitry Artamonow
2013-11-22 17:58 ` Russell King - ARM Linux
2013-11-22 19:12 ` Dmitry Eremin-Solenikov
2013-11-22 19:51 ` Russell King - ARM Linux
2013-11-22 21:23 ` Dmitry Eremin-Solenikov
2013-11-20 0:40 ` Dmitry Eremin-Solenikov
2013-11-22 17:33 ` Dmitry Eremin-Solenikov
2013-11-22 21:35 ` Dmitry Eremin-Solenikov
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=20131122200242.GE16735@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=dbaryshkov@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mad_soft@inbox.ru \
/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).