* 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
