Message-ID: <15d23d63900e4545a40555961c49c421.squirrel@codeaurora.org>
Date:	Thu, 9 Dec 2010 01:23:24 -0800 (PST)
From:	skannan@...eaurora.org
To:	"Saravana Kannan" <skannan@...eaurora.org>
Cc:	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	dwalker@...eaurora.org, linux-arm-msm@...r.kernel.org,
	"Nicolas Pitre" <nico@...vell.com>, linux-kernel@...r.kernel.org,
	"Jeff Ohlstein" <johlstei@...eaurora.org>,
	"Catalin Marinas" <catalin.marinas@....com>,
	"Tejun Heo" <tj@...nel.org>, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm: dma-mapping: move consistent_init to 
     early_initcall


> 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
>

Russell, Have you had a chance to look at this? Any comments? How do we
move ahead?

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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists