public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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/


       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