From: Rob Clark <robdclark(a)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.)
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(-)
--
2.20.1
These are cherrypicks from the aarch64-laptops [1] effort. I have
pinged those maintainers pointing out that these patches have not been
submitted upstream. In the future it should be... Otherwise, I'll keep
rebasing this.
This is useful on the AArch64 laptops [2] booting in ACPI mode, as they
are Win10 laptops they use/publish WMI, hence it should stop being x86
only and be enabled on arm64 too.
[1] https://github.com/aarch64-laptops/linux/tree/laptops-ubuntu
[2] ASUS NovaGo TP370QL, HP Envy x2, Lenovo Mixx 630 & Yoga C630, and
Samsung Book2
Ard Biesheuvel (2):
UBUNTU: SAUCE: acpi: move WMI subsystem to generic code
UBUNTU: SAUCE: acpi/wmi: move BMOF driver to generic code
Dimitri John Ledkov (1):
UBUNTU: [Config] Update WMI_BMOF annotations.
.../abi/5.3.0-0.1/arm64/generic.modules | 2 ++
debian.master/config/annotations | 4 +--
drivers/acpi/Kconfig | 33 +++++++++++++++++++
drivers/acpi/Makefile | 2 ++
drivers/{platform/x86 => acpi}/wmi-bmof.c | 0
drivers/{platform/x86 => acpi}/wmi.c | 0
drivers/platform/x86/Kconfig | 33 -------------------
drivers/platform/x86/Makefile | 2 --
8 files changed, 39 insertions(+), 37 deletions(-)
rename drivers/{platform/x86 => acpi}/wmi-bmof.c (100%)
rename drivers/{platform/x86 => acpi}/wmi.c (100%)
--
2.20.1