search for: rpmsg_ns_flags

...riate rpmsg driver will be invoked > > - * (if/as-soon-as one is registered). > > - */ > > -struct rpmsg_ns_msg { > > - char name[RPMSG_NAME_SIZE]; > > - __virtio32 addr; > > - __virtio32 flags; > > -} __packed; > > - > > -/** > > - * enum rpmsg_ns_flags - dynamic name service announcement flags > > - * > > - * @RPMSG_NS_CREATE: a new remote service was just created > > - * @RPMSG_NS_DESTROY: a known remote service was just destroyed > > - */ > > -enum rpmsg_ns_flags { > > - RPMSG_NS_CREATE = 0, > > - RPMS...

...gt; > > - */ > > > > -struct rpmsg_ns_msg { > > > > - char name[RPMSG_NAME_SIZE]; > > > > - __virtio32 addr; > > > > - __virtio32 flags; > > > > -} __packed; > > > > - > > > > -/** > > > > - * enum rpmsg_ns_flags - dynamic name service announcement flags > > > > - * > > > > - * @RPMSG_NS_CREATE: a new remote service was just created > > > > - * @RPMSG_NS_DESTROY: a known remote service was just destroyed > > > > - */ > > > > -enum rpmsg_ns_flags {...

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

...520994 + +} __packed; +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + +/** +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + + * enum rpmsg_ns_flags - dynamic name service announcement flags +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + + * +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + + * @RPMSG_NS_CREATE: a new remote service was just created +\end_layout + +\...

...520994 + +} __packed; +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + +/** +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + + * enum rpmsg_ns_flags - dynamic name service announcement flags +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + + * +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1096565211 1333520994 + + * @RPMSG_NS_CREATE: a new remote service was just created +\end_layout + +\...

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

...e changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/virtio_rpmsg.h b/include/linux/virtio_rpmsg.h > > index 679be8b..1add468 100644 > > --- a/include/linux/virtio_rpmsg.h > > +++ b/include/linux/virtio_rpmsg.h > > @@ -72,8 +72,8 @@ enum rpmsg_ns_flags { > > * can change this without changing anything in the firmware of the remote > > * processor. > > */ > > -#define MAX_RPMSG_NUM_BUFS 512 > > -#define MAX_RPMSG_BUF_SIZE 512 > > +#define MAX_RPMSG_NUM_BUFS (512 / 32) > > +#define MAX_RPMSG_BUF_SIZE...

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.

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, 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 -

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 -

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:

This patch set is a follow up to "Add a vhost RPMsg API" [1], it is marked as an RFC because firstly it depends on the RPMsg API series and secondly it is currently being reviewed on ALSA and SOF mailing lists, but any early comments from virtualisation developers would be highly appreciated too! Thanks Guennadi [1]

This patch set is a follow up to "Add a vhost RPMsg API" [1], it is marked as an RFC because firstly it depends on the RPMsg API series and secondly it is currently being reviewed on ALSA and SOF mailing lists, but any early comments from virtualisation developers would be highly appreciated too! Thanks Guennadi [1]