[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191209191242.GA3075464@rani.riverdale.lan>
Date: Mon, 9 Dec 2019 14:12:42 -0500
From: Arvind Sankar <nivedita@...m.mit.edu>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: linux-efi@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Arvind Sankar <nivedita@...m.mit.edu>,
Bhupesh Sharma <bhsharma@...hat.com>,
Masayoshi Mizuma <m.mizuma@...fujitsu.com>
Subject: Re: [PATCH 6/6] efi/earlycon: Remap entire framebuffer after page
initialization
On Fri, Dec 06, 2019 at 04:55:42PM +0000, Ard Biesheuvel wrote:
> From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
>
> When commit 69c1f396f25b
>
> "efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation"
>
> moved the x86 specific EFI earlyprintk implementation to a shared location,
> it also tweaked the behaviour. In particular, it dropped a trick with full
> framebuffer remapping after page initialization, leading to two regressions:
> 1) very slow scrolling after page initialization,
> 2) kernel hang when the 'keep_bootcon' command line argument is passed.
>
> Putting the tweak back fixes #2 and mitigates #1, i.e., it limits the slow
> behavior to the early boot stages, presumably due to eliminating heavy
> map()/unmap() operations per each pixel line on the screen.
>
Could the efi earlycon have an interaction with PCI resource allocation,
similar to what commit dcf8f5ce3165 ("drivers/fbdev/efifb: Allow BAR to
be moved instead of claiming it") fixed for efifb?
Powered by blists - more mailing lists