From: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
To: robh+dt@kernel.org
Cc: kernel@collabora.com, devicetree@vger.kernel.org,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org, jason@lakedaemon.net,
tomi.valkeinen@ti.com
Subject: [RFC PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml
Date: Tue, 28 Apr 2020 11:20:48 +0200 [thread overview]
Message-ID: <20200428092048.14939-1-ricardo.canuelo@collabora.com> (raw)
Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
encoder to json-schema.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
Hi all,
I found some issues while converting this binding and I'd like to know
your opinions on how to tackle them.
1) dtbs_check fails for arch/arm/boot/dts/dove-sbc-a510.dts
This board uses the TFP410 encoder but it doesn't define any ports for
it. I can't find any suitable remote endpoints in its description
either. Maybe this board description should be reworked? The current
driver won't handle the device if it doesn't define any ports or
endpoints anyway.
It also uses the 'powerdown-gpio' property instead of
'powerdown-gpios'. AFAICT this shouldn't be a problem from the driver
point of view, but the general standard in DT bindings is to use the
plural. This is trivial to fix.
2) The definition of ti,deskew in the original binding seems to be
tailored to the current driver and the way it's defined may not be very
DT-friendly.
This parameter maps to a 3-bit field in a hardware register that takes
a value from 0 to 7, so the [-4, 3] range described for this would map
to [000, 111]: -4 -> 000, -3 -> 001, -2 -> 010, ... 3 -> 111.
Then, the driver parses the parameter (unsigned) and casts it to a
signed integer to get a number in the [-4, 3] range.
A vendor-specific property must have a type definition in json-schema,
so if I translate the original bindings semantics directly, I should
define ti,deskew as an int32, but this makes dt_binding_check fail if
the property has a negative value in the example because of the
internal representation of cells as unsigned integers:
ti,deskew:0:0: 4294967293 is greater than the maximum of 2147483647
So I can think of two solutions to this:
a) Keep the ti,deskew property as an uint32 and document the valid
range ([-4, 3]) in the property description (this is what this patch
does currently).
b) Redefine this property to be closer to the datasheet description
(ie. unsigned integers from 0 to 7) and adapt the driver accordingly.
This would also let us define its range properly using minimum and
maximum properties for it.
I think (b) is the right thing to do but I want to know your
opinion. Besides, I don't have this hardware at hand and if I updated
the driver I wouldn't be able to test it.
Thanks.
Patch tested with:
make dt_binding_check ARCH=arm DT_SCHEMA_FILES=<.../ti,tfp410.yaml>
make dtbs_check ARCH=arm DT_SCHEMA_FILES=<.../ti,tfp410.yaml>
.../bindings/display/bridge/ti,tfp410.txt | 66 ----------
.../bindings/display/bridge/ti,tfp410.yaml | 121 ++++++++++++++++++
2 files changed, 121 insertions(+), 66 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
deleted file mode 100644
index 5ff4f64ef8e8..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-TFP410 DPI to DVI encoder
-=========================
-
-Required properties:
-- compatible: "ti,tfp410"
-
-Optional properties:
-- powerdown-gpios: power-down gpio
-- reg: I2C address. If and only if present the device node should be placed
- into the I2C controller node where the TFP410 I2C is connected to.
-- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
- through th DK[3:1] pins. This property shall be present only if the TFP410
- is not connected through I2C.
-
-Required nodes:
-
-This device has two video ports. Their connections are modeled using the OF
-graph bindings specified in [1]. Each port node shall have a single endpoint.
-
-- Port 0 is the DPI input port. Its endpoint subnode shall contain a
- pclk-sample and bus-width property and a remote-endpoint property as specified
- in [1].
- - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
- backward compatibility.
- - If bus-width is not defined then bus-width = 24 should be assumed for
- backward compatibility.
- bus-width = 24: 24 data lines are connected and single-edge mode
- bus-width = 12: 12 data lines are connected and dual-edge mode
-
-- Port 1 is the DVI output port. Its endpoint subnode shall contain a
- remote-endpoint property is specified in [1].
-
-[1] Documentation/devicetree/bindings/media/video-interfaces.txt
-
-
-Example
--------
-
-tfp410: encoder@0 {
- compatible = "ti,tfp410";
- powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
- ti,deskew = <4>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- tfp410_in: endpoint@0 {
- pclk-sample = <1>;
- bus-width = <24>;
- remote-endpoint = <&dpi_out>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- tfp410_out: endpoint@0 {
- remote-endpoint = <&dvi_connector_in>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
new file mode 100644
index 000000000000..79666ee540f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TFP410 DPI to DVI encoder
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ti.com>
+ - Jyri Sarha <jsarha@ti.com>
+
+properties:
+ compatible:
+ const: "ti,tfp410"
+
+ reg:
+ description: I2C address of the device.
+ maxItems: 1
+
+ powerdown-gpios:
+ maxItems: 1
+
+ ti,deskew:
+ description:
+ Data de-skew in 350ps increments, from -4 to +3, as configured
+ through the DK[3:1] pins. This property shall be present only if
+ the TFP410 is not connected through I2C.
+ maxItems: 1
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ ports:
+ description:
+ A node containing input and output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ type: object
+
+ properties:
+ port@0:
+ description: DPI input port.
+ type: object
+
+ properties:
+ reg:
+ const: 0
+
+ endpoint:
+ type: object
+
+ properties:
+ pclk-sample:
+ description: Endpoint sampling edge.
+ enum:
+ - 0 # Falling edge
+ - 1 # Rising edge
+
+ bus-width:
+ description: Endpoint bus width.
+ enum: [ 12, 24 ]
+
+ required:
+ - endpoint
+
+ port@1:
+ description: DVI output port.
+ type: object
+
+ properties:
+ reg:
+ const: 1
+
+ endpoint:
+ type: object
+
+ required:
+ - endpoint
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ tfp410: encoder {
+ compatible = "ti,tfp410";
+ powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+ ti,deskew = <3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tfp410_in: endpoint {
+ pclk-sample = <1>;
+ bus-width = <24>;
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ tfp410_out: endpoint {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+...
--
2.18.0
WARNING: multiple messages have this Message-ID (diff)
From: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
To: robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, jason@lakedaemon.net,
dri-devel@lists.freedesktop.org, tomi.valkeinen@ti.com,
kernel@collabora.com, linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml
Date: Tue, 28 Apr 2020 11:20:48 +0200 [thread overview]
Message-ID: <20200428092048.14939-1-ricardo.canuelo@collabora.com> (raw)
Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
encoder to json-schema.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
Hi all,
I found some issues while converting this binding and I'd like to know
your opinions on how to tackle them.
1) dtbs_check fails for arch/arm/boot/dts/dove-sbc-a510.dts
This board uses the TFP410 encoder but it doesn't define any ports for
it. I can't find any suitable remote endpoints in its description
either. Maybe this board description should be reworked? The current
driver won't handle the device if it doesn't define any ports or
endpoints anyway.
It also uses the 'powerdown-gpio' property instead of
'powerdown-gpios'. AFAICT this shouldn't be a problem from the driver
point of view, but the general standard in DT bindings is to use the
plural. This is trivial to fix.
2) The definition of ti,deskew in the original binding seems to be
tailored to the current driver and the way it's defined may not be very
DT-friendly.
This parameter maps to a 3-bit field in a hardware register that takes
a value from 0 to 7, so the [-4, 3] range described for this would map
to [000, 111]: -4 -> 000, -3 -> 001, -2 -> 010, ... 3 -> 111.
Then, the driver parses the parameter (unsigned) and casts it to a
signed integer to get a number in the [-4, 3] range.
A vendor-specific property must have a type definition in json-schema,
so if I translate the original bindings semantics directly, I should
define ti,deskew as an int32, but this makes dt_binding_check fail if
the property has a negative value in the example because of the
internal representation of cells as unsigned integers:
ti,deskew:0:0: 4294967293 is greater than the maximum of 2147483647
So I can think of two solutions to this:
a) Keep the ti,deskew property as an uint32 and document the valid
range ([-4, 3]) in the property description (this is what this patch
does currently).
b) Redefine this property to be closer to the datasheet description
(ie. unsigned integers from 0 to 7) and adapt the driver accordingly.
This would also let us define its range properly using minimum and
maximum properties for it.
I think (b) is the right thing to do but I want to know your
opinion. Besides, I don't have this hardware at hand and if I updated
the driver I wouldn't be able to test it.
Thanks.
Patch tested with:
make dt_binding_check ARCH=arm DT_SCHEMA_FILES=<.../ti,tfp410.yaml>
make dtbs_check ARCH=arm DT_SCHEMA_FILES=<.../ti,tfp410.yaml>
.../bindings/display/bridge/ti,tfp410.txt | 66 ----------
.../bindings/display/bridge/ti,tfp410.yaml | 121 ++++++++++++++++++
2 files changed, 121 insertions(+), 66 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
deleted file mode 100644
index 5ff4f64ef8e8..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-TFP410 DPI to DVI encoder
-=========================
-
-Required properties:
-- compatible: "ti,tfp410"
-
-Optional properties:
-- powerdown-gpios: power-down gpio
-- reg: I2C address. If and only if present the device node should be placed
- into the I2C controller node where the TFP410 I2C is connected to.
-- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
- through th DK[3:1] pins. This property shall be present only if the TFP410
- is not connected through I2C.
-
-Required nodes:
-
-This device has two video ports. Their connections are modeled using the OF
-graph bindings specified in [1]. Each port node shall have a single endpoint.
-
-- Port 0 is the DPI input port. Its endpoint subnode shall contain a
- pclk-sample and bus-width property and a remote-endpoint property as specified
- in [1].
- - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
- backward compatibility.
- - If bus-width is not defined then bus-width = 24 should be assumed for
- backward compatibility.
- bus-width = 24: 24 data lines are connected and single-edge mode
- bus-width = 12: 12 data lines are connected and dual-edge mode
-
-- Port 1 is the DVI output port. Its endpoint subnode shall contain a
- remote-endpoint property is specified in [1].
-
-[1] Documentation/devicetree/bindings/media/video-interfaces.txt
-
-
-Example
--------
-
-tfp410: encoder@0 {
- compatible = "ti,tfp410";
- powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
- ti,deskew = <4>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- tfp410_in: endpoint@0 {
- pclk-sample = <1>;
- bus-width = <24>;
- remote-endpoint = <&dpi_out>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- tfp410_out: endpoint@0 {
- remote-endpoint = <&dvi_connector_in>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
new file mode 100644
index 000000000000..79666ee540f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TFP410 DPI to DVI encoder
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ti.com>
+ - Jyri Sarha <jsarha@ti.com>
+
+properties:
+ compatible:
+ const: "ti,tfp410"
+
+ reg:
+ description: I2C address of the device.
+ maxItems: 1
+
+ powerdown-gpios:
+ maxItems: 1
+
+ ti,deskew:
+ description:
+ Data de-skew in 350ps increments, from -4 to +3, as configured
+ through the DK[3:1] pins. This property shall be present only if
+ the TFP410 is not connected through I2C.
+ maxItems: 1
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ ports:
+ description:
+ A node containing input and output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ type: object
+
+ properties:
+ port@0:
+ description: DPI input port.
+ type: object
+
+ properties:
+ reg:
+ const: 0
+
+ endpoint:
+ type: object
+
+ properties:
+ pclk-sample:
+ description: Endpoint sampling edge.
+ enum:
+ - 0 # Falling edge
+ - 1 # Rising edge
+
+ bus-width:
+ description: Endpoint bus width.
+ enum: [ 12, 24 ]
+
+ required:
+ - endpoint
+
+ port@1:
+ description: DVI output port.
+ type: object
+
+ properties:
+ reg:
+ const: 1
+
+ endpoint:
+ type: object
+
+ required:
+ - endpoint
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ tfp410: encoder {
+ compatible = "ti,tfp410";
+ powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+ ti,deskew = <3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tfp410_in: endpoint {
+ pclk-sample = <1>;
+ bus-width = <24>;
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ tfp410_out: endpoint {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+...
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
To: robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, jason@lakedaemon.net,
dri-devel@lists.freedesktop.org, tomi.valkeinen@ti.com,
kernel@collabora.com, linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml
Date: Tue, 28 Apr 2020 11:20:48 +0200 [thread overview]
Message-ID: <20200428092048.14939-1-ricardo.canuelo@collabora.com> (raw)
Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
encoder to json-schema.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
Hi all,
I found some issues while converting this binding and I'd like to know
your opinions on how to tackle them.
1) dtbs_check fails for arch/arm/boot/dts/dove-sbc-a510.dts
This board uses the TFP410 encoder but it doesn't define any ports for
it. I can't find any suitable remote endpoints in its description
either. Maybe this board description should be reworked? The current
driver won't handle the device if it doesn't define any ports or
endpoints anyway.
It also uses the 'powerdown-gpio' property instead of
'powerdown-gpios'. AFAICT this shouldn't be a problem from the driver
point of view, but the general standard in DT bindings is to use the
plural. This is trivial to fix.
2) The definition of ti,deskew in the original binding seems to be
tailored to the current driver and the way it's defined may not be very
DT-friendly.
This parameter maps to a 3-bit field in a hardware register that takes
a value from 0 to 7, so the [-4, 3] range described for this would map
to [000, 111]: -4 -> 000, -3 -> 001, -2 -> 010, ... 3 -> 111.
Then, the driver parses the parameter (unsigned) and casts it to a
signed integer to get a number in the [-4, 3] range.
A vendor-specific property must have a type definition in json-schema,
so if I translate the original bindings semantics directly, I should
define ti,deskew as an int32, but this makes dt_binding_check fail if
the property has a negative value in the example because of the
internal representation of cells as unsigned integers:
ti,deskew:0:0: 4294967293 is greater than the maximum of 2147483647
So I can think of two solutions to this:
a) Keep the ti,deskew property as an uint32 and document the valid
range ([-4, 3]) in the property description (this is what this patch
does currently).
b) Redefine this property to be closer to the datasheet description
(ie. unsigned integers from 0 to 7) and adapt the driver accordingly.
This would also let us define its range properly using minimum and
maximum properties for it.
I think (b) is the right thing to do but I want to know your
opinion. Besides, I don't have this hardware at hand and if I updated
the driver I wouldn't be able to test it.
Thanks.
Patch tested with:
make dt_binding_check ARCH=arm DT_SCHEMA_FILES=<.../ti,tfp410.yaml>
make dtbs_check ARCH=arm DT_SCHEMA_FILES=<.../ti,tfp410.yaml>
.../bindings/display/bridge/ti,tfp410.txt | 66 ----------
.../bindings/display/bridge/ti,tfp410.yaml | 121 ++++++++++++++++++
2 files changed, 121 insertions(+), 66 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
deleted file mode 100644
index 5ff4f64ef8e8..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-TFP410 DPI to DVI encoder
-=========================
-
-Required properties:
-- compatible: "ti,tfp410"
-
-Optional properties:
-- powerdown-gpios: power-down gpio
-- reg: I2C address. If and only if present the device node should be placed
- into the I2C controller node where the TFP410 I2C is connected to.
-- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
- through th DK[3:1] pins. This property shall be present only if the TFP410
- is not connected through I2C.
-
-Required nodes:
-
-This device has two video ports. Their connections are modeled using the OF
-graph bindings specified in [1]. Each port node shall have a single endpoint.
-
-- Port 0 is the DPI input port. Its endpoint subnode shall contain a
- pclk-sample and bus-width property and a remote-endpoint property as specified
- in [1].
- - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
- backward compatibility.
- - If bus-width is not defined then bus-width = 24 should be assumed for
- backward compatibility.
- bus-width = 24: 24 data lines are connected and single-edge mode
- bus-width = 12: 12 data lines are connected and dual-edge mode
-
-- Port 1 is the DVI output port. Its endpoint subnode shall contain a
- remote-endpoint property is specified in [1].
-
-[1] Documentation/devicetree/bindings/media/video-interfaces.txt
-
-
-Example
--------
-
-tfp410: encoder@0 {
- compatible = "ti,tfp410";
- powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
- ti,deskew = <4>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- tfp410_in: endpoint@0 {
- pclk-sample = <1>;
- bus-width = <24>;
- remote-endpoint = <&dpi_out>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- tfp410_out: endpoint@0 {
- remote-endpoint = <&dvi_connector_in>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
new file mode 100644
index 000000000000..79666ee540f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TFP410 DPI to DVI encoder
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ti.com>
+ - Jyri Sarha <jsarha@ti.com>
+
+properties:
+ compatible:
+ const: "ti,tfp410"
+
+ reg:
+ description: I2C address of the device.
+ maxItems: 1
+
+ powerdown-gpios:
+ maxItems: 1
+
+ ti,deskew:
+ description:
+ Data de-skew in 350ps increments, from -4 to +3, as configured
+ through the DK[3:1] pins. This property shall be present only if
+ the TFP410 is not connected through I2C.
+ maxItems: 1
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ ports:
+ description:
+ A node containing input and output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ type: object
+
+ properties:
+ port@0:
+ description: DPI input port.
+ type: object
+
+ properties:
+ reg:
+ const: 0
+
+ endpoint:
+ type: object
+
+ properties:
+ pclk-sample:
+ description: Endpoint sampling edge.
+ enum:
+ - 0 # Falling edge
+ - 1 # Rising edge
+
+ bus-width:
+ description: Endpoint bus width.
+ enum: [ 12, 24 ]
+
+ required:
+ - endpoint
+
+ port@1:
+ description: DVI output port.
+ type: object
+
+ properties:
+ reg:
+ const: 1
+
+ endpoint:
+ type: object
+
+ required:
+ - endpoint
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ tfp410: encoder {
+ compatible = "ti,tfp410";
+ powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+ ti,deskew = <3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tfp410_in: endpoint {
+ pclk-sample = <1>;
+ bus-width = <24>;
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ tfp410_out: endpoint {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+...
--
2.18.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2020-04-28 9:21 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 9:20 Ricardo Cañuelo [this message]
2020-04-28 9:20 ` [RFC PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml Ricardo Cañuelo
2020-04-28 9:20 ` Ricardo Cañuelo
2020-04-28 9:49 ` Tomi Valkeinen
2020-04-28 9:49 ` Tomi Valkeinen
2020-04-28 9:49 ` Tomi Valkeinen
2020-05-06 7:21 ` Ricardo Cañuelo
2020-05-06 7:21 ` Ricardo Cañuelo
2020-05-06 7:21 ` Ricardo Cañuelo
2020-05-06 8:01 ` Tomi Valkeinen
2020-05-06 8:01 ` Tomi Valkeinen
2020-05-06 8:01 ` Tomi Valkeinen
2020-05-06 8:28 ` Ricardo Cañuelo
2020-05-06 8:28 ` Ricardo Cañuelo
2020-05-06 8:28 ` Ricardo Cañuelo
2020-05-06 8:33 ` Tomi Valkeinen
2020-05-06 8:33 ` Tomi Valkeinen
2020-05-06 8:33 ` Tomi Valkeinen
2020-05-06 15:53 ` Laurent Pinchart
2020-05-06 15:53 ` Laurent Pinchart
2020-05-06 15:53 ` Laurent Pinchart
2020-05-11 14:59 ` Ricardo Cañuelo
2020-05-11 14:59 ` Ricardo Cañuelo
2020-05-11 14:59 ` Ricardo Cañuelo
2020-05-11 16:26 ` Sam Ravnborg
2020-05-11 16:26 ` Sam Ravnborg
2020-05-11 16:26 ` Sam Ravnborg
2020-05-12 2:09 ` Rob Herring
2020-05-12 2:09 ` Rob Herring
2020-05-12 2:09 ` Rob Herring
2020-05-13 11:09 ` Ricardo Cañuelo
2020-05-13 11:09 ` Ricardo Cañuelo
2020-05-13 11:09 ` Ricardo Cañuelo
2020-05-13 14:08 ` Laurent Pinchart
2020-05-13 14:08 ` Laurent Pinchart
2020-05-13 14:08 ` Laurent Pinchart
2020-05-13 14:20 ` Ricardo Cañuelo
2020-05-13 14:20 ` Ricardo Cañuelo
2020-05-13 14:20 ` Ricardo Cañuelo
2020-04-28 19:21 ` Sam Ravnborg
2020-04-28 19:21 ` Sam Ravnborg
2020-04-28 19:21 ` Sam Ravnborg
2020-04-29 8:54 ` Ricardo Cañuelo
2020-04-29 8:54 ` Ricardo Cañuelo
2020-04-29 8:54 ` Ricardo Cañuelo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200428092048.14939-1-ricardo.canuelo@collabora.com \
--to=ricardo.canuelo@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jason@lakedaemon.net \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.