From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F965438FFB; Tue, 5 May 2026 10:15:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777976117; cv=none; b=WUBLzz2Nf3vl5Ngu7ztihubEnMUIjI52qVHuojnX+thdbAUfuQv6E5C3SbXEcwS1Ayb213JqPkYNKlGUpOgBdtxairwgxrCv85ZqkH3XzZaDBHvWyxNU7iLXpK0Wdq5IKDNek5nS+2oER0M/p7w9hvDFwPtoMdH+5QJvMoWZ7cY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777976117; c=relaxed/simple; bh=irhwqt3pKWI8A9+c4uATwd1lfeQj1Qp64GK5X6PBU6M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Gf1UfcriNl9ReJLFWahOVE2/WAH4PhjcKgaRQyPcOisUGYseC2JrCGIKnPsMUgLSh5Xr7CZ8jW/f/QC2kFTEJa/YKqedxQ/oDVCYV8kNSKtNLwSvON0AIe5BxR2PBmIVzQh0J05lM3vg7jdw6NVZA0iSySTDiqofgRlCSIo8fDo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=QtJKsZHW; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="QtJKsZHW" Received: from killaraus.ideasonboard.com (2001-14ba-703d-e500--2a1.rev.dnainternet.fi [IPv6:2001:14ba:703d:e500::2a1]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id B2137874; Tue, 5 May 2026 12:15:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1777976104; bh=irhwqt3pKWI8A9+c4uATwd1lfeQj1Qp64GK5X6PBU6M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QtJKsZHWMFVaYqitfZJGvVeX7ouWbbMSaaLfgMOAMxOO3NO+WlmzNkXqGrNDrZKoy m2hurIMNnbwPRNxF76UutfbzPLtXgj0eG17LI5SGv0fuUuZy/LQRknnx9Qsul/oS0f ZjGVbsfozGKrEje54UWlTMV5yHjDhSYPZvJA4xT8= Date: Tue, 5 May 2026 13:15:05 +0300 From: Laurent Pinchart To: Alexander Shiyan Cc: linux-media@vger.kernel.org, Isaac Scott , Dave Stevenson , Dongcheng Yan , devicetree@vger.kernel.org, Mauro Carvalho Chehab , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sakari Ailus , Hans Verkuil , Hans de Goede , Vladimir Zapolskiy , Mehdi Djait , Benjamin Mugnier , Bryan O'Donoghue , Jingjing Xiong , Svyatoslav Ryhel Subject: Re: [RFC PATCH v3 1/2] dt-bindings: media: i2c: Add onsemi AR0234 image sensor binding Message-ID: <20260505101505.GB1547435@killaraus.ideasonboard.com> References: <20260306103614.3208182-1-eagle.alexander923@gmail.com> <20260306103614.3208182-2-eagle.alexander923@gmail.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260306103614.3208182-2-eagle.alexander923@gmail.com> Hi Alexander, Thank you for the patch. On Fri, Mar 06, 2026 at 01:36:13PM +0300, Alexander Shiyan wrote: > Add devicetree binding for the onsemi AR0234 CMOS image sensor. > > Signed-off-by: Alexander Shiyan > --- > .../bindings/media/i2c/onnn,ar0234.yaml | 109 ++++++++++++++++++ > 1 file changed, 109 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/i2c/onnn,ar0234.yaml > > diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,ar0234.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,ar0234.yaml > new file mode 100644 > index 000000000000..d93fa99e6535 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/i2c/onnn,ar0234.yaml > @@ -0,0 +1,109 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/i2c/onnn,ar0234.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ON Semiconductor AR0234 1/2.6-inch CMOS Digital Image Sensor > + > +description: > + The AR0234 is a 1/2.6-inch CMOS digital image sensor with a pixel > + array of 1940x1220 pixels, capable of 1920x1200 resolution at up > + to 120 fps. It supports MIPI CSI-2 output with 1, 2, or 4 data lanes, > + and raw Bayer (8/10-bit) or monochrome output. > + > +properties: > + compatible: > + const: onnn,ar0234cs Should we define separate compatible strings for the mono and colour variants ? I know you identify the variant at runtime in the driver, but avoid I2C communication at boot time can be beneficial (to reduce boot time, and also to avoid flashing the privacy LED on systems that have one, albeit the latter is probably less applicable to the AR0234). > + > + reg: > + description: I2C device address > + maxItems: 1 > + > + clocks: > + description: Reference clock (external clock) input > + maxItems: 1 > + > + reset-gpios: > + description: Reset pin, usually active low (if needed) > + maxItems: 1 > + > + vaa-supply: > + description: Analog (2.8V) supply regulator > + > + vdd-supply: > + description: Digital Core (1.2V) supply regulator > + > + vddio-supply: > + description: I/O (1.8V-2.8V) supply regulator > + > + port: > + $ref: /schemas/graph.yaml#/$defs/port-base > + description: CSI-2 transmitter port > + additionalProperties: false > + properties: > + endpoint: > + $ref: /schemas/media/video-interfaces.yaml# > + unevaluatedProperties: false > + properties: > + data-lanes: > + description: > + Number of MIPI CSI-2 data lanes. Supported values: 2, 4. > + minItems: 2 > + maxItems: 4 > + items: > + enum: [1, 2, 3, 4] > + > + link-frequencies: > + description: > + Allowed MIPI link frequencies in Hz. The driver expects two > + frequencies: one for 8-bit and one for 10-bit modes, > + typically 360 MHz and 450 MHz, but any frequency supported > + by the sensor may be used. What the driver supports isn't relevant for the DT bindings. The frequencies should only be limited here to the range supported by the device, regardless of the current driver implementation. > + minItems: 2 > + maxItems: 2 > + items: > + minimum: 360000000 > + maximum: 450000000 > + > + required: > + - data-lanes > + - link-frequencies > + > + required: > + - endpoint > + > +required: > + - compatible > + - reg > + - clocks > + - port > + > +additionalProperties: false > + > +examples: > + - | > + i2c { > + #address-cells = <1>; > + #size-cells = <0>; > + > + camera@10 { > + compatible = "onnn,ar0234cs"; > + reg = <0x10>; > + clocks = <&clk_ext_camera>; > + > + vaa-supply = <®_cam_vaa>; > + vdd-supply = <®_cam_vdd>; > + vddio-supply = <®_cam_vddio>; > + > + reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>; > + > + port { > + ar0234_ep: endpoint { > + data-lanes = <1 2 3 4>; > + link-frequencies = /bits/ 64 <360000000 450000000>; > + }; > + }; > + }; > + }; > +... -- Regards, Laurent Pinchart