On 12/17/10 15:14, Saravana Kannan wrote:
Catalin Marinas wrote:
Russell,
I agree with your point about using an API for purpose and not property.
But I read Catalin's proposal as, let's treat secure domain as another
DMA
"device". If we make a conscious agreement to do that, then using the
DMA
Catalin Marinas wrote:
>> Russell,
>>
>> I agree with your point about using an API for purpose and not property.
>> But I read Catalin's proposal as, let's treat secure domain as another
>> DMA
>> "device". If we make a conscious agreement to do that, then using the
>> DMA
>> API for secure domain
On 17 December 2010 10:26, Saravana Kannan wrote:
>>> Looks like you agree with our approach. If that's the case, would you
>>> mind
>>> Acking Jeff's initial patch that this thread is based on?
>>
>> I read Catalin's reply as agreeing with me.
>
> Catalin, Can you clarify?
I'll try but I started
> On Fri, Dec 17, 2010 at 02:26:44AM -0800, Saravana Kannan wrote:
>> After Catalin's response to clarify, if we still end up not treating
>> secure domain as a "DMA device", then what's the alternative? Can we get
>> an explicit "cache invalidate API" that's outside of the DMA APIs? Or a
>> gener
On Fri, Dec 17, 2010 at 02:26:44AM -0800, Saravana Kannan wrote:
> After Catalin's response to clarify, if we still end up not treating
> secure domain as a "DMA device", then what's the alternative? Can we get
> an explicit "cache invalidate API" that's outside of the DMA APIs? Or a
> general unca
>> Catalin,
>>
>> Looks like you agree with our approach. If that's the case, would you
>> mind
>> Acking Jeff's initial patch that this thread is based on?
>
> I read Catalin's reply as agreeing with me.
Catalin, Can you clarify?
>> Russell,
>>
>> Does Catalin's proposal sound acceptable to you
On Thu, Dec 16, 2010 at 06:55:06PM -0800, Saravana Kannan wrote:
>
> > On 12 December 2010 04:58, Saravana Kannan wrote:
> >> As you and James suggested, having the NS bit set by the secure world is
> >> definitely a solution that would work. But IMHO, the explicit cache
> >> flush/invalidate app
> On 12 December 2010 04:58, Saravana Kannan wrote:
>> As you and James suggested, having the NS bit set by the secure world is
>> definitely a solution that would work. But IMHO, the explicit cache
>> flush/invalidate approach keeps the design simple and easy to maintain.
>
> That is indeed an a
On 12 December 2010 04:58, Saravana Kannan wrote:
> As you and James suggested, having the NS bit set by the secure world is
> definitely a solution that would work. But IMHO, the explicit cache
> flush/invalidate approach keeps the design simple and easy to maintain.
That is indeed an approach t
On 12/10/2010 02:00 AM, Catalin Marinas wrote:
On 10 December 2010 00:58, Saravana Kannan wrote:
Russell King - ARM Linux wrote:
On Thu, Dec 09, 2010 at 01:23:24AM -0800, skan...@codeaurora.org wrote:
Russell, Have you had a chance to look at this? Any comments? How do we
move ahead?
I ha
On 10 December 2010 00:58, Saravana Kannan wrote:
> Russell King - ARM Linux wrote:
>>
>> On Thu, Dec 09, 2010 at 01:23:24AM -0800, skan...@codeaurora.org wrote:
>>>
>>> Russell, Have you had a chance to look at this? Any comments? How do we
>>> move ahead?
>>
>> I had connected the other thread w
Russell King - ARM Linux wrote:
On Thu, Dec 09, 2010 at 01:23:24AM -0800, skan...@codeaurora.org wrote:
Russell, Have you had a chance to look at this? Any comments? How do we
move ahead?
I had connected the other thread with this one - it's pretty hard not
to as it included this patch in that
On Thu, Dec 09, 2010 at 01:23:24AM -0800, skan...@codeaurora.org wrote:
> Russell, Have you had a chance to look at this? Any comments? How do we
> move ahead?
I had connected the other thread with this one - it's pretty hard not
to as it included this patch in that set as the first patch.
--
To u
> 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 imag
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
On Fri, Dec 03, 2010 at 08:36:53PM +, 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 o
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_sta
Russell King - ARM Linux wrote:
On Thu, Dec 02, 2010 at 02:11:18PM -0800, Jeff Ohlstein wrote:
Some machines require the use of coherent memory to bring up auxillary
cpus, and thus want to use dma_alloc_coherent prior to smp_init
completing.
I'd like to see the rest of the code to indicate why
On Thu, Dec 02, 2010 at 02:11:18PM -0800, Jeff Ohlstein wrote:
> Some machines require the use of coherent memory to bring up auxillary
> cpus, and thus want to use dma_alloc_coherent prior to smp_init
> completing.
I'd like to see the rest of the code to indicate why you need DMA
coherent memory
Some machines require the use of coherent memory to bring up auxillary
cpus, and thus want to use dma_alloc_coherent prior to smp_init
completing.
Signed-off-by: Jeff Ohlstein
---
arch/arm/mm/dma-mapping.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/dma-
20 matches
Mail list logo
