From: Takashi Iwai <tiwai@suse.de>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Matt Porter <mporter@kernel.crashing.org>,
Jamey Hicks <jamey.hicks@hp.com>, Ian Molton <spyro@f2s.com>,
linux-kernel@vger.kernel.org, greg@kroah.com, tony@atomide.com,
david-b@pacbell.net, joshua@joshuawise.com
Subject: Re: DMA API issues
Date: Mon, 21 Jun 2004 15:35:42 +0200 [thread overview]
Message-ID: <s5hoendm3td.wl@alsa2.suse.de> (raw)
In-Reply-To: <20040618204322.C17516@flint.arm.linux.org.uk>
At Fri, 18 Jun 2004 20:43:22 +0100,
Russell King wrote:
>
> On Fri, Jun 18, 2004 at 12:21:12PM -0700, Matt Porter wrote:
> > > page_to_dma so that device specific dma addresses can be constructed.
> >
> > A struct device argument to page_to_dma seems like a no brainer to be
> > included.
>
> Tony Lindgren recently submitted a patch for this:
>
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1931/1
>
> which now pending for Linus. ARM platforms now have three macros to
> define if they want to override the default struct page to DMA address
> translation.
Wouldn't it be nicer to define a more generic style like
struct page *dma_to_page(struct device *, void *, dma_addr_t)
??
>
> > I see that's somewhat like what David Brownell suggested before...a single
> > pointer to a set of dma ops from struct device. hppa_dma_ops translated
> > into a generic dma_ops entity with fields corresponding to existing
> > DMA API calls would be a good starting point. We can get rid of some
> > address translation hacks in a lot of custom embedded PPC drivers
> > with something like this.
>
> I really don't think we need to go this far.
>
> As I understand it, the issue seems to surround DMA coherent memory
> for USB descriptors, and what happens when we call the streaming DMA
> API.
>
> We have the latter solved with Deepak's DMA bounce code (already merged)
> provided it's given the right information to determine when bounce
> buffers are needed.
>
> The bounce code only needs a way to get at the "safe" DMA memory, and
> it uses DMA pools for that. DMA pools in turn take their memory from
> dma_alloc_coherent.
>
> So, we just need a way to make dma_alloc_coherent do the right thing.
> One suggestion from James yesterday was to have a way to register
> device-private "coherent DMA" backing memory with dma_alloc_coherent,
> which it would use in preference to calling alloc_pages(). However,
> this memory would have no struct page pointer associated with it, and
> our dma_alloc_coherent implementation currently relies completely on
> that condition existing - so it would mean a complete rewrite of that.
>
> Note also that some drivers (notably ALSA) assume that memory returned
> from dma_alloc_coherent() does have struct page pointers, so this would
> also break ALSA (which in turn provides much more of a justification
> for the DMA MMAP API I was trying (and failed) to propose a few months
> back.)
Yes, the struct page pointer is needed for vma_ops.nopage in mmap on
ALSA. So far, this is broken on some architectures like ARM. We need
a proper conversion from virtual/bus pointer to a page struct.
Of course, mmap is not mandatory, and we have a fallback via
ioctl/read/write. But it's important to _know_ whether remapping is
available...
--
Takashi Iwai <tiwai@suse.de> ALSA Developer - www.alsa-project.org
next prev parent reply other threads:[~2004-06-21 13:36 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-18 16:59 DMA API issues Ian Molton
2004-06-18 18:07 ` Matt Porter
2004-06-18 18:19 ` Ian Molton
2004-06-18 18:58 ` Matt Porter
2004-06-18 18:33 ` Jamey Hicks
2004-06-18 19:21 ` Matt Porter
2004-06-18 19:43 ` Russell King
2004-06-21 13:35 ` Takashi Iwai [this message]
2004-06-21 23:08 ` Russell King
2004-06-22 2:06 ` Jeff Garzik
2004-06-22 3:18 ` Linus Torvalds
2004-06-22 3:26 ` Linus Torvalds
2004-06-22 10:40 ` Takashi Iwai
2004-06-23 12:34 ` Russell King
2004-06-23 15:36 ` Takashi Iwai
2004-06-23 15:44 ` Russell King
2004-06-23 16:01 ` Takashi Iwai
2004-06-23 16:10 ` Russell King
2004-06-22 10:48 ` Takashi Iwai
2004-06-18 19:48 ` Jamey Hicks
2004-06-18 21:08 ` Jeff Garzik
2004-06-18 22:12 ` Richard B. Johnson
2004-06-18 23:27 ` Ian Molton
2004-06-18 23:26 ` Ian Molton
2004-06-18 23:30 ` James Bottomley
2004-06-18 23:32 ` Jeff Garzik
[not found] ` <20040619005714.37b68453.spyro@f2s.com>
[not found] ` <40D3838B.2070608@pobox.com>
[not found] ` <20040619011621.4491600a.spyro@f2s.com>
[not found] ` <40D3872F.5010007@pobox.com>
2004-06-19 0:34 ` Ian Molton
2004-06-19 21:15 ` Tony Lindgren
-- strict thread matches above, loose matches on Subject: below --
2004-06-18 18:20 James Bottomley
2004-06-18 18:35 ` Ian Molton
2004-06-18 18:52 ` James Bottomley
2004-06-18 18:57 ` Ian Molton
2004-06-18 19:20 ` David Brownell
2004-06-18 19:44 ` Ian Molton
2004-06-18 19:57 ` James Bottomley
2004-06-18 21:08 ` David Brownell
2004-06-18 21:14 ` James Bottomley
2004-06-18 22:38 ` David Brownell
2004-06-18 23:07 ` James Bottomley
2004-06-18 23:31 ` Ian Molton
2004-06-19 18:23 ` David Brownell
2004-06-19 20:41 ` Russell King
2004-06-19 21:46 ` James Bottomley
2004-06-19 22:49 ` Ian Molton
2004-06-20 13:37 ` James Bottomley
2004-06-20 15:50 ` Ian Molton
2004-06-20 16:26 ` Jeff Garzik
2004-06-20 16:57 ` Ian Molton
2004-06-20 20:15 ` David Brownell
2004-06-20 16:46 ` James Bottomley
2004-06-20 18:02 ` Oliver Neukum
2004-06-20 19:27 ` James Bottomley
2004-06-20 19:34 ` Oliver Neukum
2004-06-20 20:07 ` David Brownell
2004-06-20 20:18 ` David Brownell
2004-06-20 20:02 ` David Brownell
2004-06-18 23:25 ` Ian Molton
2004-06-18 23:29 ` James Bottomley
2004-06-18 23:51 ` Ian Molton
2004-06-19 0:04 ` James Bottomley
2004-06-19 0:14 ` Ian Molton
2004-06-19 3:49 ` James Bottomley
2004-06-20 20:59 ` Jamey Hicks
2004-06-18 19:30 ` James Bottomley
2004-06-18 19:56 ` Ian Molton
2004-06-18 19:22 ` Jamey Hicks
2004-06-18 19:41 ` James Bottomley
2004-06-18 20:02 ` Oliver Neukum
2004-06-18 20:07 ` James Bottomley
2004-06-18 20:14 ` Benjamin Herrenschmidt
2004-06-18 20:24 ` James Bottomley
2004-06-18 21:20 ` Russell King
2004-06-18 23:20 ` Ian Molton
2004-06-20 18:25 ` Deepak Saxena
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=s5hoendm3td.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=david-b@pacbell.net \
--cc=greg@kroah.com \
--cc=jamey.hicks@hp.com \
--cc=joshua@joshuawise.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mporter@kernel.crashing.org \
--cc=rmk+lkml@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 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.