linux/arch/arc/kernel/mcip.c, branch v4.5

arc: SMP: CONFIG_ARC_IPI_DBG cleanup

2016-02-24T08:45:39Z

Previous Commit ("ARC: SMP: No need for CONFIG_ARC_IPI_DBG") removed the Kconfig option ARC_IPI_DBG. Remove the last reference on this option. Signed-off-by: Valentin Rothberg Signed-off-by: Vineet Gupta

ARC: SMP: No need for CONFIG_ARC_IPI_DBG

2016-02-24T05:37:32Z

This was more relevant during SMP bringup. The warning for bogus msg better be visible always. Signed-off-by: Vineet Gupta

ARCv2: Elide sending new cross core intr if receiver didn't ack prev

2016-02-24T05:37:31Z

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 Cc: Peter Zijlstra Signed-off-by: Vineet Gupta

ARCv2: SMP: Push IPI_IRQ into IPI provider

2016-02-24T05:37:31Z

Signed-off-by: Vineet Gupta

ARCv2: SMP: Emulate IPI to self using software triggered interrupt

2016-02-24T05:37:28Z

ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to local core. So use core intc capability to trigger software interrupt to self, using an unsued IRQ #21. This showed up as csd deadlock with LTP trace_sched on a dual core system. This test acts as scheduler fuzzer, triggering all sorts of schedulting activity. Trouble starts with IPI to self, which doesn't get delivered (effectively lost due to H/w capability), but the msg intended to be sent remain enqueued in per-cpu @ipi_data. All subsequent IPIs to this core from other cores get elided due to the IPI coalescing optimization in ipi_send_msg_one() where a pending msg implies an IPI already sent and assumes other core is yet to ack it. After the elided IPI, other core simply goes into csd_lock_wait() but never comes out as this core never sees the interrupt. Fixes STAR 9001008624 Cc: Peter Zijlstra Cc: [4.2] Signed-off-by: Vineet Gupta

ARCv2: boot print Low Latency Memory

2016-02-18T12:00:17Z

Signed-off-by: Vineet Gupta

ARCv2: clocksource: Rename GRTC -> GFRC ...

2016-01-29T11:21:02Z

... it is now called Global Free Running Counter Signed-off-by: Vineet Gupta

ARC: rename smp operation init_irq_cpu() to init_per_cpu()

2015-12-17T07:26:43Z

This will better reflect its description i.e. "any needed setup..." and not just do an "IPI request". Signed-off-by: Noam Camus Acked-by: Vineet Gupta Signed-off-by: Vineet Gupta

ARCv2: smp: [plat-*]: No need to explicitly call mcip_init_smp()

2015-10-28T10:43:41Z

MCIP now registers it's own per cpu setup routine (for IPI IRQ request) using smp_ops.init_irq_cpu(). So no need for platforms to do that. This now completely decouples platforms from MCIP. Signed-off-by: Vineet Gupta

ARCv2: smp: [plat-*]: No need to explicitly call mcip_init_early_smp()

2015-10-28T10:43:40Z

MCIP now registers it's own probe callback with smp_ops.init_early_smp() which is called by ARC common code, so no need for platforms to do that. This decouples the platforms and MCIP and helps confine MCIP details to it's own file. Signed-off-by: Vineet Gupta