similar to: [PATCH] virtio_rpmsg: set DRIVER_OK before using device

"Michael S. Tsirkin" <mst at redhat.com> writes: > virtio spec requires that all drivers set DRIVER_OK > before using devices. While rpmsg isn't yet > included in the virtio 1 spec, previous spec versions > also required this. > > virtio rpmsg violates this rule: is calls kick > before setting DRIVER_OK. > > The fix isn't trivial since simply

On Sat, Mar 07, 2015 at 08:06:56PM +0100, Michael S. Tsirkin wrote: > virtio spec requires that all drivers set DRIVER_OK > before using devices. While rpmsg isn't yet > included in the virtio 1 spec, previous spec versions > also required this. > > virtio rpmsg violates this rule: is calls kick > before setting DRIVER_OK. > > The fix isn't trivial since simply

"Michael S. Tsirkin" <mst at redhat.com> writes: > virtio spec requires that all drivers set DRIVER_OK > before using devices. While rpmsg isn't yet > included in the virtio 1 spec, previous spec versions > also required this. > > virtio rpmsg violates this rule: is calls kick > before setting DRIVER_OK. > > The fix isn't trivial since simply

On Sat, Mar 07, 2015 at 08:06:56PM +0100, Michael S. Tsirkin wrote: > virtio spec requires that all drivers set DRIVER_OK > before using devices. While rpmsg isn't yet > included in the virtio 1 spec, previous spec versions > also required this. > > virtio rpmsg violates this rule: is calls kick > before setting DRIVER_OK. > > The fix isn't trivial since simply

"Edgar E. Iglesias" <edgar.iglesias at gmail.com> writes: > From: "Edgar E. Iglesias" <edgar.iglesias at xilinx.com> > > Signed-off-by: Edgar E. Iglesias <edgar.iglesias at xilinx.com> First off, I have handed maintainership off to Michael S. Tsirkin, so his word is now law. That said... there's nothing fundamentally *wrong* with this, but

"Edgar E. Iglesias" <edgar.iglesias at gmail.com> writes: > From: "Edgar E. Iglesias" <edgar.iglesias at xilinx.com> > > Signed-off-by: Edgar E. Iglesias <edgar.iglesias at xilinx.com> First off, I have handed maintainership off to Michael S. Tsirkin, so his word is now law. That said... there's nothing fundamentally *wrong* with this, but

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

checkpatch.pl wants arrays of strings declared as follows: static const char * const names[] = { "vq-1", "vq-2", "vq-3" }; Currently the find_vqs() function takes a const char *names[] argument so passing checkpatch.pl's const char * const names[] results in a compiler error due to losing the second const. This patch adjusts the find_vqs() prototype and

checkpatch.pl wants arrays of strings declared as follows: static const char * const names[] = { "vq-1", "vq-2", "vq-3" }; Currently the find_vqs() function takes a const char *names[] argument so passing checkpatch.pl's const char * const names[] results in a compiler error due to losing the second const. This patch adjusts the find_vqs() prototype and

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

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

We are going to add more parameters to find_vqs, let's wrap the call so we don't need to tweak all drivers every time. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 3 +-- drivers/char/virtio_console.c | 6 +++--- drivers/crypto/virtio/virtio_crypto_core.c | 3 +-- drivers/gpu/drm/virtio/virtgpu_kms.c | 3

We are going to add more parameters to find_vqs, let's wrap the call so we don't need to tweak all drivers every time. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 3 +-- drivers/char/virtio_console.c | 6 +++--- drivers/crypto/virtio/virtio_crypto_core.c | 3 +-- drivers/gpu/drm/virtio/virtgpu_kms.c | 3

On Mon, Mar 9, 2015 at 10:41 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Sat, Mar 07, 2015 at 08:06:56PM +0100, Michael S. Tsirkin wrote: >> virtio spec requires that all drivers set DRIVER_OK >> before using devices. While rpmsg isn't yet >> included in the virtio 1 spec, previous spec versions >> also required this. >> >> virtio rpmsg

On Mon, Mar 9, 2015 at 10:41 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Sat, Mar 07, 2015 at 08:06:56PM +0100, Michael S. Tsirkin wrote: >> virtio spec requires that all drivers set DRIVER_OK >> before using devices. While rpmsg isn't yet >> included in the virtio 1 spec, previous spec versions >> also required this. >> >> virtio rpmsg