[RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[Rob Herring]

Convert the common panel bindings to DT schema consolidating scattered
definitions to a single schema file.

The 'simple-panel' binding just a collection of properties and not a
complete binding itself. All of the 'simple-panel' properties are
covered by the panel-common.txt binding with the exception of the
'no-hpd' property, so add that to the schema.

As there are lots of references to simple-panel.txt, just keep the file
with a reference to panel-common.yaml for now until all the bindings are
converted.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
Note there's still some references to panel-common.txt that I need to 
update or just go ahead and convert to schema.

 .../bindings/display/panel/panel-common.txt   | 101 -------------
 .../bindings/display/panel/panel-common.yaml  | 143 ++++++++++++++++++
 .../bindings/display/panel/panel.txt          |   4 -
 .../bindings/display/panel/simple-panel.txt   |  29 +---
 4 files changed, 144 insertions(+), 133 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt b/Documentation/devicetree/bindings/display/panel/panel-common.txt
deleted file mode 100644
index 5d2519af4bb5..000000000000
--- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-Common Properties for Display Panel
-===================================
-
-This document defines device tree properties common to several classes of
-display panels. It doesn't constitue a device tree binding specification by
-itself but is meant to be referenced by device tree bindings.
-
-When referenced from panel device tree bindings the properties defined in this
-document are defined as follows. The panel device tree bindings are
-responsible for defining whether each property is required or optional.
-
-
-Descriptive Properties
-----------------------
-
-- width-mm,
-- height-mm: The width-mm and height-mm specify the width and height of the
-  physical area where images are displayed. These properties are expressed in
-  millimeters and rounded to the closest unit.
-
-- label: The label property specifies a symbolic name for the panel as a
-  string suitable for use by humans. It typically contains a name inscribed on
-  the system (e.g. as an affixed label) or specified in the system's
-  documentation (e.g. in the user's manual).
-
-  If no such name exists, and unless the property is mandatory according to
-  device tree bindings, it shall rather be omitted than constructed of
-  non-descriptive information. For instance an LCD panel in a system that
-  contains a single panel shall not be labelled "LCD" if that name is not
-  inscribed on the system or used in a descriptive fashion in system
-  documentation.
-
-
-Display Timings
----------------
-
-- panel-timing: Most display panels are restricted to a single resolution and
-  require specific display timings. The panel-timing subnode expresses those
-  timings as specified in the timing subnode section of the display timing
-  bindings defined in
-  Documentation/devicetree/bindings/display/panel/display-timing.txt.
-
-
-Connectivity
-------------
-
-- ports: Panels receive video data through one or multiple connections. While
-  the nature of those connections is specific to the panel type, the
-  connectivity is expressed in a standard fashion using ports as specified in
-  the device graph bindings defined in
-  Documentation/devicetree/bindings/graph.txt.
-
-- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible
-  bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
-  phandle to the system I2C controller connected to that bus.
-
-
-Control I/Os
-------------
-
-Many display panels can be controlled through pins driven by GPIOs. The nature
-and timing of those control signals are device-specific and left for panel
-device tree bindings to specify. The following GPIO specifiers can however be
-used for panels that implement compatible control signals.
-
-- enable-gpios: Specifier for a GPIO connected to the panel enable control
-  signal. The enable signal is active high and enables operation of the panel.
-  This property can also be used for panels implementing an active low power
-  down signal, which is a negated version of the enable signal. Active low
-  enable signals (or active high power down signals) can be supported by
-  inverting the GPIO specifier polarity flag.
-
-  Note that the enable signal control panel operation only and must not be
-  confused with a backlight enable signal.
-
-- reset-gpios: Specifier for a GPIO coonnected to the panel reset control
-  signal. The reset signal is active low and resets the panel internal logic
-  while active. Active high reset signals can be supported by inverting the
-  GPIO specifier polarity flag.
-
-Power
------
-
-- power-supply: display panels require power to be supplied. While several
-  panels need more than one power supply with panel-specific constraints
-  governing the order and timings of the power supplies, in many cases a single
-  power supply is sufficient, either because the panel has a single power rail,
-  or because all its power rails can be driven by the same supply. In that case
-  the power-supply property specifies the supply powering the panel as a phandle
-  to a regulator.
-
-Backlight
----------
-
-Most display panels include a backlight. Some of them also include a backlight
-controller exposed through a control bus such as I2C or DSI. Others expose
-backlight control through GPIO, PWM or other signals connected to an external
-backlight controller.
-
-- backlight: For panels whose backlight is controlled by an external backlight
-  controller, this property contains a phandle that references the controller.
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
new file mode 100644
index 000000000000..6fe87254edad
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Properties for Display Panels
+
+maintainers:
+  - Thierry Reding <thierry.reding@gmail.com>
+  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+
+description: |
+  This document defines device tree properties common to several classes of
+  display panels. It doesn't constitue a device tree binding specification by
+  itself but is meant to be referenced by device tree bindings.
+
+  When referenced from panel device tree bindings the properties defined in this
+  document are defined as follows. The panel device tree bindings are
+  responsible for defining whether each property is required or optional.
+
+
+properties:
+  # Descriptive Properties
+  width-mm:
+    description: The width-mm and height-mm specify the width and height of the
+      physical area where images are displayed. These properties are expressed
+      in millimeters and rounded to the closest unit.
+
+  height-mm:
+    description: The width-mm and height-mm specify the width and height of the
+      physical area where images are displayed. These properties are expressed
+      in millimeters and rounded to the closest unit.
+
+  label:
+    description: |
+      The label property specifies a symbolic name for the panel as a
+      string suitable for use by humans. It typically contains a name inscribed
+      on the system (e.g. as an affixed label) or specified in the system's
+      documentation (e.g. in the user's manual).
+
+      If no such name exists, and unless the property is mandatory according to
+      device tree bindings, it shall rather be omitted than constructed of
+      non-descriptive information. For instance an LCD panel in a system that
+      contains a single panel shall not be labelled "LCD" if that name is not
+      inscribed on the system or used in a descriptive fashion in system
+      documentation.
+
+  rotation:
+    description:
+      Display rotation in degrees counter clockwise (0,90,180,270)
+    allOf:
+      - $ref: /schemas/types.yaml#/definitions/uint32
+      - enum: [ 0, 90, 180, 270 ]
+
+  # Display Timings
+  panel-timing:
+    type: object
+    description:
+      Most display panels are restricted to a single resolution and
+      require specific display timings. The panel-timing subnode expresses those
+      timings as specified in the timing subnode section of the display timing
+      bindings defined in
+      Documentation/devicetree/bindings/display/panel/display-timing.txt.
+
+  # Connectivity
+  ports:
+    type: object
+    description:
+      Panels receive video data through one or multiple connections. While
+      the nature of those connections is specific to the panel type, the
+      connectivity is expressed in a standard fashion using ports as specified
+      in the device graph bindings defined in
+      Documentation/devicetree/bindings/graph.txt.
+
+  ddc-i2c-bus:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      Some panels expose EDID information through an I2C-compatible
+      bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
+      phandle to the system I2C controller connected to that bus.
+
+  no-hpd:
+    type: boolean
+    description:
+      This panel is supposed to communicate that it's ready via HPD
+      (hot plug detect) signal, but the signal isn't hooked up so we should
+      hardcode the max delay from the panel spec when powering up the panel.
+
+  # Control I/Os
+
+  # Many display panels can be controlled through pins driven by GPIOs. The nature
+  # and timing of those control signals are device-specific and left for panel
+  # device tree bindings to specify. The following GPIO specifiers can however be
+  # used for panels that implement compatible control signals.
+
+  enable-gpios:
+    maxItems: 1
+    description: |
+      Specifier for a GPIO connected to the panel enable control signal. The
+      enable signal is active high and enables operation of the panel. This
+      property can also be used for panels implementing an active low power down
+      signal, which is a negated version of the enable signal. Active low enable
+      signals (or active high power down signals) can be supported by inverting
+      the GPIO specifier polarity flag.
+
+      Note that the enable signal control panel operation only and must not be
+      confused with a backlight enable signal.
+
+  reset-gpios:
+    maxItems: 1
+    description:
+      Specifier for a GPIO coonnected to the panel reset control signal.
+      The reset signal is active low and resets the panel internal logic
+      while active. Active high reset signals can be supported by inverting the
+      GPIO specifier polarity flag.
+
+  # Power
+  power-supply:
+    description:
+      Display panels require power to be supplied. While several panels need
+      more than one power supply with panel-specific constraints governing the
+      order and timings of the power supplies, in many cases a single power
+      supply is sufficient, either because the panel has a single power rail, or
+      because all its power rails can be driven by the same supply. In that case
+      the power-supply property specifies the supply powering the panel as a
+      phandle to a regulator.
+
+  # Backlight
+
+  # Most display panels include a backlight. Some of them also include a backlight
+  # controller exposed through a control bus such as I2C or DSI. Others expose
+  # backlight control through GPIO, PWM or other signals connected to an external
+  # backlight controller.
+
+  backlight:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      For panels whose backlight is controlled by an external backlight
+      controller, this property contains a phandle that references the
+      controller.
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt b/Documentation/devicetree/bindings/display/panel/panel.txt
deleted file mode 100644
index e2e6867852b8..000000000000
--- a/Documentation/devicetree/bindings/display/panel/panel.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-Common display properties
--------------------------
-
-- rotation:	Display rotation in degrees counter clockwise (0,90,180,270)
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index b2b872c710f2..e11208fb7da8 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -1,28 +1 @@
-Simple display panel
-====================
-
-panel node
-----------
-
-Required properties:
-- power-supply: See panel-common.txt
-
-Optional properties:
-- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
-- enable-gpios: GPIO pin to enable or disable the panel
-- backlight: phandle of the backlight device attached to the panel
-- no-hpd: This panel is supposed to communicate that it's ready via HPD
-  (hot plug detect) signal, but the signal isn't hooked up so we should
-  hardcode the max delay from the panel spec when powering up the panel.
-
-Example:
-
-	panel: panel {
-		compatible = "cptt,claa101wb01";
-		ddc-i2c-bus = <&panelddc>;
-
-		power-supply = <&vdd_pnl_reg>;
-		enable-gpios = <&gpio 90 0>;
-
-		backlight = <&backlight>;
-	};
+See panel-common.yaml in this directory.
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 2/4] dt-bindings: display: Convert ampire, am-480272h3tmqw-t01h panel to DT schema

[Rob Herring]

Convert the ampire,am-480272h3tmqw-t01h panel binding to DT schema.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
 .../panel/ampire,am-480272h3tmqw-t01h.txt     | 26 ------------
 .../panel/ampire,am-480272h3tmqw-t01h.yaml    | 41 +++++++++++++++++++
 2 files changed, 41 insertions(+), 26 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
deleted file mode 100644
index 6812280cb109..000000000000
--- a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
-
-Required properties:
-- compatible: should be "ampire,am-480272h3tmqw-t01h"
-
-Optional properties:
-- power-supply: regulator to provide the supply voltage
-- enable-gpios: GPIO pin to enable or disable the panel
-- backlight: phandle of the backlight device attached to the panel
-
-Optional nodes:
-- Video port for RGB input.
-
-Example:
-	panel_rgb: panel-rgb {
-		compatible = "ampire,am-480272h3tmqw-t01h";
-		enable-gpios = <&gpioa 8 1>;
-		port {
-			panel_in_rgb: endpoint {
-				remote-endpoint = <&controller_out_rgb>;
-			};
-		};
-	};
diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
new file mode 100644
index 000000000000..cc2f6ec6ebf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
+
+maintainers:
+  - Thierry Reding <treding@nvidia.com>
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+    const: ampire,am-480272h3tmqw-t01h
+
+  power-supply: true
+  enable-gpios: true
+  backlight: true
+  port: true
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    panel_rgb: panel {
+      compatible = "ampire,am-480272h3tmqw-t01h";
+      enable-gpios = <&gpioa 8 1>;
+      port {
+        panel_in_rgb: endpoint {
+          remote-endpoint = <&controller_out_rgb>;
+        };
+      };
+    };
+
+...
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 3/4] dt-bindings: display: Convert panel-lvds to DT schema

[Rob Herring]

Convert the panel-lvds binding to use DT schema. The panel-lvds schema
inherits from the panel-common.yaml schema and specific LVDS panel
bindings should inherit from this schema.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
 .../bindings/display/panel/panel-lvds.txt     | 121 ------------------
 .../bindings/display/panel/panel-lvds.yaml    | 107 ++++++++++++++++
 2 files changed, 107 insertions(+), 121 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
deleted file mode 100644
index 250850a2150b..000000000000
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-LVDS Display Panel
-==================
-
-LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
-incompatible data link layers have been used over time to transmit image data
-to LVDS panels. This bindings supports display panels compatible with the
-following specifications.
-
-[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
-1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
-[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
-Semiconductor
-[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
-Electronics Standards Association (VESA)
-
-Device compatible with those specifications have been marketed under the
-FPD-Link and FlatLink brands.
-
-
-Required properties:
-
-- compatible: Shall contain "panel-lvds" in addition to a mandatory
-  panel-specific compatible string defined in individual panel bindings. The
-  "panel-lvds" value shall never be used on its own.
-- width-mm: See panel-common.txt.
-- height-mm: See panel-common.txt.
-- data-mapping: The color signals mapping order, "jeida-18", "jeida-24"
-  or "vesa-24".
-
-Optional properties:
-
-- label: See panel-common.txt.
-- gpios: See panel-common.txt.
-- backlight: See panel-common.txt.
-- power-supply: See panel-common.txt.
-- data-mirror: If set, reverse the bit order described in the data mappings
-  below on all data lanes, transmitting bits for slots 6 to 0 instead of
-  0 to 6.
-
-Required nodes:
-
-- panel-timing: See panel-common.txt.
-- ports: See panel-common.txt. These bindings require a single port subnode
-  corresponding to the panel LVDS input.
-
-
-LVDS data mappings are defined as follows.
-
-- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
-  [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
-
-Slot	    0       1       2       3       4       5       6
-	________________                         _________________
-Clock	                \_______________________/
-	  ______  ______  ______  ______  ______  ______  ______
-DATA0	><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
-DATA1	><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
-DATA2	><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
-
-- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
-  specifications. Data are transferred as follows on 4 LVDS lanes.
-
-Slot	    0       1       2       3       4       5       6
-	________________                         _________________
-Clock	                \_______________________/
-	  ______  ______  ______  ______  ______  ______  ______
-DATA0	><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
-DATA1	><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
-DATA2	><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
-DATA3	><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
-
-- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
-  Data are transferred as follows on 4 LVDS lanes.
-
-Slot	    0       1       2       3       4       5       6
-	________________                         _________________
-Clock	                \_______________________/
-	  ______  ______  ______  ______  ______  ______  ______
-DATA0	><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
-DATA1	><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
-DATA2	><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
-DATA3	><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
-
-Control signals are mapped as follows.
-
-CTL0: HSync
-CTL1: VSync
-CTL2: Data Enable
-CTL3: 0
-
-
-Example
--------
-
-panel {
-	compatible = "mitsubishi,aa121td01", "panel-lvds";
-
-	width-mm = <261>;
-	height-mm = <163>;
-
-	data-mapping = "jeida-24";
-
-	panel-timing {
-		/* 1280x800 @60Hz */
-		clock-frequency = <71000000>;
-		hactive = <1280>;
-		vactive = <800>;
-		hsync-len = <70>;
-		hfront-porch = <20>;
-		hback-porch = <70>;
-		vsync-len = <5>;
-		vfront-porch = <3>;
-		vback-porch = <15>;
-	};
-
-	port {
-		panel_in: endpoint {
-			remote-endpoint = <&lvds_encoder>;
-		};
-	};
-};
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
new file mode 100644
index 000000000000..1dd5eea7b930
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LVDS Display Panel
+
+maintainers:
+  - Thierry Reding <thierry.reding@gmail.com>
+  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+
+description: |+
+  LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+  incompatible data link layers have been used over time to transmit image data
+  to LVDS panels. This bindings supports display panels compatible with the
+  following specifications.
+
+  [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+  1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+  [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+  Semiconductor
+  [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+  Electronics Standards Association (VESA)
+
+  Device compatible with those specifications have been marketed under the
+  FPD-Link and FlatLink brands.
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+    contains:
+      const: panel-lvds
+    description:
+      Shall contain "panel-lvds" in addition to a mandatory panel-specific
+      compatible string defined in individual panel bindings. The "panel-lvds"
+      value shall never be used on its own.
+
+  data-mapping:
+    enum:
+      - jeida-18
+      - jeida-24
+      - vesa-24
+    description: |
+      The color signals mapping order.
+
+      LVDS data mappings are defined as follows.
+
+      - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
+        [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
+
+      Slot	    0       1       2       3       4       5       6
+            ________________                         _________________
+      Clock	                \_______________________/
+              ______  ______  ______  ______  ______  ______  ______
+      DATA0	><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+      DATA1	><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+      DATA2	><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+
+      - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
+        specifications. Data are transferred as follows on 4 LVDS lanes.
+
+      Slot	    0       1       2       3       4       5       6
+            ________________                         _________________
+      Clock	                \_______________________/
+              ______  ______  ______  ______  ______  ______  ______
+      DATA0	><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
+      DATA1	><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
+      DATA2	><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
+      DATA3	><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
+
+      - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
+        Data are transferred as follows on 4 LVDS lanes.
+
+      Slot	    0       1       2       3       4       5       6
+            ________________                         _________________
+      Clock	                \_______________________/
+              ______  ______  ______  ______  ______  ______  ______
+      DATA0	><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+      DATA1	><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+      DATA2	><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+      DATA3	><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
+
+      Control signals are mapped as follows.
+
+      CTL0: HSync
+      CTL1: VSync
+      CTL2: Data Enable
+      CTL3: 0
+
+  data-mirror:
+    type: boolean
+    description:
+      If set, reverse the bit order described in the data mappings below on all
+      data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
+
+required:
+  - compatible
+  - data-mapping
+  - width-mm
+  - height-mm
+  - panel-timing
+  - port
+
+...
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 4/4] dt-bindings: display: Convert innolux,ee101ia-01 panel to DT schema

[Rob Herring]

Convert the innolux,ee101ia-01 LVDS panel binding to DT schema.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
 .../display/panel/innolux,ee101ia-01d.txt     |  7 -------
 .../display/panel/innolux,ee101ia-01d.yaml    | 21 +++++++++++++++++++
 2 files changed, 21 insertions(+), 7 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
deleted file mode 100644
index e5ca4ccd55ed..000000000000
--- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
-
-Required properties:
-- compatible: should be "innolux,ee101ia-01d"
-
-This binding is compatible with the lvds-panel binding, which is specified
-in panel-lvds.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
new file mode 100644
index 000000000000..53d0e9c6169f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
+
+maintainers:
+  - Thierry Reding <thierry.reding@gmail.com>
+
+allOf:
+  - $ref: panel-lvds.yaml#
+
+properties:
+  compatible:
+    items:
+      - const: innolux,ee101ia-01d
+      - {} # panel-lvds, but not listed here to avoid false select
+
+...
-- 
2.20.1

Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[Sam Ravnborg]

Hi Rob.

Thanks for starting the conversion of panel bindings to yaml.

On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote:
> Convert the common panel bindings to DT schema consolidating scattered
> definitions to a single schema file.
> 
> The 'simple-panel' binding just a collection of properties and not a
> complete binding itself. All of the 'simple-panel' properties are
> covered by the panel-common.txt binding with the exception of the
> 'no-hpd' property, so add that to the schema.
> 
> As there are lots of references to simple-panel.txt, just keep the file
> with a reference to panel-common.yaml for now until all the bindings are
> converted.
Good idea.

> 
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Note there's still some references to panel-common.txt that I need to 
> update or just go ahead and convert to schema.
Better let it point to the .yaml variant, so this patchset does not
depend on too much other bindings to be converted.
Then we can start the conversion of the remaining panel bindings.
Any tooling that helps the conversions?

When this hits upstream I assume all future panel bindings shall be yaml
based - so we have a few pending contributions that need to do something.

For the actual conversion below:
Acked-by: Sam Ravnborg <sam@ravnborg.org>

	Sam
> 
>  .../bindings/display/panel/panel-common.txt   | 101 -------------
>  .../bindings/display/panel/panel-common.yaml  | 143 ++++++++++++++++++
>  .../bindings/display/panel/panel.txt          |   4 -
>  .../bindings/display/panel/simple-panel.txt   |  29 +---
>  4 files changed, 144 insertions(+), 133 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt
>  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> deleted file mode 100644
> index 5d2519af4bb5..000000000000
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> +++ /dev/null
> @@ -1,101 +0,0 @@
> -Common Properties for Display Panel
> -===================================
> -
> -This document defines device tree properties common to several classes of
> -display panels. It doesn't constitue a device tree binding specification by
> -itself but is meant to be referenced by device tree bindings.
> -
> -When referenced from panel device tree bindings the properties defined in this
> -document are defined as follows. The panel device tree bindings are
> -responsible for defining whether each property is required or optional.
> -
> -
> -Descriptive Properties
> -----------------------
> -
> -- width-mm,
> -- height-mm: The width-mm and height-mm specify the width and height of the
> -  physical area where images are displayed. These properties are expressed in
> -  millimeters and rounded to the closest unit.
> -
> -- label: The label property specifies a symbolic name for the panel as a
> -  string suitable for use by humans. It typically contains a name inscribed on
> -  the system (e.g. as an affixed label) or specified in the system's
> -  documentation (e.g. in the user's manual).
> -
> -  If no such name exists, and unless the property is mandatory according to
> -  device tree bindings, it shall rather be omitted than constructed of
> -  non-descriptive information. For instance an LCD panel in a system that
> -  contains a single panel shall not be labelled "LCD" if that name is not
> -  inscribed on the system or used in a descriptive fashion in system
> -  documentation.
> -
> -
> -Display Timings
> ----------------
> -
> -- panel-timing: Most display panels are restricted to a single resolution and
> -  require specific display timings. The panel-timing subnode expresses those
> -  timings as specified in the timing subnode section of the display timing
> -  bindings defined in
> -  Documentation/devicetree/bindings/display/panel/display-timing.txt.
> -
> -
> -Connectivity
> -------------
> -
> -- ports: Panels receive video data through one or multiple connections. While
> -  the nature of those connections is specific to the panel type, the
> -  connectivity is expressed in a standard fashion using ports as specified in
> -  the device graph bindings defined in
> -  Documentation/devicetree/bindings/graph.txt.
> -
> -- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible
> -  bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
> -  phandle to the system I2C controller connected to that bus.
> -
> -
> -Control I/Os
> -------------
> -
> -Many display panels can be controlled through pins driven by GPIOs. The nature
> -and timing of those control signals are device-specific and left for panel
> -device tree bindings to specify. The following GPIO specifiers can however be
> -used for panels that implement compatible control signals.
> -
> -- enable-gpios: Specifier for a GPIO connected to the panel enable control
> -  signal. The enable signal is active high and enables operation of the panel.
> -  This property can also be used for panels implementing an active low power
> -  down signal, which is a negated version of the enable signal. Active low
> -  enable signals (or active high power down signals) can be supported by
> -  inverting the GPIO specifier polarity flag.
> -
> -  Note that the enable signal control panel operation only and must not be
> -  confused with a backlight enable signal.
> -
> -- reset-gpios: Specifier for a GPIO coonnected to the panel reset control
> -  signal. The reset signal is active low and resets the panel internal logic
> -  while active. Active high reset signals can be supported by inverting the
> -  GPIO specifier polarity flag.
> -
> -Power
> ------
> -
> -- power-supply: display panels require power to be supplied. While several
> -  panels need more than one power supply with panel-specific constraints
> -  governing the order and timings of the power supplies, in many cases a single
> -  power supply is sufficient, either because the panel has a single power rail,
> -  or because all its power rails can be driven by the same supply. In that case
> -  the power-supply property specifies the supply powering the panel as a phandle
> -  to a regulator.
> -
> -Backlight
> ----------
> -
> -Most display panels include a backlight. Some of them also include a backlight
> -controller exposed through a control bus such as I2C or DSI. Others expose
> -backlight control through GPIO, PWM or other signals connected to an external
> -backlight controller.
> -
> -- backlight: For panels whose backlight is controlled by an external backlight
> -  controller, this property contains a phandle that references the controller.
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> new file mode 100644
> index 000000000000..6fe87254edad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> @@ -0,0 +1,143 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common Properties for Display Panels
> +
> +maintainers:
> +  - Thierry Reding <thierry.reding@gmail.com>
> +  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> +
> +description: |
> +  This document defines device tree properties common to several classes of
> +  display panels. It doesn't constitue a device tree binding specification by
> +  itself but is meant to be referenced by device tree bindings.
> +
> +  When referenced from panel device tree bindings the properties defined in this
> +  document are defined as follows. The panel device tree bindings are
> +  responsible for defining whether each property is required or optional.
> +
> +
> +properties:
> +  # Descriptive Properties
> +  width-mm:
> +    description: The width-mm and height-mm specify the width and height of the
> +      physical area where images are displayed. These properties are expressed
> +      in millimeters and rounded to the closest unit.
> +
> +  height-mm:
> +    description: The width-mm and height-mm specify the width and height of the
> +      physical area where images are displayed. These properties are expressed
> +      in millimeters and rounded to the closest unit.
> +
> +  label:
> +    description: |
> +      The label property specifies a symbolic name for the panel as a
> +      string suitable for use by humans. It typically contains a name inscribed
> +      on the system (e.g. as an affixed label) or specified in the system's
> +      documentation (e.g. in the user's manual).
> +
> +      If no such name exists, and unless the property is mandatory according to
> +      device tree bindings, it shall rather be omitted than constructed of
> +      non-descriptive information. For instance an LCD panel in a system that
> +      contains a single panel shall not be labelled "LCD" if that name is not
> +      inscribed on the system or used in a descriptive fashion in system
> +      documentation.
> +
> +  rotation:
> +    description:
> +      Display rotation in degrees counter clockwise (0,90,180,270)
> +    allOf:
> +      - $ref: /schemas/types.yaml#/definitions/uint32
> +      - enum: [ 0, 90, 180, 270 ]
> +
> +  # Display Timings
> +  panel-timing:
> +    type: object
> +    description:
> +      Most display panels are restricted to a single resolution and
> +      require specific display timings. The panel-timing subnode expresses those
> +      timings as specified in the timing subnode section of the display timing
> +      bindings defined in
> +      Documentation/devicetree/bindings/display/panel/display-timing.txt.
> +
> +  # Connectivity
> +  ports:
> +    type: object
> +    description:
> +      Panels receive video data through one or multiple connections. While
> +      the nature of those connections is specific to the panel type, the
> +      connectivity is expressed in a standard fashion using ports as specified
> +      in the device graph bindings defined in
> +      Documentation/devicetree/bindings/graph.txt.
> +
> +  ddc-i2c-bus:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      Some panels expose EDID information through an I2C-compatible
> +      bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
> +      phandle to the system I2C controller connected to that bus.
> +
> +  no-hpd:
> +    type: boolean
> +    description:
> +      This panel is supposed to communicate that it's ready via HPD
> +      (hot plug detect) signal, but the signal isn't hooked up so we should
> +      hardcode the max delay from the panel spec when powering up the panel.
> +
> +  # Control I/Os
> +
> +  # Many display panels can be controlled through pins driven by GPIOs. The nature
> +  # and timing of those control signals are device-specific and left for panel
> +  # device tree bindings to specify. The following GPIO specifiers can however be
> +  # used for panels that implement compatible control signals.
> +
> +  enable-gpios:
> +    maxItems: 1
> +    description: |
> +      Specifier for a GPIO connected to the panel enable control signal. The
> +      enable signal is active high and enables operation of the panel. This
> +      property can also be used for panels implementing an active low power down
> +      signal, which is a negated version of the enable signal. Active low enable
> +      signals (or active high power down signals) can be supported by inverting
> +      the GPIO specifier polarity flag.
> +
> +      Note that the enable signal control panel operation only and must not be
> +      confused with a backlight enable signal.
> +
> +  reset-gpios:
> +    maxItems: 1
> +    description:
> +      Specifier for a GPIO coonnected to the panel reset control signal.
> +      The reset signal is active low and resets the panel internal logic
> +      while active. Active high reset signals can be supported by inverting the
> +      GPIO specifier polarity flag.
> +
> +  # Power
> +  power-supply:
> +    description:
> +      Display panels require power to be supplied. While several panels need
> +      more than one power supply with panel-specific constraints governing the
> +      order and timings of the power supplies, in many cases a single power
> +      supply is sufficient, either because the panel has a single power rail, or
> +      because all its power rails can be driven by the same supply. In that case
> +      the power-supply property specifies the supply powering the panel as a
> +      phandle to a regulator.
> +
> +  # Backlight
> +
> +  # Most display panels include a backlight. Some of them also include a backlight
> +  # controller exposed through a control bus such as I2C or DSI. Others expose
> +  # backlight control through GPIO, PWM or other signals connected to an external
> +  # backlight controller.
> +
> +  backlight:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      For panels whose backlight is controlled by an external backlight
> +      controller, this property contains a phandle that references the
> +      controller.
> +
> +...
> diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt b/Documentation/devicetree/bindings/display/panel/panel.txt
> deleted file mode 100644
> index e2e6867852b8..000000000000
> --- a/Documentation/devicetree/bindings/display/panel/panel.txt
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -Common display properties
> --------------------------
> -
> -- rotation:	Display rotation in degrees counter clockwise (0,90,180,270)
> diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> index b2b872c710f2..e11208fb7da8 100644
> --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> @@ -1,28 +1 @@
> -Simple display panel
> -====================
> -
> -panel node
> -----------
> -
> -Required properties:
> -- power-supply: See panel-common.txt
> -
> -Optional properties:
> -- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> -- enable-gpios: GPIO pin to enable or disable the panel
> -- backlight: phandle of the backlight device attached to the panel
> -- no-hpd: This panel is supposed to communicate that it's ready via HPD
> -  (hot plug detect) signal, but the signal isn't hooked up so we should
> -  hardcode the max delay from the panel spec when powering up the panel.
> -
> -Example:
> -
> -	panel: panel {
> -		compatible = "cptt,claa101wb01";
> -		ddc-i2c-bus = <&panelddc>;
> -
> -		power-supply = <&vdd_pnl_reg>;
> -		enable-gpios = <&gpio 90 0>;
> -
> -		backlight = <&backlight>;
> -	};
> +See panel-common.yaml in this directory.
> -- 
> 2.20.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1023 bytes --]

On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote:
> Convert the common panel bindings to DT schema consolidating scattered
> definitions to a single schema file.
>
> The 'simple-panel' binding just a collection of properties and not a
> complete binding itself. All of the 'simple-panel' properties are
> covered by the panel-common.txt binding with the exception of the
> 'no-hpd' property, so add that to the schema.
>
> As there are lots of references to simple-panel.txt, just keep the file
> with a reference to panel-common.yaml for now until all the bindings are
> converted.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>

Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 2/4] dt-bindings: display: Convert ampire,am-480272h3tmqw-t01h panel to DT schema

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On Wed, Jun 19, 2019 at 03:51:54PM -0600, Rob Herring wrote:
> Convert the ampire,am-480272h3tmqw-t01h panel binding to DT schema.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>

Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH 3/4] dt-bindings: display: Convert panel-lvds to DT schema

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 676 bytes --]

On Wed, Jun 19, 2019 at 03:51:55PM -0600, Rob Herring wrote:
> Convert the panel-lvds binding to use DT schema. The panel-lvds schema
> inherits from the panel-common.yaml schema and specific LVDS panel
> bindings should inherit from this schema.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>

Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 4/4] dt-bindings: display: Convert innolux,ee101ia-01 panel to DT schema

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Wed, Jun 19, 2019 at 03:51:56PM -0600, Rob Herring wrote:
> Convert the innolux,ee101ia-01 LVDS panel binding to DT schema.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>

Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 16180 bytes --]

On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote:
> Convert the common panel bindings to DT schema consolidating scattered
> definitions to a single schema file.
> 
> The 'simple-panel' binding just a collection of properties and not a
> complete binding itself. All of the 'simple-panel' properties are
> covered by the panel-common.txt binding with the exception of the
> 'no-hpd' property, so add that to the schema.
> 
> As there are lots of references to simple-panel.txt, just keep the file
> with a reference to panel-common.yaml for now until all the bindings are
> converted.
> 
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Note there's still some references to panel-common.txt that I need to 
> update or just go ahead and convert to schema.
> 
>  .../bindings/display/panel/panel-common.txt   | 101 -------------
>  .../bindings/display/panel/panel-common.yaml  | 143 ++++++++++++++++++
>  .../bindings/display/panel/panel.txt          |   4 -
>  .../bindings/display/panel/simple-panel.txt   |  29 +---
>  4 files changed, 144 insertions(+), 133 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt
>  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml

I know it was this way before, but perhaps remove the redundant panel-
prefix while at it?

>  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> deleted file mode 100644
> index 5d2519af4bb5..000000000000
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> +++ /dev/null
> @@ -1,101 +0,0 @@
> -Common Properties for Display Panel
> -===================================
> -
> -This document defines device tree properties common to several classes of
> -display panels. It doesn't constitue a device tree binding specification by
> -itself but is meant to be referenced by device tree bindings.
> -
> -When referenced from panel device tree bindings the properties defined in this
> -document are defined as follows. The panel device tree bindings are
> -responsible for defining whether each property is required or optional.
> -
> -
> -Descriptive Properties
> -----------------------
> -
> -- width-mm,
> -- height-mm: The width-mm and height-mm specify the width and height of the
> -  physical area where images are displayed. These properties are expressed in
> -  millimeters and rounded to the closest unit.
> -
> -- label: The label property specifies a symbolic name for the panel as a
> -  string suitable for use by humans. It typically contains a name inscribed on
> -  the system (e.g. as an affixed label) or specified in the system's
> -  documentation (e.g. in the user's manual).
> -
> -  If no such name exists, and unless the property is mandatory according to
> -  device tree bindings, it shall rather be omitted than constructed of
> -  non-descriptive information. For instance an LCD panel in a system that
> -  contains a single panel shall not be labelled "LCD" if that name is not
> -  inscribed on the system or used in a descriptive fashion in system
> -  documentation.
> -
> -
> -Display Timings
> ----------------
> -
> -- panel-timing: Most display panels are restricted to a single resolution and
> -  require specific display timings. The panel-timing subnode expresses those
> -  timings as specified in the timing subnode section of the display timing
> -  bindings defined in
> -  Documentation/devicetree/bindings/display/panel/display-timing.txt.
> -
> -
> -Connectivity
> -------------
> -
> -- ports: Panels receive video data through one or multiple connections. While
> -  the nature of those connections is specific to the panel type, the
> -  connectivity is expressed in a standard fashion using ports as specified in
> -  the device graph bindings defined in
> -  Documentation/devicetree/bindings/graph.txt.
> -
> -- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible
> -  bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
> -  phandle to the system I2C controller connected to that bus.
> -
> -
> -Control I/Os
> -------------
> -
> -Many display panels can be controlled through pins driven by GPIOs. The nature
> -and timing of those control signals are device-specific and left for panel
> -device tree bindings to specify. The following GPIO specifiers can however be
> -used for panels that implement compatible control signals.
> -
> -- enable-gpios: Specifier for a GPIO connected to the panel enable control
> -  signal. The enable signal is active high and enables operation of the panel.
> -  This property can also be used for panels implementing an active low power
> -  down signal, which is a negated version of the enable signal. Active low
> -  enable signals (or active high power down signals) can be supported by
> -  inverting the GPIO specifier polarity flag.
> -
> -  Note that the enable signal control panel operation only and must not be
> -  confused with a backlight enable signal.
> -
> -- reset-gpios: Specifier for a GPIO coonnected to the panel reset control
> -  signal. The reset signal is active low and resets the panel internal logic
> -  while active. Active high reset signals can be supported by inverting the
> -  GPIO specifier polarity flag.
> -
> -Power
> ------
> -
> -- power-supply: display panels require power to be supplied. While several
> -  panels need more than one power supply with panel-specific constraints
> -  governing the order and timings of the power supplies, in many cases a single
> -  power supply is sufficient, either because the panel has a single power rail,
> -  or because all its power rails can be driven by the same supply. In that case
> -  the power-supply property specifies the supply powering the panel as a phandle
> -  to a regulator.
> -
> -Backlight
> ----------
> -
> -Most display panels include a backlight. Some of them also include a backlight
> -controller exposed through a control bus such as I2C or DSI. Others expose
> -backlight control through GPIO, PWM or other signals connected to an external
> -backlight controller.
> -
> -- backlight: For panels whose backlight is controlled by an external backlight
> -  controller, this property contains a phandle that references the controller.
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> new file mode 100644
> index 000000000000..6fe87254edad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> @@ -0,0 +1,143 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common Properties for Display Panels
> +
> +maintainers:
> +  - Thierry Reding <thierry.reding@gmail.com>
> +  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> +
> +description: |
> +  This document defines device tree properties common to several classes of
> +  display panels. It doesn't constitue a device tree binding specification by
> +  itself but is meant to be referenced by device tree bindings.
> +
> +  When referenced from panel device tree bindings the properties defined in this
> +  document are defined as follows. The panel device tree bindings are
> +  responsible for defining whether each property is required or optional.
> +
> +

Are the two blank lines here on purpose? The original document had two
blank lines here, but that was mostly for readability I would guess. The
YAML format doesn't really need additional formatting for readability,
so perhaps just remove the extra blank line?

> +properties:
> +  # Descriptive Properties
> +  width-mm:
> +    description: The width-mm and height-mm specify the width and height of the
> +      physical area where images are displayed. These properties are expressed
> +      in millimeters and rounded to the closest unit.
> +
> +  height-mm:
> +    description: The width-mm and height-mm specify the width and height of the
> +      physical area where images are displayed. These properties are expressed
> +      in millimeters and rounded to the closest unit.

I suppose there's no way in YAML to share the description between both
the width-mm and height-mm properties? It's a little unfortunate that we
have to copy, but if there's no better way, guess we'll have to live
with it.

> +
> +  label:
> +    description: |
> +      The label property specifies a symbolic name for the panel as a
> +      string suitable for use by humans. It typically contains a name inscribed
> +      on the system (e.g. as an affixed label) or specified in the system's
> +      documentation (e.g. in the user's manual).
> +
> +      If no such name exists, and unless the property is mandatory according to
> +      device tree bindings, it shall rather be omitted than constructed of
> +      non-descriptive information. For instance an LCD panel in a system that
> +      contains a single panel shall not be labelled "LCD" if that name is not
> +      inscribed on the system or used in a descriptive fashion in system
> +      documentation.
> +
> +  rotation:
> +    description:
> +      Display rotation in degrees counter clockwise (0,90,180,270)
> +    allOf:
> +      - $ref: /schemas/types.yaml#/definitions/uint32
> +      - enum: [ 0, 90, 180, 270 ]
> +
> +  # Display Timings
> +  panel-timing:

Am I the only one bugged by the redundancy in this property name? What
else is the timing going to express if not the timing of the panel that
it's part of. "timing" really would be enough. Anyway, not much we can
do about it now.

> +    type: object
> +    description:
> +      Most display panels are restricted to a single resolution and
> +      require specific display timings. The panel-timing subnode expresses those
> +      timings as specified in the timing subnode section of the display timing
> +      bindings defined in
> +      Documentation/devicetree/bindings/display/panel/display-timing.txt.
> +
> +  # Connectivity
> +  ports:
> +    type: object
> +    description:
> +      Panels receive video data through one or multiple connections. While
> +      the nature of those connections is specific to the panel type, the
> +      connectivity is expressed in a standard fashion using ports as specified
> +      in the device graph bindings defined in
> +      Documentation/devicetree/bindings/graph.txt.
> +
> +  ddc-i2c-bus:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      Some panels expose EDID information through an I2C-compatible
> +      bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
> +      phandle to the system I2C controller connected to that bus.
> +
> +  no-hpd:
> +    type: boolean
> +    description:
> +      This panel is supposed to communicate that it's ready via HPD
> +      (hot plug detect) signal, but the signal isn't hooked up so we should
> +      hardcode the max delay from the panel spec when powering up the panel.
> +
> +  # Control I/Os
> +
> +  # Many display panels can be controlled through pins driven by GPIOs. The nature
> +  # and timing of those control signals are device-specific and left for panel
> +  # device tree bindings to specify. The following GPIO specifiers can however be
> +  # used for panels that implement compatible control signals.
> +
> +  enable-gpios:
> +    maxItems: 1
> +    description: |
> +      Specifier for a GPIO connected to the panel enable control signal. The
> +      enable signal is active high and enables operation of the panel. This
> +      property can also be used for panels implementing an active low power down
> +      signal, which is a negated version of the enable signal. Active low enable
> +      signals (or active high power down signals) can be supported by inverting
> +      the GPIO specifier polarity flag.
> +
> +      Note that the enable signal control panel operation only and must not be
> +      confused with a backlight enable signal.
> +
> +  reset-gpios:
> +    maxItems: 1
> +    description:
> +      Specifier for a GPIO coonnected to the panel reset control signal.

This is preexisting, but: "connected".

> +      The reset signal is active low and resets the panel internal logic
> +      while active. Active high reset signals can be supported by inverting the
> +      GPIO specifier polarity flag.
> +
> +  # Power
> +  power-supply:
> +    description:
> +      Display panels require power to be supplied. While several panels need
> +      more than one power supply with panel-specific constraints governing the
> +      order and timings of the power supplies, in many cases a single power
> +      supply is sufficient, either because the panel has a single power rail, or
> +      because all its power rails can be driven by the same supply. In that case
> +      the power-supply property specifies the supply powering the panel as a
> +      phandle to a regulator.
> +
> +  # Backlight
> +
> +  # Most display panels include a backlight. Some of them also include a backlight
> +  # controller exposed through a control bus such as I2C or DSI. Others expose
> +  # backlight control through GPIO, PWM or other signals connected to an external
> +  # backlight controller.
> +
> +  backlight:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      For panels whose backlight is controlled by an external backlight
> +      controller, this property contains a phandle that references the
> +      controller.
> +
> +...
> diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt b/Documentation/devicetree/bindings/display/panel/panel.txt
> deleted file mode 100644
> index e2e6867852b8..000000000000
> --- a/Documentation/devicetree/bindings/display/panel/panel.txt
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -Common display properties
> --------------------------
> -
> -- rotation:	Display rotation in degrees counter clockwise (0,90,180,270)
> diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> index b2b872c710f2..e11208fb7da8 100644
> --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> @@ -1,28 +1 @@
> -Simple display panel
> -====================
> -
> -panel node
> -----------
> -
> -Required properties:
> -- power-supply: See panel-common.txt
> -
> -Optional properties:
> -- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> -- enable-gpios: GPIO pin to enable or disable the panel
> -- backlight: phandle of the backlight device attached to the panel
> -- no-hpd: This panel is supposed to communicate that it's ready via HPD
> -  (hot plug detect) signal, but the signal isn't hooked up so we should
> -  hardcode the max delay from the panel spec when powering up the panel.
> -
> -Example:
> -
> -	panel: panel {
> -		compatible = "cptt,claa101wb01";
> -		ddc-i2c-bus = <&panelddc>;
> -
> -		power-supply = <&vdd_pnl_reg>;
> -		enable-gpios = <&gpio 90 0>;
> -
> -		backlight = <&backlight>;
> -	};
> +See panel-common.yaml in this directory.

We can address the nits above separately, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 2/4] dt-bindings: display: Convert ampire,am-480272h3tmqw-t01h panel to DT schema

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On Wed, Jun 19, 2019 at 03:51:54PM -0600, Rob Herring wrote:
> Convert the ampire,am-480272h3tmqw-t01h panel binding to DT schema.
> 
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>  .../panel/ampire,am-480272h3tmqw-t01h.txt     | 26 ------------
>  .../panel/ampire,am-480272h3tmqw-t01h.yaml    | 41 +++++++++++++++++++
>  2 files changed, 41 insertions(+), 26 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>  create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml

Acked-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC PATCH 3/4] dt-bindings: display: Convert panel-lvds to DT schema

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1067 bytes --]

On Wed, Jun 19, 2019 at 03:51:55PM -0600, Rob Herring wrote:
> Convert the panel-lvds binding to use DT schema. The panel-lvds schema
> inherits from the panel-common.yaml schema and specific LVDS panel
> bindings should inherit from this schema.
> 
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>  .../bindings/display/panel/panel-lvds.txt     | 121 ------------------
>  .../bindings/display/panel/panel-lvds.yaml    | 107 ++++++++++++++++
>  2 files changed, 107 insertions(+), 121 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.yaml

Similar to my comments on panel-common.yaml, perhaps make this just
lvds.yaml? Otherwise:

Acked-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 4/4] dt-bindings: display: Convert innolux,ee101ia-01 panel to DT schema

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Wed, Jun 19, 2019 at 03:51:56PM -0600, Rob Herring wrote:
> Convert the innolux,ee101ia-01 LVDS panel binding to DT schema.
> 
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>  .../display/panel/innolux,ee101ia-01d.txt     |  7 -------
>  .../display/panel/innolux,ee101ia-01d.yaml    | 21 +++++++++++++++++++
>  2 files changed, 21 insertions(+), 7 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
>  create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml

Acked-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[Rob Herring]

On Thu, Jun 20, 2019 at 3:01 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote:
> > Convert the common panel bindings to DT schema consolidating scattered
> > definitions to a single schema file.
> >
> > The 'simple-panel' binding just a collection of properties and not a
> > complete binding itself. All of the 'simple-panel' properties are
> > covered by the panel-common.txt binding with the exception of the
> > 'no-hpd' property, so add that to the schema.
> >
> > As there are lots of references to simple-panel.txt, just keep the file
> > with a reference to panel-common.yaml for now until all the bindings are
> > converted.
> >
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > Note there's still some references to panel-common.txt that I need to
> > update or just go ahead and convert to schema.
> >
> >  .../bindings/display/panel/panel-common.txt   | 101 -------------
> >  .../bindings/display/panel/panel-common.yaml  | 143 ++++++++++++++++++
> >  .../bindings/display/panel/panel.txt          |   4 -
> >  .../bindings/display/panel/simple-panel.txt   |  29 +---
> >  4 files changed, 144 insertions(+), 133 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt
> >  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml
>
> I know it was this way before, but perhaps remove the redundant panel-
> prefix while at it?

Sure.


> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> > new file mode 100644
> > index 000000000000..6fe87254edad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> > @@ -0,0 +1,143 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common Properties for Display Panels
> > +
> > +maintainers:
> > +  - Thierry Reding <thierry.reding@gmail.com>
> > +  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > +
> > +description: |
> > +  This document defines device tree properties common to several classes of
> > +  display panels. It doesn't constitue a device tree binding specification by
> > +  itself but is meant to be referenced by device tree bindings.
> > +
> > +  When referenced from panel device tree bindings the properties defined in this
> > +  document are defined as follows. The panel device tree bindings are
> > +  responsible for defining whether each property is required or optional.
> > +
> > +
>
> Are the two blank lines here on purpose?

No.

> The original document had two
> blank lines here, but that was mostly for readability I would guess. The
> YAML format doesn't really need additional formatting for readability,
> so perhaps just remove the extra blank line?
>
> > +properties:
> > +  # Descriptive Properties
> > +  width-mm:
> > +    description: The width-mm and height-mm specify the width and height of the
> > +      physical area where images are displayed. These properties are expressed
> > +      in millimeters and rounded to the closest unit.
> > +
> > +  height-mm:
> > +    description: The width-mm and height-mm specify the width and height of the
> > +      physical area where images are displayed. These properties are expressed
> > +      in millimeters and rounded to the closest unit.
>
> I suppose there's no way in YAML to share the description between both
> the width-mm and height-mm properties? It's a little unfortunate that we
> have to copy, but if there's no better way, guess we'll have to live
> with it.

I could make it a comment instead, but then we loose being able to
parse it. I should probably just reword them to be separate:

"Specifies the height of the physical area where images are displayed.
The property is expressed in millimeters and rounded to the closest
unit."

Also, just realized I need to make these 2 dependencies on either
other (i.e. not valid to only have one).

> > +  label:
> > +    description: |
> > +      The label property specifies a symbolic name for the panel as a
> > +      string suitable for use by humans. It typically contains a name inscribed
> > +      on the system (e.g. as an affixed label) or specified in the system's
> > +      documentation (e.g. in the user's manual).
> > +
> > +      If no such name exists, and unless the property is mandatory according to
> > +      device tree bindings, it shall rather be omitted than constructed of
> > +      non-descriptive information. For instance an LCD panel in a system that
> > +      contains a single panel shall not be labelled "LCD" if that name is not
> > +      inscribed on the system or used in a descriptive fashion in system
> > +      documentation.
> > +
> > +  rotation:
> > +    description:
> > +      Display rotation in degrees counter clockwise (0,90,180,270)
> > +    allOf:
> > +      - $ref: /schemas/types.yaml#/definitions/uint32
> > +      - enum: [ 0, 90, 180, 270 ]
> > +
> > +  # Display Timings
> > +  panel-timing:
>
> Am I the only one bugged by the redundancy in this property name? What
> else is the timing going to express if not the timing of the panel that
> it's part of. "timing" really would be enough. Anyway, not much we can
> do about it now.

I'm just happy we have a defined name.

Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[Rob Herring]

On Thu, Jun 20, 2019 at 12:55 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Rob.
>
> Thanks for starting the conversion of panel bindings to yaml.
>
> On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote:
> > Convert the common panel bindings to DT schema consolidating scattered
> > definitions to a single schema file.
> >
> > The 'simple-panel' binding just a collection of properties and not a
> > complete binding itself. All of the 'simple-panel' properties are
> > covered by the panel-common.txt binding with the exception of the
> > 'no-hpd' property, so add that to the schema.
> >
> > As there are lots of references to simple-panel.txt, just keep the file
> > with a reference to panel-common.yaml for now until all the bindings are
> > converted.
> Good idea.
>
> >
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > Note there's still some references to panel-common.txt that I need to
> > update or just go ahead and convert to schema.
> Better let it point to the .yaml variant, so this patchset does not
> depend on too much other bindings to be converted.

There's only 8 files referencing panel-common.txt which was why I was
debating just converting all of them.

> Then we can start the conversion of the remaining panel bindings.
> Any tooling that helps the conversions?

I have a doc2yaml script that helps with some of the boilerplate. It's
in my yaml-bindings-v2 branch[1].

> When this hits upstream I assume all future panel bindings shall be yaml
> based - so we have a few pending contributions that need to do something.

That would be ideal, but not strictly required. For pending things, no
reason to make folks redo things. Requiring schema really depends on
whomever is applying things to run at least 'make dt_binding_check'
before accepting.

>
> For the actual conversion below:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>

Thanks.

Rob

[1] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=yaml-bindings-v2

Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[Rob Herring]

On Thu, Jun 20, 2019 at 8:52 AM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Jun 20, 2019 at 3:01 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote:
> > > Convert the common panel bindings to DT schema consolidating scattered
> > > definitions to a single schema file.
> > >
> > > The 'simple-panel' binding just a collection of properties and not a
> > > complete binding itself. All of the 'simple-panel' properties are
> > > covered by the panel-common.txt binding with the exception of the
> > > 'no-hpd' property, so add that to the schema.
> > >
> > > As there are lots of references to simple-panel.txt, just keep the file
> > > with a reference to panel-common.yaml for now until all the bindings are
> > > converted.
> > >
> > > Cc: Thierry Reding <thierry.reding@gmail.com>
> > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Cc: dri-devel@lists.freedesktop.org
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > Note there's still some references to panel-common.txt that I need to
> > > update or just go ahead and convert to schema.
> > >
> > >  .../bindings/display/panel/panel-common.txt   | 101 -------------
> > >  .../bindings/display/panel/panel-common.yaml  | 143 ++++++++++++++++++
> > >  .../bindings/display/panel/panel.txt          |   4 -
> > >  .../bindings/display/panel/simple-panel.txt   |  29 +---
> > >  4 files changed, 144 insertions(+), 133 deletions(-)
> > >  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt
> > >  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml
> >
> > I know it was this way before, but perhaps remove the redundant panel-
> > prefix while at it?
>
> Sure.

On 2nd thought, I prefer it as-is. The reason being the schema
including this file are more readable with:

allOf:
  - $ref: panel-common.yaml#

Compared to one of:

$ref: common.yaml#
$ref: /schemas/display/panel/common.yaml#

I suppose we could automagically include a 'common.yaml' file if
existing in the same directory. That's a bigger change though...

Rob