Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp167128ybl; Tue, 28 Jan 2020 00:41:10 -0800 (PST) X-Google-Smtp-Source: APXvYqxmYbPkcMZDK70QzRVtEzGy4qrbhLK0TP5FYwjkeH2cmja4SgmnM3zDs3x47VNg6fflkRnp X-Received: by 2002:a9d:6d81:: with SMTP id x1mr16382227otp.9.1580200870324; Tue, 28 Jan 2020 00:41:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580200870; cv=none; d=google.com; s=arc-20160816; b=EzQ8edmTiaA56qUwSlkRVtUjQ39TfOXg9Sy4vXU+U2W7XmUqQVjs2VZVJ3PDGQFpyO Szy05LBdsEbPoZaBuNpAwbtmwVVchvzYjlrs6qj13R94Xmp/1r41ERZZLFEpqhne6ZcD ZiO3BH9IfuvdRUf/7v/qYo9NB6URnSXWAN5kgOlNMNPd4eV46AZKPh9F5YtMXEPrqHxZ nueqTNT63CK/r0VUODXvREX9hC82hwx7I5r9qMpQpLUaElBWpVy2GwayYKyfI3dfZCkF ZyEMn3a/F9zZOmRG1nAo0nEYQzwhNhlAY9ROa9qlX0hVFDmVyjLTfQKem9CvgJYDltiW R7Fg== 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=IV9O/g4Kf0NmuJ/UEFAYcx5nb57xh717LTJtJ7iiERY=; b=slPYQ/3IQgZProCP2i3UkFD2PqVzBwx1CbQ5YSEHfdxladaCWvZ57aH4ZjTwWXoDT9 RCLe8NqafaJDDuKQN9pabGPC6rYnNPHCxsIJtCPdiMXP8y/E7Azq8HhB0WYQ8NqC+PWx UWYwEU0Lz6IFfTHub7B6pYJbJH5CgAxlV2xW/FVA9wPPhvld86ejpd89h4BzWOn6t1sb bty8GwKbDyqOBaDC9eyO2U1mDXZ7PSJATaXdWVE7NsaxP8hg0eheauvLfZXwpPKe2H7M u9uh5RiD9tYBfTG/RqhcU+36h+UnMdzJN50vwwZ2KMETmLXtvxI6e89yxDqlGsJpWjZN djSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@xs4all.nl header.s=s1 header.b=TFndPTPX; 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 x137si4703776oif.42.2020.01.28.00.40.56; Tue, 28 Jan 2020 00:41:10 -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=TFndPTPX; 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 S1725997AbgA1Iie (ORCPT + 99 others); Tue, 28 Jan 2020 03:38:34 -0500 Received: from lb2-smtp-cloud7.xs4all.net ([194.109.24.28]:54143 "EHLO lb2-smtp-cloud7.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725867AbgA1Iid (ORCPT ); Tue, 28 Jan 2020 03:38:33 -0500 Received: from [IPv6:2001:983:e9a7:1:6d16:ffdc:f7c6:fc6f] ([IPv6:2001:983:e9a7:1:6d16:ffdc:f7c6:fc6f]) by smtp-cloud7.xs4all.net with ESMTPA id wMOEiIkz7rNgywMOFiSdnm; Tue, 28 Jan 2020 09:38:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s1; t=1580200711; bh=IV9O/g4Kf0NmuJ/UEFAYcx5nb57xh717LTJtJ7iiERY=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type:From: Subject; b=TFndPTPXRuMwwNo9Xd2LuBMFrNO3fT0IEbD2rbN3hfbTyj+Q5vk6lNyCsMz8m4Zmu VZMvVKjo8tEQL9U79xT1Nvd/2/VFyonkddRzVLbEI4957OA5b5bxCKn2HZtaM/tQRf Q/VYb73UEWH4OM/OvGB1VTFAKZR3juKGQuiRv0Iw5/ZR/50DUDTn8OnBqPRF0owxlb REo2XDKXspBE8VxVcCxL3UmWtIs+HPfkCewn0Wsg8+qg+Edgjn9/M0ATuKc05rPPiq r6GPOKW2Mc4c3+hAWzmHn/a++MTF3zofvfbU6YC4qljetjvLdhDe3sgOWiL0E83F64 Q26qq9d0zwO2w== Subject: Re: [RFC][PATCH 05/15] videobuf2: handle V4L2_FLAG_MEMORY_NON_CONSISTENT in REQBUFS To: Tomasz Figa Cc: Sergey Senozhatsky , Hans Verkuil , Mauro Carvalho Chehab , Kyungmin Park , Marek Szyprowski , Sakari Ailus , Laurent Pinchart , Pawel Osciak , Linux Media Mailing List , Linux Kernel Mailing List References: <20191217032034.54897-1-senozhatsky@chromium.org> <20191217032034.54897-6-senozhatsky@chromium.org> <8d0c95c3-64a2-ec14-0ac2-204b0430b2b4@xs4all.nl> <20200122021805.GE149602@google.com> <20200122034826.GA49953@google.com> <7c4accc6-56f2-ecd0-1549-a4114b339ce8@xs4all.nl> From: Hans Verkuil Message-ID: Date: Tue, 28 Jan 2020 09:38:29 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKhEKfdXAdA81HiQ4zgKXjWpzuc1aiNifsOOV1m3LmCz/4IKJlloa5zdoRcxZbCSUQrnY0MAlFMtbdmbqFumT0EcI+bVtzG+r5NS1DLOh/LwW8BpM3GU oXt0dUpdn+Lod8HiKhoGdxMskahQN3fVNR0AXeK/sstlhbjVagvJ4DNLk/rzLc5juWPdDIjqAOt4ZrjAyFiQkLl+I+aboXk5oivLErmzpUB/6qPhI1sQ3Hgp ym+nbdFiULGbqK21+UcVM0U7I6t+XKvwT2mppESmeRWMqvIRPYkNfkqK5TtYiGykDYWjGTPh+K+Co5jh8E77viyZcdWgcXFVr+8QUMp7xHuFEfk2UqlEovtQ enASxPymsBn6hH0piaWtU2LzrAOpSegXNZR/I8Mvn9671sb9KZhl0R9mlexhKQJmsNGuxMX8cNgj/7d4PeVL/tSkVJjN2rAto/n+Na/jx9ED6fQga+cADLsd 1nLBnkm1/7f85cFkYlWZ7HILdH4kUudd25vaav1Hf4XqULX1BaZhLYhW7GGnkZNYjapAN8eNmZCSxVbLSZtkLaOSgMfUw5/+/xqg+8+8fcmeJDDvQXK9BPei reOAdRBVcW/eG08q4X+pPN3UmzHX27QJHpIquqDoHCijag== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/28/20 5:45 AM, Tomasz Figa wrote: > On Thu, Jan 23, 2020 at 8:08 PM Hans Verkuil wrote: >> >> On 1/22/20 4:48 AM, Sergey Senozhatsky wrote: >>> On (20/01/22 11:18), Sergey Senozhatsky wrote: >>> [..] >>>>>> + * - >>>>>> + - __u32 >>>>>> - ``reserved``\ [1] >>>>>> - A place holder for future extensions. Drivers and applications >>>>>> - must set the array to zero. >>>>>> + must set the array to zero, unless application wants to specify >>>>>> + buffer management ``flags``. >>>>> >>>>> I think support for this flag should be signaled as a V4L2_BUF_CAP capability. >>>>> If the capability is not set, then vb2 should set 'flags' to 0 to preserve the >>>>> old 'Drivers and applications must set the array to zero' behavior. >>>> >>>> The patch set adds V4L2_BUF_CAP_SUPPORTS_CACHE_HINTS towards the end of the >>>> series, I guess I can shuffle the patches and change the wording here. >>> >>> Or I can add separate queue flag and V4L2_BUF_CAP: >>> >>> struct vb2_queue { >>> ... >>> allow_cache_hints:1 >>> + allow_consistency_hints:1 >>> ... >>> } >>> >>> and then have CAP_SUPPORTS_CACHE_HINTS/CAP_SUPPORTS_CONSISTENCY_HINTS. >> >> Don't these two go hand-in-hand? I.e. either neither are supported, or >> both are supported? If so, then one queue flag is sufficient. > > Cache sync hints are already part of the standard UAPI, so I think > there isn't any capability bit needed for them. These hints may exist, but they never worked. So I think a capability would be very useful. That said, they aren't > really tied to non-consistent MMAP buffers. Userspace using USERPTR > can also use them. OK, two separate capability bits is fine. Regards, Hans > > MMAP buffer consistency hint deserves a capability bit indeed. > > Best regards, > Tomasz >