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 <[email protected]> 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 _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
