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

ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core

2016-11-08T20:22:52Z

ARC linux uses 2 distribution modes for common interrupts: round robin mode (IDU_M_DISTRI_RR) and a simple destination mode (IDU_M_DISTRI_DEST). The first one is used when more than 1 cores may handle a common interrupt and the second one is used when only 1 core may handle a common interrupt. However idu_irq_set_affinity() always sets IDU_M_DISTRI_RR for all affinity values. But there is no sense in setting of such mode if only 1 core must handle a common interrupt. Signed-off-by: Yuriy Kolerov Signed-off-by: Vineet Gupta

ARC: IRQ: Do not use hwirq as virq and vice versa

2016-11-08T20:05:10Z

This came up when reviewing code to address missing IRQ affinity setting in AXS103 platform and/or implementing hierarchical IRQ domains - smp_ipi_irq_setup() callers pass hwirq but in turn calls request_percpu_irq() which expects a linux virq. So invoke irq_find_mapping() to do the conversion (also explicitify this in code by renaming the args appropriately) - idu_of_init()/idu_cascade_isr() were similarly using linux virq where hwirq is expected, so do the conversion using irqd_to_hwirq() helper Signed-off-by: Yuriy Kolerov [vgupta: made changelog a bit concise a bit] Signed-off-by: Vineet Gupta

ARCv2: intc: untangle SMP, MCIP and IDU

2016-10-16T22:49:07Z

The IDU intc is technically part of MCIP (Multi-core IP) hence historically was only available in a SMP hardware build (and thus only in a SMP kernel build). Now that hardware restriction has been lifted, so a UP kernel needs to support it. This requires breaking mcip.c into parts which are strictly SMP (inter-core interrupts) and IDU which in reality is just another intc and thus has no bearing on SMP. This change allows IDU in UP builds and with a suitable device tree, we can have the cascaded intc system ARCv2 core intc <---> ARCv2 IDU intc <---> periperals Signed-off-by: Vineet Gupta

ARC: irq: export some IRQs again

2016-05-09T04:02:30Z

This will be needed for switching to linear irq domain as irq_create_mapping() called by intr code needs the IRQ numbers in addition to existing usage in mcip.c for requesting the irq Signed-off-by: Vineet Gupta

ARC: clocksource: DT based probe

2016-05-09T04:02:30Z

- Remove explicit clocksource setup and let it be done by OF framework by defining CLOCKSOURCE_OF_DECLARE() for various timers - This allows multiple clocksources to be potentially registered simultaneouly: previously we could only do one - as all of them had same arc_counter_setup() routine for registration - Setup routines also ensure that the underlying timer actually exists. - Remove some of the panic() calls if underlying timer is NOT detected as fallback clocksource might still be available 1. If GRFC doesn't exist, jiffies clocksource gets registered anyways 2. if RTC doesn't exist, TIMER1 can take over (as it is always present) Cc: Daniel Lezcano Signed-off-by: Vineet Gupta

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