Thread (1 message) 1 message, 1 author, 2015-02-04
DORMANTno replies

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

From: Mitchel Humpherys <hidden>
Date: 2015-02-04 17:19:06
Also in: linux-iommu

On Wed, Feb 04 2015 at 03:33:05 AM, Will Deacon [off-list ref] wrote:
On Mon, Feb 02, 2015 at 08:10:02PM +0000, Mitchel Humpherys wrote:
quoted
On Wed, Jan 28 2015 at 04:07:39 AM, Will Deacon [off-list ref] wrote:
quoted
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.
But we'll need to turn on clocks just to read the FSR, which can't be
done from atomic context.
quoted
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.
Yeah I'll try to come up with something.  In this particular case I
guess we'd actually have to call out to some iommu_enable_access API so
it wouldn't be completely transparent.  Everywhere else I think the
iommu core can wrap the various iommu_ops callbacks with the
enable/disable calls.


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help