From: "steve spano" <steve@fl-eng.com>
To: linux-kernel@vger.kernel.org
Subject: ### DMA_ALLOC_COHERENT question
Date: Thu, 9 Sep 2010 21:38:39 -0400 [thread overview]
Message-ID: <234ad71a39aa28e71c3fccd1f16fd1f3.squirrel@webmail.fl-eng.com> (raw)
Hi Folks,
I probably have a simple question and I hope someone can point me in the
right direction.
I have a 2.6.30.2 kernel running with a custom device driver for a
multi-channel sound card via PCI-Express. Interrupts,DMA, everything is
working fine.
We allocate a very small 64KB buffer for our DMA actions using
dma_alloc_coherent.
Tripped across an issue with larger amounts of memory on the motherboard.
This is an x86 ATOM motherboard.
At 256MB of ram, dma_alloc_coherent gets us an address within the first
128MB of ram, near the upper 1/2 of the 256MB actually.
Then at 1GB, we get an address near the upper 1/2 again (512MB)
Then at 2GB, we get an address near the upper 1/2 again (1GB)
This causes a problem on the sound card board because we need to then map
in nearly all 2GB of address space across the PCI bar registers so we can
access our tiny 64KB dma address range sitting up near the 1GB boundary.
This seems like we are doing something not right?
Ideally, we would get a non-cached block of ram that we can DMA to and the
processor can access. This block would ideally always be located near the
base of ram (maybe right after the kernel?). That way we can open a 128MB
window into the system ram from PCI-Express and always be sure to be able
to access our DMA buffer.
Can someone provide some insight in how to do this?
Is there a differnet dma allocation procedure we should use?
Should we just put an "unsigned char []" of 64k in the driver? Can we make
that also non cache?
Or do we have to hack the kernel allocation process?
Im sure there is something simple we can do.
Thanks again
Steve Spano
FLE
next reply other threads:[~2010-09-10 1:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-10 1:38 steve spano [this message]
2010-09-10 8:37 ` Clemens Ladisch
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=234ad71a39aa28e71c3fccd1f16fd1f3.squirrel@webmail.fl-eng.com \
--to=steve@fl-eng.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome