From: Norbert Roos <norbert.roos@cluster-labs.de>
To: linux-kernel@vger.kernel.org
Subject: Probs with PCI bus master DMA to user space
Date: Tue, 20 Feb 2001 11:57:14 +0100 [thread overview]
Message-ID: <3A924D8A.FBEAD695@cluster-labs.de> (raw)
Hello!
I think the following is general problem, but i haven't found any
information about that yet..
I'm currently writing a driver which wants to transfer data between main
memory and a PCI device. The data buffers are allocated by the program
which uses the driver and therefore lie in the user space. Pointers to
the data buffers are as usual passed to the driver with read() and
write() calls. The driver then initializes a DMA transfer where the PCI
device is bus master.
The driver of course has to split the transfer into several smaller
ones, because the memory pages which contain the data buffers could be
spread across the complete memory.
Before i can actually start the transfer, i have to make sure that the
pages are not swapped and remain locked during the transfer.
The problem I have is: Is there an efficient way to lock the pages which
are accessed by the DMA?
The program using the driver can't use mlock(), because the program does
not know about DMA transfers somewhere below the driver.
The driver should not use mlock() either, because i think that the
execution of mlock() takes about as long as copying the data directly
with copy_from/to_user(). Additionally, I could not unlock() the memory
after the transfer, because the main program might have locked the same
memory area and wants the memory to remain locked.
So what can i do then?
bye
next reply other threads:[~2001-02-20 10:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-20 10:57 Norbert Roos [this message]
2001-02-20 12:37 ` Probs with PCI bus master DMA to user space Alan Cox
2001-02-20 17:03 ` David Woodhouse
-- strict thread matches above, loose matches on Subject: below --
2001-02-20 13:31 Norbert Roos
2001-02-20 13:37 ` Jeff Garzik
2001-02-20 14:10 ` Norbert Roos
2001-02-20 14:49 ` Jeff Garzik
2001-02-20 16:50 ` Norbert Roos
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=3A924D8A.FBEAD695@cluster-labs.de \
--to=norbert.roos@cluster-labs.de \
--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