RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2009-09-03 at 13:20 +0100, Wrobel Heinz-R39252 wrote:
> Hi,
> 
> This doesn't seem right. If we are talking about a single CPU core chip,
> i.e., just one data cache, then setting M is typically a) useless and
> could even b) cause a performance penalty depending on a chip's
> implementation.
> The M bit is required if *other* cores with caches need to see changes
> for coherency of their caches. You wouldn't set it for one core only
> because your own core knows about its own cache.
> The possible performance penalty could happen because you need some way
> to tell the others that they better intercept a transaction. And that
> could, depending on the chip, by a clock extra or so per transaction.
> Now, in theory, a DMA engine could have caches, read from cache content
> first, and could snoop the bus on global transactions like another core,
> but I have never heard of such a beast. 

Actually there are some freescale part, afaik, that require M for proper
cache coherency :-) I don't have names off the top of my mind, I think
it has to be with PCI inbound buffers.

In this case, however, it's 440 on which I believe M is simply ignored.

Cheers,
Ben.

> Hope this helps,
> 
> Heinz
> 
> -----Original Message-----
> From: linuxppc-dev-bounces+heinz.wrobel=freescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+heinz.wrobel=freescale.com@lists.ozlabs.org
> ] On Behalf Of Chris Pringle
> Sent: Donnerstag, 3. September 2009 10:05
> To: azilkie@datacast.com
> Cc: Tom Burns; Andrea Zypchen; linuxppc-dev@lists.ozlabs.org
> Subject: Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
> 
> Hi Adam,
> 
> If you have a look in include/asm-ppc/pgtable.h for the following
> section:
> #ifdef CONFIG_44x
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
> #else
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> #endif
> 
> Try adding _PAGE_COHERENT to the appropriate line above and see if that
> fixes your issue - this causes the 'M' bit to be set on the page which
> sure enforce cache coherency. If it doesn't, you'll need to check the
> 'M' bit isn't being masked out in head_44x.S (it was originally masked
> out on arch/powerpc, but was fixed in later kernels when the cache
> coherency issues with non-SMP systems were resolved).
> 
> The patch I had fixed two problems on 2.6.26 for 'powerpc':
> 1) It stopped the 'M' bit being masked out (head_32.S)
> 2) It set the cache coherency ('M' bit) flag on each page table entry
> (pgtable-ppc32.h)
> 
> Hope this helps!
> 
> Cheers,
> Chris
> 
> Adam Zilkie wrote:
> > Hi Chris,
> >
> > I am having a problem similar to what you described in this
> discussion.
> > We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with 
> > compiles arch/ppc/kernel/head_44x.c (quite different from 
> > /arch/powerpc/kernel/head_32.S). I would like to apply your 
> > backporting patch to this architecture. Any help would be appreciated.
> >
> > Regards,
> > Adam
> >
> >   
> 
>