Hi Rob,
Thank you for the patch.
On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
From: Rob Clark robdclark@chromium.org
Now that we can deal gracefully with bootloader (firmware) initialized display on aarch64 laptops[1], the next step is to deal with the fact that the same model of laptop can have one of multiple different panels. (For the yoga c630 that I have, I know of at least two possible panels, there might be a third.)
I have to ask the obvious question: why doesn't the boot loader just pass a correct DT to Linux ? There's no point in passing a list of panels that are not there, this seems quite a big hack to me. A proper boot loader should construct the DT based on hardware detection.
This is actually a scenario that comes up frequently in phones and tablets as well, so it is useful to have an upstream solution for this.
The basic idea is to add a 'panel-id' property in dt chosen node, and use that to pick the endpoint we look at when loading the panel driver, e.g.
/ { chosen { panel-id = <0xc4>; };
ivo_panel { compatible = "ivo,m133nwf4-r0"; power-supply = <&vlcm_3v3>; no-hpd;
ports { port { ivo_panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_out_ivo>; }; }; };
};
boe_panel { compatible = "boe,nv133fhm-n61"; power-supply = <&vlcm_3v3>; no-hpd;
ports { port { boe_panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_out_boe>; }; }; };
};
sn65dsi86: bridge@2c { compatible = "ti,sn65dsi86";
... ports { #address-cells = <1>; #size-cells = <0>; ... port@1 { #address-cells = <1>; #size-cells = <0>; reg = <1>; endpoint@c4 { reg = <0xc4>; remote-endpoint = <&boe_panel_in_edp>; }; endpoint@c5 { reg = <0xc5>; remote-endpoint = <&ivo_panel_in_edp>; }; }; };
} };
Note that the panel-id is potentially a sparse-int. The values I've seen so far on aarch64 laptops are:
- 0xc2
- 0xc3
- 0xc4
- 0xc5
- 0x8011
- 0x8012
- 0x8055
- 0x8056
At least on snapdragon aarch64 laptops, they can be any u32 value.
However, on these laptops, the bootloader/firmware is not populating the chosen node, but instead providing an "UEFIDisplayInfo" variable, which contains the panel id. Unfortunately EFI variables are only available before ExitBootServices, so the second patch checks for this variable before EBS and populates the /chosen/panel-id variable.
[1] https://patchwork.freedesktop.org/series/63001/
Rob Clark (4): dt-bindings: chosen: document panel-id binding efi/libstub: detect panel-id drm: add helper to lookup panel-id drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
Documentation/devicetree/bindings/chosen.txt | 69 ++++++++++++++++++++ drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++ drivers/firmware/efi/libstub/efistub.h | 2 + drivers/firmware/efi/libstub/fdt.c | 9 +++ drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +- drivers/gpu/drm/drm_of.c | 21 ++++++ include/drm/drm_of.h | 7 ++ 7 files changed, 160 insertions(+), 2 deletions(-)