From: slash.tmp@free•fr (Mason)
To: linux-arm-kernel@lists•infradead.org
Subject: Unhandled fault: page domain fault (0x81b) at 0x00e41008
Date: Sat, 23 Jan 2016 21:53:30 +0100 [thread overview]
Message-ID: <56A3E84A.1000604@free.fr> (raw)
In-Reply-To: <20160123113438.GG19062@n2100.arm.linux.org.uk>
On 23/01/2016 12:34, Russell King - ARM Linux wrote:
> [snip firmware interface blurb -- I'll take a look]
>
> However, if you're going to stick with your approach, there's a way to
> avoid the need to copy into userspace and then copy back out. It's
> called sendfile(). This can be used to send part (or all) of one file
> to another file descriptor. It's intended use was to accelerate
> server applications such as apache, but it seems to be a good fit
> for what you want.
>
> If you arrange for your module to provide an anonymous file descriptor,
> you can use that as the destination file descriptor for uploading the
> contents of your file to using sendfile(). The anonymous file
> descriptor's f_ops->write method should be called as if userspace
> were writing the firmware into this file descriptor - but without the
> data being copied into and back out of userspace.
>
> As the file descriptor will be writable, you can also use lseek() and
> write() to invoke the f_ops->write method for any file offset, so you
> can also use it to upload at any offset and length via standard APIs.
>
> It seems to me that such a solution has a very nice elegance to it.
True.
But I would consider mmaping /dev/mem even simpler: it doesn't
require writing a single line of kernel code, and it works as
expected. The gist of the code is:
fd = open("/path/to/file", O_RDONLY);
mem_fd = open("/dev/mem", O_WRONLY | O_SYNC);
va = mmap(NULL, len, PROT_WRITE, MAP_SHARED, mem_fd, phys_addr);
read(fd, va, len);
And that's it. If I understand correctly, the mem driver
will copy the file contents directly to "remote" RAM.
Is there something wrong with this solution, in your opinion?
Regards.
next prev parent reply other threads:[~2016-01-23 20:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 17:37 Unhandled fault: page domain fault (0x81b) at 0x00e41008 Mason
2016-01-22 17:48 ` Russell King - ARM Linux
2016-01-22 18:59 ` Mason
2016-01-22 19:34 ` Russell King - ARM Linux
2016-01-22 23:15 ` Mason
2016-01-22 23:57 ` Russell King - ARM Linux
2016-01-23 11:14 ` Mason
2016-01-23 11:34 ` Russell King - ARM Linux
2016-01-23 20:53 ` Mason [this message]
2016-01-23 22:46 ` Mason
2016-01-23 23:59 ` Russell King - ARM Linux
2016-01-24 13:27 ` Mason
2016-01-27 10:36 ` Mason
2016-01-27 10:48 ` Russell King - ARM Linux
2016-01-27 12:04 ` Mason
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=56A3E84A.1000604@free.fr \
--to=slash.tmp@free$(echo .)fr \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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