Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1254065ybg; Tue, 2 Jun 2020 05:27:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypfUo1cQdcnR9K/QjqQavxxBivFX+iuhdhbZYSmtdtc+uqYSJpFsuSJ561iKqWqu0V68C4 X-Received: by 2002:a50:9f0f:: with SMTP id b15mr25589145edf.60.1591100829017; Tue, 02 Jun 2020 05:27:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591100829; cv=none; d=google.com; s=arc-20160816; b=DYDsTQ5HLHmREMhDFx+n51L2IJIghzr/mP+RelwwtVUrVueHqQObpg2rdi7VwYgAxv sALOTjkcX5qxzKAv+PuvG0aQWEv4RUm78kdADblv/5pOu6WukPn/MRY5fmOVuNl9VezT Wfcx9p+b6YBX2P0ei27MXXWPhPQgmQX6l1OewQEGVfV2N+MsARSexf/4DYwwacLQPDis vFWaebTxWCB7wXSPGOxpe5RXLioptak8UpFrePHl1xbmHeXVkYln74lH92uuaNeZaupd rvak+S7banLE2NZWPRPc5xZJj1V/8cP0+tuhZIu+ZQ4v+5d+ZqRiHZIeeXQySx5mnke3 sTRw== 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=QJyBxueTazKFkTqWF58Ggg0h2EATDIQfTVWKCSwHXGQ=; b=kYyHT+ZYrnpb1WA68OX9KTumWK3nYfAetPlZ8KXDbHQXx3hn5RiIfGFIElGxy/7rwe wujYDmQDMBp4MN2mO7c/HGRLgOn/+cpGeD2kMVnZIQh4BoNPDVLFrflzAt1RBFBzoAa1 nLJ10z6JjrGHArjP9BNk2AMOISkFMHX69nx1P5B2GlgIYy94dJspY4a8gm+EtpZd54J8 QQvcrvoV9KBLb/8Xvi7MPJJVzAyDZ8euwWEbKRMuYdCJUc4MuY7B00D5e7tpuQf3W9JJ nYKrRQJ0jcx6bGuEe70M9a62115YIutWwOIZw/icTEDpfoDkydRdC1mtIj4OVFAxP03f xtbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@xs4all.nl header.s=s1 header.b=MZWMXgP1; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t25si1456298edq.407.2020.06.02.05.26.45; Tue, 02 Jun 2020 05:27:09 -0700 (PDT) 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=@xs4all.nl header.s=s1 header.b=MZWMXgP1; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726371AbgFBMYu (ORCPT + 99 others); Tue, 2 Jun 2020 08:24:50 -0400 Received: from lb3-smtp-cloud8.xs4all.net ([194.109.24.29]:51109 "EHLO lb3-smtp-cloud8.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725940AbgFBMYt (ORCPT ); Tue, 2 Jun 2020 08:24:49 -0400 Received: from cust-b5b5937f ([IPv6:fc0c:c16d:66b8:757f:c639:739b:9d66:799d]) by smtp-cloud8.xs4all.net with ESMTPA id g5yFjjTQAnv5ng5yIjpM3S; Tue, 02 Jun 2020 14:24:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s1; t=1591100687; bh=QJyBxueTazKFkTqWF58Ggg0h2EATDIQfTVWKCSwHXGQ=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type:From: Subject; b=MZWMXgP1pYS9MYeGlQn34cZqx2Lpx9MjjE+RaChodLv+m/f+9/HkrlUgJwhFztlkg Q3aOanSfNPt5Ed9BGtvanGR8P53/JlaRgqSAhMK/nZEjSTMZ3E1KoA9hz9/UkuZjf/ ggFCzTnJ8HC4LjkhmGrsGB76lugFNWD85CLhI2jLelWLYeVZwlfIst5Fp6vbFSB5qQ sl5IxPJZDkBSDDmYnyP1E48z8U4SEndBx4XLmKWKUbN6RdOZb5IAwBKGM5B2XzwIY2 MVjwihqWpujnCZrOB2tXdDSbVRVze+MxboLl/qJF1hA496IGLqaOuX4qrF6qp1VaE6 8S3bEQo9Ai27w== Subject: Re: [PATCH v6 03/14] videobuf2: handle V4L2 buffer cache flags To: Tomasz Figa Cc: Sergey Senozhatsky , Hans Verkuil , Mauro Carvalho Chehab , Linux Media Mailing List , Linux Kernel Mailing List , Sergey Senozhatsky References: <20200514160153.3646-1-sergey.senozhatsky@gmail.com> <20200514160153.3646-4-sergey.senozhatsky@gmail.com> From: Hans Verkuil Message-ID: Date: Tue, 2 Jun 2020 14:24:43 +0200 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEBfkBJht8YpQj63rNYopBeCmw9rfXwtK/dJdjGpdMJzx5R/vzwrQ+ttN9O5LlW+Na3PFMj+kz+JFK4t1tHjykFrHwc7yTOpFzBUkcdDCzv72VHLofT0 137elGGTAJLAAFV02Q2S6RS1HZg7W61RUevimOA2gX0npzSegrMF8IU7GZPXXTyeT5Mw3XtRxGNJYdupAbvqywJGZv45MO4HywGYRoNQKczbN9igCFh07R4K JThMaFP+FFOCyav32RCK5ZI8VOi9UprfwZWWgckzHeC5Mg62AK8Blqr653V++r8/5qVLj4fF2tpG50CkxiMq0T+KthRBzpEmr6BngFu18/IsJzmQqVtUoZHf UHQKGkllDJxaptxu4xqaAIS8vnOAYgiWtFjZ1Xa2h7gvBrUQgm8= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/06/2020 14:22, Tomasz Figa wrote: > Hi Hans, > > On Tue, Jun 2, 2020 at 11:51 AM Hans Verkuil wrote: >> >> Hi Sergey, >> >> While doing final testing for this patch series (together with the v4l-utils patch) >> I found one remaining issue: >> >> On 14/05/2020 18:01, Sergey Senozhatsky wrote: >>> From: Sergey Senozhatsky >>> >>> Set video buffer cache management flags corresponding to V4L2 cache >>> flags. >>> >>> Both ->prepare() and ->finish() cache management hints should be >>> passed during this stage (buffer preparation), because there is >>> no other way for user-space to tell V4L2 to avoid ->finish() cache >>> flush. >>> >>> Signed-off-by: Sergey Senozhatsky >>> --- >>> .../media/common/videobuf2/videobuf2-v4l2.c | 48 +++++++++++++++++++ >>> include/media/videobuf2-core.h | 11 +++++ >>> 2 files changed, 59 insertions(+) >>> >>> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c >>> index eb5d5db96552..f13851212cc8 100644 >>> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c >>> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c >>> @@ -337,6 +337,53 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b >>> return 0; >>> } >>> >>> +static void set_buffer_cache_hints(struct vb2_queue *q, >>> + struct vb2_buffer *vb, >>> + struct v4l2_buffer *b) >>> +{ >>> + /* >>> + * DMA exporter should take care of cache syncs, so we can avoid >>> + * explicit ->prepare()/->finish() syncs. For other ->memory types >>> + * we always need ->prepare() or/and ->finish() cache sync. >>> + */ >>> + if (q->memory == VB2_MEMORY_DMABUF) { >>> + vb->need_cache_sync_on_finish = 0; >>> + vb->need_cache_sync_on_prepare = 0; >>> + return; >>> + } >>> + >>> + /* >>> + * Cache sync/invalidation flags are set by default in order to >>> + * preserve existing behaviour for old apps/drivers. >>> + */ >>> + vb->need_cache_sync_on_prepare = 1; >>> + vb->need_cache_sync_on_finish = 1; >>> + >>> + if (!vb2_queue_allows_cache_hints(q)) { >>> + /* >>> + * Clear buffer cache flags if queue does not support user >>> + * space hints. That's to indicate to userspace that these >>> + * flags won't work. >>> + */ >>> + b->flags &= ~V4L2_BUF_FLAG_NO_CACHE_INVALIDATE; >>> + b->flags &= ~V4L2_BUF_FLAG_NO_CACHE_CLEAN; >>> + return; >>> + } >> >> These two flags need to be cleared for VB2_MEMORY_DMABUF as well in the test above. >> This bug is causing v4l2-compliance failures (use the test-media script in contrib/test >> in v4l-utils: 'sudo test-media vim2m'). > > Would you be able to paste the failures, so that we know that we > reproduce the same problems? Thanks! For vim2m (but looks the same for vivid/vimc/vicodec): Streaming ioctls: test read/write: OK (Not Supported) test blocking wait: OK Video Capture: Captured 8 buffers test MMAP (no poll): OK Video Capture: Captured 8 buffers test MMAP (select): OK Video Capture: Captured 8 buffers test MMAP (epoll): OK Video Capture: Captured 8 buffers test USERPTR (no poll): OK Video Capture: Captured 8 buffers test USERPTR (select): OK fail: v4l2-test-buffers.cpp(1874): flags & V4L2_BUF_FLAG_NO_CACHE_INVALIDATE fail: v4l2-test-buffers.cpp(1937): setupDmaBuf(expbuf_node, node, q, exp_q) test DMABUF (no poll): FAIL fail: v4l2-test-buffers.cpp(1874): flags & V4L2_BUF_FLAG_NO_CACHE_INVALIDATE fail: v4l2-test-buffers.cpp(1937): setupDmaBuf(expbuf_node, node, q, exp_q) test DMABUF (select): FAIL Regards, Hans > > Best regards, > Tomasz > >> >> It's enough to post a v6.1 for this patch, everything else is fine. >> >> Regards, >> >> Hans >> >>> + >>> + /* >>> + * ->finish() cache sync can be avoided when queue direction is >>> + * TO_DEVICE. >>> + */ >>> + if (q->dma_dir == DMA_TO_DEVICE) >>> + vb->need_cache_sync_on_finish = 0; >>> + >>> + if (b->flags & V4L2_BUF_FLAG_NO_CACHE_INVALIDATE) >>> + vb->need_cache_sync_on_finish = 0; >>> + >>> + if (b->flags & V4L2_BUF_FLAG_NO_CACHE_CLEAN) >>> + vb->need_cache_sync_on_prepare = 0; >>> +} >>> + >>> static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct media_device *mdev, >>> struct v4l2_buffer *b, bool is_prepare, >>> struct media_request **p_req) >>> @@ -381,6 +428,7 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct media_device *md >>> } >>> >>> if (!vb->prepared) { >>> + set_buffer_cache_hints(q, vb, b); >>> /* Copy relevant information provided by the userspace */ >>> memset(vbuf->planes, 0, >>> sizeof(vbuf->planes[0]) * vb->num_planes); >>> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h >>> index 7f39d9fffc8c..ccc5c498d3e3 100644 >>> --- a/include/media/videobuf2-core.h >>> +++ b/include/media/videobuf2-core.h >>> @@ -635,6 +635,17 @@ struct vb2_queue { >>> #endif >>> }; >>> >>> +/** >>> + * vb2_queue_allows_cache_hints() - Return true if the queue allows cache >>> + * and memory consistency hints. >>> + * >>> + * @q: pointer to &struct vb2_queue with videobuf2 queue >>> + */ >>> +static inline bool vb2_queue_allows_cache_hints(struct vb2_queue *q) >>> +{ >>> + return q->allow_cache_hints && q->memory == VB2_MEMORY_MMAP; >>> +} >>> + >>> /** >>> * vb2_plane_vaddr() - Return a kernel virtual address of a given plane. >>> * @vb: pointer to &struct vb2_buffer to which the plane in >>> >>