From: Steven Rostedt <rostedt@goodmis.org>
To: Clemens Koller <clemens.koller@anagramm.de>
Cc: LKML List <linux-kernel@vger.kernel.org>,
"linux-os (Dick Johnson)" <linux-os@analogic.com>
Subject: Re: How to get the physical page addresses from a kernel virtual address for DMA SG List?
Date: Thu, 04 Aug 2005 09:57:26 -0400 [thread overview]
Message-ID: <1123163846.12009.15.camel@localhost.localdomain> (raw)
In-Reply-To: <42F21A86.8030408@anagramm.de>
On Thu, 2005-08-04 at 15:39 +0200, Clemens Koller wrote:
> > You are trying to do it backwards. You need to have your driver
> > use get_dma_pages() to acquire pages suitable for DMA. Your
> > driver then impliments mmap().
>
> Okay, I have seen that, too. I've seen that some drivers do it the other
> way around as I do, but I still try to follow my idea that the
> application allocs the memory and the dma / the driver fills it up.
> Or are there fundamental problems I get with my approach which I haven't seen yet?
The driver doing the allocation would probably be easier. Do you mean
that the application will do some large malloc and then pass that
address to the driver? The driver would then need to map in those pages
since most of them would probably not be even allocated yet (no physical
memory associated to them). Then there's always the point to prevent
abuse by the user. If the driver did the allocation, it would just be
easier to control.
>
> > The user-mode application then mmaps() the dma-able pages into
> > its address-space. FYI, the pages may be from anywhere, some
> > archs can only DMA to/from memory below 16MB.
>
> My DMA machine (ppc32, mpc8540 cpu) can do the whole 32bit phys address
> space so, that's not an issue here.
I guess you don't mind that your driver will be locked to a specific
architecture. Or at least one that can handle these requirements. Is
this just for a single use?
>
> > The pages do not have
> > to be continuous because you will build a scatter-list for
> > the DMA engine and you will mmap() the pages so they are
> > contiguous to the user.
>
> Yes, only virtual space is contigous. The DMA can do nice
> sg_lists and chained sg_lists, so, this should not be a problem,
> too.
>
> > Also 400 Megabytes is absurd.
>
> Why?
> Actually I am planning to alloc more than 1.5GByte at once,
> lock that down, build a big sg_list for all that memory because
> I need to _continously_ feed it with data from the DMA. I get
> about 200MBytes/sec and I cannot stop in between!
Wow! what a system you must have :-) With a 32 bit address space that
really does take a big chunck out of it. Well I guess whatever device
this driver is for must be for some specific architecture.
-- Steve
next prev parent reply other threads:[~2005-08-04 14:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-04 12:41 Clemens Koller
2005-08-04 13:09 ` linux-os (Dick Johnson)
2005-08-04 13:39 ` Clemens Koller
2005-08-04 13:57 ` Steven Rostedt [this message]
2005-08-04 14:56 ` How to get the physical page addresses from a kernel virtualaddress " linux-os (Dick Johnson)
2005-08-04 17:01 ` Steven Rostedt
2005-08-04 18:09 ` Clemens Koller
2005-08-05 0:11 ` How to get the physical page addresses from a kernel virtual address " Peter Chubb
2005-08-04 14:10 ` Arjan van de Ven
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=1123163846.12009.15.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=clemens.koller@anagramm.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.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
Powered by JetHome