Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp714050imm; Wed, 23 May 2018 04:30:08 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpySdPXWMznFHHyuiLODETIk6Nac7ywZgdN/Evn4HvSWB3VQNaY6jj7UpI9pO8EoC18eLSN X-Received: by 2002:a65:61a6:: with SMTP id i6-v6mr2017509pgv.88.1527075008889; Wed, 23 May 2018 04:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527075008; cv=none; d=google.com; s=arc-20160816; b=LgpQBkH2IjWm070zV+gusf2iGgR9UDRM7JYSSDwO4JyIc4R9AkaBsVZekeV1nIJAbC fTmqA0m9CpP8Nxrf4TrnRjjF9KRsPgaQkCYcS8vXe5l5dTCpsslhrVIhO01wjGqXoEwh XjjNUhO0D14jU8vjPobdk0e1ssgttSEjwUZDMRQxnYACndebnrHGHJ6aRHzPIxWIRCBv UfsVFRvf2W/E+RpAgtaEgUwbLcpQeHh6HT7H/JhbgudwQnkgUHnmV8WAmv5XV98oyIxb G5vBsbxI8T6HP/40xePUH71vl8CcRKvglu6MRtZuCC4ozsI4PjRMhgFhOuI6KnFED7uj Ww0w== 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:arc-authentication-results; bh=3PNlQpG9fx17NG7EFtDdlGCpGWpLXLlQTD3gP/k40+E=; b=taaC/Qld6E6R7C7Ux1m3JhU26gPP3ve/acxG6EcBlafBJ8t6jhFx2Xkszcm80yH/i/ FqaD4SAn0w0qvySp8Tdu2oKZGvRbTcEzhYL1jJitWTnNosdKWJxR9Y8dA6KPVJAmx6eE vhpS9+Mm6VGG2bFhwV1+6ACF9r+Svm+3OAOGprA6Yb6wkU0VGfw66zksASbxAXFCtm/3 Mhg+SIn4g3Mv8UPEQh/UnY+xHMlRPH9enpYNFx8KYiyLluAwEYfkOOcAnMydRhudBYMp PY5GeZIAxbRFw+aDSKqu5FuN7sDZXrn7JwD32gHrdj/z707yK81n9myTarNcrCVYKVNb NWDg== ARC-Authentication-Results: i=1; mx.google.com; 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 m19-v6si18248174pff.303.2018.05.23.04.29.54; Wed, 23 May 2018 04:30:08 -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; 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 S932639AbeEWL3J (ORCPT + 99 others); Wed, 23 May 2018 07:29:09 -0400 Received: from lb3-smtp-cloud7.xs4all.net ([194.109.24.31]:52747 "EHLO lb3-smtp-cloud7.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932531AbeEWL3F (ORCPT ); Wed, 23 May 2018 07:29:05 -0400 Received: from [IPv6:2001:983:e9a7:1:6dcf:7d19:725:579d] ([IPv6:2001:983:e9a7:1:6dcf:7d19:725:579d]) by smtp-cloud7.xs4all.net with ESMTPA id LRwzfudDd8U07LRx0fvLc2; Wed, 23 May 2018 13:29:04 +0200 Subject: Re: [PATCH v10 08/16] v4l: mark unordered formats To: Ezequiel Garcia , linux-media@vger.kernel.org Cc: kernel@collabora.com, Mauro Carvalho Chehab , Shuah Khan , Pawel Osciak , Alexandre Courbot , Sakari Ailus , Brian Starkey , linux-kernel@vger.kernel.org, Gustavo Padovan References: <20180521165946.11778-1-ezequiel@collabora.com> <20180521165946.11778-9-ezequiel@collabora.com> <2df0ec97-9e0f-8fc3-1481-ac0a72e52e4d@xs4all.nl> <70b7ddaf685c2fc08dfd1caaab45bb0cc9c99a21.camel@collabora.com> From: Hans Verkuil Message-ID: Date: Wed, 23 May 2018 13:29:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <70b7ddaf685c2fc08dfd1caaab45bb0cc9c99a21.camel@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMlcjNgTcjBnfday/RRCwLxdkfuaYg2uFWroDTPP5tAXkbNYRkevTGx1joHJyAr3+j9D+sgJ7GjnS6K6eXQhZFXWbkXNgQ1xylflzPmfOXcShE/v/ucX LZFhaLZYjvuRNZiMg2CjixRuxQisJcVlxoH0v+D43pe5VMvrxHE8+lG1GpraoBNgKj/W9MqtJd4hdz2hSBsRqByxd76Ua/REMe4/9prqzI0BckghKc27VBBz s7s/RmnWZkKFppHhSom4tKMuOKD/rpZhJoOAnsrLEy4u1Mw2LJK9eFOZW7HhitVnVWO4AniYG10xKXE5xA5Fnlmt9LFQzFYq5L0+p+ko1E2PwBsjzcUZjRJp jhKmbCNA86wY+xgYDZmThCT5KWXT/c6xGkom+noiM5ehXN0wuTzoQDEVQyIDmHPEim3gQVmG3DiHWttG8KjjWje+Gql+/XEmkstGZ598xVwXMiABM3KMFdaz tR5WoQsZpj9FlSXbfHPdmFVJ3tofFwaN9gPxMg3kTgJPybCr5XYzqpcwvSpbaHVp9+x/szmU2Ee0D0+K5cSXuJbV0dE+w5L4yk9seHl/axIE7tkg+yiwpZkc zX6saR6GDyjHIhkUYyn1OPu5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/05/18 12:30, Ezequiel Garcia wrote: > On Tue, 2018-05-22 at 13:55 +0200, Hans Verkuil wrote: >> On 21/05/18 18:59, Ezequiel Garcia wrote: >>> From: Gustavo Padovan >>> >>> Now that we've introduced the V4L2_FMT_FLAG_UNORDERED flag, >>> mark the appropriate formats. >>> >>> v2: Set unordered flag before calling the driver callback. >>> >>> Signed-off-by: Gustavo Padovan >>> Signed-off-by: Ezequiel Garcia >>> --- >>> drivers/media/v4l2-core/v4l2-ioctl.c | 74 +++++++++++++++++++++++++++--------- >>> 1 file changed, 57 insertions(+), 17 deletions(-) >>> >>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c >>> index f48c505550e0..2135ac235a96 100644 >>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c >>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c >>> @@ -1102,6 +1102,27 @@ static int v4l_enumoutput(const struct v4l2_ioctl_ops *ops, >>> return ops->vidioc_enum_output(file, fh, p); >>> } >>> >>> +static void v4l_fill_unordered_fmtdesc(struct v4l2_fmtdesc *fmt) >>> +{ >>> + switch (fmt->pixelformat) { >>> + case V4L2_PIX_FMT_MPEG: >>> + case V4L2_PIX_FMT_H264: >>> + case V4L2_PIX_FMT_H264_NO_SC: >>> + case V4L2_PIX_FMT_H264_MVC: >>> + case V4L2_PIX_FMT_H263: >>> + case V4L2_PIX_FMT_MPEG1: >>> + case V4L2_PIX_FMT_MPEG2: >>> + case V4L2_PIX_FMT_MPEG4: >>> + case V4L2_PIX_FMT_XVID: >>> + case V4L2_PIX_FMT_VC1_ANNEX_G: >>> + case V4L2_PIX_FMT_VC1_ANNEX_L: >>> + case V4L2_PIX_FMT_VP8: >>> + case V4L2_PIX_FMT_VP9: >>> + case V4L2_PIX_FMT_HEVC: >>> + fmt->flags |= V4L2_FMT_FLAG_UNORDERED; >> >> Please add a break here. This prevents potential future errors if new cases >> are added below this line. >> > > Sure. > >>> + } >>> +} >>> + >>> static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) >>> { >>> const unsigned sz = sizeof(fmt->description); >>> @@ -1310,61 +1331,80 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) >>> >>> if (descr) >>> WARN_ON(strlcpy(fmt->description, descr, sz) >= sz); >>> - fmt->flags = flags; >>> + fmt->flags |= flags; >>> } >>> >>> -static int v4l_enum_fmt(const struct v4l2_ioctl_ops *ops, >>> - struct file *file, void *fh, void *arg) >>> -{ >>> - struct v4l2_fmtdesc *p = arg; >>> - int ret = check_fmt(file, p->type); >>> >>> - if (ret) >>> - return ret; >>> - ret = -EINVAL; >>> +static int __vidioc_enum_fmt(const struct v4l2_ioctl_ops *ops, >>> + struct v4l2_fmtdesc *p, >>> + struct file *file, void *fh) >>> +{ >>> + int ret = 0; >>> >>> switch (p->type) { >>> case V4L2_BUF_TYPE_VIDEO_CAPTURE: >>> if (unlikely(!ops->vidioc_enum_fmt_vid_cap)) >>> break; >>> - ret = ops->vidioc_enum_fmt_vid_cap(file, fh, arg); >>> + ret = ops->vidioc_enum_fmt_vid_cap(file, fh, p); >>> break; >>> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE: >>> if (unlikely(!ops->vidioc_enum_fmt_vid_cap_mplane)) >>> break; >>> - ret = ops->vidioc_enum_fmt_vid_cap_mplane(file, fh, arg); >>> + ret = ops->vidioc_enum_fmt_vid_cap_mplane(file, fh, p); >>> break; >>> case V4L2_BUF_TYPE_VIDEO_OVERLAY: >>> if (unlikely(!ops->vidioc_enum_fmt_vid_overlay)) >>> break; >>> - ret = ops->vidioc_enum_fmt_vid_overlay(file, fh, arg); >>> + ret = ops->vidioc_enum_fmt_vid_overlay(file, fh, p); >>> break; >>> case V4L2_BUF_TYPE_VIDEO_OUTPUT: >>> if (unlikely(!ops->vidioc_enum_fmt_vid_out)) >>> break; >>> - ret = ops->vidioc_enum_fmt_vid_out(file, fh, arg); >>> + ret = ops->vidioc_enum_fmt_vid_out(file, fh, p); >>> break; >>> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE: >>> if (unlikely(!ops->vidioc_enum_fmt_vid_out_mplane)) >>> break; >>> - ret = ops->vidioc_enum_fmt_vid_out_mplane(file, fh, arg); >>> + ret = ops->vidioc_enum_fmt_vid_out_mplane(file, fh, p); >>> break; >>> case V4L2_BUF_TYPE_SDR_CAPTURE: >>> if (unlikely(!ops->vidioc_enum_fmt_sdr_cap)) >>> break; >>> - ret = ops->vidioc_enum_fmt_sdr_cap(file, fh, arg); >>> + ret = ops->vidioc_enum_fmt_sdr_cap(file, fh, p); >>> break; >>> case V4L2_BUF_TYPE_SDR_OUTPUT: >>> if (unlikely(!ops->vidioc_enum_fmt_sdr_out)) >>> break; >>> - ret = ops->vidioc_enum_fmt_sdr_out(file, fh, arg); >>> + ret = ops->vidioc_enum_fmt_sdr_out(file, fh, p); >>> break; >>> case V4L2_BUF_TYPE_META_CAPTURE: >>> if (unlikely(!ops->vidioc_enum_fmt_meta_cap)) >>> break; >>> - ret = ops->vidioc_enum_fmt_meta_cap(file, fh, arg); >>> + ret = ops->vidioc_enum_fmt_meta_cap(file, fh, p); >>> break; >>> } >>> + return ret; >>> +} >>> + >>> +static int v4l_enum_fmt(const struct v4l2_ioctl_ops *ops, >>> + struct file *file, void *fh, void *arg) >>> +{ >>> + struct v4l2_fmtdesc *p = arg; >>> + int ret = check_fmt(file, p->type); >>> + >>> + if (ret) >>> + return ret; >>> + ret = -EINVAL; >> >> Why set ret when it is overwritten below? >> > > Oops, seems to be some leftover code. > >>> + >>> + ret = __vidioc_enum_fmt(ops, p, file, fh); >>> + if (ret) >>> + return ret; >> >> Huh? Why call the driver twice? As far as I can see you can just drop >> these three lines above. >> >> > > Well, because I thought this was the outcome of v9 [1]. Let me quote you: > > "" > I realized that this is a problem since this function is called *after* > the driver. So the driver has no chance to clear this flag if it knows > that the queue is always ordered. > "" > > So, we first call the driver to get struct v4l2_fmtdesc pixelformat field > filled by the driver, then we call v4l_fill_unordered_fmtdesc() > to set FLAG_UNORDERED if needed, and finally we call the driver again > so it can clear the FLAG_UNORDERED. > > Does that make sense? Not what I meant. v4l_fill_unordered_fmtdesc() should be called first, then the driver (which can now fiddle with the flag if it wants to) and finally v4l_fill_fmtdesc(p) is called. Drivers that support these compressed formats need to be checked though: they shouldn't overwrite flags unconditionally. Regards, Hans > > [1] https://lkml.org/lkml/2018/5/7/349 >