Re: DMA API issues
From: Russell King (rmk+lkml_at_arm.linux.org.uk)
Date: 06/18/04
- Previous message: Valdis.Kletnieks_at_vt.edu: "Re: Stop the Linux kernel madness"
- In reply to: Matt Porter: "Re: DMA API issues"
- Next in thread: Takashi Iwai: "Re: DMA API issues"
- Reply: Takashi Iwai: "Re: DMA API issues"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 18 Jun 2004 20:43:22 +0100 To: Matt Porter <mporter@kernel.crashing.org>
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Valdis.Kletnieks_at_vt.edu: "Re: Stop the Linux kernel madness"
- In reply to: Matt Porter: "Re: DMA API issues"
- Next in thread: Takashi Iwai: "Re: DMA API issues"
- Reply: Takashi Iwai: "Re: DMA API issues"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
