All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Alex <arghness@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>, linux-kernel@vger.kernel.org
Subject: Re: DMA with PCIe and very large DMA transfers
Date: Fri, 25 Jul 2008 09:33:11 +0200	[thread overview]
Message-ID: <488981B7.1060002@ladisch.de> (raw)
In-Reply-To: <200807241302.19656.jbarnes@virtuousgeek.org>

Jesse Barnes wrote:
> On Thursday, July 24, 2008 8:06 am Alex wrote:
> > I'm also interested in knowing if any drivers perform very large DMA
> > transfers. I'm putting together a driver for a specialist high-speed
> > data acquisition device that typically might need a DMA buffer of
> > 100-500MB (ouch!) in the low 32 bit address space (or possibly 36 bit
> > address space, but I'm not sure if this is possible to allocate
> > without allocating as much as possible and then discarding?) but only
> > supports a very limited number of scatter/gather entries (between 1
> > and 4). [...]
>
> It sounds like you'll probably have fairly special purpose configurations.  In
> that case, it may be reasonable to reserve your large DMA buffers at boot
> time, assuming you need large, contiguous chunks of physical memory.

Most of the sound drivers do this because few chips support SG.

> > I assume that to allocate that much memory in physical contiguous
> > addresses will require a driver to be loaded as soon as possible at
> > startup. I was thinking about trying to grab a lot of high-order pages
> > and try and make them one contiguous block - is that feasible?
> > Browsing the archives, I found references to early allocation for
> > large buffers, but no direct links to existing examples or recommended
> > techniques on how to stitch pages together in to a single buffer.

Have a look into sound/core/memalloc.c.  It tries to get a contiguous
block from the kernel; I don't think that it's possible to do this
manually if the kernel has failed.


Regards,
Clemens

  reply	other threads:[~2008-07-25  7:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-24 15:06 DMA with PCIe and very large DMA transfers Alex
2008-07-24 20:02 ` Jesse Barnes
2008-07-25  7:33   ` Clemens Ladisch [this message]
     [not found] <fa.vod1UTmCwWWvRyGIk08cgMVx/H4@ifi.uio.no>
2008-07-24 20:03 ` Robert Hancock

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=488981B7.1060002@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=arghness@gmail.com \
    --cc=jbarnes@virtuousgeek.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.