Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp177523ybb; Tue, 24 Mar 2020 19:34:22 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtr3NUtFcXQu04m3dChy30cuw7pVJBCUVYeK4Bv+MXceAAE8C64nhEJSCttha+om3q3BPf3 X-Received: by 2002:aca:f582:: with SMTP id t124mr972471oih.17.1585103661914; Tue, 24 Mar 2020 19:34:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585103661; cv=none; d=google.com; s=arc-20160816; b=vTw4UbJxp6BGw9w89OXf1KP3Mguazo5tEDrZl5YxBqJS/1F7yXOIuTZgzlYvhrT2Ns v3AH14SAx3ExW8P2mB+REeQ6c/GevXp2yNRJr0FrpMqDR9QAWeIeShv66VMnCxw1NAMo X2JBbiBtsuEamdEqU3TaiIYXPYfVdf4TI7WS1n/os8LHQ/v+DkFLHGgc2JM46Jkx4Tn0 rBx/HIjDuogggCevtXeOOQxB/qFXZtqp9SaKizSGWDvMwwmwzWZhFNYpPfAmzDGdgZet njlqRKLMB/DDtPmpvz4/s2PU8c2mHZxf6HwI5TAd9lxD8FsmtLrtvBWjJ1QLg2KRuajb ZIwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=L0byPyKsVMZgh2TI47PblbS4cxi4k/gb3aMdbr//qWM=; b=rbqr7CqRsks3Wh5rZp21eD7LsagghdOSfj7uBC5lxZ7/ZO91pCWJiOubS32hn7bj1Y PK9Ydeha/OEY2D5MaXpTSZA40sDLOMbbuM0WvbvcXzKWAwPldw4tJ9Wl3ARqRiqAQ7k3 VgiyRgPFmD6UyubZfyfcbxWGStnEybRziNm9dpZ82O2TEOG3VfCyZYKBry9YB+y0rf/T sHqJJVsn5olw7Ob3Qy2zapAIaZP3i3MM5q1mEkDdiSoGkbPYfo5y2YI0fqsu1NTX7bzr TpMEvUGA4KaV7uU8MpeUPgwJn1cgLMHDdxCyyUSR9enPhIRSzSXJoMAxZowd7LHnoqP1 vB4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=MVkLuY0q; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e22si1138240oob.87.2020.03.24.19.34.10; Tue, 24 Mar 2020 19:34:21 -0700 (PDT) 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=@chromium.org header.s=google header.b=MVkLuY0q; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727325AbgCYCcx (ORCPT + 99 others); Tue, 24 Mar 2020 22:32:53 -0400 Received: from mail-pf1-f172.google.com ([209.85.210.172]:46681 "EHLO mail-pf1-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727305AbgCYCcw (ORCPT ); Tue, 24 Mar 2020 22:32:52 -0400 Received: by mail-pf1-f172.google.com with SMTP id q3so276649pff.13 for ; Tue, 24 Mar 2020 19:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=L0byPyKsVMZgh2TI47PblbS4cxi4k/gb3aMdbr//qWM=; b=MVkLuY0qbCwRfXrKb6jF3fByfM+IIR1jD6Eetdv5shDt4UFneVZfWXgc7E1r3AL7gN VtXM0qRKvJukcN70k0M+sSaTuDKU61RcT25oiOU5G6tReaQ2RkRcFHPSFN+C86badtHc eilCyY46wrMdqs+nzxEHoWV4ff+0ak97PKq6c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=L0byPyKsVMZgh2TI47PblbS4cxi4k/gb3aMdbr//qWM=; b=sxbourVPrPHiwwL7KXlg+CyeqooroutmKSHDcCA99Hka2ap8FBdG5OLriLjqWZgQmg VMKHFLhSG0vkF75VCUx52Mq/HraY/rzcWhO+yzPkgc40LhBQFVXENIFIkej7V1dCxd4W Ke5rN4MlP8vh6p8PhhQwlHtZRSs/S7rF6+INhwNKeb94O76KJXjzJ+dyZ7df2aS3qflZ kb3gaLMkrlQ4Y4rdF8HhAGCW6MOjlGVT2K7C9ZIkebIz8uNLl2sj6AgU9mZmo2iKYjD/ e4vFLZ9GdwHicT3W2cO0RM3bN43KYZk0kfIxYJVOWQi279tTcePD3/8APCTEksTV/Rnw Ozyg== X-Gm-Message-State: ANhLgQ0BB7hS7oioZ3b68od8CxK7KZQ//pN5+syG/KxTadGnfNpklXFM dX1FIl3Oq2npJlX+SN+xwxX+0g== X-Received: by 2002:a65:6244:: with SMTP id q4mr842322pgv.84.1585103570795; Tue, 24 Mar 2020 19:32:50 -0700 (PDT) Received: from localhost ([2401:fa00:8f:203:5bbb:c872:f2b1:f53b]) by smtp.gmail.com with ESMTPSA id e3sm15638759pgm.15.2020.03.24.19.32.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2020 19:32:50 -0700 (PDT) Date: Wed, 25 Mar 2020 11:32:48 +0900 From: Sergey Senozhatsky To: Ezequiel Garcia Cc: Sergey Senozhatsky , Dafna Hirschfeld , Hans Verkuil , Tomasz Figa , Mauro Carvalho Chehab , Kyungmin Park , Marek Szyprowski , Sakari Ailus , Laurent Pinchart , Pawel Osciak , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Helen Koike , nicolas.dufresne@collabora.co.uk Subject: Re: [PATCHv4 04/11] videobuf2: add queue memory consistency parameter Message-ID: <20200325023248.GA241329@google.com> References: <20200302041213.27662-1-senozhatsky@chromium.org> <20200302041213.27662-5-senozhatsky@chromium.org> <6e4fc7f9-0068-92ff-77d7-9c77c047f3db@collabora.com> <20200324023909.GA201720@google.com> <1187a3f660b092d8a9d5437445155edfc0744a4f.camel@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1187a3f660b092d8a9d5437445155edfc0744a4f.camel@collabora.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (20/03/24 07:17), Ezequiel Garcia wrote: [..] > > > > +static void set_queue_consistency(struct vb2_queue *q, bool consistent_mem) > > > > +{ > > > > + if (!vb2_queue_allows_cache_hints(q)) > > > > + return; > > > > + > > > > + if (consistent_mem) > > > > + q->dma_attrs &= ~DMA_ATTR_NON_CONSISTENT; > > > > + else > > > > + q->dma_attrs |= DMA_ATTR_NON_CONSISTENT; > > > > +} > > > > + > > > > int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory, > > > > - unsigned int *count) > > > > + bool consistent_mem, unsigned int *count) > > > You extended the vb2_core_reqbufs accepting a new boolean that > > > is decided according to the setting of the V4L2_FLAG_MEMORY_NON_CONSISTENT > > > but in the future some other flags might be added, and so I think it > > > is better to replace the boolean with a u32 consisting of all the flags. > > > > Don't have any objections. Can change the `bool' to `u32'. > > > > or maybe an enum instead? That would help get a cleaner > interface. Hmm, interesting. The flags in question can be from different, unrelated groups (types), controlling various parts of the stack. Not necessarily all of them are memory_consistency related. We can, for instance, pass some additional flags to underlying memory allocators (contig, sg), etc. E.g. enum MEMORY_ATTR { MEM_NON_CONSISTENT, ... }; enum VMALLOC_ALLOCATOR_ATTR { DO_A_BARREL_ROLL, ... }; enum DMA_SG_ALLOCATOR_ATTR { WRITEBACK_TO_TAPE_DEVICE, ... }; enum DMA_CONTIG_ALLOCATOR_ATTR { PREFER_HTTPS, ... }; and so on. We maybe can keep all of those in one enum (umm, what should be the name?), and then either make sure that all of them are proper powers of two enum AUX_FLAGS { MEM_NON_CONSISTENT = (1 << 0), DO_A_BARREL_ROLL = (1 << 1), WRITEBACK_TO_TAPE_DEVICE = (1 << 2), PREFER_HTTPS = (1 << 3), }; or enum AUX_FLAGS { MEM_NON_CONSISTENT = 0, DO_A_BARREL_ROLL, WRITEBACK_TO_TAPE_DEVICE, PREFER_HTTPS, }; and make sure that those are not flags, but bits. IOW, if (flags & BIT(MEM_NON_CONSISTENT)). What do others think? -ss