[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA07jV-Neu5r2-CFFsnuN9pT_g9kV=zSSbzhbxCFODHe4v9b=g@mail.gmail.com>
Date: Tue, 28 Mar 2017 11:52:53 -0700
From: Wendy Liang <sunnyliangjy@...il.com>
To: Suman Anna <s-anna@...com>
Cc: Wendy Liang <wendy.liang@...inx.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
Wendy Liang <jliang@...inx.com>
Subject: Re: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory
Thanks Suman for your comments.
On Mon, Mar 27, 2017 at 8:54 AM, Suman Anna <s-anna@...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.
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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists