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