From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Strange delay on PCI-DMA-transfer completion by wait_event_interruptible()
Date: Wed, 14 Dec 2005 19:22:37 -0600 [thread overview]
Message-ID: <43A0C55D.2070500@shaw.ca> (raw)
In-Reply-To: <5jzIB-3pY-5@gated-at.bofh.it>
Burkhard Schölpen wrote:
> I'm glad to meet somebody with dma experience, because I have
> some other difficulties concerning DMA buffers in RAM. The PCI-Board
> is to be applied in a large size copying machine, so it essentially
> has to transfer tons of data in 2 directions very fast without wasting
> cpu time (because the cpu has to run many image processing algorithms
> meanwhile on this data). So my approach is to allocate a quite large
> ringbuffer in kernel space (or more precisely one ringbuffer for each
> direction) which is capable of dma. Afterwards I would map this buffer
> to user space to avoid unnecessary memcopies/cpu usage. My problem is
> for now to get such a large DMA buffer. I tried out several things I
> read in O'Reilly's book, but they all failed so far. My current
> attempt is to take a high memory area with ioremap:
You can't ioremap normal memory like that. ioremap is only for MMIO
address regions.
Better than trying to allocate lots of memory in the kernel (which you
can't, really), would be to make the userspace application allocate the
ringbuffer and do DMA from the device to userspace memory. To do this,
you'll have to either make the device do a separate DMA for every
contiguous chunk, or better yet make the device support scatter-gather
DMA so that it can read/write from discontiguous physical blocks of
memory. Have a look at Documentation/DMA-mapping.txt and
Documentation/DMA-API.txt, also at the Linux Device Drivers 3rd ed.
online book, these all have info on how this can be done.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
next parent reply other threads:[~2005-12-15 1:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5jzIB-3pY-5@gated-at.bofh.it>
2005-12-15 1:22 ` Robert Hancock [this message]
2005-12-14 7:59 Strange delay on PCI-DMA-transfer completion by wait_event_interruptible() Burkhard Schölpen
2005-12-14 14:12 ` linux-os (Dick Johnson)
[not found] <5jeNG-740-1@gated-at.bofh.it>
[not found] ` <5jnfV-2xy-577@gated-at.bofh.it>
2005-12-14 2:13 ` Robert Hancock
-- strict thread matches above, loose matches on Subject: below --
2005-12-13 9:29 Burkhard Schölpen
2005-12-13 14:27 ` linux-os (Dick Johnson)
2005-12-12 18:14 Burkhard Schölpen
2005-12-12 20:14 ` linux-os (Dick Johnson)
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=43A0C55D.2070500@shaw.ca \
--to=hancockr@shaw.ca \
--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