Messages in this thread | | | Date | Mon, 12 Jun 2017 19:11:34 -0700 | From | Stephen Boyd <> | Subject | Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs |
| |
On 06/06, kgunda@codeaurora.org wrote: > On 2017-05-31 07:27, Stephen Boyd wrote: > >On 05/30, Kiran Gunda wrote: > >>From: Abhijeet Dharmapurikar <adharmap@codeaurora.org> > >> > >>We see a unmapped irqs trigger right around bootup. This could > >>likely be because the bootloader exited leaving the interrupts > >>in an unknown or unhandled state. Ack and mask the interrupt > >>if one is found. A request_irq later will unmask it and also > >>setup proper mapping structures. > > > >Do we have systems where this is causing an interrupt storm due > >to a level high interrupt or something? Just plain acking and > >masking irqs at boot if we don't have an irq descriptor created > >yet doesn't sound like a good idea, because we'll lose all > >interrupts that happen before this driver probes? > > > Yes. There were instances of an interrupt storm without this patch. > There is an RT_STATUS register in the peripheral address space which > maintains the real time state and can be read by the client driver > before it registers for the irq. Few client drivers such as charger > already doing this.
So you're saying that drivers need to read RT_STATUS to know if they have a pending interrupt before requesting it? That sounds bogus.
-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
| |