Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3301807pxu; Tue, 15 Dec 2020 03:52:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJz2Mdte7tWjEdPZl8Bha/laZBKJcT2C7uKYrzvYvz3h4kfmud2EmozpjY5AESnlWrHpbgy/ X-Received: by 2002:a17:906:3593:: with SMTP id o19mr13252766ejb.377.1608033138397; Tue, 15 Dec 2020 03:52:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608033138; cv=none; d=google.com; s=arc-20160816; b=manqUz+Ibkd/t/PxcPAnK82aOE0GP8WgUL+xP+T81Wv9bkT6PEZrZGdD0MHUgoflaE LfD/2i7rCz5fK3IcngQcgWagpQorh95yOZp2K5B2BBEAQqQESYUz/GJqSDH+XQw/5+jq sG9xF3n3KoQnmH/OwpsuSmXij486Et9S0aGruEVxh+qrOrAEAlCu7zlD4dqlZa6V5Iu/ Y9Lov1TsQsNtSrVRFDhMrqxPlugU0FNaT/kByagLUHIQe7Npev2pxaUGReO3Xu6WeGW/ K0iVOVI87UJvyr1diofDl/EU4r8lb78FsnKIbEYH1EBA01Hm78XvaTwmyKXgaWU4sUWs ZWbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=VY9C6dKzDaM57v3JdSf9JJx6SvlGxl+IBr0BX0RagYY=; b=gU/PIqfl+QXTMvTtoPr47FCnAgyNaQMCGLVfqtoNnFqxPObQo1Mn3UdCbVaMeha6IA 8GBWM4txdKlkGgQHgKJKOqRKKiUzRgrJSjM1Cg+pXWhkuv0Q1ww3dj0MXIwnSgiun9uB JAkpCTaZ5EhWqNYBGwFlHt38Gfs58vzoS7aBRY/6hA0gmRJhnJ1RLeNHY5Vno7MzOnFJ Jhf7PQIcG2m5KyQfcF0iOCoog5xrmPHAo6hQqSswZWZAZSMwDHg8vALbwTClKLDb29z6 uVvOrutO7y/sVjuAuiqd8juEuyEGWLPEyrmWU3N0jWcQaRsTPnPqJooItYQPpf+x8VgM Kdlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=N9uyguSn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p20si770325ejw.65.2020.12.15.03.51.55; Tue, 15 Dec 2020 03:52:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=N9uyguSn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727366AbgLOLtG (ORCPT + 99 others); Tue, 15 Dec 2020 06:49:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725535AbgLOLsy (ORCPT ); Tue, 15 Dec 2020 06:48:54 -0500 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8ACE9C0617A6 for ; Tue, 15 Dec 2020 03:48:14 -0800 (PST) Received: by mail-ej1-x643.google.com with SMTP id g20so27277300ejb.1 for ; Tue, 15 Dec 2020 03:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VY9C6dKzDaM57v3JdSf9JJx6SvlGxl+IBr0BX0RagYY=; b=N9uyguSnGB+JUEvy3Zokm/wwWmOPeKisc2thcMEVjc8JqPOw4S+qpWc7TN43mrmb/R atMsEGLUAf0pEj1yDu/bUT5OE9UTG3bwoMph8vSrfnTxCEKSqrfU2I8yHFt6MhZZpc8g jeS5KYLTnisHoG+YLt8S3bJH5lgv8pMMa+MJU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VY9C6dKzDaM57v3JdSf9JJx6SvlGxl+IBr0BX0RagYY=; b=gJJEW+BvxZ4dqyxUsT99hPZwLbjc0Muex67dOYL7fxUIN4e1zz8r07k6JLsX5mFhuW PcfQazVfNeEe2tje+HvjMLWaTsHTf0hBuZ+gr9ipoivYsxUP3vcLVGZyB2XQS0+WIm4B xwrJI+0AWsK/vSyJtOqY7yq5PbJQp8qHBwUHy8I9nZ2NDaKIt2zqkAbIDhbiqMl/lmyU vwMZYhvmaCTVvUsS+Q2bCi6Qr/0L2+6HnCt/FqvrRhw6yH2mZqN1K0K3PafeGHRWv80c C3fOFW+W6WDtkSgfgUq+op732wMGZXxMQ0XLoeS4DSv5N27Yovmma863HUd9D/JjJ4Xb eDSQ== X-Gm-Message-State: AOAM533zsqPJB8bLsgvJwfZfdERV45SMGoObkA1ieNG2Yu/W18uIM0nT 1rtvRqmsTYSwdBdiYCbF5hyt6kjILCyOkA== X-Received: by 2002:a17:906:add7:: with SMTP id lb23mr27847909ejb.352.1608032892948; Tue, 15 Dec 2020 03:48:12 -0800 (PST) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com. [209.85.221.46]) by smtp.gmail.com with ESMTPSA id z26sm18205323edl.71.2020.12.15.03.48.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Dec 2020 03:48:12 -0800 (PST) Received: by mail-wr1-f46.google.com with SMTP id d26so6323167wrb.12 for ; Tue, 15 Dec 2020 03:48:12 -0800 (PST) X-Received: by 2002:a5d:6209:: with SMTP id y9mr6274395wru.197.1608032891619; Tue, 15 Dec 2020 03:48:11 -0800 (PST) MIME-Version: 1.0 References: <20201214125703.866998-1-acourbot@chromium.org> <5319c101-f4a4-9c99-b15d-4999366f7a63@linaro.org> In-Reply-To: <5319c101-f4a4-9c99-b15d-4999366f7a63@linaro.org> From: Tomasz Figa Date: Tue, 15 Dec 2020 20:47:59 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] media: venus: use contig vb2 ops To: Stanimir Varbanov Cc: Alexandre Courbot , Fritz Koenig , Linux Media Mailing List , Linux Kernel Mailing List , linux-arm-msm , Robin Murphy Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 15, 2020 at 8:16 PM Stanimir Varbanov wrote: > > Hi, > > Cc: Robin > > On 12/14/20 2:57 PM, Alexandre Courbot wrote: > > This driver uses the SG vb2 ops, but effectively only ever accesses the > > first entry of the SG table, indicating that it expects a flat layout. > > Switch it to use the contiguous ops to make sure this expected invariant > > Under what circumstances the sg table will has nents > 1? I came down to > [1] but not sure I got it right. > > I'm afraid that for systems with low amount of system memory and when > the memory become fragmented, the driver will not work. That's why I > started with sg allocator. It is exactly the opposite. The vb2-dma-contig allocator is "contig" in terms of the DMA (aka IOVA) address space. In other words, it guarantees that having one DMA address and length fully describes the buffer. This seems to be the requirement of the hardware/firmware handled by the venus driver. If the device is behind an IOMMU, which is the case for the SoCs in question, the underlying DMA ops will actually allocate a discontiguous set of pages, so it has nothing to do to system memory amount or fragmentation. If for some reason the IOMMU can't be used, there is no way around, the memory needs to be contiguous because of the hardware/firmware/driver expectation. On the other hand, the vb2-dma-sg allocator doesn't have any continuity guarantees for the DMA, or any other, address space. The current code works fine, because it calls dma_map_sg() on the whole set of pages and that ends up mapping it contiguously in the IOVA space, but that's just an implementation detail, not an API guarantee. Best regards, Tomasz > > [1] > https://elixir.bootlin.com/linux/v5.10.1/source/drivers/iommu/dma-iommu.c#L782 > > > is always enforced. Since the device is supposed to be behind an IOMMU > > this should have little to none practical consequences beyond making the > > driver not rely on a particular behavior of the SG implementation. > > > > Reported-by: Tomasz Figa > > Signed-off-by: Alexandre Courbot > > --- > > Hi everyone, > > > > It probably doesn't hurt to fix this issue before some actual issue happens. > > I have tested this patch on Chrome OS and playback was just as fine as with > > the SG ops. > > > > drivers/media/platform/Kconfig | 2 +- > > drivers/media/platform/qcom/venus/helpers.c | 9 ++------- > > drivers/media/platform/qcom/venus/vdec.c | 6 +++--- > > drivers/media/platform/qcom/venus/venc.c | 6 +++--- > > 4 files changed, 9 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > > index 35a18d388f3f..d9d7954111f2 100644 > > --- a/drivers/media/platform/Kconfig > > +++ b/drivers/media/platform/Kconfig > > @@ -533,7 +533,7 @@ config VIDEO_QCOM_VENUS > > depends on INTERCONNECT || !INTERCONNECT > > select QCOM_MDT_LOADER if ARCH_QCOM > > select QCOM_SCM if ARCH_QCOM > > - select VIDEOBUF2_DMA_SG > > + select VIDEOBUF2_DMA_CONTIG > > select V4L2_MEM2MEM_DEV > > help > > This is a V4L2 driver for Qualcomm Venus video accelerator > > diff --git a/drivers/media/platform/qcom/venus/helpers.c b/drivers/media/platform/qcom/venus/helpers.c > > index 50439eb1ffea..859d260f002b 100644 > > --- a/drivers/media/platform/qcom/venus/helpers.c > > +++ b/drivers/media/platform/qcom/venus/helpers.c > > @@ -7,7 +7,7 @@ > > #include > > #include > > #include > > -#include > > +#include > > #include > > #include > > > > @@ -1284,14 +1284,9 @@ int venus_helper_vb2_buf_init(struct vb2_buffer *vb) > > struct venus_inst *inst = vb2_get_drv_priv(vb->vb2_queue); > > struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb); > > struct venus_buffer *buf = to_venus_buffer(vbuf); > > - struct sg_table *sgt; > > - > > - sgt = vb2_dma_sg_plane_desc(vb, 0); > > - if (!sgt) > > - return -EFAULT; > > > > buf->size = vb2_plane_size(vb, 0); > > - buf->dma_addr = sg_dma_address(sgt->sgl); > > Can we do it: > > if (WARN_ON(sgt->nents > 1)) > return -EFAULT; > > I understand that logically using dma-sg when the flat layout is > expected by the hardware is wrong, but I haven't seen issues until now. > > > + buf->dma_addr = vb2_dma_contig_plane_dma_addr(vb, 0); > > > > if (vb->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) > > list_add_tail(&buf->reg_list, &inst->registeredbufs); > > diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c > > index 8488411204c3..3fb277c81aca 100644 > > --- a/drivers/media/platform/qcom/venus/vdec.c > > +++ b/drivers/media/platform/qcom/venus/vdec.c > > @@ -13,7 +13,7 @@ > > #include > > #include > > #include > > -#include > > +#include > > > > #include "hfi_venus_io.h" > > #include "hfi_parser.h" > > @@ -1461,7 +1461,7 @@ static int m2m_queue_init(void *priv, struct vb2_queue *src_vq, > > src_vq->io_modes = VB2_MMAP | VB2_DMABUF; > > src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; > > src_vq->ops = &vdec_vb2_ops; > > - src_vq->mem_ops = &vb2_dma_sg_memops; > > + src_vq->mem_ops = &vb2_dma_contig_memops; > > src_vq->drv_priv = inst; > > src_vq->buf_struct_size = sizeof(struct venus_buffer); > > src_vq->allow_zero_bytesused = 1; > > @@ -1475,7 +1475,7 @@ static int m2m_queue_init(void *priv, struct vb2_queue *src_vq, > > dst_vq->io_modes = VB2_MMAP | VB2_DMABUF; > > dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; > > dst_vq->ops = &vdec_vb2_ops; > > - dst_vq->mem_ops = &vb2_dma_sg_memops; > > + dst_vq->mem_ops = &vb2_dma_contig_memops; > > dst_vq->drv_priv = inst; > > dst_vq->buf_struct_size = sizeof(struct venus_buffer); > > dst_vq->allow_zero_bytesused = 1; > > diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c > > index 1c61602c5de1..a09550cd1dba 100644 > > --- a/drivers/media/platform/qcom/venus/venc.c > > +++ b/drivers/media/platform/qcom/venus/venc.c > > @@ -10,7 +10,7 @@ > > #include > > #include > > #include > > -#include > > +#include > > #include > > #include > > #include > > @@ -1001,7 +1001,7 @@ static int m2m_queue_init(void *priv, struct vb2_queue *src_vq, > > src_vq->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF; > > src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; > > src_vq->ops = &venc_vb2_ops; > > - src_vq->mem_ops = &vb2_dma_sg_memops; > > + src_vq->mem_ops = &vb2_dma_contig_memops; > > src_vq->drv_priv = inst; > > src_vq->buf_struct_size = sizeof(struct venus_buffer); > > src_vq->allow_zero_bytesused = 1; > > @@ -1017,7 +1017,7 @@ static int m2m_queue_init(void *priv, struct vb2_queue *src_vq, > > dst_vq->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF; > > dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; > > dst_vq->ops = &venc_vb2_ops; > > - dst_vq->mem_ops = &vb2_dma_sg_memops; > > + dst_vq->mem_ops = &vb2_dma_contig_memops; > > dst_vq->drv_priv = inst; > > dst_vq->buf_struct_size = sizeof(struct venus_buffer); > > dst_vq->allow_zero_bytesused = 1; > > > > -- > regards, > Stan