On Wed, Feb 04 2015 at 03:33:05 AM, Will Deacon <will.dea...@arm.com> wrote: > 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.dea...@arm.com> 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.
But we'll need to turn on clocks just to read the FSR, which can't be done from atomic context. > >> 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 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
