Message-ID: <CANLsYkzDiWtyNvYm8a_MBgz=cryb2mNNUwVA9=K2yrO3XTa-xA@mail.gmail.com>
Date:   Fri, 4 Dec 2020 10:51:49 -0700
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Guennadi Liakhovetski <guennadi.liakhovetski@...ux.intel.com>
Cc:     Kishon Vijay Abraham I <kishon@...com>,
        Ohad Ben-Cohen <ohad@...ery.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Arnaud POULIQUEN <arnaud.pouliquen@...com>,
        linux-remoteproc <linux-remoteproc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jason Wang <jasowang@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Vincent Whitchurch <vincent.whitchurch@...s.com>,
        virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v7 0/8] rpmsg: Make RPMSG name service modular

I am adding Vincent Whitchurch and the virtualization mailing list...

On Thu, 3 Dec 2020 at 13:42, Guennadi Liakhovetski
<guennadi.liakhovetski@...ux.intel.com> wrote:
>
> (adding vhost maintainers and the author of [1])
>
> Hi,
>
> I'm working on an Audio DSP virtualisation solution [2] and the next
> step in its upstreaming should be an RPMsg vhost implementation, based
> on [3], which contains a simple addition to the current library-style
> vhost API. Later in [1] a different approach has been presented,
> converting the vhost framework to a proper bus-type and device driver.
> Therefore my questions:
>
> 1. if the latter approach is prefered, should we expect follow up
> versions of [1] and their upstreaming?
> 2. judging by the size and complexity of [1] would it maybe be
> preferable to first extract a minimum patch set just to add vhost
> rpmsg? Looking at the patch set it should be doable and not too
> difficult? Kishon, would it be something you could submit?

To me that is the best approach.  It might be best for you to do the
work and credit Kishon where needed.

> 3. or would it be preferable to keep vhost in its present form, use
> [3] for rpmsg support and re-implement [1] based on a different
> vhost / vringh approach?
>
> Thanks
> Guennadi
>
> [1] https://www.spinics.net/lists/kvm/msg219632.html
> [2] https://mailman.alsa-project.org/pipermail/sound-open-firmware/2020-April/003766.html
> [3] https://www.spinics.net/lists/linux-virtualization/msg43359.html
>
> On Wed, Dec 02, 2020 at 01:39:54PM -0700, Mathieu Poirier wrote:
> > Good day,
> >
> > On Wed, Dec 02, 2020 at 12:05:55PM +0100, Guennadi Liakhovetski wrote:
> > > Hi Mathieu,
> > >
> > > I'd like to resume reviewing and begin upstreaming of the next steps of
> > > my Audio DSP Virtualisation work, based on this your patch set. How
> >
> > I'm all for it too.
> >
> > > confident are we that it's going to be upstreamed in its present form?
> > > What's the plan to push it to "next?"
> > >
> >
> > I thought we were pretty unanimous that something like what Kishon did was the
> > way to go.
> >
> > > Thanks
> > > Guennadi
> > >
> > > On Mon, Nov 23, 2020 at 05:06:10PM +0100, Guennadi Liakhovetski wrote:
> > > > Hi Mathieu,
> > > >
> > > > Thanks for bringing all the stuff together and for polishing it!
> > > >
> > > > For the entire series:
> > > >
> > > > Tested-by: Guennadi Liakhovetski <guennadi.liakhovetski@...ux.intel.com>
> > > > Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@...ux.intel.com>
> > > >
> > > > Thanks
> > > > Guennadi
> > > >
> > > > On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote:
> > > > > This revision addresses comments received from the previous revision,
> > > > > i.e V6.  Please see details below.
> > > > >
> > > > > It starts by making the RPMSG protocol transport agnostic by
> > > > > moving the headers it uses to generic types and using those in the
> > > > > current implementation.  From there it re-uses the work that Arnaud
> > > > > published[1] to make the name service modular.
> > > > >
> > > > > Tested on stm32mp157 with the RPMSG client sample application.  Applies
> > > > > cleanly on rpmsg-next.
> > > > >
> > > > > Thanks,
> > > > > Mathieu
> > > > >
> > > > > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335
> > > > >
> > > > > -------
> > > > > New for V7:
> > > > > - Fixed error path in rpmsg_probe() as reported by Guennadi
> > > > >
> > > > > Arnaud Pouliquen (4):
> > > > >   rpmsg: virtio: Rename rpmsg_create_channel
> > > > >   rpmsg: core: Add channel creation internal API
> > > > >   rpmsg: virtio: Add rpmsg channel device ops
> > > > >   rpmsg: Turn name service into a stand alone driver
> > > > >
> > > > > Mathieu Poirier (4):
> > > > >   rpmsg: Introduce __rpmsg{16|32|64} types
> > > > >   rpmsg: virtio: Move from virtio to rpmsg byte conversion
> > > > >   rpmsg: Move structure rpmsg_ns_msg to header file
> > > > >   rpmsg: Make rpmsg_{register|unregister}_device() public
> > > > >
> > > > >  drivers/rpmsg/Kconfig            |   9 ++
> > > > >  drivers/rpmsg/Makefile           |   1 +
> > > > >  drivers/rpmsg/rpmsg_core.c       |  44 ++++++++
> > > > >  drivers/rpmsg/rpmsg_internal.h   |  14 ++-
> > > > >  drivers/rpmsg/rpmsg_ns.c         | 126 +++++++++++++++++++++
> > > > >  drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++--------------------
> > > > >  include/linux/rpmsg.h            |  63 ++++++++++-
> > > > >  include/linux/rpmsg/byteorder.h  |  67 +++++++++++
> > > > >  include/linux/rpmsg/ns.h         |  45 ++++++++
> > > > >  include/uapi/linux/rpmsg_types.h |  11 ++
> > > > >  10 files changed, 439 insertions(+), 127 deletions(-)
> > > > >  create mode 100644 drivers/rpmsg/rpmsg_ns.c
> > > > >  create mode 100644 include/linux/rpmsg/byteorder.h
> > > > >  create mode 100644 include/linux/rpmsg/ns.h
> > > > >  create mode 100644 include/uapi/linux/rpmsg_types.h
> > > > >
> > > > > --
> > > > > 2.25.1
> > > > >

Powered by blists - more mailing lists