Re: [PATCH] iommu/arm-smmu: use a threaded handler for context interrupts

[Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>]

On Mon, Feb 02, 2015 at 08:10:02PM +0000, Mitchel Humpherys wrote:
> On Wed, Jan 28 2015 at 04:07:39 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> > With a shared handler (e.g. a bunch of context banks have the same IRQ)
> > then I assume that we don't want to end up with multiple handler threads
> > all tripping over each other. I'd rather have one thread that handles work
> > queued up by multiple low-level handlers.
> >
> > Do you have a preference either way?
> 
> Ok I think I understand the scenario you're describing.  If multiple
> context banks are sharing an interrupt line their handlers currently
> execute serially, but with threaded handlers they would all be woken up
> and possibly execute concurrently.  I hadn't really considered this
> because none of our targets have CBs sharing interrupts.  In any case,
> the CBs that aren't interrupting should quickly return IRQ_NONE when
> they notice that !(fsr & FSR_FAULT), so is this really a concern?

Well, with my stall-mode hat on, the FSR check could be done in the
low-level handler, with the actual page fault handling or whatever done
in the thread.

> Anyways, we can always hold off on this until we have a more compelling
> motivation for it.  For example, if we need to enable clocks to read
> registers then threaded IRQs seem like the best solution.  Hopefully
> I'll find time to have another go at the clocks stuff soon, which is the
> real reason why we're using threaded IRQs for context interrupts in our
> msm tree.

Okey doke. Having the clocks stuff supported in iommu core would be my
preference.

Will