Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6864474ybf; Fri, 6 Mar 2020 06:04:50 -0800 (PST) X-Google-Smtp-Source: ADFU+vtoCuqNQ/7FfXe4FZWaNOUkqtbMWQcMwkmINxUAmCtvufXh1AzpTjQY6GJboAOC/oZ0Mp/6 X-Received: by 2002:a9d:69cd:: with SMTP id v13mr2602513oto.134.1583503490774; Fri, 06 Mar 2020 06:04:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583503490; cv=none; d=google.com; s=arc-20160816; b=TmfrLP6dW67EVySReSW1gCQR/vkd8n1lhLoFHmztK8SIKY5LCw1kM7ZsuPZtPlzSID r5qIPaLSC84BtBIv/Zu/hOmVwl3AQmX3/1aTaZUiY+8E52dKAtKp10VQuOownKkQZbfk EpglByrkbSxTaYYqnmRylAhQjaS65P5hMg9XPIefoWyDBXkYwpXdc8IUL8NccMR0cLEY K518oQm1a2vFWInsjzqRC8yX+4PqU9ANX+n5e1QhgL5ZW8JE7sc3eo9kvQ4gNqBnm18a iTqI/D6VORrBvUEHaFYpsVc2R9LvgYG8mWRWLWL7JRo9mJZYl9PLS74X/sDa2OkhiPkp WH8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=8XxOCEPoREORb7c2HZFhCn8VIk+8g8Vx9q7Ipbq6HFw=; b=qnHjJsrcbHszfLeGwUZWP67EshgSyseY/zIkd8vh5cPlPMrGSEuD4EyVkgEHSgX/VE YdTN+WChq18Gk4avGV6mTOqUO6U/mnkFQkcEjXHc+pWa5/eoxkG0bGrq03cuvMkEcOsK tb1kS601zH/tdGwryixQXNFjHKOe0c2JG76vsCdojYwvh0fkcN9z1RvtAjGCyj64hru4 5v/HJSSa/2RHZvAKCqcMYh6oI6vsTs+CbcHIZwY/skwD1BhCXLHRFGTskaGQVdhnXUdL 9S5fTg6wc+STJEEOeUl4H0bNvHmUdLzMTfLZWIC2OHHZQ4hiwhkgxjmI0WNnnHWsCkYd SmSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@xs4all.nl header.s=s1 header.b=FvVbK0Bl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g17si1638805ots.153.2020.03.06.06.04.38; Fri, 06 Mar 2020 06:04:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@xs4all.nl header.s=s1 header.b=FvVbK0Bl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726898AbgCFOEJ (ORCPT + 99 others); Fri, 6 Mar 2020 09:04:09 -0500 Received: from lb2-smtp-cloud7.xs4all.net ([194.109.24.28]:51351 "EHLO lb2-smtp-cloud7.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726650AbgCFOEI (ORCPT ); Fri, 6 Mar 2020 09:04:08 -0500 Received: from [IPv6:2001:983:e9a7:1:558f:c736:2117:17d1] ([IPv6:2001:983:e9a7:1:558f:c736:2117:17d1]) by smtp-cloud7.xs4all.net with ESMTPA id ADa9j3D5JEE3qADaAjCcfO; Fri, 06 Mar 2020 15:04:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s1; t=1583503446; bh=8XxOCEPoREORb7c2HZFhCn8VIk+8g8Vx9q7Ipbq6HFw=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type:From: Subject; b=FvVbK0BlEtTlr/R0qe1IPOmx5y2+1eGzOryBsaMeONisjfDEnowfg8CsvLS9+I9sA rYVBmc/471Yk5tTURRtrnPBz9Y0dQMva2hwHCRf4948cul0cISEZLuu52/xjn9aTrW JLYzyt4WEBsgLEMuLszQ3wVREtNEffedsBrAUcXCT5vY1W9GE5W2VMI+G4xb3HRq+E 9bFa7Ir22jMArz5Umg5ZZ6s64YCw/qClxfLZtlqH9NGqZQOergZgnVkjQByNi+ZHyC 3oeEV7dBp02TpvAFYS9A03DtIrCqzC7QTnCUx1O70lsURRucl4c/tSAOmzlrx4bMdh N1Hh+A4cOjHgg== Subject: Re: [PATCHv4 10/11] videobuf2: add begin/end cpu_access callbacks to dma-sg To: Sergey Senozhatsky , Hans Verkuil , Tomasz Figa Cc: Mauro Carvalho Chehab , Kyungmin Park , Marek Szyprowski , Sakari Ailus , Laurent Pinchart , Pawel Osciak , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200302041213.27662-1-senozhatsky@chromium.org> <20200302041213.27662-11-senozhatsky@chromium.org> From: Hans Verkuil Message-ID: Date: Fri, 6 Mar 2020 15:04:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200302041213.27662-11-senozhatsky@chromium.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfFMSCgA13lZgSAxVSxB39QttbqabtJqi1Btj2KpFHRd7akSgc+5ebRNAGJwWhBvwvkSHc6wEsg1VbBBnY1jIcXPh6QBQIa8FwoDM7YoSQ67UyYSoOqVw KmoWWaLlsWMbbbeeK3RV2XIFpZArCb1gbE0ConzX8jJwz2zk0CEzBG5j1YlpLZNXFS8ceb/RidXCFTCHuRdJVkeIxNGxNoA6sTGwNRgZj4gsNm4/iLNBfsS5 SnMtxh3XyRtmbE6B8Dhm/2KtFuXbwSFxgsVLEJujOFQVJfd0vz7cjTsfVVXC/3Aeej4XSO43AQVYw7dC8e8tgrgf632YLGhKMZsHGciQrXYw4Cn89b9NxqaE AKR6RNLyFs/0LBlqbB9tazliftZRYKGOzOtVSoNOC2crpWmb4ZLZ93tjuGBQ+zZsl5hNIBHjEE2TeaU+Vu3RUTKkrG8jOD+8LKIKoZyBEQ7KHpDOmszy303A 9BEU6q05KdyCwuPv+CpURSSqx7K5vj4tAU8p6/0YrG/PzocjIfWLYn+jbFTVnFq8oIYUnvo3r7tdSYMbozhuQgnV2V+VkflgmW1v0kEi6Q905aLZsn1g7u51 wjMQTwYYt9/iM+3BEStzJTrb2fO93zJa8YYwn5TWt4KI0g== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/03/2020 05:12, Sergey Senozhatsky wrote: > Provide begin_cpu_access() and end_cpu_access() dma_buf_ops > callbacks for cache synchronisation on exported buffers. > > V4L2_FLAG_MEMORY_NON_CONSISTENT has no effect on dma-sg buffers. > dma-sg allocates memory using the page allocator directly, so > there is no memory consistency guarantee. > > Signed-off-by: Sergey Senozhatsky > --- > .../media/common/videobuf2/videobuf2-dma-sg.c | 28 +++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c > index 6db60e9d5183..ddc67c9aaedb 100644 > --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c > +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c > @@ -120,6 +120,12 @@ static void *vb2_dma_sg_alloc(struct device *dev, unsigned long dma_attrs, > buf->num_pages = size >> PAGE_SHIFT; > buf->dma_sgt = &buf->sg_table; > > + /* > + * NOTE: dma-sg allocates memory using the page allocator directly, so > + * there is no memory consistency guarantee, hence dma-sg ignores DMA > + * attributes passed from the upper layer. That means that > + * V4L2_FLAG_MEMORY_NON_CONSISTENT has no effect on dma-sg buffers. > + */ > buf->pages = kvmalloc_array(buf->num_pages, sizeof(struct page *), > GFP_KERNEL | __GFP_ZERO); > if (!buf->pages) > @@ -470,6 +476,26 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf) > vb2_dma_sg_put(dbuf->priv); > } > > +static int vb2_dma_sg_dmabuf_ops_begin_cpu_access(struct dma_buf *dbuf, > + enum dma_data_direction direction) I suggest you use this style to avoid checkpatch warnings: static int vb2_dma_sg_dmabuf_ops_begin_cpu_access(struct dma_buf *dbuf, enum dma_data_direction direction) > +{ > + struct vb2_dma_sg_buf *buf = dbuf->priv; > + struct sg_table *sgt = buf->dma_sgt; > + > + dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir); > + return 0; > +} > + > +static int vb2_dma_sg_dmabuf_ops_end_cpu_access(struct dma_buf *dbuf, > + enum dma_data_direction direction) Ditto. Regards, Hans > +{ > + struct vb2_dma_sg_buf *buf = dbuf->priv; > + struct sg_table *sgt = buf->dma_sgt; > + > + dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir); > + return 0; > +} > + > static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf) > { > struct vb2_dma_sg_buf *buf = dbuf->priv; > @@ -488,6 +514,8 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = { > .detach = vb2_dma_sg_dmabuf_ops_detach, > .map_dma_buf = vb2_dma_sg_dmabuf_ops_map, > .unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap, > + .begin_cpu_access = vb2_dma_sg_dmabuf_ops_begin_cpu_access, > + .end_cpu_access = vb2_dma_sg_dmabuf_ops_end_cpu_access, > .vmap = vb2_dma_sg_dmabuf_ops_vmap, > .mmap = vb2_dma_sg_dmabuf_ops_mmap, > .release = vb2_dma_sg_dmabuf_ops_release, >