new file mode 100644
@@ -0,0 +1,188 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-edp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Probable (via DP AUX / EDID) eDP Panels with simple poweron sequences
+
+maintainers:
+ - Douglas Anderson <dianders@chromium.org>
+
+description: |
+ This binding file can be used to indicate that an eDP panel is connected
+ to a Embedded DisplayPort AUX bus (see display/dp-aux-bus.yaml) without
+ actually specifying exactly what panel is connected. This is useful for
+ the case that more than one different panel could be connected to the
+ board, either for second-sourcing purposes or to support multiple SKUs
+ with different LCDs that hook up to a common board.
+
+ As per above, a requirement for using this binding is that the panel is
+ represented under the DP AUX bus. This means that we can use any
+ information provided by the DP AUX bus (including the EDID) to identify
+ the panel. We can use this to identify display size, resolution, and
+ timings among other things.
+
+ One piece of information about eDP panels that is typically _not_
+ provided anywhere on the DP AUX bus is the power sequencing timings.
+ This is the reason why, historically, we've always had to explicitly
+ list eDP panels. We solve that here with two tricks. The "worst case"
+ power on timings for any panels expected to be connected to a board are
+ specified in these bindings. Once we've powered on, it's expected that
+ the operating system will lookup the panel in a table (based on EDID
+ information) to figure out other power sequencing timings.
+
+ eDP panels in general can have somewhat arbitrary power sequencing
+ requirements. However, even though it's arbitrary in general, the
+ vast majority of panel datasheets have a power sequence diagram that
+ looks the exactly the same as every other panel. Each panel datasheet
+ cares about different timings in this diagram but the fact that the
+ diagram is so similar means we can come up with a single driver to
+ handle it.
+
+ These diagrams all look roughly like this, sometimes labeled with
+ slightly different numbers / lines but all pretty much the same
+ sequence. This is because much of this diagram comes straight from
+ the eDP Standard.
+
+ __________________________________________________
+ Vdd ___/: :\____ /
+ _/ : : \_____/
+ :<T1>:<T2>: :<--T10-->:<T11>:<T12>:
+ : +-----------------------+---------+---------+
+ eDP -----------+ Black video | Src vid | Blk vid +
+ Display : +-----------------------+---------+---------+
+ : _______________________:_________:_________:
+ HPD :<T3>| : : |
+ ___________| : : |_____________
+ : : : :
+ Sink +-----------------------:---------:---------+
+ AUX CH -----------+ AUX Ch operational : : +-------------
+ +-----------------------:---------:---------+
+ : : : :
+ :<T4>: :<T7>: : :
+ Src main +------+------+--------------+---------+
+ lnk data----------------+LnkTrn| Idle |Valid vid data| Idle/off+-------------
+ +------+------+--------------+---------+
+ : <T5> :<-T6->:<-T8->: :
+ :__:<T9>:
+ LED_EN | |
+ _____________________________________| |____________________________
+ : :
+ __________:__:_
+ PWM | : : |
+ __________________________| : : |__________________________
+ : : : :
+ _____________:__________:__:_:______
+ Bklight ____/: : : : : :\____
+ power _______/ :<---T13---->: : : :<T16>: \______________
+ (Vbl) :<T17>:<---------T14--------->: :<-T15->:<T18>:
+
+ The above looks fairly complex but, as per above, each panel only cares
+ about a subset of those timings.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: edp-panel
+
+ hpd-reliable-delay-ms:
+ description:
+ A fixed amount of time that must be waited after powering on the
+ panel's power-supply before the HPD signal is a reliable way to know
+ when the AUX channel is ready. This is useful for panels that glitch
+ the HPD at the start of power-on. This value is not needed if HPD is
+ always reliable for all panels that might be connected.
+
+ hpd-absent-delay-ms:
+ description:
+ The panel specifies that HPD will be asserted this many milliseconds
+ from power on (timing T3 in the diagram above). If we have no way to
+ measure HPD then a fixed delay of this many milliseconds can be used.
+ This can also be used as a timeout when waiting for HPD. Does not
+ include the hpd-reliable-delay, so if hpd-reliable-delay was 80 ms
+ and hpd-absent-delay was 200 ms then we'd do a fixed 80 ms delay and
+ then we know HPD would assert in the next 120 ms. This value is not
+ needed if HPD hooked up, either through a GPIO in the panel node or
+ hooked up directly to the eDP controller.
+
+ backlight: true
+ enable-gpios: true
+ port: true
+ power-supply: true
+ no-hpd: true
+ hpd-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - power-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2d {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2d>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+
+ enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>;
+
+ vpll-supply = <&src_pp1800_s4a>;
+ vccio-supply = <&src_pp1800_s4a>;
+ vcca-supply = <&src_pp1200_l2a>;
+ vcc-supply = <&src_pp1200_l2a>;
+
+ clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
+ clock-names = "refclk";
+
+ no-hpd;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ sn65dsi86_out: endpoint {
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+
+ aux-bus {
+ panel {
+ compatible = "edp-panel";
+ power-supply = <&pp3300_dx_edp>;
+ backlight = <&backlight>;
+ hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>;
+ hpd-reliable-delay-ms = <15>;
+
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&sn65dsi86_out>;
+ };
+ };
+ };
+ };
+ };
+ };