Message-ID: <9de125b10df7471abcea747f12fdc00b@SFHDAG7NODE2.st.com>
Date:   Wed, 29 Mar 2017 18:56:53 +0000
From:   Loic PALLARDY <loic.pallardy@...com>
To:     Jiaying Liang <wendy.liang@...inx.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



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

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.

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

Powered by blists - more mailing lists