[PATCH 2/4] efi/libstub: detect panel-id

[Rob Clark]

On Tue, Jul 2, 2019 at 2:53 PM Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>
> On Tue, 2 Jul 2019 at 23:02, Rob Clark <robdclark at gmail.com> wrote:
> >
> > On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> > >
> > > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> > > >
> > > > On Sun, 30 Jun 2019 at 22:36, Rob Clark <robdclark at gmail.com> wrote:
> > > > >
> > > > > From: Rob Clark <robdclark at 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 at 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