Re: [PATCH 0/4] 34xx spurious interrupts unravelling

[David Brownell <david-b@pacbell.net>]

On Friday 31 October 2008, Woodruff, Richard wrote:
> 
> > owner@vger.kernel.org] On Behalf Of David Brownell
> > Sent: Friday, October 31, 2008 4:59 PM
> 
> > As in, issue those dma cache updates, then write to the
> > DMA or peripheral controller registers ... and the key data
> > was still in the write buffers when those writes completed!
> > That's quite unusual; possibly related to memory controller
> > bugs in that silicon revision.
> 
> For the next series of ARMv7 Cortex's this is all being projected
> to require much more strictness in access ordering and use of barriers.

Any particular kind of barriers?  barrier() is compiler advice,
and gets the most use in Linux ... but <asm/system.h> reminds
me that V7 has isb/dsb/dmb instructions, and V6 can do them too.
(Now I'll have to go look at what they do again...)

That case needed a dsb analogue (on armv5, flush write buffer).


> There have been some cautions about newer write buffer policies
> which try and keep data instead of flushing it. Today even if
> you miss some drain in a small amount of time it will happen.
> That may not be the case always.   

Yeah, I remember back when I had to work with SPARC the issue
of memory ordering models was problematic.  There's a tradeoff:
the more ordering guarantees the easier it is for software, at
cost of slowing down data transfers by excess serialization.

And at the other extreme, if you configured things for highly
unordered access, the hardware wouldn't have many roadblocks
but the software could get confused rather easily.


What this means for software developers -- especially folk
writing drivers and tweaking address spaces -- is needing to
pay a bunch more attention to some confusing issues that most
ARM folk have managed to avoid over the past many years.

- Dave


> 
> Regards,
> Richard W.
> 
>