Message ID | 20240521162950.6987-2-sylvain.petinot@foss.st.com (mailing list archive) |
---|---|
State | Changes Requested |
Delegated to: | Sakari Ailus |
Headers |
Received: from sy.mirrors.kernel.org ([147.75.48.161]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-11704-patchwork=linuxtv.org@vger.kernel.org>) id 1s9SOS-00046k-1F for patchwork@linuxtv.org; Tue, 21 May 2024 16:31:17 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 4387DB21DD5 for <patchwork@linuxtv.org>; Tue, 21 May 2024 16:31:13 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A6C2229414; Tue, 21 May 2024 16:31:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=foss.st.com header.i=@foss.st.com header.b="WKpHZGwR" X-Original-To: linux-media@vger.kernel.org Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) (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 75B1A17556; Tue, 21 May 2024 16:31:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.132.182.106 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716309066; cv=none; b=d0OqI9bf+1XHDrBlfMjI+p7hDXBPuAhOMKY097sajCQeyRdu2YDMPIAheii5Qd4ZWV21X8Gw2Zl0ej7h11GJO2S0H0UVR9IrQ+7BariqaB/LnxBmCy1cf6BMi2Msu5bVYGpQHBuUGlmctkrnzJUr9I2GLkA/59QmCw62sSk7o4Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716309066; c=relaxed/simple; bh=vKGOTT1yBBRyHhWvN3uok2skglokzqEQ67BbRlFR580=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FZgkRQSyEIjB/z+uplw5DSIFW0WOshOfdFnUeaIm/Sv/enRsYXKokRBXpyVmC2aQ64kEFhC9cpvQ1rHf7HYVBXnsm+xLsi8KFMbkJsVq6kHHP9MKuRqL7BqTm0PxBqrOHcpKcYb1w/2UWdr6zLuHXD1lkwYIv+rphYz5R/enQRs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=foss.st.com; spf=pass smtp.mailfrom=foss.st.com; dkim=pass (2048-bit key) header.d=foss.st.com header.i=@foss.st.com header.b=WKpHZGwR; arc=none smtp.client-ip=185.132.182.106 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0369458.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 44LGIegf023007; Tue, 21 May 2024 18:30:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; s=selector1; bh=ITGLkU6HTHqFtjoyA5kj iBnTyFGlt6kPKc0wp2BTy68=; b=WKpHZGwRnWUMX+hq8UrnhKBMf3FwVp0vY9+Y +/GzuoDSWXlmyYWaanvIjy+J7PvWQb3paqcQEnTeb4lZDbkb6jGNCrSeowSTr90o hV5IXDWp7gErkwHL/Ps/zeuGLmWgv397ZOPsPFjKkniK7mofdNYeiuWybFJhZ5co uzc7nPnNkV5Ep7HXemuCb8UFTi5Or2N+/uVgXBWC3+HvYF8vQoO2sjLBotJi79Z8 sHw6UNU51f6rDnXfY3j65hKkIfcX+KxXiGyJjwH7Zb7L3hdUOzhZD1KVxj5FSttx UF7mbFLp2VxPA+i2geSR0YCDNZXwUaj/8fUv+PBxaVctFPs0Qg== Received: from beta.dmz-ap.st.com (beta.dmz-ap.st.com [138.198.100.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3y8vqh8nn4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 May 2024 18:30:57 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-ap.st.com (STMicroelectronics) with ESMTP id 4133340045; Tue, 21 May 2024 18:30:53 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node1.st.com [10.75.129.69]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 76E9F226FDA; Tue, 21 May 2024 18:30:23 +0200 (CEST) Received: from localhost (10.130.72.242) by SHFDAG1NODE1.st.com (10.75.129.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 21 May 2024 18:30:23 +0200 From: Sylvain Petinot <sylvain.petinot@foss.st.com> To: <benjamin.mugnier@foss.st.com>, <sylvain.petinot@foss.st.com>, <mchehab@kernel.org>, <robh@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org> CC: <linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH v2 1/2] media: dt-bindings: Add ST VD56G3 camera sensor binding Date: Tue, 21 May 2024 18:29:49 +0200 Message-ID: <20240521162950.6987-2-sylvain.petinot@foss.st.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240521162950.6987-1-sylvain.petinot@foss.st.com> References: <20240521162950.6987-1-sylvain.petinot@foss.st.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: EQNCAS1NODE4.st.com (10.75.129.82) To SHFDAG1NODE1.st.com (10.75.129.69) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16 definitions=2024-05-21_10,2024-05-21_01,2024-05-17_01 X-LSpam-Score: -2.6 (--) X-LSpam-Report: No, score=-2.6 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no |
Series |
media: Add driver for ST VD56G3 camera sensor
|
|
Commit Message
Sylvain Petinot
May 21, 2024, 4:29 p.m. UTC
Add devicetree bindings Documentation for ST VD56G3 & ST VD66GY camera
sensors. Update MAINTAINERS file.
Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com>
---
.../bindings/media/i2c/st,st-vd56g3.yaml | 132 ++++++++++++++++++
MAINTAINERS | 9 ++
2 files changed, 141 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml
Comments
On 21/05/2024 18:29, Sylvain Petinot wrote: > Add devicetree bindings Documentation for ST VD56G3 & ST VD66GY camera > sensors. Update MAINTAINERS file. > A nit, subject: drop second/last, redundant "binding". The "dt-bindings" prefix is already stating that these are bindings. See also: https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18 > Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> > --- > .../bindings/media/i2c/st,st-vd56g3.yaml | 132 ++++++++++++++++++ > MAINTAINERS | 9 ++ > 2 files changed, 141 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml > > diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml > new file mode 100644 > index 000000000000..22cb2557e311 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml Why duplicated 'st'? > @@ -0,0 +1,132 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +# Copyright (c) 2024 STMicroelectronics SA. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/i2c/st,st-vd56g3.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: STMicroelectronics VD56G3 Global Shutter Image Sensor > + > +maintainers: > + - Benjamin Mugnier <benjamin.mugnier@foss.st.com> > + - Sylvain Petinot <sylvain.petinot@foss.st.com> > + > +description: |- > + The STMicroelectronics VD56G3 is a 1.5 M pixel global shutter image sensor This claims device is VD56G3, not ST-VD56G3. > + with an active array size of 1124 x 1364 (portrait orientation). It is > + programmable through I2C, the address is fixed to 0x10. The sensor output is > + available via CSI-2, which is configured as either 1 or 2 data lanes. The > + sensor provides 8 GPIOS that can be used for external LED signal > + (synchronized with sensor integration periods) > + > +properties: > + compatible: > + enum: > + - st,st-vd56g3 > + - st,st-vd66gy > + description: > + Two variants are availables; VD56G3 is a monochrome sensor while VD66GY > + is a colour variant. > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + vcore-supply: > + description: Digital core power supply (1.15V) > + > + vddio-supply: > + description: Digital IO power supply (1.8V) > + > + vana-supply: > + description: Analog power supply (2.8V) > + > + reset-gpios: > + description: Sensor reset active low GPIO (XSHUTDOWN) > + maxItems: 1 > + > + st,leds: > + description: > + Sensor's GPIOs used for external LED control. Signal being the enveloppe > + of the integration time. More information is needed. GPIOs coming from LED or SoC? What's the meaning of values? > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 1 > + maxItems: 8 > + items: > + minimum: 0 > + maximum: 7 > + > + port: > + $ref: /schemas/graph.yaml#/$defs/port-base missing additionalProperties: false > + > + properties: > + endpoint: > + $ref: /schemas/media/video-interfaces.yaml# > + unevaluatedProperties: false > + > + properties: > + data-lanes: > + minItems: 1 > + maxItems: 2 > + items: > + enum: [1, 2] > + > + link-frequencies: > + minItems: 1 maxItems is enough > + maxItems: 1 > + items: > + enum: [402000000, 750000000] > + > + lane-polarities: > + minItems: 1 > + maxItems: 3 > + description: Any lane can be inverted or not. > + > + required: > + - data-lanes > + - link-frequencies > + > +required: > + - compatible > + - reg > + - clocks > + - vcore-supply > + - vddio-supply > + - vana-supply > + - reset-gpios > + - port > + Not a video-interface-device.yaml type of device? Best regards, Krzysztof
Hi Krzysztof, Thanks for the review. On 5/21/2024 7:37 PM, Krzysztof Kozlowski wrote: > On 21/05/2024 18:29, Sylvain Petinot wrote: >> Add devicetree bindings Documentation for ST VD56G3 & ST VD66GY camera >> sensors. Update MAINTAINERS file. >> > > A nit, subject: drop second/last, redundant "binding". The "dt-bindings" > prefix is already stating that these are bindings. > See also: > https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18 > Ok, fixed in V3. > >> Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> >> --- >> .../bindings/media/i2c/st,st-vd56g3.yaml | 132 ++++++++++++++++++ >> MAINTAINERS | 9 ++ >> 2 files changed, 141 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml >> >> diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml >> new file mode 100644 >> index 000000000000..22cb2557e311 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml > > Why duplicated 'st'? Legacy : our first st-mipid02 driver was upstream this way few years back. We have 3 options : 1- keep this unpleasant naming to keep consistency with st-mipid02 [1] and st-vgxy61 [2] 2- rename this driver properly ('vd56g3') and keep the two others the old way (I personally don't like this option) 3- rename this driver properly ('vd56g3') and in a second patch rename the two others drivers. I would be interested to get Sakari's opinion on this subject. [1]: https://elixir.bootlin.com/linux/v6.9.1/source/drivers/media/i2c/st-mipid02.c [2]: https://elixir.bootlin.com/linux/v6.9.1/source/drivers/media/i2c/st-vgxy61.c > >> @@ -0,0 +1,132 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +# Copyright (c) 2024 STMicroelectronics SA. >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/media/i2c/st,st-vd56g3.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: STMicroelectronics VD56G3 Global Shutter Image Sensor >> + >> +maintainers: >> + - Benjamin Mugnier <benjamin.mugnier@foss.st.com> >> + - Sylvain Petinot <sylvain.petinot@foss.st.com> >> + >> +description: |- >> + The STMicroelectronics VD56G3 is a 1.5 M pixel global shutter image sensor > > This claims device is VD56G3, not ST-VD56G3. Sure, linked with previous point. > >> + with an active array size of 1124 x 1364 (portrait orientation). It is >> + programmable through I2C, the address is fixed to 0x10. The sensor output is >> + available via CSI-2, which is configured as either 1 or 2 data lanes. The >> + sensor provides 8 GPIOS that can be used for external LED signal >> + (synchronized with sensor integration periods) >> + >> +properties: >> + compatible: >> + enum: >> + - st,st-vd56g3 >> + - st,st-vd66gy >> + description: >> + Two variants are availables; VD56G3 is a monochrome sensor while VD66GY >> + is a colour variant. >> + >> + reg: >> + maxItems: 1 >> + >> + clocks: >> + maxItems: 1 >> + >> + vcore-supply: >> + description: Digital core power supply (1.15V) >> + >> + vddio-supply: >> + description: Digital IO power supply (1.8V) >> + >> + vana-supply: >> + description: Analog power supply (2.8V) >> + >> + reset-gpios: >> + description: Sensor reset active low GPIO (XSHUTDOWN) >> + maxItems: 1 >> + >> + st,leds: >> + description: >> + Sensor's GPIOs used for external LED control. Signal being the enveloppe >> + of the integration time. > > More information is needed. GPIOs coming from LED or SoC? What's the > meaning of values? The vd56g3 image sensor provides 8 GPIOS that can be used for different use cases (external led controls, synchronization between master/slave sensors, external sensor trigger, etc.). This submission supports only the first use case: the control of one(or multiple) external LED. The vd56g3 sensor family are optimized for visible and near infrared scenes. In NIR, external IR leds are generally used for illumination. With such use case, a led (or a led driver) can be connected directly to one of the 8 GPIOs of the sensor. On the driver side, when a led is configured in the dt, the driver will configure the sensor accordingly. It will also offer an optional "V4L2_FLASH_LED_MODE_FLASH" control to start/stop the external control. Different signal modes are supported by the HW, but the default (implemented) one is a "strobe" mode where signal is the envelope of the integration time (IR led is on while image sensor is integrating). > >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + minItems: 1 >> + maxItems: 8 >> + items: >> + minimum: 0 >> + maximum: 7 >> + >> + port: >> + $ref: /schemas/graph.yaml#/$defs/port-base > > missing additionalProperties: false Ok, fixed in V3. > >> + >> + properties: >> + endpoint: >> + $ref: /schemas/media/video-interfaces.yaml# >> + unevaluatedProperties: false >> + >> + properties: >> + data-lanes: >> + minItems: 1 >> + maxItems: 2 >> + items: >> + enum: [1, 2] > > >> + >> + link-frequencies: >> + minItems: 1 > > maxItems is enough Ok, fixed in V3. > >> + maxItems: 1 >> + items: >> + enum: [402000000, 750000000] >> + >> + lane-polarities: >> + minItems: 1 >> + maxItems: 3 >> + description: Any lane can be inverted or not. >> + >> + required: >> + - data-lanes >> + - link-frequencies >> + >> +required: >> + - compatible >> + - reg >> + - clocks >> + - vcore-supply >> + - vddio-supply >> + - vana-supply >> + - reset-gpios >> + - port >> + > > > Not a video-interface-device.yaml type of device? Good point, something I'll consider in V3 > > Best regards, > Krzysztof > -- Sylvain
On 27/05/2024 15:14, Sylvain Petinot wrote: >> >>> Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> >>> --- >>> .../bindings/media/i2c/st,st-vd56g3.yaml | 132 ++++++++++++++++++ >>> MAINTAINERS | 9 ++ >>> 2 files changed, 141 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml >>> new file mode 100644 >>> index 000000000000..22cb2557e311 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml >> >> Why duplicated 'st'? > > Legacy : our first st-mipid02 driver was upstream this way few years back. > > We have 3 options : > > 1- keep this unpleasant naming to keep consistency with st-mipid02 [1] > and st-vgxy61 [2] ? Unpleasant? Please follow generic rules. Filename must match compatible and compatible must follow vendor,device format. > 2- rename this driver properly ('vd56g3') and keep the two others the > old way (I personally don't like this option) We do not talk about driver here. Does not matter. > 3- rename this driver properly ('vd56g3') and in a second patch rename > the two others drivers. > > I would be interested to get Sakari's opinion on this subject. About what? Renaming drivers? > > [1]: > https://elixir.bootlin.com/linux/v6.9.1/source/drivers/media/i2c/st-mipid02.c > > [2]: > https://elixir.bootlin.com/linux/v6.9.1/source/drivers/media/i2c/st-vgxy61.c Howe are these drivers anyhow related to the *binding*? ... >>> + >>> + st,leds: >>> + description: >>> + Sensor's GPIOs used for external LED control. Signal being the enveloppe >>> + of the integration time. >> >> More information is needed. GPIOs coming from LED or SoC? What's the >> meaning of values? > > The vd56g3 image sensor provides 8 GPIOS that can be used for different > use cases (external led controls, synchronization between master/slave > sensors, external sensor trigger, etc.). This submission supports only > the first use case: the control of one(or multiple) external LED. What your driver supports is not really relevant. Describe hardware. > > The vd56g3 sensor family are optimized for visible and near infrared > scenes. In NIR, external IR leds are generally used for illumination. > > With such use case, a led (or a led driver) can be connected directly to > one of the 8 GPIOs of the sensor. On the driver side, when a led is > configured in the dt, the driver will configure the sensor accordingly. > It will also offer an optional "V4L2_FLASH_LED_MODE_FLASH" control to > start/stop the external control. > > Different signal modes are supported by the HW, but the default > (implemented) one is a "strobe" mode where signal is the envelope of the > integration time (IR led is on while image sensor is integrating). You did not explain the meaning of the property. Please describe the hardware and the meaning of values used in this property. Best regards, Krzysztof
On 21/05/2024 18:29, Sylvain Petinot wrote: > Add devicetree bindings Documentation for ST VD56G3 & ST VD66GY camera > sensors. Update MAINTAINERS file. > > Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> > diff --git a/MAINTAINERS b/MAINTAINERS > index ef6be9d95143..554e6861425b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -20885,6 +20885,15 @@ S: Maintained > F: Documentation/hwmon/stpddc60.rst > F: drivers/hwmon/pmbus/stpddc60.c > > +ST VD56G3 DRIVER > +M: Benjamin Mugnier <benjamin.mugnier@foss.st.com> > +M: Sylvain Petinot <sylvain.petinot@foss.st.com> > +L: linux-media@vger.kernel.org > +S: Maintained > +T: git git://linuxtv.org/media_tree.git This is a friendly reminder during the review process. It seems my or other reviewer's previous comments were not fully addressed. Maybe the feedback got lost between the quotes, maybe you just forgot to apply it. Please go back to the previous discussion and either implement all requested changes or keep discussing them. Thank you. Best regards, Krzysztof
Hi Sylvain, On Mon, May 27, 2024 at 03:14:35PM +0200, Sylvain Petinot wrote: > >> diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml > >> new file mode 100644 > >> index 000000000000..22cb2557e311 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml > > > > Why duplicated 'st'? > > Legacy : our first st-mipid02 driver was upstream this way few years back. > > We have 3 options : > > 1- keep this unpleasant naming to keep consistency with st-mipid02 [1] > and st-vgxy61 [2] > 2- rename this driver properly ('vd56g3') and keep the two others the > old way (I personally don't like this option) > 3- rename this driver properly ('vd56g3') and in a second patch rename > the two others drivers. > > I would be interested to get Sakari's opinion on this subject. > > [1]: > https://elixir.bootlin.com/linux/v6.9.1/source/drivers/media/i2c/st-mipid02.c > > [2]: > https://elixir.bootlin.com/linux/v6.9.1/source/drivers/media/i2c/st-vgxy61.c The driver could be renamed to align with a large majority that use the same name as the bindings without the vendor prefix. You could add MODULE_ALIAS() to help user space to cope with the change. The DT compatible string indeed should reflect the name of the device, the driver is indeed another matter.
Hi Krzysztof, On Mon, May 27, 2024 at 09:04:38PM +0200, Krzysztof Kozlowski wrote: > On 21/05/2024 18:29, Sylvain Petinot wrote: > > Add devicetree bindings Documentation for ST VD56G3 & ST VD66GY camera > > sensors. Update MAINTAINERS file. > > > > Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index ef6be9d95143..554e6861425b 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -20885,6 +20885,15 @@ S: Maintained > > F: Documentation/hwmon/stpddc60.rst > > F: drivers/hwmon/pmbus/stpddc60.c > > > > +ST VD56G3 DRIVER I might add this is a sensor, i.e. "ST VD653G IMAGE SENSOR DRIVER". > > +M: Benjamin Mugnier <benjamin.mugnier@foss.st.com> > > +M: Sylvain Petinot <sylvain.petinot@foss.st.com> > > +L: linux-media@vger.kernel.org > > +S: Maintained > > +T: git git://linuxtv.org/media_tree.git > > This is a friendly reminder during the review process. > > It seems my or other reviewer's previous comments were not fully > addressed. Maybe the feedback got lost between the quotes, maybe you > just forgot to apply it. Please go back to the previous discussion and > either implement all requested changes or keep discussing them. The above MAINTAINERS entry is roughly in line with what else we have for the Media tree. I'm in favour of listing the people who would look after the driver, not just those who merge the patches (or even send PRs to Linus). In other words, I think the above entry is fine as-is. Sylvain: could you also add the file under "V4L2 CAMERA SENSOR DRIVERS" that lists myself as the maintainer? Thanks.
On 28/05/2024 11:22, Sakari Ailus wrote: > Hi Krzysztof, > > On Mon, May 27, 2024 at 09:04:38PM +0200, Krzysztof Kozlowski wrote: >> On 21/05/2024 18:29, Sylvain Petinot wrote: >>> Add devicetree bindings Documentation for ST VD56G3 & ST VD66GY camera >>> sensors. Update MAINTAINERS file. >>> >>> Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> >> >> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index ef6be9d95143..554e6861425b 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -20885,6 +20885,15 @@ S: Maintained >>> F: Documentation/hwmon/stpddc60.rst >>> F: drivers/hwmon/pmbus/stpddc60.c >>> >>> +ST VD56G3 DRIVER > > I might add this is a sensor, i.e. "ST VD653G IMAGE SENSOR DRIVER". > >>> +M: Benjamin Mugnier <benjamin.mugnier@foss.st.com> >>> +M: Sylvain Petinot <sylvain.petinot@foss.st.com> >>> +L: linux-media@vger.kernel.org >>> +S: Maintained >>> +T: git git://linuxtv.org/media_tree.git >> >> This is a friendly reminder during the review process. >> >> It seems my or other reviewer's previous comments were not fully >> addressed. Maybe the feedback got lost between the quotes, maybe you >> just forgot to apply it. Please go back to the previous discussion and >> either implement all requested changes or keep discussing them. > > The above MAINTAINERS entry is roughly in line with what else we have for > the Media tree. I'm in favour of listing the people who would look after > the driver, not just those who merge the patches (or even send PRs to > Linus). I did not propose to drop the entry. > > In other words, I think the above entry is fine as-is. I propose to drop duplicated, redundant git entry. Maintainer of this driver does not have access to git tree and the git tree is already explained in media subsystem entry. If you ever update the git tree, you need to update 100 driver entries which is meaningless... Best regards, Krzysztof
Hi Krzysztof, On Tue, May 28, 2024 at 11:46:00AM +0200, Krzysztof Kozlowski wrote: > On 28/05/2024 11:22, Sakari Ailus wrote: > > Hi Krzysztof, > > > > On Mon, May 27, 2024 at 09:04:38PM +0200, Krzysztof Kozlowski wrote: > >> On 21/05/2024 18:29, Sylvain Petinot wrote: > >>> Add devicetree bindings Documentation for ST VD56G3 & ST VD66GY camera > >>> sensors. Update MAINTAINERS file. > >>> > >>> Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> > >> > >> > >>> diff --git a/MAINTAINERS b/MAINTAINERS > >>> index ef6be9d95143..554e6861425b 100644 > >>> --- a/MAINTAINERS > >>> +++ b/MAINTAINERS > >>> @@ -20885,6 +20885,15 @@ S: Maintained > >>> F: Documentation/hwmon/stpddc60.rst > >>> F: drivers/hwmon/pmbus/stpddc60.c > >>> > >>> +ST VD56G3 DRIVER > > > > I might add this is a sensor, i.e. "ST VD653G IMAGE SENSOR DRIVER". > > > >>> +M: Benjamin Mugnier <benjamin.mugnier@foss.st.com> > >>> +M: Sylvain Petinot <sylvain.petinot@foss.st.com> > >>> +L: linux-media@vger.kernel.org > >>> +S: Maintained > >>> +T: git git://linuxtv.org/media_tree.git > >> > >> This is a friendly reminder during the review process. > >> > >> It seems my or other reviewer's previous comments were not fully > >> addressed. Maybe the feedback got lost between the quotes, maybe you > >> just forgot to apply it. Please go back to the previous discussion and > >> either implement all requested changes or keep discussing them. > > > > The above MAINTAINERS entry is roughly in line with what else we have for > > the Media tree. I'm in favour of listing the people who would look after > > the driver, not just those who merge the patches (or even send PRs to > > Linus). > > I did not propose to drop the entry. > > > > > In other words, I think the above entry is fine as-is. > > I propose to drop duplicated, redundant git entry. Maintainer of this Ah, I agree, that makes sense. > driver does not have access to git tree and the git tree is already > explained in media subsystem entry. If you ever update the git tree, you > need to update 100 driver entries which is meaningless...
Hello Krzysztof, On 5/27/2024 9:00 PM, Krzysztof Kozlowski wrote: > On 27/05/2024 15:14, Sylvain Petinot wrote: >>> >>>> Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> >>>> --- >>>> .../bindings/media/i2c/st,st-vd56g3.yaml | 132 ++++++++++++++++++ >>>> MAINTAINERS | 9 ++ >>>> 2 files changed, 141 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml >>>> new file mode 100644 >>>> index 000000000000..22cb2557e311 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml >>> >>> Why duplicated 'st'? >> >> Legacy : our first st-mipid02 driver was upstream this way few years back. >> >> We have 3 options : >> >> 1- keep this unpleasant naming to keep consistency with st-mipid02 [1] >> and st-vgxy61 [2] > > ? Unpleasant? > Please follow generic rules. Filename must match compatible and > compatible must follow vendor,device format. > >> 2- rename this driver properly ('vd56g3') and keep the two others the >> old way (I personally don't like this option) > > We do not talk about driver here. Does not matter. > >> 3- rename this driver properly ('vd56g3') and in a second patch rename >> the two others drivers. >> >> I would be interested to get Sakari's opinion on this subject. > > About what? Renaming drivers? > >> >> [1]: >> https://elixir.bootlin.com/linux/v6.9.1/source/drivers/media/i2c/st-mipid02.c >> >> [2]: >> https://elixir.bootlin.com/linux/v6.9.1/source/drivers/media/i2c/st-vgxy61.c > > Howe are these drivers anyhow related to the *binding*? I got your point. bindings will be updated accordingly in V3 to follow vendor,device format. My point was more about consistency : 1- ensure driver name is aligned with the bindings name (without vendor prefix) 2- ensure all ST image sensor drivers and bindings follow the same rules. But, you're right, this is a out of bindings topic and I will handle it separately. > > > ... > >>>> + >>>> + st,leds: >>>> + description: >>>> + Sensor's GPIOs used for external LED control. Signal being the enveloppe >>>> + of the integration time. >>> >>> More information is needed. GPIOs coming from LED or SoC? What's the >>> meaning of values? >> >> The vd56g3 image sensor provides 8 GPIOS that can be used for different >> use cases (external led controls, synchronization between master/slave >> sensors, external sensor trigger, etc.). This submission supports only >> the first use case: the control of one(or multiple) external LED. > > What your driver supports is not really relevant. Describe hardware. > >> >> The vd56g3 sensor family are optimized for visible and near infrared >> scenes. In NIR, external IR leds are generally used for illumination. >> >> With such use case, a led (or a led driver) can be connected directly to >> one of the 8 GPIOs of the sensor. On the driver side, when a led is >> configured in the dt, the driver will configure the sensor accordingly. >> It will also offer an optional "V4L2_FLASH_LED_MODE_FLASH" control to >> start/stop the external control. >> >> Different signal modes are supported by the HW, but the default >> (implemented) one is a "strobe" mode where signal is the envelope of the >> integration time (IR led is on while image sensor is integrating). > > You did not explain the meaning of the property. Please describe the > hardware and the meaning of values used in this property. > > Sure, this was more contextual information. Please find below a proposal for the "st,leds" property : st,leds: description: List sensor's GPIOs used to control strobe light sources during exposure time. The numbers identify the sensor pin on which the illumination system is connected. GPIOs are active-high. $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 8 items: minimum: 0 maximum: 7 > > Best regards, > Krzysztof > -- Sylvain
Hi Krzysztof, Sakari On 5/28/2024 12:01 PM, Sakari Ailus wrote: > Hi Krzysztof, > > On Tue, May 28, 2024 at 11:46:00AM +0200, Krzysztof Kozlowski wrote: >> On 28/05/2024 11:22, Sakari Ailus wrote: >>> Hi Krzysztof, >>> >>> On Mon, May 27, 2024 at 09:04:38PM +0200, Krzysztof Kozlowski wrote: >>>> On 21/05/2024 18:29, Sylvain Petinot wrote: >>>>> Add devicetree bindings Documentation for ST VD56G3 & ST VD66GY camera >>>>> sensors. Update MAINTAINERS file. >>>>> >>>>> Signed-off-by: Sylvain Petinot <sylvain.petinot@foss.st.com> >>>> >>>> >>>>> diff --git a/MAINTAINERS b/MAINTAINERS >>>>> index ef6be9d95143..554e6861425b 100644 >>>>> --- a/MAINTAINERS >>>>> +++ b/MAINTAINERS >>>>> @@ -20885,6 +20885,15 @@ S: Maintained >>>>> F: Documentation/hwmon/stpddc60.rst >>>>> F: drivers/hwmon/pmbus/stpddc60.c >>>>> >>>>> +ST VD56G3 DRIVER >>> >>> I might add this is a sensor, i.e. "ST VD653G IMAGE SENSOR DRIVER". >>> >>>>> +M: Benjamin Mugnier <benjamin.mugnier@foss.st.com> >>>>> +M: Sylvain Petinot <sylvain.petinot@foss.st.com> >>>>> +L: linux-media@vger.kernel.org >>>>> +S: Maintained >>>>> +T: git git://linuxtv.org/media_tree.git >>>> >>>> This is a friendly reminder during the review process. >>>> >>>> It seems my or other reviewer's previous comments were not fully >>>> addressed. Maybe the feedback got lost between the quotes, maybe you >>>> just forgot to apply it. Please go back to the previous discussion and >>>> either implement all requested changes or keep discussing them. >>> >>> The above MAINTAINERS entry is roughly in line with what else we have for >>> the Media tree. I'm in favour of listing the people who would look after >>> the driver, not just those who merge the patches (or even send PRs to >>> Linus). >> >> I did not propose to drop the entry. >> >>> >>> In other words, I think the above entry is fine as-is. >> >> I propose to drop duplicated, redundant git entry. Maintainer of this > > Ah, I agree, that makes sense. Thanks for clarifying, git entry will be drop in V3. > >> driver does not have access to git tree and the git tree is already >> explained in media subsystem entry. If you ever update the git tree, you >> need to update 100 driver entries which is meaningless... > -- Sylvain
diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml new file mode 100644 index 000000000000..22cb2557e311 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (c) 2024 STMicroelectronics SA. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/st,st-vd56g3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics VD56G3 Global Shutter Image Sensor + +maintainers: + - Benjamin Mugnier <benjamin.mugnier@foss.st.com> + - Sylvain Petinot <sylvain.petinot@foss.st.com> + +description: |- + The STMicroelectronics VD56G3 is a 1.5 M pixel global shutter image sensor + with an active array size of 1124 x 1364 (portrait orientation). It is + programmable through I2C, the address is fixed to 0x10. The sensor output is + available via CSI-2, which is configured as either 1 or 2 data lanes. The + sensor provides 8 GPIOS that can be used for external LED signal + (synchronized with sensor integration periods) + +properties: + compatible: + enum: + - st,st-vd56g3 + - st,st-vd66gy + description: + Two variants are availables; VD56G3 is a monochrome sensor while VD66GY + is a colour variant. + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + vcore-supply: + description: Digital core power supply (1.15V) + + vddio-supply: + description: Digital IO power supply (1.8V) + + vana-supply: + description: Analog power supply (2.8V) + + reset-gpios: + description: Sensor reset active low GPIO (XSHUTDOWN) + maxItems: 1 + + st,leds: + description: + Sensor's GPIOs used for external LED control. Signal being the enveloppe + of the integration time. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + items: + minimum: 0 + maximum: 7 + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 2 + items: + enum: [1, 2] + + link-frequencies: + minItems: 1 + maxItems: 1 + items: + enum: [402000000, 750000000] + + lane-polarities: + minItems: 1 + maxItems: 3 + description: Any lane can be inverted or not. + + required: + - data-lanes + - link-frequencies + +required: + - compatible + - reg + - clocks + - vcore-supply + - vddio-supply + - vana-supply + - reset-gpios + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera-sensor@10 { + compatible = "st,st-vd56g3"; + reg = <0x10>; + + clocks = <&camera_clk_12M>; + + vcore-supply = <&camera_vcore_v1v15>; + vddio-supply = <&camera_vddio_v1v8>; + vana-supply = <&camera_vana_v2v8>; + + reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>; + st,leds = <6>; + + port { + endpoint { + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <402000000>; + remote-endpoint = <&csiphy0_ep>; + }; + }; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index ef6be9d95143..554e6861425b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -20885,6 +20885,15 @@ S: Maintained F: Documentation/hwmon/stpddc60.rst F: drivers/hwmon/pmbus/stpddc60.c +ST VD56G3 DRIVER +M: Benjamin Mugnier <benjamin.mugnier@foss.st.com> +M: Sylvain Petinot <sylvain.petinot@foss.st.com> +L: linux-media@vger.kernel.org +S: Maintained +T: git git://linuxtv.org/media_tree.git +F: Documentation/devicetree/bindings/media/i2c/st,st-vd56g3.yaml +F: drivers/media/i2c/st-vd56g3.c + ST VGXY61 DRIVER M: Benjamin Mugnier <benjamin.mugnier@foss.st.com> M: Sylvain Petinot <sylvain.petinot@foss.st.com>