From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Spence Nick" <Nick.Spence@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] [POWERPC] Reintroduce O_SYNC flag to make DRAM non-cached.
Date: Thu, 8 May 2008 11:54:56 +0200 [thread overview]
Message-ID: <3b94d56008ca72b846fbdf8cfe9925e6@kernel.crashing.org> (raw)
In-Reply-To: <9E50B2A5FE44294CBF877745D9A4125F01D37125@az33exm24.fsl.freescale.net>
> We found the problem when porting code from Linux 2.4 to 2.6, where a
> user space application maps a 1 MByte region of DRAM with the O_SYNC
> flag to communicate with an internal core that shares access to the
> DRAM but does not have any cache snooping logic.
>
> In 2.4 the mem driver honors the O_SYNC flag and makes the requested
> memory
> memory non-cached so that writes from user space are immediately
> available
> to the second core.
If you only need to write from the core running Linux, and never
read the memory back, and the secondary core never writes the memory,
your userland program can simply do dcbst on it after it wrote it.
Otherwise, if your CPU has BAT registers, you could use those to
force that memory region as non-cacheable (be careful, BATs are not
allowed to overlap each other).
If these things won't work for you, you need to do some simple device
driver, and do non-coherent DMA from it (you can view the secondary
core as an I/O device like any other).
Segher
prev parent reply other threads:[~2008-05-08 9:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-08 5:26 [PATCH] [POWERPC] Reintroduce O_SYNC flag to make DRAM non-cached nick.spence
2008-05-08 5:50 ` Paul Mackerras
2008-05-08 6:31 ` Spence Nick
2008-05-08 6:55 ` Benjamin Herrenschmidt
2008-05-08 7:17 ` Nick Spence
2008-05-08 7:21 ` Benjamin Herrenschmidt
2008-05-08 9:54 ` Segher Boessenkool [this message]
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=3b94d56008ca72b846fbdf8cfe9925e6@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=Nick.Spence@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).