Re: [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers

From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Robin Murphy <robin.murphy@arm.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	linux-arm-kernel@lists.infradead.org,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers
Date: Mon, 7 Sep 2020 16:02:17 +0200	[thread overview]
Message-ID: <bdd3503f-d4f1-a1af-d10d-d75a1037ac5a@samsung.com> (raw)
In-Reply-To: <CAAFQd5AZDzG6i00gcAZKM9ZV1tATWufL=+xXUAmgrbTPt8W6Gw@mail.gmail.com>

Hi Tomasz,

On 07.09.2020 15:07, Tomasz Figa wrote:
> On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> Use recently introduced common wrappers operating directly on the struct
>> sg_table objects and scatterlist page iterators to make the code a bit
>> more compact, robust, easier to follow and copy/paste safe.
>>
>> No functional change, because the code already properly did all the
>> scatterlist related calls.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>   .../common/videobuf2/videobuf2-dma-contig.c   | 34 ++++++++-----------
>>   .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++++++----------
>>   .../common/videobuf2/videobuf2-vmalloc.c      | 12 +++----
>>   3 files changed, 31 insertions(+), 47 deletions(-)
>>
> Thanks for the patch! Please see my comments inline.
>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
>> index ec3446cc45b8..1b242d844dde 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
>> @@ -58,10 +58,10 @@ static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
>>          unsigned int i;
>>          unsigned long size = 0;
>>
>> -       for_each_sg(sgt->sgl, s, sgt->nents, i) {
>> +       for_each_sgtable_dma_sg(sgt, s, i) {
>>                  if (sg_dma_address(s) != expected)
>>                          break;
>> -               expected = sg_dma_address(s) + sg_dma_len(s);
>> +               expected += sg_dma_len(s);
>>                  size += sg_dma_len(s);
>>          }
>>          return size;
>> @@ -103,8 +103,7 @@ static void vb2_dc_prepare(void *buf_priv)
>>          if (!sgt)
>>                  return;
>>
>> -       dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
>> -                              buf->dma_dir);
>> +       dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir);
>>   }
>>
>>   static void vb2_dc_finish(void *buf_priv)
>> @@ -115,7 +114,7 @@ static void vb2_dc_finish(void *buf_priv)
>>          if (!sgt)
>>                  return;
>>
>> -       dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
>> +       dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir);
>>   }
>>
>>   /*********************************************/
>> @@ -275,8 +274,8 @@ static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf,
>>                   * memory locations do not require any explicit cache
>>                   * maintenance prior or after being used by the device.
>>                   */
>> -               dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
>> -                                  attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
>> +               dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir,
>> +                                 DMA_ATTR_SKIP_CPU_SYNC);
>>          sg_free_table(sgt);
>>          kfree(attach);
>>          db_attach->priv = NULL;
>> @@ -301,8 +300,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
>>
>>          /* release any previous cache */
>>          if (attach->dma_dir != DMA_NONE) {
>> -               dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
>> -                                  attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
>> +               dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir,
>> +                                 DMA_ATTR_SKIP_CPU_SYNC);
>>                  attach->dma_dir = DMA_NONE;
>>          }
>>
>> @@ -310,9 +309,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
>>           * mapping to the client with new direction, no cache sync
>>           * required see comment in vb2_dc_dmabuf_ops_detach()
>>           */
>> -       sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
>> -                                     dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
>> -       if (!sgt->nents) {
>> +       if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
>> +                           DMA_ATTR_SKIP_CPU_SYNC)) {
>>                  pr_err("failed to map scatterlist\n");
>>                  mutex_unlock(lock);
>>                  return ERR_PTR(-EIO);
> As opposed to dma_map_sg_attrs(), dma_map_sgtable() now returns an
> error code on its own. Is it expected to ignore it and return -EIO?

Those errors are more or less propagated to userspace and -EIO has been 
already widely documented in V4L2 documentation as the error code for 
the most of the V4L2 ioctls. I don't want to change it. A possible 
-EINVAL returned from dma_map_sgtable() was just one of the 'generic' 
error codes, not very descriptive in that case. Probably the main 
problem here is that dma_map_sg() and friend doesn't return any error 
codes...

 > ...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland