linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Matt Porter <mporter@kernel.crashing.org>
To: Tom Rini <trini@kernel.crashing.org>
Cc: Pantelis Antoniou <panto@intracom.gr>,
	Matt Porter <mporter@kernel.crashing.org>,
	Linuxppc-Embedded <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: new dma API questions
Date: Thu, 3 Jun 2004 09:04:21 -0700	[thread overview]
Message-ID: <20040603090421.A7347@home.com> (raw)
In-Reply-To: <20040603154624.GM15195@smtp.west.cox.net>; from trini@kernel.crashing.org on Thu, Jun 03, 2004 at 08:46:24AM -0700


On Thu, Jun 03, 2004 at 08:46:24AM -0700, Tom Rini wrote:
> On Thu, Jun 03, 2004 at 12:06:29PM +0300, Pantelis Antoniou wrote:
>
> > Hi there.
> >
> > I have a few questions regarding the new DMA API.
> [snip]
> > 3. The first argument is dma_* function is a struct device.
> >   When working with network devices I must set this to NULL.
> >   Granted this is no problem right now, but could this be
> >   a problem in the future?
>
> It could be a problem in the future, but probably not until cpm1/cpm2
> stuff uses OCP bits, which would have a dev entry to pass in (AFAIK,
> there aren't plans to make use of dev yet, so...).

To further clarify, it just happens that DMA API has to allow for that
parameter since several architectures need to be able to perform
operations based on the "bus type" which can be derived from the
struct device argument.  It just happens that we don't need to do
that on ppc32.  However!...I've been enlightened to a case on
Marvell 64x60 where it would be desirable to use the "non-coherent"
implementation on the on-chip peripherals that don't have snooping
and then use the "coherent" implementation on the PCI bus. That
would require additional reorg work and it's not clear yet how the
64x60 folks want to handle the situation.

-Matt

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

      reply	other threads:[~2004-06-03 16:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-03  9:06 new dma API questions Pantelis Antoniou
2004-06-03 10:56 ` Dan Malek
2004-06-03 11:05   ` Pantelis Antoniou
2004-06-03 15:46 ` Tom Rini
2004-06-03 16:04   ` Matt Porter [this message]

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=20040603090421.A7347@home.com \
    --to=mporter@kernel.crashing.org \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=panto@intracom.gr \
    --cc=trini@kernel.crashing.org \
    /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).