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

[Catalin Marinas]

On Fri, Aug 30, 2013 at 10:20:33AM +0100, Will Deacon wrote:
> 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.

Yes, an asm-generic default relaxed would be good (that's what I
suggested earlier in this thread and it was discussed in the past). But
no-one volunteered ;).

-- 
Catalin