Message-ID: <DC2968D6352D1841BA729D8C06CC9DBB99067F79@XSJ-PSEXMBX01.xlnx.xilinx.com>
Date:   Thu, 30 Mar 2017 17:39:24 +0000
From:   Jiaying Liang <wendy.liang@...inx.com>
To:     Loic PALLARDY <loic.pallardy@...com>, Suman Anna <s-anna@...com>,
        "Wendy Liang" <sunnyliangjy@...il.com>
CC:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        "linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory

HI Loic,

> -----Original Message-----
> From: Loic PALLARDY [mailto:loic.pallardy@...com]
> Sent: Wednesday, March 29, 2017 11:57 AM
> To: Jiaying Liang; Suman Anna; Wendy Liang
> Cc: Bjorn Andersson; linux-remoteproc@...r.kernel.org; linux-
> kernel@...r.kernel.org
> Subject: RE: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory
>
>
>
> > -----Original Message-----
> > From: linux-remoteproc-owner@...r.kernel.org [mailto:linux-remoteproc-
> > owner@...r.kernel.org] On Behalf Of Jiaying Liang
> > Sent: Wednesday, March 29, 2017 6:41 PM
> > To: Suman Anna <s-anna@...com>; Wendy Liang <sunnyliangjy@...il.com>
> > Cc: Bjorn Andersson <bjorn.andersson@...aro.org>; linux-
> > remoteproc@...r.kernel.org; linux-kernel@...r.kernel.org
> > Subject: RE: [RFC LINUX PATCH 0/3] Allow remote to specify shared
> > memory
> >
> > Hi Suman,
> >
> > > -----Original Message-----
> > > From: Suman Anna [mailto:s-anna@...com]
> > > Sent: Tuesday, March 28, 2017 4:24 PM
> > > To: Wendy Liang
> > > Cc: Jiaying Liang; Bjorn Andersson;
> > > linux-remoteproc@...r.kernel.org;
> > > linux- kernel@...r.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@...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?
> Hi Wendy,
>
> Potential issue with this proposal if the order resource table is proceed. This
> memory region should be assigned to device driver first before starting any
> allocation.
[Wendy] User will need to put it to the first entry in the resource table. So that
It can be declared first before device driver to allocate memory.
> Moreover you can assign only one region to a device. But you need different
> memory regions with different attributes: one for firmware and one for vring
> for example.
> That's why we propose sub-dev mechanism some months ago.
[Wendy]  Just in our case, we only use virtio devices. But I agree, there can be
Limitations if you have other sub-devices.

>
> I think we need to find a central mechanism to manage "fixed" memory
> region for firmware (carveout) vring as both are handled by rproc.
> For rpmsg buffer, one proposal will be to assigned a dedicated region to
> vring device as mentioned in "[PATCH v4 0/5] virtio_rpmsg: make rpmsg
> channel configurable" cover letter.
> It will be rproc responsibility to provide this specific memory region based
> either on DT or an firmware resource table information to virtio device.
[Wendy] Just the virtio_rpmsg is not in the latest Linux kernel master. Is there
Any plan to apply the patch?

I agree we need to find a central mechanism to manage "fixed" memory.
Here are some questions:
* Shall we reuse carveout resource for "fixed" memory?
    * Although "fixed" memory doesn't sound like the same as "carveout" memory to me.
       We may consider "fixed" memory as carveout resource with pre-defined addresses. Is this ok?
* How to linked the fixed memory to the target device (e.g. virtio device)?, Can we use "name" of the memory resource?
   * how to "formalize" the name? "virtio_<id>"?

Maybe Bjorn can provide some suggestions on the "fixed" memory solution.

Thanks,
Wendy


>
> Regards,
> Loic
> >
> > 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@...r.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.
> >
> > N     r  y   b X  ǧv ^ )޺{.n +    {  騵 k ȧ .  ܨ}   Ơz &j:+v        zZ+  +zf   h   ~    i
> z . w   ?
> > & )ߢ.f


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.

Powered by blists - more mailing lists