public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: ohad@wizery.com, bjorn.andersson@linaro.org,
	arnaud.pouliquen@st.com, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jason Wang <jasowang@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [PATCH v7 0/8] rpmsg: Make RPMSG name service modular
Date: Thu, 3 Dec 2020 21:42:18 +0100	[thread overview]
Message-ID: <20201203204218.GA13001@ubuntu> (raw)
In-Reply-To: <20201202203954.GC1282360@xps15>

(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?
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@linux.intel.com>
> > > Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.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
> > > > 

  reply	other threads:[~2020-12-03 20:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 21:42 [PATCH v7 0/8] rpmsg: Make RPMSG name service modular Mathieu Poirier
2020-11-20 21:42 ` [PATCH v7 1/8] rpmsg: Introduce __rpmsg{16|32|64} types Mathieu Poirier
2020-11-20 21:42 ` [PATCH v7 2/8] rpmsg: virtio: Move from virtio to rpmsg byte conversion Mathieu Poirier
2020-11-20 21:42 ` [PATCH v7 3/8] rpmsg: Move structure rpmsg_ns_msg to header file Mathieu Poirier
2020-11-20 21:42 ` [PATCH v7 4/8] rpmsg: virtio: Rename rpmsg_create_channel Mathieu Poirier
2020-11-20 21:42 ` [PATCH v7 5/8] rpmsg: core: Add channel creation internal API Mathieu Poirier
2020-11-20 21:42 ` [PATCH v7 6/8] rpmsg: virtio: Add rpmsg channel device ops Mathieu Poirier
2020-11-20 21:42 ` [PATCH v7 7/8] rpmsg: Make rpmsg_{register|unregister}_device() public Mathieu Poirier
2020-11-20 21:42 ` [PATCH v7 8/8] rpmsg: Turn name service into a stand alone driver Mathieu Poirier
2020-11-23 16:06 ` [PATCH v7 0/8] rpmsg: Make RPMSG name service modular Guennadi Liakhovetski
2020-12-02 11:05   ` Guennadi Liakhovetski
2020-12-02 20:39     ` Mathieu Poirier
2020-12-03 20:42       ` Guennadi Liakhovetski [this message]
2020-12-04 17:51         ` Mathieu Poirier
2020-12-07 15:35           ` Kishon Vijay Abraham I

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=20201203204218.GA13001@ubuntu \
    --to=guennadi.liakhovetski@linux.intel.com \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=jasowang@redhat.com \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mst@redhat.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