* [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels
2021-07-23 0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
@ 2021-07-23 0:21 ` Douglas Anderson
2021-07-29 20:27 ` Rob Herring
2021-07-23 0:21 ` [RFC PATCH 2/8] drm/edid: Break out reading block 0 of the EDID Douglas Anderson
` (6 subsequent siblings)
7 siblings, 1 reply; 11+ messages in thread
From: Douglas Anderson @ 2021-07-23 0:21 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Maarten Lankhorst, Steev Klimaszewski, dri-devel, David Airlie,
devicetree, Daniel Vetter, Maxime Ripard, Sam Ravnborg,
Thomas Zimmermann, linux-arm-msm, Linus W, Bjorn Andersson,
Douglas Anderson, linux-kernel
eDP panels generally contain almost everything needed to control them
in their EDID. This comes from their DP heritage were a computer needs
to be able to properly control pretty much any DP display that's
plugged into it.
The one big issue with eDP panels and the reason that we need a panel
driver for them is that the power sequencing can be different per
panel.
While it is true that eDP panel sequencing can be arbitrarily complex,
in practice it turns out that many eDP panels are compatible with just
some slightly different delays. See the contents of the bindings file
introduced in this patch for some details.
The fact that eDP panels are 99% probable and that the power
sequencing (especially power up) can be compatible between many panels
means that there's a constant desire to plug multiple different panels
into the same board. This could be for second sourcing purposes or to
support multiple SKUs (maybe a 11" and a 13", for instance).
As discussed [1], it should be OK to support this by adding two
properties to the device tree to specify the delays needed for
powering up the panel the first time. We'll create a new "edp-panel"
bindings file and define the two delays that might need to be
specified. NOTE: in the vast majority of the cases (HPD is hooked up
and isn't glitchy or is debounced) even these delays aren't needed.
In order to help ease the transition, we'll support old "panel-simple"
panels as "fallback" panels. In this case "edp-panel" should be
specified first but if there are problems or a panel is unknown we can
fallback to controlling panels like we used to.
[1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
As usual with anything remotely complicated with yaml bindings, I
mostly messed around with these until it seemed to validate
correctly. Hopefully this is somewhat the way to do things. If folks
would prefer something different (maybe just having one bindings file
for edp-panel and simple-panel) I can change it up.
.../bindings/display/panel/panel-edp.yaml | 196 ++++++
.../bindings/display/panel/panel-simple.yaml | 559 +++++++++---------
2 files changed, 479 insertions(+), 276 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml
new file mode 100644
index 000000000000..7a9dcf270646
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml
@@ -0,0 +1,196 @@
+# 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 fairly 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:
+
+ __________________________________________________
+ 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:
+ items:
+ - const: edp-panel
+
+ # You can list a panel from panel-simple.yaml as a fallback which will
+ # be used for power sequence timings in case the operating system can't
+ # auto-detect using the AUX bus.
+ additionalItems: true
+ minItems: 1
+ maxItems: 2
+
+ hpd-reliable-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ A fixed amount of time (in milliseconds) 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:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ 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", "boe,nv133fhm-n62";
+ power-supply = <&pp3300_dx_edp>;
+ backlight = <&backlight>;
+ hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>;
+ hpd-reliable-delay = <15>;
+
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&sn65dsi86_out>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 3624363938dd..a3ebd2bdbe1e 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -23,284 +23,287 @@ allOf:
- $ref: panel-common.yaml#
properties:
-
compatible:
- enum:
- # compatible must be listed in alphabetical order, ordered by compatible.
- # The description in the comment is mandatory for each compatible.
+ anyOf:
+ - minItems: 1
+ - items:
+ - const: edp-panel
+ - enum:
+ # compatible must be listed in alphabetical order, ordered by compatible.
+ # The description in the comment is mandatory for each compatible.
- # Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel
- - ampire,am-1280800n3tzqw-t00h
- # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
- - ampire,am-480272h3tmqw-t01h
- # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
- - ampire,am800480r3tmqwa1h
- # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
- - auo,b101aw03
- # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
- - auo,b101ean01
- # AU Optronics Corporation 10.1" WXGA TFT LCD panel
- - auo,b101xtn01
- # AUO B116XAK01 eDP TFT LCD panel
- - auo,b116xa01
- # AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel
- - auo,b116xw03
- # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
- - auo,b133htn01
- # AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel
- - auo,b133xtn01
- # AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
- - auo,g070vvn01
- # AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel
- - auo,g101evn010
- # AU Optronics Corporation 10.4" (800x600) color TFT LCD panel
- - auo,g104sn02
- # AU Optronics Corporation 12.1" (1280x800) TFT LCD panel
- - auo,g121ean01
- # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
- - auo,g133han01
- # AU Optronics Corporation 15.6" (1366x768) TFT LCD panel
- - auo,g156xtn01
- # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
- - auo,g185han01
- # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
- - auo,g190ean01
- # AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel
- - auo,p320hvn03
- # AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
- - auo,t215hvn01
- # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel
- - avic,tm070ddh03
- # BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
- - boe,hv070wsa-100
- # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
- - boe,nv101wxmn51
- # BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel
- - boe,nv110wtm-n61
- # BOE NV110WTM-N61 11.0" 2160x1440 TFT LCD Panel
- - boe,nv133fhm-n61
- # BOE NV133FHM-N62 13.3" FHD (1920x1080) TFT LCD Panel
- - boe,nv133fhm-n62
- # BOE NV140FHM-N49 14.0" FHD a-Si FT panel
- - boe,nv140fhmn49
- # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
- - cdtech,s043wq26h-ct7
- # CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel
- - cdtech,s070pws19hp-fc21
- # CDTech(H.K.) Electronics Limited 7" WVGA (800x480) TFT LCD Panel
- - cdtech,s070swv29hg-dc44
- # CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
- - cdtech,s070wv95-ct16
- # Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel
- - chefree,ch101olhlwh-002
- # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
- - chunghwa,claa070wp03xg
- # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
- - chunghwa,claa101wa01a
- # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
- - chunghwa,claa101wb01
- # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
- - chunghwa,claa101wb03
- # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface.
- - dataimage,scf0700c48ggu18
- # DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel
- - dlc,dlc1010gig
- # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel
- - edt,et035012dm6
- # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
- - edt,et057090dhu
- - edt,et070080dh6
- # Emerging Display Technology Corp. 3.5" WVGA TFT LCD panel with
- # capacitive multitouch
- - edt,etm0350g0dh6
- # Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch
- - edt,etm043080dh6gp
- # Emerging Display Technology Corp. 480x272 TFT Display
- - edt,etm0430g0dh6
- # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
- # Same as ETM0700G0DH6 but with inverted pixel clock.
- - edt,etm070080bdh6
- # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
- # Same timings as the ETM0700G0DH6, but with resistive touch.
- - edt,etm070080dh6
- # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
- # Same display as the ETM0700G0BDH6, but with changed hardware for the
- # backlight and the touch interface.
- - edt,etm070080edh6
- - edt,etm0700g0bdh6
- # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
- - edt,etm0700g0dh6
- - edt,etm0700g0edh6
- # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with
- # capacitive touch
- - edt,etmv570g2dhu
- # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
- - evervision,vgg804821
- # Foxlink Group 5" WVGA TFT LCD panel
- - foxlink,fl500wvr00-a0t
- # Frida FRD350H54004 3.5" QVGA TFT LCD panel
- - frida,frd350h54004
- # FriendlyELEC HD702E 800x1280 LCD panel
- - friendlyarm,hd702e
- # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel
- - giantplus,gpg48273qs5
- # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
- - giantplus,gpm940b0
- # HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel
- - hannstar,hsd070pww1
- # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
- - hannstar,hsd100pxn1
- # Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel
- - hit,tx23d38vm0caa
- # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel
- - ivo,m133nwf4-r0
- # Innolux AT043TN24 4.3" WQVGA TFT LCD panel
- - innolux,at043tn24
- # Innolux AT070TN92 7.0" WQVGA TFT LCD panel
- - innolux,at070tn92
- # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
- - innolux,g070y2-l01
- # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel
- - innolux,g101ice-l01
- # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel
- - innolux,g121i1-l01
- # Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
- - innolux,g121x1-l03
- # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- - innolux,n116bca-ea1
- # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- - innolux,n116bge
- # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
- - innolux,n125hce-gn1
- # InnoLux 15.6" WXGA TFT LCD panel
- - innolux,n156bge-l21
- # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
- - innolux,zj070na-01p
- # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
- - kingdisplay,kd116n21-30nv-a010
- # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
- - koe,tx14d24vm1bpa
- # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
- - koe,tx26d202vm0bwa
- # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
- - koe,tx31d200vm0baa
- # Kyocera Corporation 7" WVGA (800x480) transmissive color TFT
- - kyo,tcg070wvlq
- # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
- - kyo,tcg121xglp
- # LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel
- - lemaker,bl035-rgb-002
- # LG 7" (800x480 pixels) TFT LCD panel
- - lg,lb070wv8
- # LG Corporation 5" HD TFT LCD panel
- - lg,lh500wx1-sd03
- # LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
- - lg,lp079qx1-sp0v
- # LG 9.7" (2048x1536 pixels) TFT LCD panel
- - lg,lp097qx1-spa1
- # LG 12.0" (1920x1280 pixels) TFT LCD panel
- - lg,lp120up1
- # LG 12.9" (2560x1700 pixels) TFT LCD panel
- - lg,lp129qe
- # Logic Technologies LT161010-2NHC 7" WVGA TFT Cap Touch Module
- - logictechno,lt161010-2nhc
- # Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module
- - logictechno,lt161010-2nhr
- # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
- - logictechno,lt170410-2whc
- # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
- - mitsubishi,aa070mc01-ca1
- # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel
- - nec,nl12880bc20-05
- # NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
- - nec,nl4827hc19-05b
- # Netron-DY E231732 7.0" WSVGA TFT LCD panel
- - netron-dy,e231732
- # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
- - neweast,wjfh116008a
- # Newhaven Display International 480 x 272 TFT LCD panel
- - newhaven,nhd-4.3-480272ef-atxl
- # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
- - nlt,nl192108ac18-02d
- # New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
- - nvd,9128
- # OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
- - okaya,rs800480t-7x0gp
- # Olimex 4.3" TFT LCD panel
- - olimex,lcd-olinuxino-43-ts
- # On Tat Industrial Company 7" DPI TFT panel.
- - ontat,yx700wv03
- # OrtusTech COM37H3M05DTC Blanview 3.7" VGA portrait TFT-LCD panel
- - ortustech,com37h3m05dtc
- # OrtusTech COM37H3M99DTC Blanview 3.7" VGA portrait TFT-LCD panel
- - ortustech,com37h3m99dtc
- # OrtusTech COM43H4M85ULC Blanview 3.7" TFT-LCD panel
- - ortustech,com43h4m85ulc
- # OSD Displays OSD070T1718-19TS 7" WVGA TFT LCD panel
- - osddisplays,osd070t1718-19ts
- # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel
- - osddisplays,osd101t2045-53ts
- # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel
- - powertip,ph800480t013-idf02
- # QiaoDian XianShi Corporation 4"3 TFT LCD panel
- - qiaodian,qd43003c0-40
- # Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800
- - rocktech,rk101ii01d-ct
- # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
- - rocktech,rk070er9427
- # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
- - samsung,atna33xc20
- # Samsung 12.2" (2560x1600 pixels) TFT LCD panel
- - samsung,lsn122dl01-c01
- # Samsung Electronics 10.1" WSVGA TFT LCD panel
- - samsung,ltn101nt05
- # Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
- - samsung,ltn140at29-301
- # Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel
- - satoz,sat050at40h12r2
- # Sharp LQ035Q7DB03 3.5" QVGA TFT LCD panel
- - sharp,lq035q7db03
- # Sharp LQ070Y3DG3B 7.0" WVGA landscape TFT LCD panel
- - sharp,lq070y3dg3b
- # Sharp Display Corp. LQ101K1LY04 10.07" WXGA TFT LCD panel
- - sharp,lq101k1ly04
- # Sharp 12.3" (2400x1600 pixels) TFT LCD panel
- - sharp,lq123p1jx31
- # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
- - sharp,ls020b1dd01d
- # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel
- - shelly,sca07010-bfn-lnn
- # Starry KR070PE2T 7" WVGA TFT LCD panel
- - starry,kr070pe2t
- # Starry 12.2" (1920x1200 pixels) TFT LCD panel
- - starry,kr122ea0sra
- # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
- - tianma,tm070jdhg30
- # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel
- - tianma,tm070jvhg33
- # Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
- - tianma,tm070rvhg71
- # Toshiba 8.9" WXGA (1280x768) TFT LCD panel
- - toshiba,lt089ac29000
- # TPK U.S.A. LLC Fusion 7" 800 x 480 (WVGA) LCD panel with capacitive touch
- - tpk,f07a-0102
- # TPK U.S.A. LLC Fusion 10.1" 1024 x 600 (WSVGA) LCD panel with capacitive touch
- - tpk,f10a-0102
- # United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
- # Supported are LVDS versions (-11T, -19T) and parallel ones
- # (-T, -1T, -7T, -20T).
- - urt,umsh-8596md-t
- - urt,umsh-8596md-1t
- - urt,umsh-8596md-7t
- - urt,umsh-8596md-11t
- - urt,umsh-8596md-19t
- - urt,umsh-8596md-20t
- # VXT 800x480 color TFT LCD panel
- - vxt,vl050-8048nt-c01
- # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
- - winstar,wf35ltiacd
- # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
- - yes-optoelectronics,ytc700tlag-05-201c
+ # Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel
+ - ampire,am-1280800n3tzqw-t00h
+ # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
+ - ampire,am-480272h3tmqw-t01h
+ # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
+ - ampire,am800480r3tmqwa1h
+ # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+ - auo,b101aw03
+ # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+ - auo,b101ean01
+ # AU Optronics Corporation 10.1" WXGA TFT LCD panel
+ - auo,b101xtn01
+ # AUO B116XAK01 eDP TFT LCD panel
+ - auo,b116xa01
+ # AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel
+ - auo,b116xw03
+ # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
+ - auo,b133htn01
+ # AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel
+ - auo,b133xtn01
+ # AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
+ - auo,g070vvn01
+ # AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel
+ - auo,g101evn010
+ # AU Optronics Corporation 10.4" (800x600) color TFT LCD panel
+ - auo,g104sn02
+ # AU Optronics Corporation 12.1" (1280x800) TFT LCD panel
+ - auo,g121ean01
+ # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
+ - auo,g133han01
+ # AU Optronics Corporation 15.6" (1366x768) TFT LCD panel
+ - auo,g156xtn01
+ # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
+ - auo,g185han01
+ # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
+ - auo,g190ean01
+ # AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel
+ - auo,p320hvn03
+ # AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
+ - auo,t215hvn01
+ # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel
+ - avic,tm070ddh03
+ # BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
+ - boe,hv070wsa-100
+ # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
+ - boe,nv101wxmn51
+ # BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel
+ - boe,nv110wtm-n61
+ # BOE NV110WTM-N61 11.0" 2160x1440 TFT LCD Panel
+ - boe,nv133fhm-n61
+ # BOE NV133FHM-N62 13.3" FHD (1920x1080) TFT LCD Panel
+ - boe,nv133fhm-n62
+ # BOE NV140FHM-N49 14.0" FHD a-Si FT panel
+ - boe,nv140fhmn49
+ # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
+ - cdtech,s043wq26h-ct7
+ # CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel
+ - cdtech,s070pws19hp-fc21
+ # CDTech(H.K.) Electronics Limited 7" WVGA (800x480) TFT LCD Panel
+ - cdtech,s070swv29hg-dc44
+ # CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
+ - cdtech,s070wv95-ct16
+ # Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel
+ - chefree,ch101olhlwh-002
+ # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
+ - chunghwa,claa070wp03xg
+ # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+ - chunghwa,claa101wa01a
+ # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+ - chunghwa,claa101wb01
+ # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+ - chunghwa,claa101wb03
+ # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface.
+ - dataimage,scf0700c48ggu18
+ # DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel
+ - dlc,dlc1010gig
+ # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel
+ - edt,et035012dm6
+ # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
+ - edt,et057090dhu
+ - edt,et070080dh6
+ # Emerging Display Technology Corp. 3.5" WVGA TFT LCD panel with
+ # capacitive multitouch
+ - edt,etm0350g0dh6
+ # Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch
+ - edt,etm043080dh6gp
+ # Emerging Display Technology Corp. 480x272 TFT Display
+ - edt,etm0430g0dh6
+ # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
+ # Same as ETM0700G0DH6 but with inverted pixel clock.
+ - edt,etm070080bdh6
+ # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
+ # Same timings as the ETM0700G0DH6, but with resistive touch.
+ - edt,etm070080dh6
+ # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
+ # Same display as the ETM0700G0BDH6, but with changed hardware for the
+ # backlight and the touch interface.
+ - edt,etm070080edh6
+ - edt,etm0700g0bdh6
+ # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
+ - edt,etm0700g0dh6
+ - edt,etm0700g0edh6
+ # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with
+ # capacitive touch
+ - edt,etmv570g2dhu
+ # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
+ - evervision,vgg804821
+ # Foxlink Group 5" WVGA TFT LCD panel
+ - foxlink,fl500wvr00-a0t
+ # Frida FRD350H54004 3.5" QVGA TFT LCD panel
+ - frida,frd350h54004
+ # FriendlyELEC HD702E 800x1280 LCD panel
+ - friendlyarm,hd702e
+ # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel
+ - giantplus,gpg48273qs5
+ # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
+ - giantplus,gpm940b0
+ # HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel
+ - hannstar,hsd070pww1
+ # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
+ - hannstar,hsd100pxn1
+ # Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel
+ - hit,tx23d38vm0caa
+ # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel
+ - ivo,m133nwf4-r0
+ # Innolux AT043TN24 4.3" WQVGA TFT LCD panel
+ - innolux,at043tn24
+ # Innolux AT070TN92 7.0" WQVGA TFT LCD panel
+ - innolux,at070tn92
+ # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
+ - innolux,g070y2-l01
+ # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel
+ - innolux,g101ice-l01
+ # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel
+ - innolux,g121i1-l01
+ # Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
+ - innolux,g121x1-l03
+ # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
+ - innolux,n116bca-ea1
+ # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
+ - innolux,n116bge
+ # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
+ - innolux,n125hce-gn1
+ # InnoLux 15.6" WXGA TFT LCD panel
+ - innolux,n156bge-l21
+ # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
+ - innolux,zj070na-01p
+ # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
+ - kingdisplay,kd116n21-30nv-a010
+ # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
+ - koe,tx14d24vm1bpa
+ # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
+ - koe,tx26d202vm0bwa
+ # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
+ - koe,tx31d200vm0baa
+ # Kyocera Corporation 7" WVGA (800x480) transmissive color TFT
+ - kyo,tcg070wvlq
+ # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
+ - kyo,tcg121xglp
+ # LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel
+ - lemaker,bl035-rgb-002
+ # LG 7" (800x480 pixels) TFT LCD panel
+ - lg,lb070wv8
+ # LG Corporation 5" HD TFT LCD panel
+ - lg,lh500wx1-sd03
+ # LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
+ - lg,lp079qx1-sp0v
+ # LG 9.7" (2048x1536 pixels) TFT LCD panel
+ - lg,lp097qx1-spa1
+ # LG 12.0" (1920x1280 pixels) TFT LCD panel
+ - lg,lp120up1
+ # LG 12.9" (2560x1700 pixels) TFT LCD panel
+ - lg,lp129qe
+ # Logic Technologies LT161010-2NHC 7" WVGA TFT Cap Touch Module
+ - logictechno,lt161010-2nhc
+ # Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module
+ - logictechno,lt161010-2nhr
+ # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
+ - logictechno,lt170410-2whc
+ # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
+ - mitsubishi,aa070mc01-ca1
+ # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel
+ - nec,nl12880bc20-05
+ # NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
+ - nec,nl4827hc19-05b
+ # Netron-DY E231732 7.0" WSVGA TFT LCD panel
+ - netron-dy,e231732
+ # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
+ - neweast,wjfh116008a
+ # Newhaven Display International 480 x 272 TFT LCD panel
+ - newhaven,nhd-4.3-480272ef-atxl
+ # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
+ - nlt,nl192108ac18-02d
+ # New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
+ - nvd,9128
+ # OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
+ - okaya,rs800480t-7x0gp
+ # Olimex 4.3" TFT LCD panel
+ - olimex,lcd-olinuxino-43-ts
+ # On Tat Industrial Company 7" DPI TFT panel.
+ - ontat,yx700wv03
+ # OrtusTech COM37H3M05DTC Blanview 3.7" VGA portrait TFT-LCD panel
+ - ortustech,com37h3m05dtc
+ # OrtusTech COM37H3M99DTC Blanview 3.7" VGA portrait TFT-LCD panel
+ - ortustech,com37h3m99dtc
+ # OrtusTech COM43H4M85ULC Blanview 3.7" TFT-LCD panel
+ - ortustech,com43h4m85ulc
+ # OSD Displays OSD070T1718-19TS 7" WVGA TFT LCD panel
+ - osddisplays,osd070t1718-19ts
+ # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel
+ - osddisplays,osd101t2045-53ts
+ # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel
+ - powertip,ph800480t013-idf02
+ # QiaoDian XianShi Corporation 4"3 TFT LCD panel
+ - qiaodian,qd43003c0-40
+ # Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800
+ - rocktech,rk101ii01d-ct
+ # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
+ - rocktech,rk070er9427
+ # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
+ - samsung,atna33xc20
+ # Samsung 12.2" (2560x1600 pixels) TFT LCD panel
+ - samsung,lsn122dl01-c01
+ # Samsung Electronics 10.1" WSVGA TFT LCD panel
+ - samsung,ltn101nt05
+ # Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
+ - samsung,ltn140at29-301
+ # Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel
+ - satoz,sat050at40h12r2
+ # Sharp LQ035Q7DB03 3.5" QVGA TFT LCD panel
+ - sharp,lq035q7db03
+ # Sharp LQ070Y3DG3B 7.0" WVGA landscape TFT LCD panel
+ - sharp,lq070y3dg3b
+ # Sharp Display Corp. LQ101K1LY04 10.07" WXGA TFT LCD panel
+ - sharp,lq101k1ly04
+ # Sharp 12.3" (2400x1600 pixels) TFT LCD panel
+ - sharp,lq123p1jx31
+ # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
+ - sharp,ls020b1dd01d
+ # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel
+ - shelly,sca07010-bfn-lnn
+ # Starry KR070PE2T 7" WVGA TFT LCD panel
+ - starry,kr070pe2t
+ # Starry 12.2" (1920x1200 pixels) TFT LCD panel
+ - starry,kr122ea0sra
+ # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
+ - tianma,tm070jdhg30
+ # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel
+ - tianma,tm070jvhg33
+ # Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
+ - tianma,tm070rvhg71
+ # Toshiba 8.9" WXGA (1280x768) TFT LCD panel
+ - toshiba,lt089ac29000
+ # TPK U.S.A. LLC Fusion 7" 800 x 480 (WVGA) LCD panel with capacitive touch
+ - tpk,f07a-0102
+ # TPK U.S.A. LLC Fusion 10.1" 1024 x 600 (WSVGA) LCD panel with capacitive touch
+ - tpk,f10a-0102
+ # United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
+ # Supported are LVDS versions (-11T, -19T) and parallel ones
+ # (-T, -1T, -7T, -20T).
+ - urt,umsh-8596md-t
+ - urt,umsh-8596md-1t
+ - urt,umsh-8596md-7t
+ - urt,umsh-8596md-11t
+ - urt,umsh-8596md-19t
+ - urt,umsh-8596md-20t
+ # VXT 800x480 color TFT LCD panel
+ - vxt,vl050-8048nt-c01
+ # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
+ - winstar,wf35ltiacd
+ # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
+ - yes-optoelectronics,ytc700tlag-05-201c
backlight: true
enable-gpios: true
@@ -309,6 +312,10 @@ properties:
no-hpd: true
hpd-gpios: true
+ # These are OK if we're a fallback for edp-panel
+ hpd-reliable-delay: true
+ hpd-absent-delay: true
+
additionalProperties: false
required:
--
2.32.0.432.gabb21c7263-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels
2021-07-23 0:21 ` [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels Douglas Anderson
@ 2021-07-29 20:27 ` Rob Herring
2021-07-29 21:19 ` Doug Anderson
0 siblings, 1 reply; 11+ messages in thread
From: Rob Herring @ 2021-07-29 20:27 UTC (permalink / raw)
To: Douglas Anderson
Cc: Thierry Reding, Maarten Lankhorst, Steev Klimaszewski, dri-devel,
David Airlie, devicetree, Daniel Vetter, Maxime Ripard,
Sam Ravnborg, Thomas Zimmermann, linux-arm-msm, Linus W,
Bjorn Andersson, linux-kernel
On Thu, Jul 22, 2021 at 05:21:39PM -0700, Douglas Anderson wrote:
> eDP panels generally contain almost everything needed to control them
> in their EDID. This comes from their DP heritage were a computer needs
> to be able to properly control pretty much any DP display that's
> plugged into it.
>
> The one big issue with eDP panels and the reason that we need a panel
> driver for them is that the power sequencing can be different per
> panel.
>
> While it is true that eDP panel sequencing can be arbitrarily complex,
> in practice it turns out that many eDP panels are compatible with just
> some slightly different delays. See the contents of the bindings file
> introduced in this patch for some details.
>
> The fact that eDP panels are 99% probable and that the power
> sequencing (especially power up) can be compatible between many panels
> means that there's a constant desire to plug multiple different panels
> into the same board. This could be for second sourcing purposes or to
> support multiple SKUs (maybe a 11" and a 13", for instance).
>
> As discussed [1], it should be OK to support this by adding two
> properties to the device tree to specify the delays needed for
> powering up the panel the first time. We'll create a new "edp-panel"
> bindings file and define the two delays that might need to be
> specified. NOTE: in the vast majority of the cases (HPD is hooked up
> and isn't glitchy or is debounced) even these delays aren't needed.
>
> In order to help ease the transition, we'll support old "panel-simple"
> panels as "fallback" panels. In this case "edp-panel" should be
> specified first but if there are problems or a panel is unknown we can
> fallback to controlling panels like we used to.
>
> [1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> As usual with anything remotely complicated with yaml bindings, I
> mostly messed around with these until it seemed to validate
> correctly. Hopefully this is somewhat the way to do things. If folks
> would prefer something different (maybe just having one bindings file
> for edp-panel and simple-panel) I can change it up.
>
> .../bindings/display/panel/panel-edp.yaml | 196 ++++++
> .../bindings/display/panel/panel-simple.yaml | 559 +++++++++---------
> 2 files changed, 479 insertions(+), 276 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml
> new file mode 100644
> index 000000000000..7a9dcf270646
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml
> @@ -0,0 +1,196 @@
> +# 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 fairly 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:
> +
> + __________________________________________________
> + 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:
> + items:
> + - const: edp-panel
> +
> + # You can list a panel from panel-simple.yaml as a fallback which will
edp-panel should be the fallback. If you want to define that in schema,
then you need to add another case under a oneOf:
items:
- {}
- const: edp-panel
> + # be used for power sequence timings in case the operating system can't
> + # auto-detect using the AUX bus.
> + additionalItems: true
> + minItems: 1
> + maxItems: 2
and then drop all this.
> +
> + hpd-reliable-delay:
standard unit suffix needed
> + $ref: /schemas/types.yaml#/definitions/uint32
Then you can drop this.
> + description:
> + A fixed amount of time (in milliseconds) 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:
> + $ref: /schemas/types.yaml#/definitions/uint32
Same here.
> + 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", "boe,nv133fhm-n62";
> + power-supply = <&pp3300_dx_edp>;
> + backlight = <&backlight>;
> + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>;
> + hpd-reliable-delay = <15>;
> +
> + port {
> + panel_in_edp: endpoint {
> + remote-endpoint = <&sn65dsi86_out>;
> + };
> + };
> + };
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 3624363938dd..a3ebd2bdbe1e 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -23,284 +23,287 @@ allOf:
> - $ref: panel-common.yaml#
>
> properties:
> -
> compatible:
> - enum:
> - # compatible must be listed in alphabetical order, ordered by compatible.
> - # The description in the comment is mandatory for each compatible.
> + anyOf:
> + - minItems: 1
> + - items:
> + - const: edp-panel
> + - enum:
This is odd... I'm somewhat surprised it works with the dtschema fixups
and 'select' generation code.
> + # compatible must be listed in alphabetical order, ordered by compatible.
> + # The description in the comment is mandatory for each compatible.
>
> - # Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel
> - - ampire,am-1280800n3tzqw-t00h
> - # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> - - ampire,am-480272h3tmqw-t01h
> - # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
> - - ampire,am800480r3tmqwa1h
> - # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
> - - auo,b101aw03
> - # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
> - - auo,b101ean01
> - # AU Optronics Corporation 10.1" WXGA TFT LCD panel
> - - auo,b101xtn01
> - # AUO B116XAK01 eDP TFT LCD panel
> - - auo,b116xa01
> - # AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel
> - - auo,b116xw03
> - # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
> - - auo,b133htn01
> - # AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel
> - - auo,b133xtn01
> - # AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
> - - auo,g070vvn01
> - # AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel
> - - auo,g101evn010
> - # AU Optronics Corporation 10.4" (800x600) color TFT LCD panel
> - - auo,g104sn02
> - # AU Optronics Corporation 12.1" (1280x800) TFT LCD panel
> - - auo,g121ean01
> - # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
> - - auo,g133han01
> - # AU Optronics Corporation 15.6" (1366x768) TFT LCD panel
> - - auo,g156xtn01
> - # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
> - - auo,g185han01
> - # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
> - - auo,g190ean01
> - # AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel
> - - auo,p320hvn03
> - # AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
> - - auo,t215hvn01
> - # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel
> - - avic,tm070ddh03
> - # BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
> - - boe,hv070wsa-100
> - # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
> - - boe,nv101wxmn51
> - # BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel
> - - boe,nv110wtm-n61
> - # BOE NV110WTM-N61 11.0" 2160x1440 TFT LCD Panel
> - - boe,nv133fhm-n61
> - # BOE NV133FHM-N62 13.3" FHD (1920x1080) TFT LCD Panel
> - - boe,nv133fhm-n62
> - # BOE NV140FHM-N49 14.0" FHD a-Si FT panel
> - - boe,nv140fhmn49
> - # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
> - - cdtech,s043wq26h-ct7
> - # CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel
> - - cdtech,s070pws19hp-fc21
> - # CDTech(H.K.) Electronics Limited 7" WVGA (800x480) TFT LCD Panel
> - - cdtech,s070swv29hg-dc44
> - # CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
> - - cdtech,s070wv95-ct16
> - # Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel
> - - chefree,ch101olhlwh-002
> - # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
> - - chunghwa,claa070wp03xg
> - # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> - - chunghwa,claa101wa01a
> - # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> - - chunghwa,claa101wb01
> - # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> - - chunghwa,claa101wb03
> - # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface.
> - - dataimage,scf0700c48ggu18
> - # DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel
> - - dlc,dlc1010gig
> - # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel
> - - edt,et035012dm6
> - # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
> - - edt,et057090dhu
> - - edt,et070080dh6
> - # Emerging Display Technology Corp. 3.5" WVGA TFT LCD panel with
> - # capacitive multitouch
> - - edt,etm0350g0dh6
> - # Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch
> - - edt,etm043080dh6gp
> - # Emerging Display Technology Corp. 480x272 TFT Display
> - - edt,etm0430g0dh6
> - # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
> - # Same as ETM0700G0DH6 but with inverted pixel clock.
> - - edt,etm070080bdh6
> - # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
> - # Same timings as the ETM0700G0DH6, but with resistive touch.
> - - edt,etm070080dh6
> - # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
> - # Same display as the ETM0700G0BDH6, but with changed hardware for the
> - # backlight and the touch interface.
> - - edt,etm070080edh6
> - - edt,etm0700g0bdh6
> - # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
> - - edt,etm0700g0dh6
> - - edt,etm0700g0edh6
> - # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with
> - # capacitive touch
> - - edt,etmv570g2dhu
> - # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
> - - evervision,vgg804821
> - # Foxlink Group 5" WVGA TFT LCD panel
> - - foxlink,fl500wvr00-a0t
> - # Frida FRD350H54004 3.5" QVGA TFT LCD panel
> - - frida,frd350h54004
> - # FriendlyELEC HD702E 800x1280 LCD panel
> - - friendlyarm,hd702e
> - # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel
> - - giantplus,gpg48273qs5
> - # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
> - - giantplus,gpm940b0
> - # HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel
> - - hannstar,hsd070pww1
> - # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
> - - hannstar,hsd100pxn1
> - # Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel
> - - hit,tx23d38vm0caa
> - # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel
> - - ivo,m133nwf4-r0
> - # Innolux AT043TN24 4.3" WQVGA TFT LCD panel
> - - innolux,at043tn24
> - # Innolux AT070TN92 7.0" WQVGA TFT LCD panel
> - - innolux,at070tn92
> - # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
> - - innolux,g070y2-l01
> - # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel
> - - innolux,g101ice-l01
> - # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel
> - - innolux,g121i1-l01
> - # Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
> - - innolux,g121x1-l03
> - # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
> - - innolux,n116bca-ea1
> - # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
> - - innolux,n116bge
> - # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
> - - innolux,n125hce-gn1
> - # InnoLux 15.6" WXGA TFT LCD panel
> - - innolux,n156bge-l21
> - # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
> - - innolux,zj070na-01p
> - # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
> - - kingdisplay,kd116n21-30nv-a010
> - # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
> - - koe,tx14d24vm1bpa
> - # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
> - - koe,tx26d202vm0bwa
> - # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
> - - koe,tx31d200vm0baa
> - # Kyocera Corporation 7" WVGA (800x480) transmissive color TFT
> - - kyo,tcg070wvlq
> - # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
> - - kyo,tcg121xglp
> - # LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel
> - - lemaker,bl035-rgb-002
> - # LG 7" (800x480 pixels) TFT LCD panel
> - - lg,lb070wv8
> - # LG Corporation 5" HD TFT LCD panel
> - - lg,lh500wx1-sd03
> - # LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
> - - lg,lp079qx1-sp0v
> - # LG 9.7" (2048x1536 pixels) TFT LCD panel
> - - lg,lp097qx1-spa1
> - # LG 12.0" (1920x1280 pixels) TFT LCD panel
> - - lg,lp120up1
> - # LG 12.9" (2560x1700 pixels) TFT LCD panel
> - - lg,lp129qe
> - # Logic Technologies LT161010-2NHC 7" WVGA TFT Cap Touch Module
> - - logictechno,lt161010-2nhc
> - # Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module
> - - logictechno,lt161010-2nhr
> - # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
> - - logictechno,lt170410-2whc
> - # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
> - - mitsubishi,aa070mc01-ca1
> - # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel
> - - nec,nl12880bc20-05
> - # NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
> - - nec,nl4827hc19-05b
> - # Netron-DY E231732 7.0" WSVGA TFT LCD panel
> - - netron-dy,e231732
> - # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
> - - neweast,wjfh116008a
> - # Newhaven Display International 480 x 272 TFT LCD panel
> - - newhaven,nhd-4.3-480272ef-atxl
> - # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
> - - nlt,nl192108ac18-02d
> - # New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
> - - nvd,9128
> - # OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
> - - okaya,rs800480t-7x0gp
> - # Olimex 4.3" TFT LCD panel
> - - olimex,lcd-olinuxino-43-ts
> - # On Tat Industrial Company 7" DPI TFT panel.
> - - ontat,yx700wv03
> - # OrtusTech COM37H3M05DTC Blanview 3.7" VGA portrait TFT-LCD panel
> - - ortustech,com37h3m05dtc
> - # OrtusTech COM37H3M99DTC Blanview 3.7" VGA portrait TFT-LCD panel
> - - ortustech,com37h3m99dtc
> - # OrtusTech COM43H4M85ULC Blanview 3.7" TFT-LCD panel
> - - ortustech,com43h4m85ulc
> - # OSD Displays OSD070T1718-19TS 7" WVGA TFT LCD panel
> - - osddisplays,osd070t1718-19ts
> - # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel
> - - osddisplays,osd101t2045-53ts
> - # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel
> - - powertip,ph800480t013-idf02
> - # QiaoDian XianShi Corporation 4"3 TFT LCD panel
> - - qiaodian,qd43003c0-40
> - # Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800
> - - rocktech,rk101ii01d-ct
> - # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
> - - rocktech,rk070er9427
> - # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
> - - samsung,atna33xc20
> - # Samsung 12.2" (2560x1600 pixels) TFT LCD panel
> - - samsung,lsn122dl01-c01
> - # Samsung Electronics 10.1" WSVGA TFT LCD panel
> - - samsung,ltn101nt05
> - # Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
> - - samsung,ltn140at29-301
> - # Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel
> - - satoz,sat050at40h12r2
> - # Sharp LQ035Q7DB03 3.5" QVGA TFT LCD panel
> - - sharp,lq035q7db03
> - # Sharp LQ070Y3DG3B 7.0" WVGA landscape TFT LCD panel
> - - sharp,lq070y3dg3b
> - # Sharp Display Corp. LQ101K1LY04 10.07" WXGA TFT LCD panel
> - - sharp,lq101k1ly04
> - # Sharp 12.3" (2400x1600 pixels) TFT LCD panel
> - - sharp,lq123p1jx31
> - # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
> - - sharp,ls020b1dd01d
> - # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel
> - - shelly,sca07010-bfn-lnn
> - # Starry KR070PE2T 7" WVGA TFT LCD panel
> - - starry,kr070pe2t
> - # Starry 12.2" (1920x1200 pixels) TFT LCD panel
> - - starry,kr122ea0sra
> - # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
> - - tianma,tm070jdhg30
> - # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel
> - - tianma,tm070jvhg33
> - # Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
> - - tianma,tm070rvhg71
> - # Toshiba 8.9" WXGA (1280x768) TFT LCD panel
> - - toshiba,lt089ac29000
> - # TPK U.S.A. LLC Fusion 7" 800 x 480 (WVGA) LCD panel with capacitive touch
> - - tpk,f07a-0102
> - # TPK U.S.A. LLC Fusion 10.1" 1024 x 600 (WSVGA) LCD panel with capacitive touch
> - - tpk,f10a-0102
> - # United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
> - # Supported are LVDS versions (-11T, -19T) and parallel ones
> - # (-T, -1T, -7T, -20T).
> - - urt,umsh-8596md-t
> - - urt,umsh-8596md-1t
> - - urt,umsh-8596md-7t
> - - urt,umsh-8596md-11t
> - - urt,umsh-8596md-19t
> - - urt,umsh-8596md-20t
> - # VXT 800x480 color TFT LCD panel
> - - vxt,vl050-8048nt-c01
> - # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
> - - winstar,wf35ltiacd
> - # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
> - - yes-optoelectronics,ytc700tlag-05-201c
> + # Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel
> + - ampire,am-1280800n3tzqw-t00h
> + # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> + - ampire,am-480272h3tmqw-t01h
> + # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
> + - ampire,am800480r3tmqwa1h
> + # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
> + - auo,b101aw03
> + # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
> + - auo,b101ean01
> + # AU Optronics Corporation 10.1" WXGA TFT LCD panel
> + - auo,b101xtn01
> + # AUO B116XAK01 eDP TFT LCD panel
> + - auo,b116xa01
> + # AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel
> + - auo,b116xw03
> + # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
> + - auo,b133htn01
> + # AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel
> + - auo,b133xtn01
> + # AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
> + - auo,g070vvn01
> + # AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel
> + - auo,g101evn010
> + # AU Optronics Corporation 10.4" (800x600) color TFT LCD panel
> + - auo,g104sn02
> + # AU Optronics Corporation 12.1" (1280x800) TFT LCD panel
> + - auo,g121ean01
> + # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
> + - auo,g133han01
> + # AU Optronics Corporation 15.6" (1366x768) TFT LCD panel
> + - auo,g156xtn01
> + # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
> + - auo,g185han01
> + # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
> + - auo,g190ean01
> + # AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel
> + - auo,p320hvn03
> + # AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
> + - auo,t215hvn01
> + # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel
> + - avic,tm070ddh03
> + # BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
> + - boe,hv070wsa-100
> + # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
> + - boe,nv101wxmn51
> + # BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel
> + - boe,nv110wtm-n61
> + # BOE NV110WTM-N61 11.0" 2160x1440 TFT LCD Panel
> + - boe,nv133fhm-n61
> + # BOE NV133FHM-N62 13.3" FHD (1920x1080) TFT LCD Panel
> + - boe,nv133fhm-n62
> + # BOE NV140FHM-N49 14.0" FHD a-Si FT panel
> + - boe,nv140fhmn49
> + # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
> + - cdtech,s043wq26h-ct7
> + # CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel
> + - cdtech,s070pws19hp-fc21
> + # CDTech(H.K.) Electronics Limited 7" WVGA (800x480) TFT LCD Panel
> + - cdtech,s070swv29hg-dc44
> + # CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
> + - cdtech,s070wv95-ct16
> + # Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel
> + - chefree,ch101olhlwh-002
> + # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
> + - chunghwa,claa070wp03xg
> + # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> + - chunghwa,claa101wa01a
> + # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> + - chunghwa,claa101wb01
> + # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> + - chunghwa,claa101wb03
> + # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface.
> + - dataimage,scf0700c48ggu18
> + # DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel
> + - dlc,dlc1010gig
> + # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel
> + - edt,et035012dm6
> + # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
> + - edt,et057090dhu
> + - edt,et070080dh6
> + # Emerging Display Technology Corp. 3.5" WVGA TFT LCD panel with
> + # capacitive multitouch
> + - edt,etm0350g0dh6
> + # Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch
> + - edt,etm043080dh6gp
> + # Emerging Display Technology Corp. 480x272 TFT Display
> + - edt,etm0430g0dh6
> + # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
> + # Same as ETM0700G0DH6 but with inverted pixel clock.
> + - edt,etm070080bdh6
> + # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
> + # Same timings as the ETM0700G0DH6, but with resistive touch.
> + - edt,etm070080dh6
> + # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
> + # Same display as the ETM0700G0BDH6, but with changed hardware for the
> + # backlight and the touch interface.
> + - edt,etm070080edh6
> + - edt,etm0700g0bdh6
> + # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch
> + - edt,etm0700g0dh6
> + - edt,etm0700g0edh6
> + # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with
> + # capacitive touch
> + - edt,etmv570g2dhu
> + # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
> + - evervision,vgg804821
> + # Foxlink Group 5" WVGA TFT LCD panel
> + - foxlink,fl500wvr00-a0t
> + # Frida FRD350H54004 3.5" QVGA TFT LCD panel
> + - frida,frd350h54004
> + # FriendlyELEC HD702E 800x1280 LCD panel
> + - friendlyarm,hd702e
> + # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel
> + - giantplus,gpg48273qs5
> + # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
> + - giantplus,gpm940b0
> + # HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel
> + - hannstar,hsd070pww1
> + # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
> + - hannstar,hsd100pxn1
> + # Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel
> + - hit,tx23d38vm0caa
> + # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel
> + - ivo,m133nwf4-r0
> + # Innolux AT043TN24 4.3" WQVGA TFT LCD panel
> + - innolux,at043tn24
> + # Innolux AT070TN92 7.0" WQVGA TFT LCD panel
> + - innolux,at070tn92
> + # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
> + - innolux,g070y2-l01
> + # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel
> + - innolux,g101ice-l01
> + # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel
> + - innolux,g121i1-l01
> + # Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
> + - innolux,g121x1-l03
> + # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
> + - innolux,n116bca-ea1
> + # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
> + - innolux,n116bge
> + # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
> + - innolux,n125hce-gn1
> + # InnoLux 15.6" WXGA TFT LCD panel
> + - innolux,n156bge-l21
> + # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
> + - innolux,zj070na-01p
> + # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
> + - kingdisplay,kd116n21-30nv-a010
> + # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
> + - koe,tx14d24vm1bpa
> + # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
> + - koe,tx26d202vm0bwa
> + # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
> + - koe,tx31d200vm0baa
> + # Kyocera Corporation 7" WVGA (800x480) transmissive color TFT
> + - kyo,tcg070wvlq
> + # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
> + - kyo,tcg121xglp
> + # LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel
> + - lemaker,bl035-rgb-002
> + # LG 7" (800x480 pixels) TFT LCD panel
> + - lg,lb070wv8
> + # LG Corporation 5" HD TFT LCD panel
> + - lg,lh500wx1-sd03
> + # LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
> + - lg,lp079qx1-sp0v
> + # LG 9.7" (2048x1536 pixels) TFT LCD panel
> + - lg,lp097qx1-spa1
> + # LG 12.0" (1920x1280 pixels) TFT LCD panel
> + - lg,lp120up1
> + # LG 12.9" (2560x1700 pixels) TFT LCD panel
> + - lg,lp129qe
> + # Logic Technologies LT161010-2NHC 7" WVGA TFT Cap Touch Module
> + - logictechno,lt161010-2nhc
> + # Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module
> + - logictechno,lt161010-2nhr
> + # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
> + - logictechno,lt170410-2whc
> + # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
> + - mitsubishi,aa070mc01-ca1
> + # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel
> + - nec,nl12880bc20-05
> + # NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
> + - nec,nl4827hc19-05b
> + # Netron-DY E231732 7.0" WSVGA TFT LCD panel
> + - netron-dy,e231732
> + # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
> + - neweast,wjfh116008a
> + # Newhaven Display International 480 x 272 TFT LCD panel
> + - newhaven,nhd-4.3-480272ef-atxl
> + # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
> + - nlt,nl192108ac18-02d
> + # New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
> + - nvd,9128
> + # OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
> + - okaya,rs800480t-7x0gp
> + # Olimex 4.3" TFT LCD panel
> + - olimex,lcd-olinuxino-43-ts
> + # On Tat Industrial Company 7" DPI TFT panel.
> + - ontat,yx700wv03
> + # OrtusTech COM37H3M05DTC Blanview 3.7" VGA portrait TFT-LCD panel
> + - ortustech,com37h3m05dtc
> + # OrtusTech COM37H3M99DTC Blanview 3.7" VGA portrait TFT-LCD panel
> + - ortustech,com37h3m99dtc
> + # OrtusTech COM43H4M85ULC Blanview 3.7" TFT-LCD panel
> + - ortustech,com43h4m85ulc
> + # OSD Displays OSD070T1718-19TS 7" WVGA TFT LCD panel
> + - osddisplays,osd070t1718-19ts
> + # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel
> + - osddisplays,osd101t2045-53ts
> + # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel
> + - powertip,ph800480t013-idf02
> + # QiaoDian XianShi Corporation 4"3 TFT LCD panel
> + - qiaodian,qd43003c0-40
> + # Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800
> + - rocktech,rk101ii01d-ct
> + # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
> + - rocktech,rk070er9427
> + # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
> + - samsung,atna33xc20
> + # Samsung 12.2" (2560x1600 pixels) TFT LCD panel
> + - samsung,lsn122dl01-c01
> + # Samsung Electronics 10.1" WSVGA TFT LCD panel
> + - samsung,ltn101nt05
> + # Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
> + - samsung,ltn140at29-301
> + # Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel
> + - satoz,sat050at40h12r2
> + # Sharp LQ035Q7DB03 3.5" QVGA TFT LCD panel
> + - sharp,lq035q7db03
> + # Sharp LQ070Y3DG3B 7.0" WVGA landscape TFT LCD panel
> + - sharp,lq070y3dg3b
> + # Sharp Display Corp. LQ101K1LY04 10.07" WXGA TFT LCD panel
> + - sharp,lq101k1ly04
> + # Sharp 12.3" (2400x1600 pixels) TFT LCD panel
> + - sharp,lq123p1jx31
> + # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
> + - sharp,ls020b1dd01d
> + # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel
> + - shelly,sca07010-bfn-lnn
> + # Starry KR070PE2T 7" WVGA TFT LCD panel
> + - starry,kr070pe2t
> + # Starry 12.2" (1920x1200 pixels) TFT LCD panel
> + - starry,kr122ea0sra
> + # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
> + - tianma,tm070jdhg30
> + # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel
> + - tianma,tm070jvhg33
> + # Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
> + - tianma,tm070rvhg71
> + # Toshiba 8.9" WXGA (1280x768) TFT LCD panel
> + - toshiba,lt089ac29000
> + # TPK U.S.A. LLC Fusion 7" 800 x 480 (WVGA) LCD panel with capacitive touch
> + - tpk,f07a-0102
> + # TPK U.S.A. LLC Fusion 10.1" 1024 x 600 (WSVGA) LCD panel with capacitive touch
> + - tpk,f10a-0102
> + # United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
> + # Supported are LVDS versions (-11T, -19T) and parallel ones
> + # (-T, -1T, -7T, -20T).
> + - urt,umsh-8596md-t
> + - urt,umsh-8596md-1t
> + - urt,umsh-8596md-7t
> + - urt,umsh-8596md-11t
> + - urt,umsh-8596md-19t
> + - urt,umsh-8596md-20t
> + # VXT 800x480 color TFT LCD panel
> + - vxt,vl050-8048nt-c01
> + # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
> + - winstar,wf35ltiacd
> + # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
> + - yes-optoelectronics,ytc700tlag-05-201c
Well, this is going to cause every patch to conflict...
IMO, you should move any applicable compatibles to the edp-panel schema.
Also, I don't think you should add 'edp-panel' to them. If they can work
better with the generic eDP driver, then that should be an internal
kernel change without a DT change. Also, if 2 different drivers match on
compatible, it's a roll of the dice which driver binds.
Rob
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels
2021-07-29 20:27 ` Rob Herring
@ 2021-07-29 21:19 ` Doug Anderson
0 siblings, 0 replies; 11+ messages in thread
From: Doug Anderson @ 2021-07-29 21:19 UTC (permalink / raw)
To: Rob Herring
Cc: Thierry Reding, Maarten Lankhorst, Steev Klimaszewski, dri-devel,
David Airlie,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Daniel Vetter, Maxime Ripard, Sam Ravnborg, Thomas Zimmermann,
linux-arm-msm, Linus W, Bjorn Andersson, LKML
Hi,
On Thu, Jul 29, 2021 at 1:27 PM Rob Herring <robh@kernel.org> wrote:
>
> IMO, you should move any applicable compatibles to the edp-panel schema.
> Also, I don't think you should add 'edp-panel' to them. If they can work
> better with the generic eDP driver, then that should be an internal
> kernel change without a DT change. Also, if 2 different drivers match on
> compatible, it's a roll of the dice which driver binds.
So overall what I was going for is this:
1. I want to be able to specify _just_ "edp-panel" for new boards.
We'll make sure this is how it looks on devices that go through the
factory and thus we can make sure that the driver can recognize all
panels that get shipped.
2. For existing boards, I'd like to be able to move them to use
"edp-panel" but I'm less confident that I can really say exactly what
panels are out there in the field. Even though our device tree has
always listed only one panel, in truth boards have shipped with more
than one and they've just been "compatible enough" with each other
(this "white lie" is what I'm trying to fix). If somehow the generic
"edp-panel" doesn't recognize a panel then I wanted to be able to use
the old timings we'd always had before as a "fallback". That means
that logically I wanted "edp-panel" to be first and only fallback to
the old compatible string if we didn't recognize the panel ID that
came from the EDID. In truth, both compatible strings are handled by
the same driver the driver patch I submitted tried to be smart.
Perhaps that above is over ambitious and it'd be better to just drop
the whole "fallback" concept. If a board manufacturer wants to start
using the "edp-panel" concept then maybe the right idea is to force
them to bump the "board id" and then we can pick a new device tree
revision. Then we can make sure all boards that come out of the
factory with that new "board id" can be identified properly in the
EDID. This will also get rid of some of the complexity in the driver
patch, which is nice. I'll plan on doing this and address your other
feedback for a v2.
-Doug
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC PATCH 2/8] drm/edid: Break out reading block 0 of the EDID
2021-07-23 0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels Douglas Anderson
@ 2021-07-23 0:21 ` Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 3/8] drm/edid: Allow the querying/working with the panel ID from " Douglas Anderson
` (5 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: Douglas Anderson @ 2021-07-23 0:21 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Maarten Lankhorst, Steev Klimaszewski, dri-devel, David Airlie,
devicetree, Daniel Vetter, Maxime Ripard, Sam Ravnborg,
Thomas Zimmermann, linux-arm-msm, Linus W, Bjorn Andersson,
Douglas Anderson, linux-kernel
A future change wants to be able to read just block 0 of the EDID, so
break it out of drm_do_get_edid() into a sub-function.
This is intended to be a no-op change--just code movement.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/gpu/drm/drm_edid.c | 62 +++++++++++++++++++++++++++-----------
1 file changed, 44 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 81d5f2524246..a623a80f7edb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1905,6 +1905,43 @@ int drm_add_override_edid_modes(struct drm_connector *connector)
}
EXPORT_SYMBOL(drm_add_override_edid_modes);
+static struct edid *drm_do_get_edid_blk0(
+ int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
+ size_t len),
+ void *data, bool *edid_corrupt, int *null_edid_counter)
+{
+ int i;
+ u8 *edid;
+
+ if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
+ return NULL;
+
+ /* base block fetch */
+ for (i = 0; i < 4; i++) {
+ if (get_edid_block(data, edid, 0, EDID_LENGTH))
+ goto out;
+ if (drm_edid_block_valid(edid, 0, false, edid_corrupt))
+ break;
+ if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
+ if (null_edid_counter)
+ (*null_edid_counter)++;
+ goto carp;
+ }
+ }
+ if (i == 4)
+ goto carp;
+
+ return (struct edid *)edid;
+
+carp:
+ kfree(edid);
+ return ERR_PTR(-EINVAL);
+
+out:
+ kfree(edid);
+ return NULL;
+}
+
/**
* drm_do_get_edid - get EDID data using a custom EDID block read function
* @connector: connector we're probing
@@ -1938,25 +1975,16 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
if (override)
return override;
- if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
+ edid = (u8 *)drm_do_get_edid_blk0(get_edid_block, data,
+ &connector->edid_corrupt,
+ &connector->null_edid_counter);
+ if (IS_ERR_OR_NULL(edid)) {
+ if (IS_ERR(edid))
+ connector_bad_edid(connector, edid, 1);
return NULL;
-
- /* base block fetch */
- for (i = 0; i < 4; i++) {
- if (get_edid_block(data, edid, 0, EDID_LENGTH))
- goto out;
- if (drm_edid_block_valid(edid, 0, false,
- &connector->edid_corrupt))
- break;
- if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
- connector->null_edid_counter++;
- goto carp;
- }
}
- if (i == 4)
- goto carp;
- /* if there's no extensions, we're done */
+ /* if there's no extensions or no connector, we're done */
valid_extensions = edid[0x7e];
if (valid_extensions == 0)
return (struct edid *)edid;
@@ -2010,8 +2038,6 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
return (struct edid *)edid;
-carp:
- connector_bad_edid(connector, edid, 1);
out:
kfree(edid);
return NULL;
--
2.32.0.432.gabb21c7263-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread* [RFC PATCH 3/8] drm/edid: Allow the querying/working with the panel ID from the EDID
2021-07-23 0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 2/8] drm/edid: Break out reading block 0 of the EDID Douglas Anderson
@ 2021-07-23 0:21 ` Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 4/8] drm/panel-simple: Don't re-read the EDID every time we power off the panel Douglas Anderson
` (4 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: Douglas Anderson @ 2021-07-23 0:21 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Maarten Lankhorst, Steev Klimaszewski, dri-devel, David Airlie,
devicetree, Daniel Vetter, Maxime Ripard, Sam Ravnborg,
Thomas Zimmermann, linux-arm-msm, Linus W, Bjorn Andersson,
Douglas Anderson, linux-kernel
EDIDs have 32-bits worth of data which is intended to be used to
uniquely identify the make/model of a panel. This has historically
been used only internally in the EDID processing code to identify
quirks with panels.
We'd like to use this panel ID in panel-simple to identify which panel
is hooked up and from that information figure out power sequence
timings. Let's expose this information from the EDID code and also
allow it to be accessed early, before a connector has been created.
To make matching in the panel-simple code easier, we'll return the
panel ID as a 32-bit value. We'll provide some functions for
converting this value back and forth to something more human readable.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/gpu/drm/drm_edid.c | 51 ++++++++++++++++++++++++++++++++++++++
include/drm/drm_edid.h | 47 +++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a623a80f7edb..43633e083ecd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2086,6 +2086,57 @@ struct edid *drm_get_edid(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_get_edid);
+/**
+ * drm_get_panel_id - Get a panel's ID through DDC
+ * @adapter: I2C adapter to use for DDC
+ *
+ * This function reads the first block of the EDID of a panel and (assuming
+ * that the EDID is valid) extracts the ID out of it. The ID is a 32-bit value
+ * (16 bits of manufacturer ID and 16 bits of per-manufacturer ID) that's
+ * supposed to be different for each different modem of panel.
+ *
+ * This function is intended to be used during early probing on devices where
+ * more than one panel might be present. Because of its intended use it must
+ * assume that the EDID of the panel is correct, at least as far as the ID
+ * is concerned (in other words, we don't process any overrides here).
+ *
+ * NOTE: it's expected that this function and drm_do_get_edid() will both
+ * be read the EDID, but there is no caching between them. Since we're only
+ * reading the first block, hopefully this extra overhead won't be too big.
+ *
+ * Return: A 32-bit ID that should be different for each make/model of panel.
+ * See the functions encode_edid_id() and decode_edid_id() for some
+ * details on the structure of this ID.
+ */
+u32 drm_get_panel_id(struct i2c_adapter *adapter)
+{
+ struct edid *edid;
+ u32 val;
+
+ edid = drm_do_get_edid_blk0(drm_do_probe_ddc_edid, adapter, NULL, NULL);
+
+ /*
+ * There are no manufacturer IDs of 0, so if there is a problem reading
+ * the EDID then we'll just return 0.
+ */
+ if (IS_ERR_OR_NULL(edid))
+ return 0;
+
+ /*
+ * In theory we could try to de-obfuscate this like edid_get_quirks()
+ * does, but it's easier to just deal with a 32-bit number.
+ */
+ val = (u32)edid->mfg_id[0] << 24 |
+ (u32)edid->mfg_id[1] << 16 |
+ (u32)edid->prod_code[0] << 8 |
+ (u32)edid->prod_code[1] << 0;
+
+ kfree(edid);
+
+ return val;
+}
+EXPORT_SYMBOL(drm_get_panel_id);
+
/**
* drm_get_edid_switcheroo - get EDID data for a vga_switcheroo output
* @connector: connector we're probing
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 759328a5eeb2..75a23caa7709 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -508,6 +508,52 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
}
+/**
+ * encode_edid_id - Encode an ID for matching against drm_get_panel_id()
+ * @vend_chr_0: First character of the vendor string.
+ * @vend_chr_2: Second character of the vendor string.
+ * @vend_chr_3: Third character of the vendor string.
+ * @product_id: The 16-bit product ID.
+ *
+ * This is a macro so that it can be calculated at compile time and used
+ * as an initializer.
+ *
+ * For instance:
+ * encode_edid_id('B', 'O', 'E', 0x2d08) => 0x09e52d08
+ *
+ * Return: a 32-bit ID per panel.
+ */
+#define encode_edid_id(vend_chr_0, vend_chr_1, vend_chr_2, product_id) \
+ ((((u32)(vend_chr_0) - '@') & 0x1f) << 26 | \
+ (((u32)(vend_chr_1) - '@') & 0x1f) << 21 | \
+ (((u32)(vend_chr_2) - '@') & 0x1f) << 16 | \
+ ((product_id) & 0xffff))
+
+/**
+ * decode_edid_id - Decode a panel ID from encode_edid_id()
+ * @panel_id: The panel ID to decode.
+ * @vend: A 4-byte buffer to store the 3-letter vendor string plus a '\0'
+ * termination
+ * @product_id: The product ID will be returned here.
+ *
+ * For instance, after:
+ * decode_edid_id(0x09e52d08, vend, &product_id)
+ * These will be true:
+ * vend[0] = 'B'
+ * vend[1] = 'O'
+ * vend[2] = 'E'
+ * vend[3] = '\0'
+ * product_id = 0x2d08
+ */
+static inline void decode_edid_id(u32 panel_id, char vend[4], u16 *product_id)
+{
+ *product_id = (u16)(panel_id & 0xffff);
+ vend[0] = '@' + ((panel_id >> 26) & 0x1f);
+ vend[1] = '@' + ((panel_id >> 21) & 0x1f);
+ vend[2] = '@' + ((panel_id >> 16) & 0x1f);
+ vend[3] = '\0';
+}
+
bool drm_probe_ddc(struct i2c_adapter *adapter);
struct edid *drm_do_get_edid(struct drm_connector *connector,
int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
@@ -515,6 +561,7 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
void *data);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
+u32 drm_get_panel_id(struct i2c_adapter *adapter);
struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
struct i2c_adapter *adapter);
struct edid *drm_edid_duplicate(const struct edid *edid);
--
2.32.0.432.gabb21c7263-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread* [RFC PATCH 4/8] drm/panel-simple: Don't re-read the EDID every time we power off the panel
2021-07-23 0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
` (2 preceding siblings ...)
2021-07-23 0:21 ` [RFC PATCH 3/8] drm/edid: Allow the querying/working with the panel ID from " Douglas Anderson
@ 2021-07-23 0:21 ` Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 5/8] drm/panel-simple: Copy "desc" into driver data; don't store a pointer Douglas Anderson
` (3 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: Douglas Anderson @ 2021-07-23 0:21 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Maarten Lankhorst, Steev Klimaszewski, dri-devel, David Airlie,
devicetree, Daniel Vetter, Maxime Ripard, Sam Ravnborg,
Thomas Zimmermann, linux-arm-msm, Linus W, Bjorn Andersson,
Douglas Anderson, linux-kernel
The simple-panel driver is for panels that are not hot-pluggable at
runtime. Let's keep our cached EDID around until driver unload.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/gpu/drm/panel/panel-simple.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9b286bd4444f..bcdc84b20827 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -370,9 +370,6 @@ static int panel_simple_suspend(struct device *dev)
regulator_disable(p->supply);
p->unprepared_time = ktime_get();
- kfree(p->edid);
- p->edid = NULL;
-
return 0;
}
@@ -862,6 +859,9 @@ static int panel_simple_remove(struct device *dev)
if (panel->ddc && (!panel->aux || panel->ddc != &panel->aux->ddc))
put_device(&panel->ddc->dev);
+ kfree(panel->edid);
+ panel->edid = NULL;
+
return 0;
}
--
2.32.0.432.gabb21c7263-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread* [RFC PATCH 5/8] drm/panel-simple: Copy "desc" into driver data; don't store a pointer
2021-07-23 0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
` (3 preceding siblings ...)
2021-07-23 0:21 ` [RFC PATCH 4/8] drm/panel-simple: Don't re-read the EDID every time we power off the panel Douglas Anderson
@ 2021-07-23 0:21 ` Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 6/8] drm/panel-simple: Split the delay structure out of the panel description Douglas Anderson
` (2 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: Douglas Anderson @ 2021-07-23 0:21 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Maarten Lankhorst, Steev Klimaszewski, dri-devel, David Airlie,
devicetree, Daniel Vetter, Maxime Ripard, Sam Ravnborg,
Thomas Zimmermann, linux-arm-msm, Linus W, Bjorn Andersson,
Douglas Anderson, linux-kernel
Up until now "desc" has usually pointed to one of the "static const"
objects defined in the panel-simple driver. Just storing a pointer to
one of these data elements made sense.
In a future patch to support probable eDP panels, however, it's
convenient to be able to modify the delays that the driver uses as it
starts up. One nice way to handle this is to just copy the "desc" into
our driver data instead of storing a pointer.
This has a nice side effect of simplifying the "DPI" case since we no
longer need an extra alloc there.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/gpu/drm/panel/panel-simple.c | 84 +++++++++++++---------------
1 file changed, 38 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index bcdc84b20827..c08bc70f7798 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -199,7 +199,7 @@ struct panel_simple {
ktime_t prepared_time;
ktime_t unprepared_time;
- const struct panel_desc *desc;
+ struct panel_desc desc;
struct regulator *supply;
struct i2c_adapter *ddc;
@@ -226,8 +226,8 @@ static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel,
struct drm_display_mode *mode;
unsigned int i, num = 0;
- for (i = 0; i < panel->desc->num_timings; i++) {
- const struct display_timing *dt = &panel->desc->timings[i];
+ for (i = 0; i < panel->desc.num_timings; i++) {
+ const struct display_timing *dt = &panel->desc.timings[i];
struct videomode vm;
videomode_from_timing(dt, &vm);
@@ -242,7 +242,7 @@ static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel,
mode->type |= DRM_MODE_TYPE_DRIVER;
- if (panel->desc->num_timings == 1)
+ if (panel->desc.num_timings == 1)
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
@@ -258,8 +258,8 @@ static unsigned int panel_simple_get_display_modes(struct panel_simple *panel,
struct drm_display_mode *mode;
unsigned int i, num = 0;
- for (i = 0; i < panel->desc->num_modes; i++) {
- const struct drm_display_mode *m = &panel->desc->modes[i];
+ for (i = 0; i < panel->desc.num_modes; i++) {
+ const struct drm_display_mode *m = &panel->desc.modes[i];
mode = drm_mode_duplicate(connector->dev, m);
if (!mode) {
@@ -271,7 +271,7 @@ static unsigned int panel_simple_get_display_modes(struct panel_simple *panel,
mode->type |= DRM_MODE_TYPE_DRIVER;
- if (panel->desc->num_modes == 1)
+ if (panel->desc.num_modes == 1)
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_set_name(mode);
@@ -290,9 +290,6 @@ static int panel_simple_get_non_edid_modes(struct panel_simple *panel,
bool has_override = panel->override_mode.type;
unsigned int num = 0;
- if (!panel->desc)
- return 0;
-
if (has_override) {
mode = drm_mode_duplicate(connector->dev,
&panel->override_mode);
@@ -305,7 +302,7 @@ static int panel_simple_get_non_edid_modes(struct panel_simple *panel,
}
/* Only add timings if override was not there or failed to validate */
- if (num == 0 && panel->desc->num_timings)
+ if (num == 0 && panel->desc.num_timings)
num = panel_simple_get_timings_modes(panel, connector);
/*
@@ -314,17 +311,17 @@ static int panel_simple_get_non_edid_modes(struct panel_simple *panel,
* We should only ever have either the display timings specified
* or a fixed mode. Anything else is rather bogus.
*/
- WARN_ON(panel->desc->num_timings && panel->desc->num_modes);
+ WARN_ON(panel->desc.num_timings && panel->desc.num_modes);
if (num == 0)
num = panel_simple_get_display_modes(panel, connector);
- connector->display_info.bpc = panel->desc->bpc;
- connector->display_info.width_mm = panel->desc->size.width;
- connector->display_info.height_mm = panel->desc->size.height;
- if (panel->desc->bus_format)
+ connector->display_info.bpc = panel->desc.bpc;
+ connector->display_info.width_mm = panel->desc.size.width;
+ connector->display_info.height_mm = panel->desc.size.height;
+ if (panel->desc.bus_format)
drm_display_info_set_bus_formats(&connector->display_info,
- &panel->desc->bus_format, 1);
- connector->display_info.bus_flags = panel->desc->bus_flags;
+ &panel->desc.bus_format, 1);
+ connector->display_info.bus_flags = panel->desc.bus_flags;
return num;
}
@@ -350,8 +347,8 @@ static int panel_simple_disable(struct drm_panel *panel)
if (!p->enabled)
return 0;
- if (p->desc->delay.disable)
- msleep(p->desc->delay.disable);
+ if (p->desc.delay.disable)
+ msleep(p->desc.delay.disable);
p->enabled = false;
@@ -364,8 +361,8 @@ static int panel_simple_suspend(struct device *dev)
gpiod_set_value_cansleep(p->enable_gpio, 0);
- if (p->desc->delay.disable_to_power_off)
- msleep(p->desc->delay.disable_to_power_off);
+ if (p->desc.delay.disable_to_power_off)
+ msleep(p->desc.delay.disable_to_power_off);
regulator_disable(p->supply);
p->unprepared_time = ktime_get();
@@ -416,7 +413,7 @@ static int panel_simple_prepare_once(struct panel_simple *p)
int hpd_asserted;
unsigned long hpd_wait_us;
- panel_simple_wait(p->unprepared_time, p->desc->delay.unprepare);
+ panel_simple_wait(p->unprepared_time, p->desc.delay.unprepare);
err = regulator_enable(p->supply);
if (err < 0) {
@@ -424,20 +421,20 @@ static int panel_simple_prepare_once(struct panel_simple *p)
return err;
}
- if (p->desc->delay.power_to_enable)
- msleep(p->desc->delay.power_to_enable);
+ if (p->desc.delay.power_to_enable)
+ msleep(p->desc.delay.power_to_enable);
gpiod_set_value_cansleep(p->enable_gpio, 1);
- delay = p->desc->delay.prepare;
+ delay = p->desc.delay.prepare;
if (p->no_hpd)
- delay += p->desc->delay.hpd_absent_delay;
+ delay += p->desc.delay.hpd_absent_delay;
if (delay)
msleep(delay);
if (p->hpd_gpio) {
- if (p->desc->delay.hpd_absent_delay)
- hpd_wait_us = p->desc->delay.hpd_absent_delay * 1000UL;
+ if (p->desc.delay.hpd_absent_delay)
+ hpd_wait_us = p->desc.delay.hpd_absent_delay * 1000UL;
else
hpd_wait_us = 2000000;
@@ -520,10 +517,10 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enabled)
return 0;
- if (p->desc->delay.enable)
- msleep(p->desc->delay.enable);
+ if (p->desc.delay.enable)
+ msleep(p->desc.delay.enable);
- panel_simple_wait(p->prepared_time, p->desc->delay.prepare_to_enable);
+ panel_simple_wait(p->prepared_time, p->desc.delay.prepare_to_enable);
p->enabled = true;
@@ -566,14 +563,14 @@ static int panel_simple_get_timings(struct drm_panel *panel,
struct panel_simple *p = to_panel_simple(panel);
unsigned int i;
- if (p->desc->num_timings < num_timings)
- num_timings = p->desc->num_timings;
+ if (p->desc.num_timings < num_timings)
+ num_timings = p->desc.num_timings;
if (timings)
for (i = 0; i < num_timings; i++)
- timings[i] = p->desc->timings[i];
+ timings[i] = p->desc.timings[i];
- return p->desc->num_timings;
+ return p->desc.num_timings;
}
static const struct drm_panel_funcs panel_simple_funcs = {
@@ -592,15 +589,12 @@ static int panel_dpi_probe(struct device *dev,
{
struct display_timing *timing;
const struct device_node *np;
- struct panel_desc *desc;
+ struct panel_desc *desc = &panel->desc;
unsigned int bus_flags;
struct videomode vm;
int ret;
np = dev->of_node;
- desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
- if (!desc)
- return -ENOMEM;
timing = devm_kzalloc(dev, sizeof(*timing), GFP_KERNEL);
if (!timing)
@@ -628,8 +622,6 @@ static int panel_dpi_probe(struct device *dev,
/* We do not know the connector for the DT node, so guess it */
desc->connector_type = DRM_MODE_CONNECTOR_DPI;
- panel->desc = desc;
-
return 0;
}
@@ -640,7 +632,7 @@ static void panel_simple_parse_panel_timing_node(struct device *dev,
struct panel_simple *panel,
const struct display_timing *ot)
{
- const struct panel_desc *desc = panel->desc;
+ const struct panel_desc *desc = &panel->desc;
struct videomode vm;
unsigned int i;
@@ -653,8 +645,8 @@ static void panel_simple_parse_panel_timing_node(struct device *dev,
return;
}
- for (i = 0; i < panel->desc->num_timings; i++) {
- const struct display_timing *dt = &panel->desc->timings[i];
+ for (i = 0; i < desc->num_timings; i++) {
+ const struct display_timing *dt = &desc->timings[i];
if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
@@ -696,7 +688,7 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc,
panel->enabled = false;
panel->prepared_time = 0;
- panel->desc = desc;
+ panel->desc = *desc;
panel->aux = aux;
panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
--
2.32.0.432.gabb21c7263-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread* [RFC PATCH 6/8] drm/panel-simple: Split the delay structure out of the panel description
2021-07-23 0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
` (4 preceding siblings ...)
2021-07-23 0:21 ` [RFC PATCH 5/8] drm/panel-simple: Copy "desc" into driver data; don't store a pointer Douglas Anderson
@ 2021-07-23 0:21 ` Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 7/8] drm/panel-simple: Implement generic "edp-panel"s probed by EDID Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 8/8] arm64: dts: qcom: sc7180: trogdor devices can use probable eDP panels Douglas Anderson
7 siblings, 0 replies; 11+ messages in thread
From: Douglas Anderson @ 2021-07-23 0:21 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Maarten Lankhorst, Steev Klimaszewski, dri-devel, David Airlie,
devicetree, Daniel Vetter, Maxime Ripard, Sam Ravnborg,
Thomas Zimmermann, linux-arm-msm, Linus W, Bjorn Andersson,
Douglas Anderson, linux-kernel
In the case where we can read an EDID for a panel the only part of the
panel description that can't be found directly from the EDID is the
description of the delays. Let's break the delay structure out so that
we can specify just the delays for panels that are detected by EDID.
This is simple code motion. No functional change is intended.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/gpu/drm/panel/panel-simple.c | 191 ++++++++++++++-------------
1 file changed, 98 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index c08bc70f7798..80bc60648ecf 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -41,6 +41,103 @@
#include <drm/drm_mipi_dsi.h>
#include <drm/drm_panel.h>
+/**
+ * struct panel_delay - Describes delays for a simple panel.
+ */
+struct panel_delay {
+ /**
+ * @prepare: Time for the panel to become ready.
+ *
+ * The time (in milliseconds) that it takes for the panel to
+ * become ready and start receiving video data
+ */
+ unsigned int prepare;
+
+ /**
+ * @hpd_absent_delay: Time to wait if HPD isn't hooked up.
+ *
+ * Add this to the prepare delay if we know Hot Plug Detect
+ * isn't used.
+ */
+ unsigned int hpd_absent_delay;
+
+ /**
+ * @prepare_to_enable: Time between prepare and enable.
+ *
+ * The minimum time, in milliseconds, that needs to have passed
+ * between when prepare finished and enable may begin. If at
+ * enable time less time has passed since prepare finished,
+ * the driver waits for the remaining time.
+ *
+ * If a fixed enable delay is also specified, we'll start
+ * counting before delaying for the fixed delay.
+ *
+ * If a fixed prepare delay is also specified, we won't start
+ * counting until after the fixed delay. We can't overlap this
+ * fixed delay with the min time because the fixed delay
+ * doesn't happen at the end of the function if a HPD GPIO was
+ * specified.
+ *
+ * In other words:
+ * prepare()
+ * ...
+ * // do fixed prepare delay
+ * // wait for HPD GPIO if applicable
+ * // start counting for prepare_to_enable
+ *
+ * enable()
+ * // do fixed enable delay
+ * // enforce prepare_to_enable min time
+ */
+ unsigned int prepare_to_enable;
+
+ /**
+ * @power_to_enable: Time for the power to enable the display on.
+ *
+ * The time (in milliseconds) to wait after powering up the display
+ * before asserting its enable pin.
+ */
+ unsigned int power_to_enable;
+
+ /**
+ * @disable_to_power_off: Time for the disable to power the display off.
+ *
+ * The time (in milliseconds) to wait before powering off the display
+ * after deasserting its enable pin.
+ */
+ unsigned int disable_to_power_off;
+
+ /**
+ * @enable: Time for the panel to display a valid frame.
+ *
+ * The time (in milliseconds) that it takes for the panel to
+ * display the first valid frame after starting to receive
+ * video data.
+ */
+ unsigned int enable;
+
+ /**
+ * @disable: Time for the panel to turn the display off.
+ *
+ * The time (in milliseconds) that it takes for the panel to
+ * turn the display off (no content is visible).
+ */
+ unsigned int disable;
+
+ /**
+ * @unprepare: Time to power down completely.
+ *
+ * The time (in milliseconds) that it takes for the panel
+ * to power itself down completely.
+ *
+ * This time is used to prevent a future "prepare" from
+ * starting until at least this many milliseconds has passed.
+ * If at prepare time less time has passed since unprepare
+ * finished, the driver waits for the remaining time.
+ */
+ unsigned int unprepare;
+};
+
/**
* struct panel_desc - Describes a simple panel.
*/
@@ -85,99 +182,7 @@ struct panel_desc {
} size;
/** @delay: Structure containing various delay values for this panel. */
- struct {
- /**
- * @delay.prepare: Time for the panel to become ready.
- *
- * The time (in milliseconds) that it takes for the panel to
- * become ready and start receiving video data
- */
- unsigned int prepare;
-
- /**
- * @delay.hpd_absent_delay: Time to wait if HPD isn't hooked up.
- *
- * Add this to the prepare delay if we know Hot Plug Detect
- * isn't used.
- */
- unsigned int hpd_absent_delay;
-
- /**
- * @delay.prepare_to_enable: Time between prepare and enable.
- *
- * The minimum time, in milliseconds, that needs to have passed
- * between when prepare finished and enable may begin. If at
- * enable time less time has passed since prepare finished,
- * the driver waits for the remaining time.
- *
- * If a fixed enable delay is also specified, we'll start
- * counting before delaying for the fixed delay.
- *
- * If a fixed prepare delay is also specified, we won't start
- * counting until after the fixed delay. We can't overlap this
- * fixed delay with the min time because the fixed delay
- * doesn't happen at the end of the function if a HPD GPIO was
- * specified.
- *
- * In other words:
- * prepare()
- * ...
- * // do fixed prepare delay
- * // wait for HPD GPIO if applicable
- * // start counting for prepare_to_enable
- *
- * enable()
- * // do fixed enable delay
- * // enforce prepare_to_enable min time
- */
- unsigned int prepare_to_enable;
-
- /**
- * @delay.power_to_enable: Time for the power to enable the display on.
- *
- * The time (in milliseconds) to wait after powering up the display
- * before asserting its enable pin.
- */
- unsigned int power_to_enable;
-
- /**
- * @delay.disable_to_power_off: Time for the disable to power the display off.
- *
- * The time (in milliseconds) to wait before powering off the display
- * after deasserting its enable pin.
- */
- unsigned int disable_to_power_off;
-
- /**
- * @delay.enable: Time for the panel to display a valid frame.
- *
- * The time (in milliseconds) that it takes for the panel to
- * display the first valid frame after starting to receive
- * video data.
- */
- unsigned int enable;
-
- /**
- * @delay.disable: Time for the panel to turn the display off.
- *
- * The time (in milliseconds) that it takes for the panel to
- * turn the display off (no content is visible).
- */
- unsigned int disable;
-
- /**
- * @delay.unprepare: Time to power down completely.
- *
- * The time (in milliseconds) that it takes for the panel
- * to power itself down completely.
- *
- * This time is used to prevent a future "prepare" from
- * starting until at least this many milliseconds has passed.
- * If at prepare time less time has passed since unprepare
- * finished, the driver waits for the remaining time.
- */
- unsigned int unprepare;
- } delay;
+ struct panel_delay delay;
/** @bus_format: See MEDIA_BUS_FMT_... defines. */
u32 bus_format;
--
2.32.0.432.gabb21c7263-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread* [RFC PATCH 7/8] drm/panel-simple: Implement generic "edp-panel"s probed by EDID
2021-07-23 0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
` (5 preceding siblings ...)
2021-07-23 0:21 ` [RFC PATCH 6/8] drm/panel-simple: Split the delay structure out of the panel description Douglas Anderson
@ 2021-07-23 0:21 ` Douglas Anderson
2021-07-23 0:21 ` [RFC PATCH 8/8] arm64: dts: qcom: sc7180: trogdor devices can use probable eDP panels Douglas Anderson
7 siblings, 0 replies; 11+ messages in thread
From: Douglas Anderson @ 2021-07-23 0:21 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Maarten Lankhorst, Steev Klimaszewski, dri-devel, David Airlie,
devicetree, Daniel Vetter, Maxime Ripard, Sam Ravnborg,
Thomas Zimmermann, linux-arm-msm, Linus W, Bjorn Andersson,
Douglas Anderson, linux-kernel
As discussed in the patch ("dt-bindings: drm/panel-simple: Introduce
generic eDP panels") we can actually support probing eDP panels at
runtime instead of hardcoding what panel is connected. Add support to
the panel-simple driver for this.
We'll implement a solution like this:
* We'll read in two delays from the device tree that are used for
powering up the panel the initial time (to read the EDID).
* In the EDID we can find a 32-bit ID that identifies what panel we've
found. From this ID we can look up the full set of delays.
After this change we'll still need to add per-panel delays into the
panel-simple driver but we will no longer need to specify exactly
which panel is connected to which board. Nicely, any panels that are
only supported this way also don't need to hardcode mode data since
it's guaranteed that we can get that through the EDID.
This patch will seed the ID-to-delay table with a few panels that I
have access to, many of which are on sc7180-trogdor devices.
NOTE: as part of this patch, we'll also support a "fallback" panel. If
we have problems reading the EDID or we don't recognize the panel
connected then we can fallback to the delays from the fallback
panel. This can be handy for transitioning existing boards over to use
the new edp-panel solution since we'll still end up with a working
system even if some boards were shipped with different panels or bad
EDIDs.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/gpu/drm/panel/panel-simple.c | 218 ++++++++++++++++++++++++---
1 file changed, 200 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 80bc60648ecf..3220298f0772 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -194,6 +194,20 @@ struct panel_desc {
int connector_type;
};
+/**
+ * struct edp_panel_entry - Maps panel ID to delay / panel name.
+ */
+struct edp_panel_entry {
+ /** @panel_id: 32-bit ID for panel, encoded with encode_edid_id(). */
+ u32 panel_id;
+
+ /* @delay: The power sequencing delays needed for this panel. */
+ const struct panel_delay *delay;
+
+ /* @name: Name of this panel (for printing to logs). */
+ const char *name;
+};
+
struct panel_simple {
struct drm_panel base;
bool enabled;
@@ -552,8 +566,15 @@ static int panel_simple_get_modes(struct drm_panel *panel,
pm_runtime_put_autosuspend(panel->dev);
}
- /* add hard-coded panel modes */
- num += panel_simple_get_non_edid_modes(p, connector);
+ /*
+ * Add hard-coded panel modes. Don't call this if there are no timings
+ * and no modes (the generic edp-panel case) because it will clobber
+ * the display_info that was already set by drm_add_edid_modes().
+ */
+ if (p->desc.num_timings || p->desc.num_modes)
+ num += panel_simple_get_non_edid_modes(p, connector);
+ else if (!num)
+ dev_warn(p->base.dev, "No display modes\n");
/* set up connector's "panel orientation" property */
drm_connector_set_panel_orientation(connector, p->orientation);
@@ -677,9 +698,90 @@ static void panel_simple_parse_panel_timing_node(struct device *dev,
dev_err(dev, "Reject override mode: No display_timing found\n");
}
+static const struct edp_panel_entry *find_edp_panel(u32 panel_id);
+
+static int generic_edp_panel_probe(struct device *dev, struct panel_simple *panel)
+{
+ const struct edp_panel_entry *edp_panel;
+ u32 panel_id;
+ char vend[4];
+ u16 product_id;
+ u32 val;
+ int ret;
+
+ /*
+ * Read the dts properties for the initial probe. These are used by
+ * the runtime resume code which will get called by the
+ * pm_runtime_get_sync() call below.
+ *
+ * NOTE: the delays might be pre-populated if a fallback panel was
+ * specified or might be 0 if no fallback panel was specified.
+ *
+ * The value in the device tree can be _higher_ than the fallback
+ * panel but never lower since the device tree value should be the max
+ * of all possible panels that might be plugged into a given board.
+ */
+ ret = of_property_read_u32(dev->of_node, "hpd-reliable-delay", &val);
+ if (!ret) {
+ if (panel->desc.delay.prepare > val)
+ dev_warn(dev,
+ "Ignoring hpd-reliable-delay that's lower than fallback\n");
+ else
+ panel->desc.delay.prepare = val;
+ }
+ ret = of_property_read_u32(dev->of_node, "hpd-absent-delay", &val);
+ if (!ret) {
+ if (panel->desc.delay.hpd_absent_delay > val)
+ dev_warn(dev,
+ "Ignoring hpd-absent-delay that's lower than fallback\n");
+ else if (panel->desc.delay.prepare > val)
+ dev_warn(dev,
+ "Ignoring hpd-absent-delay that's lower than prepare delay\n");
+ else
+ /* hpd_absent_delay is added to prepare delay in prepare, so subtract now */
+ panel->desc.delay.hpd_absent_delay =
+ val - panel->desc.delay.prepare;
+ }
+
+ /* Power the panel on so we can read the EDID */
+ pm_runtime_get_sync(dev);
+
+ panel_id = drm_get_panel_id(panel->ddc);
+ if (!panel_id) {
+ dev_warn(dev, "Couldn't identify panel via EDID\n");
+ ret = -EIO;
+ goto exit;
+ }
+ decode_edid_id(panel_id, vend, &product_id);
+
+ edp_panel = find_edp_panel(panel_id);
+ if (!edp_panel) {
+ dev_warn(dev, "Unrecognized panel %s %#06x\n", vend, product_id);
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ dev_info(dev, "Detected %s %s (%#06x)\n", vend, edp_panel->name, product_id);
+
+ /* Zero out anything from the fallback */
+ memset(&panel->desc, 0, sizeof(panel->desc));
+
+ /* Fill in the two required things; everything else comes from EDID */
+ panel->desc.connector_type = DRM_MODE_CONNECTOR_eDP;
+ panel->desc.delay = *edp_panel->delay;
+
+ ret = 0;
+exit:
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
+
+ return ret;
+}
+
static int panel_simple_probe(struct device *dev, const struct panel_desc *desc,
struct drm_dp_aux *aux)
{
+ bool is_generic_edp_panel = false;
struct panel_simple *panel;
struct display_timing dt;
struct device_node *ddc;
@@ -693,7 +795,8 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc,
panel->enabled = false;
panel->prepared_time = 0;
- panel->desc = *desc;
+ if (desc)
+ panel->desc = *desc;
panel->aux = aux;
panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
@@ -743,6 +846,36 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc,
panel_simple_parse_panel_timing_node(dev, panel, &dt);
}
+ dev_set_drvdata(dev, panel);
+
+ /*
+ * We use runtime PM for prepare / unprepare since those power the panel
+ * on and off and those can be very slow operations. This is important
+ * to optimize powering the panel on briefly to read the EDID before
+ * fully enabling the panel.
+ */
+ pm_runtime_enable(dev);
+ pm_runtime_set_autosuspend_delay(dev, 1000);
+ pm_runtime_use_autosuspend(dev);
+
+ if (of_device_is_compatible(dev->of_node, "edp-panel")) {
+ err = generic_edp_panel_probe(dev, panel);
+ if (err && !desc)
+ return dev_err_probe(dev, err,
+ "Couldn't detect panel nor find a fallback\n");
+
+ is_generic_edp_panel = !err;
+
+ /*
+ * If desc was non-NULL then worst case we're using the fallback
+ * and we can ignore errors. The generic_edp_panel_probe()
+ * function would have already printed a warning.
+ */
+ err = 0;
+ }
+
+ desc = &panel->desc;
+
connector_type = desc->connector_type;
/* Catch common mistakes for panels. */
switch (connector_type) {
@@ -766,7 +899,7 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc,
desc->bpc != 8);
break;
case DRM_MODE_CONNECTOR_eDP:
- if (desc->bpc != 6 && desc->bpc != 8 && desc->bpc != 10)
+ if (!is_generic_edp_panel && desc->bpc != 6 && desc->bpc != 8 && desc->bpc != 10)
dev_warn(dev, "Expected bpc in {6,8,10} but got: %u\n", desc->bpc);
break;
case DRM_MODE_CONNECTOR_DSI:
@@ -802,18 +935,6 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc,
if (!panel->enable_gpio && desc->delay.power_to_enable)
dev_warn(dev, "Need a delay before enabling panel GPIO, but a GPIO wasn't provided\n");
- dev_set_drvdata(dev, panel);
-
- /*
- * We use runtime PM for prepare / unprepare since those power the panel
- * on and off and those can be very slow operations. This is important
- * to optimize powering the panel on briefly to read the EDID before
- * fully enabling the panel.
- */
- pm_runtime_enable(dev);
- pm_runtime_set_autosuspend_delay(dev, 1000);
- pm_runtime_use_autosuspend(dev);
-
drm_panel_init(&panel->base, dev, &panel_simple_funcs, connector_type);
err = drm_panel_of_backlight(&panel->base);
@@ -4331,6 +4452,9 @@ static const struct panel_desc arm_rtsm = {
static const struct of_device_id platform_of_match[] = {
{
+ /* Must be first */
+ .compatible = "edp-panel",
+ }, {
.compatible = "ampire,am-1280800n3tzqw-t00h",
.data = &ire_am_1280800n3tzqw_t00h,
}, {
@@ -4760,11 +4884,61 @@ static const struct of_device_id platform_of_match[] = {
};
MODULE_DEVICE_TABLE(of, platform_of_match);
+const struct panel_delay boe116whm_t01_delay = {
+ .hpd_absent_delay = 200,
+ .prepare_to_enable = 80,
+ .unprepare = 500,
+};
+
+#define EDP_PANEL_ENTRY(vend_chr_0, vend_chr_1, vend_chr_2, product_id, _delay, _name) \
+{ \
+ .name = _name, \
+ .panel_id = encode_edid_id(vend_chr_0, vend_chr_1, vend_chr_2, product_id), \
+ .delay = _delay \
+}
+
+/*
+ * This table is used to figure out power sequencing delays for panels that
+ * are detected by EDID. Entries here may point to entries in the
+ * platform_of_match table (if a panel is listed in both places).
+ *
+ * Sort first by vendor, then by product ID.
+ */
+static const struct edp_panel_entry edp_panels[] = {
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x5c40, &auo_b116xak01.delay, "B116XAK01"),
+
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x2d08, &boe_nv133fhm_n61.delay, "NV133FHM-N62"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x8607, &boe116whm_t01_delay, "NV116WHM-T01"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x8d09, &boe_nv110wtm_n61.delay, "NV110WTM-N61"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0xd107, &boe_nv133fhm_n61.delay, "NV133FHM-N61"),
+
+ EDP_PANEL_ENTRY('C', 'M', 'N', 0x4c11, &innolux_n116bca_ea1.delay, "N116BCA-EA1"),
+
+ EDP_PANEL_ENTRY('K', 'D', 'B', 0x2406, &kingdisplay_kd116n21_30nv_a010.delay, "116N21-30NV-A010"),
+
+ { /* sentinal */ }
+};
+
+static const struct edp_panel_entry *find_edp_panel(u32 panel_id)
+{
+ const struct edp_panel_entry *panel;
+
+ if (!panel_id)
+ return NULL;
+
+ for (panel = edp_panels; panel->panel_id; panel++)
+ if (panel->panel_id == panel_id)
+ return panel;
+
+ return NULL;
+}
+
static int panel_simple_platform_probe(struct platform_device *pdev)
{
const struct of_device_id *id;
- id = of_match_node(platform_of_match, pdev->dev.of_node);
+ /* Skip one since "edp-panel" is only supported on DP AUX bus */
+ id = of_match_node(platform_of_match + 1, pdev->dev.of_node);
if (!id)
return -ENODEV;
@@ -5097,7 +5271,15 @@ static int panel_simple_dp_aux_ep_probe(struct dp_aux_ep_device *aux_ep)
{
const struct of_device_id *id;
- id = of_match_node(platform_of_match, aux_ep->dev.of_node);
+ /*
+ * Try "+ 1" first to only match "edp-panel" as a last resort. This
+ * means that our descriptor will be set based on the fallback
+ * compatible string if possible.
+ */
+ id = of_match_node(platform_of_match + 1, aux_ep->dev.of_node);
+ if (!id)
+ id = of_match_node(platform_of_match, aux_ep->dev.of_node);
+
if (!id)
return -ENODEV;
--
2.32.0.432.gabb21c7263-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread* [RFC PATCH 8/8] arm64: dts: qcom: sc7180: trogdor devices can use probable eDP panels
2021-07-23 0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
` (6 preceding siblings ...)
2021-07-23 0:21 ` [RFC PATCH 7/8] drm/panel-simple: Implement generic "edp-panel"s probed by EDID Douglas Anderson
@ 2021-07-23 0:21 ` Douglas Anderson
7 siblings, 0 replies; 11+ messages in thread
From: Douglas Anderson @ 2021-07-23 0:21 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Maarten Lankhorst, Steev Klimaszewski, dri-devel, David Airlie,
devicetree, Daniel Vetter, Maxime Ripard, Sam Ravnborg,
Thomas Zimmermann, linux-arm-msm, Linus W, Bjorn Andersson,
Douglas Anderson, Andy Gross, linux-kernel
This change enables probable eDP panels for all sc7180-trogdor
variants, leaving the existing panel as a fallback.
Though this won't make any immediate change, it paves the way for
supporting more second source panels on trogdor devices. It also
removes a "little white lie" which is that some trogdor devices
already had second sources for their panels but the panels were
compatible enough that they could simply use the same delays across
the board.
NOTE that all trogdor devices currently supported by mainline have HPD
hooked up properly and so there is no need for the hpd-absent-delay on
any of these. One of the trogdor devices does have a glitchy HPD upon
first power on, though, so we need "hpd-reliable-delay" on lazor.
This also removes the "innolux,n116bge" fallback from one of the
limozeen models. The limozeen board never had this panel but the
"innolux,n116bge" panel timings / delays worked OK and having this as
a fallback compatible string helped until the "innolux,n116bca-ea1"
panel was supported.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 2 +-
.../arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots.dts | 2 +-
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen.dts | 2 +-
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi | 3 ++-
arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi | 2 +-
5 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
index 4c6e433c8226..b2ff87769a7b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
@@ -74,7 +74,7 @@ &i2c9 {
};
&panel {
- compatible = "boe,nv110wtm-n61";
+ compatible = "edp-panel", "boe,nv110wtm-n61";
};
&pp3300_dx_edp {
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots.dts b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots.dts
index 0456c7e05d00..56bff28cdd9e 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots.dts
@@ -18,7 +18,7 @@ / {
/delete-node/&ap_ts;
&panel {
- compatible = "innolux,n116bca-ea1", "innolux,n116bge";
+ compatible = "edp-panel", "innolux,n116bca-ea1";
};
&sdhc_2 {
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen.dts b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen.dts
index e6ad6dae4e60..892f6ff8f155 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen.dts
@@ -34,7 +34,7 @@ ap_ts: touchscreen@10 {
};
&panel {
- compatible = "auo,b116xa01";
+ compatible = "edp-panel", "auo,b116xa01";
};
&sdhc_2 {
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
index 6b10b96173e8..f31a8f54c855 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
@@ -42,7 +42,8 @@ ap_ts: touchscreen@10 {
};
&panel {
- compatible = "boe,nv133fhm-n62";
+ compatible = "edp-panel", "boe,nv133fhm-n62";
+ hpd-reliable-delay = <15>;
};
&trackpad {
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
index 622b5f1b88a2..bf0d2a8a195b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
@@ -108,7 +108,7 @@ ap_ts: touchscreen@10 {
};
&panel {
- compatible = "kingdisplay,kd116n21-30nv-a010";
+ compatible = "edp-panel", "kingdisplay,kd116n21-30nv-a010";
};
&pen_insert {
--
2.32.0.432.gabb21c7263-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread