Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1230342
| From | Robin Murphy <robin.murphy@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device |
| Date | 2015-09-22 17:40 +0200 |
| Message-ID | <qbxPI-10s-29@gated-at.bofh.it> (permalink) |
| References | <qb8oi-6wH-1@gated-at.bofh.it> <qb9aI-7Hp-45@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Hans, On 21/09/15 14:13, Hans Verkuil wrote: > Hi Tiffany! > > On 21-09-15 14:26, Tiffany Lin wrote: >> vb2_dc_prepare use the number of SG entries dma_map_sg_attrs return. >> But in dma_sync_sg_for_device, it use lengths of each SG entries >> before dma_map_sg_attrs. dma_map_sg_attrs will concatenate >> SGs until dma length > dma seg bundary. sgt->nents will less than >> sgt->orig_nents. Using SG entries after dma_map_sg_attrs >> in vb2_dc_prepare will make some SGs are not sync to device. >> After add DMA_ATTR_SKIP_CPU_SYNC in vb2_dc_get_userptr to remove >> sync data to device twice. Device randomly get incorrect data because >> some SGs are not sync to device. Change to use number of SG entries >> before dma_map_sg_attrs in vb2_dc_prepare to prevent this issue. >> >> Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com> >> --- >> drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c >> index 2397ceb..c5d00bd 100644 >> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c >> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c >> @@ -100,7 +100,7 @@ static void vb2_dc_prepare(void *buf_priv) >> if (!sgt || buf->db_attach) >> return; >> >> - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir); >> + dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir); >> } >> >> static void vb2_dc_finish(void *buf_priv) >> @@ -112,7 +112,7 @@ static void vb2_dc_finish(void *buf_priv) >> if (!sgt || buf->db_attach) >> return; >> >> - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir); >> + dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir); >> } > > I don't really understand it. I am assuming that this happens on an arm and that > the dma_map_sg_attrs and dma_sync_sg_* functions used are arm_iommu_map_sg() and > arm_iommu_sync_sg_* as implemented in arch/arm/mm/dma-mapping.c. > > Now, as I understand it (and my understanding may very well be flawed!) the map_sg > function concatenates SG entries if possible, so it may return fewer entries. But > the dma_sync_sg functions use those updated SG entries, so the full buffer should > be covered by this. Using orig_nents will actually sync parts of the buffer twice! > The first nents entries already cover the full buffer so any remaining entries up > to orig_nents will just duplicate parts of the buffer. As Documentation/DMA-API.txt says, the parameters to dma_sync_sg_* must be the same as those originally passed into dma_map_sg. The segments are only merged *from the point of view of the device*: if I have a scatterlist of two discontiguous 4K segments, I can remap them with an IOMMU so the device sees them as a single 8K buffer, and tell it as such. If on the other hand I want to do maintenance from the CPU side (i.e. any DMA API call), then those DMA addresses mean nothing and I can only operate on the CPU addresses of the underlying pages, which are still very much discontiguous in the linear map; ergo I still need to iterate over the original entries. Whilst I can't claim much familiarity with v4l itself, from a brief look over the existing code this patch does look to be doing the right thing. Robin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Tiffany Lin <tiffany.lin@mediatek.com> - 2015-09-21 14:30 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Hans Verkuil <hverkuil@xs4all.nl> - 2015-09-21 15:20 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device tiffany lin <tiffany.lin@mediatek.com> - 2015-09-22 12:20 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Sakari Ailus <sakari.ailus@iki.fi> - 2015-09-22 14:10 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device tiffany lin <tiffany.lin@mediatek.com> - 2015-09-22 15:40 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Robin Murphy <robin.murphy@arm.com> - 2015-09-22 17:40 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Sakari Ailus <sakari.ailus@iki.fi> - 2015-09-22 22:40 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Daniel Kurtz <djkurtz@chromium.org> - 2015-09-23 02:00 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Sakari Ailus <sakari.ailus@iki.fi> - 2015-09-22 23:20 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Hans Verkuil <hverkuil@xs4all.nl> - 2015-09-23 10:50 +0200
Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device Sakari Ailus <sakari.ailus@iki.fi> - 2015-09-23 12:10 +0200
csiph-web