search for: virtio_rpmsg_f_ns

...nclude <uapi/linux/rpmsg.h> > > > > #include "rpmsg_internal.h" > > > > @@ -70,58 +72,6 @@ struct virtproc_info { > > struct rpmsg_endpoint *ns_ept; > > }; > > > > -/* The feature bitmap for virtio rpmsg */ > > -#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */ > > - > > -/** > > - * struct rpmsg_hdr - common header for all rpmsg messages > > - * @src: source address > > - * @dst: destination address > > - * @reserved: reserved for future use > > - * @len: length of p...

...t;rpmsg_internal.h" > > > > > > > > @@ -70,58 +72,6 @@ struct virtproc_info { > > > > struct rpmsg_endpoint *ns_ept; > > > > }; > > > > > > > > -/* The feature bitmap for virtio rpmsg */ > > > > -#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */ > > > > - > > > > -/** > > > > - * struct rpmsg_hdr - common header for all rpmsg messages > > > > - * @src: source address > > > > - * @dst: destination address > > > > - * @reser...

Hi, Next update: v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different

Hi, Next update: v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different

On 18/09/2015 18:29, Claudio Fontana wrote: > > this is a first RFC for virtio-peer 0.1, which is still very much a work in progress: > > https://github.com/hw-claudio/virtio-peer/wiki > > It is also available as PDF there, but the text is reproduced here for commenting: > > Peer shared memory communication device (virtio-peer) Apart from the windows idea, how does

On 18/09/2015 18:29, Claudio Fontana wrote: > > this is a first RFC for virtio-peer 0.1, which is still very much a work in progress: > > https://github.com/hw-claudio/virtio-peer/wiki > > It is also available as PDF there, but the text is reproduced here for commenting: > > Peer shared memory communication device (virtio-peer) Apart from the windows idea, how does

...-1096565211 1333519647 +Virtqueues 0:receiveq. + 1:transmitq. +\end_layout + +\begin_layout Description + +\change_inserted -1096565211 1333519460 +Feature +\begin_inset space ~ +\end_inset + +bits +\end_layout + +\begin_deeper +\begin_layout Description + +\change_inserted -1096565211 1333520994 +VIRTIO_RPMSG_F_NS +\begin_inset space ~ +\end_inset + +(0) Device sends (and capable of receiving) name service messages announcing + the creation (or destruction) of a channel: +\begin_inset listings +inline false +status open + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + +/** +\end_lay...

...-1096565211 1333519647 +Virtqueues 0:receiveq. + 1:transmitq. +\end_layout + +\begin_layout Description + +\change_inserted -1096565211 1333519460 +Feature +\begin_inset space ~ +\end_inset + +bits +\end_layout + +\begin_deeper +\begin_layout Description + +\change_inserted -1096565211 1333520994 +VIRTIO_RPMSG_F_NS +\begin_inset space ~ +\end_inset + +(0) Device sends (and capable of receiving) name service messages announcing + the creation (or destruction) of a channel: +\begin_inset listings +inline false +status open + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + +/** +\end_lay...

Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development,

Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development,

v2: - remove "default n" from Kconfig - drop patch #6 - it depends on a different patch, that is currently an RFC - update patch #5 with a correct vhost_dev_init() prototype Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This

v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart: * remove "default n" from Kconfig Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases.

v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart: * remove "default n" from Kconfig Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases.

...re > referring to? Ok, we're both right: it goes both ways. Here's my understanding of the control flow of virtio_rpmsg_bus.c: 1. The driver registers a VirtIO driver with the VIRTIO_ID_RPMSG ID. 2. When the driver is probed, if the server / the application processor supports the VIRTIO_RPMSG_F_NS feature, the driver calls __rpmsg_create_ept() to create an endpoint with rpmsg_ns_cb() as a callback. 3. When a namespace announcement arrives from the server, the callback is called, which then registers a new channel (in case of CREATE). That then created an rpmsg device. 4. If there&...

...linux/vhost.h> +#include <linux/virtio_rpmsg.h> +#include <uapi/linux/rpmsg.h> + +#include <sound/sof/stream.h> +#include <sound/sof/rpmsg.h> + +#include "vhost.h" +#include "vhost_rpmsg.h" + +#define VHOST_DSP_FEATURES (VHOST_FEATURES | (1ULL << VIRTIO_RPMSG_F_NS)) + +struct snd_sof_dev; +struct sof_vhost_client; + +struct vhost_dsp { + struct vhost_rpmsg vrdev; + + struct sof_vhost_client *snd; + + bool active; + + /* RPMsg address of the position update endpoint */ + u32 posn_addr; + /* position update buffer and work */ + struct vhost_work posn_work; + s...

Hi, Next update: v7: - remove documentation update to be send separately - address comments from Mathieu Poirier (thanks) v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2:

Hi, Next update: v7: - remove documentation update to be send separately - address comments from Mathieu Poirier (thanks) v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2:

Hi, Next update: v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart:

Hi, Next update: v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart:

Hi, Now that virtio-rpmsg endianness fixes have been merged we can proceed with the next step. v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC -