search for: rpdev

...nd rpmsg_endpoint_ops. Then with the following patches and no other vhost-specific API use, I was able to load and use the same rpmsg-char and rpmsg-client-sample drivers on both host and guest kernels. Userspace sets up the vhost using vhost-rpmsg-bus' misc device and triggers creation of an rpdev which leads to a probe of the (for example) rpmsg-client-sample driver on the host (server), which, in turn, via NS announcement, triggers a creation of an rpdev and a probe of the rpmsg-client-sample driver on the guest (client). diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char....

...nd rpmsg_endpoint_ops. Then with the following patches and no other vhost-specific API use, I was able to load and use the same rpmsg-char and rpmsg-client-sample drivers on both host and guest kernels. Userspace sets up the vhost using vhost-rpmsg-bus' misc device and triggers creation of an rpdev which leads to a probe of the (for example) rpmsg-client-sample driver on the host (server), which, in turn, via NS announcement, triggers a creation of an rpdev and a probe of the rpmsg-client-sample driver on the guest (client). diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char....

...ith the following > patches and no other vhost-specific API use, I was able to load and use > the same rpmsg-char and rpmsg-client-sample drivers on both host and > guest kernels. > > Userspace sets up the vhost using vhost-rpmsg-bus' misc device and > triggers creation of an rpdev which leads to a probe of the (for > example) rpmsg-client-sample driver on the host (server), which, in > turn, via NS announcement, triggers a creation of an rpdev and a probe > of the rpmsg-client-sample driver on the guest (client). > > diff --git a/drivers/rpmsg/rpmsg_char.c b/...

On Wed, May 27, 2020 at 08:05:41PM +0200, Guennadi Liakhovetski wrote: > Linux supports running the RPMsg protocol over the VirtIO transport > protocol, but currently there is only support for VirtIO clients and > no support for a VirtIO server. This patch adds a vhost-based RPMsg > server implementation. This looks really useful, but why is it implemented as an API and not as a real

On Wed, May 27, 2020 at 08:05:41PM +0200, Guennadi Liakhovetski wrote: > Linux supports running the RPMsg protocol over the VirtIO transport > protocol, but currently there is only support for VirtIO clients and > no support for a VirtIO server. This patch adds a vhost-based RPMsg > server implementation. This looks really useful, but why is it implemented as an API and not as a real

...t_table(sg, 1); > + sg_dma_address(sg) = msg_dma_address(vrp, msg); > + sg_dma_len(sg) = len; > +} > + > /* for more info, see below documentation of rpmsg_create_ept() */ > static struct rpmsg_endpoint *__rpmsg_create_ept(struct virtproc_info *vrp, > struct rpmsg_channel *rpdev, rpmsg_rx_cb_t cb, > @@ -754,12 +770,12 @@ int rpmsg_send_offchannel_raw(struct rpmsg_channel *rpdev, u32 src, u32 dst, > print_hex_dump(KERN_DEBUG, "rpmsg_virtio TX: ", DUMP_PREFIX_NONE, 16, 1, > msg, sizeof(*msg) + msg->len, true); > > - sg_init_one(&sg,...

...t_table(sg, 1); > + sg_dma_address(sg) = msg_dma_address(vrp, msg); > + sg_dma_len(sg) = len; > +} > + > /* for more info, see below documentation of rpmsg_create_ept() */ > static struct rpmsg_endpoint *__rpmsg_create_ept(struct virtproc_info *vrp, > struct rpmsg_channel *rpdev, rpmsg_rx_cb_t cb, > @@ -754,12 +770,12 @@ int rpmsg_send_offchannel_raw(struct rpmsg_channel *rpdev, u32 src, u32 dst, > print_hex_dump(KERN_DEBUG, "rpmsg_virtio TX: ", DUMP_PREFIX_NONE, 16, 1, > msg, sizeof(*msg) + msg->len, true); > > - sg_init_one(&sg,...

...*msg, unsigned int len) +{ + sg_init_table(sg, 1); + sg_dma_address(sg) = msg_dma_address(vrp, msg); + sg_dma_len(sg) = len; +} + /* for more info, see below documentation of rpmsg_create_ept() */ static struct rpmsg_endpoint *__rpmsg_create_ept(struct virtproc_info *vrp, struct rpmsg_channel *rpdev, rpmsg_rx_cb_t cb, @@ -754,12 +770,12 @@ int rpmsg_send_offchannel_raw(struct rpmsg_channel *rpdev, u32 src, u32 dst, print_hex_dump(KERN_DEBUG, "rpmsg_virtio TX: ", DUMP_PREFIX_NONE, 16, 1, msg, sizeof(*msg) + msg->len, true); - sg_init_one(&sg, msg, sizeof(*msg) + len);...

...b232a 100644 > > --- a/Documentation/rpmsg.txt > > +++ b/Documentation/rpmsg.txt > > @@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value on failure. > > > > :: > > > > - struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev, > > - void (*cb)(struct rpmsg_channel *, void *, int, void *, u32), > > - void *priv, u32 addr); > > + struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev, > > + rpmsg_rx_cb_t cb, void *priv, > > + struct rpmsg_channel_info chinfo); >...

From: "Edgar E. Iglesias" <edgar.iglesias at xilinx.com> I'm trying to run rpmsg and remoteproc on the ZynqMP (arm64) but I'm hitting a DMA/mm error. The issue was discussed here: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333050.html Russel King pointed out that the arm64 is not doing anything wrong by returning vmapped memory (which is incompatible

From: "Edgar E. Iglesias" <edgar.iglesias at xilinx.com> I'm trying to run rpmsg and remoteproc on the ZynqMP (arm64) but I'm hitting a DMA/mm error. The issue was discussed here: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333050.html Russel King pointed out that the arm64 is not doing anything wrong by returning vmapped memory (which is incompatible

...address(sg) = msg_dma_address(vrp, msg); > > + sg_dma_len(sg) = len; > > +} > > + > > /* for more info, see below documentation of rpmsg_create_ept() */ > > static struct rpmsg_endpoint *__rpmsg_create_ept(struct virtproc_info *vrp, > > struct rpmsg_channel *rpdev, rpmsg_rx_cb_t cb, > > @@ -754,12 +770,12 @@ int rpmsg_send_offchannel_raw(struct rpmsg_channel *rpdev, u32 src, u32 dst, > > print_hex_dump(KERN_DEBUG, "rpmsg_virtio TX: ", DUMP_PREFIX_NONE, 16, 1, > > msg, sizeof(*msg) + msg->len, true); > > > &gt...

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]

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

RPMsg uses dma_alloc_coherent() to allocate memory to shared with the remote. In this case, as there is no pages setup in the dma_alloc_coherent(), we cannot get the physical address back from the virtual address, and thus, we can set the sg_dma_addr to store the DMA address and mark it already DMA mapped. When virtio vring sees the sg_dma_addr is ready set, do not call dma_map_page(). The issue

RPMsg uses dma_alloc_coherent() to allocate memory to shared with the remote. In this case, as there is no pages setup in the dma_alloc_coherent(), we cannot get the physical address back from the virtual address, and thus, we can set the sg_dma_addr to store the DMA address and mark it already DMA mapped. When virtio vring sees the sg_dma_addr is ready set, do not call dma_map_page(). The issue

RPMsg uses dma_alloc_coherent() to allocate memory to shared with the remote. In this case, as there is no pages setup in the dma_alloc_coherent(), we cannot get the physical address back from the virtual address, and thus, we can set the sg_dma_addr to store the DMA address and mark it already DMA mapped. When virtio vring sees the sg_dma_addr is ready set, do not call dma_map_page(). The issue

RPMsg uses dma_alloc_coherent() to allocate memory to shared with the remote. In this case, as there is no pages setup in the dma_alloc_coherent(), we cannot get the physical address back from the virtual address, and thus, we can set the sg_dma_addr to store the DMA address and mark it already DMA mapped. When virtio vring sees the sg_dma_addr is ready set, do not call dma_map_page(). The issue