public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Matt Porter <mporter@kernel.crashing.org>
Cc: 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: Fri, 18 Jun 2004 20:43:22 +0100	[thread overview]
Message-ID: <20040618204322.C17516@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20040618122112.D3851@home.com>; from mporter@kernel.crashing.org on Fri, Jun 18, 2004 at 12:21:12PM -0700

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.

> 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.)

Also, we need to consider what the DMA mask means in this case?  Should
it be zero (to mean "can't DMA from system memory"?)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

  reply	other threads:[~2004-06-18 19:44 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 [this message]
2004-06-21 13:35         ` Takashi Iwai
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=20040618204322.C17516@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --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=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