From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud Pouliquen <arnaud.pouliquen@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,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [RFC 00/18] remoteproc: Decorelate virtio from core
Date: Thu, 23 Apr 2020 11:26:26 -0600 [thread overview]
Message-ID: <20200423172626.GA5781@xps15> (raw)
In-Reply-To: <20200416161331.7606-1-arnaud.pouliquen@st.com>
On Thu, Apr 16, 2020 at 06:13:13PM +0200, Arnaud Pouliquen wrote:
> This series proposes to introduce the notion of platform device for the
> rproc virtio management. One obective is to allow virtio to declare is
> own memory resources without the usage of dma_declare_coherent_memory
> that seems deprecated since the introduction of the device tree.
Just to follow up with the rest of the community...
During the openAMP remoteproc sub-group conference call [1] Arnaud and I have agreed
the best way forward for this patchset is to split it up and make a few
adjustment that will make it easier for people to review the work.
Thanks,
Mathieu
[1]. These conference call are open to anyone who wishes to participate.
>
> Proposal:
> - the rproc virtio is processed in a separate platform and could be handled
> as a generic platform device.
> - Several vdev devices can be declared in DT:
> - which allows to declare their own memory regions and answer to [1].
> - as next steps it would be also possible to:
> - declare their own mailboxes, rpmsg drivers, ...
> - use dma-range to handle the pa<->da translation at virtio level
>
> Several notions are introduced here:
> - Virtio platform registration which allows to decorelate virtio from the
> remote proc core device.
> - Synchronization of the child devices relying on component bind/unbind.
> This mechanism ensures the synchronization of the child devices before
> the boot of the remote processor and before the release of the resources
> on the remote processor shutdown.
> - Ability to populate child devices declared in rproc device tree node.
> - Possibility to declare the memory regions reserved to a virtio devices in
> the devicetree.
>
> Known limitations:
> - the patchset has been tested on a st32mP1 plaform only
> - it is based on the v5.6 (need to evoluate depending on V5.7 and on going
> patchsets).
> - The virtio memory allocation does not take into account memory
> controllers such as IOMMU and MPU.
>
> Arnaud Pouliquen (18):
> remoteproc: Store resource table address in rvdev
> remoteproc: Introduce virtio device add/remove functions in core.
> remoteproc: Move rvdev management in rproc_virtio
> remoteproc: Add rproc_get_by_node helper
> remoteproc: Create platform device for vdev
> remoteproc: Add component in core for child devices synchronization
> remoteproc: Add component bind/unbind for virtio platform
> remoteproc: Externalize carveout functions
> remoteproc: Move vring management from core to virtio
> remoteproc: Add capability to populate rproc subnode devices
> remoteproc: Add child node component in rproc match list
> remoteproc: Support of pre-registered virtio device
> remoteproc: Add memory default allocator helper
> remoteproc: Add pa to da translation API
> remoteproc: associate memory entry to a device
> remoteproc: Parse virtio node for memory region
> remoteproc: stm32: add the pa to da ops.
> ARM: dts: stm32: Declare a virtio device
>
> arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 10 +
> drivers/remoteproc/remoteproc_core.c | 469 ++++++++++++-----------
> drivers/remoteproc/remoteproc_internal.h | 23 +-
> drivers/remoteproc/remoteproc_virtio.c | 415 ++++++++++++++++++--
> drivers/remoteproc/stm32_rproc.c | 1 +
> include/linux/remoteproc.h | 27 +-
> 6 files changed, 673 insertions(+), 272 deletions(-)
>
> --
> 2.17.1
>
prev parent reply other threads:[~2020-04-23 17:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 16:13 [RFC 00/18] remoteproc: Decorelate virtio from core Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 01/18] remoteproc: Store resource table address in rvdev Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 02/18] remoteproc: Introduce virtio device add/remove functions in core Arnaud Pouliquen
2020-04-21 20:41 ` Mathieu Poirier
2020-04-22 12:30 ` Arnaud POULIQUEN
2020-04-22 16:57 ` Mathieu Poirier
2020-04-16 16:13 ` [RFC 03/18] remoteproc: Move rvdev management in rproc_virtio Arnaud Pouliquen
2020-04-21 22:18 ` Mathieu Poirier
2020-04-22 17:26 ` Mathieu Poirier
2020-04-16 16:13 ` [RFC 04/18] remoteproc: Add rproc_get_by_node helper Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 05/18] remoteproc: Create platform device for vdev Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 06/18] remoteproc: Add component in core for child devices synchronization Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 07/18] remoteproc: Add component bind/unbind for virtio platform Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 08/18] remoteproc: Externalize carveout functions Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 09/18] remoteproc: Move vring management from core to virtio Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 10/18] remoteproc: Add capability to populate rproc subnode devices Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 11/18] remoteproc: Add child node component in rproc match list Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 12/18] remoteproc: Support of pre-registered virtio device Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 13/18] remoteproc: Add memory default allocator helper Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 14/18] remoteproc: Add pa to da translation API Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 15/18] remoteproc: associate memory entry to a device Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 16/18] remoteproc: Parse virtio node for memory region Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 17/18] remoteproc: stm32: Add the pa to da ops Arnaud Pouliquen
2020-04-16 16:13 ` [RFC 18/18] ARM: dts: stm32: Declare a virtio device Arnaud Pouliquen
2020-04-23 17:26 ` Mathieu Poirier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200423172626.GA5781@xps15 \
--to=mathieu.poirier@linaro.org \
--cc=arnaud.pouliquen@st.com \
--cc=bjorn.andersson@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=ohad@wizery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox