Re: [PATCH 20/28] ARCv2: barriers

[Vineet Gupta <Vineet.Gupta1@synopsys.com>]

On Monday 22 June 2015 07:06 PM, Will Deacon wrote:
>> OK, so given that regular/mmio is also weakly ordered, it would seem that we need
>> > full mb() *before* and *after* the IO access in the non relaxed API. ARM code
>> > seems to put a rmb() after the readl and wmb() before the writel. Is that based on
>> > how h/w provides for some ?
> We figured that you'd likely be doing something like:
> 
> <writel_relaxed DMA buffer>
> <writel MMIO "go" reg>
> 
> or:
> 
> <readl MMIO "status" reg>
> <readl_relaxed DMA buffer>
> 
> so ended up with writel doing {wmb(); writel_relaxed} and readl doing
> {readl_relaxed; rmb()}.
> 
>> > In one of the links you posted above, Catalin posed the same question, but I
>> > didn't see response to that.
>> > 
>> > | If we are to make the writel/readl on ARM fully ordered with both IO
>> > | (enforced by hardware) and uncached memory, do we add barriers on each
>> > | side of the writel/readl etc.? The common cases would require a barrier
>> > | before writel (write buffer flushing) and a barrier after readl (in case
>> > | of polling for a "DMA complete" state).
>> > |
>> > | So if io_wmb() just orders to IO writes (writel_relaxed), does it mean
>> > | that we still need a mighty wmb() that orders any type of accesses (i.e.
>> > | uncached memory vs IO)? Can drivers not use the strict writel() and no
>> > | longer rely on wmb() (wondering whether we could simplify it on ARM with
>> > | fully ordered IO accessors)?
>> > 
>> > Further readl/writel would be no different than ioread32/iowrite32 ?
> ioread32/iowrite32 can be used with port addresses and dispatch to the
> relevant accessors depending on that. The memory ordering semantics should
> be the same as readl/writel.
> 
>> > FWIW, h/w folks tell me that DMB guarentess local barrier semantics so we don't
>> > need to use DSYNC. Latter only provides full r+w+TLB/BPU stuff while DMB allows
>> > finer grained r/w/r+w. But if we need full mb then using one vs. other becomes a
>> > moot point.
> I'd say go with what we do on ARM/arm64, then at least we have consistency
> in the use of barriers.

Thx for very helpful review/feedback Will. I've posted a v2 !

-Vineet