All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Wendy Liang <sunnyliangjy@gmail.com>
Cc: Wendy Liang <wendy.liang@xilinx.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Wendy Liang <jliang@xilinx.com>
Subject: Re: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory
Date: Tue, 28 Mar 2017 18:24:09 -0500	[thread overview]
Message-ID: <3aaedbd9-168f-9dd0-62de-3e4209ee09a8@ti.com> (raw)
In-Reply-To: <CAA07jV-Neu5r2-CFFsnuN9pT_g9kV=zSSbzhbxCFODHe4v9b=g@mail.gmail.com>

Hi Wendy,

On 03/28/2017 01:52 PM, Wendy Liang wrote:
> Thanks Suman for your comments.
> 
> On Mon, Mar 27, 2017 at 8:54 AM, Suman Anna <s-anna@ti.com> wrote:
>> Hi Wendy,
>>
>> On 03/24/2017 02:22 PM, Wendy Liang wrote:
>>> This patch enables the remoteproc to specify the shared memory.
>>> Remoteproc declared this memory as DMA memory.
>>> It can be used for virtio, or shared buffers.
>>
>> You should be able to achieve this without any remoteproc core changes.
>> You can do this by defining a reserved-memory node in your DTS file (can
>> be a CMA pool or a DMA pool), assigning the node using memory-region in
>> your remoteproc DT node and using the function,
>> of_reserved_mem_device_init() in your remoteproc driver.
> 
> The idea to introduce the rproc_mem is to let the remote to specify
> the shared memory.
> I am trying to see if there is a way to specify this software attribute without
> touching the device tree as it doesn't look like it is hardware related.
> And try to see if there is a way that when I change the firmware, i
> don't need to change the device tree.

So is this shared memory going to be accessed through an MMU by the
remote processor? If not, don't you need a specific carveout, which
would then in turn mean boot-time memory reservation?

regards
Suman

> 
> Thanks,
> Wendy
> 
>>
>> regards
>> Suman
>>
>>>
>>> Wendy Liang (3):
>>>   remoteproc: add rproc mem resource entry
>>>   remoteproc: add rproc_mem resource entry handler
>>>   remoteproc: Release DMA declare mem when cleanup rsc
>>>
>>>  drivers/remoteproc/remoteproc_core.c | 40 ++++++++++++++++++++++++++++++++++++
>>>  include/linux/remoteproc.h           | 23 ++++++++++++++++++++-
>>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com>
To: Wendy Liang <sunnyliangjy@gmail.com>
Cc: Wendy Liang <wendy.liang@xilinx.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	<linux-remoteproc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, Wendy Liang <jliang@xilinx.com>
Subject: Re: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory
Date: Tue, 28 Mar 2017 18:24:09 -0500	[thread overview]
Message-ID: <3aaedbd9-168f-9dd0-62de-3e4209ee09a8@ti.com> (raw)
In-Reply-To: <CAA07jV-Neu5r2-CFFsnuN9pT_g9kV=zSSbzhbxCFODHe4v9b=g@mail.gmail.com>

Hi Wendy,

On 03/28/2017 01:52 PM, Wendy Liang wrote:
> Thanks Suman for your comments.
> 
> On Mon, Mar 27, 2017 at 8:54 AM, Suman Anna <s-anna@ti.com> wrote:
>> Hi Wendy,
>>
>> On 03/24/2017 02:22 PM, Wendy Liang wrote:
>>> This patch enables the remoteproc to specify the shared memory.
>>> Remoteproc declared this memory as DMA memory.
>>> It can be used for virtio, or shared buffers.
>>
>> You should be able to achieve this without any remoteproc core changes.
>> You can do this by defining a reserved-memory node in your DTS file (can
>> be a CMA pool or a DMA pool), assigning the node using memory-region in
>> your remoteproc DT node and using the function,
>> of_reserved_mem_device_init() in your remoteproc driver.
> 
> The idea to introduce the rproc_mem is to let the remote to specify
> the shared memory.
> I am trying to see if there is a way to specify this software attribute without
> touching the device tree as it doesn't look like it is hardware related.
> And try to see if there is a way that when I change the firmware, i
> don't need to change the device tree.

So is this shared memory going to be accessed through an MMU by the
remote processor? If not, don't you need a specific carveout, which
would then in turn mean boot-time memory reservation?

regards
Suman

> 
> Thanks,
> Wendy
> 
>>
>> regards
>> Suman
>>
>>>
>>> Wendy Liang (3):
>>>   remoteproc: add rproc mem resource entry
>>>   remoteproc: add rproc_mem resource entry handler
>>>   remoteproc: Release DMA declare mem when cleanup rsc
>>>
>>>  drivers/remoteproc/remoteproc_core.c | 40 ++++++++++++++++++++++++++++++++++++
>>>  include/linux/remoteproc.h           | 23 ++++++++++++++++++++-
>>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-03-28 23:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 19:22 [RFC LINUX PATCH 0/3] Allow remote to specify shared memory Wendy Liang
2017-03-24 19:22 ` Wendy Liang
2017-03-24 19:22 ` [RFC LINUX PATCH 1/3] remoteproc: add rproc mem resource entry Wendy Liang
2017-03-24 19:22   ` Wendy Liang
2017-03-24 19:22 ` [RFC LINUX PATCH 2/3] remoteproc: add rproc_mem resource entry handler Wendy Liang
2017-03-24 19:22   ` Wendy Liang
2017-03-24 19:22 ` [RFC LINUX PATCH 3/3] remoteproc: Release DMA declare mem when cleanup rsc Wendy Liang
2017-03-24 19:22   ` Wendy Liang
2017-03-27 15:54 ` [RFC LINUX PATCH 0/3] Allow remote to specify shared memory Suman Anna
2017-03-27 15:54   ` Suman Anna
2017-03-28 18:52   ` Wendy Liang
2017-03-28 23:24     ` Suman Anna [this message]
2017-03-28 23:24       ` Suman Anna
2017-03-29 16:41       ` Jiaying Liang
2017-03-29 16:41         ` Jiaying Liang
2017-03-29 18:56         ` Loic PALLARDY
2017-03-29 18:56           ` Loic PALLARDY
2017-03-30 17:39           ` Jiaying Liang
2017-03-30 17:39             ` Jiaying Liang

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=3aaedbd9-168f-9dd0-62de-3e4209ee09a8@ti.com \
    --to=s-anna@ti.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=jliang@xilinx.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=sunnyliangjy@gmail.com \
    --cc=wendy.liang@xilinx.com \
    /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.