Revision 3dea30ca5bef0e013abe857057a952a9d6757fe5 authored by Vineet Gupta on 19 February 2016, 02:27:41 UTC, committed by Vineet Gupta on 24 February 2016, 05:37:31 UTC
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>
1 parent 9681787
| File | Mode | Size |
|---|---|---|
| .gitignore | -rw-r--r-- | 151 bytes |
| Kconfig | -rw-r--r-- | 2.9 KB |
| Makefile | -rw-r--r-- | 2.3 KB |
| gen_init_cpio.c | -rw-r--r-- | 12.7 KB |
| initramfs_data.S | -rw-r--r-- | 1.3 KB |
Computing file changes ...
