Received: by 10.223.185.116 with SMTP id b49csp1838486wrg; Thu, 22 Feb 2018 04:05:48 -0800 (PST) X-Google-Smtp-Source: AH8x227W9/xh0fsz8USri0tRELhTa9d6xWqAhpJJ8Asqh0zJe90+iCRqskLauN+Bc0iJX0gD5+Y+ X-Received: by 10.101.71.202 with SMTP id f10mr5393222pgs.91.1519301148658; Thu, 22 Feb 2018 04:05:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519301148; cv=none; d=google.com; s=arc-20160816; b=dQKhhIAjUAqMBNnfD2K6XQH3r0LY9VxjXlVjpJatIMuXEb7FFZun4WNTm6XFTNCmis 5/e+3O483QM61N+uXL7f34/aGhNJXt3ihoaTnBpkQDMWCI0YPMDRi8/8gsWPm9DIoNkb GaFF8bgmx6TMmoXghaegeBenflCazjovRZVBplAmLLpleA1/S+dXAW6QHMHa+MvceRDr jPFuUnj4MthrODKTai36WFvvT6vYR6gxcgluSOMy6fy88jvwpsYElCikhEBR0aSAoq3o XH1T6+k3l5VQIc8Vhd34pbVCB5o7ABOIvL1t1vr5X1ZagzKeoUC/zLvlKN0yXJOWujc0 2ptw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=S5+H/Rm9TsJoBBqEFU6HKrR4DtvqnZ4JXgKChEo3en4=; b=OqZUuHYCM4MTdVjXIcL8XARsHei+e845pjncNurs35F1sW4ygcAwBJ0LzQAL0LdnPz LUCbrrkby9pn4QiKM5mdeb9CvgDDtZ4zpRsp1M7iWZkdDke6GzxOEFfsJsAbu86XY4vu M49N/RNIcM07PdecLIr+P3e4HWyauJrRQB98aaDFOnnQ+9qgZ26gWwbfWDQqTef23Sem JWqDxJcuseK4+h2uqKBb79Td3pb10ZV/5Sf7TITV4c5FuH1ZvLCTZuezJ+CeB/88n6Xd iHgziA8G0BBGs19+NyVDCcMw0WKQLW2+qx3u8Os78l5RijNskHRFeQqiRjfiF+A+mdXd Pg1Q== 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 s16-v6si1412980plr.109.2018.02.22.04.05.11; Thu, 22 Feb 2018 04:05:48 -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; 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 S932472AbeBVMEX (ORCPT + 99 others); Thu, 22 Feb 2018 07:04:23 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:41053 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932444AbeBVMEU (ORCPT ); Thu, 22 Feb 2018 07:04:20 -0500 Received: from w540 (unknown [IPv6:2001:b07:6442:1ac4:3969:b0e2:8dc9:48c3]) (Authenticated sender: jacopo@jmondi.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 277C8A80ED; Thu, 22 Feb 2018 13:04:13 +0100 (CET) Date: Thu, 22 Feb 2018 13:04:12 +0100 From: jacopo mondi To: Laurent Pinchart Cc: Jacopo Mondi , magnus.damm@gmail.com, geert@glider.be, hverkuil@xs4all.nl, mchehab@kernel.org, festevam@gmail.com, sakari.ailus@iki.fi, robh+dt@kernel.org, mark.rutland@arm.com, pombredanne@nexb.com, linux-renesas-soc@vger.kernel.org, linux-media@vger.kernel.org, linux-sh@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 11/11] media: i2c: ov7670: Fully set mbus frame fmt Message-ID: <20180222120412.GL7203@w540> References: <1519059584-30844-1-git-send-email-jacopo+renesas@jmondi.org> <1963190.TI9O1pFqZp@avalon> <20180220085857.GC7203@w540> <56271779.hLAmkO6BAC@avalon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56271779.hLAmkO6BAC@avalon> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laurent, On Wed, Feb 21, 2018 at 10:28:06PM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > On Tuesday, 20 February 2018 10:58:57 EET jacopo mondi wrote: > > On Mon, Feb 19, 2018 at 09:19:32PM +0200, Laurent Pinchart wrote: > > > On Monday, 19 February 2018 18:59:44 EET Jacopo Mondi wrote: > > >> The sensor driver sets mbus format colorspace information and sizes, > > >> but not ycbcr encoding, quantization and xfer function. When supplied > > >> with an badly initialized mbus frame format structure, those fields > > >> need to be set explicitly not to leave them uninitialized. This is > > >> tested by v4l2-compliance, which supplies a mbus format description > > >> structure and checks for all fields to be properly set. > > >> > > >> Without this commit, v4l2-compliance fails when testing formats with: > > >> fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff > > >> > > >> Signed-off-by: Jacopo Mondi > > >> --- > > >> > > >> drivers/media/i2c/ov7670.c | 4 ++++ > > >> 1 file changed, 4 insertions(+) > > >> > > >> diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c > > >> index 25b26d4..61c472e 100644 > > >> --- a/drivers/media/i2c/ov7670.c > > >> +++ b/drivers/media/i2c/ov7670.c > > >> @@ -996,6 +996,10 @@ static int ov7670_try_fmt_internal(struct > > >> v4l2_subdev > > >> *sd, fmt->height = wsize->height; > > >> > > >> fmt->colorspace = ov7670_formats[index].colorspace; > > > > > > On a side note, if I'm not mistaken the colorspace field is set to SRGB > > > for all entries. Shouldn't you hardcode it here and remove the field ? > > > > > >> + fmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; > > >> + fmt->quantization = V4L2_QUANTIZATION_DEFAULT; > > >> + fmt->xfer_func = V4L2_XFER_FUNC_DEFAULT; > > > > > > How about setting the values explicitly instead of relying on defaults ? > > > That would be V4L2_YCBCR_ENC_601, V4L2_QUANTIZATION_LIM_RANGE and > > > V4L2_XFER_FUNC_SRGB. And could you then check a captured frame to see if > > > the sensor outputs limited or full range ? > > > > This actually makes me wonder if those informations (ycbcb_enc, > > quantization and xfer_func) shouldn't actually be part of the > > supported format list... I blindly added those default fields in the > > try_fmt function, but I doubt they applies to all supported formats. > > > > Eg. the sensor supports YUYV as well as 2 RGB encodings (RGB444 and > > RGB 565) and 1 raw format (BGGR). I now have a question here: > > > > 1) ycbcr_enc transforms non-linear R'G'B' to Y'CbCr: does this > > applies to RGB and raw formats? I don't think so, and what value is > > the correct one for the ycbcr_enc field in this case? I assume > > xfer_func and quantization applies to all formats instead.. > > There's no encoding for RGB formats if I understand things correctly, so I'd > set ycbcr_enc to V4L2_YCBCR_ENC_DEFAULT. The transfer function and the > quantization apply to all formats, but I'd be surprised to find a sensor > outputting limited range for RGB. Ack, we got the same understanding for RGB formats. I wonder if for those formats we wouldn't need a V4L2_YCBCR_ENC_NONE or similar... > > Have you been able to check whether the sensor outputs limited range of full > range YUV ? If it outputs full range you can hardcode quantization to > V4L2_QUANTIZATION_FULL_RANGE for all formats. In YUYV mode, I see values > 0xf0 ( > 240, which is the max value for CbCr samples in limited quantization range), so I assume quantization is full range. Actually the hardest part here was having a white enough surface to point the sensor to :) Thanks j > > > >> info->format = *fmt; > > >> > > >> return 0; > > -- > Regards, > > Laurent Pinchart >