Add bindings for the already upstream OV08X40 to enable usage of this
sensor on DTS based systems.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
.../bindings/media/i2c/ovti,ov08x40.yaml | 116 +++++++++++++++++++++
1 file changed, 116 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08x40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08x40.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..74b33a083efbe91db0fa4e7e7bb6008a95e4e4d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08x40.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2024 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov08x40.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV08X40 CMOS Sensor
+
+maintainers:
+ - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+description: |
+ The Omnivision OV08X40 is a 9.2 megapixel, CMOS image sensor which supports:
+ - Automatic black level calibration (ABLC)
+ - Programmable controls for frame rate, mirror and flip, binning, cropping
+ and windowing
+ - Output formats 10-bit 4C RGB RAW, 10-bit Bayer RAW
+ - 4-lane MIPI D-PHY TX @ 1 Gbps per lane
+ - 2-lane MPIP D-PHY TX @ 2 Gbps per lane
+ - Dynamic defect pixel cancellation
+ - Standard SCCB command interface
+
+properties:
+ compatible:
+ const: ovti,ov08x40
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogue circuit voltage supply.
+
+ dovdd-supply:
+ description: I/O circuit voltage supply.
+
+ dvdd-supply:
+ description: Digital circuit voltage supply.
+
+ reset-gpios:
+ description: Active low GPIO connected to XSHUTDOWN pad of the sensor.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov08x40: camera@36 {
+ compatible = "ovti,ov08x40";
+ reg = <0x36>;
+
+ reset-gpios = <&tlmm 111 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_rgb_defaultt>;
+
+ clocks = <&ov08x40_clk>;
+
+ assigned-clocks = <&ov08x40_clk>;
+ assigned-clock-parents = <&ov08x40_clk_parent>;
+ assigned-clock-rates = <19200000>;
+
+ avdd-supply = <&vreg_l7b_2p8>;
+ dvdd-supply = <&vreg_l7b_1p8>;
+ dovdd-supply = <&vreg_l3m_1p8>;
+
+ port {
+ ov08x40_ep: endpoint {
+ remote-endpoint = <&csiphy4_ep>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <400000000>;
+ };
+ };
+ };
+ };
+...
--
2.46.2On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote: > + properties: > + data-lanes: > + oneOf: > + - items: > + - const: 1 > + - const: 2 > + - items: > + - const: 1 > + - const: 2 > + - const: 3 > + - const: 4 > + > + link-frequencies: true Not much changed here and you did not continued discussion about it. Best regards, Krzysztof
On 03/10/2024 09:29, Krzysztof Kozlowski wrote: > On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote: >> + properties: >> + data-lanes: >> + oneOf: >> + - items: >> + - const: 1 >> + - const: 2 >> + - items: >> + - const: 1 >> + - const: 2 >> + - const: 3 >> + - const: 4 >> + >> + link-frequencies: true > > Not much changed here and you did not continued discussion about it. > > Best regards, > Krzysztof > Ah my mistake, I didn't read the bit at the bottom of your email
On 03/10/2024 09:33, Bryan O'Donoghue wrote:
> On 03/10/2024 09:29, Krzysztof Kozlowski wrote:
>> On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote:
>>> + properties:
>>> + data-lanes:
>>> + oneOf:
>>> + - items:
>>> + - const: 1
>>> + - const: 2
>>> + - items:
>>> + - const: 1
>>> + - const: 2
>>> + - const: 3
>>> + - const: 4
>>> +
>>> + link-frequencies: true
>>
>> Not much changed here and you did not continued discussion about it.
>>
>> Best regards,
>> Krzysztof
>>
>
> Ah my mistake, I didn't read the bit at the bottom of your email
I'll do this
Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
data-lanes:
description:
This property is for lane reordering between the THP7312
and the SoC. The sensor supports either two-lane, or
four-lane operation.
If this property is omitted four-lane operation is
assumed. For two-lane operation the property must be
set to <1 2>.
minItems: 2
maxItems: 4
items:
maximum: 4
This captures what I'm after.
---
bod
On 03/10/2024 10:38, Bryan O'Donoghue wrote: > On 03/10/2024 09:33, Bryan O'Donoghue wrote: >> On 03/10/2024 09:29, Krzysztof Kozlowski wrote: >>> On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote: >>>> + properties: >>>> + data-lanes: >>>> + oneOf: >>>> + - items: >>>> + - const: 1 >>>> + - const: 2 >>>> + - items: >>>> + - const: 1 >>>> + - const: 2 >>>> + - const: 3 >>>> + - const: 4 >>>> + >>>> + link-frequencies: true >>> >>> Not much changed here and you did not continued discussion about it. >>> >>> Best regards, >>> Krzysztof >>> >> >> Ah my mistake, I didn't read the bit at the bottom of your email > > I'll do this > > Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml > > data-lanes: > description: > This property is for lane reordering between the THP7312 > and the SoC. The sensor supports either two-lane, or > four-lane operation. > If this property is omitted four-lane operation is > assumed. For two-lane operation the property must be > set to <1 2>. > minItems: 2 > maxItems: 4 > items: > maximum: 4 > > This captures what I'm after. I commented on link-frequencies. Best regards, Krzysztof
On 03/10/2024 11:17, Krzysztof Kozlowski wrote: > On 03/10/2024 10:38, Bryan O'Donoghue wrote: >> On 03/10/2024 09:33, Bryan O'Donoghue wrote: >>> On 03/10/2024 09:29, Krzysztof Kozlowski wrote: >>>> On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote: >>>>> + properties: >>>>> + data-lanes: >>>>> + oneOf: >>>>> + - items: >>>>> + - const: 1 >>>>> + - const: 2 >>>>> + - items: >>>>> + - const: 1 >>>>> + - const: 2 >>>>> + - const: 3 >>>>> + - const: 4 >>>>> + >>>>> + link-frequencies: true >>>> >>>> Not much changed here and you did not continued discussion about it. >>>> >>>> Best regards, >>>> Krzysztof >>>> >>> >>> Ah my mistake, I didn't read the bit at the bottom of your email >> >> I'll do this >> >> Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml >> >> data-lanes: >> description: >> This property is for lane reordering between the THP7312 >> and the SoC. The sensor supports either two-lane, or >> four-lane operation. >> If this property is omitted four-lane operation is >> assumed. For two-lane operation the property must be >> set to <1 2>. >> minItems: 2 >> maxItems: 4 >> items: >> maximum: 4 >> >> This captures what I'm after. > > I commented on link-frequencies. > > Best regards, > Krzysztof > Ah I understand you. You're saying the link-frequencies we have in Documentation/devicetree/bindings/media/i2c/* are redundant absent hardware specific link frequencies being enumerated. I'll either enumerate the acceptable set or drop this. --- bod
Hi Bryan, Krzysztof, On Thu, Oct 03, 2024 at 12:54:41PM +0100, Bryan O'Donoghue wrote: > On 03/10/2024 11:17, Krzysztof Kozlowski wrote: > > On 03/10/2024 10:38, Bryan O'Donoghue wrote: > > > On 03/10/2024 09:33, Bryan O'Donoghue wrote: > > > > On 03/10/2024 09:29, Krzysztof Kozlowski wrote: > > > > > On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote: > > > > > > + properties: > > > > > > + data-lanes: > > > > > > + oneOf: > > > > > > + - items: > > > > > > + - const: 1 > > > > > > + - const: 2 > > > > > > + - items: > > > > > > + - const: 1 > > > > > > + - const: 2 > > > > > > + - const: 3 > > > > > > + - const: 4 > > > > > > + > > > > > > + link-frequencies: true > > > > > > > > > > Not much changed here and you did not continued discussion about it. > > > > > > > > > > Best regards, > > > > > Krzysztof > > > > > > > > > > > > > Ah my mistake, I didn't read the bit at the bottom of your email > > > > > > I'll do this > > > > > > Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml > > > > > > data-lanes: > > > description: > > > This property is for lane reordering between the THP7312 > > > and the SoC. The sensor supports either two-lane, or > > > four-lane operation. > > > If this property is omitted four-lane operation is > > > assumed. For two-lane operation the property must be > > > set to <1 2>. > > > minItems: 2 > > > maxItems: 4 > > > items: > > > maximum: 4 > > > > > > This captures what I'm after. > > > > I commented on link-frequencies. > > > > Best regards, > > Krzysztof > > > > Ah I understand you. > > You're saying the link-frequencies we have in > Documentation/devicetree/bindings/media/i2c/* are redundant absent hardware > specific link frequencies being enumerated. > > I'll either enumerate the acceptable set or drop this. link-frequencies should remain mandatory in bindings, whether there are hardware specific limits in bindings or not. <URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera-sensor.html#handling-clocks> -- Kind regards, Sakari Ailus
On 03/10/2024 14:17, Sakari Ailus wrote: > Hi Bryan, Krzysztof, > > On Thu, Oct 03, 2024 at 12:54:41PM +0100, Bryan O'Donoghue wrote: >> On 03/10/2024 11:17, Krzysztof Kozlowski wrote: >>> On 03/10/2024 10:38, Bryan O'Donoghue wrote: >>>> On 03/10/2024 09:33, Bryan O'Donoghue wrote: >>>>> On 03/10/2024 09:29, Krzysztof Kozlowski wrote: >>>>>> On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote: >>>>>>> + properties: >>>>>>> + data-lanes: >>>>>>> + oneOf: >>>>>>> + - items: >>>>>>> + - const: 1 >>>>>>> + - const: 2 >>>>>>> + - items: >>>>>>> + - const: 1 >>>>>>> + - const: 2 >>>>>>> + - const: 3 >>>>>>> + - const: 4 >>>>>>> + >>>>>>> + link-frequencies: true >>>>>> >>>>>> Not much changed here and you did not continued discussion about it. >>>>>> >>>>>> Best regards, >>>>>> Krzysztof >>>>>> >>>>> >>>>> Ah my mistake, I didn't read the bit at the bottom of your email >>>> >>>> I'll do this >>>> >>>> Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml >>>> >>>> data-lanes: >>>> description: >>>> This property is for lane reordering between the THP7312 >>>> and the SoC. The sensor supports either two-lane, or >>>> four-lane operation. >>>> If this property is omitted four-lane operation is >>>> assumed. For two-lane operation the property must be >>>> set to <1 2>. >>>> minItems: 2 >>>> maxItems: 4 >>>> items: >>>> maximum: 4 >>>> >>>> This captures what I'm after. >>> >>> I commented on link-frequencies. >>> >>> Best regards, >>> Krzysztof >>> >> >> Ah I understand you. >> >> You're saying the link-frequencies we have in >> Documentation/devicetree/bindings/media/i2c/* are redundant absent hardware >> specific link frequencies being enumerated. >> >> I'll either enumerate the acceptable set or drop this. > > link-frequencies should remain mandatory in bindings, whether there are > hardware specific limits in bindings or not. > <URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera-sensor.html#handling-clocks> Yep and my comment was not under required field. Why all this discussion is taken out of context? No wonder everyone interprets it differently. Best regards, Krzysztof
Hi Krzyzstof, On Thu, Oct 03, 2024 at 02:31:17PM +0200, Krzysztof Kozlowski wrote: > On 03/10/2024 14:17, Sakari Ailus wrote: > > Hi Bryan, Krzysztof, > > > > On Thu, Oct 03, 2024 at 12:54:41PM +0100, Bryan O'Donoghue wrote: > >> On 03/10/2024 11:17, Krzysztof Kozlowski wrote: > >>> On 03/10/2024 10:38, Bryan O'Donoghue wrote: > >>>> On 03/10/2024 09:33, Bryan O'Donoghue wrote: > >>>>> On 03/10/2024 09:29, Krzysztof Kozlowski wrote: > >>>>>> On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote: > >>>>>>> + properties: > >>>>>>> + data-lanes: > >>>>>>> + oneOf: > >>>>>>> + - items: > >>>>>>> + - const: 1 > >>>>>>> + - const: 2 > >>>>>>> + - items: > >>>>>>> + - const: 1 > >>>>>>> + - const: 2 > >>>>>>> + - const: 3 > >>>>>>> + - const: 4 > >>>>>>> + > >>>>>>> + link-frequencies: true > >>>>>> > >>>>>> Not much changed here and you did not continued discussion about it. > >>>>>> > >>>>>> Best regards, > >>>>>> Krzysztof > >>>>>> > >>>>> > >>>>> Ah my mistake, I didn't read the bit at the bottom of your email > >>>> > >>>> I'll do this > >>>> > >>>> Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml > >>>> > >>>> data-lanes: > >>>> description: > >>>> This property is for lane reordering between the THP7312 > >>>> and the SoC. The sensor supports either two-lane, or > >>>> four-lane operation. > >>>> If this property is omitted four-lane operation is > >>>> assumed. For two-lane operation the property must be > >>>> set to <1 2>. > >>>> minItems: 2 > >>>> maxItems: 4 > >>>> items: > >>>> maximum: 4 > >>>> > >>>> This captures what I'm after. > >>> > >>> I commented on link-frequencies. > >>> > >>> Best regards, > >>> Krzysztof > >>> > >> > >> Ah I understand you. > >> > >> You're saying the link-frequencies we have in > >> Documentation/devicetree/bindings/media/i2c/* are redundant absent hardware > >> specific link frequencies being enumerated. > >> > >> I'll either enumerate the acceptable set or drop this. > > > > link-frequencies should remain mandatory in bindings, whether there are > > hardware specific limits in bindings or not. > > <URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera-sensor.html#handling-clocks> > > Yep and my comment was not under required field. Why all this discussion > is taken out of context? No wonder everyone interprets it differently. I wanted to just add that so we wouldn't have a need for v5. :-) -- Kind regards, Sakari Ailus
On 03/10/2024 13:31, Krzysztof Kozlowski wrote:
>>> Ah I understand you.
>>>
>>> You're saying the link-frequencies we have in
>>> Documentation/devicetree/bindings/media/i2c/* are redundant absent hardware
>>> specific link frequencies being enumerated.
>>>
>>> I'll either enumerate the acceptable set or drop this.
>> link-frequencies should remain mandatory in bindings, whether there are
>> hardware specific limits in bindings or not.
>> <URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera-
>> sensor.html#handling-clocks>
> Yep and my comment was not under required field. Why all this discussion
> is taken out of context? No wonder everyone interprets it differently.
>
> Best regards,
Just so I'm 100% clear.
required:
link-frequencies
is required but
properties:
link-frequencies: true
is not, and presumably should be dropped from other yaml descriptions
upstream.
---
bod
Hi Bryan, On Thu, Oct 03, 2024 at 01:40:34PM +0100, Bryan O'Donoghue wrote: > On 03/10/2024 13:31, Krzysztof Kozlowski wrote: > > > > Ah I understand you. > > > > > > > > You're saying the link-frequencies we have in > > > > Documentation/devicetree/bindings/media/i2c/* are redundant absent hardware > > > > specific link frequencies being enumerated. > > > > > > > > I'll either enumerate the acceptable set or drop this. > > > link-frequencies should remain mandatory in bindings, whether there are > > > hardware specific limits in bindings or not. > > > <URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera- > > > sensor.html#handling-clocks> > > Yep and my comment was not under required field. Why all this discussion > > is taken out of context? No wonder everyone interprets it differently. > > > > Best regards, > > Just so I'm 100% clear. > > required: > link-frequencies > > is required but > > properties: > link-frequencies: true > > is not, and presumably should be dropped from other yaml descriptions > upstream. Seems good to me. -- Kind regards, Sakari Ailus
On 03/10/2024 13:47, Sakari Ailus wrote: > Hi Bryan, > > On Thu, Oct 03, 2024 at 01:40:34PM +0100, Bryan O'Donoghue wrote: >> On 03/10/2024 13:31, Krzysztof Kozlowski wrote: >>>>> Ah I understand you. >>>>> >>>>> You're saying the link-frequencies we have in >>>>> Documentation/devicetree/bindings/media/i2c/* are redundant absent hardware >>>>> specific link frequencies being enumerated. >>>>> >>>>> I'll either enumerate the acceptable set or drop this. >>>> link-frequencies should remain mandatory in bindings, whether there are >>>> hardware specific limits in bindings or not. >>>> <URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera- >>>> sensor.html#handling-clocks> >>> Yep and my comment was not under required field. Why all this discussion >>> is taken out of context? No wonder everyone interprets it differently. >>> >>> Best regards, >> >> Just so I'm 100% clear. >> >> required: >> link-frequencies >> >> is required but >> >> properties: >> link-frequencies: true >> >> is not, and presumably should be dropped from other yaml descriptions >> upstream. > > Seems good to me. > heh so I'll v4 this and since I'm a masochist, I'll send out a fixup series for the rest ... --- bod
On 03/10/2024 10:33, Bryan O'Donoghue wrote: > On 03/10/2024 09:29, Krzysztof Kozlowski wrote: >> On Wed, Oct 02, 2024 at 02:58:44PM +0100, Bryan O'Donoghue wrote: >>> + properties: >>> + data-lanes: >>> + oneOf: >>> + - items: >>> + - const: 1 >>> + - const: 2 >>> + - items: >>> + - const: 1 >>> + - const: 2 >>> + - const: 3 >>> + - const: 4 >>> + >>> + link-frequencies: true >> >> Not much changed here and you did not continued discussion about it. >> >> Best regards, >> Krzysztof >> > > Ah my mistake, I didn't read the bit at the bottom of your email Unlike some other folks, I almost never leave useless quote below my messages, because it wastes a lot of time on reader side, so if there is a quote it means there is something further. Best regards, Krzysztof
© 2016 - 2024 Red Hat, Inc.