All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saravana Kannan <skannan@codeaurora.org>
To: Saravana Kannan <skannan@codeaurora.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	dwalker@codeaurora.org, linux-arm-msm@vger.kernel.org,
	Nicolas Pitre <nico@marvell.com>,
	linux-kernel@vger.kernel.org,
	Jeff Ohlstein <johlstei@codeaurora.org>,
	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, 20 Dec 2010 15:22:02 -0800	[thread overview]
Message-ID: <4D0FE51A.4050506@codeaurora.org> (raw)
In-Reply-To: <7276921204ba82a2065faa61548f1699.squirrel@www.codeaurora.org>

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
>>> API for secure domain would be "using it for its purpose" and we will
>>> make
>>> an effort to not break it with future updates. Of course, if we don't
>>> agree on that proposal, then we can't use the DMA API for secure domain
>>> stuff.
>>
>> If there is no better proposal, I'm for such extension to the DMA API.
>>  From the kernel perspecitve, the secure side is just another entity
>> that accesses the RAM directly. It's not a physically separate device
>> indeed but from a direct memory access perspective it can be treated
>> as any other device.
>>
>> In the DMA API we can fall back to the non-coherent ops when a NULL
>> struct device is passed. I assume in your code you already pass a NULL
>> device to dma_alloc_coherent().
>
> Russell,
>
> Would the extension of the DMA API as described above be acceptable to
> you? If not, can you please suggest an alternative that's acceptable to
> you?

Ping...

-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, 20 Dec 2010 15:22:02 -0800	[thread overview]
Message-ID: <4D0FE51A.4050506@codeaurora.org> (raw)
In-Reply-To: <7276921204ba82a2065faa61548f1699.squirrel@www.codeaurora.org>

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
>>> API for secure domain would be "using it for its purpose" and we will
>>> make
>>> an effort to not break it with future updates. Of course, if we don't
>>> agree on that proposal, then we can't use the DMA API for secure domain
>>> stuff.
>>
>> If there is no better proposal, I'm for such extension to the DMA API.
>>  From the kernel perspecitve, the secure side is just another entity
>> that accesses the RAM directly. It's not a physically separate device
>> indeed but from a direct memory access perspective it can be treated
>> as any other device.
>>
>> In the DMA API we can fall back to the non-coherent ops when a NULL
>> struct device is passed. I assume in your code you already pass a NULL
>> device to dma_alloc_coherent().
>
> Russell,
>
> Would the extension of the DMA API as described above be acceptable to
> you? If not, can you please suggest an alternative that's acceptable to
> you?

Ping...

-Saravana

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

  reply	other threads:[~2010-12-20 23: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
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 [this message]
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=4D0FE51A.4050506@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.