From: jamie@jamieiles.com (Jamie Iles)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: dma-mapping: move consistent_init to early_initcall
Date: Fri, 3 Dec 2010 22:45:23 +0000 [thread overview]
Message-ID: <20101203224523.GU12385@pulham.picochip.com> (raw)
In-Reply-To: <20101203203653.GB10245@n2100.arm.linux.org.uk>
On Fri, Dec 03, 2010 at 08:36:53PM +0000, Russell King - ARM Linux wrote:
> On Fri, Dec 03, 2010 at 12:06:53PM -0800, Saravana Kannan wrote:
> > The MSM8660 SoC uses the TrustZone technology and the Linux kernel
> > executes in normal/non-secure domain. When the second core is brought
> > out of reset, it starts executing a secure image which then jumps to
> > "secondary_startup". So, before bringing the second core out of reset,
> > we need to inform the secure domain code where secondary_startup is
> > located in memory.
> >
> > We do the communication with the secure code by using buffers in memory.
> > The cache treats the NS (non secure) bit as an additional address bit
> > when tagging memory. Hence, cache accesses are not coherent between the
> > secure and non-secure domains. So, the secure side flushes it's cache
> > after writing to the buffer. To properly read the response from the
> > secure side, the kernel has to pick a buffer that isn't cacheable in the
> > first place. We have similar issues in the reverse direction.
Is the secure world running with the MMU enabled (or is there enough onchip
memory for page tables in the secure world)? If so, could you recreate the
direct-mapping in the secure world with the same attributes and the nonsecure
bit set in the page table descriptors? The cache should be coherent between
both worlds in this case.
Alternatively could you not pass the address to the monitor mode in a
register?
Jamie
next prev parent reply other threads:[~2010-12-03 22:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-02 22:11 [PATCH] arm: dma-mapping: move consistent_init to early_initcall Jeff Ohlstein
2010-12-02 22:19 ` Russell King - ARM Linux
2010-12-03 20:06 ` Saravana Kannan
2010-12-03 20:36 ` Russell King - ARM Linux
2010-12-03 22:45 ` Jamie Iles [this message]
2010-12-07 6:22 ` Saravana Kannan
2010-12-09 9:23 ` skannan at codeaurora.org
2010-12-09 10:38 ` Russell King - ARM Linux
2010-12-10 0:58 ` Saravana Kannan
2010-12-10 10:00 ` Catalin Marinas
2010-12-12 4:58 ` Saravana Kannan
2010-12-13 15:26 ` Catalin Marinas
2010-12-17 2:55 ` Saravana Kannan
2010-12-17 9:48 ` Russell King - ARM Linux
2010-12-17 10:26 ` Saravana Kannan
2010-12-17 10:56 ` Russell King - ARM Linux
2010-12-17 11:09 ` Saravana Kannan
2010-12-17 11:31 ` Catalin Marinas
2010-12-17 23:14 ` Saravana Kannan
2010-12-20 23:22 ` Saravana Kannan
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=20101203224523.GU12385@pulham.picochip.com \
--to=jamie@jamieiles.com \
--cc=linux-arm-kernel@lists.infradead.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).