linux/Documentation/devicetree/bindings/display/panel/panel-edp.yaml

# 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: Probeable (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>;
              };
            };
          };
        };
      };
    };