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? > > Also the current driver ensures that no read/write transaction > is in progress while it makes changes to the interrupt regions. > This is not necessary because read/writes over spmi and arbiter > interrupt control are independent operations. Hence, remove the > synchronized accesses to interrupt region. That's another patch for this paragraph. -- 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
