mbox series

[v4,00/17] remoteproc: add fixed memory region support

Message ID 1532697292-14272-1-git-send-email-loic.pallardy@st.com
Headers show
Series remoteproc: add fixed memory region support | expand

Message

Loic Pallardy July 27, 2018, 1:14 p.m. UTC
The aim of the series is to implement carveout memory management as
discussed during OpenAMP weekly call and defined in proposed document [1]

This first series focus only on adding support of the different types of
carveout memories (dynamic, fixed, platform driver depend...).
64bit resource table will be addressed in a next series.
Cent
[1]: http://openamp.github.io/docs/mca/coprocessor-memory-definition-v6.pdf

---
Changes since V3:
- Rebase on top of Bjorn remoteproc next git (3d065621c921)
- Apply on top of "remoteproc: replace "%p" with "%pK"" [2]
- Lot of changes to centralize carveout allocation before rproc_start()
- Remove prepare/unprepare ops and rely on parse_fw instead of
- Add possibility to assign reserved memory region to vdev device
- Adapt TI da8xx and keystone remoteproc driver

As V3 series, V4 series takes some assumptions for carveout names
associated to vdev:
- For vring: "vdev%xvring%x" with vdev index from resource table and vring index
  in vdev.
- For vdev buffer: "vdev%xbuffer" with vdev index from resource table

[2] https://patchwork.kernel.org/patch/10511599

Changes since V2:
Reshuffle the series to: 
- Take into account Bjorn's comments.
- Add patch to check consistency between carveout resource request and IOMMU
  support.
- Introduce platform specific prepare and unprepare ops to enable HW like
  clock, bus, regulator, memory region... before loading co-processor firmware.
- Rely on memory carveout management for all remoteproc memory allocations.
- Lookup pre-registered carveout by name first.
- Create a subdevice for each vdev declared in firmware resource table that
  will be used by virtio based driver to retrieve specific memory pool.

This series takes some assumptions for carveout names associated to vdev:
- For vring: "vdev%xvring%x" with vdev index from resource table and vring index
  in vdev.
- For vdev buffer: "vdev%xbuffer" with vdev index from resource table

This will be changed in the future, adding names field in vdev resource in
next resource table version.


Changes since V1:
- Minor corrections on first 7 patches (error management)
- Add "memory device" support on the top of first 7 patches.
  Goal is to answer use case reported during OpenAMP weekly discussion:
  - "Be able to specify memory region for vring and buffer allocation, even
    if no specific request defined in firmware resource table."
  Patches offer the capability to create a "memory device" associated to a
  carveout with a dedicated DMA memory pool. Different resource handlers are
  modified to look-up for specific carveout by name. If match found and associated
  "memory device" present, device is used instead of rproc platform device for
  allocation.


Loic Pallardy (17):
  remoteproc: configure IOMMU only if device address requested
  remoteproc: add rproc_va_to_pa function
  remoteproc: add release ops in rproc_mem_entry struct
  remoteproc: add name in rproc_mem_entry struct
  remoteproc: add helper function to allocate and init rproc_mem_entry
    struct
  remoteproc: introduce rproc_add_carveout function
  remoteproc: introduce rproc_find_carveout_by_name function
  remoteproc: add alloc ops in rproc_mem_entry struct
  remoteproc: add helper function to allocate rproc_mem_entry from
    reserved memory
  remoteproc: add helper function to check carveout device address
  remoteproc: modify rproc_handle_carveout to support pre-registered
    region
  remoteproc: modify vring allocation to rely on centralized carveout
    allocator
  remoteproc: create vdev subdevice with specific dma memory pool
  remoteproc: keystone: declare reserved memory region for vdev device
  remoteproc: da8xx: declare reserved memory region for vdev device
  remoteproc: st: add reserved memory support
  rpmsg: virtio: allocate buffer from parent

 drivers/remoteproc/da8xx_remoteproc.c    |  38 ++
 drivers/remoteproc/keystone_remoteproc.c |  53 ++-
 drivers/remoteproc/remoteproc_core.c     | 572 +++++++++++++++++++++++++------
 drivers/remoteproc/remoteproc_debugfs.c  |   1 +
 drivers/remoteproc/remoteproc_internal.h |   3 +
 drivers/remoteproc/remoteproc_virtio.c   |  56 ++-
 drivers/remoteproc/st_remoteproc.c       |  96 +++++-
 drivers/rpmsg/virtio_rpmsg_bus.c         |   6 +-
 include/linux/remoteproc.h               |  35 +-
 9 files changed, 728 insertions(+), 132 deletions(-)

-- 
1.9.1

Comments

Anup Patel Sept. 21, 2018, 6:04 a.m. UTC | #1
Hi Loic/Bjorn,

Can we consider this series for v4.20?

I am interested in for patch "rpmsg: virtio: allocate buffer
from parent". This patch allows me to used VirtIO
RPMSG driver inside Guest/VM.

Regards,
Anup
Loic Pallardy Sept. 26, 2018, 4 p.m. UTC | #2
Hi Anup,

> -----Original Message-----

> From: Anup Patel <anup@brainfault.org>

> Sent: Friday, September 21, 2018 8:05 AM

> To: Loic PALLARDY <loic.pallardy@st.com>

> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>; Ohad Ben-Cohen

> <ohad@wizery.com>; linux-remoteproc@vger.kernel.org; linux-

> kernel@vger.kernel.org List <linux-kernel@vger.kernel.org>; Arnaud

> POULIQUEN <arnaud.pouliquen@st.com>; Benjamin Gaignard

> <benjamin.gaignard@linaro.org>; s-anna@ti.com

> Subject: Re: [PATCH v4 00/17] remoteproc: add fixed memory region support

> 

> Hi Loic/Bjorn,

> 

> Can we consider this series for v4.20?


I discussed with Bjorn last week at Linaro connect.
He should review the series hopefully soon.
> 

> I am interested in for patch "rpmsg: virtio: allocate buffer

> from parent". This patch allows me to used VirtIO

> RPMSG driver inside Guest/VM.

Please send your acked-by or reviewed-by or tested-by 
It will help Bjorn to see interest for this series

Regards,
Loic

> 

> Regards,

> Anup
Anup Patel Sept. 28, 2018, 7:54 a.m. UTC | #3
On Wed, Sep 26, 2018 at 9:31 PM Loic PALLARDY <loic.pallardy@st.com> wrote:
>

> Hi Anup,

>

> > -----Original Message-----

> > From: Anup Patel <anup@brainfault.org>

> > Sent: Friday, September 21, 2018 8:05 AM

> > To: Loic PALLARDY <loic.pallardy@st.com>

> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org>; Ohad Ben-Cohen

> > <ohad@wizery.com>; linux-remoteproc@vger.kernel.org; linux-

> > kernel@vger.kernel.org List <linux-kernel@vger.kernel.org>; Arnaud

> > POULIQUEN <arnaud.pouliquen@st.com>; Benjamin Gaignard

> > <benjamin.gaignard@linaro.org>; s-anna@ti.com

> > Subject: Re: [PATCH v4 00/17] remoteproc: add fixed memory region support

> >

> > Hi Loic/Bjorn,

> >

> > Can we consider this series for v4.20?

>

> I discussed with Bjorn last week at Linaro connect.

> He should review the series hopefully soon.

> >

> > I am interested in for patch "rpmsg: virtio: allocate buffer

> > from parent". This patch allows me to used VirtIO

> > RPMSG driver inside Guest/VM.

> Please send your acked-by or reviewed-by or tested-by

> It will help Bjorn to see interest for this series


Sure, I will provided Reviewed-by and Tested-by for
patch "rpmsg: virtio: allocate buffer from parent".

Thanks,
Anup
Suman Anna Oct. 23, 2018, 4:42 p.m. UTC | #4
Hi Bjorn,

On 7/27/18 8:14 AM, Loic Pallardy wrote:
> The aim of the series is to implement carveout memory management as

> discussed during OpenAMP weekly call and defined in proposed document [1]

> 

> This first series focus only on adding support of the different types of

> carveout memories (dynamic, fixed, platform driver depend...).

> 64bit resource table will be addressed in a next series.

> Cent

> [1]: http://openamp.github.io/docs/mca/coprocessor-memory-definition-v6.pdf


Some of the patches in this series are breaking TI platforms, and I have
found couple of generic bugs as well. You may want to reconsider some of
these patches for 4.20. Apologies for the late review, but please look
through the comments I will be posting on various patches through the
rest of the day.

regards
Suman

> 

> ---

> Changes since V3:

> - Rebase on top of Bjorn remoteproc next git (3d065621c921)

> - Apply on top of "remoteproc: replace "%p" with "%pK"" [2]

> - Lot of changes to centralize carveout allocation before rproc_start()

> - Remove prepare/unprepare ops and rely on parse_fw instead of

> - Add possibility to assign reserved memory region to vdev device

> - Adapt TI da8xx and keystone remoteproc driver

> 

> As V3 series, V4 series takes some assumptions for carveout names

> associated to vdev:

> - For vring: "vdev%xvring%x" with vdev index from resource table and vring index

>   in vdev.

> - For vdev buffer: "vdev%xbuffer" with vdev index from resource table

> 

> [2] https://patchwork.kernel.org/patch/10511599

> 

> Changes since V2:

> Reshuffle the series to: 

> - Take into account Bjorn's comments.

> - Add patch to check consistency between carveout resource request and IOMMU

>   support.

> - Introduce platform specific prepare and unprepare ops to enable HW like

>   clock, bus, regulator, memory region... before loading co-processor firmware.

> - Rely on memory carveout management for all remoteproc memory allocations.

> - Lookup pre-registered carveout by name first.

> - Create a subdevice for each vdev declared in firmware resource table that

>   will be used by virtio based driver to retrieve specific memory pool.

> 

> This series takes some assumptions for carveout names associated to vdev:

> - For vring: "vdev%xvring%x" with vdev index from resource table and vring index

>   in vdev.

> - For vdev buffer: "vdev%xbuffer" with vdev index from resource table

> 

> This will be changed in the future, adding names field in vdev resource in

> next resource table version.

> 

> 

> Changes since V1:

> - Minor corrections on first 7 patches (error management)

> - Add "memory device" support on the top of first 7 patches.

>   Goal is to answer use case reported during OpenAMP weekly discussion:

>   - "Be able to specify memory region for vring and buffer allocation, even

>     if no specific request defined in firmware resource table."

>   Patches offer the capability to create a "memory device" associated to a

>   carveout with a dedicated DMA memory pool. Different resource handlers are

>   modified to look-up for specific carveout by name. If match found and associated

>   "memory device" present, device is used instead of rproc platform device for

>   allocation.

> 

> 

> Loic Pallardy (17):

>   remoteproc: configure IOMMU only if device address requested

>   remoteproc: add rproc_va_to_pa function

>   remoteproc: add release ops in rproc_mem_entry struct

>   remoteproc: add name in rproc_mem_entry struct

>   remoteproc: add helper function to allocate and init rproc_mem_entry

>     struct

>   remoteproc: introduce rproc_add_carveout function

>   remoteproc: introduce rproc_find_carveout_by_name function

>   remoteproc: add alloc ops in rproc_mem_entry struct

>   remoteproc: add helper function to allocate rproc_mem_entry from

>     reserved memory

>   remoteproc: add helper function to check carveout device address

>   remoteproc: modify rproc_handle_carveout to support pre-registered

>     region

>   remoteproc: modify vring allocation to rely on centralized carveout

>     allocator

>   remoteproc: create vdev subdevice with specific dma memory pool

>   remoteproc: keystone: declare reserved memory region for vdev device

>   remoteproc: da8xx: declare reserved memory region for vdev device

>   remoteproc: st: add reserved memory support

>   rpmsg: virtio: allocate buffer from parent

> 

>  drivers/remoteproc/da8xx_remoteproc.c    |  38 ++

>  drivers/remoteproc/keystone_remoteproc.c |  53 ++-

>  drivers/remoteproc/remoteproc_core.c     | 572 +++++++++++++++++++++++++------

>  drivers/remoteproc/remoteproc_debugfs.c  |   1 +

>  drivers/remoteproc/remoteproc_internal.h |   3 +

>  drivers/remoteproc/remoteproc_virtio.c   |  56 ++-

>  drivers/remoteproc/st_remoteproc.c       |  96 +++++-

>  drivers/rpmsg/virtio_rpmsg_bus.c         |   6 +-

>  include/linux/remoteproc.h               |  35 +-

>  9 files changed, 728 insertions(+), 132 deletions(-)

>