From: Paul Mundt <lethal@linux-sh.org>
To: Michael Bourgeous <sts.nitrogen@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Driver-level memory management
Date: Sun, 12 Aug 2007 14:04:09 +0900 [thread overview]
Message-ID: <20070812050409.GC13496@linux-sh.org> (raw)
In-Reply-To: <8e4fc8270708112014h5f4e9bf1ua9565eab60f915c1@mail.gmail.com>
On Sat, Aug 11, 2007 at 09:14:00PM -0600, Michael Bourgeous wrote:
> I'm working on a driver for older HDTV cards based on the TL880 chip.
> These cards typically have 16MB of their own memory, which is
> available to me over the PCI bus. Various functions of the card
> require me to manage this memory, allocating and freeing chunks of it
> as necessary. I can easily include my own allocation and management
> code, but I'm sure this is a problem that has been solved before.
> I've found two interesting sets of functions, the kmem_cache_* and
> mempool_* functions, but neither does quite what I'm looking for. So,
> in a sentence, my question is this: Does the kernel provide memory
> pool functions that would allow me to call the appropriate equivalent
> of kmalloc/kfree, using the card's memory as the pool instead of
> actually allocating physical or virtual memory?
>
Many platforms have similar requirements for DMA, both in terms of bounce
buffers and consistent allocations. If you're looking at this
specifically for DMA, then things like dma_declare_coherent_memory() and
the corresponding alloc/free routines that go along with it will do what
you need. If you require something more generalized, you can still
abstract what you need fairly trivially.
There are a few examples of bitmap based region management in the kernel
you can look at. arch/i386/kernel/pci-dma.c implements the aforementioned
DMA ops, and arch/sh/kernel/cpu/sh4/sq.c does something similar, albeit
with a larger address range (64MB). A simple bitmap approach from one or
the other should work fine for your 16MB case.
next prev parent reply other threads:[~2007-08-12 5:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-12 3:14 Driver-level memory management Michael Bourgeous
2007-08-12 5:04 ` Paul Mundt [this message]
2007-08-13 0:37 ` Ingo Oeser
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=20070812050409.GC13496@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sts.nitrogen@gmail.com \
/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