linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Gerhard Sittig <gsi@denx.de>
To: Peter LaDow <petela@gocougs.wsu.edu>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Inbound PCI and Memory Corruption
Date: Fri, 19 Jul 2013 15:46:15 +0200	[thread overview]
Message-ID: <20130719134615.GR7080@book.gsilab.sittig.org> (raw)
In-Reply-To: <CAN8Q1EeKCTCB30N50iA8-QB=0aoNtS1U3nNLGVoz7sHG-Qg26A@mail.gmail.com>

On Thu, Jul 18, 2013 at 14:30 -0700, Peter LaDow wrote:
> 
> We are still stumped on this one, but during a review of the system
> setup one thing came up that we aren't sure about is the device tree
> and the DMA engine.
> 
> It does seem that for incoming PCI transactions the Freescale DMA
> engine is not used.  And in our device tree we have the DMA engine
> commented out.  That is, the "fsl,mpc8349-dma" and "fsl,elo-dma"
> compatible items are not present in the FDT.
> 
> I don't suppose this could be a problem?

Can't tell whether it helps or whether I'm telling you what's
already known, but here we go:

Some Freescale SoC's don't have "_the_ DMA", but instead several
of them.  Many peripherals have a DMA engine of their own, which
you won't notice as a separate entity from the software POV
(typically ethernet, USB, PCI, partially video in and out, even
coprocessor may have dedicated DMA engines which they might take
care of themselves).

The thing that you do see (in the device tree, as a software
controllable entity) is the "general purpose DMA" with user
servicable channels.  This one is may be used for serial
communication via UART or SPI, or SDHC/MMC, or peripherals
attached to the EMB.  Sometimes it's called "DMA2" to reflect
that there are others as well.

So:  No, not having to fiddle with DMA stuff when doing PCI need
not be a problem, it's actually expected.  But since a DMA engine
might be involved (that's just not under your command), the
accompanying problems may arise.  You may need to flush CPU
provided data upon write before telling an external entity to
access it, and may need to invalidate caches (to have data
re-fetched) before the CPU accesses what an external entity did
manipulate.  And this applies to both payload data as well as
management data (descriptors) if the latter apply to the former.

HTH


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de

  parent reply	other threads:[~2013-07-19 13:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21 16:56 Inbound PCI and Memory Corruption Peter LaDow
2013-06-21 17:14 ` Peter LaDow
2013-06-23  0:00   ` Benjamin Herrenschmidt
2013-06-24  0:56     ` Peter LaDow
2013-06-24  1:16       ` Benjamin Herrenschmidt
2013-06-24  3:47         ` Peter LaDow
2013-06-24  3:49           ` Benjamin Herrenschmidt
2013-06-25 18:44         ` Peter LaDow
2013-07-10 21:06     ` Peter LaDow
2013-07-10 21:40       ` Benjamin Herrenschmidt
2013-07-10 22:16         ` Peter LaDow
2013-07-11 21:00         ` Peter LaDow
2013-07-18 21:30           ` Peter LaDow
2013-07-18 22:02             ` Benjamin Herrenschmidt
2013-07-19 17:44               ` Scott Wood
2013-07-19 13:46             ` Gerhard Sittig [this message]
2013-07-24  4:22               ` Peter LaDow
2013-07-24  4:27                 ` Benjamin Herrenschmidt
2013-07-24 15:39                   ` Peter LaDow
2013-07-24 22:08                     ` Benjamin Herrenschmidt
2013-07-25  6:13                       ` Peter LaDow
2013-08-02 15:01                         ` Peter LaDow
2013-07-24  8:40                 ` David Laight
2013-07-19 20:13             ` Timur Tabi

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=20130719134615.GR7080@book.gsilab.sittig.org \
    --to=gsi@denx.de \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=petela@gocougs.wsu.edu \
    /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).