Messages in this thread | | | Subject | Re: [PATCH 4/4] irqchip: imgpdc: Pass on peripheral mask/unmasks to the parent | From | Ed Blake <> | Date | Thu, 5 Oct 2017 16:43:48 +0100 |
| |
On 05/10/17 16:26, James Hogan wrote: > On Thu, Oct 05, 2017 at 03:48:53PM +0100, Ed Blake wrote: >> >> I'm not sure how this is supposed to work, but the issue seems to be >> that without this patch the parent irq isn't being masked. This is >> causing the parent handler (MIPS GIC in this case) to be called >> continuously. This leads to the PDC irq being masked each time, but not >> the parent irq. This is the callstack: >> >> "irq-imgpdc.c"::perip_irq_mask >> mask_ack_irq >> handle_level_irq >> generic_handle_irq_desc >> generic_handle_irq >> generic_handle_irq_desc >> generic_handle_irq >> gic_handle_shared_int >> gic_handle_local_int >> "irq-mips-gic.c"::gic_irq_dispatch >> generic_handle_irq_desc >> generic_handle_irq >> do_IRQ >> plat_irq_dispatch() > Right, yeh it shouldn't technically be masked by the parent (contrary to > what I said above) because its a chained handler, i.e. as far as the > kernel knows there could be other IRQs coming through that GIC pin that > would also get masked. > > (though IIRC the perip IRQs can wake, but then they go straight out to > separate dedicated IRQ pins into the main IRQ chip, i.e. the GIC in this > case).
That's right, each of the PDC peripherals (RTC, WD, IR) has a dedicated IRQ to the parent, and the sys wakes are muxed onto a single IRQ. > I think its worth understanding the root cause here though. Disabling > routing of an IRQ fundamentally should deassert it. Is it an actual > hardware bug that has reached silicon?
So you think the PDC->parent IRQ must not be being de-asserted when IRQ_ROUTE is cleared? I hadn't considered this and thought it was some persistence in the GIC due to not being masked / ack'd there. Is that possible? I'll discuss the possible IRQ_ROUTE issue with the hardware team.
Ed.
| |