Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread

From: Tony Lindgren
Date: Tue Mar 28 2017 - 11:47:48 EST


* Mark Brown <broonie@xxxxxxxxxx> [170328 08:21]:
> On Mon, Mar 27, 2017 at 05:36:48PM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@xxxxxxxxxx> [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