From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88A44C33CA4 for ; Fri, 10 Jan 2020 10:32:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5F1CB2080D for ; Fri, 10 Jan 2020 10:32:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=xs4all.nl header.i=@xs4all.nl header.b="u+wL2c4v" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727557AbgAJKcs (ORCPT ); Fri, 10 Jan 2020 05:32:48 -0500 Received: from lb3-smtp-cloud8.xs4all.net ([194.109.24.29]:57803 "EHLO lb3-smtp-cloud8.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726697AbgAJKcs (ORCPT ); Fri, 10 Jan 2020 05:32:48 -0500 Received: from [IPv6:2001:420:44c1:2577:c967:e1d3:183a:b8ef] ([IPv6:2001:420:44c1:2577:c967:e1d3:183a:b8ef]) by smtp-cloud8.xs4all.net with ESMTPA id pratilzq7pLtbprawiPzAM; Fri, 10 Jan 2020 11:32:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s1; t=1578652366; bh=gjJVby9uVquUwr750rfbXHaGifI2jr0RhPUkWoJN5rI=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type:From: Subject; b=u+wL2c4vbqWi5AWOgN5v7opLIfDSy6K+t9Ks+U9dfmqJvKfx8Goi2WrdWA9yCiICt AgBPalUNujx9TC3rWES3ceJa8HuYTEfW5ePKzpTux1kKj7tn/sfq4frVC8NatiaJEP SwwP8fiEeyS3zhL6sowCSk8kQBxVbUBZLaiBL3JdAROAdMSWeYbTJ2y6Ix1+cn6fv3 jKLhPmMJ1we8PcDXDXeO/nrmUSIyqBXaPgehvWwfJzeUsB2BvcSnUTflqamg8HCJk+ 0n5/Yw2z4k0sTeJHOQzEYecDGCERAqnBa1QYzQKB3Sp247xvp14mO3wEpNKlmiIaxx 2PFdFUBomYeQA== Subject: Re: [RFC][PATCH 14/15] videobuf2: don't test db_attach in dma-contig prepare and finish To: Sergey Senozhatsky , Hans Verkuil , Tomasz Figa , Mauro Carvalho Chehab , Kyungmin Park , Marek Szyprowski Cc: Sakari Ailus , Laurent Pinchart , Pawel Osciak , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org References: <20191217032034.54897-1-senozhatsky@chromium.org> <20191217032034.54897-15-senozhatsky@chromium.org> From: Hans Verkuil Message-ID: <8d79287c-d868-37cc-85f1-89cf5d8b92a9@xs4all.nl> Date: Fri, 10 Jan 2020 11:32:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191217032034.54897-15-senozhatsky@chromium.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfML14yM9Vzax8I0cQcPmUXvKvshoBz8Gw1Qr7AxI7CtZHh1vmU53s4jSWcc/BddjGM6DrKO9JngNMat9pCW8W7uql/YZpVjrSr46gTMSbTICyZFkY2W8 PEmS+nwickgcfpGYZU1ij2A+EkBvQPlRhZOIV4T+zxsynR7ra5Hdz8PLXhB7YLy9xw53xX3G7IxYEM55AkfM1N+WBJ2fJzuvN6ixgbDzDAJSPqrKcblWh7NK XDpGdgjvQWdBojQeFDCGN5K0Mi6hVlvM4c3T5hUoMIwR7DvyE5KWLWOpOzvrNl7pBowSGlOZhwH0ZzX/BSpQQXaVNOr6vsE/vY1ObnzTwW6q/GyhPmTA0J90 SW68nfMKmioxRG+wJ60Wj2fuX8nbxBsGlogkT7d4oSeUF55jLsO/YdCD4+ieZthlIX8vNf4kxm6swLiGPgn6n4ToIPYmozOtcUvK5jhL/Un3ouGO85h6CZi1 VStaWnlLZW3VkOeBxk8Fvu93D1daoee8d0YU67X9sBsz2JSxpfw6TfhNzonLVF72QBK09XFUsY5Baa9fhr1YCd5XJ6QTm728R4nqGifKt+ZP4zl0Kkuv4PHS IcLl3Ins2LnGamUfL70LxpKI1tMm4RyYg3gag7k0/YimLV3C76octX+ziwqMKic5jjg= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/17/19 4:20 AM, Sergey Senozhatsky wrote: > We moved cache management decision making to the upper layer and > rely on buffer's need_cache_sync flags and videobuf2 core. If the > upper layer (core) has decided to invoke ->prepare() or ->finish() > then we must sync. > > For DMABUF ->need_cache_sync_on_prepare and ->need_cache_sync_on_flush > are always false so videobuf core does not call ->prepare() and > ->finish() on such buffers. > > Additionally, scratch the DMABUF comment. Just combine this and the next patch into a single patch. No need to split this up. Regards, Hans > > Signed-off-by: Sergey Senozhatsky > --- > drivers/media/common/videobuf2/videobuf2-dma-contig.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > index a387260fb321..6ea0961149d7 100644 > --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c > +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > @@ -100,8 +100,7 @@ static void vb2_dc_prepare(void *buf_priv) > struct vb2_dc_buf *buf = buf_priv; > struct sg_table *sgt = buf->dma_sgt; > > - /* DMABUF exporter will flush the cache for us */ > - if (!sgt || buf->db_attach) > + if (!sgt) > return; > > dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, > @@ -113,8 +112,7 @@ static void vb2_dc_finish(void *buf_priv) > struct vb2_dc_buf *buf = buf_priv; > struct sg_table *sgt = buf->dma_sgt; > > - /* DMABUF exporter will flush the cache for us */ > - if (!sgt || buf->db_attach) > + if (!sgt) > return; > > dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir); >