search for: vrp

....c > index 73354ee..9ae53a0 100644 > --- a/drivers/rpmsg/virtio_rpmsg_bus.c > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c > @@ -210,6 +210,22 @@ static void __ept_release(struct kref *kref) > kfree(ept); > } > > +static inline dma_addr_t msg_dma_address(struct virtproc_info *vrp, void *msg) > +{ > + unsigned long offset = msg - vrp->rbufs; > + > + return vrp->bufs_dma + offset; > +} > + > +static inline void rpmsg_msg_sg_init(struct virtproc_info *vrp, > + struct scatterlist *sg, > + void *msg, unsigned int len) > +{ >...

....c > index 73354ee..9ae53a0 100644 > --- a/drivers/rpmsg/virtio_rpmsg_bus.c > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c > @@ -210,6 +210,22 @@ static void __ept_release(struct kref *kref) > kfree(ept); > } > > +static inline dma_addr_t msg_dma_address(struct virtproc_info *vrp, void *msg) > +{ > + unsigned long offset = msg - vrp->rbufs; > + > + return vrp->bufs_dma + offset; > +} > + > +static inline void rpmsg_msg_sg_init(struct virtproc_info *vrp, > + struct scatterlist *sg, > + void *msg, unsigned int len) > +{ >...

...g_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c index 73354ee..9ae53a0 100644 --- a/drivers/rpmsg/virtio_rpmsg_bus.c +++ b/drivers/rpmsg/virtio_rpmsg_bus.c @@ -210,6 +210,22 @@ static void __ept_release(struct kref *kref) kfree(ept); } +static inline dma_addr_t msg_dma_address(struct virtproc_info *vrp, void *msg) +{ + unsigned long offset = msg - vrp->rbufs; + + return vrp->bufs_dma + offset; +} + +static inline void rpmsg_msg_sg_init(struct virtproc_info *vrp, + struct scatterlist *sg, + void *msg, unsigned int len) +{ + sg_init_table(sg, 1); + sg_dma_address(sg) = msg_dma...

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

...44 > > --- a/drivers/rpmsg/virtio_rpmsg_bus.c > > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c > > @@ -210,6 +210,22 @@ static void __ept_release(struct kref *kref) > > kfree(ept); > > } > > > > +static inline dma_addr_t msg_dma_address(struct virtproc_info *vrp, void *msg) > > +{ > > + unsigned long offset = msg - vrp->rbufs; > > + > > + return vrp->bufs_dma + offset; > > +} > > + > > +static inline void rpmsg_msg_sg_init(struct virtproc_info *vrp, > > + struct scatterlist *sg, > > +...

...bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c index 92f6af6..73354ee 100644 --- a/drivers/rpmsg/virtio_rpmsg_bus.c +++ b/drivers/rpmsg/virtio_rpmsg_bus.c @@ -951,6 +951,7 @@ static int rpmsg_probe(struct virtio_device *vdev) void *bufs_va; int err = 0, i; size_t total_buf_space; + bool notify; vrp = kzalloc(sizeof(*vrp), GFP_KERNEL); if (!vrp) @@ -1030,8 +1031,22 @@ static int rpmsg_probe(struct virtio_device *vdev) } } + /* + * Prepare to kick but don't notify yet - we can't do this before + * device is ready. + */ + notify = virtqueue_kick_prepare(vrp->rvq); + + /* F...

...bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c index 92f6af6..73354ee 100644 --- a/drivers/rpmsg/virtio_rpmsg_bus.c +++ b/drivers/rpmsg/virtio_rpmsg_bus.c @@ -951,6 +951,7 @@ static int rpmsg_probe(struct virtio_device *vdev) void *bufs_va; int err = 0, i; size_t total_buf_space; + bool notify; vrp = kzalloc(sizeof(*vrp), GFP_KERNEL); if (!vrp) @@ -1030,8 +1031,22 @@ static int rpmsg_probe(struct virtio_device *vdev) } } + /* + * Prepare to kick but don't notify yet - we can't do this before + * device is ready. + */ + notify = virtqueue_kick_prepare(vrp->rvq); + + /* F...

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

...x 92f6af6..73354ee 100644 > --- a/drivers/rpmsg/virtio_rpmsg_bus.c > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c > @@ -951,6 +951,7 @@ static int rpmsg_probe(struct virtio_device *vdev) > void *bufs_va; > int err = 0, i; > size_t total_buf_space; > + bool notify; > > vrp = kzalloc(sizeof(*vrp), GFP_KERNEL); > if (!vrp) > @@ -1030,8 +1031,22 @@ static int rpmsg_probe(struct virtio_device *vdev) > } > } > > + /* > + * Prepare to kick but don't notify yet - we can't do this before > + * device is ready. > + */ > + noti...

...x 92f6af6..73354ee 100644 > --- a/drivers/rpmsg/virtio_rpmsg_bus.c > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c > @@ -951,6 +951,7 @@ static int rpmsg_probe(struct virtio_device *vdev) > void *bufs_va; > int err = 0, i; > size_t total_buf_space; > + bool notify; > > vrp = kzalloc(sizeof(*vrp), GFP_KERNEL); > if (!vrp) > @@ -1030,8 +1031,22 @@ static int rpmsg_probe(struct virtio_device *vdev) > } > } > > + /* > + * Prepare to kick but don't notify yet - we can't do this before > + * device is ready. > + */ > + noti...

...x 92f6af6..73354ee 100644 > --- a/drivers/rpmsg/virtio_rpmsg_bus.c > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c > @@ -951,6 +951,7 @@ static int rpmsg_probe(struct virtio_device *vdev) > void *bufs_va; > int err = 0, i; > size_t total_buf_space; > + bool notify; > > vrp = kzalloc(sizeof(*vrp), GFP_KERNEL); > if (!vrp) > @@ -1030,8 +1031,22 @@ static int rpmsg_probe(struct virtio_device *vdev) > } > } > > + /* > + * Prepare to kick but don't notify yet - we can't do this before > + * device is ready. > + */ > + noti...

...x 92f6af6..73354ee 100644 > --- a/drivers/rpmsg/virtio_rpmsg_bus.c > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c > @@ -951,6 +951,7 @@ static int rpmsg_probe(struct virtio_device *vdev) > void *bufs_va; > int err = 0, i; > size_t total_buf_space; > + bool notify; > > vrp = kzalloc(sizeof(*vrp), GFP_KERNEL); > if (!vrp) > @@ -1030,8 +1031,22 @@ static int rpmsg_probe(struct virtio_device *vdev) > } > } > > + /* > + * Prepare to kick but don't notify yet - we can't do this before > + * device is ready. > + */ > + noti...

Hi Douglas, On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: > My work is not part of the LLVM mainline yet. But I would be happy to > contribute with the code of my range analysis implementation if it can help > you in something else. We were thinking of adding VRP to LLVM too, though we were mostly interested in Patterson's approach (i.e. not connected with SSI form). It would be great if you can share the code nevertheless. Andrey

Hello, I am trying to figure out, what vrp propagation does in llvm. I tried this program: #include <stdio.h> int main() { int s = 0; int j = 0; for (int i = 0; i < 100; i++) { j = j+i+1; s+=j; } return (s+j); } And got this under optimized version ( I don...