linux/arch/arc, 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

ARC: [intc-compact] Remove IPI setup from ARCompact port

2016-02-24T05:37:31Z

There is no real ARC700 based SMP SoC so remove IPI definition. EZChip's SMP ARC700 is going to use a different intc and IPI provider anyways. 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

arc: get rid of DEVTMPFS dependency on INITRAMFS_SOURCE

2016-02-23T07:01:04Z

Even though DEVTMPFS is required when our pre-built initramfs is used it is not the case in general. It is perfectly possible to use initramfs with device nodes already populated or there could be other usages, see discussion below for more detials: http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/37819/focus=37821 This change removes mentioned dependency from arch/arc/Kconfig updating instead those defconfigs that are usually used with this kind of pre-build initramfs. And while at it all touched defconfigs were regenerated via savedefconfig and some options were removed: * USB is selected by other options implicitly * VGA_CONSOLE is disableb for ARC since 031e29b5877f31676739dc2f847d04c2c0732034 * EXT3_FS automatically selects EXT4_FS * MTDxxx and JFFS2_FS make no sense for AXS because AXS NAND controller is not upstreamed * NET_OSCI_LAN is not in upstream as well * ARCPGU_xxx options make no sense because ARC PGU is not yet in upstream and when it gets there all config options would be taken from devicetree Signed-off-by: Alexey Brodkin Signed-off-by: Vineet Gupta

ARCv2: boot report CCMs (Closely Coupled Memories)

2016-02-18T12:00:18Z

- ARCv2 uses a seperate BCR for {I,D}CCM base address: ARCompact encoded both base/size in same BCR - Size encoding in common BCR is different for ARCompact/ARCv2 Signed-off-by: Vineet Gupta

ARCv2: boot print Low Latency Memory

2016-02-18T12:00:17Z

Signed-off-by: Vineet Gupta

ARC: Assume multiplier is always present

2016-02-18T12:00:03Z

It is unlikely that designs running Linux will not have multiplier. Further the current support is not complete as tool don't generate a multilib w/o multiplier. Signed-off-by: Vineet Gupta