1# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
2%YAML 1.2
3---
4$id: http://devicetree.org/schemas/display/panel/panel-edp.yaml#
5$schema: http://devicetree.org/meta-schemas/core.yaml#
6
7title: Probeable (via DP AUX / EDID) eDP Panels with simple poweron sequences
8
9maintainers:
10  - Douglas Anderson <dianders@chromium.org>
11
12description: |
13  This binding file can be used to indicate that an eDP panel is connected
14  to a Embedded DisplayPort AUX bus (see display/dp-aux-bus.yaml) without
15  actually specifying exactly what panel is connected. This is useful for
16  the case that more than one different panel could be connected to the
17  board, either for second-sourcing purposes or to support multiple SKUs
18  with different LCDs that hook up to a common board.
19
20  As per above, a requirement for using this binding is that the panel is
21  represented under the DP AUX bus. This means that we can use any
22  information provided by the DP AUX bus (including the EDID) to identify
23  the panel. We can use this to identify display size, resolution, and
24  timings among other things.
25
26  One piece of information about eDP panels that is typically _not_
27  provided anywhere on the DP AUX bus is the power sequencing timings.
28  This is the reason why, historically, we've always had to explicitly
29  list eDP panels. We solve that here with two tricks. The "worst case"
30  power on timings for any panels expected to be connected to a board are
31  specified in these bindings. Once we've powered on, it's expected that
32  the operating system will lookup the panel in a table (based on EDID
33  information) to figure out other power sequencing timings.
34
35  eDP panels in general can have somewhat arbitrary power sequencing
36  requirements. However, even though it's arbitrary in general, the
37  vast majority of panel datasheets have a power sequence diagram that
38  looks the exactly the same as every other panel. Each panel datasheet
39  cares about different timings in this diagram but the fact that the
40  diagram is so similar means we can come up with a single driver to
41  handle it.
42
43  These diagrams all look roughly like this, sometimes labeled with
44  slightly different numbers / lines but all pretty much the same
45  sequence. This is because much of this diagram comes straight from
46  the eDP Standard.
47
48                __________________________________________________
49  Vdd       ___/:                                                :\____       /
50          _/    :                                                :     \_____/
51           :<T1>:<T2>:                                 :<--T10-->:<T11>:<T12>:
52                :    +-----------------------+---------+---------+
53  eDP     -----------+ Black video           | Src vid | Blk vid +
54  Display       :    +-----------------------+---------+---------+
55                :     _______________________:_________:_________:
56  HPD           :<T3>|                       :         :         |
57          ___________|                       :         :         |_____________
58                     :                       :         :         :
59  Sink               +-----------------------:---------:---------+
60  AUX CH  -----------+ AUX Ch operational    :         :         +-------------
61                     +-----------------------:---------:---------+
62                     :                       :         :         :
63                     :<T4>:             :<T7>:         :         :
64  Src main                +------+------+--------------+---------+
65  lnk data----------------+LnkTrn| Idle |Valid vid data| Idle/off+-------------
66                          +------+------+--------------+---------+
67                          : <T5> :<-T6->:<-T8->:       :
68                                               :__:<T9>:
69  LED_EN                                       |  |
70          _____________________________________|  |____________________________
71                                               :  :
72                                     __________:__:_
73  PWM                               |          :  : |
74          __________________________|          :  : |__________________________
75                                    :          :  : :
76                       _____________:__________:__:_:______
77  Bklight         ____/:            :          :  : :     :\____
78  power   _______/     :<---T13---->:          :  : :<T16>:     \______________
79  (Vbl)          :<T17>:<---------T14--------->:  :<-T15->:<T18>:
80
81  The above looks fairly complex but, as per above, each panel only cares
82  about a subset of those timings.
83
84allOf:
85  - $ref: panel-common.yaml#
86
87properties:
88  compatible:
89    const: edp-panel
90
91  hpd-reliable-delay-ms:
92    description:
93      A fixed amount of time that must be waited after powering on the
94      panel's power-supply before the HPD signal is a reliable way to know
95      when the AUX channel is ready. This is useful for panels that glitch
96      the HPD at the start of power-on. This value is not needed if HPD is
97      always reliable for all panels that might be connected.
98
99  hpd-absent-delay-ms:
100    description:
101      The panel specifies that HPD will be asserted this many milliseconds
102      from power on (timing T3 in the diagram above). If we have no way to
103      measure HPD then a fixed delay of this many milliseconds can be used.
104      This can also be used as a timeout when waiting for HPD. Does not
105      include the hpd-reliable-delay, so if hpd-reliable-delay was 80 ms
106      and hpd-absent-delay was 200 ms then we'd do a fixed 80 ms delay and
107      then we know HPD would assert in the next 120 ms. This value is not
108      needed if HPD hooked up, either through a GPIO in the panel node or
109      hooked up directly to the eDP controller.
110
111  backlight: true
112  enable-gpios: true
113  port: true
114  power-supply: true
115  no-hpd: true
116  hpd-gpios: true
117
118additionalProperties: false
119
120required:
121  - compatible
122  - power-supply
123
124examples:
125  - |
126    #include <dt-bindings/clock/qcom,rpmh.h>
127    #include <dt-bindings/gpio/gpio.h>
128    #include <dt-bindings/interrupt-controller/irq.h>
129
130    i2c {
131      #address-cells = <1>;
132      #size-cells = <0>;
133
134      bridge@2d {
135        compatible = "ti,sn65dsi86";
136        reg = <0x2d>;
137
138        interrupt-parent = <&tlmm>;
139        interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
140
141        enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>;
142
143        vpll-supply = <&src_pp1800_s4a>;
144        vccio-supply = <&src_pp1800_s4a>;
145        vcca-supply = <&src_pp1200_l2a>;
146        vcc-supply = <&src_pp1200_l2a>;
147
148        clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
149        clock-names = "refclk";
150
151        no-hpd;
152
153        ports {
154          #address-cells = <1>;
155          #size-cells = <0>;
156
157          port@0 {
158            reg = <0>;
159            endpoint {
160              remote-endpoint = <&dsi0_out>;
161            };
162          };
163
164          port@1 {
165            reg = <1>;
166            sn65dsi86_out: endpoint {
167              remote-endpoint = <&panel_in_edp>;
168            };
169          };
170        };
171
172        aux-bus {
173          panel {
174            compatible = "edp-panel";
175            power-supply = <&pp3300_dx_edp>;
176            backlight = <&backlight>;
177            hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>;
178            hpd-reliable-delay-ms = <15>;
179
180            port {
181              panel_in_edp: endpoint {
182                remote-endpoint = <&sn65dsi86_out>;
183              };
184            };
185          };
186        };
187      };
188    };
189