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.
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(-)
--
1.9.1
From: Wendy Liang <[email protected]>
Add a resource entry to the resource table to tells the host the remote
processor's memory which can be used as shared memory.
Signed-off-by: Wendy Liang <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
---
include/linux/remoteproc.h | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 81da495..799f041 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -115,7 +115,8 @@ enum fw_resource_type {
RSC_DEVMEM = 1,
RSC_TRACE = 2,
RSC_VDEV = 3,
- RSC_LAST = 4,
+ RSC_RPROC_MEM = 4,
+ RSC_LAST = 5,
};
#define FW_RSC_ADDR_ANY (-1)
@@ -306,6 +307,26 @@ struct fw_rsc_vdev {
} __packed;
/**
+ * struct fw_rsc_rproc_mem - remote processor memory
+ * @da: device address
+ * @pa: physical address
+ * @len: length (in bytes)
+ * @reserved: reserved (must be zero)
+ *
+ * This resource entry tells the host to the remote processor
+ * memory that the host can be used as shared memory.
+ *
+ * These request entries should precede other shared resource entries
+ * such as vdevs, vrings.
+ */
+struct fw_rsc_rproc_mem {
+ u32 da;
+ u32 pa;
+ u32 len;
+ u32 reserved;
+} __packed;
+
+/**
* struct rproc_mem_entry - memory entry descriptor
* @va: virtual address
* @dma: dma address
--
1.9.1
From: Wendy Liang <[email protected]>
Release the declared DMA memory in the end of resource
cleanup.
Signed-off-by: Wendy Liang <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
---
drivers/remoteproc/remoteproc_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 0ffd9dc..9d32737 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -882,6 +882,9 @@ static void rproc_resource_cleanup(struct rproc *rproc)
/* clean up remote vdev entries */
list_for_each_entry_safe(rvdev, rvtmp, &rproc->rvdevs, node)
kref_put(&rvdev->refcount, rproc_vdev_release);
+
+ /* Release declared DMA memory */
+ dma_release_declared_memory(dev->parent);
}
/*
--
1.9.1
From: Wendy Liang <[email protected]>
Add resource table handler to handle fw_rsc_rproc_mem entry.
Signed-off-by: Wendy Liang <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
---
drivers/remoteproc/remoteproc_core.c | 37 ++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 3dabb20..0ffd9dc 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -720,6 +720,42 @@ static int rproc_handle_carveout(struct rproc *rproc,
return ret;
}
+/**
+ * rproc_handle_rproc_mem() - handle remote processor memory
+ * @rproc: rproc handle
+ * @rsc: the resource entry
+ * @avail: size of available data (for image validation)
+ *
+ * This function will handle declare the remote procesor's memory
+ * as DMA memory of the remoteproc, and then, the host can use it
+ * as shared memory, e.g. vrings ahre shared buffers.
+ */
+static int rproc_handle_rproc_mem(struct rproc *rproc,
+ struct fw_rsc_rproc_mem *rsc,
+ int offset, int avail)
+{
+ struct device *dev = &rproc->dev;
+ int ret;
+
+ if (sizeof(*rsc) > avail) {
+ dev_err(dev, "rproc_mem rsc is truncated\n");
+ return -EINVAL;
+ }
+
+ if (rsc->pa == FW_RSC_ADDR_ANY) {
+ dev_err(dev, "not able to declare rproc mem, pa is 0x%x\n",
+ rsc->pa);
+ return -EINVAL;
+ }
+ ret = dma_declare_coherent_memory(dev->parent, rsc->pa,
+ rsc->pa, rsc->len, DMA_MEMORY_MAP);
+ if (!ret) {
+ dev_err(dev, "failed to declare rproc mem as DMA mem.\n");
+ return -ENOMEM;
+ }
+ return 0;
+}
+
/*
* A lookup table for resource handlers. The indices are defined in
* enum fw_resource_type.
@@ -729,6 +765,7 @@ static int rproc_handle_carveout(struct rproc *rproc,
[RSC_DEVMEM] = (rproc_handle_resource_t)rproc_handle_devmem,
[RSC_TRACE] = (rproc_handle_resource_t)rproc_handle_trace,
[RSC_VDEV] = (rproc_handle_resource_t)rproc_handle_vdev,
+ [RSC_RPROC_MEM] = (rproc_handle_resource_t)rproc_handle_rproc_mem,
};
/* handle firmware resource entries before booting the remote processor */
--
1.9.1
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.
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(-)
>
Thanks Suman for your comments.
On Mon, Mar 27, 2017 at 8:54 AM, Suman Anna <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Suman,
> -----Original Message-----
> From: Suman Anna [mailto:[email protected]]
> Sent: Tuesday, March 28, 2017 4:24 PM
> To: Wendy Liang
> Cc: Jiaying Liang; Bjorn Andersson; [email protected]; linux-
> [email protected]; 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 <[email protected]> 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
> >> [email protected] 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.
> -----Original Message-----
> From: [email protected] [mailto:linux-remoteproc-
> [email protected]] On Behalf Of Jiaying Liang
> Sent: Wednesday, March 29, 2017 6:41 PM
> To: Suman Anna <[email protected]>; Wendy Liang <[email protected]>
> Cc: Bjorn Andersson <[email protected]>; linux-
> [email protected]; [email protected]
> Subject: RE: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory
>
> Hi Suman,
>
> > -----Original Message-----
> > From: Suman Anna [mailto:[email protected]]
> > Sent: Tuesday, March 28, 2017 4:24 PM
> > To: Wendy Liang
> > Cc: Jiaying Liang; Bjorn Andersson; [email protected];
> > linux- [email protected]; 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 <[email protected]> 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
> > >> [email protected] 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
HI Loic,
> -----Original Message-----
> From: Loic PALLARDY [mailto:[email protected]]
> Sent: Wednesday, March 29, 2017 11:57 AM
> To: Jiaying Liang; Suman Anna; Wendy Liang
> Cc: Bjorn Andersson; [email protected]; linux-
> [email protected]
> Subject: RE: [RFC LINUX PATCH 0/3] Allow remote to specify shared memory
>
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:linux-remoteproc-
> > [email protected]] On Behalf Of Jiaying Liang
> > Sent: Wednesday, March 29, 2017 6:41 PM
> > To: Suman Anna <[email protected]>; Wendy Liang <[email protected]>
> > Cc: Bjorn Andersson <[email protected]>; linux-
> > [email protected]; [email protected]
> > Subject: RE: [RFC LINUX PATCH 0/3] Allow remote to specify shared
> > memory
> >
> > Hi Suman,
> >
> > > -----Original Message-----
> > > From: Suman Anna [mailto:[email protected]]
> > > Sent: Tuesday, March 28, 2017 4:24 PM
> > > To: Wendy Liang
> > > Cc: Jiaying Liang; Bjorn Andersson;
> > > [email protected];
> > > linux- [email protected]; 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 <[email protected]>
> 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
> > > >> [email protected] 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.