2021-06-22 11:19:59

by Krzysztof Hałasa

[permalink] [raw]
Subject: [RFC v2] 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.

Signed-off-by: Krzysztof Halasa <[email protected]>

diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml
new file mode 100644
index 000000000000..29421daacc87
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml
@@ -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>;
+ };
+ };
+ };
+ };

--
Krzysztof Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa


2021-06-22 12:22:02

by Laurent Pinchart

[permalink] [raw]
Subject: Re: [RFC v2] dt-binding: media: document ON Semi AR0521 sensor bindings

Hi Krzysztof,

Thank you for the patch.

On Tue, Jun 22, 2021 at 01:18:35PM +0200, Krzysztof Hałasa wrote:
> 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.

> 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.

> - C and other source files (comments and stuff like MODULE_AUTHOR).

This may be more problematic, especially in strings in source code.

> 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]>
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml
> new file mode 100644
> index 000000000000..29421daacc87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml
> @@ -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

You can drop the description, it's implied by the clock-names property.

> + maxItems: 1
> +
> + clock-names:
> + const: xclk

Isn't the pin named extclk ?

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

> + 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).

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

> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - port

Supplies should be mandatory as the chip needs them.

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

--
Regards,

Laurent Pinchart

2021-06-23 05:47:34

by Krzysztof Hałasa

[permalink] [raw]
Subject: Re: [RFC v2] dt-binding: media: document ON Semi AR0521 sensor bindings

Laurent Pinchart <[email protected]> writes:

>> 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.
--
Krzysztof Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

2021-06-23 13:25:54

by Laurent Pinchart

[permalink] [raw]
Subject: Re: [RFC v2] dt-binding: media: document ON Semi AR0521 sensor bindings

On Wed, Jun 23, 2021 at 07:46:25AM +0200, Krzysztof Hałasa wrote:
> Laurent Pinchart <[email protected]> writes:
>
> >> 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.

I think it should be better, yes. As long as there's no MS Exchange
along the way of course ;-)

--
Regards,

Laurent Pinchart