RFC on writel and writel_relaxed

Sinan Kaya okaya at codeaurora.org
Thu Mar 22 02:04:19 AEDT 2018


On 3/21/2018 9:35 AM, David Laight wrote:
>> x86 has compiler barrier inside the relaxed() API so that code does not
>> get reordered. ARM64 architecturally guarantees device writes to be observed
>> in order.
> 
> There are places where you don't even need a compile barrier between
> every write.
> 
> I had horrid problems getting some ppc code (for a specific embedded SoC)
> optimised to have no extra barriers.
> I ended up just writing through 'pointer to volatile' and adding an
> explicit 'eieio' between the block of writes and status read.
> 
> No less painful was doing a byteswapping write to normal memory.

If the architecture is reordering writes to the peripheral, then removing
the compiler barrier can break the multi-arch drivers. barriers document
clearly states that device need to observe writes in order. 

Though for special cases like you mentioned, you can certainly do this:

wmb()
__raw_write/pointer access
__raw_write/pointer access
__raw_write/pointer access

/* flush everything */
mmiowb()
__raw_write/pointer access

There would be no ordering guarantee between the wmb() and mmiowb().
This can only be done for known code and known hardware. I don't believe
this applies to multi-arch drivers.


> 
> 	David
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.


More information about the Linuxppc-dev mailing list