RE: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory

[Jiaying Liang <wendy.liang@xilinx.com>]

Hi Suman,

> -----Original Message-----
> From: Suman Anna [mailto:s-anna@ti.com]
> Sent: Tuesday, March 28, 2017 4:24 PM
> To: Wendy Liang
> Cc: Jiaying Liang; Bjorn Andersson; linux-remoteproc@vger.kernel.org; linux-
> kernel@vger.kernel.org; Jiaying Liang
> Subject: Re: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory
>
> 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?
[Wendy] This memory is not accessed through MMU by remote.
Here is the usecase, the number of remotes can be changed at run time,
Also the firmware running on the remotes can be changed. And the remote will
Need to memory map those memory before it can use it.

From what you have suggested, we reserved memory from the device node, and then remoteproc driver linked to that reserved memory with "memory-region", I suppose different remoteproc drivers can share one "memory-region". However, now the question is how the remote knows the shared memory.
Let say I use rpmsg for the communication between the two. But how can remote knows about the shared buffers before it can used it.

I  saw Loic has a patch to add virtio config to specify this buffer, however, it is not in the latest linux kernel master. And thus, trying to see if there is another way to solve this issue. Use existing carveout to specify this memory?

Thanks,
Wendy

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



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.