From: Adrian Cox <adrian@humboldt.co.uk>
To: John Whitney <jwhitney-linuxppc@sands-edge.com>
Cc: Linux/PPC Development <linuxppc-dev@lists.linuxppc.org>
Subject: Re: Problems with dma_alloc_coherent()
Date: Mon, 05 Apr 2004 10:05:37 +0100 [thread overview]
Message-ID: <1081155937.7999.893.camel@newt> (raw)
In-Reply-To: <811D8989-856C-11D8-9FF0-000A95A07384@sands-edge.com>
On Sat, 2004-04-03 at 13:43, John Whitney wrote:
> One of the nice things about having the DMA-core, however, was that it
> accepted virtual addresses and handled cache consistency. If the
> driver is accepting physical addresses only, it can't do that. This
> means the client would have to allocate space using the DMA/PCI to get
> the same coherency, which means all addresses will be
> PCI-address-space. Should the individual drivers accept this and just
> subtract off PCI_DRAM_OFFSET (or equivalent) to get back to a physical
> address? This is what would make life hell for a cross-platform DMA
> controller.
What I would like is a general API for a block move between memory and a
dumb PCI peripheral. Something like mempcy_toio() but with the
expectation of it sleeping.
Your local bus peripheral might benefit from a standard API, but I'm
still not convinced that there will be many cross-platform DMA
controllers. All the ones I've seen are tightly coupled to the
northbridge or system-on-a-chip internal bus. I'd still prefer a shared
interface rather than implementation, and I'd suggest taking an
interface proposal to the linux-arm-kernel and linuxppc-embedded lists.
- Adrian Cox
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-04-05 9:05 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-01 15:59 Problems with dma_alloc_coherent() John Whitney
2004-04-01 16:30 ` John Whitney
2004-04-01 16:51 ` Dan Malek
2004-04-01 17:01 ` Tom Rini
2004-04-01 17:05 ` Matt Porter
2004-04-01 17:51 ` John Whitney
2004-04-01 18:16 ` Matt Porter
2004-04-01 18:19 ` Eugene Surovegin
2004-04-01 18:33 ` Eugene Surovegin
2004-04-01 18:33 ` John Whitney
2004-04-01 18:40 ` Eugene Surovegin
2004-04-01 18:48 ` John Whitney
2004-04-01 18:55 ` Dan Malek
2004-04-01 18:59 ` Eugene Surovegin
2004-04-01 19:10 ` John Whitney
2004-04-01 19:17 ` Eugene Surovegin
2004-04-01 19:35 ` John Whitney
2004-04-02 1:22 ` Benjamin Herrenschmidt
2004-04-01 20:52 ` Michael R. Zucca
2004-04-01 22:00 ` Eugene Surovegin
2004-04-01 22:39 ` Michael R. Zucca
2004-04-02 16:50 ` John Whitney
2004-04-02 18:50 ` Michael R. Zucca
2004-04-02 19:27 ` John Whitney
2004-04-02 20:20 ` Michael R. Zucca
2004-04-02 21:01 ` John Whitney
2004-04-03 7:54 ` Adrian Cox
2004-04-03 12:43 ` John Whitney
2004-04-05 9:05 ` Adrian Cox [this message]
2004-04-03 17:33 ` Brad Boyer
2004-04-03 23:17 ` Paul Mackerras
2004-04-04 8:15 ` Adrian Cox
2004-04-02 22:54 ` Paul Mackerras
2004-04-03 7:33 ` Adrian Cox
2004-04-04 22:56 ` Benjamin Herrenschmidt
2004-04-02 5:45 ` Christoph Hellwig
2004-04-01 20:49 ` Matt Porter
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=1081155937.7999.893.camel@newt \
--to=adrian@humboldt.co.uk \
--cc=jwhitney-linuxppc@sands-edge.com \
--cc=linuxppc-dev@lists.linuxppc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.