All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saravana Kannan <skannan@codeaurora.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: dwalker@codeaurora.org, linux-arm-msm@vger.kernel.org,
	Nicolas Pitre <nico@marvell.com>,
	linux-kernel@vger.kernel.org,
	Jeff Ohlstein <johlstei@codeaurora.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Tejun Heo <tj@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: dma-mapping: move consistent_init to early_initcall
Date: Mon, 06 Dec 2010 22:22:15 -0800	[thread overview]
Message-ID: <4CFDD297.4020600@codeaurora.org> (raw)
In-Reply-To: <20101203203653.GB10245@n2100.arm.linux.org.uk>

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.
> 
> So when ARM gets DMA-coherent caches, you of course aren't going to
> complain that the DMA APIs start avoiding doing the current tricks with
> non-cacheable memory?
> 
> I view what you're doing above with the DMA API as an abuse of the API.
> Just like the problems we're facing with ioremap() being used on system
> RAM, you're asking for problems when the ARM architecture changes because
> you're using an API for it's current properties, not for its purpose.

You are right. Thanks for catching this.

So, that basically leaves us with these options:
* Create another API to allow getting uncached pages. I don't think we 
will be the first or the last to want uncached pages. Even if ARM 
introduces DMA-coherent caches, it's  possible for SoC vendors to have 
other h/w blocks that could directly operate on memory. The cache might 
not be coherent with these h/w blocks.
* Add a cache invalidate API that's outside the DMA APIs and can be used 
  when needed.

Do one of the above two options sound reasonable to you?

> I've been on for years about purpose-designed APIs for cache issues,
> and every time someone abuses them, they eventually end up suffering
> breakage.
> 
> Let's wait until the full set of patches is available before discussing
> further.

Jeff Ohlstein sent out a series of patches ([PATCH 0/5] SMP support for 
msm). The patch that deals with talking to the secure domain code is 
titled "[PATCH 2/5] msm: scm-boot: Support for setting cold/warm boot 
addresses". I see that you replied to an email on that, but it's not 
clear if you connected that patch with this thread.

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

WARNING: multiple messages have this Message-ID (diff)
From: skannan@codeaurora.org (Saravana Kannan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: dma-mapping: move consistent_init to early_initcall
Date: Mon, 06 Dec 2010 22:22:15 -0800	[thread overview]
Message-ID: <4CFDD297.4020600@codeaurora.org> (raw)
In-Reply-To: <20101203203653.GB10245@n2100.arm.linux.org.uk>

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.
> 
> So when ARM gets DMA-coherent caches, you of course aren't going to
> complain that the DMA APIs start avoiding doing the current tricks with
> non-cacheable memory?
> 
> I view what you're doing above with the DMA API as an abuse of the API.
> Just like the problems we're facing with ioremap() being used on system
> RAM, you're asking for problems when the ARM architecture changes because
> you're using an API for it's current properties, not for its purpose.

You are right. Thanks for catching this.

So, that basically leaves us with these options:
* Create another API to allow getting uncached pages. I don't think we 
will be the first or the last to want uncached pages. Even if ARM 
introduces DMA-coherent caches, it's  possible for SoC vendors to have 
other h/w blocks that could directly operate on memory. The cache might 
not be coherent with these h/w blocks.
* Add a cache invalidate API that's outside the DMA APIs and can be used 
  when needed.

Do one of the above two options sound reasonable to you?

> I've been on for years about purpose-designed APIs for cache issues,
> and every time someone abuses them, they eventually end up suffering
> breakage.
> 
> Let's wait until the full set of patches is available before discussing
> further.

Jeff Ohlstein sent out a series of patches ([PATCH 0/5] SMP support for 
msm). The patch that deals with talking to the secure domain code is 
titled "[PATCH 2/5] msm: scm-boot: Support for setting cold/warm boot 
addresses". I see that you replied to an email on that, but it's not 
clear if you connected that patch with this thread.

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  parent reply	other threads:[~2010-12-07  6:22 UTC|newest]

Thread overview: 46+ 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:11 ` Jeff Ohlstein
2010-12-02 22:11 ` Jeff Ohlstein
2010-12-02 22:19 ` Russell King - ARM Linux
2010-12-02 22:19   ` Russell King - ARM Linux
2010-12-03 20:06   ` Saravana Kannan
2010-12-03 20:06     ` Saravana Kannan
2010-12-03 20:36     ` Russell King - ARM Linux
2010-12-03 20:36       ` Russell King - ARM Linux
2010-12-03 22:45       ` Jamie Iles
2010-12-03 22:45         ` Jamie Iles
2010-12-07  6:22       ` Saravana Kannan [this message]
2010-12-07  6:22         ` Saravana Kannan
2010-12-09  9:23         ` skannan
2010-12-09  9:23           ` skannan
2010-12-09  9:23           ` skannan at codeaurora.org
2010-12-09 10:38           ` Russell King - ARM Linux
2010-12-09 10:38             ` Russell King - ARM Linux
2010-12-10  0:58             ` Saravana Kannan
2010-12-10  0:58               ` Saravana Kannan
2010-12-10 10:00               ` Catalin Marinas
2010-12-10 10:00                 ` Catalin Marinas
2010-12-12  4:58                 ` Saravana Kannan
2010-12-12  4:58                   ` Saravana Kannan
2010-12-13 15:26                   ` Catalin Marinas
2010-12-13 15:26                     ` Catalin Marinas
2010-12-17  2:55                     ` Saravana Kannan
2010-12-17  2:55                       ` Saravana Kannan
2010-12-17  2:55                       ` Saravana Kannan
2010-12-17  9:48                       ` Russell King - ARM Linux
2010-12-17  9:48                         ` Russell King - ARM Linux
2010-12-17 10:26                         ` Saravana Kannan
2010-12-17 10:26                           ` Saravana Kannan
2010-12-17 10:26                           ` Saravana Kannan
2010-12-17 10:56                           ` Russell King - ARM Linux
2010-12-17 10:56                             ` Russell King - ARM Linux
2010-12-17 11:09                             ` Saravana Kannan
2010-12-17 11:09                               ` Saravana Kannan
2010-12-17 11:09                               ` Saravana Kannan
2010-12-17 11:31                           ` Catalin Marinas
2010-12-17 11:31                             ` Catalin Marinas
2010-12-17 23:14                             ` Saravana Kannan
2010-12-17 23:14                               ` Saravana Kannan
2010-12-17 23:14                               ` Saravana Kannan
2010-12-20 23:22                               ` 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=4CFDD297.4020600@codeaurora.org \
    --to=skannan@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=dwalker@codeaurora.org \
    --cc=johlstei@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nico@marvell.com \
    --cc=tj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.