From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Wrobel Heinz-R39252 <Heinz.Wrobel@freescale.com>
Cc: Tom Burns <tburns@datacast.com>,
Chris Pringle <chris.pringle@oxtel.com>,
Andrea Zypchen <azypchen@intldata.ca>,
linuxppc-dev@lists.ozlabs.org, azilkie@datacast.com
Subject: RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Date: Mon, 07 Sep 2009 07:32:27 +1000 [thread overview]
Message-ID: <1252272747.4950.0.camel@pasglop> (raw)
In-Reply-To: <AAE514D00E55E6438B7F5186462A545202750F9B@zuk35exm20.fsl.freescale.net>
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
> >
> >
>
>
next prev parent reply other threads:[~2009-09-06 21:32 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-02 21:22 AW: PowerPC PCI DMA issues (prefetch/coherency?) Adam Zilkie
2009-09-03 8:05 ` Chris Pringle
2009-09-03 9:57 ` Benjamin Herrenschmidt
2009-09-03 16:04 ` Adam Zilkie
2009-09-03 16:21 ` Josh Boyer
2009-09-03 20:27 ` Prodyut Hazarika
2009-09-08 18:01 ` Adam Zilkie
2009-09-08 18:59 ` Prodyut Hazarika
2009-09-08 19:30 ` Adam Zilkie
2009-09-08 19:56 ` Prodyut Hazarika
2009-09-08 20:00 ` Adam Zilkie
2009-09-09 1:34 ` Benjamin Herrenschmidt
2009-09-08 21:34 ` Benjamin Herrenschmidt
2009-09-09 13:28 ` Mikhail Zolotaryov
2009-09-09 13:43 ` Tom Burns
2009-09-09 14:12 ` Mikhail Zolotaryov
2009-09-09 14:10 ` Tom Burns
2009-09-09 14:40 ` Mikhail Zolotaryov
2009-09-11 1:57 ` Benjamin Herrenschmidt
2009-09-11 7:17 ` Mikhail Zolotaryov
2009-09-11 7:31 ` Benjamin Herrenschmidt
2009-09-11 1:57 ` Benjamin Herrenschmidt
2009-09-10 19:53 ` Tom Burns
2009-09-10 20:30 ` Pravin Bathija
2009-09-11 2:44 ` Benjamin Herrenschmidt
2009-09-11 5:12 ` Stefan Roese
2009-09-11 5:17 ` Benjamin Herrenschmidt
2009-09-11 5:25 ` Stefan Roese
2009-09-11 5:35 ` Pravin Bathija
2009-09-11 5:40 ` Benjamin Herrenschmidt
2009-09-11 9:23 ` Pravin Bathija
2009-09-11 1:59 ` Benjamin Herrenschmidt
2009-09-11 16:05 ` Prodyut Hazarika
2009-09-11 1:55 ` Benjamin Herrenschmidt
2009-09-11 13:51 ` Tom Burns
2009-09-08 21:29 ` Benjamin Herrenschmidt
2009-09-03 12:20 ` Wrobel Heinz-R39252
2009-09-03 12:43 ` Chris Pringle
2009-09-06 21:32 ` Benjamin Herrenschmidt [this message]
2009-09-03 15:54 ` Adam Zilkie
[not found] <4A37A503.3030209@oxtel.com>
[not found] ` <20090616162114.GA5051@loki.buserror.net>
[not found] ` <4A37C97A.5050508@oxtel.com>
2009-06-16 16:46 ` Scott Wood
2009-06-16 16:57 ` Chris Pringle
2009-06-16 17:03 ` Scott Wood
2009-06-17 7:58 ` Chris Pringle
2009-06-17 13:18 ` Chris Pringle
2009-06-18 11:24 ` Chris Pringle
2009-06-22 14:31 ` AW: " Sergej.Stepanov
2009-06-29 8:11 ` Chris Pringle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1252272747.4950.0.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=Heinz.Wrobel@freescale.com \
--cc=azilkie@datacast.com \
--cc=azypchen@intldata.ca \
--cc=chris.pringle@oxtel.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=tburns@datacast.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).