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