dt-binding: media: document ON Semi AR0521 sensor bindings
Krzysztof Hałasa
maintainerRFC v2 1/1 dt-binding: media: document ON Semi AR0521 sensor bindings
This file documents DT bindings for the AR0521 camera sensor driver. Changes from v1:
- added power management (power supplies).
- small fixes
The question still stands: is there a way to reliably put national unicode characters into:
- commit messages for patches submitted via email,
- C and other source files (comments and stuff like MODULE_AUTHOR).
Yes, I know I can commit it myself correctly, but then propagating it upstream is problematic. Perhaps a pullable tree would be better? I guess I need to renew my old kernel.org account.
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +87 -0
@@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/onnn,ar0521.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ON Semiconductor AR0521 MIPI CSI-2 sensor + +maintainers: + - Krzysztof Halasa <[email protected]> + +description: |- + The AR0521 is a raw CMOS image sensor with MIPI CSI-2 and + I2C-compatible control interface. + +properties: + compatible: + const: onnn,ar0521 + + reg: + maxItems: 1 + + clocks: + description: reference to the xclk clock + maxItems: 1 + + clock-names: + const: xclk + + vdd_io-supply: + description: + Definition of the regulator used as digital I/O (1.8 V) voltage supply. + + vdd_core-supply: + description: + Definition of the regulator used as digital core (1.2 V) voltage supply. + + vcc_analog-supply: + description: + Definition of the regulator used as analog (2.7 V) voltage supply. + + reset-gpios: + description: reset GPIO, usually active low + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + description: | + Output video port: 1, 2 or 4 lanes. + +required: + - compatible + - reg + - clocks + - clock-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/clock/imx6qdl-clock.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ar0521: camera-sensor@36 { + compatible = "onnn,ar0521"; + reg = <0x36>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_mipi_camera>; + + clocks = <&clks IMX6QDL_CLK_CKO>; + clock-names = "xclk"; + + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; + + port { + mipi_camera_to_mipi_csi2: endpoint { + remote-endpoint = <&mipi_csi2_in>; + data-lanes = <1 2 3 4>; + }; + }; + }; + };
Signature · 5 lines
Krzysztof Hałasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa
Hi Krzysztof,
Thank you for the patch.
Quoted 4 lines · Krzysztof Hałasa
This file documents DT bindings for the AR0521 camera sensor driver. Changes from v1:
- added power management (power supplies).
- small fixes
Please move the text below after a --- line, it shouldn't be included in the commit message.
Quoted 3 lines
The question still stands: is there a way to reliably put national unicode characters into:
- commit messages for patches submitted via email,
This shouldn't be too much of a problem, as long as you MUA and MTA don't mess up encoding.
Quoted 1 line
- C and other source files (comments and stuff like
MODULE_AUTHOR).
This may be more problematic, especially in strings in source code.
Quoted 26 lines
Yes, I know I can commit it myself correctly, but then propagating it upstream is problematic. Perhaps a pullable tree would be better? I guess I need to renew my old kernel.org account.
Signed-off-by Krzysztof Halasa <[email protected]>Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +14
-0@@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/onnn,ar0521.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ON Semiconductor AR0521 MIPI CSI-2 sensor + +maintainers: + - Krzysztof Halasa <[email protected]> + +description: |- + The AR0521 is a raw CMOS image sensor with MIPI CSI-2 and + I2C-compatible control interface.
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml line 24
Quoted 10 lines
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +10
-0+ +properties: + compatible: + const: onnn,ar0521 + + reg: + maxItems: 1 + + clocks: + description: reference to the xclk clock
You can drop the description, it's implied by the clock-names property.
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml line 28
Quoted 4 lines
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +4
-0+ maxItems: 1 + + clock-names: + const: xclk
Isn't the pin named extclk ?
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml line 36
Quoted 8 lines
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +8
-0+ + vdd_io-supply: + description: + Definition of the regulator used as digital I/O (1.8 V) voltage supply. + + vdd_core-supply: + description: + Definition of the regulator used as digital core (1.2 V) voltage supply.
It's not just the digital core, 1.2V is also needed for the PLL (VDD_PLL) and the PHY (VDD_PHY). I'd call this vdd-supply.
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml line 40
Quoted 3 lines
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +3
-0+ vcc_analog-supply: + description: + Definition of the regulator used as analog (2.7 V) voltage supply.
Similarly, I'd call this vaa-supply is is covers VAA and VAA_PIX (there's no VCC_ANALOG pin).
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml line 49
Quoted 9 lines
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +9
-0+ + reset-gpios: + description: reset GPIO, usually active low + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + description: | + Output video port: 1, 2 or 4 lanes.
The number of lanes should be described through the data-lanes endpoint property.
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml line 56
Quoted 7 lines
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +7
-0+ +required: + - compatible + - reg + - clocks + - clock-names + - port
Supplies should be mandatory as the chip needs them.
Quoted 31 lines
Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file +31
-0+ +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/clock/imx6qdl-clock.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ar0521: camera-sensor@36 { + compatible = "onnn,ar0521"; + reg = <0x36>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_mipi_camera>; + + clocks = <&clks IMX6QDL_CLK_CKO>; + clock-names = "xclk"; + + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; + + port { + mipi_camera_to_mipi_csi2: endpoint { + remote-endpoint = <&mipi_csi2_in>; + data-lanes = <1 2 3 4>; + }; + }; + }; + };
Signature · 3 lines
Regards, Laurent Pinchart
Krzysztof Hałasa
maintainerQuoted 6 lines · Laurent Pinchart
Quoted 3 lines
The question still stands: is there a way to reliably put national unicode characters into:
- commit messages for patches submitted via email,This shouldn't be too much of a problem, as long as you MUA and MTA don't mess up encoding.
Maybe it's better now. I had mixed results in the past, but maybe it was 10+ years ago. Then I stopped using non-ASCII as they weren't very essential.
Apparently there was no such problems with drivers/net, at least from the time I started using non-ASCII characters.
Signature · 5 lines
Krzysztof Hałasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa
Quoted 6 lines · Krzysztof Hałasa
Quoted 4 lines · Laurent Pinchart
Quoted 3 lines
The question still stands: is there a way to reliably put national unicode characters into:
- commit messages for patches submitted via email,
Quoted 8 lines
Quoted 2 lines
This shouldn't be too much of a problem, as long as you MUA and MTA don't mess up encoding.
Maybe it's better now. I had mixed results in the past, but maybe it was 10+ years ago. Then I stopped using non-ASCII as they weren't very essential.
Apparently there was no such problems withdrivers/net, at least from the time I started using non-ASCII characters.
I think it should be better, yes. As long as there's no MS Exchange along the way of course ;-)
Signature · 3 lines
Regards, Laurent Pinchart