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
Kconfig
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
config SRCARCH
string
option env="SRCARCH"
source "arch/$SRCARCH/Kconfig"
Computing file changes ...
