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.
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.
This patch is already pulled in to Greg's tree.
--
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
