* [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels @ 2019-06-30 20:36 Rob Clark 2019-06-30 20:36 ` [PATCH 2/4] efi/libstub: detect panel-id Rob Clark ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Rob Clark @ 2019-06-30 20:36 UTC (permalink / raw) To: dri-devel, linux-arm-msm Cc: freedreno, aarch64-laptops, Rob Clark, Ard Biesheuvel, Catalin Marinas, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Ingo Molnar, Julien Thierry, Laurent Pinchart, open list:EXTENSIBLE FIRMWARE INTERFACE (EFI), open list, Lukas Wunner, Steve Capper, Will Deacon 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.) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 2/4] efi/libstub: detect panel-id 2019-06-30 20:36 [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Rob Clark @ 2019-06-30 20:36 ` Rob Clark 2019-07-02 20:26 ` Ard Biesheuvel 2019-06-30 20:47 ` [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Laurent Pinchart 2019-07-02 12:50 ` Rob Clark 2 siblings, 1 reply; 17+ messages in thread From: Rob Clark @ 2019-06-30 20:36 UTC (permalink / raw) To: dri-devel, linux-arm-msm Cc: freedreno, aarch64-laptops, Rob Clark, Ard Biesheuvel, Ingo Molnar, Will Deacon, Leif Lindholm, Alexander Graf, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, linux-kernel From: Rob Clark <robdclark@chromium.org> On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided to communicate some information about the display. Crutially it has the panel-id, so the appropriate panel driver can be selected. Read this out and stash in /chosen/panel-id so that display driver can use it to pick the appropriate panel. Signed-off-by: Rob Clark <robdclark@chromium.org> --- drivers/firmware/efi/libstub/arm-stub.c | 49 +++++++++++++++++++++++++ drivers/firmware/efi/libstub/efistub.h | 2 + drivers/firmware/efi/libstub/fdt.c | 9 +++++ 3 files changed, 60 insertions(+) diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c index 04e6ecd72cd9..999813252e0d 100644 --- a/drivers/firmware/efi/libstub/arm-stub.c +++ b/drivers/firmware/efi/libstub/arm-stub.c @@ -69,6 +69,53 @@ static struct screen_info *setup_graphics(efi_system_table_t *sys_table_arg) return si; } +/* + * We (at least currently) don't care about most of the fields, just + * panel_id: + */ +struct mdp_disp_info { + u32 version_info; + u32 pad0[9]; + u32 panel_id; + u32 pad1[17]; +}; + +#define MDP_DISP_INFO_VERSION_MAGIC 0xaa + +static void get_panel_id(efi_system_table_t *sys_table_arg, + unsigned long fdt_addr) +{ + efi_guid_t gop_proto = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID; + efi_status_t status; + struct mdp_disp_info *disp_info; + unsigned long size = 0; + + status = efi_call_runtime(get_variable, L"UEFIDisplayInfo", + &gop_proto, NULL, &size, NULL); + if (status == EFI_NOT_FOUND) + return; + + status = efi_call_early(allocate_pool, EFI_LOADER_DATA, size, + (void **)&disp_info); + if (status != EFI_SUCCESS) + return; + + status = efi_call_runtime(get_variable, L"UEFIDisplayInfo", + &gop_proto, NULL, &size, disp_info); + if (status != EFI_SUCCESS) + goto cleanup; + + if ((disp_info->version_info >> 16) != MDP_DISP_INFO_VERSION_MAGIC) + goto cleanup; + + efi_printk(sys_table_arg, "found a panel-id!\n"); + + set_chosen_panel_id(fdt_addr, disp_info->panel_id); + +cleanup: + efi_call_early(free_pool, disp_info); +} + void install_memreserve_table(efi_system_table_t *sys_table_arg) { struct linux_efi_memreserve *rsv; @@ -229,6 +276,8 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table, if (!fdt_addr) pr_efi(sys_table, "Generating empty DTB\n"); + get_panel_id(sys_table, fdt_addr); + status = handle_cmdline_files(sys_table, image, cmdline_ptr, "initrd=", efi_get_max_initrd_addr(dram_base, *image_addr), diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h index 1b1dfcaa6fb9..8832cb9a7a40 100644 --- a/drivers/firmware/efi/libstub/efistub.h +++ b/drivers/firmware/efi/libstub/efistub.h @@ -39,6 +39,8 @@ void efi_char16_printk(efi_system_table_t *, efi_char16_t *); unsigned long get_dram_base(efi_system_table_t *sys_table_arg); +void set_chosen_panel_id(unsigned long fdt_addr, unsigned panel_id); + efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table, void *handle, unsigned long *new_fdt_addr, diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index 5440ba17a1c5..cb6ea160a40a 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -200,6 +200,15 @@ static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map) return EFI_SUCCESS; } +void set_chosen_panel_id(unsigned long fdt_addr, unsigned panel_id) +{ + void *fdt = (void *)fdt_addr; + int node = fdt_subnode_offset(fdt, 0, "chosen"); + u32 fdt_val32 = cpu_to_fdt32(panel_id); + + fdt_setprop_var(fdt, node, "panel-id", fdt_val32); +} + #ifndef EFI_FDT_ALIGN # define EFI_FDT_ALIGN EFI_PAGE_SIZE #endif -- 2.20.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-06-30 20:36 ` [PATCH 2/4] efi/libstub: detect panel-id Rob Clark @ 2019-07-02 20:26 ` Ard Biesheuvel 2019-07-02 20:35 ` Ard Biesheuvel 0 siblings, 1 reply; 17+ messages in thread From: Ard Biesheuvel @ 2019-07-02 20:26 UTC (permalink / raw) To: Rob Clark Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Leif Lindholm, Alexander Graf, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Sun, 30 Jun 2019 at 22:36, Rob Clark <robdclark@gmail.com> wrote: > > From: Rob Clark <robdclark@chromium.org> > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided > to communicate some information about the display. Crutially it has the > panel-id, so the appropriate panel driver can be selected. Read this > out and stash in /chosen/panel-id so that display driver can use it to > pick the appropriate panel. > > Signed-off-by: Rob Clark <robdclark@chromium.org> Hi Rob, I understand why you are doing this, but this *really* belongs elsewhere. So we are dealing with a platform that violates the UEFI spec, since it does not bother to implement variable services at runtime (because MS let the vendor get away with this). First of all, to pass data between the EFI stub and the OS proper, we should use a configuration table rather than a DT property, since the former is ACPI/DT agnostic. Also, I'd like the consumer of the data to actually interpret it, i.e., just dump the whole opaque thing into a config table in the stub, and do the parsing in the OS proper. However, I am not thrilled at adding code to the stub that unconditionally looks for some variable with some magic name on all ARM/arm64 EFI systems, so this will need to live under a Kconfig option that depends on ARM64 (and does not default to y) > --- > drivers/firmware/efi/libstub/arm-stub.c | 49 +++++++++++++++++++++++++ > drivers/firmware/efi/libstub/efistub.h | 2 + > drivers/firmware/efi/libstub/fdt.c | 9 +++++ > 3 files changed, 60 insertions(+) > > diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c > index 04e6ecd72cd9..999813252e0d 100644 > --- a/drivers/firmware/efi/libstub/arm-stub.c > +++ b/drivers/firmware/efi/libstub/arm-stub.c > @@ -69,6 +69,53 @@ static struct screen_info *setup_graphics(efi_system_table_t *sys_table_arg) > return si; > } > > +/* > + * We (at least currently) don't care about most of the fields, just > + * panel_id: > + */ > +struct mdp_disp_info { > + u32 version_info; > + u32 pad0[9]; > + u32 panel_id; > + u32 pad1[17]; > +}; > + > +#define MDP_DISP_INFO_VERSION_MAGIC 0xaa > + > +static void get_panel_id(efi_system_table_t *sys_table_arg, > + unsigned long fdt_addr) > +{ > + efi_guid_t gop_proto = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID; > + efi_status_t status; > + struct mdp_disp_info *disp_info; > + unsigned long size = 0; > + > + status = efi_call_runtime(get_variable, L"UEFIDisplayInfo", > + &gop_proto, NULL, &size, NULL); > + if (status == EFI_NOT_FOUND) > + return; > + > + status = efi_call_early(allocate_pool, EFI_LOADER_DATA, size, > + (void **)&disp_info); > + if (status != EFI_SUCCESS) > + return; > + > + status = efi_call_runtime(get_variable, L"UEFIDisplayInfo", > + &gop_proto, NULL, &size, disp_info); > + if (status != EFI_SUCCESS) > + goto cleanup; > + > + if ((disp_info->version_info >> 16) != MDP_DISP_INFO_VERSION_MAGIC) > + goto cleanup; > + > + efi_printk(sys_table_arg, "found a panel-id!\n"); > + > + set_chosen_panel_id(fdt_addr, disp_info->panel_id); > + > +cleanup: > + efi_call_early(free_pool, disp_info); > +} > + > void install_memreserve_table(efi_system_table_t *sys_table_arg) > { > struct linux_efi_memreserve *rsv; > @@ -229,6 +276,8 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table, > if (!fdt_addr) > pr_efi(sys_table, "Generating empty DTB\n"); > > + get_panel_id(sys_table, fdt_addr); > + > status = handle_cmdline_files(sys_table, image, cmdline_ptr, "initrd=", > efi_get_max_initrd_addr(dram_base, > *image_addr), > diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h > index 1b1dfcaa6fb9..8832cb9a7a40 100644 > --- a/drivers/firmware/efi/libstub/efistub.h > +++ b/drivers/firmware/efi/libstub/efistub.h > @@ -39,6 +39,8 @@ void efi_char16_printk(efi_system_table_t *, efi_char16_t *); > > unsigned long get_dram_base(efi_system_table_t *sys_table_arg); > > +void set_chosen_panel_id(unsigned long fdt_addr, unsigned panel_id); > + > efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table, > void *handle, > unsigned long *new_fdt_addr, > diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c > index 5440ba17a1c5..cb6ea160a40a 100644 > --- a/drivers/firmware/efi/libstub/fdt.c > +++ b/drivers/firmware/efi/libstub/fdt.c > @@ -200,6 +200,15 @@ static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map) > return EFI_SUCCESS; > } > > +void set_chosen_panel_id(unsigned long fdt_addr, unsigned panel_id) > +{ > + void *fdt = (void *)fdt_addr; > + int node = fdt_subnode_offset(fdt, 0, "chosen"); > + u32 fdt_val32 = cpu_to_fdt32(panel_id); > + > + fdt_setprop_var(fdt, node, "panel-id", fdt_val32); > +} > + > #ifndef EFI_FDT_ALIGN > # define EFI_FDT_ALIGN EFI_PAGE_SIZE > #endif > -- > 2.20.1 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-02 20:26 ` Ard Biesheuvel @ 2019-07-02 20:35 ` Ard Biesheuvel 2019-07-02 21:01 ` Rob Clark 0 siblings, 1 reply; 17+ messages in thread From: Ard Biesheuvel @ 2019-07-02 20:35 UTC (permalink / raw) To: Rob Clark Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Leif Lindholm, Alexander Graf, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > On Sun, 30 Jun 2019 at 22:36, Rob Clark <robdclark@gmail.com> wrote: > > > > From: Rob Clark <robdclark@chromium.org> > > > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided > > to communicate some information about the display. Crutially it has the > > panel-id, so the appropriate panel driver can be selected. Read this > > out and stash in /chosen/panel-id so that display driver can use it to > > pick the appropriate panel. > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > Hi Rob, > > I understand why you are doing this, but this *really* belongs elsewhere. > > So we are dealing with a platform that violates the UEFI spec, since > it does not bother to implement variable services at runtime (because > MS let the vendor get away with this). > To clarify, the above remark applies to populating the DT from the OS rather than from the firmware. > First of all, to pass data between the EFI stub and the OS proper, we > should use a configuration table rather than a DT property, since the > former is ACPI/DT agnostic. Also, I'd like the consumer of the data to > actually interpret it, i.e., just dump the whole opaque thing into a > config table in the stub, and do the parsing in the OS proper. > > However, I am not thrilled at adding code to the stub that > unconditionally looks for some variable with some magic name on all > ARM/arm64 EFI systems, so this will need to live under a Kconfig > option that depends on ARM64 (and does not default to y) > ... but saving variables at boot time for consumption at runtime is something that we will likely see more of in the future. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-02 20:35 ` Ard Biesheuvel @ 2019-07-02 21:01 ` Rob Clark 2019-07-02 21:53 ` Ard Biesheuvel 2019-07-02 21:59 ` Leif Lindholm 0 siblings, 2 replies; 17+ messages in thread From: Rob Clark @ 2019-07-02 21:01 UTC (permalink / raw) To: Ard Biesheuvel Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Leif Lindholm, Alexander Graf, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > > > On Sun, 30 Jun 2019 at 22:36, Rob Clark <robdclark@gmail.com> wrote: > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided > > > to communicate some information about the display. Crutially it has the > > > panel-id, so the appropriate panel driver can be selected. Read this > > > out and stash in /chosen/panel-id so that display driver can use it to > > > pick the appropriate panel. > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > Hi Rob, > > > > I understand why you are doing this, but this *really* belongs elsewhere. > > > > So we are dealing with a platform that violates the UEFI spec, since > > it does not bother to implement variable services at runtime (because > > MS let the vendor get away with this). > > > > To clarify, the above remark applies to populating the DT from the OS > rather than from the firmware. yeah, it isn't pretty, but there *are* some other similar cases where efi-stub is populating DT.. (like update_fdt_memmap() and kaslr-seed).. it would be kinda nice to have an early-quirks mechanism where this could fit, but I thought that might be equally unpopular ;-) > > > First of all, to pass data between the EFI stub and the OS proper, we > > should use a configuration table rather than a DT property, since the > > former is ACPI/DT agnostic. Also, I'd like the consumer of the data to > > actually interpret it, i.e., just dump the whole opaque thing into a > > config table in the stub, and do the parsing in the OS proper. > > > > However, I am not thrilled at adding code to the stub that > > unconditionally looks for some variable with some magic name on all > > ARM/arm64 EFI systems, so this will need to live under a Kconfig > > option that depends on ARM64 (and does not default to y) I defn can add this under kconfig.. is it ok if that option is select'd by ARCH_QCOM? (Just trying to minimize the things that can go wrong and the "I get a blank screen at boot" bug reports I get ;-)) > ... but saving variables at boot time for consumption at runtime is > something that we will likely see more of in the future. I think this will be nice, but it also doesn't address the need for a quirk to get this into /chosen.. I guess we *could* use a shim or something that runs before the kernel to do this. But that just seems like a logistical/support nightmare. There is one kernel, and there are N distro's, so debugging a users "I don't get a screen at boot" problem because their distro missed some shim patch really just doesn't seem like a headache I want to have. BR, -R ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-02 21:01 ` Rob Clark @ 2019-07-02 21:53 ` Ard Biesheuvel 2019-07-02 22:36 ` Rob Clark 2019-07-02 21:59 ` Leif Lindholm 1 sibling, 1 reply; 17+ messages in thread From: Ard Biesheuvel @ 2019-07-02 21:53 UTC (permalink / raw) To: Rob Clark Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Leif Lindholm, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Tue, 2 Jul 2019 at 23:02, Rob Clark <robdclark@gmail.com> wrote: > > On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > > > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > > > > > On Sun, 30 Jun 2019 at 22:36, Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided > > > > to communicate some information about the display. Crutially it has the > > > > panel-id, so the appropriate panel driver can be selected. Read this > > > > out and stash in /chosen/panel-id so that display driver can use it to > > > > pick the appropriate panel. > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > Hi Rob, > > > > > > I understand why you are doing this, but this *really* belongs elsewhere. > > > > > > So we are dealing with a platform that violates the UEFI spec, since > > > it does not bother to implement variable services at runtime (because > > > MS let the vendor get away with this). > > > > > > > To clarify, the above remark applies to populating the DT from the OS > > rather than from the firmware. > > yeah, it isn't pretty, but there *are* some other similar cases where > efi-stub is populating DT.. (like update_fdt_memmap() and > kaslr-seed).. > True, but those don't describe the hardware. > it would be kinda nice to have an early-quirks mechanism where this > could fit, but I thought that might be equally unpopular ;-) > Very :-) > > > > > First of all, to pass data between the EFI stub and the OS proper, we > > > should use a configuration table rather than a DT property, since the > > > former is ACPI/DT agnostic. Also, I'd like the consumer of the data to > > > actually interpret it, i.e., just dump the whole opaque thing into a > > > config table in the stub, and do the parsing in the OS proper. > > > > > > However, I am not thrilled at adding code to the stub that > > > unconditionally looks for some variable with some magic name on all > > > ARM/arm64 EFI systems, so this will need to live under a Kconfig > > > option that depends on ARM64 (and does not default to y) > > I defn can add this under kconfig.. is it ok if that option is > select'd by ARCH_QCOM? > I guess some mobile SOC/snapdragon symbol would be more appropriate, but given that qcom left the server business, I guess it hardly matters, so default y if ARM64 && ARCH_QCOM is fine with me > (Just trying to minimize the things that can go wrong and the "I get a > blank screen at boot" bug reports I get ;-)) > Sure > > ... but saving variables at boot time for consumption at runtime is > > something that we will likely see more of in the future. > > I think this will be nice, but it also doesn't address the need for a > quirk to get this into /chosen.. I guess we *could* use a shim or > something that runs before the kernel to do this. But that just seems > like a logistical/support nightmare. There is one kernel, and there > are N distro's, so debugging a users "I don't get a screen at boot" > problem because their distro missed some shim patch really just > doesn't seem like a headache I want to have. > I'd argue that this does not belong in /chosen in the first place, i.e., it doesn't belong in the DT at all if the OS can access the config table (and therefore the variable) directly. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-02 21:53 ` Ard Biesheuvel @ 2019-07-02 22:36 ` Rob Clark 0 siblings, 0 replies; 17+ messages in thread From: Rob Clark @ 2019-07-02 22:36 UTC (permalink / raw) To: Ard Biesheuvel Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Leif Lindholm, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Tue, Jul 2, 2019 at 2:53 PM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > On Tue, 2 Jul 2019 at 23:02, Rob Clark <robdclark@gmail.com> wrote: > > > > On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > > > > > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > > > > > > > On Sun, 30 Jun 2019 at 22:36, Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided > > > > > to communicate some information about the display. Crutially it has the > > > > > panel-id, so the appropriate panel driver can be selected. Read this > > > > > out and stash in /chosen/panel-id so that display driver can use it to > > > > > pick the appropriate panel. > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > > > Hi Rob, > > > > > > > > I understand why you are doing this, but this *really* belongs elsewhere. > > > > > > > > So we are dealing with a platform that violates the UEFI spec, since > > > > it does not bother to implement variable services at runtime (because > > > > MS let the vendor get away with this). > > > > > > > > > > To clarify, the above remark applies to populating the DT from the OS > > > rather than from the firmware. > > > > yeah, it isn't pretty, but there *are* some other similar cases where > > efi-stub is populating DT.. (like update_fdt_memmap() and > > kaslr-seed).. > > > > True, but those don't describe the hardware. > > > it would be kinda nice to have an early-quirks mechanism where this > > could fit, but I thought that might be equally unpopular ;-) > > > > Very :-) > > > > > > > > First of all, to pass data between the EFI stub and the OS proper, we > > > > should use a configuration table rather than a DT property, since the > > > > former is ACPI/DT agnostic. Also, I'd like the consumer of the data to > > > > actually interpret it, i.e., just dump the whole opaque thing into a > > > > config table in the stub, and do the parsing in the OS proper. > > > > > > > > However, I am not thrilled at adding code to the stub that > > > > unconditionally looks for some variable with some magic name on all > > > > ARM/arm64 EFI systems, so this will need to live under a Kconfig > > > > option that depends on ARM64 (and does not default to y) > > > > I defn can add this under kconfig.. is it ok if that option is > > select'd by ARCH_QCOM? > > > > I guess some mobile SOC/snapdragon symbol would be more appropriate, > but given that qcom left the server business, I guess it hardly > matters, so default y if ARM64 && ARCH_QCOM is fine with me > > > (Just trying to minimize the things that can go wrong and the "I get a > > blank screen at boot" bug reports I get ;-)) > > > > Sure > > > > ... but saving variables at boot time for consumption at runtime is > > > something that we will likely see more of in the future. > > > > I think this will be nice, but it also doesn't address the need for a > > quirk to get this into /chosen.. I guess we *could* use a shim or > > something that runs before the kernel to do this. But that just seems > > like a logistical/support nightmare. There is one kernel, and there > > are N distro's, so debugging a users "I don't get a screen at boot" > > problem because their distro missed some shim patch really just > > doesn't seem like a headache I want to have. > > > > I'd argue that this does not belong in /chosen in the first place, > i.e., it doesn't belong in the DT at all if the OS can access the > config table (and therefore the variable) directly. admittedly I'm trying to solve two different problems here.. we also have the problem of knowing which panel is installed for the "pure DT" case.. where /chosen is (IMO) the right thing (alternatives involve a shim that knows far too much about the device).. I guess for ACPI boot case, we do anyways want some sort of configuration table. I suppose the drm code could look for both /chosen/panel-id and configuration table and use either. Although it would be nice if somehow the config table info ended up in /chosen when we are not using ACPI, since then at least code paths are more similar to how we want future android devices to solve this without a pile of downstream hacks.. BR, -R ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-02 21:01 ` Rob Clark 2019-07-02 21:53 ` Ard Biesheuvel @ 2019-07-02 21:59 ` Leif Lindholm 2019-07-02 22:48 ` Rob Clark 1 sibling, 1 reply; 17+ messages in thread From: Leif Lindholm @ 2019-07-02 21:59 UTC (permalink / raw) To: Rob Clark Cc: Ard Biesheuvel, dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Alexander Graf, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Tue, Jul 02, 2019 at 02:01:49PM -0700, Rob Clark wrote: > > > So we are dealing with a platform that violates the UEFI spec, since > > > it does not bother to implement variable services at runtime (because > > > MS let the vendor get away with this). > > > > To clarify, the above remark applies to populating the DT from the OS > > rather than from the firmware. > > yeah, it isn't pretty, but there *are* some other similar cases where > efi-stub is populating DT.. (like update_fdt_memmap() and > kaslr-seed).. The problem isn't with the stub updating the DT, the problem is what it updates it with. update_fdt_memmap() is the stub filling in the information it communicates to the main kernel. kaslr-seed sets a standard property using a standard interface if that interface is available to it at the point of execution. Since what we're doing here is dressing up an ACPI platform to make it look like it was a DT platform, and since we have the ability to tweak the DT before ever passing it to the kernel, let's just do that. Yes, I know I said I'd rather not, but it's way nicer than sticking platform-specific hacks into the EFI stub. (If adding it as a DT property is indeed the thing to do.) > > ... but saving variables at boot time for consumption at runtime is > > something that we will likely see more of in the future. > > I think this will be nice, but it also doesn't address the need for a > quirk to get this into /chosen.. I guess we *could* use a shim or > something that runs before the kernel to do this. But that just seems > like a logistical/support nightmare. > > There is one kernel, and there > are N distro's, so debugging a users "I don't get a screen at boot" > problem because their distro missed some shim patch really just > doesn't seem like a headache I want to have. The distros should not need to be aware *at all* of the hacks required to disguise these platforms as DT platforms. If they do, they're already device-specific installers and have already accepted the logistical/support nightmare. / Leif ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-02 21:59 ` Leif Lindholm @ 2019-07-02 22:48 ` Rob Clark 2019-07-03 16:33 ` Leif Lindholm 0 siblings, 1 reply; 17+ messages in thread From: Rob Clark @ 2019-07-02 22:48 UTC (permalink / raw) To: Leif Lindholm Cc: Ard Biesheuvel, dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Alexander Graf, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Tue, Jul 2, 2019 at 2:59 PM Leif Lindholm <leif.lindholm@linaro.org> wrote: > > On Tue, Jul 02, 2019 at 02:01:49PM -0700, Rob Clark wrote: > > > > So we are dealing with a platform that violates the UEFI spec, since > > > > it does not bother to implement variable services at runtime (because > > > > MS let the vendor get away with this). > > > > > > To clarify, the above remark applies to populating the DT from the OS > > > rather than from the firmware. > > > > yeah, it isn't pretty, but there *are* some other similar cases where > > efi-stub is populating DT.. (like update_fdt_memmap() and > > kaslr-seed).. > > The problem isn't with the stub updating the DT, the problem is what > it updates it with. > > update_fdt_memmap() is the stub filling in the information it > communicates to the main kernel. > > kaslr-seed sets a standard property using a standard interface if that > interface is available to it at the point of execution. > > Since what we're doing here is dressing up an ACPI platform to make it > look like it was a DT platform, and since we have the ability to tweak > the DT before ever passing it to the kernel, let's just do that. > > Yes, I know I said I'd rather not, but it's way nicer than sticking > platform-specific hacks into the EFI stub. > > (If adding it as a DT property is indeed the thing to do.) > > > > ... but saving variables at boot time for consumption at runtime is > > > something that we will likely see more of in the future. > > > > I think this will be nice, but it also doesn't address the need for a > > quirk to get this into /chosen.. I guess we *could* use a shim or > > something that runs before the kernel to do this. But that just seems > > like a logistical/support nightmare. > > > > There is one kernel, and there > > are N distro's, so debugging a users "I don't get a screen at boot" > > problem because their distro missed some shim patch really just > > doesn't seem like a headache I want to have. > > The distros should not need to be aware *at all* of the hacks required > to disguise these platforms as DT platforms. > > If they do, they're already device-specific installers and have > already accepted the logistical/support nightmare. > I guess I'm not *against* a DT loader shim populating the panel-id over into /chosen.. I had it in mind as a backup plan. Ofc still need to get dt folks to buy into /chosen/panel-id but for DT boot I think that is the best option. (At least the /chosen/panel-id approach doesn't require the shim to be aware of how the panel is wired up to dsi controller and whether their is a bridge in between, and that short of thing, so the panel-id approach seems more maintainable that other options.) I am a bit fearful of problems arising from different distros and users using different versions of shim, and how to manage that. I guess if somehow "shim thing" was part of the kernel, there would by one less moving part... I'd know if user had kernel vX.Y.Z they'd be good to go vs not. But *also* depending on a new-enough version of a shim, where the version # is probably not easily apparent to the end user, sounds a bit scary from the "all the things that can go wrong" point of view. Maybe I'm paranoid, but I'm a bit worried about how to manage that. BR, -R ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-02 22:48 ` Rob Clark @ 2019-07-03 16:33 ` Leif Lindholm 2019-07-03 17:41 ` Rob Clark 0 siblings, 1 reply; 17+ messages in thread From: Leif Lindholm @ 2019-07-03 16:33 UTC (permalink / raw) To: Rob Clark Cc: Ard Biesheuvel, dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote: > > > There is one kernel, and there > > > are N distro's, so debugging a users "I don't get a screen at boot" > > > problem because their distro missed some shim patch really just > > > doesn't seem like a headache I want to have. > > > > The distros should not need to be aware *at all* of the hacks required > > to disguise these platforms as DT platforms. > > > > If they do, they're already device-specific installers and have > > already accepted the logistical/support nightmare. > > I guess I'm not *against* a DT loader shim populating the panel-id > over into /chosen.. I had it in mind as a backup plan. Ofc still need > to get dt folks to buy into /chosen/panel-id but for DT boot I think > that is the best option. (At least the /chosen/panel-id approach > doesn't require the shim to be aware of how the panel is wired up to > dsi controller and whether their is a bridge in between, and that > short of thing, so the panel-id approach seems more maintainable that > other options.) I am leaning like Ard towards preferring a configuration table though. That removes the question of no runtime services (needing to manually cache things, at least until EBBR 1.2 (?) is out and in use), and means we don't have to use different paths for DT and ACPI. Now we have UEFI in U-Boot, do we really need to worry about the non-UEFI case? > I am a bit fearful of problems arising from different distros and > users using different versions of shim, and how to manage that. I > guess if somehow "shim thing" was part of the kernel, there would by > one less moving part... Sure, but that's insurance against bindings changing non-backwards-compatibly - which there are ways to prevent, and which streamlining the design for really isn't the way to discourage... Distros have no need to worry about the DT loader - the whole point of it is to remove the need for the distro to worry about anything other than getting the required drivers in. > I'd know if user had kernel vX.Y.Z they'd be > good to go vs not. But *also* depending on a new-enough version of a > shim, where the version # is probably not easily apparent to the end > user, sounds a bit scary from the "all the things that can go wrong" > point of view. Maybe I'm paranoid, but I'm a bit worried about how to > manage that. Until the hardware abstractions provided by the system firmware (ACPI) is supported, these platforms are not going to be appropriate for end users anyway. No matter how many not-quite-upstream hacks distros include, they won't be able to support the next minor spin that comes off the production line and is no longer compatible with existing DTs. / Leif ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-03 16:33 ` Leif Lindholm @ 2019-07-03 17:41 ` Rob Clark 2019-07-03 17:54 ` Ard Biesheuvel 0 siblings, 1 reply; 17+ messages in thread From: Rob Clark @ 2019-07-03 17:41 UTC (permalink / raw) To: Leif Lindholm Cc: Ard Biesheuvel, dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Wed, Jul 3, 2019 at 9:33 AM Leif Lindholm <leif.lindholm@linaro.org> wrote: > > On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote: > > > > There is one kernel, and there > > > > are N distro's, so debugging a users "I don't get a screen at boot" > > > > problem because their distro missed some shim patch really just > > > > doesn't seem like a headache I want to have. > > > > > > The distros should not need to be aware *at all* of the hacks required > > > to disguise these platforms as DT platforms. > > > > > > If they do, they're already device-specific installers and have > > > already accepted the logistical/support nightmare. > > > > I guess I'm not *against* a DT loader shim populating the panel-id > > over into /chosen.. I had it in mind as a backup plan. Ofc still need > > to get dt folks to buy into /chosen/panel-id but for DT boot I think > > that is the best option. (At least the /chosen/panel-id approach > > doesn't require the shim to be aware of how the panel is wired up to > > dsi controller and whether their is a bridge in between, and that > > short of thing, so the panel-id approach seems more maintainable that > > other options.) > > I am leaning like Ard towards preferring a configuration table though. Ok, if you want the DT loader to propagate UEFIDisplayInfo to a config table, I can update the drm parts of my patchset to look for that in addition to /chosen/panel-id > That removes the question of no runtime services (needing to manually > cache things, at least until EBBR 1.2 (?) is out and in use), and > means we don't have to use different paths for DT and ACPI. Now we > have UEFI in U-Boot, do we really need to worry about the non-UEFI > case? I've mixed feelings about requiring UEFI.. I definitely want to give qcom an incentive to turn on GOP and full UEFI boot for future android devices. OTOH there are quite a few devices out there that aren't UEFI boot. But I guess if drm falls back to /chosen/panel-id we are covered. > > I am a bit fearful of problems arising from different distros and > > users using different versions of shim, and how to manage that. I > > guess if somehow "shim thing" was part of the kernel, there would by > > one less moving part... > > Sure, but that's insurance against bindings changing > non-backwards-compatibly - which there are ways to prevent, and which > streamlining the design for really isn't the way to discourage... > > Distros have no need to worry about the DT loader - the whole point of > it is to remove the need for the distro to worry about anything other > than getting the required drivers in. I'm a bit more concerned about DT loader getting into the business of DT fixup.. I guess if we don't do that, it is less of a concern. But if we relied on it to fixup DT for installed panel, we could probably make it work semi-generically on existing devices that have bridge and panel wired up same way. But seems like some of the 835 laptops have bridge hooked up as child of dsi bus instead. And someday we could see devices using dsi directly, etc. (It would be really nice to see DT loader able to pick the correct .dtb based on smbios tables tho ;-).. but maybe different topic) > > I'd know if user had kernel vX.Y.Z they'd be > > good to go vs not. But *also* depending on a new-enough version of a > > shim, where the version # is probably not easily apparent to the end > > user, sounds a bit scary from the "all the things that can go wrong" > > point of view. Maybe I'm paranoid, but I'm a bit worried about how to > > manage that. > > Until the hardware abstractions provided by the system firmware (ACPI) > is supported, these platforms are not going to be appropriate for > end users anyway. No matter how many not-quite-upstream hacks distros > include, they won't be able to support the next minor spin that comes > off the production line and is no longer compatible with existing DTs. yeah, that will be a problem.. and also switching to older kernel after upgrading when in-flight dt bindings evolve. Having one less moving part would be nice. Maybe if adding a config table for UEFIDisplayInfo, you could also add one for DT loader version, so (at least if user is able to get far enough to get dmesg) we could see that more easily? BR, -R ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/4] efi/libstub: detect panel-id 2019-07-03 17:41 ` Rob Clark @ 2019-07-03 17:54 ` Ard Biesheuvel 0 siblings, 0 replies; 17+ messages in thread From: Ard Biesheuvel @ 2019-07-03 17:54 UTC (permalink / raw) To: Rob Clark Cc: Leif Lindholm, dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ingo Molnar, Will Deacon, Steve Capper, Lukas Wunner, Julien Thierry, linux-efi, Linux Kernel Mailing List On Wed, 3 Jul 2019 at 19:41, Rob Clark <robdclark@gmail.com> wrote: > > On Wed, Jul 3, 2019 at 9:33 AM Leif Lindholm <leif.lindholm@linaro.org> wrote: > > > > On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote: > > > > > There is one kernel, and there > > > > > are N distro's, so debugging a users "I don't get a screen at boot" > > > > > problem because their distro missed some shim patch really just > > > > > doesn't seem like a headache I want to have. > > > > > > > > The distros should not need to be aware *at all* of the hacks required > > > > to disguise these platforms as DT platforms. > > > > > > > > If they do, they're already device-specific installers and have > > > > already accepted the logistical/support nightmare. > > > > > > I guess I'm not *against* a DT loader shim populating the panel-id > > > over into /chosen.. I had it in mind as a backup plan. Ofc still need > > > to get dt folks to buy into /chosen/panel-id but for DT boot I think > > > that is the best option. (At least the /chosen/panel-id approach > > > doesn't require the shim to be aware of how the panel is wired up to > > > dsi controller and whether their is a bridge in between, and that > > > short of thing, so the panel-id approach seems more maintainable that > > > other options.) > > > > I am leaning like Ard towards preferring a configuration table though. > > Ok, if you want the DT loader to propagate UEFIDisplayInfo to a config > table, I can update the drm parts of my patchset to look for that in > addition to /chosen/panel-id > > > That removes the question of no runtime services (needing to manually > > cache things, at least until EBBR 1.2 (?) is out and in use), and > > means we don't have to use different paths for DT and ACPI. Now we > > have UEFI in U-Boot, do we really need to worry about the non-UEFI > > case? > > I've mixed feelings about requiring UEFI.. I definitely want to give > qcom an incentive to turn on GOP and full UEFI boot for future android > devices. OTOH there are quite a few devices out there that aren't > UEFI boot. But I guess if drm falls back to /chosen/panel-id we are > covered. > > > > I am a bit fearful of problems arising from different distros and > > > users using different versions of shim, and how to manage that. I > > > guess if somehow "shim thing" was part of the kernel, there would by > > > one less moving part... > > > > Sure, but that's insurance against bindings changing > > non-backwards-compatibly - which there are ways to prevent, and which > > streamlining the design for really isn't the way to discourage... > > > > Distros have no need to worry about the DT loader - the whole point of > > it is to remove the need for the distro to worry about anything other > > than getting the required drivers in. > > I'm a bit more concerned about DT loader getting into the business of > DT fixup.. I guess if we don't do that, it is less of a concern. But > if we relied on it to fixup DT for installed panel, we could probably > make it work semi-generically on existing devices that have bridge and > panel wired up same way. But seems like some of the 835 laptops have > bridge hooked up as child of dsi bus instead. And someday we could > see devices using dsi directly, etc. > > (It would be really nice to see DT loader able to pick the correct > .dtb based on smbios tables tho ;-).. but maybe different topic) > I think this is the only sane way of doing things: the DT loader, which is tied much more closely to the platform, does whatever it needs to do to infer from UEFI variables and/or ACPI or SMBIOS tables which bundled DT it installs, and whether/how it needs to fix things up. This indeed constitutes a moving part separate from the OS, but this is the only way that scales. Getting DTs for these devices into distros is *not* what we should be doing. > > > I'd know if user had kernel vX.Y.Z they'd be > > > good to go vs not. But *also* depending on a new-enough version of a > > > shim, where the version # is probably not easily apparent to the end > > > user, sounds a bit scary from the "all the things that can go wrong" > > > point of view. Maybe I'm paranoid, but I'm a bit worried about how to > > > manage that. > > > > Until the hardware abstractions provided by the system firmware (ACPI) > > is supported, these platforms are not going to be appropriate for > > end users anyway. No matter how many not-quite-upstream hacks distros > > include, they won't be able to support the next minor spin that comes > > off the production line and is no longer compatible with existing DTs. > > yeah, that will be a problem.. and also switching to older kernel > after upgrading when in-flight dt bindings evolve. Having one less > moving part would be nice. > The whole point of the discussion we have been having for years is that for production use cases, we should not be dealing with evolving in-flight DT binding in the first place. If we ship a DT loader with a certain version of the binding and there is a need to change it, we can only do so if we retain support for the old binding as well. > Maybe if adding a config table for UEFIDisplayInfo, you could also add > one for DT loader version, so (at least if user is able to get far > enough to get dmesg) we could see that more easily? > I'd prefer it if the DT loader were in charge of creating the UEFIDisplayInfo config tables, but given that we'll need to deal with platforms that don't implement runtime variable services, it is something I would be able to live with in the stub. In summary, working around platform limitations that prevent us from delivering an accurate DT to the OS should preferably be addressed in a platform specific pre-OS component. I haven't had the chance to look at leif's code yet, but from what I understand, we have pretty much what we need with the exception of the panel/gop variable handling, no? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels 2019-06-30 20:36 [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Rob Clark 2019-06-30 20:36 ` [PATCH 2/4] efi/libstub: detect panel-id Rob Clark @ 2019-06-30 20:47 ` Laurent Pinchart 2019-06-30 21:05 ` Rob Clark 2019-07-02 12:50 ` Rob Clark 2 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2019-06-30 20:47 UTC (permalink / raw) To: Rob Clark Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ard Biesheuvel, Catalin Marinas, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Ingo Molnar, Julien Thierry, open list:EXTENSIBLE FIRMWARE INTERFACE (EFI), open list, Lukas Wunner, Steve Capper, Will Deacon 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(-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels 2019-06-30 20:47 ` [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Laurent Pinchart @ 2019-06-30 21:05 ` Rob Clark 2019-06-30 21:15 ` Laurent Pinchart 0 siblings, 1 reply; 17+ messages in thread From: Rob Clark @ 2019-06-30 21:05 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ard Biesheuvel, Catalin Marinas, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Ingo Molnar, Julien Thierry, open list:EXTENSIBLE FIRMWARE INTERFACE (EFI), open list, Lukas Wunner, Steve Capper, Will Deacon On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > 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. Hi Laurent, Actually the bootloader on these devices is passing *no* dt (they boot ACPI, we are loading dtb from grub currently) I think normally a device built w/ dt in mind would populate /chosen/panel-id directly (rather than the way it is currently populated based on reading an efi variable prior to ExitBootServices). But that is considerably easier ask than having it re-write of_graph bindings. Either way, we aren't in control of the bootloader on these devices, so it is a matter of coming up with something that works on actual hw that we don't like rather than idealized hw that we don't have ;-) BR, -R ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels 2019-06-30 21:05 ` Rob Clark @ 2019-06-30 21:15 ` Laurent Pinchart 2019-06-30 21:35 ` Rob Clark 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2019-06-30 21:15 UTC (permalink / raw) To: Rob Clark Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ard Biesheuvel, Catalin Marinas, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Ingo Molnar, Julien Thierry, open list:EXTENSIBLE FIRMWARE INTERFACE (EFI), open list, Lukas Wunner, Steve Capper, Will Deacon Hi Rob, On Sun, Jun 30, 2019 at 02:05:21PM -0700, Rob Clark wrote: > On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart wrote: > > 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. > > Hi Laurent, > > Actually the bootloader on these devices is passing *no* dt (they boot > ACPI, we are loading dtb from grub currently) Ah, the broken promises of ACPI on ARM64. I wonder how long it will take before a public acknowledgement that it was a bad idea. Bad ideas happen and can be forgiven, but stubborness in claiming it was the right decision is another story. (Not that you can be blamed for this of course :-)) > I think normally a device built w/ dt in mind would populate > /chosen/panel-id directly (rather than the way it is currently > populated based on reading an efi variable prior to ExitBootServices). > But that is considerably easier ask than having it re-write of_graph > bindings. Either way, we aren't in control of the bootloader on these > devices, If you can't control the initial boot loader, then I see two options, none of which you will like I'm afraid. - As you pass the DT to Linux from grub, there's your intermediate boot loader where you can construct a valid DT. - If the ACPI cult needs to be venerated, then drivers should be converted to support ACPI without the need for DT. A possible a middleground could be a platform driver (in drivers/firmware/efi/ ? in drivers/platform/ ?) that will patch the DT to instantiate the right panel based on the information retrieved from the boot loader. We will need something similar for the Intel IPU3 camera driver, as Intel decided to come up with two different ACPI "bindings", one for Windows and one for Chrome OS, leaving Windows machine impossible to handle from a kernel driver due to required information being hardcoded in Windows drivers shipped by Intel. This is thus an option that may (unfortunately) need to become more widespread for ACPI-based systems. > so it is a matter of coming up with something that works on actual hw > that we don't like rather than idealized hw that we don't have ;-) That doesn't however justify not going for the best solution we can achieve. What do you like best in the above ? :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels 2019-06-30 21:15 ` Laurent Pinchart @ 2019-06-30 21:35 ` Rob Clark 0 siblings, 0 replies; 17+ messages in thread From: Rob Clark @ 2019-06-30 21:35 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, linux-arm-msm, freedreno, aarch64-laptops, Rob Clark, Ard Biesheuvel, Catalin Marinas, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Ingo Molnar, Julien Thierry, open list:EXTENSIBLE FIRMWARE INTERFACE (EFI), open list, Lukas Wunner, Steve Capper, Will Deacon On Sun, Jun 30, 2019 at 2:15 PM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Rob, > > On Sun, Jun 30, 2019 at 02:05:21PM -0700, Rob Clark wrote: > > On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart wrote: > > > 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. > > > > Hi Laurent, > > > > Actually the bootloader on these devices is passing *no* dt (they boot > > ACPI, we are loading dtb from grub currently) > > Ah, the broken promises of ACPI on ARM64. I wonder how long it will take > before a public acknowledgement that it was a bad idea. Bad ideas happen > and can be forgiven, but stubborness in claiming it was the right > decision is another story. > > (Not that you can be blamed for this of course :-)) To be fair, I think the only blame here is that MS let qcom get away with some things in their ACPI and UEFI implementation.. I think we'll need to shift to ACPI eventually for these laptops, in order to keep up. DT isn't a thing that would scale with the volume of x86 laptops that exist, and if aarch64 laptops get there too, we'll need ACPI. Lets face it, the # of different dt devices supported upstream is a drop in the bucket compared to number of *actually physically different* x86 devices supported by upstream. (And I don't mean individual models of laptops, but different production runs where they picked a different panel or trackpad or whatever.) But we have a lot of upstream work to get there to support how ACPI works on these things: * The new Platform Extension Plugin (PEP) model for device power control * untangling drm bridge hookup from DT * untangling drm panel hook from DT * figuring out how to deal with mis-matches between dt device model and ACPI device model There is some early work for ACPI support for these devices, but realistically I think it is going to take a better part of a year to get there. Until then we rely on DT. That isn't to say my proposal doesn't make a ton of sense. We also need to solve this problem for DT based devices, and I think /chosen/panel-id makes a *ton* of sense for those devices. > > I think normally a device built w/ dt in mind would populate > > /chosen/panel-id directly (rather than the way it is currently > > populated based on reading an efi variable prior to ExitBootServices). > > But that is considerably easier ask than having it re-write of_graph > > bindings. Either way, we aren't in control of the bootloader on these > > devices, > > If you can't control the initial boot loader, then I see two options, > none of which you will like I'm afraid. > > - As you pass the DT to Linux from grub, there's your intermediate boot > loader where you can construct a valid DT. not really a solution that is going to scale > - If the ACPI cult needs to be venerated, then drivers should be > converted to support ACPI without the need for DT. we're working on it > A possible a middleground could be a platform driver (in > drivers/firmware/efi/ ? in drivers/platform/ ?) that will patch the DT > to instantiate the right panel based on the information retrieved from > the boot loader. We will need something similar for the Intel IPU3 > camera driver, as Intel decided to come up with two different ACPI > "bindings", one for Windows and one for Chrome OS, leaving Windows > machine impossible to handle from a kernel driver due to required > information being hardcoded in Windows drivers shipped by Intel. This is > thus an option that may (unfortunately) need to become more widespread > for ACPI-based systems. again, a kernel (or bootloader) side massively intrusive re-write the dt approach isn't going to scale. If you keep it simple, ie. /chosen/panel-id I can see a possibility to move my patch from drivers/firmware/efi into an earlier stage. But if it has to re-write graph, that falls apart as soon as a new device comes along with a different bridge, or perhaps some vendor decides to use dsi directly and forego the bridge. usually (from what I've seen so far) there are a few gpios to probe to decide which panel you have. So after a few lines of gpio banging you can either ask fw engineers to set appropriate node in chosen.. or re-write of_graph bindings. I think the former has a chance of gaining traction on android devices.. latter not so much. You are really making too big of an ask for fw engineers ;-) > > so it is a matter of coming up with something that works on actual hw > > that we don't like rather than idealized hw that we don't have ;-) > > That doesn't however justify not going for the best solution we can > achieve. What do you like best in the above ? :-) I want a solution that is achievable ;-) BR, -R ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels 2019-06-30 20:36 [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Rob Clark 2019-06-30 20:36 ` [PATCH 2/4] efi/libstub: detect panel-id Rob Clark 2019-06-30 20:47 ` [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Laurent Pinchart @ 2019-07-02 12:50 ` Rob Clark 2 siblings, 0 replies; 17+ messages in thread From: Rob Clark @ 2019-07-02 12:50 UTC (permalink / raw) To: dri-devel, linux-arm-msm Cc: freedreno, aarch64-laptops, Rob Clark, Ard Biesheuvel, Catalin Marinas, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Ingo Molnar, Julien Thierry, Laurent Pinchart, open list:EXTENSIBLE FIRMWARE INTERFACE (EFI), open list, Lukas Wunner, Steve Capper, Will Deacon On Sun, Jun 30, 2019 at 1:36 PM Rob Clark <robdclark@gmail.com> 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.) > > 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>; > }; > }; > }; > } > }; > Just to put out an alternative idea for how to handle this in DT (since Laurent seemed unhappy with the idea of using endpoints to describe multiple connections between ports that *might* exist. This approach would require of_drm_find_panel() to check the device_node to see if it is a special "panel-select" thing. (I think we could use device_node::data to recover the actual selected panel.) On the plus side, it would work for cases that aren't using of_graph to connect display/bridge to panel, so it would be pretty much transparent to drivers and bridges. And I guess it could be extended to cases where gpio's are used to detect which panel is attached.. not sure how far down that road I want to go, as jhugo mentioned elsewhere on this patchset, in some cases dsi is used to select (which could be problematic to do from kernel if display is already active in video mode scanout), or efuses which aren't accessible from kernel. chosen { panel-id = <0xc4>; }; panel_select { compatible = "linux,panel-select"; #address-cells = <1>; #size-cells = <0>; boe_panel { compatible = "boe,nv133fhm-n61"; reg = <0xc4>; power-supply = <&vlcm_3v3>; no-hpd; }; ivo_panel { compatible = "ivo,m133nwf4-r0"; reg = <0xc5>; power-supply = <&vlcm_3v3>; no-hpd; }; ports { port { panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_out>; }; }; }; }; dsi_controller_or_bridge { ... ports { ... port@1 { reg = <1>; sn65dsi86_out: endpoint { remote-endpoint = <&panel_in_edp>; }; }; }; }; Personally I find my original proposal more natural (which is why I went with it, this second idea is more similar to what I initially had in mind before looking at of_graph). And it seems to be a bit weird to have a panel_select thing which isn't really hardware. BR, -R ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-07-03 17:55 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-30 20:36 [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Rob Clark 2019-06-30 20:36 ` [PATCH 2/4] efi/libstub: detect panel-id Rob Clark 2019-07-02 20:26 ` Ard Biesheuvel 2019-07-02 20:35 ` Ard Biesheuvel 2019-07-02 21:01 ` Rob Clark 2019-07-02 21:53 ` Ard Biesheuvel 2019-07-02 22:36 ` Rob Clark 2019-07-02 21:59 ` Leif Lindholm 2019-07-02 22:48 ` Rob Clark 2019-07-03 16:33 ` Leif Lindholm 2019-07-03 17:41 ` Rob Clark 2019-07-03 17:54 ` Ard Biesheuvel 2019-06-30 20:47 ` [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Laurent Pinchart 2019-06-30 21:05 ` Rob Clark 2019-06-30 21:15 ` Laurent Pinchart 2019-06-30 21:35 ` Rob Clark 2019-07-02 12:50 ` Rob Clark
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).