[PATCH v3 1/3] ARM: Introduce atomic MMIO modify

[Will Deacon]

On Fri, Aug 30, 2013 at 10:15:36AM +0100, Catalin Marinas wrote:
> On Fri, Aug 30, 2013 at 10:08:07AM +0100, Will Deacon wrote:
> > On Fri, Aug 23, 2013 at 12:48:05PM +0100, Catalin Marinas wrote:
> > > On Fri, Aug 23, 2013 at 12:32:26PM +0100, Ezequiel Garcia wrote:
> > > > ... or maybe yes. I'm not seeing {readl,writel}_relaxed as guaranteed
> > > > to exist in every architecture. So, indeed, this seems to be ARM-dependent.
> > > 
> > > There was a discussion couple of years ago to make these part of the IO
> > > specification since many architectures define them:
> > > 
> > > http://thread.gmane.org/gmane.linux.ports.arm.kernel/117626
> > > 
> > > (and some older threads on linux-arch which I haven't searched)
> > > 
> > > We could have some default implementation pointing to readl/writel while
> > > letting the arch code to define more optimised variants.
> > 
> > The main thing I dislike about that is the back-to-back dsbs that you will
> > get from the read-(modify)-write. It really makes the non-optimised version
> > needlessly expensive.
> 
> Yes, it's pretty bad. But we don't have relaxed (write) accessors on
> other architectures and I'm not sure about their semantics either. I
> guess here it's a data dependency so you cannot write the value before
> reading it, especially since sane architectures should speculate reads
> or writes to device memory.
> 
> What about making it always use *_relaxed() accessors if the
> architecture provides them? No need for atomic_io_modify_relaxed().

The only potential problem there is if somebody uses this function to kick
off a DMA. That would require explicit barriers to enforce ordering against
population of normal, cacheable buffers, which isn't usually the case in
driver code (since we have the dsb/outer_sync in the accessor).

Perhaps we should just bit the bullet and define relaxed accessors for all
architectures? It's not difficult to default them to the non-relaxed
variants if the architecture doesn't provide an optimised implementation.

Will