From: James Bottomley <James.Bottomley@steeleye.com>
To: David Brownell <david-b@pacbell.net>
Cc: Ian Molton <spyro@f2s.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
tony@atomide.com, jamey.hicks@hp.com, joshua@joshuawise.com,
Russell King <rmk@arm.linux.org.uk>
Subject: Re: [RFC] on-chip coherent memory API for DMA
Date: 01 Jul 2004 13:04:20 -0500 [thread overview]
Message-ID: <1088705063.1919.16.camel@mulgrave> (raw)
In-Reply-To: <40E42374.8060407@pacbell.net>
On Thu, 2004-07-01 at 09:45, David Brownell wrote:
> Seems unreasonable to me, unless there's also an API to change
> the mode of the dma_alloc_coherent() memory from the normal
> "CPU can read/write as usual" to the exotic "need to use special
> memory accessors". (And another to report what mode the API is
> in at the current moment.)
No. That's why you specify how you'd like the memory to be treated. If
you don't want the memory to be accessible only via IO accessors, then
you specify DMA_MEMORY_MAP and take the failure if the platform can't
handle it.
> And I don't like modal APIs like that, which is why it'd make
> more sense to me to have a new allocator API for this new
> kind of DMA memory. (Which IS for that IBM processor, yes?)
There is no "new" kind of memory. This is currently how *all* I/O
memory is accessed. DMA_MEMORY_MAP is actually the new bit since it
allows I/O memory to be treated as normal memory.
> Alternatively, modify dma_alloc_coherent() to say what kind
> of address it must return. Since this is a "generic" DMA
> API, the caller of dma_alloc_coherent() shouldn't need to be
> guessing how they may actually use the memory returned.
> That new "must guess" requirement will break some code...
There is no "must guess". Either the driver specifies DMA_MEMORY_MAP or
DMA_MEMORY_IO. If you specify DMA_MEMORY_IO then you have to use
accessors for dma_alloc_coherent() memory. If you never wish to bother
with it, simply specify DMA_MEMORY_MAP and take the failure on platforms
which cannot comply.
> So -- you're saying it's not a bug that a __GFP_NOFAIL|__GFP_WAIT
> allocation be able to fail? Curious. I'd have thought the API
> was clear about that. Allocating 128 MB from a 1 MB region must
> of course fail, but allocating one page just needs a wait/wakeup.
It can *only* happen if you specify DMA_MEMORY_EXCLUSIVE; that preempts
the GFP_ flags and the application must be coded with this in mind.
Otherwise it will respect the GFP_ flags.
James
next prev parent reply other threads:[~2004-07-01 18:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-29 14:21 [RFC] on-chip coherent memory API for DMA James Bottomley
2004-07-01 12:43 ` Jamey Hicks
2004-07-01 14:12 ` David Brownell
2004-07-01 14:26 ` James Bottomley
2004-07-01 14:45 ` David Brownell
2004-07-01 18:04 ` James Bottomley [this message]
2004-07-01 20:14 ` David Brownell
2004-07-01 20:48 ` James Bottomley
2004-07-02 3:07 ` David Brownell
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=1088705063.1919.16.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=david-b@pacbell.net \
--cc=jamey.hicks@hp.com \
--cc=joshua@joshuawise.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=spyro@f2s.com \
--cc=tony@atomide.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