From: Mark Brown <broonie@kernel.org>
To: Yi Zhang <yizhang.mrvl@gmail.com>
Cc: linux-kernel@vger.kernel.org, Yi Zhang <yizhang@marvell.com>,
zhangwm@marvell.com, shayp@marvell.com, zhouqiao@marvell.com
Subject: Re: [Question] is it a race condition in acking PMIC sub-interrupt?
Date: Sun, 22 Jun 2014 12:12:44 +0100 [thread overview]
Message-ID: <20140622111244.GU24291@sirena.org.uk> (raw)
In-Reply-To: <CAK=oMXftjqjoM2gCrgyc+YkznCOz-V=McEx74xPbxZ2O-UFmFQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]
On Thu, Jun 19, 2014 at 08:34:12PM +0800, Yi Zhang wrote:
> 2) there are several interrupt ack registers in PMIC; in
> regmap_irq_thread(), we acked them one by one; but if before we finish
> acking all the registers, another interrupt on the "has-been-acked
> register" is triggered, the interrupt line will be pulled up or down,
> in the 1) case, because GPIO is edge triggered, it cannot "see" this
> interrupt, then GIC cannot know either; while in regmap_irq_thread(),
> the software thinks it has acked all the interrupt, then goes on; but
> actually the interrupt is missed and cannot be resumed in the 1)
> scenario;
You really shouldn't be using an edge triggered interrupt controller in
an application like this.
> So if this is true, what about using the following methods to fix it?
> a) disable all the interrupts just before ack, then enable them after
> ack finished; the cons are a) the interrupt is ignored in the process;
> b) we need to manipulate the registers more frequently, after all, I2C
> is a slow bus;
> b) polling until the interrupts are acked; but I think it's hard to
> guarantee that because the interrupt is asynchronous;
Right. If the edge triggered controller is getting a level triggered
signal (which sounds like the case) then what you can probably do here
is wrap the main interrupt loop with code that checks the state of the
GPIO directly and re-calls the interrupt if it's still asserted when the
interrupt finishes. wm8994 has some workaround code for a situation
that sounds very like yours. If it's just getting a pulse you're in
trouble here and you have to poll but like you say it's hard to
guarantee.
> and one more question:
> Seems we shouldn't connect an interrupt controller as PMIC with an
> edge triggered interrupt controller? Could you please share your
> opinion? we can modify the hardware connection accordingly;
That's definitely the best option, muxing multiple interrupts is much
simpler and more reliable when everything is level triggered.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2014-06-22 11:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-19 12:34 Yi Zhang
2014-06-22 11:12 ` Mark Brown [this message]
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=20140622111244.GU24291@sirena.org.uk \
--to=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shayp@marvell.com \
--cc=yizhang.mrvl@gmail.com \
--cc=yizhang@marvell.com \
--cc=zhangwm@marvell.com \
--cc=zhouqiao@marvell.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
all inboxes | Powered by JetHome®