linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Wrobel Heinz-R39252" <Heinz.Wrobel@freescale.com>
To: "Chris Pringle" <chris.pringle@oxtel.com>,
	<linuxppc-dev@lists.ozlabs.org>
Cc: Tom Burns <tburns@datacast.com>,
	Andrea Zypchen <azypchen@intldata.ca>,
	azilkie@datacast.com
Subject: RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Date: Thu, 3 Sep 2009 13:20:12 +0100	[thread overview]
Message-ID: <AAE514D00E55E6438B7F5186462A545202750F9B@zuk35exm20.fsl.freescale.net> (raw)
In-Reply-To: <4A9F78AF.4010206@oxtel.com>

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.=20

Hope this helps,

Heinz

-----Original Message-----
From: linuxppc-dev-bounces+heinz.wrobel=3Dfreescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+heinz.wrobel=3Dfreescale.com@lists.ozlabs.or=
g
] 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=20
> compiles arch/ppc/kernel/head_44x.c (quite different from=20
> /arch/powerpc/kernel/head_32.S). I would like to apply your=20
> backporting patch to this architecture. Any help would be appreciated.
>
> Regards,
> Adam
>
>  =20


--=20

______________________________
Chris Pringle
Software Design Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053 Registered Office: James
House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

  parent reply	other threads:[~2009-09-03 12:20 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 [this message]
2009-09-03 12:43     ` Chris Pringle
2009-09-06 21:32     ` Benjamin Herrenschmidt
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=AAE514D00E55E6438B7F5186462A545202750F9B@zuk35exm20.fsl.freescale.net \
    --to=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).