search for: sg_dma_len

Hi Logan/All, I have added a check for the sg_dma_len == 0 : """ } __sgt_iter(struct scatterlist *sgl, bool dma) { struct sgt_iter s = { .sgp = sgl }; + if (sgl && sg_dma_len(sgl) == 0) + s.sgp = NULL; if (s.sgp) { ..... """ at location [1]. but it doens't fix the...

On Thu, 27 Aug 2020 at 22:36, Logan Gunthorpe <logang at deltatee.com> wrote: > > > > On 2020-08-23 6:04 p.m., Tom Murphy wrote: > > I have added a check for the sg_dma_len == 0 : > > """ > > } __sgt_iter(struct scatterlist *sgl, bool dma) { > > struct sgt_iter s = { .sgp = sgl }; > > > > + if (sgl && sg_dma_len(sgl) == 0) > > + s.sgp = NULL; > > > > if (s.sgp) { &g...

..., max_len = dma_get_max_seg_size(dev); - int i, count = 0; + int i; for_each_sg(sg, s, nents, i) { /* Restore this segment's original unaligned fields first */ @@ -862,39 +861,16 @@ static int __finalise_sg(struct device *dev, struct scatterlist *sg, int nents, unsigned int s_length = sg_dma_len(s); unsigned int s_iova_len = s->length; + if (i > 0) + cur = sg_next(cur); + s->offset += s_iova_off; s->length = s_length; - sg_dma_address(s) = DMA_MAPPING_ERROR; - sg_dma_len(s) = 0; - - /* - * Now fill in the real DMA data. If... - * - there is a valid output s...

...m/nouveau/nvkm/falcon/fw.c @@ -89,11 +89,6 @@ nvkm_falcon_fw_boot(struct nvkm_falcon_fw *fw, struct nvkm_subdev *user, nvkm_falcon_fw_dtor_sigs(fw); } - /* after last write to the img, sync dma mappings */ - dma_sync_single_for_device(fw->fw.device->dev, - fw->fw.phys, - sg_dma_len(&fw->fw.mem.sgl), - DMA_TO_DEVICE); FLCNFW_DBG(fw, "resetting"); fw->func->reset(fw); @@ -105,6 +100,12 @@ nvkm_falcon_fw_boot(struct nvkm_falcon_fw *fw, struct nvkm_subdev *user, goto done; } + /* after last write to the img, sync dma mappings */ + dma_sy...

...+27,19 @@ static __always_inline struct sgt_iter { > >>>>>> } __sgt_iter(struct scatterlist *sgl, bool dma) { > >>>>>> struct sgt_iter s = { .sgp = sgl }; > >>>>>> > >>>>>> + if (sgl && !sg_dma_len(s.sgp)) > >>>>> > >>>>> I'd extend the condition to be, just to be safe: > >>>>> if (dma && sgl && !sg_dma_len(s.sgp)) > >>>>> > >>>> > >>>> Right, good catch, that's...

...0ec601 100644 --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c @@ -205,7 +205,8 @@ nvkm_firmware_dtor(struct nvkm_firmware *fw) break; case NVKM_FIRMWARE_IMG_DMA: nvkm_memory_unref(&memory); - dma_free_coherent(fw->device->dev, sg_dma_len(&fw->mem.sgl), fw->img, fw->phys); + dma_free_noncoherent(fw->device->dev, sg_dma_len(&fw->mem.sgl), + fw->img, fw->phys, DMA_TO_DEVICE); break; case NVKM_FIRMWARE_IMG_SGT: nvkm_memory_unref(&memory); @@ -236,10 +237,12 @@ nvkm_firmware_ctor(cons...

...15/i915_scatterlist.h > >>> @@ -27,13 +27,19 @@ static __always_inline struct sgt_iter { > >>> } __sgt_iter(struct scatterlist *sgl, bool dma) { > >>> struct sgt_iter s = { .sgp = sgl }; > >>> > >>> + if (sgl && !sg_dma_len(s.sgp)) > >> > >> I'd extend the condition to be, just to be safe: > >> if (dma && sgl && !sg_dma_len(s.sgp)) > >> > > > > Right, good catch, that's definitely necessary. > > > >>> + s.sgp =...

...f (!vring_use_dma_api(vq->vq.vdev)) > return (dma_addr_t)sg_phys(sg); > > + /* If the sg is already mapped, return the DMA address */ How come we even reach this code for rpmsg? Does vring_use_dma_api return true for rpmsg? > + if (sg_dma_address(sg)) { > + sg->length = sg_dma_len(sg); > + return sg_dma_address(sg); > + } > + Is there a rule that says 0 is not a valid address? > /* > * We can't use dma_map_sg, because we don't use scatterlists in > * the way it expects (we don't guarantee that the scatterlist > -- > 1.9.1

...f (!vring_use_dma_api(vq->vq.vdev)) > return (dma_addr_t)sg_phys(sg); > > + /* If the sg is already mapped, return the DMA address */ How come we even reach this code for rpmsg? Does vring_use_dma_api return true for rpmsg? > + if (sg_dma_address(sg)) { > + sg->length = sg_dma_len(sg); > + return sg_dma_address(sg); > + } > + Is there a rule that says 0 is not a valid address? > /* > * We can't use dma_map_sg, because we don't use scatterlists in > * the way it expects (we don't guarantee that the scatterlist > -- > 1.9.1

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

...u/drm/nouveau/nvkm/core/firmware.c > +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > @@ -205,7 +205,8 @@ nvkm_firmware_dtor(struct nvkm_firmware *fw) > break; > case NVKM_FIRMWARE_IMG_DMA: > nvkm_memory_unref(&memory); > - dma_free_coherent(fw->device->dev, sg_dma_len(&fw->mem.sgl), fw->img, fw->phys); > + dma_free_noncoherent(fw->device->dev, sg_dma_len(&fw->mem.sgl), > + fw->img, fw->phys, DMA_TO_DEVICE); > break; > case NVKM_FIRMWARE_IMG_SGT: > nvkm_memory_unref(&memory); > @@ -236,10 +237...

...13bf52 100644 --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c @@ -205,7 +205,9 @@ nvkm_firmware_dtor(struct nvkm_firmware *fw) break; case NVKM_FIRMWARE_IMG_DMA: nvkm_memory_unref(&memory); - dma_free_coherent(fw->device->dev, sg_dma_len(&fw->mem.sgl), fw->img, fw->phys); + dma_unmap_single(fw->device->dev, fw->phys, sg_dma_len(&fw->mem.sgl), + DMA_TO_DEVICE); + kfree(fw->img); break; case NVKM_FIRMWARE_IMG_SGT: nvkm_memory_unref(&memory); @@ -235,14 +237,17 @@ nvkm_firmware_ctor(co...

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

...ls in the kernel seems to > indicate checking for 0 for errors and then ignoring the non-zero return > is a common pattern. Are you sure it's okay to make the change you're > proposing? Various code uses tricks like just iterating the mapped list until the first segment with zero sg_dma_len(). Others may well simply have bugs. Robin. > Anyway, due to the time of year and all, I'd like to ask you to file a > bug against i915 at [1] so this is not forgotten, and please let's not > merge the changes before this is resolved. > > > Thanks, > Jani. > &gt...

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