Re: [PATCH v2 1/2] spi:fsl-dspi:add support of DSPI IP in big endian

[Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>]

On Fri, Jan 10, 2014 at 12:40:14PM +0000, Mark Brown wrote:
> On Fri, Jan 10, 2014 at 08:11:33AM +0000, Chao Fu wrote:
> 
> > [Chao Fu] Our CPUs are working on only ARM architecture. But DSPI have two endianness 
> > In different series CPU, so we use __raw_read that do not take of endianness.
> > We need observe ARM io methods  make sure avoid instructions executing reorder .
> > ARM IO methods :
> > #define readb(c)                ({ u8  __v = readb_relaxed(c); __iormb(); __v; })
> > #define readw(c)                ({ u16 __v = readw_relaxed(c); __iormb(); __v; })
> > #define readl(c)                ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
> > 
> > #define writeb(v,c)             ({ __iowmb(); writeb_relaxed(v,c); })
> > #define writew(v,c)             ({ __iowmb(); writew_relaxed(v,c); })
> > #define writel(v,c)             ({ __iowmb(); writel_relaxed(v,c); })
> > 
> > So add barrier here. Could you give some suggestions? Many thanks!
> 
> OK that makes sense, please add comments explaining that this is due to
> the endinaness translation.  Given that people are starting to use big
> endian more it might be sensible to have these factored out into generic
> code but that can wait.

Accesses to device memory are guaranteed by the architecture to be in
program order when they're within the same 1K block of memory.  Larger
blocks are permissible, and depends on the SoC.  (The ARM ARM is a little
unclear on this statement, and I believe the statement is/has been fixed.)

The barriers above are not about ensuring correct program order (we have
that anyway), they're about ensuring the visibility externally given the
ARM ARM mess-up, and _primerily_ ensuring proper order between DMA
coherent memory and a DMA agent being enabled, or the DMA agent status
being read vs DMA coherent memory.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html