On 06/06, kgunda@xxxxxxxxxxxxxx wrote: > On 2017-05-31 07:27, Stephen Boyd wrote: > >On 05/30, Kiran Gunda wrote: > >>From: Abhijeet Dharmapurikar <adharmap@xxxxxxxxxxxxxx> > >> > >>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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
