diff mbox series

[v3,2/4] media: dt-bindings: Add OmniVision OV08X40

Message ID 20241002-b4-master-24-11-25-ov08x40-v3-2-483bcdcf8886@linaro.org (mailing list archive)
State New
Headers show
Series ov08x40: Enable use of ov08x40 on Qualcomm X1E80100 CRD | expand

Commit Message

Bryan O'Donoghue Oct. 2, 2024, 1:58 p.m. UTC
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(+)

Comments

Krzysztof Kozlowski Oct. 3, 2024, 8:29 a.m. UTC | #1
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
Bryan O'Donoghue Oct. 3, 2024, 8:33 a.m. UTC | #2
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
Krzysztof Kozlowski Oct. 3, 2024, 8:36 a.m. UTC | #3
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
Bryan O'Donoghue Oct. 3, 2024, 8:38 a.m. UTC | #4
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
Krzysztof Kozlowski Oct. 3, 2024, 10:17 a.m. UTC | #5
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
Bryan O'Donoghue Oct. 3, 2024, 11:54 a.m. UTC | #6
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
Sakari Ailus Oct. 3, 2024, 12:17 p.m. UTC | #7
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>
Krzysztof Kozlowski Oct. 3, 2024, 12:31 p.m. UTC | #8
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
Bryan O'Donoghue Oct. 3, 2024, 12:40 p.m. UTC | #9
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
Sakari Ailus Oct. 3, 2024, 12:46 p.m. UTC | #10
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. :-)
Sakari Ailus Oct. 3, 2024, 12:47 p.m. UTC | #11
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.
Bryan O'Donoghue Oct. 3, 2024, 12:48 p.m. UTC | #12
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
diff mbox series

Patch

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>;
+                };
+            };
+        };
+    };
+...