diff mbox series

[v4,1/4] dt-bindings: media: imx258: add bindings for IMX258 sensor

Message ID 20200923152129.21736-1-krzk@kernel.org (mailing list archive)
State New, archived
Headers show
Series [v4,1/4] dt-bindings: media: imx258: add bindings for IMX258 sensor | expand

Commit Message

Krzysztof Kozlowski Sept. 23, 2020, 3:21 p.m. UTC
Add bindings for the IMX258 camera sensor.  The bindings, just like the
driver, are quite limited, e.g. do not support regulator supplies.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Changes since v3:
1. Document also two lane setup.

Changes since v2:
1. Remove clock-frequency, add reset GPIOs, add supplies.
2. Use additionalProperties.

Changes since v1:
1. None
---
 .../devicetree/bindings/media/i2c/imx258.yaml | 100 ++++++++++++++++++
 MAINTAINERS                                   |   1 +
 2 files changed, 101 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/imx258.yaml

Comments

Rob Herring (Arm) Sept. 28, 2020, 6:46 p.m. UTC | #1
On Wed, 23 Sep 2020 17:21:26 +0200, Krzysztof Kozlowski wrote:
> Add bindings for the IMX258 camera sensor.  The bindings, just like the
> driver, are quite limited, e.g. do not support regulator supplies.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> 
> ---
> 
> Changes since v3:
> 1. Document also two lane setup.
> 
> Changes since v2:
> 1. Remove clock-frequency, add reset GPIOs, add supplies.
> 2. Use additionalProperties.
> 
> Changes since v1:
> 1. None
> ---
>  .../devicetree/bindings/media/i2c/imx258.yaml | 100 ++++++++++++++++++
>  MAINTAINERS                                   |   1 +
>  2 files changed, 101 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/imx258.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>
Sakari Ailus Sept. 29, 2020, 9:15 a.m. UTC | #2
Hi Krzysztof,

On Wed, Sep 23, 2020 at 05:21:26PM +0200, Krzysztof Kozlowski wrote:
> Add bindings for the IMX258 camera sensor.  The bindings, just like the
> driver, are quite limited, e.g. do not support regulator supplies.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> 
> ---
> 
> Changes since v3:
> 1. Document also two lane setup.
> 
> Changes since v2:
> 1. Remove clock-frequency, add reset GPIOs, add supplies.

Oops. I missed this one.

How does the driver know the appropriate clock frequency for the platform
if it's not in DT? The sensor supports a range of frequencies, not a single
frequency.

Could you add clock-frequency back?
Krzysztof Kozlowski Sept. 29, 2020, 9:18 a.m. UTC | #3
On Tue, 29 Sep 2020 at 11:15, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
>
> Hi Krzysztof,
>
> On Wed, Sep 23, 2020 at 05:21:26PM +0200, Krzysztof Kozlowski wrote:
> > Add bindings for the IMX258 camera sensor.  The bindings, just like the
> > driver, are quite limited, e.g. do not support regulator supplies.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > ---
> >
> > Changes since v3:
> > 1. Document also two lane setup.
> >
> > Changes since v2:
> > 1. Remove clock-frequency, add reset GPIOs, add supplies.
>
> Oops. I missed this one.
>
> How does the driver know the appropriate clock frequency for the platform
> if it's not in DT? The sensor supports a range of frequencies, not a single
> frequency.
>
> Could you add clock-frequency back?

Not really, it was removed on Rob's request. The bindings do not
describe driver's behavior so how the driver gets frequency should not
be part of the bindings. Also it's not a real problem - the driver
just calls clk_get_rate().

Best regards,
Krzysztof
Sakari Ailus Sept. 29, 2020, 9:40 a.m. UTC | #4
On Tue, Sep 29, 2020 at 11:18:46AM +0200, Krzysztof Kozlowski wrote:
> On Tue, 29 Sep 2020 at 11:15, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> >
> > Hi Krzysztof,
> >
> > On Wed, Sep 23, 2020 at 05:21:26PM +0200, Krzysztof Kozlowski wrote:
> > > Add bindings for the IMX258 camera sensor.  The bindings, just like the
> > > driver, are quite limited, e.g. do not support regulator supplies.
> > >
> > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > >
> > > ---
> > >
> > > Changes since v3:
> > > 1. Document also two lane setup.
> > >
> > > Changes since v2:
> > > 1. Remove clock-frequency, add reset GPIOs, add supplies.
> >
> > Oops. I missed this one.
> >
> > How does the driver know the appropriate clock frequency for the platform
> > if it's not in DT? The sensor supports a range of frequencies, not a single
> > frequency.
> >
> > Could you add clock-frequency back?
> 
> Not really, it was removed on Rob's request. The bindings do not
> describe driver's behavior so how the driver gets frequency should not
> be part of the bindings. Also it's not a real problem - the driver
> just calls clk_get_rate().

How is the rate determined? I mean, many ISPs or CSI-2 receivers that
provide the clock are also capable of using a variety of frequencies. But
only one can be used on the platform in general.

Where does it come from if it's not in DT?

Using another frequency generally leads to failure later on as the desired
link frequency likely is not available for a random external clock
frequency.
Sakari Ailus Sept. 29, 2020, 9:43 a.m. UTC | #5
On Tue, Sep 29, 2020 at 11:18:46AM +0200, Krzysztof Kozlowski wrote:
> On Tue, 29 Sep 2020 at 11:15, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> >
> > Hi Krzysztof,
> >
> > On Wed, Sep 23, 2020 at 05:21:26PM +0200, Krzysztof Kozlowski wrote:
> > > Add bindings for the IMX258 camera sensor.  The bindings, just like the
> > > driver, are quite limited, e.g. do not support regulator supplies.
> > >
> > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > >
> > > ---
> > >
> > > Changes since v3:
> > > 1. Document also two lane setup.
> > >
> > > Changes since v2:
> > > 1. Remove clock-frequency, add reset GPIOs, add supplies.
> >
> > Oops. I missed this one.
> >
> > How does the driver know the appropriate clock frequency for the platform
> > if it's not in DT? The sensor supports a range of frequencies, not a single
> > frequency.
> >
> > Could you add clock-frequency back?
> 
> Not really, it was removed on Rob's request. The bindings do not
> describe driver's behavior so how the driver gets frequency should not
> be part of the bindings. Also it's not a real problem - the driver
> just calls clk_get_rate().

Btw. we also have this nowadays:
Documentation/driver-api/media/camera-sensor.rst .
Krzysztof Kozlowski Sept. 29, 2020, 9:46 a.m. UTC | #6
On Tue, Sep 29, 2020 at 12:40:46PM +0300, Sakari Ailus wrote:
> On Tue, Sep 29, 2020 at 11:18:46AM +0200, Krzysztof Kozlowski wrote:
> > On Tue, 29 Sep 2020 at 11:15, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> > >
> > > Hi Krzysztof,
> > >
> > > On Wed, Sep 23, 2020 at 05:21:26PM +0200, Krzysztof Kozlowski wrote:
> > > > Add bindings for the IMX258 camera sensor.  The bindings, just like the
> > > > driver, are quite limited, e.g. do not support regulator supplies.
> > > >
> > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > >
> > > > ---
> > > >
> > > > Changes since v3:
> > > > 1. Document also two lane setup.
> > > >
> > > > Changes since v2:
> > > > 1. Remove clock-frequency, add reset GPIOs, add supplies.
> > >
> > > Oops. I missed this one.
> > >
> > > How does the driver know the appropriate clock frequency for the platform
> > > if it's not in DT? The sensor supports a range of frequencies, not a single
> > > frequency.
> > >
> > > Could you add clock-frequency back?
> > 
> > Not really, it was removed on Rob's request. The bindings do not
> > describe driver's behavior so how the driver gets frequency should not
> > be part of the bindings. Also it's not a real problem - the driver
> > just calls clk_get_rate().
> 
> How is the rate determined? I mean, many ISPs or CSI-2 receivers that
> provide the clock are also capable of using a variety of frequencies. But
> only one can be used on the platform in general.

Having "clock-frequency" property in DTS did not solve that. It has no
effect on actual frequency.

> 
> Where does it come from if it's not in DT?

The frequency is either chosen by consumer (imx258) or pre-assigned from
DT, but not with "clock-frequency" property. There are generic
properties for this: assigned-clocks, assigned-clock-rates and
assigned-clock-parents.

These properties should be added to DTS if additionalProperties is
false, which is the case here... so I could add them. My DTS anyway does
not use them, as the clock is generated internally on a camera board so
I don't have a control over it.

Best regards,
Krzysztof


> 
> Using another frequency generally leads to failure later on as the desired
> link frequency likely is not available for a random external clock
> frequency.
Sakari Ailus Sept. 29, 2020, 11:02 a.m. UTC | #7
On Tue, Sep 29, 2020 at 11:46:36AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Sep 29, 2020 at 12:40:46PM +0300, Sakari Ailus wrote:
> > On Tue, Sep 29, 2020 at 11:18:46AM +0200, Krzysztof Kozlowski wrote:
> > > On Tue, 29 Sep 2020 at 11:15, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> > > >
> > > > Hi Krzysztof,
> > > >
> > > > On Wed, Sep 23, 2020 at 05:21:26PM +0200, Krzysztof Kozlowski wrote:
> > > > > Add bindings for the IMX258 camera sensor.  The bindings, just like the
> > > > > driver, are quite limited, e.g. do not support regulator supplies.
> > > > >
> > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > >
> > > > > ---
> > > > >
> > > > > Changes since v3:
> > > > > 1. Document also two lane setup.
> > > > >
> > > > > Changes since v2:
> > > > > 1. Remove clock-frequency, add reset GPIOs, add supplies.
> > > >
> > > > Oops. I missed this one.
> > > >
> > > > How does the driver know the appropriate clock frequency for the platform
> > > > if it's not in DT? The sensor supports a range of frequencies, not a single
> > > > frequency.
> > > >
> > > > Could you add clock-frequency back?
> > > 
> > > Not really, it was removed on Rob's request. The bindings do not
> > > describe driver's behavior so how the driver gets frequency should not
> > > be part of the bindings. Also it's not a real problem - the driver
> > > just calls clk_get_rate().
> > 
> > How is the rate determined? I mean, many ISPs or CSI-2 receivers that
> > provide the clock are also capable of using a variety of frequencies. But
> > only one can be used on the platform in general.
> 
> Having "clock-frequency" property in DTS did not solve that. It has no
> effect on actual frequency.

It's up to the driver to do what's needed, yes.

Please see examples in e.g. drivers/media/i2c/ov8856.c and
Documentation/devicetree/bindings/media/i2c/ov8856.yaml .
Krzysztof Kozlowski Oct. 2, 2020, 12:15 p.m. UTC | #8
On Tue, Sep 29, 2020 at 02:02:55PM +0300, Sakari Ailus wrote:
> On Tue, Sep 29, 2020 at 11:46:36AM +0200, Krzysztof Kozlowski wrote:
> > On Tue, Sep 29, 2020 at 12:40:46PM +0300, Sakari Ailus wrote:
> > > On Tue, Sep 29, 2020 at 11:18:46AM +0200, Krzysztof Kozlowski wrote:
> > > > On Tue, 29 Sep 2020 at 11:15, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> > > > >
> > > > > Hi Krzysztof,
> > > > >
> > > > > On Wed, Sep 23, 2020 at 05:21:26PM +0200, Krzysztof Kozlowski wrote:
> > > > > > Add bindings for the IMX258 camera sensor.  The bindings, just like the
> > > > > > driver, are quite limited, e.g. do not support regulator supplies.
> > > > > >
> > > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > Changes since v3:
> > > > > > 1. Document also two lane setup.
> > > > > >
> > > > > > Changes since v2:
> > > > > > 1. Remove clock-frequency, add reset GPIOs, add supplies.
> > > > >
> > > > > Oops. I missed this one.
> > > > >
> > > > > How does the driver know the appropriate clock frequency for the platform
> > > > > if it's not in DT? The sensor supports a range of frequencies, not a single
> > > > > frequency.
> > > > >
> > > > > Could you add clock-frequency back?
> > > > 
> > > > Not really, it was removed on Rob's request. The bindings do not
> > > > describe driver's behavior so how the driver gets frequency should not
> > > > be part of the bindings. Also it's not a real problem - the driver
> > > > just calls clk_get_rate().
> > > 
> > > How is the rate determined? I mean, many ISPs or CSI-2 receivers that
> > > provide the clock are also capable of using a variety of frequencies. But
> > > only one can be used on the platform in general.
> > 
> > Having "clock-frequency" property in DTS did not solve that. It has no
> > effect on actual frequency.
> 
> It's up to the driver to do what's needed, yes.
> 
> Please see examples in e.g. drivers/media/i2c/ov8856.c and
> Documentation/devicetree/bindings/media/i2c/ov8856.yaml .

It seems the ov8856 driver uses this property in different way than
imx258 driver. It is more appropriate and quite similar to clock
providers and buses - to set the desired frequency on input clock.

Therefore what is the point of using this DT property comparing to
assigned-clock-rates?

It's the same. So let's use generic (already documented)
assigned-clock-rates.  

For your question (not related to the bindings but to driver
implementation): "How is the rate determined?", simple: clk_get_rate.
The driver then uses it like this:
	if (clk_get_rate() != only_working_configuration_hz)
		return -EINVAL;

From the bindings point of view, the clock can be anything within a
range of sensor's accepted values. The clock frequency is a property of
a clock, not of a sensor. Therefore for HW description it should be
described in the clock bindings, not in the sensor bindings.

To summarize, the "clock-frequency" property of sensor node:
1. As a way to configure the clock should be replaced with
   assigned-clock properties,
2. As a way to describe the hardware is simply invalid. It is not a HW
   description, because HW requires just a clock of frequency within
   given range, not a fixed frequency clock.

Consider the example:
        camera@1a {
                compatible = "sony,imx258";
                reg = <0x1a>;

                clocks = <&imx258_clk>;
                clock-names = "clk";

                /* Oscillator on camera board */
                imx258_clk: clk {
                        compatible = "fixed-clock";
                        #clock-cells = <0>;
                        clock-frequency = <19200000>;
                };

                port {
			...
                };
        };

What is the point to add "clock-frequency" property to the camera
itself, since it is already clearly defined by the clock?

Or another example:

        camera@1a {
                compatible = "sony,imx258";
                reg = <0x1a>;

                clocks = <&iclk 0>;
                clock-names = "clk";
		assigned-clocks = <&clk 0>;
		assigned-clock-rates = <19200000>;

                port {
			...
                };
        };

Again, no reason for artificial clock-frequency property. It is not part
of HW description of the sensor.

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/media/i2c/imx258.yaml b/Documentation/devicetree/bindings/media/i2c/imx258.yaml
new file mode 100644
index 000000000000..520e75c7b451
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/imx258.yaml
@@ -0,0 +1,100 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/imx258.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX258 13 Mpixel CMOS Digital Image Sensor
+
+maintainers:
+  - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |-
+  IMX258 is a diagonal 5.867mm (Type 1/3.06) 13 Mega-pixel CMOS active pixel
+  type stacked image sensor with a square pixel array of size 4208 x 3120. It
+  is programmable through I2C interface.  Image data is sent through MIPI
+  CSI-2.
+
+properties:
+  compatible:
+    const: sony,imx258
+
+  clocks:
+    description:
+      Clock frequency from 6 to 27 MHz.
+    maxItems: 1
+
+  reg:
+    maxItems: 1
+
+  reset-gpios:
+    description: |-
+      Reference to the GPIO connected to the XCLR pin, if any.
+
+  vana-supply:
+    description:
+      Analog voltage (VANA) supply, 2.7 V
+
+  vdig-supply:
+    description:
+      Digital I/O voltage (VDIG) supply, 1.2 V
+
+  vif-supply:
+    description:
+      Interface voltage (VIF) supply, 1.8 V
+
+  # See ../video-interfaces.txt for more details
+  port:
+    type: object
+    properties:
+      endpoint:
+        type: object
+        properties:
+          data-lanes:
+            oneOf:
+              - items:
+                  - const: 1
+                  - const: 2
+                  - const: 3
+                  - const: 4
+              - items:
+                  - const: 1
+                  - const: 2
+
+          link-frequencies:
+            allOf:
+              - $ref: /schemas/types.yaml#/definitions/uint64-array
+            description:
+              Allowed data bus frequencies.
+
+        required:
+          - data-lanes
+          - link-frequencies
+
+required:
+  - compatible
+  - reg
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c0 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sensor@6c {
+            compatible = "sony,imx258";
+            reg = <0x6c>;
+            clocks = <&imx258_clk>;
+
+            port {
+                endpoint {
+                    remote-endpoint = <&csi1_ep>;
+                    data-lanes = <1 2 3 4>;
+                    link-frequencies = /bits/ 64 <320000000>;
+                };
+            };
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b9621ca2b31..68f30a283a2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16262,6 +16262,7 @@  M:	Sakari Ailus <sakari.ailus@linux.intel.com>
 L:	linux-media@vger.kernel.org
 S:	Maintained
 T:	git git://linuxtv.org/media_tree.git
+F:	Documentation/devicetree/bindings/media/i2c/imx258.yaml
 F:	drivers/media/i2c/imx258.c
 
 SONY IMX274 SENSOR DRIVER