3dea30ca5b
ARConnect/MCIP IPI sending has a retry-wait loop in case caller had not seen a previous such interrupt. Turns out that it is not needed at all. Linux cross core calling allows coalescing multiple IPIs to same receiver - it is fine as long as there is one. This logic is built into upper layer already, at a higher level of abstraction. ipi_send_msg_one() sets the actual msg payload, but it only calls MCIP IPI sending if msg holder was empty (using atomic-set-new-and-get-old construct). Thus it is unlikely that the retry-wait looping was ever getting exercised at all. Cc: Chuck Jordan <cjordan@synopsys.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> |
||
|---|---|---|
| .. | ||
| boot | ||
| configs | ||
| include | ||
| kernel | ||
| lib | ||
| mm | ||
| oprofile | ||
| plat-axs10x | ||
| plat-sim | ||
| plat-tb10x | ||
| Kbuild | ||
| Kconfig | ||
| Kconfig.debug | ||
| Makefile | ||