Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1016741ybb; Fri, 3 Apr 2020 16:29:14 -0700 (PDT) X-Google-Smtp-Source: APiQypJd8kvSlF0zePXJAcdgH+SvpWIxmUuddDZ1kiwG/VRayusmalJOOh486Bs0FmfXB/jkSzZ8 X-Received: by 2002:a05:6830:1f39:: with SMTP id e25mr8700594oth.135.1585956554273; Fri, 03 Apr 2020 16:29:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585956554; cv=none; d=google.com; s=arc-20160816; b=hQqCUeCk7i1kvRkpPa7cSsWBsA0Xm0cnL63doT7brnZ5qKmdUtYphX8wtzjl1LpqqK mjixjAuFus8l3z06ZpyXPFIgWIKYhrp9H5COCSXo/x/UxWuwPOHN7gtcjb3ok1Xgz/Qh IaRlc1ScX8M9cIoh+Q6Z2rAKLjGoNcqrW45TD9E2AMqXCoF/s7kNp7M4UJRhrjxS2Kex 3Mp/fMtbBTUJ98k5fczAKDDztuEvc9T1fNNsQqpsZZcRLISRbJGR/rw0kGI0bDQ7OC2w CDwQktQR3LaGlD/ARIDxoXKi8/f6Y1ahnohbVVqSgtdYzWq1ptZow4KM31+oKi+HJcRb hUFw== 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; bh=LIwMIcDdd7626p56s+GW8bVY68MNxPUGJBXwAlQxHsQ=; b=qyhcq2/eQncPPaulZ+1Na+giaKMztwczUQLTkQ6WjA8nK9WdnzC0Y3W2acU2qNupz/ rFkiSQZfvSho5UbYCgKwylmCPmngsiOzukvqqgME8rzNADf88/Hsce+wdNrwkzPaVAdo mRrvzo5D+bBQUQ8Ivb4uRnP4Yx0YrwMtPTgwV434TyZr/yQSU5BHHZOygiTBorBMZCev kj7d/znBSQIOUZnE0RUKI98E5gaPihtZ81IMAHUdLETVsVjqf8telPURu1VufbuaSdMt ltwp4kbBkFWDaUAfG72d1YZrlNG5ZCpcNQ2W/ymHl7xV6UjDtXY6IAAV8lLMiriG7gWS SNWQ== 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 s27si4467662otg.229.2020.04.03.16.29.00; Fri, 03 Apr 2020 16:29:14 -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 S1728432AbgDCX2c (ORCPT + 99 others); Fri, 3 Apr 2020 19:28:32 -0400 Received: from retiisi.org.uk ([95.216.213.190]:56404 "EHLO hillosipuli.retiisi.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726899AbgDCX2c (ORCPT ); Fri, 3 Apr 2020 19:28:32 -0400 Received: from valkosipuli.localdomain (valkosipuli.retiisi.org.uk [IPv6:2a01:4f9:c010:4572::80:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id 78475634C8C; Sat, 4 Apr 2020 02:27:37 +0300 (EEST) Received: from sailus by valkosipuli.localdomain with local (Exim 4.92) (envelope-from ) id 1jKViq-0001ju-HC; Sat, 04 Apr 2020 02:27:36 +0300 Date: Sat, 4 Apr 2020 02:27:36 +0300 From: Sakari Ailus To: Robert Foss Cc: Maxime Ripard , Dongchun Zhu , Fabio Estevam , Andy Shevchenko , Tomasz Figa , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-kernel , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Subject: Re: [PATCH v6 1/3] media: dt-bindings: ov8856: Document YAML bindings Message-ID: <20200403232736.GA6127@valkosipuli.retiisi.org.uk> References: <20200331133346.372517-1-robert.foss@linaro.org> <20200331133346.372517-2-robert.foss@linaro.org> <20200401080705.j4goeqcqhoswhx4u@gilmour.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robert, On Thu, Apr 02, 2020 at 12:10:00PM +0200, Robert Foss wrote: > Hey Maxime, > > On Wed, 1 Apr 2020 at 10:07, Maxime Ripard wrote: > > > > Hi, > > > > On Tue, Mar 31, 2020 at 03:33:44PM +0200, Robert Foss wrote: > > > From: Dongchun Zhu > > > > > > This patch adds documentation of device tree in YAML schema for the > > > OV8856 CMOS image sensor. > > > > > > Signed-off-by: Dongchun Zhu > > > Signed-off-by: Robert Foss > > > --- > > > > > > - Changes since v5: > > > * Add assigned-clocks and assigned-clock-rates > > > * robher: dt-schema errors > > > > > > - Changes since v4: > > > * Fabio: Change reset-gpio to GPIO_ACTIVE_LOW, explain in description > > > * Add clock-lanes property to example > > > * robher: Fix syntax error in devicetree example > > > > > > - Changes since v3: > > > * robher: Fix syntax error > > > * robher: Removed maxItems > > > * Fixes yaml 'make dt-binding-check' errors > > > > > > - Changes since v2: > > > Fixes comments from from Andy, Tomasz, Sakari, Rob. > > > * Convert text documentation to YAML schema. > > > > > > - Changes since v1: > > > Fixes comments from Sakari, Tomasz > > > * Add clock-frequency and link-frequencies in DT > > > > > > .../devicetree/bindings/media/i2c/ov8856.yaml | 150 ++++++++++++++++++ > > > MAINTAINERS | 1 + > > > 2 files changed, 151 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ov8856.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml > > > new file mode 100644 > > > index 000000000000..beeddfbb8709 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml > > > @@ -0,0 +1,150 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > +# Copyright (c) 2019 MediaTek Inc. > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/media/i2c/ov8856.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Omnivision OV8856 CMOS Sensor Device Tree Bindings > > > + > > > +maintainers: > > > + - Ben Kao > > > + - Dongchun Zhu > > > + > > > +description: |- > > > + The Omnivision OV8856 is a high performance, 1/4-inch, 8 megapixel, CMOS > > > + image sensor that delivers 3264x2448 at 30fps. It provides full-frame, > > > + sub-sampled, and windowed 10-bit MIPI images in various formats via the > > > + Serial Camera Control Bus (SCCB) interface. This chip is programmable > > > + through I2C and two-wire SCCB. The sensor output is available via CSI-2 > > > + serial data output (up to 4-lane). > > > + > > > +properties: > > > + compatible: > > > + const: ovti,ov8856 > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + clocks: > > > + maxItems: 1 > > > + > > > + clock-names: > > > + description: > > > + Input clock for the sensor. > > > + items: > > > + - const: xvclk > > > + > > > + clock-frequency: > > > + description: > > > + Frequency of the xvclk clock in Hertz. > > > > We also had that discussion recently for another omnivision sensor > > (ov5645 iirc), but what is clock-frequency useful for? > > > > It seems that the sensor is passed in clocks, so if you need to > > retrieve the clock rate you should use the clock API instead. > > > > Looking at the driver, it looks like it first retrieves the clock, set > > it to clock-frequency, and then checks that this is OV8856_XVCLK_19_2 > > (19.2 MHz). > > As far as I understand it, 19.2MHz is requirement for the sensor mode > that currently defaults to. Some modes require higher clock speeds > than this however. It's very system specific. Either way, bindings should not assume a particular driver implementation. > > > > > The datasheet says that the sensor can have any frequency in the 6 - > > 27 MHz range, so this is a driver limitation and should be set in the > > driver using the clock API, and you can always bail out if it doesn't > > provide a rate that is not acceptable for the drivers assumption. > > > > In any case, you don't need clock-frequency here... > > So your suggestion is that we remove all clocks-rate properties, and > replace the clk_get_rate() calls in the driver with clk_set_rate() > calls for the desired frequencies? The driver shouldn't set the rate here unless it gets it from DT (but that was not the intention). So the driver should get the frequency instead. -- Regards, Sakari Ailus