All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	aarch64-laptops@lists.linaro.org
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Vasily Khoruzhick <anarsoul@gmail.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Jeffrey Hugo <jhugo@codeaurora.org>,
	Rob Clark <robdclark@chromium.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND
	FLATTENED DEVICE TREE BINDINGS),
	linux-kernel@vger.kernel.org (open list)
Subject: [PATCH 1/4] dt-bindings: display: panel: document panel-id
Date: Sat,  7 Dec 2019 12:35:50 -0800	[thread overview]
Message-ID: <20191207203553.286017-2-robdclark@gmail.com> (raw)
In-Reply-To: <20191207203553.286017-1-robdclark@gmail.com>

From: Rob Clark <robdclark@chromium.org>

For devices that have one of several possible panels installed, the
panel-id property gives firmware a generic way to locate and enable the
panel node corresponding to the installed panel.  Example of how to use
this property:

    ivo_panel {
        compatible = "ivo,m133nwf4-r0";
        panel-id = <0xc5>;
        status = "disabled";

        ports {
            port {
                ivo_panel_in_edp: endpoint {
                    remote-endpoint = <&sn65dsi86_out_ivo>;
                };
            };
        };
    };

    boe_panel {
        compatible = "boe,nv133fhm-n61";
        panel-id = <0xc4>;
        status = "disabled";

        ports {
            port {
                boe_panel_in_edp: endpoint {
                    remote-endpoint = <&sn65dsi86_out_boe>;
                };
            };
        };
    };

    sn65dsi86: bridge@2c {
        compatible = "ti,sn65dsi86";

        ports {
            #address-cells = <1>;
            #size-cells = <0>;

            port@0 {
                reg = <0>;
                sn65dsi86_in_a: endpoint {
                    remote-endpoint = <&dsi0_out>;
                };
            };

            port@1 {
                reg = <1>;

                sn65dsi86_out_boe: endpoint@c4 {
                    remote-endpoint = <&boe_panel_in_edp>;
                };

                sn65dsi86_out_ivo: endpoint@c5 {
                    remote-endpoint = <&ivo_panel_in_edp>;
                };
            };
        };
    };

Signed-off-by: Rob Clark <robdclark@chromium.org>
---
 .../bindings/display/panel/panel-common.yaml  | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
index ef8d8cdfcede..6113319b91dd 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -75,6 +75,32 @@ properties:
       in the device graph bindings defined in
       Documentation/devicetree/bindings/graph.txt.
 
+  panel-id:
+    description:
+      To support the case where one of several different panels can be installed
+      on a device, the panel-id property can be used by the firmware to identify
+      which panel should have it's status changed to "ok".  This property is not
+      used by the HLOS itself.
+
+      For a device with multiple potential panels, a node for each potential
+      should be defined with status = "disabled", and an appropriate panel-id
+      property.  The video data producer should be setup with endpoints going to
+      each possible panel.  The firmware will find the dt node with a panel-id
+      matching the actual panel installed, and change it's status to "ok".
+
+      The exact method the firmware uses to determine the panel-id of the installed
+      panel is outside the scope of this binding, but a few examples are
+
+      1) u-boot module reading a value from a u-boot env var
+      2) EFI driver module reading a value from an EFI variable
+      3) device specific firmware reading some device specific GPIOs or
+         e-fuse
+
+      The panel-id values are an opaque integer.  They can be sparse.  The only
+      important thing is that each possible panel in the system has a unique
+      panel-id, and that the values configured in the device's DTB match the
+      values that the firmware is looking for.
+
   ddc-i2c-bus:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
-- 
2.23.0


WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com>
To: dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	aarch64-laptops@lists.linaro.org
Cc: Rob Clark <robdclark@chromium.org>,
	Mark Rutland <mark.rutland@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, Jeffrey Hugo <jhugo@codeaurora.org>,
	open list <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Vasily Khoruzhick <anarsoul@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Thierry Reding <thierry.reding@gmail.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: [PATCH 1/4] dt-bindings: display: panel: document panel-id
Date: Sat,  7 Dec 2019 12:35:50 -0800	[thread overview]
Message-ID: <20191207203553.286017-2-robdclark@gmail.com> (raw)
In-Reply-To: <20191207203553.286017-1-robdclark@gmail.com>

From: Rob Clark <robdclark@chromium.org>

For devices that have one of several possible panels installed, the
panel-id property gives firmware a generic way to locate and enable the
panel node corresponding to the installed panel.  Example of how to use
this property:

    ivo_panel {
        compatible = "ivo,m133nwf4-r0";
        panel-id = <0xc5>;
        status = "disabled";

        ports {
            port {
                ivo_panel_in_edp: endpoint {
                    remote-endpoint = <&sn65dsi86_out_ivo>;
                };
            };
        };
    };

    boe_panel {
        compatible = "boe,nv133fhm-n61";
        panel-id = <0xc4>;
        status = "disabled";

        ports {
            port {
                boe_panel_in_edp: endpoint {
                    remote-endpoint = <&sn65dsi86_out_boe>;
                };
            };
        };
    };

    sn65dsi86: bridge@2c {
        compatible = "ti,sn65dsi86";

        ports {
            #address-cells = <1>;
            #size-cells = <0>;

            port@0 {
                reg = <0>;
                sn65dsi86_in_a: endpoint {
                    remote-endpoint = <&dsi0_out>;
                };
            };

            port@1 {
                reg = <1>;

                sn65dsi86_out_boe: endpoint@c4 {
                    remote-endpoint = <&boe_panel_in_edp>;
                };

                sn65dsi86_out_ivo: endpoint@c5 {
                    remote-endpoint = <&ivo_panel_in_edp>;
                };
            };
        };
    };

Signed-off-by: Rob Clark <robdclark@chromium.org>
---
 .../bindings/display/panel/panel-common.yaml  | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
index ef8d8cdfcede..6113319b91dd 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -75,6 +75,32 @@ properties:
       in the device graph bindings defined in
       Documentation/devicetree/bindings/graph.txt.
 
+  panel-id:
+    description:
+      To support the case where one of several different panels can be installed
+      on a device, the panel-id property can be used by the firmware to identify
+      which panel should have it's status changed to "ok".  This property is not
+      used by the HLOS itself.
+
+      For a device with multiple potential panels, a node for each potential
+      should be defined with status = "disabled", and an appropriate panel-id
+      property.  The video data producer should be setup with endpoints going to
+      each possible panel.  The firmware will find the dt node with a panel-id
+      matching the actual panel installed, and change it's status to "ok".
+
+      The exact method the firmware uses to determine the panel-id of the installed
+      panel is outside the scope of this binding, but a few examples are
+
+      1) u-boot module reading a value from a u-boot env var
+      2) EFI driver module reading a value from an EFI variable
+      3) device specific firmware reading some device specific GPIOs or
+         e-fuse
+
+      The panel-id values are an opaque integer.  They can be sparse.  The only
+      important thing is that each possible panel in the system has a unique
+      panel-id, and that the values configured in the device's DTB match the
+      values that the firmware is looking for.
+
   ddc-i2c-bus:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
-- 
2.23.0

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

  reply	other threads:[~2019-12-07 20:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-07 20:35 [PATCH 0/4] drm+dt: multi panel selection and yoga c630 display Rob Clark
2019-12-07 20:35 ` Rob Clark
2019-12-07 20:35 ` Rob Clark [this message]
2019-12-07 20:35   ` [PATCH 1/4] dt-bindings: display: panel: document panel-id Rob Clark
2019-12-07 21:13   ` Sam Ravnborg
2019-12-07 21:13     ` Sam Ravnborg
2019-12-07 21:34     ` Rob Clark
2019-12-07 21:34       ` Rob Clark
2019-12-08  9:39   ` Sam Ravnborg
2019-12-08  9:39     ` Sam Ravnborg
2019-12-08 14:45   ` Laurent Pinchart
2019-12-08 14:45     ` Laurent Pinchart
2019-12-08 16:50     ` Rob Clark
2019-12-08 16:50       ` Rob Clark
2019-12-08 18:27       ` Laurent Pinchart
2019-12-08 18:27         ` Laurent Pinchart
2019-12-08 21:23         ` Rob Clark
2019-12-08 21:23           ` Rob Clark
2019-12-09 11:05           ` Laurent Pinchart
2019-12-09 11:05             ` Laurent Pinchart
2019-12-09 15:31           ` Rob Herring
2019-12-09 15:31             ` Rob Herring
2019-12-09 15:57             ` Rob Clark
2019-12-09 15:57               ` Rob Clark
2019-12-07 20:35 ` [PATCH 2/4] drm/of: add support to find any enabled endpoint Rob Clark
2019-12-07 20:35   ` Rob Clark
2019-12-08  9:31   ` Sam Ravnborg
2019-12-08  9:31     ` Sam Ravnborg
2019-12-07 20:35 ` [PATCH 3/4] drm/bridge: ti-sn65dsi86: " Rob Clark
2019-12-07 20:35   ` Rob Clark
2019-12-07 20:35 ` [PATCH 4/4] arm64: dts: qcom: c630: Enable display Rob Clark
2019-12-07 20:35   ` Rob Clark

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=20191207203553.286017-2-robdclark@gmail.com \
    --to=robdclark@gmail.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=aarch64-laptops@lists.linaro.org \
    --cc=airlied@linux.ie \
    --cc=anarsoul@gmail.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jhugo@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robdclark@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=thierry.reding@gmail.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.