| Message ID | 20220916134535.128131-4-m.felsch@pengutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add support for Toshiba TC358746 | expand |
Hi Marco, Thank you for the patch. On Fri, Sep 16, 2022 at 03:45:34PM +0200, Marco Felsch wrote: > Add the bindings for the Toshiba TC358746 Parallel <-> MIPI-CSI bridge > driver. > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > Reviewed-by: Rob Herring <robh@kernel.org> > --- > Changelog: > > v2: > - addded Robs r-b > - s/than/then/ > - added hsync/vsync/bus-type, make hsync/vsync required > - fix example indent > > .../bindings/media/i2c/toshiba,tc358746.yaml | 179 ++++++++++++++++++ > 1 file changed, 179 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > new file mode 100644 > index 000000000000..1fa574400bc2 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > @@ -0,0 +1,179 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge > + > +maintainers: > + - Marco Felsch <kernel@pengutronix.de> > + > +description: |- > + The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2 > + stream. The direction can be either parallel-in -> csi-out or csi-in -> > + parallel-out The chip is programmable trough I2C and SPI but the SPI > + interface is only supported in parallel-in -> csi-out mode. > + > + Note that the current device tree bindings only support the > + parallel-in -> csi-out path. > + > +properties: > + compatible: > + const: toshiba,tc358746 > + > + reg: > + maxItems: 1 > + > + clocks: > + description: > + The phandle to the reference clock source. This corresponds to the > + hardware pin REFCLK. > + maxItems: 1 > + > + clock-names: > + const: refclk > + > +# The bridge can act as clock provider for the sensor. To enable this support > +# #clock-cells must be specified. Attention if this feature is used then the > +# mclk rate must be at least: (2 * link-frequency) / 8 > +# `------------------´ ^ > +# internal PLL rate smallest possible mclk-div > + "#clock-cells": > + const: 0 > + > + clock-output-names: > + description: > + The clock name of the MCLK output, the default name is tc358746-mclk. > + maxItems: 1 > + > + vddc-supply: > + description: Digital core voltage supply, 1.2 volts > + > + vddio-supply: > + description: Digital I/O voltage supply, 1.8 volts > + > + vddmipi-supply: > + description: MIPI CSI phy voltage supply, 1.2 volts > + > + reset-gpios: > + description: > + The phandle and specifier for the GPIO that controls the chip reset. > + This corresponds to the hardware pin RESX which is physically active low. > + maxItems: 1 > + > + ports: > + $ref: /schemas/graph.yaml#/properties/ports > + properties: > + port@0: > + $ref: /schemas/graph.yaml#/$defs/port-base > + description: Input port > + > + properties: > + endpoint: > + $ref: /schemas/media/video-interfaces.yaml# > + unevaluatedProperties: false > + > + properties: > + hsync-active: > + enum: > + - 0 # Hvalid active high > + vsync-active: > + enum: > + - 0 # Vvalid active high > + bus-type: > + enum: > + - 5 # Parallel > + > + required: > + - hsync-active > + - vsync-active Let's make bus-type required too, to prepare for BT.656 support. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > + > + port@1: > + $ref: /schemas/graph.yaml#/$defs/port-base > + description: Output port > + > + properties: > + endpoint: > + $ref: /schemas/media/video-interfaces.yaml# > + unevaluatedProperties: false > + > + properties: > + data-lanes: > + minItems: 1 > + maxItems: 4 > + > + clock-noncontinuous: true > + link-frequencies: true > + > + required: > + - data-lanes > + - link-frequencies > + > + required: > + - port@0 > + - port@1 > + > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - vddc-supply > + - vddio-supply > + - vddmipi-supply > + - ports > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/gpio/gpio.h> > + > + i2c { > + #address-cells = <1>; > + #size-cells = <0>; > + > + csi-bridge@e { > + compatible = "toshiba,tc358746"; > + reg = <0xe>; > + > + clocks = <&refclk>; > + clock-names = "refclk"; > + > + reset-gpios = <&gpio 2 GPIO_ACTIVE_LOW>; > + > + vddc-supply = <&v1_2d>; > + vddio-supply = <&v1_8d>; > + vddmipi-supply = <&v1_2d>; > + > + /* sensor mclk provider */ > + #clock-cells = <0>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* Input */ > + port@0 { > + reg = <0>; > + tc358746_in: endpoint { > + remote-endpoint = <&sensor_out>; > + hsync-active = <0>; > + vsync-active = <0>; > + }; > + }; > + > + /* Output */ > + port@1 { > + reg = <1>; > + tc358746_out: endpoint { > + remote-endpoint = <&mipi_csi2_in>; > + data-lanes = <1 2>; > + clock-noncontinuous; > + link-frequencies = /bits/ 64 <216000000>; > + }; > + }; > + }; > + }; > + };
Hi Laurent, On 22-09-18, Laurent Pinchart wrote: > Hi Marco, > > Thank you for the patch. > > On Fri, Sep 16, 2022 at 03:45:34PM +0200, Marco Felsch wrote: > > Add the bindings for the Toshiba TC358746 Parallel <-> MIPI-CSI bridge > > driver. > > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > > Reviewed-by: Rob Herring <robh@kernel.org> > > --- > > Changelog: > > > > v2: > > - addded Robs r-b > > - s/than/then/ > > - added hsync/vsync/bus-type, make hsync/vsync required > > - fix example indent > > > > .../bindings/media/i2c/toshiba,tc358746.yaml | 179 ++++++++++++++++++ > > 1 file changed, 179 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > new file mode 100644 > > index 000000000000..1fa574400bc2 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > @@ -0,0 +1,179 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge > > + > > +maintainers: > > + - Marco Felsch <kernel@pengutronix.de> > > + > > +description: |- > > + The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2 > > + stream. The direction can be either parallel-in -> csi-out or csi-in -> > > + parallel-out The chip is programmable trough I2C and SPI but the SPI > > + interface is only supported in parallel-in -> csi-out mode. > > + > > + Note that the current device tree bindings only support the > > + parallel-in -> csi-out path. > > + > > +properties: > > + compatible: > > + const: toshiba,tc358746 > > + > > + reg: > > + maxItems: 1 > > + > > + clocks: > > + description: > > + The phandle to the reference clock source. This corresponds to the > > + hardware pin REFCLK. > > + maxItems: 1 > > + > > + clock-names: > > + const: refclk > > + > > +# The bridge can act as clock provider for the sensor. To enable this support > > +# #clock-cells must be specified. Attention if this feature is used then the > > +# mclk rate must be at least: (2 * link-frequency) / 8 > > +# `------------------´ ^ > > +# internal PLL rate smallest possible mclk-div > > + "#clock-cells": > > + const: 0 > > + > > + clock-output-names: > > + description: > > + The clock name of the MCLK output, the default name is tc358746-mclk. > > + maxItems: 1 > > + > > + vddc-supply: > > + description: Digital core voltage supply, 1.2 volts > > + > > + vddio-supply: > > + description: Digital I/O voltage supply, 1.8 volts > > + > > + vddmipi-supply: > > + description: MIPI CSI phy voltage supply, 1.2 volts > > + > > + reset-gpios: > > + description: > > + The phandle and specifier for the GPIO that controls the chip reset. > > + This corresponds to the hardware pin RESX which is physically active low. > > + maxItems: 1 > > + > > + ports: > > + $ref: /schemas/graph.yaml#/properties/ports > > + properties: > > + port@0: > > + $ref: /schemas/graph.yaml#/$defs/port-base > > + description: Input port > > + > > + properties: > > + endpoint: > > + $ref: /schemas/media/video-interfaces.yaml# > > + unevaluatedProperties: false > > + > > + properties: > > + hsync-active: > > + enum: > > + - 0 # Hvalid active high > > + vsync-active: > > + enum: > > + - 0 # Vvalid active high > > + bus-type: > > + enum: > > + - 5 # Parallel > > + > > + required: > > + - hsync-active > > + - vsync-active > > Let's make bus-type required too, to prepare for BT.656 support. I would have done it when the BT.656 support is added. Since the BT.656 don't require the sync signals I would have made a descision: - either: hsync/vsync present -> parallel with external syncs, or - bus-type present -> parallel bus with embedded syncs. So we don't bother the system-integrator with specifying unnecessary properties. Also having v/hsync required in place with the bus-type (set to bt.656) can cause confusion about the final used mode. Regards, Marco > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > + > > + port@1: > > + $ref: /schemas/graph.yaml#/$defs/port-base > > + description: Output port > > + > > + properties: > > + endpoint: > > + $ref: /schemas/media/video-interfaces.yaml# > > + unevaluatedProperties: false > > + > > + properties: > > + data-lanes: > > + minItems: 1 > > + maxItems: 4 > > + > > + clock-noncontinuous: true > > + link-frequencies: true > > + > > + required: > > + - data-lanes > > + - link-frequencies > > + > > + required: > > + - port@0 > > + - port@1 > > + > > +required: > > + - compatible > > + - reg > > + - clocks > > + - clock-names > > + - vddc-supply > > + - vddio-supply > > + - vddmipi-supply > > + - ports > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include <dt-bindings/gpio/gpio.h> > > + > > + i2c { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + csi-bridge@e { > > + compatible = "toshiba,tc358746"; > > + reg = <0xe>; > > + > > + clocks = <&refclk>; > > + clock-names = "refclk"; > > + > > + reset-gpios = <&gpio 2 GPIO_ACTIVE_LOW>; > > + > > + vddc-supply = <&v1_2d>; > > + vddio-supply = <&v1_8d>; > > + vddmipi-supply = <&v1_2d>; > > + > > + /* sensor mclk provider */ > > + #clock-cells = <0>; > > + > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + /* Input */ > > + port@0 { > > + reg = <0>; > > + tc358746_in: endpoint { > > + remote-endpoint = <&sensor_out>; > > + hsync-active = <0>; > > + vsync-active = <0>; > > + }; > > + }; > > + > > + /* Output */ > > + port@1 { > > + reg = <1>; > > + tc358746_out: endpoint { > > + remote-endpoint = <&mipi_csi2_in>; > > + data-lanes = <1 2>; > > + clock-noncontinuous; > > + link-frequencies = /bits/ 64 <216000000>; > > + }; > > + }; > > + }; > > + }; > > + }; > > -- > Regards, > > Laurent Pinchart >
Hi Marco, On Mon, Sep 19, 2022 at 12:08:44PM +0200, Marco Felsch wrote: > Hi Laurent, > > On 22-09-18, Laurent Pinchart wrote: > > Hi Marco, > > > > Thank you for the patch. > > > > On Fri, Sep 16, 2022 at 03:45:34PM +0200, Marco Felsch wrote: > > > Add the bindings for the Toshiba TC358746 Parallel <-> MIPI-CSI bridge > > > driver. > > > > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > > > Reviewed-by: Rob Herring <robh@kernel.org> > > > --- > > > Changelog: > > > > > > v2: > > > - addded Robs r-b > > > - s/than/then/ > > > - added hsync/vsync/bus-type, make hsync/vsync required > > > - fix example indent > > > > > > .../bindings/media/i2c/toshiba,tc358746.yaml | 179 ++++++++++++++++++ > > > 1 file changed, 179 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > new file mode 100644 > > > index 000000000000..1fa574400bc2 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > @@ -0,0 +1,179 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge > > > + > > > +maintainers: > > > + - Marco Felsch <kernel@pengutronix.de> > > > + > > > +description: |- > > > + The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2 > > > + stream. The direction can be either parallel-in -> csi-out or csi-in -> > > > + parallel-out The chip is programmable trough I2C and SPI but the SPI > > > + interface is only supported in parallel-in -> csi-out mode. > > > + > > > + Note that the current device tree bindings only support the > > > + parallel-in -> csi-out path. > > > + > > > +properties: > > > + compatible: > > > + const: toshiba,tc358746 > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + clocks: > > > + description: > > > + The phandle to the reference clock source. This corresponds to the > > > + hardware pin REFCLK. > > > + maxItems: 1 > > > + > > > + clock-names: > > > + const: refclk > > > + > > > +# The bridge can act as clock provider for the sensor. To enable this support > > > +# #clock-cells must be specified. Attention if this feature is used then the > > > +# mclk rate must be at least: (2 * link-frequency) / 8 > > > +# `------------------´ ^ > > > +# internal PLL rate smallest possible mclk-div > > > + "#clock-cells": > > > + const: 0 > > > + > > > + clock-output-names: > > > + description: > > > + The clock name of the MCLK output, the default name is tc358746-mclk. > > > + maxItems: 1 > > > + > > > + vddc-supply: > > > + description: Digital core voltage supply, 1.2 volts > > > + > > > + vddio-supply: > > > + description: Digital I/O voltage supply, 1.8 volts > > > + > > > + vddmipi-supply: > > > + description: MIPI CSI phy voltage supply, 1.2 volts > > > + > > > + reset-gpios: > > > + description: > > > + The phandle and specifier for the GPIO that controls the chip reset. > > > + This corresponds to the hardware pin RESX which is physically active low. > > > + maxItems: 1 > > > + > > > + ports: > > > + $ref: /schemas/graph.yaml#/properties/ports > > > + properties: > > > + port@0: > > > + $ref: /schemas/graph.yaml#/$defs/port-base > > > + description: Input port > > > + > > > + properties: > > > + endpoint: > > > + $ref: /schemas/media/video-interfaces.yaml# > > > + unevaluatedProperties: false > > > + > > > + properties: > > > + hsync-active: > > > + enum: > > > + - 0 # Hvalid active high > > > + vsync-active: > > > + enum: > > > + - 0 # Vvalid active high > > > + bus-type: > > > + enum: > > > + - 5 # Parallel > > > + > > > + required: > > > + - hsync-active > > > + - vsync-active > > > > Let's make bus-type required too, to prepare for BT.656 support. > > I would have done it when the BT.656 support is added. Since the BT.656 > don't require the sync signals I would have made a descision: > - either: hsync/vsync present -> parallel with external syncs, or > - bus-type present -> parallel bus with embedded syncs. > > So we don't bother the system-integrator with specifying unnecessary > properties. Also having v/hsync required in place with the bus-type (set > to bt.656) can cause confusion about the final used mode. The V4L2 fwnode framework can guess the type of the bus but it's not recommended to use the feature. Why do you have hsync-active and vsync-active if both are always zero? Can the hardware not support other configuration?
On Mon, Sep 19, 2022 at 10:23:55AM +0000, Sakari Ailus wrote: > On Mon, Sep 19, 2022 at 12:08:44PM +0200, Marco Felsch wrote: > > On 22-09-18, Laurent Pinchart wrote: > > > On Fri, Sep 16, 2022 at 03:45:34PM +0200, Marco Felsch wrote: > > > > Add the bindings for the Toshiba TC358746 Parallel <-> MIPI-CSI bridge > > > > driver. > > > > > > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > > > > Reviewed-by: Rob Herring <robh@kernel.org> > > > > --- > > > > Changelog: > > > > > > > > v2: > > > > - addded Robs r-b > > > > - s/than/then/ > > > > - added hsync/vsync/bus-type, make hsync/vsync required > > > > - fix example indent > > > > > > > > .../bindings/media/i2c/toshiba,tc358746.yaml | 179 ++++++++++++++++++ > > > > 1 file changed, 179 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > new file mode 100644 > > > > index 000000000000..1fa574400bc2 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > @@ -0,0 +1,179 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge > > > > + > > > > +maintainers: > > > > + - Marco Felsch <kernel@pengutronix.de> > > > > + > > > > +description: |- > > > > + The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2 > > > > + stream. The direction can be either parallel-in -> csi-out or csi-in -> > > > > + parallel-out The chip is programmable trough I2C and SPI but the SPI > > > > + interface is only supported in parallel-in -> csi-out mode. > > > > + > > > > + Note that the current device tree bindings only support the > > > > + parallel-in -> csi-out path. > > > > + > > > > +properties: > > > > + compatible: > > > > + const: toshiba,tc358746 > > > > + > > > > + reg: > > > > + maxItems: 1 > > > > + > > > > + clocks: > > > > + description: > > > > + The phandle to the reference clock source. This corresponds to the > > > > + hardware pin REFCLK. > > > > + maxItems: 1 > > > > + > > > > + clock-names: > > > > + const: refclk > > > > + > > > > +# The bridge can act as clock provider for the sensor. To enable this support > > > > +# #clock-cells must be specified. Attention if this feature is used then the > > > > +# mclk rate must be at least: (2 * link-frequency) / 8 > > > > +# `------------------´ ^ > > > > +# internal PLL rate smallest possible mclk-div > > > > + "#clock-cells": > > > > + const: 0 > > > > + > > > > + clock-output-names: > > > > + description: > > > > + The clock name of the MCLK output, the default name is tc358746-mclk. > > > > + maxItems: 1 > > > > + > > > > + vddc-supply: > > > > + description: Digital core voltage supply, 1.2 volts > > > > + > > > > + vddio-supply: > > > > + description: Digital I/O voltage supply, 1.8 volts > > > > + > > > > + vddmipi-supply: > > > > + description: MIPI CSI phy voltage supply, 1.2 volts > > > > + > > > > + reset-gpios: > > > > + description: > > > > + The phandle and specifier for the GPIO that controls the chip reset. > > > > + This corresponds to the hardware pin RESX which is physically active low. > > > > + maxItems: 1 > > > > + > > > > + ports: > > > > + $ref: /schemas/graph.yaml#/properties/ports > > > > + properties: > > > > + port@0: > > > > + $ref: /schemas/graph.yaml#/$defs/port-base > > > > + description: Input port > > > > + > > > > + properties: > > > > + endpoint: > > > > + $ref: /schemas/media/video-interfaces.yaml# > > > > + unevaluatedProperties: false > > > > + > > > > + properties: > > > > + hsync-active: > > > > + enum: > > > > + - 0 # Hvalid active high > > > > + vsync-active: > > > > + enum: > > > > + - 0 # Vvalid active high > > > > + bus-type: > > > > + enum: > > > > + - 5 # Parallel > > > > + > > > > + required: > > > > + - hsync-active > > > > + - vsync-active > > > > > > Let's make bus-type required too, to prepare for BT.656 support. > > > > I would have done it when the BT.656 support is added. Since the BT.656 > > don't require the sync signals I would have made a descision: > > - either: hsync/vsync present -> parallel with external syncs, or > > - bus-type present -> parallel bus with embedded syncs. > > > > So we don't bother the system-integrator with specifying unnecessary > > properties. Also having v/hsync required in place with the bus-type (set > > to bt.656) can cause confusion about the final used mode. > > The V4L2 fwnode framework can guess the type of the bus but it's not > recommended to use the feature. Explicit bus types in DT indeed makes it easier for drivers, so if a device can support multiple bus types (even if not implemented yet in the corresponding drivers), the property should be there. > Why do you have hsync-active and vsync-active if both are always zero? Can > the hardware not support other configuration?
Hi Laurent, Sakari, On 22-09-19, Laurent Pinchart wrote: > On Mon, Sep 19, 2022 at 10:23:55AM +0000, Sakari Ailus wrote: > > On Mon, Sep 19, 2022 at 12:08:44PM +0200, Marco Felsch wrote: > > > On 22-09-18, Laurent Pinchart wrote: > > > > On Fri, Sep 16, 2022 at 03:45:34PM +0200, Marco Felsch wrote: > > > > > Add the bindings for the Toshiba TC358746 Parallel <-> MIPI-CSI bridge > > > > > driver. > > > > > > > > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > > > > > Reviewed-by: Rob Herring <robh@kernel.org> > > > > > --- > > > > > Changelog: > > > > > > > > > > v2: > > > > > - addded Robs r-b > > > > > - s/than/then/ > > > > > - added hsync/vsync/bus-type, make hsync/vsync required > > > > > - fix example indent > > > > > > > > > > .../bindings/media/i2c/toshiba,tc358746.yaml | 179 ++++++++++++++++++ > > > > > 1 file changed, 179 insertions(+) > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > > new file mode 100644 > > > > > index 000000000000..1fa574400bc2 > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > > @@ -0,0 +1,179 @@ > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > +%YAML 1.2 > > > > > +--- > > > > > +$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge > > > > > + > > > > > +maintainers: > > > > > + - Marco Felsch <kernel@pengutronix.de> > > > > > + > > > > > +description: |- > > > > > + The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2 > > > > > + stream. The direction can be either parallel-in -> csi-out or csi-in -> > > > > > + parallel-out The chip is programmable trough I2C and SPI but the SPI > > > > > + interface is only supported in parallel-in -> csi-out mode. > > > > > + > > > > > + Note that the current device tree bindings only support the > > > > > + parallel-in -> csi-out path. > > > > > + > > > > > +properties: > > > > > + compatible: > > > > > + const: toshiba,tc358746 > > > > > + > > > > > + reg: > > > > > + maxItems: 1 > > > > > + > > > > > + clocks: > > > > > + description: > > > > > + The phandle to the reference clock source. This corresponds to the > > > > > + hardware pin REFCLK. > > > > > + maxItems: 1 > > > > > + > > > > > + clock-names: > > > > > + const: refclk > > > > > + > > > > > +# The bridge can act as clock provider for the sensor. To enable this support > > > > > +# #clock-cells must be specified. Attention if this feature is used then the > > > > > +# mclk rate must be at least: (2 * link-frequency) / 8 > > > > > +# `------------------´ ^ > > > > > +# internal PLL rate smallest possible mclk-div > > > > > + "#clock-cells": > > > > > + const: 0 > > > > > + > > > > > + clock-output-names: > > > > > + description: > > > > > + The clock name of the MCLK output, the default name is tc358746-mclk. > > > > > + maxItems: 1 > > > > > + > > > > > + vddc-supply: > > > > > + description: Digital core voltage supply, 1.2 volts > > > > > + > > > > > + vddio-supply: > > > > > + description: Digital I/O voltage supply, 1.8 volts > > > > > + > > > > > + vddmipi-supply: > > > > > + description: MIPI CSI phy voltage supply, 1.2 volts > > > > > + > > > > > + reset-gpios: > > > > > + description: > > > > > + The phandle and specifier for the GPIO that controls the chip reset. > > > > > + This corresponds to the hardware pin RESX which is physically active low. > > > > > + maxItems: 1 > > > > > + > > > > > + ports: > > > > > + $ref: /schemas/graph.yaml#/properties/ports > > > > > + properties: > > > > > + port@0: > > > > > + $ref: /schemas/graph.yaml#/$defs/port-base > > > > > + description: Input port > > > > > + > > > > > + properties: > > > > > + endpoint: > > > > > + $ref: /schemas/media/video-interfaces.yaml# > > > > > + unevaluatedProperties: false > > > > > + > > > > > + properties: > > > > > + hsync-active: > > > > > + enum: > > > > > + - 0 # Hvalid active high > > > > > + vsync-active: > > > > > + enum: > > > > > + - 0 # Vvalid active high > > > > > + bus-type: > > > > > + enum: > > > > > + - 5 # Parallel > > > > > + > > > > > + required: > > > > > + - hsync-active > > > > > + - vsync-active > > > > > > > > Let's make bus-type required too, to prepare for BT.656 support. > > > > > > I would have done it when the BT.656 support is added. Since the BT.656 > > > don't require the sync signals I would have made a descision: > > > - either: hsync/vsync present -> parallel with external syncs, or > > > - bus-type present -> parallel bus with embedded syncs. > > > > > > So we don't bother the system-integrator with specifying unnecessary > > > properties. Also having v/hsync required in place with the bus-type (set > > > to bt.656) can cause confusion about the final used mode. > > > > The V4L2 fwnode framework can guess the type of the bus but it's not > > recommended to use the feature. > > Explicit bus types in DT indeed makes it easier for drivers, so if a > device can support multiple bus types (even if not implemented yet in > the corresponding drivers), the property should be there. Okay, I will make it required. > > Why do you have hsync-active and vsync-active if both are always zero? Can > > the hardware not support other configuration? Sure the device supports toggling the logic but it is not implemented. So the bindings needs to enforce it to 0 right now. As soon as it is implemented & tested, we can say that both is supported :) Regards, Marco
Hi Marco, On Tue, Sep 20, 2022 at 05:26:32PM +0200, Marco Felsch wrote: > On 22-09-19, Laurent Pinchart wrote: > > On Mon, Sep 19, 2022 at 10:23:55AM +0000, Sakari Ailus wrote: > > > On Mon, Sep 19, 2022 at 12:08:44PM +0200, Marco Felsch wrote: > > > > On 22-09-18, Laurent Pinchart wrote: > > > > > On Fri, Sep 16, 2022 at 03:45:34PM +0200, Marco Felsch wrote: > > > > > > Add the bindings for the Toshiba TC358746 Parallel <-> MIPI-CSI bridge > > > > > > driver. > > > > > > > > > > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > > > > > > Reviewed-by: Rob Herring <robh@kernel.org> > > > > > > --- > > > > > > Changelog: > > > > > > > > > > > > v2: > > > > > > - addded Robs r-b > > > > > > - s/than/then/ > > > > > > - added hsync/vsync/bus-type, make hsync/vsync required > > > > > > - fix example indent > > > > > > > > > > > > .../bindings/media/i2c/toshiba,tc358746.yaml | 179 ++++++++++++++++++ > > > > > > 1 file changed, 179 insertions(+) > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > > > new file mode 100644 > > > > > > index 000000000000..1fa574400bc2 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > > > > > > @@ -0,0 +1,179 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge > > > > > > + > > > > > > +maintainers: > > > > > > + - Marco Felsch <kernel@pengutronix.de> > > > > > > + > > > > > > +description: |- > > > > > > + The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2 > > > > > > + stream. The direction can be either parallel-in -> csi-out or csi-in -> > > > > > > + parallel-out The chip is programmable trough I2C and SPI but the SPI > > > > > > + interface is only supported in parallel-in -> csi-out mode. > > > > > > + > > > > > > + Note that the current device tree bindings only support the > > > > > > + parallel-in -> csi-out path. > > > > > > + > > > > > > +properties: > > > > > > + compatible: > > > > > > + const: toshiba,tc358746 > > > > > > + > > > > > > + reg: > > > > > > + maxItems: 1 > > > > > > + > > > > > > + clocks: > > > > > > + description: > > > > > > + The phandle to the reference clock source. This corresponds to the > > > > > > + hardware pin REFCLK. > > > > > > + maxItems: 1 > > > > > > + > > > > > > + clock-names: > > > > > > + const: refclk > > > > > > + > > > > > > +# The bridge can act as clock provider for the sensor. To enable this support > > > > > > +# #clock-cells must be specified. Attention if this feature is used then the > > > > > > +# mclk rate must be at least: (2 * link-frequency) / 8 > > > > > > +# `------------------´ ^ > > > > > > +# internal PLL rate smallest possible mclk-div > > > > > > + "#clock-cells": > > > > > > + const: 0 > > > > > > + > > > > > > + clock-output-names: > > > > > > + description: > > > > > > + The clock name of the MCLK output, the default name is tc358746-mclk. > > > > > > + maxItems: 1 > > > > > > + > > > > > > + vddc-supply: > > > > > > + description: Digital core voltage supply, 1.2 volts > > > > > > + > > > > > > + vddio-supply: > > > > > > + description: Digital I/O voltage supply, 1.8 volts > > > > > > + > > > > > > + vddmipi-supply: > > > > > > + description: MIPI CSI phy voltage supply, 1.2 volts > > > > > > + > > > > > > + reset-gpios: > > > > > > + description: > > > > > > + The phandle and specifier for the GPIO that controls the chip reset. > > > > > > + This corresponds to the hardware pin RESX which is physically active low. > > > > > > + maxItems: 1 > > > > > > + > > > > > > + ports: > > > > > > + $ref: /schemas/graph.yaml#/properties/ports > > > > > > + properties: > > > > > > + port@0: > > > > > > + $ref: /schemas/graph.yaml#/$defs/port-base > > > > > > + description: Input port > > > > > > + > > > > > > + properties: > > > > > > + endpoint: > > > > > > + $ref: /schemas/media/video-interfaces.yaml# > > > > > > + unevaluatedProperties: false > > > > > > + > > > > > > + properties: > > > > > > + hsync-active: > > > > > > + enum: > > > > > > + - 0 # Hvalid active high > > > > > > + vsync-active: > > > > > > + enum: > > > > > > + - 0 # Vvalid active high > > > > > > + bus-type: > > > > > > + enum: > > > > > > + - 5 # Parallel > > > > > > + > > > > > > + required: > > > > > > + - hsync-active > > > > > > + - vsync-active > > > > > > > > > > Let's make bus-type required too, to prepare for BT.656 support. > > > > > > > > I would have done it when the BT.656 support is added. Since the BT.656 > > > > don't require the sync signals I would have made a descision: > > > > - either: hsync/vsync present -> parallel with external syncs, or > > > > - bus-type present -> parallel bus with embedded syncs. > > > > > > > > So we don't bother the system-integrator with specifying unnecessary > > > > properties. Also having v/hsync required in place with the bus-type (set > > > > to bt.656) can cause confusion about the final used mode. > > > > > > The V4L2 fwnode framework can guess the type of the bus but it's not > > > recommended to use the feature. > > > > Explicit bus types in DT indeed makes it easier for drivers, so if a > > device can support multiple bus types (even if not implemented yet in > > the corresponding drivers), the property should be there. > > Okay, I will make it required. > > > > Why do you have hsync-active and vsync-active if both are always zero? Can > > > the hardware not support other configuration? > > Sure the device supports toggling the logic but it is not implemented. > So the bindings needs to enforce it to 0 right now. As soon as it is > implemented & tested, we can say that both is supported :) Bindings are not supposed to be limited by the existing driver implementation, so you can already allow both polarities, and just reject the unsupported options in the driver at probe time. Future updates to the driver won't require a binding change.
On 20/09/2022 19:32, Laurent Pinchart wrote: >>> >>> Explicit bus types in DT indeed makes it easier for drivers, so if a >>> device can support multiple bus types (even if not implemented yet in >>> the corresponding drivers), the property should be there. >> >> Okay, I will make it required. >> >>>> Why do you have hsync-active and vsync-active if both are always zero? Can >>>> the hardware not support other configuration? >> >> Sure the device supports toggling the logic but it is not implemented. >> So the bindings needs to enforce it to 0 right now. As soon as it is >> implemented & tested, we can say that both is supported :) > > Bindings are not supposed to be limited by the existing driver > implementation, so you can already allow both polarities, and just > reject the unsupported options in the driver at probe time. Future > updates to the driver won't require a binding change. > +1 Best regards, Krzysztof
On 22-09-21, Krzysztof Kozlowski wrote: > On 20/09/2022 19:32, Laurent Pinchart wrote: > >>> > >>> Explicit bus types in DT indeed makes it easier for drivers, so if a > >>> device can support multiple bus types (even if not implemented yet in > >>> the corresponding drivers), the property should be there. > >> > >> Okay, I will make it required. > >> > >>>> Why do you have hsync-active and vsync-active if both are always zero? Can > >>>> the hardware not support other configuration? > >> > >> Sure the device supports toggling the logic but it is not implemented. > >> So the bindings needs to enforce it to 0 right now. As soon as it is > >> implemented & tested, we can say that both is supported :) > > > > Bindings are not supposed to be limited by the existing driver > > implementation, so you can already allow both polarities, and just > > reject the unsupported options in the driver at probe time. Future > > updates to the driver won't require a binding change. > > > > +1 I don't wanna do that because this let the binding user assume that this mode is already supported. Adapting a binding is just 1 commit and since the property is already existing, there is no breaking change. Regards, Marco
On 21/09/2022 10:35, Marco Felsch wrote: > On 22-09-21, Krzysztof Kozlowski wrote: >> On 20/09/2022 19:32, Laurent Pinchart wrote: >>>>> >>>>> Explicit bus types in DT indeed makes it easier for drivers, so if a >>>>> device can support multiple bus types (even if not implemented yet in >>>>> the corresponding drivers), the property should be there. >>>> >>>> Okay, I will make it required. >>>> >>>>>> Why do you have hsync-active and vsync-active if both are always zero? Can >>>>>> the hardware not support other configuration? >>>> >>>> Sure the device supports toggling the logic but it is not implemented. >>>> So the bindings needs to enforce it to 0 right now. As soon as it is >>>> implemented & tested, we can say that both is supported :) >>> >>> Bindings are not supposed to be limited by the existing driver >>> implementation, so you can already allow both polarities, and just >>> reject the unsupported options in the driver at probe time. Future >>> updates to the driver won't require a binding change. >>> >> >> +1 > > I don't wanna do that because this let the binding user assume that > this mode is already supported. What do you mean by "not supported"? By which system? By which firmware element? Bindings are used by several operating systems and several projects. That's not the argument. Bindings should be complete. Lack of knowledge and datasheets is a good exception from this rule. Looking at Linux driver is not good exception. > Adapting a binding is just 1 commit and > since the property is already existing, there is no breaking change. Best regards, Krzysztof
On 22-09-21, Krzysztof Kozlowski wrote: > On 21/09/2022 10:35, Marco Felsch wrote: > > On 22-09-21, Krzysztof Kozlowski wrote: > >> On 20/09/2022 19:32, Laurent Pinchart wrote: > >>>>> > >>>>> Explicit bus types in DT indeed makes it easier for drivers, so if a > >>>>> device can support multiple bus types (even if not implemented yet in > >>>>> the corresponding drivers), the property should be there. > >>>> > >>>> Okay, I will make it required. > >>>> > >>>>>> Why do you have hsync-active and vsync-active if both are always zero? Can > >>>>>> the hardware not support other configuration? > >>>> > >>>> Sure the device supports toggling the logic but it is not implemented. > >>>> So the bindings needs to enforce it to 0 right now. As soon as it is > >>>> implemented & tested, we can say that both is supported :) > >>> > >>> Bindings are not supposed to be limited by the existing driver > >>> implementation, so you can already allow both polarities, and just > >>> reject the unsupported options in the driver at probe time. Future > >>> updates to the driver won't require a binding change. > >>> > >> > >> +1 > > > > I don't wanna do that because this let the binding user assume that > > this mode is already supported. > > What do you mean by "not supported"? By which system? By which firmware > element? Bindings are used by several operating systems and several > projects. And they can use it and of course extend it, since the propery is available. > That's not the argument. > > Bindings should be complete. Lack of knowledge and datasheets is a good > exception from this rule. Looking at Linux driver is not good exception. So if I get you right, you are saying that the bindings should always be complete and describe all ever possible combinations? I am on your side that the properties should be there from day one. But listing all possible values regardless of the support.. I don't know and yes, I know that other projects using these bindings as well. But if those other projects support more than now, they can extend it and send patches. Since this is a new binding, the only user is Linux and listing all possible values can lead into erroneous assumption. No system-integrator wants to check the driver why a listed property is not supported instead most the time it is the other way. If it is listed, than it should be supported. Anyway I don't wanna make a big deal out of it. I will add all possible values to the binding if that is what you want :) Regards, Marco > > Adapting a binding is just 1 commit and > > since the property is already existing, there is no breaking change. > Best regards, > Krzysztof > >
On 22/09/2022 13:01, Marco Felsch wrote: > On 22-09-21, Krzysztof Kozlowski wrote: >> On 21/09/2022 10:35, Marco Felsch wrote: >>> On 22-09-21, Krzysztof Kozlowski wrote: >>>> On 20/09/2022 19:32, Laurent Pinchart wrote: >>>>>>> >>>>>>> Explicit bus types in DT indeed makes it easier for drivers, so if a >>>>>>> device can support multiple bus types (even if not implemented yet in >>>>>>> the corresponding drivers), the property should be there. >>>>>> >>>>>> Okay, I will make it required. >>>>>> >>>>>>>> Why do you have hsync-active and vsync-active if both are always zero? Can >>>>>>>> the hardware not support other configuration? >>>>>> >>>>>> Sure the device supports toggling the logic but it is not implemented. >>>>>> So the bindings needs to enforce it to 0 right now. As soon as it is >>>>>> implemented & tested, we can say that both is supported :) >>>>> >>>>> Bindings are not supposed to be limited by the existing driver >>>>> implementation, so you can already allow both polarities, and just >>>>> reject the unsupported options in the driver at probe time. Future >>>>> updates to the driver won't require a binding change. >>>>> >>>> >>>> +1 >>> >>> I don't wanna do that because this let the binding user assume that >>> this mode is already supported. >> >> What do you mean by "not supported"? By which system? By which firmware >> element? Bindings are used by several operating systems and several >> projects. > > And they can use it and of course extend it, since the propery is > available. > >> That's not the argument. >> >> Bindings should be complete. Lack of knowledge and datasheets is a good >> exception from this rule. Looking at Linux driver is not good exception. > > So if I get you right, you are saying that the bindings should always be > complete and describe all ever possible combinations? Not necessarily all combinations, but in general be complete as in describe entire device. Pretty often we skip describing full device because our job does not include it and we need to move on. Fine. But the argument is not really one Linux implementation. Especially that limiting binding to some subset might make it later non-extendable. Not possible to grow, because author did not think about these other features. > I am on your side > that the properties should be there from day one. But listing all > possible values regardless of the support.. I don't know and yes, I know > that other projects using these bindings as well. But if those other > projects support more than now, they can extend it and send patches. > Since this is a new binding, the only user is Linux and listing all > possible values can lead into erroneous assumption. So let me rephrase the case - there is no such assumption that one, particular driver supports entire set of bindings. If anyone makes it, without actually checking, then it is his/hers mistake. > No system-integrator > wants to check the driver why a listed property is not supported instead > most the time it is the other way. If it is listed, than it should be > supported. Bindings are also not the tool for system integrator to figure out these things. > > Anyway I don't wanna make a big deal out of it. I will add all possible > values to the binding if that is what you want :) > > Regards, > Marco > >>> Adapting a binding is just 1 commit and >>> since the property is already existing, there is no breaking change. >> Best regards, >> Krzysztof >> >> Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml new file mode 100644 index 000000000000..1fa574400bc2 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml @@ -0,0 +1,179 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge + +maintainers: + - Marco Felsch <kernel@pengutronix.de> + +description: |- + The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2 + stream. The direction can be either parallel-in -> csi-out or csi-in -> + parallel-out The chip is programmable trough I2C and SPI but the SPI + interface is only supported in parallel-in -> csi-out mode. + + Note that the current device tree bindings only support the + parallel-in -> csi-out path. + +properties: + compatible: + const: toshiba,tc358746 + + reg: + maxItems: 1 + + clocks: + description: + The phandle to the reference clock source. This corresponds to the + hardware pin REFCLK. + maxItems: 1 + + clock-names: + const: refclk + +# The bridge can act as clock provider for the sensor. To enable this support +# #clock-cells must be specified. Attention if this feature is used then the +# mclk rate must be at least: (2 * link-frequency) / 8 +# `------------------´ ^ +# internal PLL rate smallest possible mclk-div + "#clock-cells": + const: 0 + + clock-output-names: + description: + The clock name of the MCLK output, the default name is tc358746-mclk. + maxItems: 1 + + vddc-supply: + description: Digital core voltage supply, 1.2 volts + + vddio-supply: + description: Digital I/O voltage supply, 1.8 volts + + vddmipi-supply: + description: MIPI CSI phy voltage supply, 1.2 volts + + reset-gpios: + description: + The phandle and specifier for the GPIO that controls the chip reset. + This corresponds to the hardware pin RESX which is physically active low. + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + description: Input port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + hsync-active: + enum: + - 0 # Hvalid active high + vsync-active: + enum: + - 0 # Vvalid active high + bus-type: + enum: + - 5 # Parallel + + required: + - hsync-active + - vsync-active + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + description: Output port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + clock-noncontinuous: true + link-frequencies: true + + required: + - data-lanes + - link-frequencies + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - clocks + - clock-names + - vddc-supply + - vddio-supply + - vddmipi-supply + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + csi-bridge@e { + compatible = "toshiba,tc358746"; + reg = <0xe>; + + clocks = <&refclk>; + clock-names = "refclk"; + + reset-gpios = <&gpio 2 GPIO_ACTIVE_LOW>; + + vddc-supply = <&v1_2d>; + vddio-supply = <&v1_8d>; + vddmipi-supply = <&v1_2d>; + + /* sensor mclk provider */ + #clock-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + /* Input */ + port@0 { + reg = <0>; + tc358746_in: endpoint { + remote-endpoint = <&sensor_out>; + hsync-active = <0>; + vsync-active = <0>; + }; + }; + + /* Output */ + port@1 { + reg = <1>; + tc358746_out: endpoint { + remote-endpoint = <&mipi_csi2_in>; + data-lanes = <1 2>; + clock-noncontinuous; + link-frequencies = /bits/ 64 <216000000>; + }; + }; + }; + }; + };