On 03/09/17 23:12, Stafford Horne wrote:

On Fri, Sep 01, 2017 at 06:25:01PM +0100, Marc Zyngier wrote:

quoted

On 01/09/17 02:24, Stafford Horne wrote:

quoted

On Thu, Aug 31, 2017 at 10:28:01AM +0100, Marc Zyngier wrote:

quoted

On 30/08/17 22:58, Stafford Horne wrote:

quoted

From: Stefan Kristiansson <redacted>

[...]

quoted

quoted

quoted

quoted

+	unsigned int dst_cpu;
+	unsigned int src_cpu = smp_processor_id();
+
+	for_each_cpu(dst_cpu, mask) {
+		set_bit(irq, &ipi_data[dst_cpu].ops);
+
+		ompic_writereg(ompic_base, OMPIC_IPI_CTRL(src_cpu),
+			       OMPIC_IPI_CTRL_IRQ_GEN |
+			       OMPIC_IPI_CTRL_DST(dst_cpu) |
+			       OMPIC_IPI_DATA(1));

What guarantees that the action of set_bit can be observed by the target
CPU? set-bit gives you atomicity, but no barrier.

The bit will not be read by target CPUs until after the ompic_writereg()
which will trigger the target CPU interrupt to be raised.  OpenRISC stores
are ordered.

Are they really ordered irrespective of the memory type (one is
cacheable RAM, the other is a device...)?

And assuming they are (which I find a bit odd), that doesn't necessarily
guarantee that the interrupt will only be delivered once the effect of
set_bit can be seen on the target CPU...

OpenRISC might be a bit odd here, but I think this is correct.  On OpenRISC
the atomic instructions also imply a pipeline flush for stores and loads
(l.swa/l.lwa).  This is highlighted in the architecture spec section 7.3 [0].

OK, fair enough. This is quite unusual (and I'm prepared to bet that
this will be relaxed in future evolutions of the architecture), but
that's indeed the gospel.

Please add a comment between set_bit and writereg so that we know we've
been through this discussion already.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html