Re: [PATCH 05/13] irqchip: add initial support for ompic

[Marc Zyngier]

On 03/09/17 23:12, Stafford Horne wrote:
> On Fri, Sep 01, 2017 at 06:25:01PM +0100, Marc Zyngier wrote:
>> On 01/09/17 02:24, Stafford Horne wrote:
>>> On Thu, Aug 31, 2017 at 10:28:01AM +0100, Marc Zyngier wrote:
>>>> On 30/08/17 22:58, Stafford Horne wrote:
>>>>> From: Stefan Kristiansson <stefan.kristiansson@xxxxxxxxxxxxx>

[...]

>>>>> +	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...