From: Tony Lindgren <tony@atomide.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
Lee Jones <lee.jones@linaro.org>, Marcel Partap <mpartap@gmx.net>,
Michael Scott <michael.scott@linaro.org>
Subject: Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread
Date: Tue, 28 Mar 2017 08:47:41 -0700 [thread overview]
Message-ID: <20170328154740.GW10760@atomide.com> (raw)
In-Reply-To: <20170328151849.uvj2ljkbts4cwksq@sirena.org.uk>
* Mark Brown <broonie@kernel.org> [170328 08:21]:
> On Mon, Mar 27, 2017 at 05:36:48PM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@kernel.org> [170327 10:52]:
>
> > > So, I see your use case but the fact is that as Charles observed this is
> > > exactly the code used for emulating level triggered IRQs with edge
> > > triggered interrupt controllers. This means someone is doubtless going
> > > to end up using it for precisely that. This makes me uncomfortable, we
> > > do have this open coded into various drivers already but this is more of
> > > a core thing and it feels like this should be in genirq rather than
> > > here... that said, looking at the code:
>
> > Yes.. But then again we might avoid piling up yet more driver
> > specific hacks. I don't know what the genirq solution would look
>
> Right, my thinking here is that by pushing into genirq we minimise the
> need even further since it'll also be available to drivers not using
> regmap-irq.
>
> > like, handle until we get IRQ_NONE? :)
>
> Well, that's what the per driver emulation does so... yeah. Probably
> with an upper limit on the number of times we do that.
OK let's first see how that would work. I'll send a patch
for that.
> > > There's no protection against screaming interrupts here, I'd really like
> > > to see that. Also some tracing of the number of times we spin.
>
> > Good idea. How about something like below where handle_reread checks
> > for the total time spent in the thread loop with a large enough
> > timeout? Or do you have some better ideas in mind?
>
> > I tested I can hit that warning with timeout set to much lower
> > 10 ms with retries being 1 or 2 at that point.
>
> That looks sensible, yes.
OK
Regards,
Tony
next prev parent reply other threads:[~2017-03-28 15:47 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 17:10 [PATCHv2 0/4] Regmap IRQ fix and related changes CPCAP Tony Lindgren
2017-03-22 17:10 ` [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread Tony Lindgren
2017-03-27 17:49 ` Mark Brown
2017-03-28 0:36 ` Tony Lindgren
2017-03-28 15:18 ` Mark Brown
2017-03-28 15:47 ` Tony Lindgren [this message]
2017-03-28 16:49 ` Mark Brown
2017-03-28 17:10 ` Tony Lindgren
2017-04-04 3:03 ` Tony Lindgren
2017-04-04 12:19 ` Mark Brown
2017-04-04 13:56 ` Tony Lindgren
2017-04-04 15:28 ` Mark Brown
2017-04-03 11:27 ` Lee Jones
2017-03-22 17:10 ` [PATCH 2/4] mfd: cpcap: Use handle_reread flag for interrupts Tony Lindgren
2017-04-03 10:21 ` Lee Jones
2017-04-03 14:14 ` Tony Lindgren
2017-04-03 14:32 ` Lee Jones
2017-04-04 3:17 ` Tony Lindgren
2017-03-22 17:10 ` [PATCH 3/4] mfd: cpcap: Use ack_invert interrupts Tony Lindgren
2017-04-03 10:21 ` Lee Jones
2017-03-22 17:10 ` [PATCH 4/4] mfd: cpcap: Fix bad use of IRQ sense register Tony Lindgren
2017-04-03 10:21 ` Lee Jones
-- strict thread matches above, loose matches on Subject: below --
2017-03-17 0:36 [PATCH 0/4] Regmap IRQ fix and related changes CPCAP Tony Lindgren
2017-03-17 0:36 ` [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread Tony Lindgren
2017-03-20 15:14 ` Charles Keepax
2017-03-20 15:14 ` Charles Keepax
2017-03-20 15:33 ` Tony Lindgren
2017-03-21 9:23 ` Charles Keepax
2017-03-21 9:23 ` Charles Keepax
2017-03-21 15:41 ` Tony Lindgren
2017-03-21 16:43 ` Charles Keepax
2017-03-21 16:43 ` Charles Keepax
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=20170328154740.GW10760@atomide.com \
--to=tony@atomide.com \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=michael.scott@linaro.org \
--cc=mpartap@gmx.net \
/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.