[PATCH v13 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings

[Tomasz Figa]

Hi Dongchun,

On Fri, Jul 10, 2020 at 12:19 PM Dongchun Zhu <dongchun.zhu at mediatek.com> wrote:
>
> Add YAML device tree binding for OV02A10 CMOS image sensor,
> and the relevant MAINTAINERS entries.
>
> Reviewed-by: Tomasz Figa <tfiga at chromium.org>
> Reviewed-by: Rob Herring <robh at kernel.org>
> Signed-off-by: Dongchun Zhu <dongchun.zhu at mediatek.com>
> ---
>  .../bindings/media/i2c/ovti,ov02a10.yaml           | 172 +++++++++++++++++++++
>  MAINTAINERS                                        |   7 +
>  2 files changed, 179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..3a916cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,172 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> +  - Dongchun Zhu <dongchun.zhu at mediatek.com>
> +
> +description: |-
> +  The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> +  image sensor, which is the latest production derived from Omnivision's CMOS
> +  image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> +  @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> +  sensor output is available via CSI-2 serial data output.
> +
> +properties:
> +  compatible:
> +    const: ovti,ov02a10
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    items:
> +      - description: top mux camtg clock
> +      - description: divider clock
> +
> +  clock-names:
> +    items:
> +      - const: eclk
> +      - const: freq_mux

Why do we have two clocks here? Looking at the example suggests that
they may be the clocks of the SoC that the integration was done with.
However, the binding must only define the aspects of the particular
device, i.e. this sensor.

I suppose we should only have "eclk" here and it should be described
as "external clock for the sensor".

> +
> +  clock-frequency:
> +    description:
> +      Frequency of the eclk clock in Hertz.

nit: maybe Hz?

> +
> +  dovdd-supply:
> +    description:
> +      Definition of the regulator used as Digital I/O voltage supply.
> +
> +  avdd-supply:
> +    description:
> +      Definition of the regulator used as Analog voltage supply.
> +
> +  dvdd-supply:
> +    description:
> +      Definition of the regulator used as Digital core voltage supply.
> +
> +  powerdown-gpios:
> +    description:
> +      Must be the device tree identifier of the GPIO connected to the
> +      PD_PAD pin. This pin is used to place the OV02A10 into standby mode
> +      or shutdown mode. As the line needs to be high for the powerdown mode
> +      to be active, it should be marked GPIO_ACTIVE_HIGH.
> +    maxItems: 1
> +
> +  reset-gpios:
> +    description:
> +      Must be the device tree identifier of the GPIO connected to the
> +      RST_PD pin. If specified, it will be asserted during driver probe.
> +      As the line needs to be low for the reset to be active, it should be
> +      marked GPIO_ACTIVE_LOW.
> +    maxItems: 1
> +
> +  rotation:
> +    description:
> +      Definition of the sensor's placement.
> +    allOf:
> +      - $ref: "/schemas/types.yaml#/definitions/uint32"
> +      - enum:
> +          - 0    # Sensor Mounted Upright
> +          - 180  # Sensor Mounted Upside Down
> +        default: 0
> +
> +  ovti,mipi-tx-speed:
> +    description:
> +      Indication of MIPI transmission speed select, which is to control D-PHY
> +      timing setting by adjusting MIPI clock voltage to improve the clock
> +      driver capability.

The description says that the value adjusts "MIPI clock voltage".
Should the property be renamed to "ovti,mipi-clock-voltage"?

> +    allOf:
> +      - $ref: "/schemas/types.yaml#/definitions/uint32"
> +      - enum:
> +          - 0    #  20MHz -  30MHz
> +          - 1    #  30MHz -  50MHz
> +          - 2    #  50MHz -  75MHz
> +          - 3    #  75MHz - 100MHz
> +          - 4    # 100MHz - 130MHz
> +        default: 3
> +

I've discussed this on IRC with Sakari. It sounds like this works as
is for us because the driver currently only supports 1 mode, always
running the link at 390 MHz. This won't scale if one intends to add
more modes, because DT can't be expected to be updated when the driver
changes. The two are expected to be separate and backwards compatible.

I think we could model this in DT as an array of <link speed, clock
voltage> pairs. Similarly to the OPP bindings [1]. An example to have
all link speeds up to 390 MHz use the value 4:

ovti,mipi-clock-voltages = <
              /* KHz         clock voltage unit */
                 390000    4
>;

if one wants to select different voltage for different link, they
could do so as well. With the example below, the driver should
configure "3" for link frequencies <= 150 MHz and "4" for > 150 MHz <=
390 MHz. Link frequencies > 390 MHz should be disallowed.

ovti,mipi-clock-voltages = <
              /* KHz         clock voltage unit */
                 150000    3
                 390000    4
>;

What do you think?

[1] https://elixir.bootlin.com/linux/v5.9-rc3/source/Documentation/devicetree/bindings/opp/opp.txt

Best regards,
Tomasz