From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E557C06511 for ; Wed, 3 Jul 2019 00:26:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A4C321E6C for ; Wed, 3 Jul 2019 00:26:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RNTyqH/c" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726635AbfGCA0h (ORCPT ); Tue, 2 Jul 2019 20:26:37 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:36364 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbfGCA0h (ORCPT ); Tue, 2 Jul 2019 20:26:37 -0400 Received: by mail-ed1-f66.google.com with SMTP id k21so309917edq.3; Tue, 02 Jul 2019 17:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VZAFhtlOp5m5IcdkT0M3zeWqXJjIkrtR0IvKZYA1K+M=; b=RNTyqH/ceLcT+PerwCHJqQxAqAbl3I/4n9nfUD1rbqCMHjkJ1yjJKXPlhHVTm0/3PL GDDdjZpqLUCcBNL0fbqRqFHVIBYL3dg1iPSRIVfMivH59l0C4Q43EWRjv5swOEkCWxS7 XBg2EvsYn6GdfkIr52RA4wislpKD0gWQuqT/z8u/oke+PwuozA88rKogHM4x6rQexUei WKtlhaufWxo2iOfuPZrxA9BpY2Qsok8UP2uyDobE4mWGuCvZ2WsoIuHu1XKm7EQY/iJ5 uXdpSBj4pA4vd+0E6GyUmy4q45LBnFnFvioaja3bL7wS1Tf6iliwK6NKn2Jk9aBRGqS2 FuRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VZAFhtlOp5m5IcdkT0M3zeWqXJjIkrtR0IvKZYA1K+M=; b=j6E6dtJF/+f/sISn+FIJEubMaOBOc6J/fM1q6n2pLmFjGyYerweb4eKO9ZP9w0tyNY boxY9YrH2TbtgkItY6oZ1KSahSVpkfxasDMmVfqPHMPbZi3eSROOE4V9EhPRmOkcr+Hx t08GB6C3LXOJgjF3sUSiJIbjNlJLOZ1XccA3jdajcfMNoY6hrnsmrMfDDnTPmYxxIull xTLU12C1uhUe2lAhr14oKP/eTyqh4MW1R+nx8JrVQGAtBQJdaoV8rQdYT1/DY+UR8tP2 IOVo9U1+6eBtIqeA/VSMzW+lVNMjIcjIJF1J2DBFcXgfAQw2GF9t2okrNGgTYydgdiBF VpWA== X-Gm-Message-State: APjAAAVgl93QGe+Jv9q8IGB1kgFOAkgnDmgBuXPLExBPIPnfzI4Rk8fL va3HGQ5ykzqYzwyV/PSweYVV1AF5pUPyeM9YrG3eayTFv3M= X-Google-Smtp-Source: APXvYqwCaZ62YgXGr6Wefiah678BTMIgXWNniNpMylBAQqop4o300YsLoRAst/FDjF5RPt9iVWwNrtIHGTFPlYJxpS4= X-Received: by 2002:a17:906:6802:: with SMTP id k2mr5942794ejr.174.1562107010010; Tue, 02 Jul 2019 15:36:50 -0700 (PDT) MIME-Version: 1.0 References: <20190630203614.5290-1-robdclark@gmail.com> <20190630203614.5290-3-robdclark@gmail.com> In-Reply-To: From: Rob Clark Date: Tue, 2 Jul 2019 15:36:34 -0700 Message-ID: Subject: Re: [PATCH 2/4] efi/libstub: detect panel-id To: Ard Biesheuvel Cc: dri-devel , linux-arm-msm , freedreno , aarch64-laptops@lists.linaro.org, Rob Clark , Ingo Molnar , Will Deacon , Leif Lindholm , Steve Capper , Lukas Wunner , Julien Thierry , linux-efi , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Jul 2, 2019 at 2:53 PM Ard Biesheuvel wrote: > > On Tue, 2 Jul 2019 at 23:02, Rob Clark wrote: > > > > On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel wrote: > > > > > > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel wrote: > > > > > > > > On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote: > > > > > > > > > > From: Rob Clark > > > > > > > > > > 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 > > > > > > > > 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