From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=loZF6iFk; spf=pass (domain: linaro.org, ip: 209.85.128.66, mailfrom: leif.lindholm@linaro.org) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by groups.io with SMTP; Tue, 01 Oct 2019 06:11:01 -0700 Received: by mail-wm1-f66.google.com with SMTP id f22so3190716wmc.2 for ; Tue, 01 Oct 2019 06:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=C6xhWzY6WeCdjHX+2grdJPilgq5pAoegDRFx2SCzmFQ=; b=loZF6iFk7thFjTmCmQp9+O04iAZf5+lA5BYqsJqA9m/k/RoVZMV12o3MbxqRNza67m OTPHbMrgIjBP8sZac3cd2Ctr9IU6uyWA4I9Wl2pqqGZicJJc+jIufNqGVIijFgz7mSOx C4ilhDgq8TBtdvIDm8h7kB1WIdfErLF5a2XODKY1iPy127coYl2WByyeHjVGtnSKVq+k EMznHxyjX+isRZT3GAZMYIcSto+c8Dg1hHVLrjZQupUEDNEbDb6tnl1XQfKxBVrTlxXN cumHIoSp85KGdIqFPCfOi+ldk0CoWL8sBbKDyfWthfelIx3yjuyDaaeVx5jWNxk8umh4 ZhzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=C6xhWzY6WeCdjHX+2grdJPilgq5pAoegDRFx2SCzmFQ=; b=b/G5Hb/dlA3hc0eSInptv6yZNpB8TX/pp95Kn92q/zW9rTrxSyrbNCGYrVRyP/Atyd FPMhZj3Nt4hj8+zpHyah+3A8M9I5uc7WsL/k0O3S1gASfGJoEWW1r+S6ZfrOwhGmOWU6 vmu2yf0dyWYxMpYBOdL5upso4nw5EufLnPa2JKYDfTZm86/8krZjF3ZwR3bOCbVBYaFZ M7GQShTsMEiugeflBney5QJ0wIrPENTI+/xFv6ZFrXKHCbZgobOzaOzwgKg2jgr9YgPV D2m+ECSZ7hgEVC5Io97FyjwLbVrjefxoYM/aQsKja7lTfz+XG6/1nbNP45uayHG5HaED vXOw== X-Gm-Message-State: APjAAAWLiElNckaJDh8lFb1vuiihnueFQDvokgo7C/ObUNFKINTCYox5 tu0nGOH88WlT2W7MLUHaToLaMQ== X-Google-Smtp-Source: APXvYqzAa7dQJn4XLrST5g7S14Qs0pljEU80eEZSNZD1+ISXGy17HcF+g8rrcnOXyEnSByHNPmxchg== X-Received: by 2002:a7b:c7d4:: with SMTP id z20mr3679416wmk.49.1569935459934; Tue, 01 Oct 2019 06:10:59 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id e3sm2560010wme.39.2019.10.01.06.10.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Oct 2019 06:10:58 -0700 (PDT) Date: Tue, 1 Oct 2019 14:10:57 +0100 From: "Leif Lindholm" To: Pete Batard Cc: devel@edk2.groups.io, ard.biesheuvel@linaro.org Subject: Re: [edk2-platforms PATCH 1/1] Platforms/RPi3: DisplayDxe virtual resolution improvements Message-ID: <20191001131057.GT25504@bivouac.eciton.net> References: <20190927092016.5604-1-pete@akeo.ie> <20190928230525.GX25504@bivouac.eciton.net> <46241f29-f783-25a2-417b-e42880b5de1d@akeo.ie> MIME-Version: 1.0 In-Reply-To: <46241f29-f783-25a2-417b-e42880b5de1d@akeo.ie> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 30, 2019 at 10:32:03AM +0100, Pete Batard wrote: > Hi Leif, > > On 2019.09.29 00:05, Leif Lindholm wrote: > > On Fri, Sep 27, 2019 at 10:20:15AM +0100, Pete Batard wrote: > > > From: Andrei Warkentin > > > > > > The Pi GPU decouples requested resolution from actual physical resolution > > > and can perform scaling of virtual resolutions. This enables platform users > > > to do something like ask for 1024x768 and get a framebuffer of that size, > > > regardless of the actual output (which could be a very blurry SDTV). > > > > > > Specifically, this patch allows selecting which specific virtual > > > resolutions to enable, thus replacing the old all-or-nothing behaviour > > > with either all virtual resolutions supported, or just the native one. > > > > > > This patch also adds enables the common 7" Pi (800x480) screen to be used > > > at 800x600 resolution, instead of forcing 640x480 as the only usable > > > resolution. > > > > I am basically OK with this patch, but I note that the change in > > variable name/content means existing users will end up with stale > > variables. > > > > So I wonder if it would be worth explicitly adding a stanza deleting > > the old variable if found? > > That would be a valid point *if* the Pi 3 was using actual NVRAM storage to > write those variables. > > However, we have no such thing on the hardware, so we currently store those > variables on the SD card, within the firmware file itself. > > Which means, the minute you "install" a new firmware (by replacing the > existing RPI_EFI.fd on your SD card with a new one), you're losing all your > existing variables anyway, including stale ones. Ah. That is sort of unique, but I see how it could still be useful. It was the EFI_VARIABLE_NON_VOLATILE that threw me. > Maybe with the Pi 4 and its 512 KB EEPROM, we'll be able to look into > preserving the variables. Or we may also look into writing variables to a > separate virtual NVRAM file on the SD card, instead of just reusing the .fd > (which we are doing for convenience). But for our current model, what you > highlight is a non issue, as the only "upgrade" path forces users to always > start with a virtual NVRAM that has been reset and that is therefore free > from any stale variable. Sure. this works. Reviewed-by: Leif Lindholm Pushed as 777573818e0c. Regards, Leif