Received: by 10.223.176.46 with SMTP id f43csp2025529wra; Sun, 21 Jan 2018 09:29:55 -0800 (PST) X-Google-Smtp-Source: AH8x225fQHU5VtT2SFu/QEdD4vxX3Lvjqjr4SX2Tmgv8BSiunN21p7DO2mlsT5oHsU6JGmgW2Qq5 X-Received: by 10.101.64.67 with SMTP id h3mr5007593pgp.168.1516555795762; Sun, 21 Jan 2018 09:29:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516555795; cv=none; d=google.com; s=arc-20160816; b=mzId8ij32PYof4LKJu4psfMwbPHf6lV5t280wB9+KX7Stcs+m82dVsMA8PYwYeObmJ XRumlmMovrl4sdReMxH/tM4/tAPRbvzQu9eFvvuQn2bsHPzU1Jjli2yqBoefxMmXGFgJ sPYFO2yWaEc7A5saXoxA3VVCKxmQjhzKNqrJchJosoD9o+7T3vSINwrs4HtqlO1CTtw5 /HVWGVsOR+zreKeNnIKXStyryZgdw53tZKD/s+EWPouNzf01W5WspANBUZfQgSC/ftdP W5YdNyiMB5ELUwIVfwE5m/GM2IYl/fUiSk+cxen2r+Q6or4l6OZmhiilXe3oc961i0Vf DJcw== 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=COM0Rx/8IsyZJodc1itCNdnjgjbqsNpjndrz2VPJpzM=; b=ohC55emW4M+lb4Zk9BUD5MSm4f50ElWqfhsgkexW+/k2MrgEK2/SkA91JqhgiGEdJ+ hMS7iEySV79BL4R9kib3avw9E51EatpErLb/z7n39slimKXQZTg8df5c/Y0vsUDP6dhl 9lpudVUekEuKd1qEc6X2yKE7X8/baEbjVsrwXoFZ01J8L+OSBR/UNaT8CeVYabg76jUj zmMDUfoejHQVWKIzSsoLBMJWK4COYQop6mRbNnZ5uHjm9+WIiwvzx+BCes/HDcib4fvK tU2/hhX5YkG3DstLkAjjgyX/Dbd1VLVyMTHPKqICDEb5dBjODD4rz7GCsB2jJgP3Y8Ur kZAQ== 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 s24-v6si2670085plp.220.2018.01.21.09.29.40; Sun, 21 Jan 2018 09:29:55 -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 S1751243AbeAUR3R (ORCPT + 99 others); Sun, 21 Jan 2018 12:29:17 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:45974 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750853AbeAUR3P (ORCPT ); Sun, 21 Jan 2018 12:29:15 -0500 Received: from w540 (unknown [IPv6:2001:b07:6442:1ac4:3997:a7b1:efcc:5c7c]) (Authenticated sender: jacopo@jmondi.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 5781DA80CB; Sun, 21 Jan 2018 18:29:09 +0100 (CET) Date: Sun, 21 Jan 2018 18:29:07 +0100 From: jacopo mondi To: Hans Verkuil Cc: Jacopo Mondi , laurent.pinchart@ideasonboard.com, magnus.damm@gmail.com, geert@glider.be, 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 v6 3/9] v4l: platform: Add Renesas CEU driver Message-ID: <20180121172907.GO24926@w540> References: <1516139101-7835-1-git-send-email-jacopo+renesas@jmondi.org> <1516139101-7835-4-git-send-email-jacopo+renesas@jmondi.org> <20180121095323.GL24926@w540> <55c3ab66-0886-4b2b-6842-ac07fc9138f3@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 Hans, On Sun, Jan 21, 2018 at 11:23:12AM +0100, Hans Verkuil wrote: > On 21/01/18 11:21, Hans Verkuil wrote: > > On 21/01/18 10:53, jacopo mondi wrote: > >> Hi Hans, > >> > >> On Fri, Jan 19, 2018 at 12:20:19PM +0100, Hans Verkuil wrote: > >>> static int ov7670_g_parm(struct v4l2_subdev *sd, struct v4l2_streamparm *parms) > >>> { > >>> struct v4l2_captureparm *cp = &parms->parm.capture; > >>> struct ov7670_info *info = to_state(sd); > >>> > >>> if (parms->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) > >>> return -EINVAL; > >>> > >>> And parms->type is CAPTURE_MPLANE. Just drop this test from the ov7670 driver > >>> in the g/s_parm functions. It shouldn't test for that since a subdev driver > >>> knows nothing about buffer types. > >>> > >> > >> I will drop that test in an additional patch part of next iteration of this series, > > > > Replace g/s_parm by g/s_frame_interval. Consider g/s_parm for subdev drivers as > > deprecated (I'm working on a patch series to replace all g/s_parm uses by > > g/s_frame_interval). > > Take a look here: > > https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=parm > > You probably want to use the patch 'v4l2-common: add g/s_parm helper functions' > for the new ceu driver in your patch series. Feel free to add it. Thanks, I have now re-based my series on top of your 'parm' branch, and now I have silenced those errors on bad frame interval. CEU g/s_parm now look like this: static int ceu_g_parm(struct file *file, void *fh, struct v4l2_streamparm *a) { struct ceu_device *ceudev = video_drvdata(file); int ret; ret = v4l2_g_parm(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, ceudev->sd->v4l2_sd, a); if (ret) return ret; a->parm.capture.readbuffers = 0; return 0; } Very similar to what you've done on other platform drivers in this commit: https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=parm&id=a58956ef45cebaa5ce43a5f740fe04517b24a853 I have a question though (please bear with me a little more :) I had to manually set a->parm.capture.readbuffers to 0 to silence the following error in v4l2_compliance (which I have now updated to the most recent remote HEAD): fail: v4l2-test-formats.cpp(1114): cap->readbuffers test VIDIOC_G/S_PARM: FAIL fail_on_test(cap->readbuffers > VIDEO_MAX_FRAME); if (!(node->g_caps() & V4L2_CAP_READWRITE)) fail_on_test(cap->readbuffers); else if (node->g_caps() & V4L2_CAP_STREAMING) fail_on_test(!cap->readbuffers); CEU does not support CAP_READWRITE, as it seems atmel-isc/isi do not, so v4l2-compliance wants to have readbuffers set to 0. I wonder why in the previously mentioned commit you didn't have to set readbuffers explicitly to 0 for atmel-isc/isi as I had to for CEU. Will v4l2-compliance fail if run on atmel-isc/isi with your commit, or am I missing something? Thanks j