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....@lists.ozlabs.org > [mailto:linuxppc-dev-bounces+heinz.wrobel=freescale....@lists.ozlabs.org > ] On Behalf Of Chris Pringle > Sent: Donnerstag, 3. September 2009 10:05 > To: azil...@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 > > > > > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
